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

From: [email-masked]
Date: Mon, 05 Mar 2018 07:24:28 -0800

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/

---

From: Alexander Okonnikov <[email-masked]>
Date: Mon, 5 Mar 2018 18:44:27 +0300

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?

"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.

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."

As I understand, due to specifics of the solution node protection cannot 
be provided as well, which is one more drawback of the solution.

Thank you in advance.

05.03.2018 18:24, [email-masked] пишет:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 5 Mar 2018 15:13:21 -0500

WG,

We just posted a new revision (-01) for this draft. The changes are mostly
editorial:

(1) IANA section: We added a couple of code-point requests for PathErr
(Code-24) error-values.

(2) Node-protection: The authors have put together a solution for
node-protection. Since the topic is a bit involved, the authors would like
to initiate the discussion on this via a separate draft (the individual
draft should be published in the coming weeks). We made a few edits to the
WG draft to reflect this.

We would like to request the WG to review the edits (Diffs:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rsvp-shared-labels-01)
and let us know if you have any comments or concerns.

Regards,
- Pavan (on behalf of the authors)

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Mar 5, 2018 at 10:24 AM
Subject: [mpls] I-D Action: draft-ietf-mpls-rsvp-shared-labels-01.txt
To: [email-masked]
Cc: [email-masked]

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:

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 5 Mar 2018 15:22:20 -0500

Alexander, Hi!

Please see inline (prefixed VPB).

Regards,
-Pavan

> draft, but have not received answers. Could you please provide some
[VPB] I apologize for not responding to this earlier. Please see below for
responses.

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

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

> 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).

---

From: Alexander Okonnikov <[email-masked]>
Date: Mon, 5 Mar 2018 23:48:51 +0300

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 <[email-masked]>, писал:
> > On Mon, Mar 5, 2018 at 10:44 AM, Alexander Okonnikov <[email-masked]> 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.
> > >
> > >

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 5 Mar 2018 16:27:34 -0500

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 <
[email-masked]> 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
>

---

From: Alexander Okonnikov <[email-masked]>
Date: Tue, 6 Mar 2018 00:42:08 +0300

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 <[email-masked]>, писал:
> 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 <[email-masked]> wrote:
> > > Hi Pavan,
> > >

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 5 Mar 2018 17:14:07 -0500

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