Skip to main content

Segment Routing MPLS Interworking with LDP
draft-ietf-spring-segment-routing-ldp-interop-15

Revision differences

Document history

Date Rev. By Action
2019-11-18
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-11-05
15 (System) RFC Editor state changed to AUTH48 from REF
2019-11-05
15 (System) RFC Editor state changed to REF from AUTH48-DONE
2019-10-24
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-09-02
15 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-08-20
15 (System) RFC Editor state changed to RFC-EDITOR from REF
2019-07-22
15 (System) RFC Editor state changed to REF from EDIT
2019-05-28
15 (System) RFC Editor state changed to EDIT from MISSREF
2018-09-07
15 (System) IANA Action state changed to No IANA Actions from In Progress
2018-09-06
15 (System) RFC Editor state changed to MISSREF
2018-09-06
15 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-09-06
15 (System) Announcement was received by RFC Editor
2018-09-06
15 (System) IANA Action state changed to In Progress
2018-09-06
15 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-09-06
15 Amy Vezza IESG has approved the document
2018-09-06
15 Amy Vezza Closed "Approve" ballot
2018-09-06
15 Alvaro Retana IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2018-09-06
15 Alvaro Retana Ballot approval text was generated
2018-09-02
15 Benjamin Kaduk
[Ballot comment]
(Clearing DISCUSS, since the question about removed text has been resolved as
an editing error and the text will be restored.  Original COMMENT …
[Ballot comment]
(Clearing DISCUSS, since the question about removed text has been resolved as
an editing error and the text will be restored.  Original COMMENT preserved below.)

I support Alissa's suggestion about the text covering cryptographic authentication.

"[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.

As was mentioned in the secdir review, it would be good to expand FEC and LFA on first usage.

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?

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".

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"

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?

  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.

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.

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.
2018-09-02
15 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2018-09-02
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-09-02
15 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-ldp-interop-15.txt
2018-09-02
15 (System) New version approved
2018-09-02
15 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Bruno Decraene , Stefano Previdi , Ahmed Bashandy , Stephane Litkowski
2018-09-02
15 Ahmed Bashandy Uploaded new revision
2018-08-30
14 Benjamin Kaduk
[Ballot discuss]
addressed, but before I go clear that I was hoping you could help me               
remember why …
[Ballot discuss]
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.
2018-08-30
14 Benjamin Kaduk Ballot discuss text updated for Benjamin Kaduk
2018-08-29
14 Alvaro Retana IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2018-07-16
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-07-16
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-07-16
14 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-ldp-interop-14.txt
2018-07-16
14 (System) New version approved
2018-07-16
14 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Bruno Decraene , Stefano Previdi , Ahmed Bashandy , Stephane Litkowski
2018-07-16
14 Ahmed Bashandy Uploaded new revision
2018-06-25
13 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2018-06-21
13 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-06-21
13 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-06-21
13 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-06-21
13 Susan Hares Assignment of request for Last Call review by OPSDIR to Susan Hares was rejected
2018-06-20
13 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-06-20
13 Warren Kumari [Ballot comment]
NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem (and have no cycles)" sense.
2018-06-20
13 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-06-20
13 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-06-20
13 Benjamin Kaduk
[Ballot 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 …
[Ballot 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.

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.)
2018-06-20
13 Benjamin Kaduk
[Ballot comment]
I support Alissa's suggestion about the text covering cryptographic authentication.

"[100,300]" and "(100,200)" are each used as an example SRGB.  In
some contexts …
[Ballot comment]
I support Alissa's suggestion about the text covering cryptographic authentication.

"[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.

As was mentioned in the secdir review, it would be good to expand FEC and LFA on first usage.

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?

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".

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"

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?

  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.

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.

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.
2018-06-20
13 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2018-06-20
13 Alissa Cooper
[Ballot comment]
As a non-specialist I found the organization of 3.2, 3.2.1, and 3.2.2 a little hard to follow, as it seemed to me like …
[Ballot comment]
As a non-specialist I found the organization of 3.2, 3.2.1, and 3.2.2 a little hard to follow, as it seemed to me like the SRMS section should have been introduced first before the discussion of the SR to LDP flow and behavior.

Section 7 says:

"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 make use of cryptographic
  authentication mechanisms."

Unless the use of the cited cryptographic authentication mechanisms is required when using these label advertisements, I would suggest saying "which both optionally make use of." Otherwise this seems a little misleading.
2018-06-20
13 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-06-19
13 Adam Roach
[Ballot comment]
I might have missed something; and note that this is offered as an
observation, and is explicitly not a blocking comment: this document …
[Ballot comment]
I might have missed something; and note that this is offered as an
observation, and is explicitly not a blocking comment: this document appears
to offer operational advice for co-existence of LDP and SR, and for
transitioning from LDP to SR in an incremental fashion. I don't see any
protocol specification in here. Based on these observations, it is my opinion
that the contents of this document seem better suited for publication as a BCP
rather than a standards track document. For example: if one were to eventually
progress this document to an Internet Standard, what "implementations" would
one use to evaluate the criteria in section 2.2 of RFC 6140? If we can't
answer that question, I think it's a pretty clear indication that the document
isn't standards track.

---------------------------------------------------------------------------

General:

This document uses IPv4 addresses for example purposes in many places. Please
convert these to IPv6 or a mix of IPv4 and IPv6 addresses. See
https://www.iab.org/documents/correspondence-reports-documents/2016-2/iab-statement-on-ipv6/
for additional information.

---------------------------------------------------------------------------

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

This document uses non-normative, lowercased versions of these words in several
locations. Please update this section to match the boilerplate in RFC 8174.

---------------------------------------------------------------------------

§3.1.1:

>  A SR node having LDP neighbors MUST create LDP bindings for each
>  Prefix-SID learned in the SR domain by treating SR learned labels as
>  if they were learned through an LDP neighbot.

Nit: "...neighbor."
2018-06-19
13 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-06-19
13 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2018-06-19
13 Deborah Brungard [Ballot comment]
Agree with Mirja, seems more appropriate as an informational document (e.g. RFC5145).
2018-06-19
13 Deborah Brungard Ballot comment text updated for Deborah Brungard
2018-06-19
13 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-06-18
13 Ben Campbell
[Ballot comment]
Please consider using the RFC 8174 boilerplate for the requirements language section. There are a number of lower case instances of 2119 keywords. …
[Ballot comment]
Please consider using the RFC 8174 boilerplate for the requirements language section. There are a number of lower case instances of 2119 keywords.

§1, 2nd paragraph: Missing article before " Segment Routing control plane..."
2018-06-18
13 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-06-18
13 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-06-18
13 Mirja Kühlewind
[Ballot comment]
I'm not sure if informational status wouldn't be more applicable to this doc but I also fine with Proposed Standard.

nits:
1) In …
[Ballot comment]
I'm not sure if informational status wouldn't be more applicable to this doc but I also fine with Proposed Standard.

nits:
1) In sec 3.1.1 I assume "neighbor" and not "neighbot" is meant...

