[mpls] draft-rosen-mpls-rfc3107bis-01

[<[e-mail]>]

Hi Eric,

Thanks for the draft.
I may have 2 comments.



1)      Interaction with BGP Graceful Restart


"   [RFC4724] ("Graceful Restart Mechanism for BGP") describes a

   procedure that allows routes learned over a given BGP session to be

   maintained when the session fails and then restarts.  This procedure

   requires the entire RIB to be transmitted when the session restarts.



   If the Multiple Labels Capability for a given AFI/SAFI had been

   exchanged on the failed session, but is not exchanged on the

   restarted session, then any prefixes advertised in that AFI/SAFI with

   multiple labels MUST be explicitly withdrawn.  Similarly, if the

   maximum label count, specified in the Capability for a given AFI/SAFI

   is reduced, an prefixes advertised with more labels than are valid

   for the current session MUST be explicitly withdrawn."


I don't think that the prefix "MUST be explicitly withdrawn." I'd rather say that the prefix "MUST not be re-advertised" (...with a number of labels exceeding the capability of the receiver).  IOW, the new BGP session simply needs to comply with the spec, nothing new. But I'd agree that to be on the safe side, explicitly spelling out this case may be appropriate. But we could also note that rfc6793 (AS 4-octet) has a related problem and does not talk about it.
Under the control of the IDR WG that is in copy.
BTW, IMHO this document looks heavier on the BGP side than on the MPLS side, especially with the new additions in -01 e.g. interaction with GR, Enhanced-GR which are not trivial, even for the IDR WG. Especially since 3107bis mostly fixes BGP related points (e.g. capability, different BGP encoding depending on the capability)



2)      Interop with RFC 3107


<
   If a BGP implementation, not conformant with the current document,
   encodes multiple labels in the NLRI but has not sent and received the
   "Multiple Labels" Capability, a BGP implementation that does conform
   with the current document will likely reset the BGP session."

I agree, but it's rather usual that a non-conformant implementation creates issues.
In this case, I think that it would be fair to highlight that an implementation compliant with RFC 3107 and supporting the advertisement of multiple labels, is _not_ compliant with rfc3107bis, hence not interoperable, hence will likely reset the BGP session.
I think it would be useful to have a section talking about the interoperability between RFC3107 and rfc3107bis, in particular for network operator to read and be able to perform the appropriate checks before deployments.

Thanks,
Regards,
--Bruno

_________________________________________________________________________________________________________________________

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.