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,
[email protected] <mailto:[email protected]> wrote:
> >> Hi Benjamin,
> >>
> >> Thanks for the discussion.
> >> Please see inline [Bruno2]
> >>
> >>> From: Benjamin Kaduk [mailto:[email protected] <mailto:[email protected]>]
> >> > Sent: Tuesday, July 10, 2018 12:53 AM
> >> > On Mon, Jul 09, 2018 at 12:36:20PM +0000,
[email protected] <mailto:[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]
<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.
> >>
>
