sobo at arbor
May 7, 2012, 7:28 AM
Post #4 of 4
(271 views)
Permalink
|
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
|