2) In sec 3.2 this could probably be an upper case MAY:
"Multiple SRMSs may be present in the same network (for redundancy)."
2018-06-18
13 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-06-13
13 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-ldp-interop-13.txt
2018-06-13
13 (System) New version approved
2018-06-13
13 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Bruno Decraene , Stefano Previdi , Ahmed Bashandy , Stephane Litkowski
2018-06-13
13 Ahmed Bashandy Uploaded new revision
2018-06-07
12 Joel Halpern Request for Telechat review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list.
2018-06-07
12 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2018-06-07
12 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2018-06-05
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-06-05
12 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-ldp-interop-12.txt
2018-06-05
12 (System) New version approved
2018-06-05
12 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Bruno Decraene , Stefano Previdi , Ahmed Bashandy , Stephane Litkowski
2018-06-05
12 Ahmed Bashandy Uploaded new revision
2018-05-27
11 Min Ye Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Tomonori Takeda.
2018-05-24
11 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for Writeup
2018-05-24
11 Cindy Morgan Placed on agenda for telechat - 2018-06-21
2018-05-24
11 Alvaro Retana Ballot has been issued
2018-05-24
11 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2018-05-24
11 Alvaro Retana Created "Approve" ballot
2018-05-24
11 Alvaro Retana Ballot writeup was changed
2018-05-24
11 Alvaro Retana Changed consensus to Yes from Unknown
2018-05-24
11 Takeshi Takahashi Request for Last Call review by SECDIR Completed: Ready. Reviewer: Takeshi Takahashi. Sent review to list.
2018-05-24
11 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-05-18
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2018-05-18
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2018-05-17
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Takeshi Takahashi
2018-05-17
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Takeshi Takahashi
2018-05-15
11 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-05-15
11 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-spring-segment-routing-ldp-interop-11, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-spring-segment-routing-ldp-interop-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-05-14
11 Min Ye Request for Last Call review by RTGDIR is assigned to Tomonori Takeda
2018-05-14
11 Min Ye Request for Last Call review by RTGDIR is assigned to Tomonori Takeda
2018-05-14
11 Joel Halpern Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Joel Halpern. Sent review to list.
2018-05-13
11 Min Ye Request for Last Call review by RTGDIR is assigned to David Sinicrope
2018-05-13
11 Min Ye Request for Last Call review by RTGDIR is assigned to David Sinicrope
2018-05-11
11 Alvaro Retana Requested Last Call review by RTGDIR
2018-05-10
11 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2018-05-10
11 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2018-05-10
11 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-05-10
11 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-05-24):

