Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Quagga: Dev

MPLS VPN in bgpd

 

 

Quagga dev RSS feed   Index | Next | Previous | View Threaded


chris.hall.list at highwayman

May 5, 2012, 11:53 AM

Post #1 of 4 (504 views)
Permalink
MPLS VPN in bgpd

For my many sins I have spent the day looking at the SAFI_MPLS_VPN
stuff.

I note that when constructing an MP_REACH and an MP_UNREACH that the
tag part does not appear to have the "Bottom of Stack" bit set. Now,
this may be because somewhere in the RFCs it says that there will only
ever be one label in the stack for MP_REACH. Of course, MP_UNREACH
goes with a single NULL Label in any case...

Can anyone point me in the direction of the RFC which says that
"Bottom of Stack" is not required ? Or have I missed the piece of
code which sets it ?

Thanks,

Chris
--
Chris Hall, Highwayman



_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


renatowestphal at gmail

May 5, 2012, 2:09 PM

Post #2 of 4 (482 views)
Permalink
Re: MPLS VPN in bgpd [In reply to]

2012/5/5 Chris Hall <chris.hall.list [at] highwayman>:
> For my many sins I have spent the day looking at the SAFI_MPLS_VPN
> stuff.
>
> I note that when constructing an MP_REACH and an MP_UNREACH that the
> tag part does not appear to have the "Bottom of Stack" bit set.  Now,
> this may be because somewhere in the RFCs it says that there will only
> ever be one label in the stack for MP_REACH.  Of course, MP_UNREACH
> goes with a single NULL Label in any case...
>
> Can anyone point me in the direction of the RFC which says that
> "Bottom of Stack" is not required ?  Or have I missed the piece of
> code which sets it ?

The "Bottom of Stack" bit is required. RFC 3107 says "Each label is
encoded as 3 octets, where the high-order 20 bits contain the label
value, and the low order bit contains Bottom of Stack".

For solutions like MPLS VPN and 6[V]PE only one label is advertised
for each prefix, so the BoS bit is always set. RFC3107 supports the
advertisement of multiple labels for each prefix, but AFAIK this isn't
used anywhere.

In practice, most implementations set the BoS bit to 1 when
advertising an MPLS labeled route but ignore the BoS bit when
receiving an MPLS labeled route (including Quagga for VPNv4 route
reflection).

--
Renato Westphal

_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


chris.hall.list at highwayman

May 6, 2012, 3:21 AM

Post #3 of 4 (482 views)
Permalink
Re: MPLS VPN in bgpd [In reply to]

Renato Westphal wrote (on Sat 05-May-2012 at 22:10 +0100):
> 2012/5/5 Chris Hall <chris.hall.list [at] highwayman>:
...
> > Can anyone point me in the direction of the RFC which says that
> > "Bottom of Stack" is not required ?  Or have I missed the piece of
> > code which sets it ?

> The "Bottom of Stack" bit is required. RFC 3107 says "Each label is
> encoded as 3 octets, where the high-order 20 bits contain the label
> value, and the low order bit contains Bottom of Stack".

