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

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

Hi Lizhong,

[snip]

> > 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.
[snip]
> [Lizhong] I tend to remove section 3. The original purpose of section 3 is
> trying to show some use cases the HSMP LSP might be applied.

That approach would work for me.

[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.

[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.

[snip]

> > 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?
>
> [Lizhong] the intention of HSMP is to provide a leaf to root LSP path along
> the same node of downstream path. I tend to remove the co-routing word in the
> draft, and replace with the following description in section 7.
> 
> The co-routed path would be achieved for HSMP. Both LSR U and LSR D would
> ensure the same interface to send traffic by some procedures. For a network
> with symmetric IGP cost configuration, the following procedure MAY be used.
> To determine the downstream interface, LSR U MUST do a lookup in the unicast
> routing table to find the best interface and next-hop to reach LSR D. If the next-
> hop and interface are also advertised by LSR D via the LDP session, it can be
> used to transmit the packet to LSR D. Determine the upstream interface
> mechanism is same as determine downstream interface by exchanging the
> role of LSR U and LSR D.
>
> Static route table configuration on LSR U and D could also be a possible way
> to ensure co-routed path.
> 
> If co-routed is not required for HSMP LSP, LSR U is free to transmit the packet
> on any of the interfaces to LSR D, and vice versa.

This is somewhat better.

Thanks for the effort.

Adrian