Re: [mpls] Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping

["Nobo Akiya (nobo)" <[e-mail]>]

Hi Sri,

Thank you for comments.

> Hello authors,
> 
> The draft is reasonably coherent. It addresses a useful problem.
> Technically it is a start. The document is ready to be considered for WG
> adoption.
> 
> A few comments -
> 
> 
> 1. sec 8. DSMAP is deprecated. Should be removed. Even though "Multipath
> Info" field was in DSMAP too, since a more recent RFC has deprecated it, it
> should no longer be used. Some implementations referring to DSMAP is not
> a reason to continue using if the intention is to get to a proposed standard.

I see. I will speak to few people and if this is indeed the case, I will remove DSMAP from document (either next revision or later revision).

> 
> 2. The notation {x, y, z} is introduced in section 2, without mentioning what
> it means. I am assuming it means one-of. Should be stated clearly.

Good point. I will add a description on this notion.

> 
> 3. sec 9 bullet 1 - If the transit node encounters a deep label stack, it may
> not be able to access labels till the bottom of stack to compute the hash. If
> this is the case, "Depth Limit" should take care of this. It is not clear what
> this unsupported-case is and why it should occur.

Yes "Depth Limit" can communicate something. One question is, is this top N labels or bottom M labels? Either way, if Flow Label or Entropy Label is not included in this "Depth Limit", then initiator LSP cannot make changes to the label stack to traverse all ECMP paths at this point.

> 
> 4. sec 9. bullet 2 - Is this case when the transit node is using other labels in
> the label stack "in addition to the EL" OR is it when the transit node is using
> a non-EL label in the stack even if EL is included ?
> The former case is typical. The latter case I would imagine can occur if the
> transit LSR cannot access the entire label stack depth. Again not clear what
> the unsupported case is.

I will rewrite this entire section on what is and isn't supported. Hopefully next revision will be more clearer.

> 
> 5. Does the draft make a distinction between the two cases allowed by
> RFC6790, namely -
> 
>     a. Load balance solely on the EL
> 
>     b. Use as-much of the label-stack as feasible

This will be covered with section 9 rewrite.

> 
> 6. The "Associated Label Multipath Information" field should be better
> explained. I would suggest a separate section to improve the coherency.

I believe this is well described in section 8. Please let me know if you think it is still insufficient.

Thanks again!

-Nobo

> 
> 
> 
> Thanks
> 
> Sri
> 
> On 1/3/14 12:22 AM, "Loa Andersson" <[e-mail]> wrote:
> 
> >Folks,
> >
> >This was the wrong document - I intended to have the review done for
> >draft-akiya-mpls-entropy-lsp-ping sorry for the confusion.
> >
> >All other cordinates correct!
> >
> >On 2014-01-03 14:44, Loa Andersson wrote:
> >> Sri, Xiaohu, Curtis and Dan,
> >>
> >> You have been selected as MPLS Review team reviewers for
> >> draft-akiya-mpls-entropy-lsp-ping-01.
> >>
> >> Note to authors: You have been CC'd on this email so that you can
> >> know that this review is going on. However, please do not review your
> >> own document.
> >>
> >> Reviews should comment on whether the document is coherent, is it
> >> useful (ie, is it likely to be actually useful in operational
> >> networks), and is the document technically sound?  We are interested
> >> in knowing whether the document is ready to be considered for WG
> >> adoption (ie, it doesn't have to be perfect at this point, but should
> >> be a good start).
> >>
> >> Reviews should be sent to the document authors, WG co-chairs and WG
> >> secretary, and CC'd to the MPLS WG email list. If necessary, comments
> >> may be sent privately to only the WG chairs.
> >>
> >> Are you able to review this draft by January 20, 2014?
> >>
> >> Thanks, Loa
> >> (as MPLS WG chair)
> >
> >--
> >
> >
> >Loa Andersson                        email: [e-mail]
> >Senior MPLS Expert                          [e-mail]
> >Huawei Technologies (consultant)     phone: [phone]
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls