Hi Eric, Thanks for the draft. I read it and it looks good and useful to me. I have mostly 1 comment:
> - RFC 3107 provides an encoding that allows BGP to assign multiple labels Upfront, the current issue is that implementations, which claim compliance with RFC 3107, are just non-compliant. So the draft is proposing to change the specification to make such implementations compliant, while another option would be to fix implementation (to be compliant with the RFC they claim to support). I don't really expect that we'll agree on it, but I had to make the comment nonetheless. ;-) That being said, The proposed capability is a good idea to improve interoperability. Thanks. The main issue I have, is that this draft is not backward compatible with RFC 3107 (as a RFC 3107 speaker will never notice that its peer has not send the new capability, and may still send multiple labels). Plus in case of error due to this incompatibility, the error handling behavior is likely to be "BGP session shutdown" (as the NLRI "cannot" be correctly parsed) which is disruptive. Plus the implementation A not supporting multiple labels, will claim that the implementation B supporting multiple labels is "not compliant" with rfc3107bis, while I would rather argue that this is implementation A which is not compliant with RFC 3107. I'd propose one change: - Capability means: I don't support receiving multiple labels, hence you SHOULD not send that to me. - Even if the capability is not advertised by both peers, and hence a single label is expected, all implementations MUST check that the "S" bit (in this first label) is set to 1. If the bit is cleared, the Prefix MUST be identified as per RFC 3107/this document and treated as withdraw as defined in RFC 7606. This means more work for rfc3107bis speakers, but we can't ask existing speakers to do the job. Especially since they were compliant with RFC 3107. Alternatively, the capability could be extended to carry two meanings: I support rfc3107bis, I support multiple labels. This would allow a rfc3107bis speaker to refuse the BGP connection with RFC 3107 speakers. But this is much less convenient. Plus very minor comments - From an editorial standpoint, I'd personally favor removing §2.2 and saying in 2.3(or elsewhere) that if the capability is not exchanged, a single label may be encoded. (IMHO duplicating the text is less easy to read and more error prone. And I believe this would be enough to address your point). - In Figure 2 (§2.3), 2 labels are indicated. Do you think there is a need to indicate which one is the first (Label 1) and which one is the k th (Label k). Indeed, the order of the labels is significant when the router will need to push them in the dataplane. Or a sentence could be added to make this explicit. - In §4, there is a possible case which is not described: S1 receives L11, L12,... L1k S1 sends L21, L12,... L1k S1 programs in the data plane: L21 swap L11 Compared to sending a single label (L21), S1 avoids having to push k labels in its dataplane, which it may be incapable of. - In §4 "While this may be useful in certain scenarios, it may provide unintended results in other scenarios." I fail to see when this can be useful as N1 or downstream LSR will receive packets with labels there are not aware of (L22...L2k). Out of curiosity, I'm be curious to know the useful scenario that you have in mind. - in §5 " It is possible that a BGP speaker will receive both a SAFI-1 route for prefix P and a SAFI-4 route for prefix P. The significance of this is a matter of local policy." For 6PE (rfc4798), may be this should not be a local policy but be specified as a priori SAFI-1 and SAFI-4 prefix should be comparable. Ideally rfc4798 could have specified this but I haven't check if it's done. Alternatively §5 could reference this case. (Same point for propagation between SAFI-1 and SAFI-4) Thanks again for the draft, Regards, -- Bruno > From: BESS [mailto:[email protected]] On Behalf Of Eric C Rosen > Subject: [bess] draft-rosen-idr-rfc3107bis-00 > > Folks, > > Pardon the cross-post, but I think this may be of interest to all three > of the IDR, MPLS, and BESS WGs. > > I've posted draft-rosen-idr-rfc3107bis-00 ("Using BGP to Bind MPLS > Labels to Address Prefixes"), which is intended of course to obsolete > RFC 3107 ("Carrying Label Information in BGP"). (While I put "idr" in > the name of the draft, it's not completely obvious which WG should own > this draft (assuming it progresses)). > > The purpose of this draft is the following: > > - It fixes a number of errors in RFC3107. It attempts to do so in a way > that is compatible with existing implementations. > > - It removes the material about "Advertising Multiple Routes to a > Destination". This is a feature that was never implemented as > specified, and the text about it just causes confusion. The > functionality that this feature was intended to provide can now be > better provided by using add-paths; this is discussed in the draft. > > - It is explicit about its applicability to SAFI 128 as well as to SAFI 4. > > - It clarifies the procedures for withdrawing and replacing label bindings. > > - It discusses the relationship between SAFI-1 routes and SAFI-4 routes, > which is very unclear in RFC3107. Different implementations have > treated the SAFI-1/SAFI-4 interactions differently, and the draft > discusses these differences. However, as the draft is not intended to > favor any one implementation over another, it can't do much more than > point out some of the differences among implementations. > > - RFC 3107 provides an encoding that allows BGP to assign multiple > labels (i.e., a label stack) to a given prefix. However, it provides no > semantics for this, and this feature has been only rarely implemented. > In fact, it is believed that some implementations will not parse the > Updates correctly if they encode multiple labels in the NLRI. Therefore > the draft only allows a label stack to be assigned to a given prefix if > a new Capability has been exchanged. It also discusses the semantics of > assigning a label stack, and gives some examples of how this might be used. > > I hope that those of you who are interested in this topic will provide > your comments. I've tried to make the draft compatible with existing > implementations and deployments, so if anyone sees anything that > negatively impacts an existing implementation, please comment on that. > > I also removed most of the text that explains why it is a good idea to > use BGP to distribute label bindings. That text was important in the > '90s, but now seems rather out of date. However, I would welcome > comments on whether an updated "motivation/positioning" section should > be added. > > Thanks, > > Eric > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess _________________________________________________________________________________________________________________________ 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. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
