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

[Alexander Okonnikov <[e-mail]>]

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-shared-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
> > > >
>