Indeed it does. It also says that the label information "in the
Withdrawn Routes field should be set to 0x800000" which I think means
that I am not alone in finding the IETF convention of numbering bits
from 0 at the MS end just a touch confusing :-(

> For solutions like MPLS VPN and 6[V]PE only one label is advertised
> for each prefix, so the BoS bit is always set. RFC3107 supports the
> advertisement of multiple labels for each prefix, but AFAIK this
> isn't used anywhere.

I thought that might be the case. I haven't spotted anything in the
RFCs (eg 4364 and 4659) that refer to RFC3107 to say that there will
always only be one label.

> In practice, most implementations set the BoS bit to 1 when
> advertising an MPLS labeled route but ignore the BoS bit when
> receiving an MPLS labeled route (including Quagga for VPNv4 route
> reflection).

Certainly Quagga takes no notice and simply assumes that all label
stacks always contain one label. For withdrawn routes and for statics
I cannot find any code that sets BoS.

Being generous in what you receive is all very well, but I think there
should be some limits, or at least a mechanism for whining very loudly
about stuff which is just not right. In this case it looks as though
any future requirement to transmit 2 or more labels is a bit snookered
-- not that I have the faintest notion of how likely such a
requirement might be.

Thanks,

Chris


_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


sobo at arbor

May 7, 2012, 7:28 AM

Post #4 of 4 (482 views)
Permalink
Re: MPLS VPN in bgpd [In reply to]

On Sun, 6 May 2012 11:21 +0100, 'Chris Hall' <chris.hall.list [at] highwayman>
wrote:
> Renato Westphal wrote (on Sat 05-May-2012 at 22:10 +0100):
>> > 2012/5/5 Chris Hall<chris.hall.list [at] highwayman>:
> ...
>> > For solutions like MPLS VPN and 6[V]PE only one label is advertised
>> > for each prefix, so the BoS bit is always set. RFC3107 supports the
>> > advertisement of multiple labels for each prefix, but AFAIK this
>> > isn't used anywhere.
> I thought that might be the case. I haven't spotted anything in the
> RFCs (eg 4364 and 4659) that refer to RFC3107 to say that there will
> always only be one label.

There isn't. The RFCs make it possible to advertise multiple labels in one
route. However, as a practical matter there's not much point to that. Since
labels have only next-LSR significance, a multi-label advertisement using
SAFI 4 would either be adding unnecessary labels for LSPs that use the same
next LSR at multiple label depths, or would require that the advertising LSR
somehow have knowledge of inner labels that aren't in its own forwarding
tables. I would thus expect to see only one label in BGP NLRI even if many
labels are attached to the forwarded packet; the other labels would have to
come from other label distribution means. Note that there's nothing to
prevent labels from sources other than BGP from being added on top of the
BGP-learned label(s), and in fact RFC 3107 section 6 assumes that to be
happening in its example.

(Of course, now that I've said that only single labels are practical in
MP-BGP, I'm sure someone will point me to some multi-function MPLS solution
that uses stacked labels distributed together. :-) ).

> In practice, most implementations set the Bo bit to 1 when
> advertising an MPLS labeled route but ignore the Bo bit when
> receiving an MPLS labeled route (including Quagga for VP4 route
> reflection).

> Certainly Quagga takes no notice and simply assumes that all label
> stacks always contain one label. For withdrawn routes and for statics
> I cannot find any code that sets BoS.
>
> Being generous in what you receive is all very well, but I think there
> should be some limits, or at least a mechanism for whining very loudly
> about stuff which is just not right.

In my opinion, incorrect BoS isn't dangerous in BGP: The route contains the
NLRI length, so based on that you can safely read labels until you run out of
octets. (Contrast with BoS at the frame level, where a missing BoS means
you'd be switching IP header as part of the MPLS stack and bad things would
happen). The last label is going to be the bottom label. I don't think it's
possible to distribute labels via MP-BGP NLRI without including the bottom
label, since the use of an IP destination as the route index means that the
NLRI is necessarily the next layer of forwarding information; you can't
insert another label at bottom of stack from somewhere else.

I want Quagga to set BoS on the bottom label to make sure that other
less-permissive implementations don't barf when receiving a Quagga-advertised
route, but I expect that Quagga is probably doing ok to ignore it on received
routes.

> In this case it looks as though
> any future requirement to transmit 2 or more labels is a bit snookered
> -- not that I have the faintest notion of how likely such a
> requirement might be.

Per my blurb above, my opinion is that it is unlikely. I'd be happy with a
documentation note that Quagga BGP supports only one label in NLRI. It would
be great if multi-label support could be added without too much effort, but I
don't know that much effort should be invested unless you have an inner
passion about doing the most-right thing.
_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev

Quagga dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.