Subject: RE: [PWE3] BFD for MPLS PWs

From: "Sasha Vainshtein" <[email-masked]>
Date: Mon, 31 Jul 2006 19:05:10 +0200

Yaakov and all,
It is my understanding that the BFD-MPLS draft treats PWs just as a pair of uni-directional LSPs
and hence the encapsulation described in Section 7 of this draft fully applies.

In particular:

<quote>
   The BFD control packet sent by the ingress LSR MUST be a UDP packet
   with a well known destination port 3784 [BFD-IP] and a source port
   assigned by the sender as per the procedures in [BFD-IP]. 

... snipped ...

   BFD control packets sent by the egress LSR are UDP packets. The
   source IP address is a routable address of the replier; the source
   port is the well-known UDP port 3784.  The destination IP address and
   UDP port MUST be copied from the source IP address and UDP port of
   the control packet received from the ingress LSR.

... snipped ...
   The BFD control packet sent by the egress LSR to the ingress LSR MAY
   be routed based on the destination IP address as per the procedures
   in [BFD-MHOP]. Or the BFD control packet sent by the egress LSR to
   the ingress LSR MAY be encapsulated in a MPLS label stack. If this is
   the case the presence of  the fault detection message is indicated as
   described above.  This may be the case if the FEC for which the fault
   detection is being perfomed corresponds to a bi-directional LSP or a
   MPLS PW.
<end quote>

This means, IMHO, that, in the case of PWs:

- BFD requests MUST sent over the PW Associated Channel in the appropriate direction of the PW
- BFD replies SHOULD be sent over the PW Associated Channel in the reverse direcion of the PW 
  If the receiver is indeed the peer PW end point, and MAY be sent directly over IP if the BFD request 
  has been received by another entity. 

It would be probably nice to clarify this point in the VCCV draft.

It should be also noted that the PW Associated Channel does not always use the first 
nibble of the CW for discrimination. The most obvious use case is represented by the PWs 
that do not use CW, e.g., Ethernet PWs.  (AFAIK, all existing implementations support 
Ethernet PWs without CW in accordance with RFC 4448 and most do not support CW). 

For these PWs it is still possible to discriminate VCCV and PW packets (e.g., by using the 
Router Alert label above the PW one),  but it is impossible to carry additional information
(e.g., type of the VCCV packet). 

If we agree that IP (and only IP) packets are carried over the Associated Channel, we can then 
use IP protocol numbers and, where appropriate, well-known UDP ports for additional discrimination. 

One of the possible applications would be the proposal to carry Y.1731 (Ethernet OAM) PDUs over VCCV.
It would looks somewhat bizarre, IMHO, if this proposal were not applicable to Ethernet PWs, and one
way to resolve this controversy could be by encapsulating these PDUs into IP packets with EtherIP
 (RFC 3378) protocol number.

Regards,
                            Sasha

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Monday, July 31, 2006 6:02 PM
> To: [email-masked]; [email-masked]
> Subject: [PWE3] BFD for MPLS PWs
> 
> 
> Rahul, 
>  
> At the PWE session you stated that the MPLS BFD draft
> described the use of BFD for PWs, and that the VCCV draft
> and the BFD MPLS draft need to remain aligned.
>  
> The only mention I find in draft draft-ietf-bfd-mpls-03.txt of PWs
> is the following motivational text:
>  
>    2. MPLS Pseudo Wires (PW). Fast detection may be desired for MPLS
>    PWs depending on i) the model used to layer the MPLS 
> network with the
>    layer 2 network. and ii) the service that the PW is 
> emulating. For a
>    non-overlay model between the layer 2 network and the MPLS network
>    the provider may rely on PW fault detection to provide 
> service status
>    to the end-systems. Also in that case interworking 
> scenarios such as
>    ATM/Frame Relay interworking may force periodic PW fault detection
>    messages. Depending on the requirements of the service 
> that the MPLS
>    PW is emulating, fast failure detection may be desirable. 
> Use of BFD
>    for PWs is further described in [VCCV] and [OAM-MAP].
> 
> I don't see any normative text here, and certainly nothing describing
> whether or not UDP is used. What I do see is a pointer to VCCV,
> so that any changes in VCCV should reflect here.
> 
> Section 4 on "theory of operation" seems to be silent on PW issues.
> 
> Am I missing something?
> 
> 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: "Yaakov Stein" <[email-masked]>
Date: Mon, 31 Jul 2006 20:32:32 +0200

Sasha,  

> and hence the encapsulation described in Section 7 of this draft fully
applies.

Yes, I believe so as well. But that is not what Rahul said.
If I understood him, he stated that there was specific text in the MPLS
BFD
draft about PWs that should not be contradicted by the VCCV text.

>   has been received by another entity. 

But as I have stated before, this is interpretation on our part.

> It would be probably nice to clarify this point in the VCCV draft.

Agreed.

> It should be also noted that the PW Associated Channel does not always
use the first nibble of the CW for discrimination. 
> The most obvious use case is represented by the PWs that do not use
CW, e.g., Ethernet PWs.  
> (AFAIK, all existing implementations support Ethernet PWs without CW
in accordance with RFC 4448 and most do not support CW). 

A historical mistake that should be rectified by using the CW whenever
one wants to use VCCV.

> If we agree that IP (and only IP) packets are carried over the
Associated Channel, 
> we can then use IP protocol numbers and, where appropriate, well-known
UDP ports for additional discrimination. 

But I, for one, do not agree.

I believe we should expand the possibilities of the PWACH code points
instead,
and avoid the needless and confusing IP header.

> It would looks somewhat bizarre, IMHO, if this proposal were not
applicable to Ethernet PWs, 
> and one way to resolve this controversy could be by encapsulating
these PDUs into IP packets 
> with EtherIP  (RFC 3378) protocol number.

Inelegant to say the least.

Y(J)S

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 31 Jul 2006 13:12:31 -0700 (PDT)

Hi Sasha,

> - BFD requests MUST sent over the PW Associated Channel in the appropriate direction of the PW

Yes. BFD-MPLS draft doesn't use the term PW associated channel and
probably doesn't need to. It leaves sufficient room for VCCV and other
PWE3 specs to define the term PW associated channel, without conflicting
with procedures in BFD-MPLS. It leaves room for using the inner label TTL,
router alert label or a special indicator for indicating fault detection
messages.

> - BFD replies SHOULD be sent over the PW Associated Channel in the reverse direcion of the PW

Yes.

>   has been received by another entity.

Yes.

> It would be probably nice to clarify this point in the VCCV draft.

The VCCV draft should follow the BFD-MPLS encaps defined in BFD-MPLS. A
simple reference, which I believe already exists, would suffice.

rahul

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 31 Jul 2006 13:14:31 -0700 (PDT)

Hi Yaakov,

> draft about PWs that should not be contradicted by the VCCV text.

See my earlier email the describes how BFD-MPLS spells out the
encapsulation for BFD for PWs. VCCV must not contradict this. Infact the
version of VCCV which is currently published, does *not* have any
contradictions.

> But as I have stated before, this is interpretation on our part.

The interpretation is correct - see my reply to Sasha.

rahul