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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 17 Nov 2013 20:23:48 -0000

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?

---

From: Loa Andersson <[email-masked]>
Date: Sun, 17 Nov 2013 16:47:09 -0500

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

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 17 Nov 2013 22:16:19 -0000

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:[email-masked]]
> Sent: 17 November 2013 21:47
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: AD review of draft-ietf-mpls-mldp-hsmp
> 
> Adrian,
>

---

From: Loa Andersson <[email-masked]>
Date: Mon, 18 Nov 2013 10:11:23 -0500

Adrian,

OK - that is pretty clear;
- expand acronyms when they first appear in the document
- if they are in the MPLS RFC Editors acronym list with an
   asterisk we might consider the acronym

The only problem we have now is that this is not how the
working group has reviewed the last 100 RFC, what we have
done is to look at the acronym list we have not required
expansion of acronyms other than in special cases.

Hope we don't need to roll back and re-review :).

/Loa

--

---

From: "Lizhong Jin" <[email-masked]>
Date: Thu, 21 Nov 2013 00:26:04 +0800

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

Regards
Lizhong

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, November 18, 2013 4:24 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: AD review of draft-ietf-mpls-mldp-hsmp
> 
> Hi,
> 
[Lizhong] OK, will expand the acronyms.

> Perhaps also give a reference for mLDP.
[Lizhong] OK, will expand the acronyms.

> a purpose, then I think *this* is the topic you need to discuss in
[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. 

>    root note then distributes the traffic on the P2MP tree to all of
[Lizhong] accepted, thanks.

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

> impacts what happens if there is an LSR in the path that does not
[Lizhong] OK, will add explicit description.

> I think you need to explain all this. You could look to RFC 6388 for
[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).

> do not use it to define your processes.
[Lizhong] OK, thanks. I will rephrase these sections in the updated version.

> shouldn't the protocol enable it? And maybe the LSP shouldn't even come
[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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 24 Nov 2013 14:54:41 -0000

Hi Lizhong,

[snip]

> > 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
[snip]
> trying to show some use cases the HSMP LSP might be applied.

That approach would work for me.

[snip]

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

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

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]

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

This is somewhat better.

Thanks for the effort.

Adrian

---

From: "Lizhong Jin" <[email-masked]>
Date: Mon, 25 Nov 2013 11:03:12 +0800

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]

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

[Lizhong] Accepted. Thanks.

[snip]

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

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

---

From: "Lizhong Jin" <[email-masked]>
Date: Wed, 27 Nov 2013 00:14:37 +0800

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

> From: Lizhong Jin [mailto:[email-masked]]
> Sent: Monday, November 25, 2013 11:03 AM
> 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
> > >
> 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).
> 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.
> 
> 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.
> 
> 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?
> 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:
> 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.
> 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.