Subject: RE: [PWE3] VCCV BFD mode

From: "Sasha Vainshtein" <[email-masked]>
Date: Thu, 25 May 2006 15:09:12 +0200

Yaakov, Rahul and all.
I think  that VCCV in the BFD mode, just as LSP-Ping, shall use Destination IP address from 127/8 (loopback addresses).
If this is correct, it would resolve the problem mentioned by Yaakov.

My 2 c

Regards,
                               Sasha

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Thursday, May 25, 2006 2:52 PM
> To: Rahul Aggarwal
> Cc: pwe3
> Subject: RE: [PWE3] VCCV BFD mode
> 
> 
> Rahul
> 
> Sorry that my response has been so delayed - 
> too much work on non-related topics.
> 
> I will explain the problem I have with the UDP/IP encapsulation.
> 
> In my opinion one of the main advantages in using MS-PWs
> is to enable continuous end-to-end OAM at the PW level
> by using VCCV.
> 
> But alhtough I have no problem placing BFD messages 
> in the VCCV channel, I will in general not know the IP
> address of the U-PE.
> 
> So I would need to run the BFD segment by segment,
> which defeats the whole purpose.
> 
> BFD should run over the available channel,
> which in this case is the MS-PW,
> without need for identifiers from higher layers.
> 
> Y(J)S
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 25 May 2006 09:04:36 -0400

> Yaakov, Rahul and all.
> I think  that VCCV in the BFD mode, just as LSP-Ping, shall use  
> Destination IP address from 127/8 (loopback addresses).

	Yes, the intent for MH-VCCV is to use the
same target PE address that is used to signal the
PW.  Remember, VCCV will use the same encap header
to transmit the VCCV packets as data packets.

	--Tom

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 25 May 2006 14:14:15 +0100

> If this is correct, it would resolve the problem mentioned by Yaakov.

We need to consider what architecture we want.

If we run BFD over IP over PW (with the loopback address)
we are really running it between the control plane endpoints,
because the layering requires us to remove the PW headers
and deliver the packet to the object that is addressed
by the IP address that is carrying the VCCV packet.

If we omit the IP header we are running BFD strictly between
the PW demux endpoints and the BFD packet never exits the
PW environment.

What would we do if we were running static PWs? In that case
we strictly do not need an IP address at all, so what IP address
would we use?

I think that if we run BFD directly over the PW we
achieve the best match between the scope of the packet
and the object we are testing, and at the same time increase
the flexibility of VCCV to run in a number of tunnel
enviroments.

Other views?

- Stewart

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 25 May 2006 07:40:17 -0700 (PDT)

Hi Sasha and Yakov,

> If this is correct, it would resolve the problem mentioned by Yaakov.

That is correct.

rahul

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 25 May 2006 08:01:04 -0700 (PDT)

Hi Stewart,

I would like a few clarifications on your email before commenting further.

Please see inline:

On Thu, 25 May 2006, Stewart Bryant wrote:

> the PW demux endpoints

How is a PW demux endpoint identified ?

> and the BFD packet never exits the
> PW environment.
>

What is the PW environment ?

More specifically what is the PW environment for PW data packets and what
is the PW environment for PW OAM packets ?

> What would we do if we were running static PWs?

What is a static PW ? It will be great if you can point me to text in PW
architecture or requirements or protocol specifications that explain what
is a static PW.

Thanks,
rahul

> In that case

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 25 May 2006 18:10:51 +0100

> How is a PW demux endpoint identified ?

By the PSN lable + the PW lable, or by the PE IP address + session ID

> is the PW environment for PW OAM packets ?

Perhaps I mean context.
The PE has demuxed the PW packet, so it knows what
PW it is dealing with. It also knows whether the payload
is data (0000) or ACH (0001). The issue is why we now
need to unravel two more levels of demux to get to the
BFD packet and process it?

> architecture or requirements or protocol specifications that explain what

RFC 4447                     PWE3 Using LDP                   April 2006

    In addition to the protocol specified herein, static assignment of PW
    labels may be used, and implementations of this protocol SHOULD
    provide support for static assignment.

Remember that SATOP does not yet have a control plane, and none of
the ITU defines PWs have a control plane.

- Stewart

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Thu, 25 May 2006 14:34:34 -0400

Stewart,
See below.

Mustapha. 

> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Thursday, May 25, 2006 9:14 AM
> To: pwe3
> Subject: Re: [PWE3] VCCV BFD mode
> 
> Sasha Vainshtein wrote:
> 
> > Yaakov, Rahul and all.
> > I think  that VCCV in the BFD mode, just as LSP-Ping, shall 
> use Destination IP address from 127/8 (loopback addresses).
> If we run BFD over IP over PW (with the loopback address) we 
> are really running it between the control plane endpoints, 
> because the layering requires us to remove the PW headers and 
> deliver the packet to the object that is addressed by the IP 
> address that is carrying the VCCV packet.
> 
> the PW demux endpoints and the BFD packet never exits the PW 
> environment.
> 
> we strictly do not need an IP address at all, so what IP 
> address would we use?
> 
> I think that if we run BFD directly over the PW we achieve 
> the best match between the scope of the packet and the object 
> we are testing, and at the same time increase the flexibility 
> of VCCV to run in a number of tunnel enviroments.
> 
> Other views?

