Hi Bruno, Thanks for the additional clarifications in the suggested text -- it looks good to me, so you and Ahmed should please go ahead with it (once submissions open up again).
-Benjamin On Tue, Jul 10, 2018 at 12:49:28PM +0000, [email protected] wrote: > Hi Benjamin, > > Thanks for the discussion. > Please see inline [Bruno2] > > > From: Benjamin Kaduk [mailto:[email protected]] > > Sent: Tuesday, July 10, 2018 12:53 AM > > > > On Mon, Jul 09, 2018 at 12:36:20PM +0000, [email protected] wrote: > > > Hi Benjamin, > > > > > > Thanks for your comments. > > > Please see inline another addition to Ahmed's answer. [Bruno] > > > > > > > From: Ahmed Bashandy [mailto:[email protected]] > > > > Sent: Monday, July 09, 2018 2:30 AM > > > > > > > > Hi > > > > Thanks for the review > > > > > > > > See reply to the comment at #Ahmed > > > > > > > > Ahmed > > > > > > > > > > > > On 6/20/18 9:40 AM, Benjamin Kaduk wrote: > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-spring-segment-routing-ldp-interop-13: Discuss > > > > > > > > > > When responding, please keep the subject line intact and reply to > all > > > > > email addresses included in the To and CC lines. (Feel free to cut > this > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > DISCUSS: > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > I may be missing something, but I don't see anything that says > whether the > > > > > preference field introduced in Section 3.2.3 uses larger values or > smaller > > > > > values for more-preferred SRMSes. > > > > #Ahmed: > > > > If I understand this statement correctly, the concern is about which > > > > label(s) get assigned to which prefix(es). This concern is addressed > as > > > > follows > > > > > > > > From the MPLS architecture point of view, there is nothing wrong in > > > > having multiple labels for the same prefix. Segment routing in general > > > > and this document in particular did not introduce this behavior nor > did > > > > they prohibit/restrict/relax it. For example, an implementation that > > > > allows the operator to locally assign multiple local labels to the > same > > > > prefix may continue to apply this behavior whether the platform > supports > > > > segment routing or not, in which case it is up to the implementation > > > > and/or the configuration affecting the MPLS forwarding plane to > specify > > > > how to behave when multiple labels are assigned to the same prefix. > Such > > > > behavior is a general MPLS behavior that outside the scope of and is > not > > > > modified by segment routing. > > > > > > > > However the opposite, where the same label gets assigned to multiple > > > > prefixes resulting in label collision is problematic. This document > > > > prohibits label collision resulting from the use of SRMS (which is > > > > introduced by this document) in the first bullet starting at the 3rd > > > > line of page 12: > > > > "- If there is an incoming label collision as specified in > > > > [I-D.ietf-spring-segment-routing-mpls] , apply the steps > specified > > > > in [I-D.ietf-spring-segment-routing-mpls] to resolve the > > > > collision."" > > > > > > > > > > > > > > > > > > > The introduction of the SRMS is also introducing a new way for a > protocol > > > > > participant to make claims about route prefixes directed at "third > parties" > > > > > (non-MS, non-MC routers). While routing protocols in general do > require high > > > > > levels of trust in all participants in order for proper routing to > occur, this > > > > > addition seems to create a "first among equals" situation that > could be called > > > > > out more clearly in the security considerations. (I do appreciate > that the > > > > > requirement for preferring SIDs advertised in prefix reachability > > > > > advertisements over those advertised in mapping server > advertisements does help > > > > > alleviate some of the risk.) > > > > > > [Bruno] > > > 1) As the SID attached to the prefix reachability is more preferred than > the SID advertised by the > > SRMS, I would kind of argue that the SRMS is more "last among equals" :-) > > > 2) I agree that routing protocols, especially Link State Internal > Routing Protocols, do require high > > levels of trusts among participants. In particular, please note that any > node can already advertise > > any IP prefix (with any attached SID), and with any metric/cost, hence > attracting the traffic. In this > > regards, I don't really see an increased risk in IGP routing. > > > > I don't really see an increased risk per se, either (since all routers can > > break routing in all sorts of ways), but I do see a new mechanism by which > > certain routers can cause routing breakage. So I was thinking "first among > > equals" in terms of "more ways to break things", not "can break things with > > a larger magnitude of breakage". You are right that the preference order > > that Ahmed described does mean that this new "mechanism for breakage" is > > only applicable when there are no explicit prefix-SID advertisements > > received via the IGP. So in that sense this new mechanism for breakage is > > "last among equals", as you say, because it can only take effect if the IGP > > leaves room for it. > > [Bruno2] Ack; I believe we are in sync. > > > > 3) I agree that SRMS allows for a "centralized" SID advertisement. I > personally don't feel that this > > is more risky than a "centralized" BGP Route Reflector. However, I'm not > against raising this in the > > security consideration section. > > > Please see below a proposed text. Please comment/propose text as > required. > > > > > > OLD: > > > This document introduces another form of label binding > > > advertisements. The security associated with these advertisement is > > > part of the security applied to routing protocols such as IS-IS > > > [RFC5304] and OSPF [RFC5709] which both optionally make use of > > > cryptographic authentication mechanisms. This document also > > > specifies a mechanism by which the ill effects of advertising > > > conflicting label bindings can be mitigated. > > > > > > NEW: > > > This document introduces another form of label binding > > > advertisements. The security associated with these advertisements is > > > part of the security applied to routing protocols such as IS-IS > > > [RFC5304] and OSPF [RFC5709] which both optionally make use of > > > cryptographic authentication mechanisms. > > > This form of advertisement is more centralized, on behalf of the node > advertising the IP > > reachability. > > > This document also > > > specifies a mechanism by which the ill effects of advertising > > > conflicting label bindings can be mitigated. In particular, > advertisements from the node > > advertsising the IP reachability is more preference than the centralized > one. > > > > I think that's enough to resolve my DISCUSS point. I would prefer if there > > was a little bit more text, such as "more centralized, on behalf of the > > node advertising the IP reachability, which presents a different risk > > profile than existing mechanisms for distributing label bindings", but your > > version does cover the key point. > > [Bruno2] ok. Proposed NEW2: > > This document introduces another form of label binding > advertisements. The security associated with these advertisements is > part of the security applied to routing protocols such as IS-IS > [RFC5304] and OSPF [RFC5709] which both optionally make use of > cryptographic authentication mechanisms. > This form of advertisement is more centralized, on behalf of the node > advertising the IP reachability, which presents a different risk profile. > This document also > specifies a mechanism by which the ill effects of advertising > conflicting label bindings can be mitigated. In particular, advertisements > from the node advertising the IP reachability is more preferred than the > centralized one. > > > > In short, I used your proposed text but removed " than existing mechanisms > for distributing label bindings" as this could be read as "LDP". We could add > more text to distinguish, but IMO the current text seems fine. > > > > (And to be clear, I am not trying to say > > that the centralized risk is better or worse in all cases; it's just > > different, so we should call that out to the reader and inform their > decision > > making.) > > [Bruno2] In sync. I agree with you that we should call that out to the reader > and inform their decision making. Thanks for bringing the comment. > I'll work with Ahmed, to have the draft reflect this, as he has the pen. > > Thanks, > Bruno > > > > Thanks, > > > > Benjamin > > > > > > > > Thanks, > > > --Bruno > > > > > > > #Ahmed: > > > > If I understand your comment, the concern is about > > > > "first-come-first-serve" behavior. I believe this concern is addressed > > > > as follows > > > > (1) The sentence starting at the fourth line of the second paragraph > in > > > > page 10 says: > > > > For a given prefix, if an MC receives an SR mapping advertisement > > > > from a mapping server and also has received a prefix-SID > > > > advertisement for that same prefix in a prefix reachability > > > > advertisement, then the MC MUST prefer the SID advertised in the > > > > prefix reachability advertisement over the mapping server > > > > advertisement i.e., the mapping server advertisment MUST be > ignored > > > > for that prefix. > > > > > > > > (2) The last bullet at the bottom of page 11 says: > > > > - For any prefix for which it did not receive a prefix-SID > > > > advertisement, the MCC applies the SRMS mapping advertisments > with > > > > the highest preference. > > > > > > > > (3) The first bullet near the top pf page 12 says: > > > > - If there is an incoming label collision as specified in > > > > [I-D.ietf-spring-segment-routing-mpls] , apply the steps > specified > > > > in [I-D.ietf-spring-segment-routing-mpls] to resolve the > > > > collision. > > > > > > > > So for the same set of received advertisements (SRMS advertisements, > > > > prefix-SID advertisements, or combination of both), the same set of > > > > labels will be assigned to the same prefix. As mentioned in my > previous > > > > comments, if multiple labels get assigned to the same prefix, the > > > > behavior is not related to segment routing > > > > > > > > Regarding placing a comment in the security section, IMO a > specification > > > > of which advertisement(s) to use when receiving multiple (conflicting > or > > > > non-conflicting) advertisements has nothing to do with security. It is > > > > an externally visible protocol(s) behavior that should be specified in > > > > the sections covering the protocol(s) themselves rather than security > > > > consideration of the protocol(s). > > > > > > > > But if you still think there is a need to mention something in the > > > > security section, a suggestion from your side will be greatly > appreciated . > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > COMMENT: > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > I support Alissa's suggestion about the text covering cryptographic > authentication. > > > > #Ahmed: I modified the statement as Alissa suggested in version 14 > that > > > > will be published in the next 1-2 days > > > > > > > > > > "[100,300]" and "(100,200)" are each used as an example SRGB. In > > > > > some contexts the round versus square brackets indicate a > > > > > distinction between "closed" (includes endpoints) and "open" (does > > > > > not include endpoints) intervals. If there's no need to make such a > > > > > distinction, I suggest standardizing one one format. > > > > #Ahmed: I changed both of them to use [] in version because we mean > > > > inclusive > > > > > > > > > > As was mentioned in the secdir review, it would be good to expand > FEC and LFA on first > > usage. > > > > #Ahmed: Corrected in version 14 that will be published in the next > 1-2 days > > > > > > > > > > Section 1 > > > > > > > > > > Section 2 describes the co-existence of SR with other MPLS > Control > > > > > Plane. [...] > > > > > > > > > > nit: "other MPLS Control Plane" seems to be an incomplete compound > noun > > > > > -- is it other control plane technologies that are being considered? > > > > #Ahmed: I added "protocols" in version 14 to clarify that > > > > > > > > > > Section 2 > > > > > > > > > > Note that this static label allocation capability of the label > > > > > manager exists for many years across several vendors and hence > is not > > > > > new. Furthermore, note that the label-manager ability to > statically > > > > > allocate a range of labels to a specific application is not new > > > > > either. [...] > > > > > > > > > > nits: "has existed", "label-manager's ability". > > > > #Ahmed: Corrected (thanks a lot) > > > > > > > > > > Section 2.1 > > > > > > > > > > MPLS2MPLS refers the forwarding behavior where a router > receives an > > > > > labeled packet and switches it out as a labeled packet. Several > > > > > > > > > > nit: "refers to", "a labeled packet" > > > > #Ahmed: Corrected > > > > > > > > > > Section 3.2 > > > > > > > > > > This section defines the Segment Routing Mapping Server (SRMS). > The > > > > > SRMS is a IGP node advertising mapping between Segment > Identifiers > > > > > (SID) and prefixes advertised by other IGP nodes. The SRMS > uses a > > > > > dedicated IGP extension (IS-IS, OSPF and OSPFv3) which is > protocol > > > > > specific and defined in > [I-D.ietf-isis-segment-routing-extensions], > > > > > [I-D.ietf-ospf-segment-routing-extensions], and > > > > > [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. > > > > > > > > > > nit: Perhaps "IS-IS, OSPFv2, and OSPFv3 are currently supported" is > a > > > > > better parenthetical? > > > > #Ahmed: Corrected in the next version > > > > > > > > > > The example diagram depicted in Figure 3 assumes that the > operator > > > > > configures P5 to act as a Segment Routing Mapping Server (SRMS) > and > > > > > advertises the following mappings: (P7, 107), (P8, 108), (PE3, > 103) > > > > > and (PE4, 104). > > > > > > > > > > nit: I think this is Figure 2. > > > > #Ahmed: Corrected in the next version > > > > > > > > > > Section 3.2.1 > > > > > > > > > > [...] Examples > > > > > of explicit prefix-SID advertisment are the prefix-SID sub-TLVs > > > > > defined in ([I-D.ietf-isis-segment-routing-extensions], > > > > > [I-D.ietf-ospf-segment-routing-extensions], and > > > > > [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). > > > > > > > > > > Would draft-ietf-idr-bgp-prefix-sid (also on this week's telechat) > > > > > be appropriate for inclusion in this list? > > > > > > > > > > for that prefix. Hence assigning a prefix-SID to a prefix > using the > > > > > SRMS functionality does not preclude assigning the same or > different > > > > > prefix-SID(s) to the same prefix using explict prefix-SID > > > > > advertisement such as the aforementioned prefix-SID sub-TLV. > > > > #Ahmed: The SRMS functionality is specific to IGPs as mentioned in the > > > > second sentence of the second paragraph in Section 3.2 > > > > > > > > > > nit: I think the aforementioned things were a list, so "sub-TLVs" > plural > > > > > would be appropriate. > > > > > > > > > > Including the name for IS-IS TLV 135 might be helpful for the > > > > > reader. > > > > > > > > > #Ahmed: Corrected as suggested in the next version > > > > > > > > > > > > ________________________________________________________________________________ > > _________________________________________ > > > > > > 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. > > > > > _________________________________________________________________________________________________________________________ > > 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. > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
