Re: [mpls] I-D Action: draft-ietf-mpls-rsvp-shared-labels-01.txt

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

All the examples in this document assume that the egress LER uses an
implicit null label (because that is the typical default behavior in most
implementations).

Regards,
-Pavan

On Mon, Mar 5, 2018 at 4:42 PM, Alexander Okonnikov <
[e-mail]> wrote:

> Oh, thanks. May be it would make sense to point that tail-end in the
> example allocates implicit null label?
>
> Best regards,
> Alexander Okonnikov
>
> 6 марта 2018 г., 0:27 +0300, Vishnu Pavan Beeram <[e-mail]>,
> писал:
>
> Alexander, Hi!
>
> No, the understanding isn't correct. There is no "packet drop" here.
>
> Note that when the ingress receives the RRO in the Resv (as part of the
> initial signaling sequence), it becomes aware not only of all the
> nodes/links traversed by the LSP, but also of the label and the type of
> label assigned to the LSP at each hop. So for your example (where only C
> uses a regular label), using the logic explained in Section 7 (Construction
> of Label Stacks), the ingress would construct the following label stack  --
> {150, 200, 850}. When C receives the packet with top-label 200, it would
> swap it to 250 and forward it to D. When D receives the packet with
> top-label 250, it would pop the label and forward it to E. And when E
> receives the packet with top-label 850, it would pop the label and forward
> it to I.
>
> The logic for "Construction of Label Stacks" is explained in detail in
> section 7.
>
> Regards,
> -Pavan
>
>
>
> On Mon, Mar 5, 2018 at 3:48 PM, Alexander Okonnikov <
> [e-mail]> wrote:
>
>> Hi Pavan,
>>
>> Thank you for answer. I have one more question regarding mixing TE and
>> regular labels. Let’s assume that in the Figure 6 only router C uses
>> regular label, and routers B, D, E, and I use TE labels. Per example,
>> router A will push stack {150, 200}. When router C receives packet with top
>> label 200, it swaps it to 250, which is TE label, allocated by D. Router D
>> pops label 250, the packet becomes unlabeled and dropped by router E. Is my
>> understanding correct?
>>
>> Best regards,
>> Alexander Okonnikov
>>
>> 5 марта 2018 г., 23:22 +0300, Vishnu Pavan Beeram <[e-mail]>,
>> писал:
>>
>> Alexander, Hi!
>>
>> Please see inline (prefixed VPB).
>>
>> Regards,
>> -Pavan
>>
>> On Mon, Mar 5, 2018 at 10:44 AM, Alexander Okonnikov <
>> [e-mail]> wrote:
>>
>>> Hi authors,
>>>
>>>
>>> I sent comments (27.12.2017, cited below) regarding version -00 of the
>>> draft, but have not received answers. Could you please provide some
>>> explanations?
>>>
>>>
>> [VPB] I apologize for not responding to this earlier. Please see below
>> for responses.
>>
>>
>>>
>>> "The draft highlights benefits of proposed solution, but doesn't mention
>>> drawbacks. For example, in case of regular RSVP-TE LSP transit LSRs are
>>> able to perform conditioning of traffic of individual RSVP-TE LSP,
>>> thankfully to unique ingress labels of LSPs. I.e. for regular RSVP-TE LSPs
>>> incoming label is not only key for seeking ILM entry, but (optionally) is
>>> input for classifier as well.
>>>
>>
>> [VPB] The draft doesn’t hide the fact that a Segment Routing MPLS
>> forwarding plane is being used here. “Loss of granularity at the transit"
>> is a trade-off that is associated with using such a forwarding plane.
>>
>>
>>> Also, the draft points, as one of benefits, hitless re-routing nature.
>>> Regular RSVP-TE LSPs are also could be re-routed in hitless manner. RFC
>>> 3209 says that if two LSPs have the same ERO, common label can be assigned
>>> for them. So, this benefit is questionable."
>>>
>>>
>> [VPB] There is a subtle difference between what RFC3209 says and what is
>> currently being discussed in this draft. The statement in RFC3209 proposes
>> an optional reroute behavior for conventional RSVP-TE LSPs. There was an
>> attempt sometime back to make this ("reusing labels during MBB") a
>> best-practice (draft-dai-mpls-rsvp-te-mbb-label-reuse), but that draft
>> didn’t go too far. There are still implementations out there that don’t
>> reuse “labels” during MBB. With the functionality introduced by this
>> current draft, the “the common label" behavior is inherent — there is
>> nothing optional about it and that is what the draft is trying to highlight.
>>
>>
>>>
>>> As I understand, due to specifics of the solution node protection cannot
>>> be provided as well, which is one more drawback of the solution.
>>>
>>>
>> [VPB] This isn’t a drawback. As mentioned in a separate cover to the WG,
>> the solution for node protection would be published separately (involves a
>> bit too much detail to put into a WG document at this point).
>>
>>
>>>
>>> Thank you in advance.
>>>
>>>
>>> 05.03.2018 18:24, [e-mail] пишет:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>> This draft is a work item of the Multiprotocol Label Switching WG of
>>>> the IETF.
>>>>
>>>>          Title           : Signaling RSVP-TE tunnels on a shared MPLS
>>>> forwarding plane
>>>>          Authors         : Harish Sitaraman
>>>>                            Vishnu Pavan Beeram
>>>>                            Tejal Parikh
>>>>                            Tarek Saad
>>>>         Filename        : draft-ietf-mpls-rsvp-shared-labels-01.txt
>>>>         Pages           : 21
>>>>         Date            : 2018-03-05
>>>>
>>>> Abstract:
>>>>     As the scale of MPLS RSVP-TE networks has grown, so the number of
>>>>     Label Switched Paths (LSPs) supported by individual network elements
>>>>     has increased.  Various implementation recommendations have been
>>>>     proposed to manage the resulting increase in control plane state.
>>>>
>>>>     However, those changes have had no effect on the number of labels
>>>>     that a transit Label Switching Router (LSR) has to support in the
>>>>     forwarding plane.  That number is governed by the number of LSPs
>>>>     transiting or terminated at the LSR and is directly related to the
>>>>     total LSP state in the control plane.
>>>>
>>>>     This document defines a mechanism to prevent the maximum size of the
>>>>     label space limit on an LSR from being a constraint to control plane
>>>>     scaling on that node.  That is, it allows many more LSPs to be
>>>>     supported than there are forwarding plane labels available.
>>>>
>>>>     This work introduces the notion of pre-installed 'per Traffic
>>>>     Engineering (TE) link labels' that can be shared by MPLS RSVP-TE
>>>> LSPs
>>>>     that traverse these TE links.  This approach significantly reduces
>>>>     the forwarding plane state required to support a large number of
>>>>     LSPs.  This couples the feature benefits of the RSVP-TE control
>>>> plane
>>>>     with the simplicity of the Segment Routing MPLS forwarding plane.
>>>>
>>>>     This document also introduces the ability to mix different types of
>>>>     label operations along the path of an LSP, thereby allowing the
>>>>     ingress router or an external controller to influence how to
>>>>     optimally place a LSP in the network.
>>>>
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-shared-labels/
>>>>
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-mpls-rsvp-shared-labels-01
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-mpls-rsvp-s
>>>> hared-labels-01
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rsvp-shared-labels-01
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> mpls mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>
>>
>