Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-ldp-interop-13: (with DISCUSS and COMMENT)

[Ahmed Bashandy <[e-mail]>]

Thanks a for the reminder

I uploaded version 15 to address Benjamin's comments


Ahmed




On 8/29/18 9:09 AM, Alvaro Retana wrote:
> Ahmed: Ping!!
>
> We’re really close…
>
> Alvaro.
>
> On July 26, 2018 at 4:27:25 PM, Benjamin Kaduk ([e-mail] 
> <mailto:[e-mail]>) wrote:
>
>> Hi Ahmed,
>>
>> Thanks for posting the update (and sorry for only getting to it now).
>>
>> The two specific points I raised in my DISCUSS ballot are properly
>> addressed, but before I go clear that I was hoping you could help me
>> remember why the following text was removed when going from -13 to -14:
>>
>> [...] Because this document recognizes that
>> miscofiguration and/or programming may result in false or conflicting
>> label binding advertisements, thereby compromising traffic
>> forwarding, the document recommends strict configuration/
>> programmability control as well as montoring the SID advertised and
>> log/error messages by the operator to avoid or at least significantly
>> minimize the possibility of such risk.
>>
>> I couldn't find anything in my email history that helped jog my memory.
>>
>> Thanks,
>>
>> Benjamin
>>
>> On Mon, Jul 16, 2018 at 02:10:37PM -0700, Ahmed Bashandy wrote:
>> > Hi,
>> >
>> > I just posted version 14
>> > 
>> https://www.ietf.org/id/draft-ietf-spring-segment-routing-ldp-interop-14.txt 
>>
>> >
>> > Thanks
>> >
>> > Ahmed
>> >
>> >
>> >
>> > On 7/10/18 7:11 AM, Benjamin Kaduk wrote:
>> > > 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, 
>> [e-mail] <mailto:[e-mail]> wrote:
>> > >> Hi Benjamin,
>> > >>
>> > >> Thanks for the discussion.
>> > >> Please see inline [Bruno2]
>> > >>
>> > >>> From: Benjamin Kaduk [mailto:[e-mail] <mailto:[e-mail]>]
>> > >> > Sent: Tuesday, July 10, 2018 12:53 AM
>> > >> > On Mon, Jul 09, 2018 at 12:36:20PM +0000, 
>> [e-mail] <mailto:[e-mail]> wrote:
>> > >> > > Hi Benjamin,
>> > >> > >
>> > >> > > Thanks for your comments.
>> > >> > > Please see inline another addition to Ahmed's answer. [Bruno]
>> > >> > >
>> > >> > > > From: Ahmed Bashandy [mailto:[e-mail] 
>> <mailto:[e-mail]>]
>> > >> > > > 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.
>> > >>
>> >