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

[Loa Andersson <[e-mail]>]

Adrian,

I understand the latter part of the comments, but I'm confused about
the requirement that the (most of) acronyms should be expanded; almost
all of the are in the RFC Editor acronym list. The RFC Editor says:

"Some abbreviations are so well known that expansion is probably
  unnecessary.  The RFC Editor exercises editorial judgment about whether
  a particular use of one of the "well-known" abbreviations requires
  expansion."

That is why I left then unexpanded during my review, and since the
RFC-Editor promise to use " editorial judgment" I think we can leave it
at that.

/Loa

On 2013-11-17 15:23, Adrian Farrel wrote:
> 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?
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]