Subject: [PWE3] VCCV BFD mode

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 8 May 2006 19:57:41 +0200

Hi all, 
 
I have two problems with the BFD mode in the VCCV draft.

1) The text is unclear on the encapsulation.  
The method used in practice is to send BFD over UDP/IP 
inside a PW associated channel packet.
However, this is not clear in the draft, which seems to imply
that the BFD payload is placed directly in the PWACH packet.

This would also be the obvious way to send BFD. 

Quoting draft-ietf-bfd-base:

      BFD operates on top of any data protocol being forwarded 
      between two systems. 

Quoting draft-ietf-bfd-generic

       BFD is intended to protect a single "data protocol" 
       and is encapsulated within that protocol. 

So since the BFD is protecting the PW, why does a UDP/IP
encapsulation stand in between the BFD and the PW encap?

To further moddule matters, the VCCV draft references the BFD over MPLS
draft
but not the BFD over v4v6 one (where use of UDP is specified).

Of course, to send BFD directly in a PWACH packet
we would need to define a new "channel type"
(presently RFC 4385 only defines 0x21 of IPv4 and 0x57 for IPv6).

2) The VCCV draft states: 

   In order to use BFD, both ends of the PW connection must have sig-
   naled the existence of a control channel and the ability to run BFD.
   Once a node has both signaled and received signaling from its peer of
   these capabilities, it MUST begin sending BFD control packets. The
   packets MUST be sent on the control channel. The use of the control
   channel provides the context required to bind the BFD session to a
   particular PW (FEC). Thus normal BFD initialization procedures are
   followed. 

So the draft presently requires first negotiating VCCV capabilities for
BFD, 
and then a second BFD negotiation. It would seem sufficient to do one or
the other.

I would pick doing the VCCV negotiation and immediately
start sending BFD format packets.

Y(J)S

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

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 11 May 2006 12:50:36 -0700 (PDT)

Hi Yaakov,

> inside a PW associated channel packet.

Yes.

> that the BFD payload is placed directly in the PWACH packet.

This needs to be clarified. Thanks for pointing it out.

> but not the BFD over v4v6 one (where use of UDP is specified).

The BFD over MPLS draft describes the encapsulation of BFD over a MPLS LSP
which includes PWs. This encaps is clearly defined to include UDP/IP
encaps. It does not currently clarify that there may be a
ACH that sits in between the MPLS label stack and the BFD packet. It
needs to do this.

In addition I think it is reasonable to add a reference to BFD-V4-V6 in
the VCCV spec.

> (presently RFC 4385 only defines 0x21 of IPv4 and 0x57 for IPv6).

Yes. It has few other issues:

- It would result in BFD encaps over PWs to deviate from BFD
encaps over other MPLS LSPs.
- It would result in loosing information of the PW source. The IP source
address adds robustness and enables checking a BFD over MPLS packet to be
from the expected source.

Further LSP-Ping for PWs uses an IP/UDP header as well. So why deviate for
BFD ?

> start sending BFD format packets.

BFD is asynchronous. All that this text is suggeting is that both ends
will not initiate BFD on the PW unless they know that both ends are
capable of VCCV using BFD.

rahul

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 14 May 2006 15:43:37 +0200

Rahul,  

> - It would result in BFD encaps over PWs to deviate from BFD encaps
over other MPLS LSPs.

> - It would result in loosing information of the PW source. The IP
source address adds robustness 
>   and enables checking a BFD over MPLS packet to be from the expected
source.

I think that both of your points are basically the same argument.
MPLS needs the IP Source address due to the possibility of LSP merging.
With PWs we do not define merging and thus don't need the source
address.

> Further LSP-Ping for PWs uses an IP/UDP header as well. So why deviate
for BFD ?

See above.

> BFD is asynchronous. All that this text is suggeting is that both ends
will not initiate BFD on the PW 
> unless they know that both ends are capable of VCCV using BFD.

Don't they already know that from the control-protocol VCCV parameter? 
If a PE does not support BFD inside VCCV it will not set
the bit in the CV indicator. 

Y(J)S

---

From: Rahul Aggarwal <[email-masked]>
Date: Sun, 14 May 2006 08:37:53 -0700 (PDT)

Hi Yaakov,

> I think that both of your points are basically the same argument.

It was actually one point.

> With PWs we do not define merging and thus don't need the source

That is not entirely accurate. One reason for PW OAM is to detect
possible corruption in the data plane. It is possible that the end point
of a MPLS PW-BFD  connection receive packets with the destination
discriminator from the *wrong* source and the same PW label because of
data plane corruption. Ensuring that the packet is from the expected source adds
robustness. You may want to look at the
Encapsulation section of draft-ietf-bfd-mpls for further details.

> > Further LSP-Ping for PWs uses an IP/UDP header as well. So why deviate

This is a different point. If you believe that PW OAM in general doesn't
require the source address than your argument would apply to LSP-Ping for
PWs as LSP-Ping is yet another mechanism for OAM.

There is another issue. The VCCV spec lists three means of
detecting OAM packets in the
data path: router alert labels, TTL expiration, CW

For the first two how would the egress  demultiplex the type of OAM
packet if the IP header is not carried in *all* OAM packets ?

> the bit in the CV indicator.

That is exactly what the text is meant to suggest. If you belive that the
text is not accurate enough please point out what needs to be changed.

rahul

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 25 May 2006 14:52:05 +0200

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