LDP Downstream-on-Demand in Seamless MPLS
draft-ietf-mpls-ldp-dod-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-12-20 |
09 | (System) | Received changes through RFC Editor sync (changed abstract to 'Seamless MPLS design enables a single IP/MPLS network to scale over core, metro, and access parts … Received changes through RFC Editor sync (changed abstract to 'Seamless MPLS design enables a single IP/MPLS network to scale over core, metro, and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access networks including high number of devices, device position in network topology, and compute and memory constraints that limit the amount of state access devices can hold. This can be achieved with LDP Downstream-on-Demand (DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence.') |
2015-10-14 |
09 | (System) | Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-ldp-dod@ietf.org to (None) |
2013-10-31 |
09 | (System) | RFC published |
2013-10-18 |
09 | (System) | RFC Editor state changed to AUTH48 from AUTH48-DONE |
2013-10-14 |
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-09-27 |
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-09-11 |
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-08-26 |
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-08-23 |
09 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-08-23 |
09 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-08-22 |
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-08-22 |
09 | (System) | RFC Editor state changed to EDIT |
2013-08-22 |
09 | (System) | Announcement was received by RFC Editor |
2013-08-22 |
09 | (System) | IANA Action state changed to In Progress |
2013-08-22 |
09 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-08-22 |
09 | Amy Vezza | IESG has approved the document |
2013-08-22 |
09 | Amy Vezza | Closed "Approve" ballot |
2013-08-22 |
09 | Adrian Farrel | State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2013-08-22 |
09 | Adrian Farrel | Ballot writeup was changed |
2013-08-22 |
09 | Adrian Farrel | Ballot approval text was generated |
2013-08-15 |
09 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2013-08-15 |
09 | Adrian Farrel | Waiting for Stewart to supply a suitable reference for FRR |
2013-08-15 |
09 | Francis Dupont | Request for Telechat review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2013-08-15 |
09 | Adrian Farrel | Ballot writeup was changed |
2013-08-15 |
09 | Adrian Farrel | Ballot writeup was changed |
2013-08-15 |
09 | Adrian Farrel | Ballot writeup was changed |
2013-08-15 |
09 | Adrian Farrel | Ballot writeup was changed |
2013-08-14 |
09 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-08-13 |
09 | Sean Turner | [Ballot comment] nicely done! |
2013-08-13 |
09 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-08-13 |
09 | Stephen Farrell | [Ballot comment] - abstract: "specific to access" reads oddly, "specific to access networks" might be better - abstract: "fast-up convergence" isn't that clear (but I … [Ballot comment] - abstract: "specific to access" reads oddly, "specific to access networks" might be better - abstract: "fast-up convergence" isn't that clear (but I think I get it) - if there were a way to describe that in plainer language that'd be nice - I was surprised that the seamless draft is informative and not normative. Not objecting, just surprised. - intro: "access border routers (access ABRs)" seems like an oddly recursive acronym (a recursive RA:-), or maybe just a typo? - The security considerations section seems very thorough, thanks! One question though - it wasn't clear to me if there are any security mechanism(s) that are mandatory to implement - can you clarify? It may well be that that's ok for this document, and that adding some MTI security, if it were needed, ought be done elsewhere, but it just wasn't clear to me whether something here is MTI or not. - Thanks for addressing the secdir reviewer's issues as well. |
2013-08-13 |
09 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-08-12 |
09 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-08-12 |
09 | Barry Leiba | [Ballot comment] I find this document to be quite informational indeed: well written, clear, and thorough. Thanks for the good work. Comment below has been … [Ballot comment] I find this document to be quite informational indeed: well written, clear, and thorough. Thanks for the good work. Comment below has been addressed, and is retained here for posterity. -------------------------------------------- From the shepherd writeup: There has been a dioscussion if this as a Standards Track or should be Informational. Since the document specifies a new LDP TLV we have found that it needs to be on the Standrds track. In fact, the registration policy for the LDP TLV Type Name Space registry is IETF Consensus (see RFC 5036, Section 4.2), and Informational would work perfectly well. If that is the deciding reason the working group chose Standards Track over Informational, we should reconsider that now. Adrian has clarified: > I think in this case the document is describing a protocol extension to a > standards track protocol. That extension is intended for wide-scale > implementation and is neither a vendor-specific extension, not a description > of how you use existing protocol mechanisms to achieve something. Thus, > "standards track" was chosen not a requirement of the registry, but as a > statement about the content of the document. |
2013-08-12 |
09 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2013-08-12 |
09 | Jari Arkko | [Ballot comment] Has there been a response to Gen-ART review comments from Francis Dupont? |
2013-08-12 |
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-08-12 |
09 | Barry Leiba | [Ballot discuss] I'd like to discuss this with the authors, working group chairs, and responsible AD, and I expect to clear this quickly and not … [Ballot discuss] I'd like to discuss this with the authors, working group chairs, and responsible AD, and I expect to clear this quickly and not hold the document up on this point: From the shepherd writeup: There has been a dioscussion if this as a Standards Track or should be Informational. Since the document specifies a new LDP TLV we have found that it needs to be on the Standrds track. In fact, the registration policy for the LDP TLV Type Name Space registry is IETF Consensus (see RFC 5036, Section 4.2), and Informational would work perfectly well. If that is the deciding reason the working group chose Standards Track over Informational, we should reconsider that now. My reading certainly supports Informational. (And, in fact, I find this document to be quite informational indeed: well written, clear, and thorough. Thanks for the good work.) |
2013-08-12 |
09 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2013-08-10 |
09 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-08-09 |
09 | Spencer Dawkins | [Ballot comment] My understanding is that this draft is simply reducing the amount of state that access nodes need to keep, as a cost optimization, … [Ballot comment] My understanding is that this draft is simply reducing the amount of state that access nodes need to keep, as a cost optimization, and does not introduce new TSV concerns because data plane traffic would end up in the same place if MPLS routers advertise MPLS labels for all valid routes in their RIB, as they would do if Downstream On Demand was not available. As an aside, I've been reading MPLS-related drafts from time to time since the early 2000s, and found this one to be one of the clearest drafts I've seen. Good job! One nit: 4.3.2. Label Request Retry Following LDP specification LDP specification [RFC5036], if an access LSR/ABR receives a "No route" Notification in response to its Label Request message, it retries using an exponential backoff algorithm similar to the backoff algoritm mentioned in the LDP session "algorithm" negotiation described in Section 4.2. |
2013-08-09 |
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-08-08 |
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2013-08-08 |
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2013-08-08 |
09 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-08-07 |
09 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Stephen Kent. |
2013-08-06 |
09 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-08-05 |
09 | Stewart Bryant | [Ballot comment] I am voting yes, but have one small comment that I am confident that Adrian will look at: "If remote LFA is enabled, … [Ballot comment] I am voting yes, but have one small comment that I am confident that Adrian will look at: "If remote LFA is enabled, access LSR/ABR needs a label from its alternate next-hop toward the PQ node and needs a label from the remote PQ node toward its FEC/destination. " Remote LFA surely needs a reference as does PQ. |
2013-08-05 |
09 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
2013-07-25 |
09 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Stephen Kent |
2013-07-25 |
09 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Stephen Kent |
2013-07-24 |
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-07-23 |
09 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2013-07-23 |
09 | Adrian Farrel | Ballot has been issued |
2013-07-23 |
09 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2013-07-23 |
09 | Adrian Farrel | Created "Approve" ballot |
2013-07-23 |
09 | Adrian Farrel | Placed on agenda for telechat - 2013-08-15 |
2013-07-13 |
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-07-13 |
09 | Maciek Konstantynowicz | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-07-13 |
09 | Maciek Konstantynowicz | New version available: draft-ietf-mpls-ldp-dod-09.txt |
2013-06-03 |
08 | Francis Dupont | Request for Last Call review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2013-05-28 |
08 | Adrian Farrel | Changed consensus to Yes from Unknown |
2013-05-28 |
08 | Adrian Farrel | Revision needed to address SecDir review received during IETF last call |
2013-05-28 |
08 | Adrian Farrel | State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2013-05-27 |
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-05-23 |
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Stephen Kent. |
2013-05-16 |
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2013-05-16 |
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2013-05-16 |
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2013-05-16 |
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2013-05-16 |
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2013-05-16 |
08 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-ldp-dod-08.txt. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-ldp-dod-08.txt. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA understands that, upon approval of this document, there is a single IANA action which must be completed. In the TLV Type Name Space registry in the Label Distribution Protocol (LDP) registry located at: http://www.iana.org/assignments/ldp-namespaces/ldp-namespaces.xml a single TLV type will be added as follows: Value: [ TBD-at-registration ] Description: Queue Request TLV Reference: [ RFC-to-be ] Notes/Registration Date: IANA notes that the authors have requested the value 0x0971 to be used for this registration, and IANA will comply with this request where possible. IANA understands that this is the only action required upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2013-05-13 |
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-05-13 |
08 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <mpls@ietf.org> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-mpls-ldp-dod-08.txt> … The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <mpls@ietf.org> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-mpls-ldp-dod-08.txt> (LDP Downstream-on-Demand in Seamless MPLS) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'LDP Downstream-on-Demand in Seamless MPLS' <draft-ietf-mpls-ldp-dod-08.txt> 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 2013-05-27. 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 Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-05-13 |
08 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-05-13 |
08 | Adrian Farrel | Last call was requested |
2013-05-13 |
08 | Adrian Farrel | Ballot approval text was generated |
2013-05-13 |
08 | Adrian Farrel | State changed to Last Call Requested from AD Evaluation::AD Followup |
2013-05-13 |
08 | Adrian Farrel | Last call announcement was changed |
2013-05-13 |
08 | Adrian Farrel | Last call announcement was generated |
2013-05-13 |
08 | Maciek Konstantynowicz | New version available: draft-ietf-mpls-ldp-dod-08.txt |
2013-05-13 |
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-05-13 |
07 | Maciek Konstantynowicz | New version available: draft-ietf-mpls-ldp-dod-07.txt |
2013-05-13 |
06 | Adrian Farrel | Need one final revision to sort out the references and an over-long line. |
2013-05-13 |
06 | Adrian Farrel | State changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2013-05-13 |
06 | Adrian Farrel | Ballot writeup was changed |
2013-05-13 |
06 | Adrian Farrel | Ballot writeup was changed |
2013-05-13 |
06 | Adrian Farrel | Ballot writeup was generated |
2013-05-13 |
06 | Adrian Farrel | Document shepherd changed to Loa Andersson |
2013-05-10 |
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-05-10 |
06 | Maciek Konstantynowicz | New version available: draft-ietf-mpls-ldp-dod-06.txt |
2013-03-09 |
05 | Adrian Farrel | AD review === Hi authors of draft-ietf-mpls-ldp-dod, I have performed my usual review of your document at the time of your publication request. The purpose … AD review === Hi authors of draft-ietf-mpls-ldp-dod, I have performed my usual review of your document at the time of your publication request. The purpose of the review is to catch issues and nits that might otherwise show up during IETF last call or IESG evaluation and which might slow down the progress of the document, cause multiple people to spend time on the concerns, or hide other issues. Although I have no fundamental concerns with your work (which is very readable) a couple of my concerns may need some rework of the text. So I will put the document into "revised I-D needed" and wait to see a new version from you. As usual, all my comments are open for discussion. Thanks for the work, Adrian --- There are a number of cases in figures and in the text where "ISIS" is stated as the IGP running in the Aggregation Domain and/or the Core. In my opinion it is very important to separate operators' specific preferences or actual deployments from this Standards Track document. Is there any technical reason why what is described here would not work using OSPF? I think the fix is: - add a statement to the Introduction on the support of both IGPs. - either - explain that "every mention of ISIS is intended to be equally applicable to OSPF" or - replace "ISIS" with "IGP" throughout the document. --- There are few line-length problems that idnits will lag for you. --- It is clear that you intend this work to support IPv4 and IPv6 equally. This comes out in some of the examples where you write, for example, "/32 or /128 destinations". It also shows in some more explicit text like the penultimate paragraph of Section 2.2. But it is not really obvious. And a pedant might point out that a /32 is an interesting IPv6 prefix. I suggest two actions: 1. Make an explicit statement in the Introduction about supporting both v4 and v6 2. Be more longwinded (pedantic) where you say things like "/32 or /128 destinations" And I was happy with that until I got to the end of Section 3 and found: This document is focusing on IPv4 LDP DoD procedures. Similar procedures will apply to IPv6 LDP DoD [I-D.ietf-mpls-ldp-ipv6]. Make your minds up! :-) And then get the document to be self-consistent. --- Section 3 I don't know what you mean by LDP DoD operation is driven by Seamless MPLS use cases. That doesn't really seem to be generically true! Are you trying to scope what appears in this document, or maybe to scope the use cases that you are presenting? --- I am struggling to see why [I-D.ietf-mpls-seamless-mpls] is not a normative reference. It seems that it is pretty fundamental to this document. RFC 4447 is definitely used in a normative way. --- It would be nice if you followed the conventions of RFC 5036 for capitalisation of terms like "label request". It is likely that the RFC Editor will try to enforce this, and you are more likely to achieve this in a consistent and accurate way. --- I understand that the authors initially intended this document to be Informational, and that would have eased a number of my concerns, but as it is now positioned as a Standards Track document, I worry that some of the material (essentially nearly all of Section 4) that provides a description of LDP and in particular DoD, appears to be normative. I have no reason to believe that the text diverges from what 5036 says, but should it be found to (possibly at some time in the future) we will have a little conundrum to solve. So I think that means some small restructuring of the document to break Section 4 into two pieces: - Most of the descriptive text, which can then be prefixed with a clear and unambiguous statement that it is not normative and does not replace the description of LDP in 5036 and o PWs as described in 4447. - New protocol elements and procedures (which I think is limited to 4.4.3) that can be marked as normative. --- Following the previous point, I am uneasy about the use of 2119 language in Section 4. For example, in 4.1 you are essentially saying that "in order to build a specific type of network, the nodes in the network MUST do foo." What you have is essentially an applicability statement, and these are not usually written with 2119 language. More common is "to achieve bar, an implementation does foo" Is 4.4.1 bullet e defining new behavior? Or is it re-stating 5036? Ditto the second bullet a in 4.4.1. And similarly section 4.7. While the SHOULD in section 4.2 sounds more hopeful than anything else! --- Section 4.4.3 has some ambiguous behavior. If the downstream LSR does not support the Queue Request TLV, it will silently ignores it, and sends a "no route" notification back. In this case the upstream LSR invokes the exponential backoff algorithm described in Section 4.4.2. Four things: 1. I think the downstream LSR's behavior described here is compliant with RFC 5036. A precise reference would be good. 2. "Silently ignore" is not compatible with "send a no route notification" 3. The TLV has the U bit set to 1, which you correctly quote from 5036 means Unknown TLV bit is set to 1. If this optional TLV is unknown, it should be ignored without sending "no route" notification. Ensures backward compatibility. Note well *without*. This is contradicted by your text! 4. If the downstream LSR does not support the TLV, how will resending it help on a backoff help? --- Section 6 is a hearty section. Thanks for thinking about this. It is somewhat surprising that you can write a security section on MPLS without reference to RFC 5920. And I wonder whether a reference to the work in KARP (especially draft-ietf-karp-routing-tcp-analysis). One sentence in 6.3 caught my eye in particular. Similarly to Inter-AS MPLS/VPN deployments [RFC4364], the data plane security depends on the security of the control plane. To my eye that reads like "you can secure the data plane if you secure the control plane." I think you mean something more like, "if you don't secure the control plane, you can't secure the data plane." Which is more compatible with the text in 6.2 and 6.3. |
2013-03-09 |
05 | Adrian Farrel | State changed to AD Evaluation::Revised ID Needed from AD Evaluation |
2013-03-03 |
05 | Adrian Farrel | State changed to AD Evaluation from Publication Requested |
2013-03-03 |
05 | Adrian Farrel | Note added 'Loa Andersson (loa@pi.nu) is the document shepherd' |
2013-03-03 |
05 | Adrian Farrel | Intended Status changed to Proposed Standard |
2013-03-03 |
05 | Adrian Farrel | IESG process started in state Publication Requested |
2013-03-03 |
05 | (System) | Earlier history may be found in the Comment Log for draft-beckhaus-ldp-dod |
2013-03-03 |
05 | Adrian Farrel | Shepherding AD changed to Adrian Farrel |
2013-03-01 |
05 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2013-03-01 |
05 | Loa Andersson | Annotation tag Doc Shepherd Follow-up Underway set. |
2013-02-28 |
05 | Loa Andersson | Annotation tag Doc Shepherd Follow-up Underway cleared. |
2013-02-28 |
05 | Loa Andersson | Changed protocol writeup |
2013-02-25 |
05 | Maciek Konstantynowicz | New version available: draft-ietf-mpls-ldp-dod-05.txt |
2013-02-03 |
04 | Maciek Konstantynowicz | New version available: draft-ietf-mpls-ldp-dod-04.txt |
2012-08-02 |
03 | Maciek Konstantynowicz | New version available: draft-ietf-mpls-ldp-dod-03.txt |
2012-07-15 |
02 | Maciek Konstantynowicz | New version available: draft-ietf-mpls-ldp-dod-02.txt |
2012-03-12 |
01 | Thomas Beckhaus | New version available: draft-ietf-mpls-ldp-dod-01.txt |
2012-01-04 |
00 | (System) | New version available: draft-ietf-mpls-ldp-dod-00.txt |