Re: [mpls] FW: MPLS-RT rreview of draft-sitaraman-mpls-rsvp-shared-labels

[Vishnu Pavan Beeram <[e-mail]>]

{ plus MPLS WG }



> From: Vishnu Pavan Beeram <[e-mail]>
> Date: Sunday, October 1, 2017 at 5:06 PM
> To: Greg Mirsky <[e-mail]>, Loa Andersson <[e-mail]>
> Cc: "Rajiv Asati (rajiva)" <[e-mail]>, Stewart Bryant <
> [e-mail]>, Yimin Shen <[e-mail]>, "
> [e-mail]" <
> [e-mail]>
> Subject: Re: MPLS-RT rreview of draft-sitaraman-mpls-rsvp-shared-labels
>
>
> Greg, Hi!
>
> Thanks for the thorough review. Responses inline (prefixed VPB).
>
> Regards,
> -Pavan
>
> From: Greg Mirsky <[e-mail]>
> Date: Tuesday, September 26, 2017 at 3:44 PM
> To: Loa Andersson <[e-mail]>
> Cc: "Rajiv Asati (rajiva)" <[e-mail]>, Stewart Bryant <
> [e-mail]>, Yimin Shen <[e-mail]>, "
> [e-mail]" <
> [e-mail]>
> Subject: Re: MPLS-RT rreview of draft-sitaraman-mpls-rsvp-shared-labels
> Resent-From: <[e-mail]>
> Resent-To: Harish Sitaraman <[e-mail]>, Vishnu Pavan Beeram
> <[e-mail]>, <[e-mail]>, <[e-mail]>
> Resent-Date: Tuesday, September 26, 2017 at 3:44 PM
>
> Dear Authors, WG chairs, et.al
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__et.al&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=rGQH19azWZ6Vtu2iMbPcVSFLpuiaJiFK19CE4FIgACk&s=g81q4Dyv36xSCwQ6hOag_2YA76cqzrqJFHkTVB2k-ds&e=>,
>
> below please find my review of draft-sitaraman-mpls-rsvp-shared-labels-02:
>
>    - the document is very well written and it was pleasure to read it;
>    - I believe that the proposed "pop and forward" functionality is
>    useful;
>    - the proposed solution is technically sound.
>
> Hence my conclusion - the draft is ready for WG adoption.
>
> [VPB] Thanks!
>
> Taking this opportunity I'd like to share my comments but I don't consider
> any gating WG adoption:
>
>    - Introduction refers to labels with pop and forward functionality as
>    transit labels. Later in the draft, as I understand, such labels referred
>    to as 'pop labels'. Please consider establishing that these terms are used
>    interchangeably or using only 'pop label' term;
>
> [VPB] We'll make the usage consistent in the next revision.
>
>    - I think that in all examples it is assumed that the egress LER
>    advertises implicit NULL label. There's no need to change examples but it
>    may be helpful to clarify use of the implicit NULL label by the egress LER;
>
> [VPB] The procedures discussed in the draft do not change based on the
> type of the label used by the egress LER. We can add a statement to clarify
> this.
>
>    - the draft introduces Effective Transport Label-Stack Depth (ETLD)
>    parameter. On the other hand, in Sectio 4 of Entropy Label for SPRING
>    Tunnels
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dmpls-2Dspring-2Dentropy-2Dlabel-2D06&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=rGQH19azWZ6Vtu2iMbPcVSFLpuiaJiFK19CE4FIgACk&s=JSKK4zTW11k75iLyn3n5T99U0NGSRnMGyg3tCHD6jx4&e=> introduced
>    Entropy Readable Label Depth/Readable Label Depth. Could it be that these
>    are the same? That only one parameter is sufficient?
>
> [VPB] ETLD is different from RLD (Readable Label Depth) or MSD (Maximum
> SID Depth). ETLD is the maximum number of transport labels that a given
> node can potentially send to its downstream hop relative to its position in
> a given delegation segment. As noted in the draft, the ingress or the
> delegation hop starts with an appropriate value. This value is then
> decremented/adjusted at each successive hop. If a node is reached where the
> ETLD set from the previous hop is 1, then that node selects  itself as the
> delegation hop.
>
> [VPB] A node can take both RLD and MSD into account before adjusting the
> ETLD. For example, if a node can read only 4 labels (read–limit) in the
> stack, then the ETLD on this node can be adjusted in such a way that the
> upstream node will never send more than 4 labels. Similarly if a node can
> push only 3 labels, then the ETLD on this node is adjusted in such a way
> that the node has to never push more than 3 labels.
>
>    - section 8.1 I think it will be helpful to provide information on
>    what the label stack looks when a packet arrives at node F;
>
> [VPB] With link-protection, the real node of interest is the merge-point
> (Node C in the example) and the focus of the current text is to highlight
> how the packet makes it to C (after the label gets popped at the PLR).  If
> the link-protecting bypass goes from B to C via F and G, then F is merely a
> transit node along the bypass path.
>
>    - extensions proposed in section Protocol Extensions will be easier to
>    understand and evaluate if these refer to figures.
>
> [VPB] Ok.
>
> Regards,
> Greg
>
> On Fri, Sep 15, 2017 at 2:47 AM, Loa Andersson <[e-mail]> wrote:
>
>> Greg, Rajiv, Stewart, Yimin
>>
>> You have been selected as MPLS-RT reviewers for
>> draft-sitaraman-mpls-rsvp-shared-labels-02.
>>
>> 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). Please remember that it often is
>> easier to progress the document when it has become a working group
>> document. All comments in the MPLS-RT review needs to be addressed,
>> but please think carefully about whether a comment is gating the
>> adoption or could just as easily be addressed after the adoption.
>>
>> 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.
>>
>> If you have technical comments you should try to be explicit about what
>> needs to be resolved before adopting it as a working group document, and
>> what can wait until the document is a working group document and the
>> working group has the revision control.
>>
>> Are you able to review this draft by August 29, 2017? Please respond
>> whether you are available to do the review in a timely fashion.
>>
>>
>> Thanks, Loa
>> (as MPLS WG co-chair)
>> --
>>
>>
>> Loa Andersson                        email: [e-mail]
>> Senior MPLS Expert                          [e-mail]
>> Huawei Technologies (consultant)     phone: [phone]
>>
>
>