Subject: [mpls] AD review of draft-ietf-mpls-mp-ldp-reqs

From: Adrian Farrel <[email-masked]>
Date: Sat, 30 Apr 2011 23:24:50 +0100

Hi,                    

Don't panic!

I have performed my AD review of your draft. The purpose of the review
is to catch any nits or issues before the document goes forward to IETF
last call and IESG review. By getting these issues out at this stage we
can hope for a higher quality review and a smoother passage through the
process.

Thank you for a good analysis of the requirements for P2MP LDP. Most of
my issues are either relatively minor editorial changes or take the
form of questions. A few points, however, may take a little bit of new
textto resolve.

All of my comments (especially the questions) are up for discussion,
and you should not feel rail-roaded into making changes. But I do think
my comments need to be addressed before the draft moves forward, and I 
would like to see a revised I-D to tidy up the editorial points.

I have moved the draft into "AD-review:Revised-ID-needed" state in the
datatracker, and I look forward to seeing the new revision which I can
put forward for IETF last call.

Thanks,
Adrian

---

Having 7 authors listed on the front page is somewhat unusual and is
also likely to mean that the document is slow to progress through the
later stages of publication. 

Would it be possible to consider moving everyone except for the editor
off the front page? You will still all be listed as authors at the end
of the document.

---

You need to add a couple of acronyms to Section 1.1

LSP
LSR
MP2P

---

Section 2

   and
   have already deployed LDP for P2P traffic                           

s/and/and who/

---

Section 3.1 seems to replicate a deal of text from Section 2.

---

Section 5.1

   Only one copy of a packet MUST be sent on a given
   link of a P2MP LSP.

I think you mean...

   Exactly one copy of a packet MUST be sent on a given
   link of a P2MP LSP.

...or better...

   More than one copy of a packet MUST NOT be sent on a given
   link of a P2MP LSP.

But really, the ambiguity is caused by the passive voice.
So...

   An LSR MUST NOT send more than one copy of a packet on any
   given link of a P2MP LSP.

---

Section 5.2

   As such, a new LDP FEC that is suitable for P2MP forwarding MUST be
   specified.

You are prejudging the solution by stating that existing FECs are not
suitable. How about:

   If existing FECs cannot be used for this purpose, a new LDP FEC
   that is suitable for P2MP forwarding MUST be specified.

---

Section 5.3

I have no issues with the assumption of bidirectional links, but maybe
you should state the assumption?

OLD
   It is RECOMMENDED that the P2MP LSP routing rely upon a shortest path
   to the Ingress LSR so as to setup an MPLS shortest path tree.
NEW
   It is RECOMMENDED that the P2MP LSP routing rely upon a shortest path
   to the Ingress LSR so as to setup an MPLS shortest path tree assuming
   all links are bidirectional.
END

But, are you sure you want shortest path trees? It is certainly the
easiest solution to build using the mechanism recommended, but I wonder
whether the requirement here is being driven by the solution you have
in mind, rather than being the real requirement.

Anyway, you said earlier in the document that an objective was to
optimise resource usage in network, and shortest path trees don't
guarantee that. So maybe you need to go back to that base requirement
and soften it to say "make better use of network resources."

---

Section 5.4

I think you need to add that the mechanisms by which an ingress can
discover the identities of the egresses attached to the P2MP LSP are
also out of scope.

---

Section 5.4

   The P2MP LDP mechanism MUST allow the dynamic addition and removal of
   leaves to and from a P2MP LSP, without any restriction (provided
   there is network connectivity).

I agree that the mechanism must allow this.

One of the issues we faced with P2MP RSVP-TE was a belief that there
might be limits to the branching capabilities in some nodes. This is
potentially both a physical limit for the node, and a practical limit 
for the LSP (if round-robin replication is needed).

So the mechanism needs to allow a node to say "I can't be a branch
for any more spurs of this tree." 

The solution to this situation might be in direct conflict to your
requirement in 5.1 about duplicate packets on a "link". Again, see
the way we got around this in P2MP RSVP-TE.

---

