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 >> >
- [mpls] Requesting WG LC for draft-ietf-mpls-rsvp-… Vishnu Pavan Beeram
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Alexander Okonnikov
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Alexander Okonnikov
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Vishnu Pavan Beeram
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Alexander Okonnikov
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Alexander Okonnikov
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Vishnu Pavan Beeram
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Vishnu Pavan Beeram
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Vishnu Pavan Beeram
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Alexander Okonnikov
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Alexander Okonnikov
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Vishnu Pavan Beeram
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Alexander Okonnikov
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Vishnu Pavan Beeram
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Alexander Okonnikov
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Matt Hartley
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Vishnu Pavan Beeram
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Vishnu Pavan Beeram
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Matt Hartley
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Alexander Okonnikov
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Alexander Okonnikov
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Vishnu Pavan Beeram
- Re: [mpls] Requesting WG LC for draft-ietf-mpls-r… Vishnu Pavan Beeram