Re: [Idr] [bess] draft-rosen-mpls-rfc3107bis

[<[e-mail]>]

Sorry for the late answer and for breaking the email thread. (my laptop hard drive failed during the IETF week).

Please see 2 comments inline [Bruno]

And as already expressed, I support the adoption of this document.



From: Eric C Rosen [mailto:[e-mail]]

Right now, we're arguing about which of the following two strategies is

more likely to cause a problem:



1. In the first strategy, 3107bis requires the S bit to be set when

there is a single label.  This will allow 3107bis to interoperate with

3107 implementations of "multiple labels", but it will not allow 3107bis

to interoperate with (buggy) 3107 implementations that send a single

label, but don't set the S bit.



2. In the second strategy, 3107bis assumes, in the absence of the

Capability, that there is only a single label, and doesn't bother to

check the S bit.  This will allow 3107bis to interoperate with (buggy)

implementations that send a single label but fail to set the S bit; it

will not allow 3107bis to interoperate with (non-buggy) 3107

implementations of multiple labels.



My argument is that the second strategy is better because it will be

less disruptive.  This is based on my belief that the "day 1" bugs do

exist, and that the "multiple labels" feature has yet to be deployed.



Your argument seems to be that the first strategy is better because (a)

it only causes disruption if the 3107 implementation has a bug, in which

case the bug can be fixed, and (b) if the second strategy is used, a

3107-compliant implementation of multiple labels will fail to

interoperate with a 3107bis-compliant implementation of multiple labels,

and both implementors will claim compliance.



[Bruno] Thank you for this good and fair summary.

I would add: (c) a 3107-compliant implementation of multiple labels sending one route with multiple labels to a 3107bis-compliant implementation of a single label, will trigger the shutdown of the BGP sessions and hence the removal of all labelled routes and most likely all routes from all AFI/SAFI sharing this BGP session. This is very disruptive. And both implementors will claim compliance.





There may be a third strategy: second strategy, plus when a BGP error is found when parsing the NLRI, search for the S bit in order to identify the IP prefix and treat it as withdraw. (rather than kill the BGP session)



To be on the extra safe side, I'd prefer the third strategy, on the basis that you never know what you can receive (cf the BGP attribute 99 incident, which nobody asked for/expected), plus the 3107 speaker sending multiple labels IS compliant.

If you don't think that this is feasible/reasonable, I'm fine with the second strategy.





I think your argument is reasonable, the question is really just which

strategy will cause less disruption.



[Bruno] In either case, it seems like the draft will need to document the issue and warn the network operator about it.



Do other members of the WGs have opinions about this?

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.