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

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

Hi Adrian,
I have uploaded the new version: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mldp-hsmp-04.txt
Please check if all of your comments are resolved. Thank you.

Regards
Lizhong


> -----Original Message-----
> From: Lizhong Jin [mailto:[e-mail]]
> Sent: Monday, November 25, 2013 11:03 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: AD review of draft-ietf-mpls-mldp-hsmp
> 
> 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.