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

Vishnu Pavan Beeram <vishnupavan@gmail.com> Mon, 05 March 2018 21:27 UTC

Return-Path: <vishnupavan@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2285A12E03D for <mpls@ietfa.amsl.com>; Mon, 5 Mar 2018 13:27:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnVtjpv8zQAX for <mpls@ietfa.amsl.com>; Mon, 5 Mar 2018 13:27:35 -0800 (PST)
Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D74F12E89C for <mpls@ietf.org>; Mon, 5 Mar 2018 13:27:35 -0800 (PST)
Received: by mail-pg0-x231.google.com with SMTP id q27so7375536pgn.8 for <mpls@ietf.org>; Mon, 05 Mar 2018 13:27:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MYS9eZgHeGpnDCMSFOdoXaD4SdLdYd+mw+rL/hZnZ7Q=; b=PXmqjQV+QhNHmAQUfLHwOHXmQH4VuVsB8EBxR/G+JrHYZMS/tkbPoPAiwiXcx0IFo8 Krb95Pm5u7xIqmK3l23s3nBbmARRf2irK4xQhTJzG8HCOT3WoqsojIa9GmGO1D7kQxcK W0fBNaMztgaVlq8Wj8iLiCVIJ0/v+HnvfJ7QgQ3GKQUGwVL2dkp18965p+UuIU0suJF9 MDgBK7JJPzzWgiZck94NaeWmsRE61U9Lj21SSPHT/oaSPGKi0B4EL4zatZBP2We0Y9iK 5Mj9MO27gtWBPR2miB4kf+u0QImWogqlejVdb0rd1BsalUSDjtA8h8QAPR6DeRpgMWrj aLQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MYS9eZgHeGpnDCMSFOdoXaD4SdLdYd+mw+rL/hZnZ7Q=; b=NPaVuFycGOEZy9wzyLUInFi5T4QaU08QV3U+J79j7rN05yNhhR6PSG4Nc+oOMvA8nm 77oA/NDGuGBz+JE9fCBYxjErDJPhaMahUqTvCUVkdFCH0+QDnr3pk2FtseqXq6qM2+0H CAGkywoCGpElfUngdKblwHPfiuueXNqE8AmCypFkmRo2Why/qjyp6Z6SKmMNKColfqxK rQZq7mgtirkK2iBYKje1CdXoI1Ueasv5ga163YmLKGDHXLzxoLQZ+o/+uiGwLvbNaEZJ LGfFOEGTXkHBjQ3DeMkz199XkQm/fDeGdSGbXVkI8Gzin8WC/v4iXQzwhCNyiP2/fWYY KK6g==
X-Gm-Message-State: APf1xPA+zQQNqGKbjBLbjYFjNYdForxIg8razIWNkz0e+TQMJOIpgL4Z TMJdCx8Hfz/BTgComL7ryPCxhp7ufsHszXjgNTI=
X-Google-Smtp-Source: AG47ELuqlE4lSHFrrId2D924NIlb3F8OE2EZEekaq/alMhFzOSN17qiS9IaLOBnxb40yJqvzwx4akXo1Ioan2KX+dPc=
X-Received: by 10.98.25.10 with SMTP id 10mr16423058pfz.136.1520285254924; Mon, 05 Mar 2018 13:27:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.160.6 with HTTP; Mon, 5 Mar 2018 13:27:34 -0800 (PST)
In-Reply-To: <389424dc-2ba7-4311-bacf-e529c7c95c1f@Spark>
References: <152026346867.14551.6193421201216277447@ietfa.amsl.com> <bb34914d-f6fe-02b2-2aa1-9e844bee4de6@gmail.com> <CA+YzgTuRB6L+FD2L_n7tHiSUVs1-zWo6iv6LhBzQkyKEhraNCg@mail.gmail.com> <389424dc-2ba7-4311-bacf-e529c7c95c1f@Spark>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Mon, 05 Mar 2018 16:27:34 -0500
Message-ID: <CA+YzgTsiKnUH97BkWn8CTSf3N6-EkPF4sq_X6PxCo1mGZT5d_g@mail.gmail.com>
To: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Cc: IETF MPLS List <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c047aae93be870566b0fe74"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/PchQfouaUXgI8tz-mP-phkbxiJw>
Subject: Re: [mpls] I-D Action: draft-ietf-mpls-rsvp-shared-labels-01.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2018 21:27:47 -0000

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 <
alexander.okonnikov@gmail.com> 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 <vishnupavan@gmail.com>,
> писал:
>
> Alexander, Hi!
>
> Please see inline (prefixed VPB).
>
> Regards,
> -Pavan
>
> On Mon, Mar 5, 2018 at 10:44 AM, Alexander Okonnikov <
> alexander.okonnikov@gmail.com> 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, internet-drafts@ietf.org пишет:
>>
>> 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
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>
>