Subject: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use

From: Mach Chen <[email-masked]>
Date: Mon, 21 Jan 2013 10:03:59 +0000

Hi,

I was selected as an MPLS-RT team reviewer for draft-villamizar-mpls-multipath-use.

I read the draft and think it is a useful draft that discusses a real issue. I think that this draft is ready to be considered for WG adoption. At same time, the draft also needs more work to make it more clear, especially for Section 3. 

Here are my comments:

1. Section 3, 
The 1th para after the 4 requirements, this para talks how to satisfy MP#1, but at the end of this para, it starts to talk about Entropy label but with limited text. Not sure the entropy label is an alternative solution to satisfy MP#1 or entropy label is an alternative idea to make sure the MPLS-TP payload and OAM packets have the same path. I guess it's later. So, I'd suggest to remove the last sentence or move it the 3rd para after the 4 requirements. 

2. I am not sure why MP#3 is a requirement, the result should be no different from the situation where a component link is failed and the MPLS-TP LSP is then moved to other links, a potential temp "out of order" may occur and IMHO this is acceptable. 

In addition, there are some nits like redundant/missing words, for example: the abstract Section: s/MPLS can LSP can/MPLS LSP can

Best regards,
Mach

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 22 Jan 2013 23:05:38 -0500

In message <[email-masked]>
Mach Chen writes:
> I read the draft and think it is a useful draft that discusses a real
> issue. I think that this draft is ready to be considered for WG
> adoption. At same time, the draft also needs more work to make it more
> clear, especially for Section 3.

Three for three on Section 3 needs clarity.

> Here are my comments:
>  
> 1. Section 3, 
>  
>    The 1th para after the 4 requirements, this para talks how to
>    satisfy MP#1, but at the end of this para, it starts to talk about
>    Entropy label but with limited text. Not sure the entropy label is
>    an alternative solution to satisfy MP#1 or entropy label is an
>    alternative idea to make sure the MPLS-TP payload and OAM packets
>    have the same path. I guess it's later. So, I'd suggest to remove
>    the last sentence or move it the 3rd para after the 4 requirements.

In response to Carlos I suggested that MP#1 be made more clear by
adding a phrase.

   MP#1  It MUST be possible to identify MPLS-TP LSP or otherwise
         accommodate the MPLS-TP LSP requirement to avoid reordering
         of packets.

The last sentence you refer to identifies a means to "otherwise
accommodate the MPLS-TP LSP requirement to avoid reordering of
packets".  That could be made more clear by making the sentence into a
separate paragraph that explains this.

> 2. I am not sure why MP#3 is a requirement, the result should be no
>    different from the situation where a component link is failed and
>    the MPLS-TP LSP is then moved to other links, a potential temp "out
>    of order" may occur and IMHO this is acceptable.

The wording on MP#2 and MP#3 could be more clear.  The intent is that
MP#2 indicates that an equivalent to MPLS Link Bundling "pinning"
should be available.  The intent of MP#3 is to indicate that it should
be possible to signal LSP that are only moved if the component can no
longer be used (component link down, etc).

As Carlos pointed out, the most obvious requirement is not explicitly
mentioned in the bullet list, but only in the text, and that is the
requirement that MPLS-TP traffic not get reordered as per RFC 5960
"MUST NOT use ECMP" (paraphrased).

> In addition, there are some nits like redundant/missing words, for
> example: the abstract Section: s/MPLS can LSP can/MPLS LSP can

Thanks.  Got that one.  Please point out any other that you notice.

> Mach

Thank you for your review and comments.

Best regards,
Curtis