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

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

Hi Adrian,
Thank you for the AD review. Please see my reply inline below.

Regards
Lizhong


> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Monday, November 18, 2013 4:24 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: AD review of draft-ietf-mpls-mldp-hsmp
> 
> 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
[Lizhong] OK, will expand the acronyms.

> 
> ---
> 
> 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.
[Lizhong] OK, will expand the acronyms.

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

> 
> ---
> 
> 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.
[Lizhong] accepted, thanks.

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

> 
> ---
> 
> 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.
[Lizhong] OK, will add explicit description.

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

> 
> ---
> 
> 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.
[Lizhong] OK, thanks. I will rephrase these sections in the updated version.

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

Thanks
Lizhong