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.')

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

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

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

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

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

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.

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.

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.