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

Vishnu Pavan Beeram <vishnupavan@gmail.com> Wed, 26 September 2018 14:20 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 A7F1D130EE4 for <mpls@ietfa.amsl.com>; Wed, 26 Sep 2018 07:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 VYp93v18pX6Y for <mpls@ietfa.amsl.com>; Wed, 26 Sep 2018 07:20:39 -0700 (PDT)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 7D282130EFF for <mpls@ietf.org>; Wed, 26 Sep 2018 07:20:39 -0700 (PDT)
Received: by mail-pf1-x42b.google.com with SMTP id j26-v6so13510564pfi.10 for <mpls@ietf.org>; Wed, 26 Sep 2018 07:20:39 -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=aH5nhPkQtizdFPGuJIIyHk66+3FjpLxLZk55DFrvOos=; b=E7Q32enaUeu2eHdQnO329x0w0l0eUG7AWEH4+D2t0ozcc+cIvsD8CuO+cwJuEDdr0f r1greRr5oVDepyNvOGa9XFg+3fXpV30iBYHl+adWxDUvimUOkbcHdxsmfqXCrTSZRZq3 W/k+O7iZOOZCb3CwzD48/RPlI6toBdhNyD6abgQN7+8LWdJQZuOHIrZwbYrOtplycWf9 DDXwrIKabwajTRCIhiSgkVsISpDYxraGofeOa3BSIOEcKKXmaR2jMrT8G/DwJMwv9JXb gwDBKdqq8KE8NMIF0bTP+NNLMU4Tya7ChRTbne15KbQ664GPrUvHxrU0YX7/q6DdRLDf +SjQ==
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=aH5nhPkQtizdFPGuJIIyHk66+3FjpLxLZk55DFrvOos=; b=CPmp2VMDokfLv0MjGTEUsX7ZRGkxvP0jipjT3NnX8qHXs/7KblUq0oXlx6kXEw19eZ SxCukoTSZGS3qjbILX2g/vb4GWFseREbo+FmapIB8eS/gPcYkCM1pIWkYYJyuO7Ci7Zd k2dVNPqygIZQygGFq7uYWolkkNV3fjzfdkUVIn9Ce3Am9JsVbTPgffg0lxBZIR/xl994 Ey2LaYvrekXWg+GKnS+Ts5y9V5NyYVlYpEW1crYSiZM9JyFJslphds/bZstYMEBdOUAs Pi8yI/nnNasKHiuu54mnZ6fimlqdMdf/w8D0TAlPrOvLXgPyckxIWUqG9CdC/KOgxDwf J3xw==
X-Gm-Message-State: ABuFfojNLc5EXPNwEq2S0mxQ4Bif+a+bzJxI9bsOVBJENsDeWwo2SUoA TdSBPHj4426PoafugTRxcRlIuM+6LioOMQteHcY=
X-Google-Smtp-Source: ACcGV603WsjQG31RjpuHIDLmyRblEesPJq8vRwiKEZ7W6+anyhIzwGMoFV+hQeMFkCvGlgJI+FzVrotptUeorQ4XMe0=
X-Received: by 2002:a63:e443:: with SMTP id i3-v6mr6046481pgk.381.1537971639008; Wed, 26 Sep 2018 07:20:39 -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> <CA+YzgTt4XRQKpAmxk50cLTfAfOmt_csX9Q-zrddsn70cAdyQXA@mail.gmail.com> <EF52917C-814E-4107-9035-F4E6A36A9BB2@gmail.com>
In-Reply-To: <EF52917C-814E-4107-9035-F4E6A36A9BB2@gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Wed, 26 Sep 2018 10:20:27 -0400
Message-ID: <CA+YzgTvuFj7xaB3NJ+HRQ7MAB2xNHFsSqkTEM9zV0ego0sDj=w@mail.gmail.com>
To: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Cc: IETF MPLS List <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000037c1ea0576c6edd0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/fdh2L2P2uJEUFnGc5JR13lc2B0o>
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: Wed, 26 Sep 2018 14:20:48 -0000

