Subject: [mpls] AD review of draft-ietf-mpls-mldp-in-band-signaling

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 Sep 2012 23:54:15 +0100

Hi,

I have done my AD review of your draft prior to sending it to IETF last
call and subsequent IESG evaluation. There are a number of small nits
that I hope you can mop up, and a few questions that we should be able
to resolve through discussion or with a new revision of the I-D.

I will change the state of the draft in the data tracker to show
"revised I-D needed", but please feel free to debate these points if you
want to convince me that no change is needed.

Cheers,
Adrian

---

Please fix the idnits as indicated in the shepherd write-up

> The idnits-tool flags three "problems" 
>
> 1. There are three outdated references 
>
> 2. There is a disclaimer for pre-RFC5378 work, that is not 
>     really needed. 
>
> 3. Some of the references are to older version of the referenced 
>     document 

In particular, note RFC 6388.

---

Abstract is fine in what it says, but it should also have a short
second sentence "This document..." saying whatever it is that this
document does.

--- 

Afraid that you need to expand acronyms on first use in the body text
because it is assumed to be stand-alone from the Abstract.

But some are already well-known and don't need to be expanded. (PIM, 
BGP, MPLS, IP)

I see...

mLDP
LSP
FEC
LSR

---

Section 1
s/enduser/end-user/  twice

---

Section 1

   Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in
   the MPLS network.  This type of service works well if the number of
   LSPs that are created is under control of the MPLS network operator,
   or if the number of LSPs for a particular service are known to be
   limited in number.

This paragraph gives me cause to wonder. Does the service work badly if
neither of these conditions holds? What would badly mean?

I suspect you are hinting that there is a scaling issue here. Do you
think you should bring that out? I don't think it would damage your work
if you did so because clearly you believe there are advantages to this
approach of direct mapping when the numbers are under control.

---

s/draft/document/
- Section 1 twice
- Section 2.1
- Section 6

---

Section 1.2
s/an source/a source/
s/An P2MP/A P2MP/

---

Section 1.2

   IP multicast tree :  An IP multicast distribution tree identified by
      an source IP address and/or IP multicast destination address, also
      refered to as (S,G) and (*,G).

I think you and/or is wrong. The G is always present and the S is
optionally present. You have written that at least one of S and G must
be present.

Also, why do you call it "destination address" not "group"? The text 
later (e.g. Section 2) uses "group".

Oh, and s/refered/referred/

---

Section 1.2

   MP2MP LSP:  An LSP that connects a set of leaf nodes, acting
      indifferently as ingress or egress.

"indifferently" is beautiful in this usage.
Suggest:

   MP2MP LSP:  An LSP that connects a set of leaf nodes that may each 
      independently act as ingress or egress.

---

Section 1.2

   Ingress LSR:  Source of the P2MP LSP, also referred to as root node.

Doesn't "ingress" have a meaning in the context of an MP2MP LSP?

---

Section 2 really would benefit from at least one figure, but maybe more.
It is not a requirement to add them, but they don't cost anything and
they are really easy to add.

---

Section 2

   Suppose an LSR, call it D, is attached to a network that is capable
   of MPLS multicast and IP multicast

I suspect from the text that follows (e.g. ""the IP multicast tree needs
to travel through the MPLS network") that D is attached to two networks
one of which is capable of MPLS multicast, and the other is capable of
IP multicast. Is that what you meant?

---

Section 2.3

   Bidirectional IP multicast trees [RFC5015] MUST be transported across
   a MPLS network using MP2MP LSPs.

I am trying to work out how this "MUST" is to be applied.

Obviously you don't mean that every time you have a bidir IP mcast tree
you have to go out and find an MPLS network to transport it across :-)

But are you trying to say that when a bidir IP mcast tree needs to be
carried over an MPLS network it MUST be carried by an MP2MP LSP? Is that
a. really true
b. enforceable by the IETF
c. something that this protocol spec can state?

Are you actually saying:

   When a bidirectional IP multicast tree [RFC5015] is carried over an
   MPLS network using the in-band signaling described in this document, 
   it is supported using an MP2MP LSP.

---

Section 3.1

Figure seems to be missing row ends.

---

Sections 3.1 and 3.2

Shouldn't you say how to encode (*,G)? What value goes in the Source
field in the TLV?

---

4.  Security Considerations

   The same security considerations apply as for the base LDP
   specification, as described in [RFC5036].

Isn't this a little bit of a stretch?
The fact is that there is now a new way to trigger behavior inside the
MPLS network (viz. by hacking a PIM network). And a new way to disrupt
a PIM network (viz. by hacking an MPLS network).

At the very least, this means policy needs to be carefully configured
at the edge LSRs. You need to talk about this in this section.

---

I find two important topics missing from this document:
1. manageability
2. backward compatibility

For the first of these, I should have liked to have some discussion of 
what things need to be configured to make this process work. What should
be configurable in an implementation (you mention "under control of the 
MPLS network operator" in Section 1) and how should an operator use the
knobs?

For the second, I think you need to describe what happens when a transit
or an ingress is unaware of the meaning of the opaque TLVs. The transit
is easy, I think - it should not examine the opaque info so it won't
matter... you can just make this statement and point at the appropriate
section of RFC 6388. The ingress is more interesting: will it barf, 
release the label, or ignore the unknown opaque TLV? If it ignores it, 
how will you ever know that your mcast flow has not been set up (except
you never receive traffic)?