[mpls] AD review of draft-ietf-mpls-ldp-dod

["Adrian Farrel" <[e-mail]>]

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.