Re: [mpls] Requesting WG LC for draft-ietf-mpls-rsvp-shared-labels

Vishnu Pavan Beeram <vishnupavan@gmail.com> Thu, 27 September 2018 08:30 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 429A1130E6F for <mpls@ietfa.amsl.com>; Thu, 27 Sep 2018 01:30:59 -0700 (PDT)
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 wDEffDVPM_6v for <mpls@ietfa.amsl.com>; Thu, 27 Sep 2018 01:30:55 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 62033130E13 for <mpls@ietf.org>; Thu, 27 Sep 2018 01:30:55 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id v133-v6so1411749pgb.2 for <mpls@ietf.org>; Thu, 27 Sep 2018 01:30:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6A9Q7qz7TWx4zr8ShYJ/msFvI6Th+FaGPqztIoDZyhQ=; b=SzKjor2dX6NKGyb8DJpSsruxSJv271oj5bNKy5M7h6kQ0wJLLur5vnjKEZ+lJudwW/ J/k0lTe59b+sIQYawAjUVLRFj9yfguR5e5WsbiRq8vBARDL11/x2PjtBIqbg3lnWkInl VtLOkgIFvh3jCzUdUdEQXpx76TPbtoiG3HyumR3GJtSkU+wt3V0yrvmEnPmZtyAVfTKT SJq65C/+bViLV02mwN5LVnz0dAr2qV1SPdSJIdShDtuLLVVB4o9COAnVv3XgtNQ2BE2e kLu9ibTOkFSykuBXLuEFSpDuS9Xvj0BgYzqchiD0QEiN2j1ZDZEGYHylht5dZNZM2ZVv XtZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6A9Q7qz7TWx4zr8ShYJ/msFvI6Th+FaGPqztIoDZyhQ=; b=OwahjxQT/UE+9iNPHP9WsekiOWwOmFHjwS8vgvSnS5jlCa8x2PTaXl+wfbbinwOONH YZuosvqf7N0clLJ0pP4o/eQDMOagfVFsncIIAegYjFuRouUOoNFE0ygW2RYWconqWOvc S/l9Jqt8AqfRKJfA/dgYlj4DRPylgRflTpG8QBpzKPIfOpdPcHoFzzlGPvjWiu52CDt2 nv4rjNdewGUYBEZfEOEkQ++d38OHHzPSAhduLOzDEk+Ncbi5K+oAIMtydBhxRWMssDFy rIu1PsSeeBsINEfVw8TIC9hOzCqbDDBgmbnD808YaPWSa5aNG4LlJh7kKqyYipic0wag MKCg==
X-Gm-Message-State: ABuFfogB/48wMvOikrvyRVDum76gsstvBjEbhxwg/j2HInKNp2sxKndZ RW6Efc3dD9fvnQZMkmgvJ6S3jDw0MH4WGN2+a+o=
X-Google-Smtp-Source: ACcGV602HLHJwNjE11janxXYKtFMOEBs3znB0CENGZYWcAOjN+jCxun7pKnLU0hiSZ/XBUmYDgGqWOgFDTbzIq90Mt0=
X-Received: by 2002:a62:56d9:: with SMTP id h86-v6mr10209490pfj.229.1538037054718; Thu, 27 Sep 2018 01:30:54 -0700 (PDT)
MIME-Version: 1.0
References: <CA+YzgTskvvzq6n=v156C8hB1=Yws--7nRFbNpUbUTSgWzhh9cw@mail.gmail.com> <211770d4-8279-33e2-b6bf-289261b6f6ff@gmail.com> <CA+YzgTt6qPhk83gjf+yG7zYVuDnTiUf=SMYJ3VYvKxqaWSHdQg@mail.gmail.com> <D06589AC-990F-4D31-8E68-098D4603CCD7@gmail.com> <5437736B-6E12-4595-A333-367AB7232692@gmail.com> <AB550F73-BD87-4219-AD70-6F1482C62AEF@gmail.com> <CA+YzgTuE184Tctf6ZL6T+Ka70ZkiPb92PpzG1f8Hz3FUgN4fwA@mail.gmail.com> <60C0E897-0D5D-4230-9094-4367524F91EE@gmail.com> <CA+YzgTtHSNieUKVq4QiFc7iaEOxcv-2PogtmZm5vgw04awx72g@mail.gmail.com> <CAKfnWBh8XexmpKPxM96e67GjtVEW8OERZOW_rrNgc5mqOYn69w@mail.gmail.com>
In-Reply-To: <CAKfnWBh8XexmpKPxM96e67GjtVEW8OERZOW_rrNgc5mqOYn69w@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Thu, 27 Sep 2018 04:30:42 -0400
Message-ID: <CA+YzgTtCT=AUh4n171+3kgJEOu=q-ATbrkqb5AurmyoVhawpWw@mail.gmail.com>
To: mhartley.ietf@gmail.com
Cc: Alexander Okonnikov <alexander.okonnikov@gmail.com>, IETF MPLS List <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004c49640576d6285e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/bHU2NisCfZxU4RXSIdOutqqzRdw>
Subject: Re: [mpls] Requesting WG LC for draft-ietf-mpls-rsvp-shared-labels
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 27 Sep 2018 08:30:59 -0000