From: The IESG
To: IETF-Announce
CC: spring@ietf.org, spring-chairs@ietf.org, aretana.ietf@gmail.com, robjs@google.com, draft-ietf-spring-segment-routing-ldp-interop@ietf.org …
The following Last Call announcement was sent out (ends 2018-05-24):

From: The IESG
To: IETF-Announce
CC: spring@ietf.org, spring-chairs@ietf.org, aretana.ietf@gmail.com, robjs@google.com, draft-ietf-spring-segment-routing-ldp-interop@ietf.org, Rob Shakir
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Segment Routing interworking with LDP) to Proposed Standard


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'Segment Routing
interworking with LDP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-05-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  A Segment Routing (SR) node steers a packet through a controlled set
  of instructions, called segments, by prepending the packet with an SR
  header.  A segment can represent any instruction, topological or
  service-based.  SR allows to enforce a flow through any topological
  path while maintaining per-flow state only at the ingress node to the
  SR domain.

  The Segment Routing architecture can be directly applied to the MPLS
  data plane with no change in the forwarding plane.  This document
  describes how Segment Routing operates in a network where LDP is
  deployed and in the case where SR-capable and non-SR-capable nodes
  coexist.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2456/
  https://datatracker.ietf.org/ipr/2277/





2018-05-10
11 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-05-10
11 Alvaro Retana Last call was requested
2018-05-10
11 Alvaro Retana Ballot approval text was generated
2018-05-10
11 Alvaro Retana Ballot writeup was generated
2018-05-10
11 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2018-05-10
11 Alvaro Retana Last call announcement was generated
2018-04-11
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-04-11
11 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-ldp-interop-11.txt
2018-04-11
11 (System) New version approved
2018-04-11
11 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Bruno Decraene , Stefano Previdi , Ahmed Bashandy , Stephane Litkowski
2018-04-11
11 Ahmed Bashandy Uploaded new revision
2018-04-02
10 Alvaro Retana The change from -09 to -10 was just a refresh (no change!).  I'm still waiting for a reply to my AD review.
2018-04-02
10 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2018-04-02
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-04-02
10 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-ldp-interop-10.txt
2018-04-02
10 (System) New version approved
2018-04-02
10 (System) Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Bruno Decraene , spring-chairs@ietf.org, Clarence Filsfils , Stefano Previdi , Stephane Litkowski
2018-04-02
10 Ahmed Bashandy Uploaded new revision
2018-03-20
09 Bruno Decraene Notification list changed to aretana.ietf@gmail.com, Rob Shakir <robjs@google.com> from aretana.ietf@gmail.com
2018-03-20
09 Bruno Decraene Document shepherd changed to Rob Shakir
2017-12-20
09 Alvaro Retana
=== AD Review of draft-ietf-spring-segment-routing-ldp-interop-09 ===
https://mailarchive.ietf.org/arch/msg/spring/wCtx1K0O11zIlbqsE-1nbqahXC8/?qid=88ba5ff46316989f187930e45e0b0e4d

Dear authors:

I just finished reading this document.  I have some Major comments below
that I would like …
=== AD Review of draft-ietf-spring-segment-routing-ldp-interop-09 ===
https://mailarchive.ietf.org/arch/msg/spring/wCtx1K0O11zIlbqsE-1nbqahXC8/?qid=88ba5ff46316989f187930e45e0b0e4d

Dear authors:

I just finished reading this document.  I have some Major comments below
that I would like to see addressed before starting the IETF LC.

