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

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sun, 1 Oct 2017 17:08:46 -0400

Yimin, Hi!

Thanks for the review. We'll address the editorial nits mentioned below in
the next rev.

Regards,
-Pavan

On Thu, Sep 28, 2017 at 10:47 AM, Yimin Shen <[email-masked]> wrote:

> Dear Authors, WG Chairs, and colleagues,
>
> I was selected as an MPLS-RT reviewer for draft-sitaraman-mpls-rsvp-shared-labels-02.
> I’ve now completed my review with the following consideration.
>
> - The draft targets on decoupling RSVP protocol state from MPLS forwarding
> plane state, which is a well-known challenge in today’s scaling MPLS
> networks.
> - It introduces the “pop-and-forward” paradigm to RSVP LSPs to take
> advantage of the simplicity of the segment routing MPLS forwarding plane,
> which is an elegant and generic solution.
> - It is well written in a coherent manner.
>
> Therefore, I support this draft to be adopted as a WG document.
>
> Besides that, I do have a few of other comments, and hope they can be
> addressed while the draft is progressing. However, these comments should
> not be considered as gating the adoption.
>
> [1] In some places in sections 3 and 10, “SHOULD” may be replaced by
> “MUST”.
>
> Example: An LSR SHOULD allocate a unique pop label for each TE link.
>
> [2] The mechanism seems to apply to P2P LSP signaling only. It would be
> good if the draft can clarify that P2MP LSP signaling is out of scope or
> for future study.
>
> [3] Delegation hop and delegation label.
>
> It is worth clarifying in the draft that the cases of Figure-3 (i.e. Stack
> to Reach Delegation Hop) and Figure-4 (Stack to Reach Egress) may co-exist
> for a given delegation hop D. For example, LSP-1 may be signaled with the
> LSI-D-S2E flag, while LSP-2 (which also traverse from D to L) may be
> signaled without the LSI-D-S2E flag. D will need to allocate two distinct
> delegation labels to serve the two LSPs. This will help make this part
> easier to understand.
>
> Regards,
>
> -- Yimin Shen
> Juniper Networks
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 2 Oct 2017 06:59:16 -0700

And now with MPLS WG included.

Regards,
Greg

On Tue, Sep 26, 2017 at 12:44 PM, Greg Mirsky <[email-masked]> wrote:

> Dear Authors, WG chairs, et.al,
> 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.
>
> 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;
>    - 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;
>    - the draft introduces Effective Transport Label-Stack Depth (ETLD)
>    parameter. On the other hand, in Sectio 4 of Entropy Label for SPRING
>    Tunnels
>    <https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-06> introduced
>    Entropy Readable Label Depth/Readable Label Depth. Could it be that these
>    are the same? That only one parameter is sufficient?
>    - 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;
>    - extensions proposed in section Protocol Extensions will be easier to
>    understand and evaluate if these refer to figures.
>
> Regards,
> Greg
>
> On Fri, Sep 15, 2017 at 2:47 AM, Loa Andersson <[email-masked]> 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: [email-masked]
>> Senior MPLS Expert                          [email-masked]
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>
>
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 2 Oct 2017 11:08:29 -0400

{ plus MPLS WG }

> From: Vishnu Pavan Beeram <[email-masked]>
> Date: Sunday, October 1, 2017 at 5:06 PM
> To: Greg Mirsky <[email-masked]>, Loa Andersson <[email-masked]>
> Cc: "Rajiv Asati (rajiva)" <[email-masked]>, Stewart Bryant <
> [email-masked]>, Yimin Shen <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> 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 <[email-masked]>
> Date: Tuesday, September 26, 2017 at 3:44 PM
> To: Loa Andersson <[email-masked]>
> Cc: "Rajiv Asati (rajiva)" <[email-masked]>, Stewart Bryant <
> [email-masked]>, Yimin Shen <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> Subject: Re: MPLS-RT rreview of draft-sitaraman-mpls-rsvp-shared-labels
> Resent-From: <[email-masked]>
> Resent-To: Harish Sitaraman <[email-masked]>, Vishnu Pavan Beeram
> <[email-masked]>, <[email-masked]>, <[email-masked]>
> 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=>,
>
> [VPB] Thanks!
> [VPB] We'll make the usage consistent in the next revision.
>
> [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.
>
>    <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
> [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.
>
> [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.
>
> [VPB] Ok.