Matt, Hi!



The purpose of this document is to provide a mechanism to bring up MPLS
RSVP-TE LSPs on a shared forwarding plane. There is a set of key RSVP-TE
features/functionalities specified in the Introduction Section that
would continue
to work with this forwarding plane (without needing any special
extensions). The authors believe that a deployable solution can be
implemented with this set of features/functionalities.



If there are any other desirable features/functionalities (that are not
specified as supported in this document) that can be supported on this
forwarding plane by introducing a few protocol extensions, then those are
expected to be discussed separately
(draft-chandra-mpls-rsvp-shared-labels-np is an example of that).



Regards,

-Pavan

On Wed, Sep 26, 2018 at 10:56 AM Matt Hartley <mhartley.ietf@gmail.com>
wrote:

> Pavan,
>
> The problem with lists like this (in general) is that it's not clear what
> the status is for anything that isn't on the list, and most lists will
> probably manage to omit *something*. I think there's three reasonable
> options:
>
> 1. State unequivocally that everything works
> 2. List the functionalities that definitely don't work, and make it clear
> that everything else does
> 3. List the functionalities that definitely work, and explicitly make no
> guarantees about anything that isn't listed.
>
> It isn't really clear what you're trying to do here.
>
> Note that in this case option 1 isn't on the table because we've already
> established that nnhop FRR requires further extensions.
>
> Cheers
>
> Matt
>
> On Wed, Sep 26, 2018 at 10:17 AM Vishnu Pavan Beeram <
> vishnupavan@gmail.com> wrote:
>
>> Alexander Hi!
>>
>>
>>
>> The intent of the following statement in Section 1 is certainly not to be
>> evasive (slightly or otherwise).
>>
>>    Functionalities such as bandwidth admission control, LSP
>>
>>    priorities, preemption, auto-bandwidth and Fast Reroute
>>
>>    continue to work with this forwarding plane.
>>
>>
>>
>> We (the authors) still don’t see any problem with the above statement.
>> But we’ll go ahead and make a slight adjustment (see below) to address your
>> concern.
>>
>>    Key functionalities such as bandwidth admission control, LSP
>>
>>    priorities, preemption, auto-bandwidth and Fast Reroute via
>>
>>    facility backup protection continue to work with this
>>
>>    forwarding plane.
>>
>>
>>
>> Regards,
>>
>> -Pavan
>>
>>
>> On Tue, Sep 25, 2018 at 11:34 AM Alexander Okonnikov <
>> alexander.okonnikov@gmail.com> wrote:
>>
>>> Hi Panav,
>>>
>>> Ok, 1:1 is not to be supported by this approach. In general, 1:1 has its
>>> own benefits  - for example, it is more attractive versus N:1 in ring
>>> topologies. After all, it is FRR too, as N:1 one. My point was that
>>> description in section 1 is slightly evasive regarding FRR and other
>>> RSVP-TE properties (PMTUD).
>>>
>>> Thank you.
>>>
>>>
>>> 16 сент. 2018 г., в 4:38, Vishnu Pavan Beeram <vishnupavan@gmail.com>
>>> написал(а):
>>>
>>> Alexander, Hi!
>>>
>>>
>>> Please see inline for responses (prefixed VPB).
>>>
>>>
>>> Regards,
>>> -Pavan
>>>
>>> On Thu, Sep 13, 2018 at 1:37 PM Alexander Okonnikov <
>>> alexander.okonnikov@gmail.com> wrote:
>>>
>>>> Hi Panav,
>>>>
>>>> From section 7:
>>>>
>>>>
>>>> "If the label type is a delegation label, then the stacking procedure
>>>> stops at that delegation hop."
>>>> It is OK for "Stack to Reach Delegation Hop" approach, but it doesn't
>>>> work for "Stack to Reach Egress", isn't it?
>>>>
>>>
>>> [VPB] The logic specified in Section 7 could be used by any node
>>> constructing the label stack (this could be the ingress or a delegation
>>> hop). The sentence immediately following the above quoted sentence in
>>> Section 7 is important. It currently reads –
>>> Approaches in Section 5.1
>>> <https://tools.ietf.org/html/draft-ietf-mpls-rsvp-shared-labels-03#section-5.1>
>>> SHOULD be used to determine how the delegation labels are pushed in the
>>> label stack.
>>>
>>>
>>> The intent here is to say that if you encounter a delegation label, use
>>> the procedures outlined in Section 5.1 to determine how the delegation
>>> labels are pushed in the label stack. The following change to the text
>>> should address this comment:
>>>
>>> OLD:
>>>
>>> If the label type is a delegation label, then the stacking procedure stops at that delegation hop.
>>> Approaches in Section 5.1 <https://tools.ietf.org/html/draft-ietf-mpls-rsvp-shared-labels-03#section-5.1> SHOULD be used to determine how the delegation labels are pushed in the label stack.
>>>
>>>
>>> NEW:
>>> If the label type is a delegation label, then the type of stacking
>>> approach chosen by the ingress for this LSP (Section 5.1) MUST be used to
>>> determine how the delegation labels are pushed in the label stack.
>>>
>>>
>>>
>>>>
>>>> Also, regarding FRR support. Section 1 says:
>>>>
>>>> "Functionalities such as bandwidth admission control, LSP priorities,
>>>> preemption,
>>>> auto-bandwidth and Fast Reroute continue to work with this forwarding
>>>> plane."
>>>> It seems that shared labels approach supports only facility bypass
>>>> link-protection. It doesn't support one-to-one link- and node-protection,
>>>> per my understanding. Facility bypass node-protection is not supported as
>>>> well (as mentioned in Section 8). Hence, FRR support is very limited, and
>>>> section 1 needs correction.
>>>>
>>>
>>> [VPB] I don’t see anything wrong with the quoted text. Fast Reroute for
>>> MPLS-TE LSPs can be realized by either the 1-to-1 protection mechanism
>>> (detours) or the facility bypass mechanism. The authors don’t intend to add
>>> procedures for 1-to-1 link/node protection (who needs it?).  The
>>> facility bypass link-protection procedure is discussed in this draft. The
>>> facility bypass node-protection procedure is discussed in
>>> https://tools.ietf.org/html/draft-chandra-mpls-rsvp-shared-labels-np-00
>>> (this was presented at the last IETF).
>>>
>>>
>>>>
>>>> Thank you.
>>>>
>>>> 13 сент. 2018 г., в 20:28, Alexander Okonnikov <
>>>> alexander.okonnikov@gmail.com> написал(а):
>>>>
>>>> Hi Panav,
>>>>
>>>> Questions regarding ETLD:
>>>>
>>>> The draft is not clear about signaling of ETLD attribute. It says that
>>>> ETLD is conveyed as per-hop attribute. Is my understanding correct that it
>>>> is conveyed as RRO Hop attribute? Probably it could be cleaned to avoid
>>>> confusion whether ERO or RRO Hop attribute mechanism is used.
>>>>
>>>> Next, the draft says that:
>>>>
>>>> "... If a node is reached where the ETLD set from the previous hop is
>>>> 1, then that
>>>> node MUST select itself as the delegation hop.  If a node is reached
>>>> and it is
>>>> determined that this hop cannot receive more than one transport label,
>>>> then that node
>>>> MUST select itself as the delegation hop. ..."
>>>>
>>>> What is purpose of the second sentence/rule?
>>>>
>>>> Next:
>>>>
>>>> "If there is a node or a sequence of nodes along the path of the LSP
>>>> that do not
>>>> support ETLD, then the immediate hop that supports ETLD MUST select
>>>> itself as the
>>>> delegation hop."
>>>>
>>>> If some node (consecutive nodes) doesn't support ETLD then it doesn't
>>>> support TE labels. Hence, that node (regular RSVP-TE LSR) will do SWAP and
>>>> not POP. As a result non-decremented ETLD is OK and immediate hop that
>>>> supports ETLD not necessary should become delegation hop?
>>>>
>>>> Also, from Section 9.7:
>>>>
>>>> "The ETLD field specifies the maximum number of transport labels that
>>>> this hop can potentially send to its downstream hop.  It MUST be set to a
>>>> non-zero value."
>>>>
>>>> Strictly speaking it is not correct. ETLD reflects decrementing counter
>>>> and not capability of some transit node. I.e. if we consider LSP R1-R2-R3,
>>>> R1 puts value 5 in ETLD,and R2 supports imposing of 2 labels, it doesn't
>>>> mean that R2 should rewrite ETLD with value 2. It just should decrement
>>>> value 5. Correct?
>>>>
>>>> Also, per my understanding it is supposed that in fact ETLD value will
>>>> not be just decremented, but it will be copied from previous RRO Hop
>>>> attributes subobject into being inserted RRO Hop attributes subobject with
>>>> decrementing. May be it would be better to signal ETLD value in LSP
>>>> Attributes object (and each capable node decrements ETLD value there),
>>>> while signaling support of ETLD itself in RRO Hop attributes subobject?
>>>>
>>>> Thank you.
>>>>
>>>> 13 сент. 2018 г., в 20:22, Alexander Okonnikov <
>>>> alexander.okonnikov@gmail.com> написал(а):
>>>>
>>>> Hi Pavan,
>>>>
>>>> I'm sorry for delay with answer.
>>>>
>>>> If ingress uses regular Path MTU discovery mechanism, it could produce
>>>> value of MTU lower than actual one. This is because ingress doesn't know
>>>> MTU per each hop. Let's consider case with four routers: R1 - R2 - R3 - R4.
>>>> MTU for R1-R2 link is 2000, MTU for R2-R3 is 1600 and MTU for R3-R4 is
>>>> 2000. By virtue of regular Path MTU discovery mechanism R1 will derive from
>>>> FLOWSPEC that path MTU is 1600. As soon as R1 doesn't know how many labels
>>>> in the stack will be on the lowest MTU hop, it can only set LSP MTU to most
>>>> conservative value (1600 - 4 - 4 = 1592, provided that R4 has advertised
>>>> implicit null label). In fact actual path MTU is 1596 (1600 - 4 on R2-R3
>>>> hop). Of course, it could be acceptable, but calculated LSP MTU as more
>>>> lower than actual as longer LSP path. For correct path MTU discovery
>>>> ingress needs to know MTU per each hop.
>>>>
>>>> Thank you.
>>>>
>>>> 6 сент. 2018 г., в 18:27, Vishnu Pavan Beeram <vishnupavan@gmail.com>
>>>> написал(а):
>>>>
>>>> Alexander, Hi!
>>>>
>>>> I apologize for the delayed response.
>>>>
>>>> This draft does not propose any changes to the standard RSVP MTU
>>>> signaling procedures (Int Serv object specific signaling procedures). After
>>>> the initial signaling sequence is complete, an ingress implementation
>>>> (RFC3209) would typically take the path MTU learnt via signaling, run it
>>>> through some local logic and then arrive at an MTU value that can be
>>>> assigned to the LSP. This local logic typically involves deducting the
>>>> number of bytes in the label stack used for the LSP from the path MTU
>>>> learnt via signaling. The ingress implementation supporting this draft will
>>>> rely on the Resv RRO to accurately determine the max-number of labels
>>>> pushed along the path of the LSP (note that with delegation, downstream
>>>> hops can impose label stacks) and account for it in the local logic used to
>>>> arrive at the MTU value assigned to the LSP.
>>>>
>>>> I hope this addresses your question..
>>>>
>>>> Regards,
>>>> -Pavan
>>>>
>>>> On Tue, Aug 7, 2018 at 12:22 PM Alexander Okonnikov <
>>>> alexander.okonnikov@gmail.com> wrote:
>>>>
>>>>> Hi Pavan,
>>>>>
>>>>>
>>>>> Regular RSVP-TE LSPs use standard RSVP path MTU discovery mechanism.
>>>>> That one cannot be used "as is" for approach described in the draft, and
>>>>> the draft doesn't address path MTU identification. Is it to be considered?
>>>>>
>>>>>
>>>>> Thank you.
>>>>>
>>>>> 26.07.2018 06:07, Vishnu Pavan Beeram пишет:
>>>>>
>>>>> Chairs, Hi!
>>>>>
>>>>> As mentioned (in our presentation) in last week's WG session, we
>>>>> believe that the draft is sufficiently baked and ready to progress to the
>>>>> next stage. We would like to formally request this draft to be considered
>>>>> for WG LC.
>>>>>
>>>>> Regards,
>>>>> - Pavan (on behalf of the authors)
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mpls mailing listmpls@ietf.orghttps://www.ietf.org/mailman/listinfo/mpls
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>