Hi Bruno, Ahmed,
On Mon, Jul 09, 2018 at 11:57:05AM +0000, [email protected] wrote:
> Hi Benjamin,
>
> Thanks for your comments.
> Please see inline 1 addition to Ahmed's answer. [Bruno]
>
> > -----Original Message-----
> > From: Ahmed Bashandy [mailto:[email protected]]
> > Sent: Monday, July 09, 2018 2:30 AM
> > To: Benjamin Kaduk; The IESG
> > Cc: [email protected]; Rob Shakir;
> [email protected];
> > [email protected]; [email protected]
> > Subject: Re: Benjamin Kaduk's Discuss on
> draft-ietf-spring-segment-routing-ldp-interop-13: (with
> > DISCUSS and COMMENT)
> >
> > 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.
>
> [Bruno] section 3.2.3 says:
>
> "A MCC on a node receiving one or more SRMS mapping advertisements
> applies them as follows
>
> - For any prefix for which it did not receive a prefix-SID
> advertisement, the MCC applies the SRMS mapping advertisments with
> the highest preference."
>
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-13#page-11
>
> If you believe "highest preference" is not clear enough, could you propose an
> alternate wording?
I was thinking something like:
OLD:
1 - 255 Preference value
NEW:
1 - 255 Preference value (255 is most preferred)
Since "highest preference" can be interpreted either as "the preference
value that is numerically highest/largest" or "the most-preferred value",
and the latter can be (and is, in various protocols) either the highest
numerical value or the lowest numerical value.
>
> > #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.""
Thanks for the extra explanation, but per the above this is the very simple
"is 1 or 255 more preferred?".
> > >
> > >
> > > 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.)
> > #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 .
I see Bruno sent another mail on this one, so I will reply there.
(It seems like my "first among equals" led you down the wrong path; sorry
about that. I meant it more like "all routers can cause severe disruption,
but the SRMS has more ways in which it can do so than other routers".)
> > >
> > >
> > > ----------------------------------------------------------------------
> > > 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
I wasn't sure whether the deployments that use BGP as effectively an IGP
would also be applicable, but you would know better than I do.
-Benjamin
> > > 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.
>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