Thanks for your work on this document.

Alvaro.


Major:

M1. From Section 2: "An MCC, operating at node N, MUST ensure that the
incoming label it installs in the MPLS data plane of Node N has been
uniquely allocated to himself.”  I’m sure this sentence is not meant as a
new Normative statement for all MCCs, right?  I think that the “MUST” is
out of place since the text is really stating a fact.  s/MUST/must


M2. SRMS Definition and Operation

M2.1. Section 4.2.1. (SR to LDP Behavior) uses normative language to
describe the operation of the SRMS in ways that I think are not needed for
interoperability.

M2.1.1. "The SRMS MUST be configured by the operator in order to
advertise Node-SIDs
on behalf of non-SR nodes.”  Section 4.2 already says that "The mappings
advertised by one or more SRMSs result from local policy information
configured by the operator.”, so the sentence in 4.2.1 is at best
redundant.  In any case, what can be enforced from a specification point of
view by that “MUST”?  s/MUST/must

M2.1.2. "At least one SRMS MUST be present in the routing domain.
Multiple SRMSs
SHOULD be present for redundancy.”  These MUST|SHOULD seem to indicate a
statement of fact.  Again, from a specification point of view, what can be
enforced?  s/MUST|SHOULD/must|should. Note also that in 7.2 the text says
that "Multiple SRMSs can be provisioned in a network for redundancy.”,
which seems to be the right thing (no Normative language).

M2.2. Section 7.2. says that "a preference mechanism may also be used among
SRMSs so to deploy a primary/secondary SRMS scheme”…but no other details
are included.  This document is where the SRMS is first defined, so I would
expect this detail to also be included here.  I note that Section 3.1. (SID
Preference) of draft-ietf-spring-conflict-resolution contains the
preference specification. Please move that section to this document.

M2.3. Section 7.2 also says that: "When the SRMS advertise mappings, an
implementation SHOULD provide a mechanism through which the operator
determines which of the IP2MPLS mappings are preferred among the one
advertised by the SRMS and the ones advertised by LDP.”  First off, I think
that the SHOULD is out of place because it is not specifying any specific
action (the mechanism is not explicit). Second, this statement (with the
Normative SHOULD) is in conflict with (from 2.2. (IP2MPLS co-existence)):
"if both LDP and SR propose an IP to MPLS entry (IP2MPLS) for the same IP
prefix, then the LDP route SHOULD be selected.”  Solution: s/SHOULD/should


M3. Manageability Considerations

M3.1. The text in Section 7.1. (SR and LDP co-existence) is almost the same
as in Section 2.2. (IP2MPLS co-existence); the difference is that 7.1’s
first bullet says that "by default the LDP route MUST be selected”, while
2.2 uses SHOULD instead.  Which one is it?  Obviously, having the same text
is two places adds nothing to the document — please consolidate.

M3.2. [minor] The last bullet in 7.1/2.2 says that the "policy MAY be
locally defined.  There is no requirement that all routers use the same
policy.”  Given that in this case “all routers” really refers to the edge
nodes (at the IP2MPLS boundary), it seems like it makes sense that either
choice could be ok.  Maybe I’m wrong, but I’m guessing that giving
preference to LDP (MUST/SHOULD above) has to do with the assumption that it
is supported everywhere, while SR might not yet be…so it supports the
migration case in Section 3.  Is that a reasonable guess?  It would be
nice, to provide some justification for the default LDP preference so that
operators have a better idea of when it might be ok to use SR instead.


M4. Security Considerations.  I tend to agree that this document doesn’t
introduce anything new…but it does specify something different.  The base
SR-related advertisement by an IGP is done for the segments belonging to
the local node, but the SRMS lets a node (any node, multiple nodes) adverse
any mapping (for nodes that may be anywhere in the network) which may
result in conflicting advertisements (in the best case), or even false
ones.  Cryptographic authentication (any any other current security
mechanisms in IGPs) only verify that the information was not changed, but
it doesn’t validate the information itself, which can then lead to
conflicting and or false advertisements, which could “compromise traffic
forwarding”.  You should at least recognize that the risk exists, even if
no specific mitigation (except maybe strict configuration/programmability
control by the operator) can be mentioned.