MA> I would vote in favor of keeping BFD over PWs inline with BFD over LSPs.
I know there are tradeoffs in terms of what is being exercised by the BFD
message but implementation wise, this is what we do for VCCV Ping.

As for static PWs, there are two cases to consider:
1. Static PW configured on a node compliant to the PWE3 architecture. In
that case, all what is needed is to provide local configuration on the node
of the BFD capabilities since there is no T-LDP session to be used for the
negotiation of these parameters. 

2. Static PWs on an ITU compliant architecture with no IP control plane. In
that case, it is up to ITU to define what OAM mechanisms they want to use.
In fact, Y.1711 already defined a feature called Fast Failure Detection
(FFD) and which includes a LSP Trail Termination Source Identifier (TTSI).
The latter is a which includes a LSR ID and a LSP ID. The LSR ID can be in
IPv6 or IPv4 format. I assume they will extend this feature to operate over
interworking LSPs (PW in ITU architecture).

---

From: "Florin Balus" <[email-masked]>
Date: Fri, 26 May 2006 08:32:49 -0400

>> Destination IP address from 127/8 (loopback addresses). If this is 
>> correct, it would resolve the problem mentioned by Yaakov.
>> 
>> My 2 c
>> 
>> Regards,
>>                                Sasha
>> 
>
>the flexibility of VCCV to run in a number of tunnel enviroments.
>

I agree. I think we should investigate at least this type of
architecture. PWE3 at the end of the day represent just a L2 connection
between 2 endpoints and we should be able to test just its data path
components.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 26 May 2006 09:03:45 -0400

> interworking LSPs (PW in ITU architecture).

	I totally disagree with this. Why would you
want to implement two completely different mechanisms
within the same box/code?  Chances are that the same vendors
will be building a single code base/box that can do both
static and dynamic.

	--Tom

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Fri, 26 May 2006 10:47:05 -0400

> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: Friday, May 26, 2006 9:04 AM
> To: Mustapha Aissaoui
> Cc: 'pwe3'; 'Stewart Bryant'
> >> If we run BFD over IP over PW (with the loopback address) we are 
> >> really running it between the control plane endpoints, because the 
> >> layering requires us to remove the PW headers and deliver 
> the packet 
> >> to the object that is addressed by the IP address that is carrying 
> >> the VCCV packet.
> >>
> >> If we omit the IP header we are running BFD strictly 
> between the PW 
> >> demux endpoints and the BFD packet never exits the PW environment.
> >>
> >> What would we do if we were running static PWs? In that case we 
> >> strictly do not need an IP address at all, so what IP 
> address would 
> >> we use?
> >>
> the best 
> >> match between the scope of the packet and the object we 
> are testing, 
> >> and at the same time increase the flexibility of VCCV to run in a 
> >> number of tunnel enviroments.
> >>
> >> Other views?
> >
> > I know there are tradeoffs in terms of what is being 
> exercised by the 
> > BFD message but implementation wise, this is what we do for 
> VCCV Ping.
> >
> > 1. Static PW configured on a node compliant to the PWE3 
> architecture. 
> > In that case, all what is needed is to provide local 
> configuration on 
> > the node of the BFD capabilities since there is no T-LDP 
> session to be 
> > used for the negotiation of these parameters.
> >
> > 2. Static PWs on an ITU compliant architecture with no IP control 
> > plane. In that case, it is up to ITU to define what OAM mechanisms 
> > they want to use.
> > The latter is a which includes a LSR ID and a LSP ID. The 
> LSR ID can 
> > be in
> > IPv6 or IPv4 format. I assume they will extend this feature 
> to operate 
> > over interworking LSPs (PW in ITU architecture).
> 
> 	I totally disagree with this. Why would you want to 
> implement two completely different mechanisms within the same 
> box/code?  Chances are that the same vendors will be building 
> a single code base/box that can do both static and dynamic.
> 
> 	--Tom

This is not about static vs dynamic. This is about architecture choices. The
ITU architecture for MPLS/PW is different than PWE3. It is up to ITU to
decide what OAM mechanisms they want to use. 

As for static PW support as per the PWE3 architecture, which is the point of
this email discussion, point 1 above states that this can be done with the
same implementation as dynamic PWs except for the local configuration of the
BFD parameters.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 26 May 2006 12:19:38 -0400

> decide what OAM mechanisms they want to use.

	Sure, have fun. *)

> same implementation as dynamic PWs except for the local  

	Yes.

	--tom