[mpls] AD review of draft-ietf-mpls-mldp-hsmp

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

Hi,

I have done my usual AD review of your document having received the
publication request from the working group. The purpose of the review is
to catch and clean up any issues before the document goes to IETF last
call and IESG evaluation.

The WG chairs tell me that there is at least one implementation and a
few planned implementations, so it is clear we should look at how to
advance this work. At the same time I have a number of issues with the
text that I believe need to be fixed or discussed before we can do that.

Could you please work through the comments below and either produce a
revised document or let me know why I am wrong.

Thanks,
Adrian

===========

You will need to expand some acronyms on first use.
You need to expand them in the Abstract and in the main text even if
they are already expanded in the Abstract.
I see:
LSP
P2MP
OAM
PW
PE
P2P
VPMS
IPTV
FEC
LSR
LER

---

Section 2

All good except would be good to actually expand the acronyms rather
than just explaining them.

Perhaps also give a reference for mLDP.

---

Please read the comments on Sections 3.1 to 3.3, below, and then the
meta-comment that follows.

---

Section 3.1

I believe that the TicToc working group has agreed to change the status
of [I-D.ietf-tictoc-1588overmpls] to be Experimental because it only
describes an approach, and does not have consensus of the MPLS
community.

So I think you should

OLD
   [IEEE1588] over MPLS is defined in [I-D.ietf-tictoc-1588overmpls].
NEW
   [I-D.ietf-tictoc-1588overmpls] describes a possible approach to
   carry [IEEE1588] over an MPLS network.
END

I do believe this use case in as much as timing synchronization benefits
from the forward and reverse paths being identical.  I am less sure that
P2MP timing synchronization is a big requirement, but I am happy to
believe you if you say it is needed.

---

I think you need to do some rewriting in Section 3.2

[I-D.ietf-pwe3-p2mp-pw] expired over a year ago meaning that it has made
no progress for about 20 months. It appears to have been abandoned by
the WG. I think that part of the reason was that the solutions offered
provided too much complexity when the rend result could be achieved more
simply.

This leads to wonder whether your use case is making too many
assumptions.

You could possibly use draft-ietf-pwe3-p2mp-pw-requirements as your
reference, but to be honest with you, that I-D is not in a  good place
either having been sent back to the WG by its AD.

Similarly, [I-D.ietf-l2vpn-vpms-frmwk-requirements] expired more than
six months ago meaning it has made no progress for a year.

You could rewrite this section to establish the requirements in your
text rather than by reference, but IMHO, the best thing is to remove the
whole section.

---

As far as I can tell, section 3.3. does not provide a motivating use
case for this work. It is true that if you do have HSMP it would server
the purpose, but I do not believe that the IGMP messages or the channel
switch messages or whatever have to follow the reverse path of the P2MP
distribution tree.

This makes me think that you have two classes of use case (in the set of
two use cases that remain after the removal of section 3.2). The first
is the type of use case that motivates the invention of HSMP. The second
is the type of use case that shows that HSMP could also be used for
other things. Really, we need to separate these out to see whether there
is real motivation for this work.

Does this mean that the only reason for this work is time distribution
in a multicast network?

---

The comments on Sections 3.1 to 3.3, above, make me wonder about the
value of Section 3. What does it add to the document? Was it intended to
prove that there is a purpose to this work, or was it just trying to
show some ways that HSMP might be used?

If the latter, I recommend simply removing the whole section.