M5. References:  These references don’t need to be Normative and can be
made Informative:
I-D.ietf-isis-segment-routing-extensions,
I-D.ietf-ospf-ospfv3-segment-routing-extensions,
I-D.ietf-ospf-segment-routing-extensions.
OTOH, this one should be Normative: RFC5036



Minor:

P1. As with all the other SR-related documents, please take out “service
chain” from the text.

P2. Please add References for "RSVP-TE, BGP 3107, VPNv4”.  BTW, note that
rfc3107 has been obsoleted by rfc8277 — you make references to “BGP3107”
routes/label.

P3. Please define (or reference) the MPLS2MPLS, MPLS2IP and IP2MPLS
terminology (only IP2MPLS is expanded).

P4. From Section 3: “...the SR infrastructure is usable, e.g. for Fast
Reroute (FRR) or IGP Loop Free Convergence to protect existing IP and LDP
traffic.  FRR mechanisms are described in
[I-D.bashandy-rtgwg-segment-routing-ti-lfa].”
draft-ietf-spring-resiliency-use-cases may be a better reference.

P5. Section 3: "However, any traffic switched through LDP entries will
still suffer from LDP-IGP synchronization.”  While that statement is true,
it seems out of place since there is no other discussion about LDP-IGP
synchronization anywhere — if you want to keep it, please add a reference.

P6. Sections 4 and 4.1.1 have very similar, redundant text.  To avoid
confusion, please consolidate it in one place.  This is what I’m referring
to:

4:
“  If the SR/LDP node operates in LDP ordered label distribution control
  mode (as defined in [RFC5036]), then the SR/LDP node MUST consider SR
  learned labels as if they were learned through an LDP neighbor and
  create LDP bindings for each Prefix-SID and Node-SID learned in the
  SR domain."

4.1.1:
"  A SR node having LDP neighbors MUST create LDP bindings for each
  Prefix-SID and Node-SID learned in the SR domain and, for each FEC,
  stitch the incoming LDP label to the outgoing SR label.  This has to
  be done in both LDP independent and ordered label distribution
  control modes as defined in [RFC5036]."

Note that this same text (as in 4.1.1 above) is repeated exactly in 4.2.1 —
where the SRMS is discussed.  To me, it seems out of place there (4.2.1) as
the behavior is true whether an SRMS is in use or not.  In line with the
above, it may be better to consolidate redundant text in one place —
Section 4 seems good to me.



Nits:

N1. s/This draft(s)/This document

N2. s/Ship-in-the-night/Ships-in-the-night

N3. Please don’t use “we”, use the 3rd person instead.  Just a personal
preference (= nit).

N4. s/R-LFA/RLFA

N5. Please put the reference for Option C when it is first mentioned.
2017-12-20
09 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2017-12-07
09 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2017-12-07
09 Alvaro Retana Notification list changed to aretana.ietf@gmail.com
2017-09-29
09 Stephane Litkowski New version available: draft-ietf-spring-segment-routing-ldp-interop-09.txt
2017-09-29
09 (System) New version approved
2017-09-29
09 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Ahmed Bashandy , Bruno Decraene , Stefano Previdi , Stephane Litkowski
2017-09-29
09 Stephane Litkowski Uploaded new revision
2017-07-12
08 Martin Vigoureux
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard is being requested and indicated in the header.
This is appropriate as the draft defines methods and procedures to achieve interoperability between LDP and SR.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  A Segment Routing (SR) node steers a packet through a controlled set
  of instructions, called segments, by prepending the packet with an SR
  header.  A segment can represent any instruction, topological or
  service-based.  SR allows to enforce a flow through any topological
  path and service chain while maintaining per-flow state only at the
  ingress node to the SR domain.

  The Segment Routing architecture can be directly applied to the MPLS
  data plane with no change in the forwarding plane.  This drafts
  describes how Segment Routing operates in a network where LDP is
  deployed and in the case where SR-capable and non-SR-capable nodes
  coexist.

Working Group Summary

  The WG supports the progress of this Document towards its publication as a Proposed Standard RFC.

Document Quality

  The Document is quite well written, with configuration examples.
  There are known implementations.

Personnel

  Martin Vigoureux is the Document Shepherd
  Alvaro Retana is the Responsible AD

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The Document has been reviewed in depth by the Document Shepherd. It is ready

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No such concern. The Document has been reviewed by the WG and went through an early RTGDIR review.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No portion of the Document needs such review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concern

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  All authors have confirmed that they are not aware of any undisclosed IPR which would relate to this draft.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Two IPR disclosures exist against this document.
  https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-ldp-interop
  The WG did not express any concern.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threat.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  ID nits is clean

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No such review criteria needed.

