Skip to main content

LDP Downstream-on-Demand in Seamless MPLS
RFC 7032

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 <a href="http://www.rfc-editor.org/auth48/rfc7032">AUTH48</a> from AUTH48-DONE
2013-10-14
09 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7032">AUTH48-DONE</a> from AUTH48
2013-09-27
09 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7032">AUTH48</a> 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:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <mpls@ietf.org>
Reply-To: ietf@ietf.org
Sender: …
The following Last Call announcement was sent out:<br><br>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 …
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 <a href="/doc/draft-beckhaus-ldp-dod/">draft-beckhaus-ldp-dod</a>
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