Subject: BFD for MPLS

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 8 Sep 2008 15:30:56 +0530

Hi,

I found some basic issues with the BFD MPLS LSP's draft.

1. When talking about IPv6 the notation for IPv6 address is wrong. The
address 0:0:0:0:0:FFFF:7F00/104  is not an IPv6 address at all. Please
read RFC4291. It should be put as 0:0:0:0:0:FFFF:7F00::/104
everywhere.

Here are some explicit examples I am adding for your help

   "For example, the following are legal representations of the 60-bit
   prefix 20010DB80000CD3 (hexadecimal):

      2001:0DB8:0000:CD30:0000:0000:0000:0000/60
      2001:0DB8::CD30:0:0:0:0/60
      2001:0DB8:0:CD30::/60

   The following are NOT legal representations of the above prefix:

      2001:0DB8:0:CD3/60   may drop leading zeros, but not trailing
                           zeros, within any 16-bit chunk of the address

      2001:0DB8::CD30/60   address to left of "/" expands to
                           2001:0DB8:0000:0000:0000:0000:0000:CD30

      2001:0DB8::CD3/60    address to left of "/" expands to
                           2001:0DB8:0000:0000:0000:0000:0000:0CD3"

2. The RFC states that "If the label stack has a depth greater than
one, the TTL of the inner MPLS label MAY be set to 1."

However in case of a label stack there are multiple levels of labels.
What is meant by inner label here? Do we mean all inner labels?

3. The draft states that:

"   Note that once the BFD session for the MPLS LSP is UP, either end of
   the BFD session MUST NOT change the source IP address and the local
   discriminator values of the BFD control packets it generates, unless
   it first brings down the session."

Doesn't this violate the basics of what the BFD base spec states? How
can an application apply a rule to how the base protocol works? The
base BFD RFC states that:

"   Note that it is permissible for a system to change its discriminator
   during a session without affecting the session state, since only that
   system uses its discriminator for demultiplexing purposes (by having
   the other system reflect it back.) "

Thanks,
Vishwas

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 08 Sep 2008 21:55:03 -0700

>    the other system reflect it back.) "

MPLS BFD is a specific use case of BFD-Base and hence MPLS-BFD can apply
specific provisions to the use of BFD-Base.

In MPLS-BFD, discriminators are learnt using LSP-Ping. So you don't want the
other end to randomly change the discriminator. If the discriminator needs
change, then that change should probably come via LSP-Ping.

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 9 Sep 2008 13:44:21 +0530

Hi Nitin,

Thanks for the reply and great to see your mail. It is encouraging to
see some discussion (I was just beginning to become unsure if the list
was still alive or not).

> specific provisions to the use of BFD-Base.
I agree to the specific provisions can be applied however here the
base protocol itself is changed (where the base protocol gives a
different behavior an application using it states a different one). It
is also a layering violation too (base protocol now needs to be aware
of the application using it and hence changing behavior based on
that).

I guess any check so required should be done in the application and it
should not limit the base specification for this.

> change, then that change should probably come via LSP-Ping.

Yes, I got that part correct. thanks a lot for explaining it.

Thanks again,
Vishwas

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 09 Sep 2008 12:52:19 -0700

> should not limit the base specification for this.

I agree. Where you do the  check is implementation specific. From a design
perspective, this is a special case of BFD for MPLS and the MPLS specific
client code should enforce that.

But there is a small aspect of BFD here, that the BFD state machine should
not allow discriminator change (if it doesn't come from LSP-Ping). I guess
the draft tries to point out this specific case....I don't think the
intention of the draft is to say that the change is not allowed even via
lsp-ping.

Nitin