(13) Have all references within this document been identified as
either normative or informative?

  Yes, except maybe for ietf-spring-conflict-resolution and ietf-spring-segment-routing-mpls which may not need to be Normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All Normative References are still Internet-Drafts but these are being progressed towards RFC publication currently.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  The publication of this Document will not change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This document makes no request to IANA.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  This document makes no request to IANA.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No section requires such automated checks.
2017-07-12
08 Martin Vigoureux Responsible AD changed to Alvaro Retana
2017-07-12
08 Martin Vigoureux IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2017-07-12
08 Martin Vigoureux IESG state changed to Publication Requested
2017-07-12
08 Martin Vigoureux IESG process started in state Publication Requested
2017-07-12
08 Martin Vigoureux Changed document writeup
2017-07-12
08 Martin Vigoureux Changed document writeup
2017-07-10
08 Martin Vigoureux Changed document writeup
2017-07-10
08 Martin Vigoureux Changed document writeup
2017-06-15
08 Stefano Previdi New version available: draft-ietf-spring-segment-routing-ldp-interop-08.txt
2017-06-15
08 (System) New version approved
2017-06-15
08 (System) Request for posting confirmation emailed to previous authors: Stefano Previdi , Ahmed Bashandy , Bruno Decraene , spring-chairs@ietf.org, Clarence Filsfils , Stephane Litkowski
2017-06-15
08 Stefano Previdi Uploaded new revision
2017-05-02
07 Stefano Previdi New version available: draft-ietf-spring-segment-routing-ldp-interop-07.txt
2017-05-02
07 (System) New version approved
2017-05-02
07 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Ahmed Bashandy , Bruno Decraene , Stefano Previdi , Stephane Litkowski
2017-05-02
07 Stefano Previdi Uploaded new revision
2017-03-17
06 Martin Vigoureux IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2017-02-08
06 Stefano Previdi New version available: draft-ietf-spring-segment-routing-ldp-interop-06.txt
2017-02-08
06 (System) New version approved
2017-02-08
06 (System) Request for posting confirmation emailed to previous authors: "Clarence Filsfils" , "Ahmed Bashandy" , "Bruno Decraene" , "Stefano Previdi" , "Stephane Litkowski"
2017-02-08
06 Stefano Previdi Uploaded new revision
2017-02-06
05 Martin Vigoureux IETF WG state changed to In WG Last Call from WG Document
2017-01-27
05 Martin Vigoureux Notification list changed to none from "Martin Vigoureux" <martin.vigoureux@nokia.com>
2017-01-27
05 Martin Vigoureux Notification list changed to "Martin Vigoureux" <martin.vigoureux@nokia.com>
2017-01-27
05 Martin Vigoureux Document shepherd changed to Martin Vigoureux
2017-01-06
05 Stefano Previdi New version available: draft-ietf-spring-segment-routing-ldp-interop-05.txt
2017-01-06
05 (System) New version approved
2017-01-06
05 (System) Request for posting confirmation emailed to previous authors: "Clarence Filsfils" , "Ahmed Bashandy" , "Bruno Decraene" , "Stefano Previdi" , "Stephane Litkowski"
2017-01-06
05 Stefano Previdi Uploaded new revision
2017-01-05
04 (System) Document has expired
2016-07-12
04 Bruno Decraene Added to session: IETF-96: spring  Mon-1800
2016-07-04
04 Stefano Previdi New version available: draft-ietf-spring-segment-routing-ldp-interop-04.txt
2016-05-17
03 Stefano Previdi New version available: draft-ietf-spring-segment-routing-ldp-interop-03.txt
2016-05-11
02 Stefano Previdi New version available: draft-ietf-spring-segment-routing-ldp-interop-02.txt
2016-04-14
01 Stefano Previdi New version available: draft-ietf-spring-segment-routing-ldp-interop-01.txt
2015-10-15
00 Bruno Decraene Intended Status changed to Proposed Standard from None
2015-10-15
00 Bruno Decraene This document now replaces draft-filsfils-spring-segment-routing-ldp-interop instead of None
2015-10-15
00 Stefano Previdi New version available: draft-ietf-spring-segment-routing-ldp-interop-00.txt