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

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

The very next line from the one you quote says...

   In the following list of
   abbreviations, those that are usually (but not necessarily) treated as
   "well known" are marked with asterisks.

Thus, anything not marked with an asterisk in the list at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt may be regarded
as "not well known" and need expansion.

In particular, it is not only the reader that you need to worry about, but also
the RFC Editor. If you are asking that the RFC Editor should expand these
acronyms for you, they need to know what you intend the expansion to be and they
of, course, have no insight on the technology to guide them. The alternative to
the authors expanding the acronyms now is a series of email exchanges during the
edit process where the RFC Editor questions the authors about what they meant. 

There is also a risk here that the RFC Editor will use the wrong expansion and
it will be missed in Auth48. Perhaps the best example in the Routing Area is
"LSP". 

Cheers,
Adrian

> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]]
> Sent: 17 November 2013 21:47
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: AD review of draft-ietf-mpls-mldp-hsmp
> 
> 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]