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

["Lizhong Jin" <[e-mail]>]

Hi Adrian,
Thank you for the review. See inline for the reply. I will upload a new version soon to reflect all the review comments.

Regards
Lizhong


[snip]

> > 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?
>
> [Lizhong] How about the below:
> 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, and would not be 
> sent to any other leaf nodes. The upstream path is the reverse path of 
> traffic sent from the root node to the leaf node.

OK. I see the confusion.
Your text is making the distinction that traffic traveling upstream to the root does so in a P2P fashion and is not branched to any other leaf (as it would be in mp2mp).
That is a good point to make clear.

My question was about how traffic is distributed from the root back to the leaf nodes. I believe that this use a single P2MP tree to distribute traffic to all of the leaf nodes regardless of which leaf originated the traffic. That is, there are not n distinct trees each containing (n-1) nodes. Thus, it seems to me that the sender will receive a copy of every packet that it sends to the root.

If I am correct, and to include your point, I suggest the following paragraph.

The transmission of packets from the root node of an HSMP LSP to the receivers (the leaf nodes) is identical to that of a P2MP LSP. Traffic from a leaf node to the root follows the upstream path that is the reverse of the path from the root to the leaf. Unlike an MP2MP LSP, traffic from a leaf node does not branch toward other leaf nodes, but is sent direct to the root where it is placed on the P2MP path and distributed to all leaf nodes including the original sender.

[Lizhong] Accepted. Thanks.

[snip]

> > 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 if 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.
>
> [Lizhong] How about to add the following:
>
> If the peer has not advertised the corresponding capability, then 
> label messages using the HSMP FEC Element SHOULD NOT be sent to the 
> peer. In that case, the HSMP LSP has not been completely established, 
> and leaf node is unable to send any traffic to root node (see section 4.3.1 for detail).

Yes, but doesn't this mean that the root and some leaf nodes may think that the LSP is more complete than it actually is?
Maybe the DoD procedures mean that the root has knowledge of which leaf nodes are fully attached?
Perhaps this is all explained in the I-D and I can't remember it now, or perhaps there are some unspoken assumptions about how many nodes support these procedures and how LSPs get established.

[Lizhong] ordered mode is used for the upstream path, and it is described in section 4:
  For setting up the upstream path of an HSMP LSP, ordered mode MUST be
   used which is same as MP2MP.  Ordered mode can guarantee a leaf to
   start sending packets to root immediately after the upstream path is
   installed, without being dropped due to an incomplete LSP.
Then if one node does not support HSMP, the Label Mapping with upstream FEC element
will not be received by leaf node, and the leaf node is unable to establish the upstream path.
I change the description as follows, to make it more clear.

If the peer has not advertised the corresponding capability, then 
label messages using the HSMP FEC Element SHOULD NOT be sent to the 
peer. Since ordered mode (see section 4.3.1 for detail) is applied for HSMP LSP signaling, 
the label message break would ensure that the initiating leaf node is unable to establish the 
upstream path.