If the former, I think you have failed! :-(
If you *do* want show that there is value in the work (and I don't
believe you need to *if* people are coding/deploying this function) then
I suspect that the real motivation for this work is that it provides
MP2MP functionality with the simplicity of a single hub compared to the
multiple "distributed" hubs of MP2MP LSPs. If you feel the need to show
a purpose, then I think *this* is the topic you need to discuss in
Section 3.

---

Section 4

   HSMP LSP is similar with MP2MP LSP described in [RFC6388], with the
   difference that the leaf LSRs can only send traffic to root node
   along the same path of traffic from root node to leaf node.

This paragraph is very ambiguous.
Is it that the LSRs can only send *traffic*?
Is it that the LSRs can only send *to*the*root*?
Or is it that the LSRs can only send *along*the*same*path*

I think you need

   HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the
   difference that in HSMP, when the leaf LSRs send traffic on the LSP,
   the traffic is first delivered only to the root node and follows the
   reverse path of traffic sent from the root node to the leaf node. The
   root note then distributes the traffic on the P2MP tree to all of the
   leaf nodes.

---

Section 4

   The transmission of packets from the root node of an HSMP LSP
   to the receivers is identical to that of a P2MP LSP.  Traffic from a
   leaf node follows the upstream path toward the root node, along a
   path that traverse the same nodes as the downstream node, but in
   reverse order.

I believe this says that traffic is delivered back to the sender in all
cases. Is that the intent?

This makes for a significant difference between HSMP and MP2MP, doesn't
it? Shouldn't the document make this clearer?

---

Although Figure 1 shows the settings of the U and F bits, I think you
should mention them explicitly. This seems to be important because it
impacts what happens if there is an LSR in the path that does not
support HSMP.

---

Somewhat to my surprise, the use of the HSMP capability TLV is not
described anywhere. Reading between the lines in Section 4.1 I can see
that the new TLV is carried on the Initialization message. I can also
see that an implementation wishing to indicate it supports HSMP includes
the TLV and follow the procedures for indicating capabilities as defined
in RFC 5561.

But I don't find anything saying MUST NOT use HSMP FEC is peer does not
support HSMP.

I also don't understand what happens if I am tying to build an HSMP LSP
and discover that the next hop does not support HSMP. Can I have an
HSMP LSP with a hole in it? Does an LSR finding it cannot advance an
HSMP FEC fail any received HSMP LDP messages? Is there, in fact, an
assumption that all nodes that might be on an HSMP tree will support
HSMP?

I think you need to explain all this. You could look to RFC 6388 for
some suitable wording.

---

Throughout Section 4 the references to 6388 for process may be "obvious"
but are broken.

For example, in 4.3.1 you have

   Determining the upstream LSR for the HSMP LSP <X, Y> follows the
   procedure for a MP2MP LSP described in [RFC6388] Section 3.3.1.1.

But Section 3.3.1.1 of RFC 6388 says:

   Determining the upstream LDP peer U for an MP2MP LSP <X, Y> follows
   the procedure for a P2MP LSP described in Section 2.4.1.1.

This is a double indirection, so you should go direct to the source.

For example, later in 4.3.1 you have

   Determining one's HSMP downstream LSR follows the procedure defined
   in [RFC6388] section 3.3.1.2.

But Section 3.3.1.2 of RFC 6388 says

   An LDP peer U that receives an MP2MP-D Label Mapping from an LDP peer
   D will treat D as downstream MP2MP LSR.

which is not helpful in the context of this I-D.

I think the bottom line is that this document needs to be written to
desribe the processes that apply for these extensions.

Looking to the future, there is a strong case to be made that HSMP
might get more traction than MP2MP (since it provides the same user
service with a number of simplifications). If this turns out to be the
case, you do not want this document to need to lean on RFC 6388. It
should be independent. By all means reference 6388 for comparison, but
do not use it to define your processes.

---

I am unconvinced by Section 7. As I read the rest of the document, HSMP
has a high reliance on being able to produce a tree where the leaf-to-
root path is co-routed (in the opposite direction) with the root-to-leaf
path for each leaf. But I don't see anything in the document that
*makes* this happen.

Section 7 seems to expose that the document assumes that co-routing will
happen fortuitously. That is, when it doesn't occur, the network is 
requested to detect the fact and scream.

If the main purpose of HSMP is the co-routing, shouldn't this be
factored into the protocol? 

If detection and reporting of non-co-routed HSMP LSPs is so important,
shouldn't the protocol enable it? And maybe the LSP shouldn't even come
up?