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 |