Date: Mon, 31 Jul 2006 13:07:30 -0700 (PDT)
From: Rahul Aggarwal <rahul@juniper.net>
To: Yaakov Stein <yaakov_s@rad.com>
Subject: Re: [PWE3] BFD for MPLS PWs
In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D014D047B@exrad3.ad.rad.co.il>
Message-ID: <20060731125428.U26800@sapphire.juniper.net>
References: <457D36D9D89B5B47BC06DA869B1C815D014D047B@exrad3.ad.rad.co.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: pwe3@ietf.org
Precedence: list
Errors-To: pwe3-bounces@ietf.org


Hi Yaakov,

On Mon, 31 Jul 2006, Yaakov Stein wrote:

> 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?
>

a) Section 3.1.

"The LSP may be  associated with any of the following FECs:
RSVP IPv4/IPv6 Session [RFC3209]
     b) LDP IPv4/IPv6 prefix [RFC3036]
     c) VPN IPv4/IPv6 prefix [RFC4364]
     d) Layer 2 VPN [L2-VPN]
     e) Layer 2 Circuit ID [RFC4447]"

Note (e). This implies that the procedures in this draft apply to all of
the above FECs, including PWs.

b) Section 7.

"BFD control packets sent by the ingress LSR MUST be encapsulated in
   the MPLS label stack that corresponds to the FEC for which fault
   detection is being performed. If the label stack has a depth greater
   than one, the TTL of the inner MPLS label MAY be set to 1. This may
   be necessary for certain FECs to enable the egress LSR's control
   plane to receive the packet [LSP-Ping]. For MPLS PWs, alternatively,
   the presence of a fault detection message may be indicated by setting
   a bit in the control word [VCCV]."


The above describes the encapsulation from the ingress to the egress LSR
and applies to PWs as well. It allows for VCCV procedures for indicating
whether a message is a fault detection message.

Further, the following para completes the encapsulation description:

"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]. The source
   IP address is a routable address of the sender. The destination IP
   address is randomly chosen from the 127/8 range, with the following
   exception. If the FEC is a LDP IP FEC the ingress LSR may discover
   multiple alternate paths to the egress LSR for this FEC using LSP-
   ping traceroute. In this case the destination IP address, used in a
   BFD session established for one such alternate path, is the address
   in the 127/8 range discovered by LSP-ping traceroute [RFC4379] to
   exercise that particular alternate path."

c) Section 7.

"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.

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. This may also be the case when there is a return LSP from
   the egress LSR to the ingress LSR."

This describes the encapsulation from egress to ingress and states that
for a MPLS PW, the return epackets are UDP packets encapsulated in a MPLS
label stack of the FEC.

The above, (a), (b) and (c) spell out the encapsulation procedures for BFD
for MPLS PWs. Further they point to VCCV for defining how the fault
detection messages are indicated, other than using the TTL.

To put it differently, the BFD-MPLS spec, applies to all FECs in section
3.1. Where there are additional details, eg. PWs, the spec spells out
these details or points to specs that spell out the details, eg. VCCV.

Hope this helps.

rahul




> Y(J)S
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>
>

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3