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

From: <[email-masked]>
Date: Thu, 2 Aug 2018 17:29:01 +0000

Hi Benjamin,

My understanding is that -14 address your DISCUSS comments.
- If so, could you clear you DISCUSS?
- If not, can you clarify what's missing?

Thanks,
Regards,
--Bruno

 > -----Original Message-----
 > From: Ahmed Bashandy [mailto:[email-masked]]
 > Sent: Monday, July 16, 2018 11:11 PM
 > To: Benjamin Kaduk; DECRAENE Bruno IMT/OLN
 > Cc: [email-masked]; Rob Shakir; [email-masked];
 > [email-masked]; [email-masked]; The IESG
 > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-ldp-interop-13:
 > (with DISCUSS and COMMENT)
 > 
 > 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, [email-masked] wrote:
 > >> Hi Benjamin,
 > >>
 > >> Thanks for the discussion.
 > >> Please see inline [Bruno2]
 > >>
 > >>> From: Benjamin Kaduk [mailto:[email-masked]]
 > >>   > Sent: Tuesday, July 10, 2018 12:53 AM
 > >>   > On Mon, Jul 09, 2018 at 12:36:20PM +0000, [email-masked] wrote:
 > >>   > > Hi Benjamin,
 > >>   > >
 > >>   > > Thanks for your comments.
 > >>   > > Please see inline another addition to Ahmed's answer. [Bruno]
 > >>   > >
 > >>   > > > From: Ahmed Bashandy [mailto:[email-masked]]
 > >>   > >  > 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.
 > >>

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Thu, 2 Aug 2018 17:35:06 +0000

Sorry Benjamin, please disregards.
I had missed your last week reply.

--Bruno

 > From: DECRAENE Bruno IMT/OLN
 > Sent: Thursday, August 02, 2018 7:29 PM
 > To: Benjamin Kaduk
 > [email-masked]; [email-masked]; The IESG; 'Ahmed Bashandy'
 > Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-ldp-interop-13:

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 29 Aug 2018 09:09:00 -0700

Ahmed: Ping!!

We’re really close…

Alvaro.

On July 26, 2018 at 4:27:25 PM, Benjamin Kaduk ([email-masked]) 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

> >> > > > > Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
> >> > > 1) As the SID attached to the prefix reachability is more
preferred than the SID advertised by the
> >> > > 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
> >> > > 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
> >> This form of advertisement is more centralized, on behalf of the node
advertising the IP reachability, which presents a different risk profile.
> >> 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.
> >> [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.
> >> > > > > As was mentioned in the secdir review, it would be good to
expand FEC and LFA on first
> >> > > > > specific and defined in
[I-D.ietf-isis-segment-routing-extensions],
> >> > > > #Ahmed: Corrected as suggested in the next version
________________________________________________________________________________

> >> > > This message and its attachments may contain confidential or
privileged information that may be
> >> > > 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

> >>
> >> 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,
> >> This message and its attachments may contain confidential or
privileged information that may be protected by law;