Alex, Hi!

Yes, the bypass tunnel (as indicated by the reference) referred to here is
a regular RFC4090 bypass tunnel.

Regards,
-Pavan

On Tue, Sep 25, 2018 at 11:43 AM Alexander Okonnikov <
alexander.okonnikov@gmail.com> wrote:

> Hi Pavan,
>
> One question regarding ETLD. The draft says (section 5.3.1):
>
>    When an LSP that requests automatic delegation also requests facility
>    backup protection [RFC4090 <https://tools.ietf.org/html/rfc4090>], the ingress or the delegation hop MUST
>    account for the bypass tunnel's label when populating the ETLD.  So,
>    the ETLD that gets populated on these nodes is one less than what
>    gets populated for a corresponding unprotected LSP.
>
>
> I.e. is it assumed that bypass tunnel itself will be regular RSVP-TE LSP?
> Otherwise, if bypass LSP is signalled using shared labels approach, ETLD
> should be decreased for amount of label stack depth, imposed by this PLR
> (ingress or delegation hop) for bypass tunnel.
>
> Thank you.
>
> 16 сент. 2018 г., в 3:03, Vishnu Pavan Beeram <vishnupavan@gmail.com>
> написал(а):
>
> Alexander, Hi!
>
>
> Much Thanks for the review comments. Please keep them coming.
> Please see inline for responses (prefixed VPB).
>
>
> Regards,
> -Pavan
>
>
> On Thu, Sep 13, 2018 at 1:28 PM Alexander Okonnikov <
> alexander.okonnikov@gmail.com> wrote:
>
>> 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.
>>
>
> [VPB] The ETLD specific protocol extensions are discussed in Section 9.7.
> This section clearly states that the ETLD TLV is carried in the
> HOP_ATTRIBUTES subobject of an RRO object in the Path message. That said,
> the following tweak to the text in Section 5.3.1 should address your
> comment:
>
>
> OLD:
> The ETLD is signaled as a per-hop attribute in the Path message [RFC7570
> <https://tools.ietf.org/html/rfc7570>].
>
>
> NEW:
> The ETLD is signaled as a per-hop recorded attribute in the Path message [
> RFC7570 <https://tools.ietf.org/html/rfc7570>].
>
>
>
>
>>
>> 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?
>>
>
> [VPB] Selecting oneself as a delegation hop ensures that the incoming
> packet will not carry more than one transport label. The second sentence
> above was added to let the transit node have the ability to influence the
> delegation decision if it ran into some local policy/limitation that
> prevented it from receiving more than one transport label. As an
> alternative, the transit node may decide to choose a regular swap label in
> such scenarios and let some downstream node be the delegation hop.
>
>
>>
>> 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?
>>
>>
> [VPB] If an intermediate transit node doesn’t support ETLD, it will not
> record ETLD for that hop. The immediate hop that supports ETLD will realize
> that the previous hop doesn’t support ETLD (no recording available for the
> previous hop) and designates itself as a 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?
>>
>>
> [VPB] I agree that the above sentence can read better. The intent was to
> say – “the maximum number of transport labels that the hop can send in
> relation to its position in the path”. The following tweak to the sentence
> should address your concern:
>
>
> OLD:
> The ETLD field specifies the maximum number of transport labels that this
> hop can potentially send to its downstream hop.
>
>
> NEW:
> The ETLD field specifies the effective number of transport labels that
> this hop (in relation to its position in the path) can potentially send to
> its downstream hop.
>
>
>
>
>> 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?
>>
>>
> [VPB] The authors did consider the alternative protocol extensions that
> you have specified above. We decided to use the current encoding in the
> draft because there was no good reason to get 2 code-points for ETLD when
> the same objective could be achieved with one code-point.
>
>
>> 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
>>>
>>
>>
>>
>