The MPLS WG Archive

["Girish" <girish23@onebox.com>]

Per 2547, the vpn-ipv4 NLRI carried in a BGP update message is supposed
to follow the RFC 3107 ("Carrying Label Information in BGP-4") specifications.
This mandates that for the case where more than one label is sent with
a prefix (the "prefix" for vpn-ipv4 being {RD+IPv4 prefix}), then the
last label in the stack should be marked with a "bottom of stack" bit.

Atleast w/ a Cisco, I have verified that the update message does have
the bottom of stack bit marked in the label (however in this case, just
1 label was being carried).

The part where I suspect the bug lies is when a Cisco or a Juniper receive
vpn-ipv4 update messages. I am working with a box which (incorrectly)
*does not* mark this bottom of stack bit...but at the same time never
sends more than one label per vpn-ipv4 prefix. Nonetheless, I would expect
this box to not interoperate w/ Cisco or Juniper. When the update message
from this box reaches the Cisco/Juniper, they would look for a "bottom
of stack" bit which is missing.

The fact, though, is that this box does interoperate w/ Cisco and Juniper...I'd
like to understand how that's possible unless Cisco and Juniper are not
following 3107 and are detecting that there is exactly  one label some
other way. It doesn't seem like it is possible to detect this from the
length of the NLRI. Suppose the length is 15, then it could be that 3
bytes are for used label, 8 bytes for RD and 3 bytes of prefix OR that
6 bytes are used for 2 labels, 8 bytes for RD and 1 byte for prefix.

Girish







__________________________________________________
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com