Section 5.7

   This may rely on extensions to the LDP Loop detection mechanism
   defined in [RFC5036].  A loop detection mechanism may require
   recording the set of LSRs traversed on the P2MP Tree.  The P2MP loop
   avoidance mechanism MUST NOT impact the scalability of the P2MP LDP
   solution.

I think both "may" should be "MAY"

---

Section 5.8

   Given that P2MP LDP routing should rely on the RIB, the achievement
   of the following requirements also implies the underlying routing
   protocols (IGP, etc.).

Something wrong with this sentence around "also implies".

---

Section 5.8.1

   A mechanism MUST be defined to prevent constant P2MP LSP teardown and
   rebuild which may be caused by the instability of a specific link/
   node in the network.  This will rely on IGP dampening but may be
   completed by specific dampening at the LDP level.

Again, this is driving the solution a bit hard. 
If you really want to say "will rely" then you should convert it to 
"MUST rely".
s/may/MAY/ in the last subclause.

---

Section 5.9

I am not sure why you limit this case to a LAN.

Would you consider replacing "LAN" with "multi-access network"?
Needs a little rewording around "LAN interface" but that looks easy
enough.

---

Section 5.16. 

   A solution MUST avoid single points of failures provided there is
   enough network connectivity.

What does this mean?
It shows up again in section 6.1.

---

Section 5.18

   In order to allow for a smooth migration, the P2MP LDP mechanism
   SHOULD offer as much backward compatibility as possible.  In
   particular, the solution SHOULD allow the setup of a P2MP LSP along
   non-Branch Transit LSRs that do not support P2MP LDP extensions.

Hooray for this, but note that if a legacy LSR is at a topological
branch, it will result in duplicate packets being sent by an upstream
LSR on some links that the P2MP LSP traverses. This would be in direct
conflict with your requirement in 5.1 about duplicate packets on a 
"link". Maybe you need to redefine a "link of a P2MP LSP"?

---

Section 6. 

   For traffic delivery between a group of N Leaf LSRs which are acting
   indifferently as Ingress or Egress LSRs, it may be useful to setup a
   shared tree connecting all these LSRs, instead of having N P2MP LSPs.

"acting indifferently" has some unfortunate overtones!

How about...

   For traffic delivery between a group of N LSRs that may be ingress
   and egress LSRs on different P2MP flows, it may be useful to setup a
   shared tree connecting all these LSRs, instead of having N P2MP LSPs.

Or did you mean

   For traffic delivery between a group of N LSRs that all act as 
   ingress and egress LSRs on different P2MP flows, it may be useful to
   setup a shared tree connecting all these LSRs, instead of having N
   P2MP LSPs.

This shows up in 6.1 as well.

---

Section 6.1

   Requirements for P2MP LSPs, set forth in section 6, apply equally to
   MP2MP LSPs.  Particular attention should be given on the below
   requirements:

s/6/5/

---

Section 6.1

   o  Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that
      may trigger exponential growth of traffic.  Note that this
      requirement is more challenging with MP2MP LSPs as a LSR can
      receive traffic for a given LSP on multiple interfaces.

s/can receive/can legitimately receive/

---

Section 6.1

Are you sure that the following two requirements are not in conflict:

   o  It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a
      specific LSR called root LSR;

   o  The solution SHOULD avoid that all traffic between any pair of
      leaves is traversing a root LSR, and SHOULD as much as possible
      minimize the distance between two leaves (similarly to PIM-Bidir
      trees);

---

7.1.  Performances

s/Performances/Performance/

---

Section 7.1

I thought that optimality of the use of network resources was a
criterion

---

Section 8

More important than commenting on the security implications of *this*
document is to set security requirements for the P2MP solution. This
should include the normal control plane considerations, but should 
also examine the risks of a leaf adding itself to a tree to which
it does not belong. I think there may be some specific additional
requirements on the solution in this regard.

---

Section 10

We don't normally name people's companies in the Acknowledgements 
section. One reason (as in this case) is that some of them change jobs.

---

Section 11

According to the use in Section 5.1, RFC 4461 is a normative reference.