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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Tue, 25 September 2018 15:43 UTC

Return-Path: <alexander.okonnikov@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 02EAD1312F4 for <mpls@ietfa.amsl.com>; Tue, 25 Sep 2018 08:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 K8JFIjaao9xj for <mpls@ietfa.amsl.com>; Tue, 25 Sep 2018 08:43:20 -0700 (PDT)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 085911312FC for <mpls@ietf.org>; Tue, 25 Sep 2018 08:43:20 -0700 (PDT)
Received: by mail-wm1-x334.google.com with SMTP id 206-v6so6065940wmb.5 for <mpls@ietf.org>; Tue, 25 Sep 2018 08:43:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FjBR8QnlWyMDTxFmttedtjHavbijFEIFwQzkY4BT0cg=; b=sUaGu2xdNd+ow+KtG1X+su0lBOH8Lx3Fnxc+hG1IqCxYhZlIaLdzXFQSVObSxDMzlh xwzMN08idkXP9K9ns7HlmeIH7CUm8tJuyLortgilegF4F3dcSXYh3a80a9Wj8SkdENwr yHtL+QDnlvfjTByNM0vgZamrvR/FVEGYGIQIa7B0UuRoXhCymZTj0dJJpJg3bFv2GGgf AjdMJ7uy7J02o5cSK+1Ey0VE9rlOZ4Ug50CJuIQ9ejPZnvLAg+CxduGbC124qZbjhzW0 /5LDs6qWXpbLP0dHZBFx33dYKVyVBIA6nP0MQ9uahSgCsR6V03FotTuhbef1N1WthBH2 a0jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FjBR8QnlWyMDTxFmttedtjHavbijFEIFwQzkY4BT0cg=; b=kPeH85hw7qLzoQYzbpAgAC1J7nYTb4ch3DIxSBXY2auXQJ2T1xdtH8PAFoGtGHtCHy YxRWUjqMEFJ8G9ByE/21/5rJZhFomvHgRDCi+pNiErDfTcGRfDd8PUl+bZLT/gII+pcN Ewh/8C8wJH62WeEWho3cLC4c03Z7YsksAPUEux+MH7UWgmlShENbKiWvxtybgZiBZmZf JQVdnIn93q4ChbZQ6yTprP2Z1uZ0tu/3nmSO15KNE+0mKdq27cUGMLKTJapf4cumwDkg fESkA0Y3izyBUuvTnotdmKhOFleGlH9sI0CCtz0S8q+D1rwtL9RfE5Z8RL2vjWudj6R/ LpiQ==
X-Gm-Message-State: ABuFfojoH+cu3+L2mVXgxTvzsl7miziPtruOgrnxH8RqQs9haq6MiZBl gUpMvN1sPkquDsM2Alic3rj1XYdxwd8=
X-Google-Smtp-Source: ACcGV639NtFHnDn7zdBVpgQyt7LS+JWHAWzvIzDs/Nt0IjnLgFMnluzNyKAkZ1TI3oepP8Y3eB7aag==
X-Received: by 2002:a1c:8dd1:: with SMTP id p200-v6mr1249615wmd.145.1537890198416; Tue, 25 Sep 2018 08:43:18 -0700 (PDT)
Received: from [10.161.106.164] ([212.65.85.100]) by smtp.gmail.com with ESMTPSA id v6-v6sm2893732wrr.60.2018.09.25.08.43.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Sep 2018 08:43:17 -0700 (PDT)
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Message-Id: <EF52917C-814E-4107-9035-F4E6A36A9BB2@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_79532E6C-1A4F-4C42-8A6D-FB5A5ABB6DE2"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 25 Sep 2018 18:43:15 +0300
In-Reply-To: <CA+YzgTt4XRQKpAmxk50cLTfAfOmt_csX9Q-zrddsn70cAdyQXA@mail.gmail.com>
Cc: IETF MPLS List <mpls@ietf.org>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
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>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/01sPdMxnli3ezrtJ7YIsqRJ543Q>
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: Tue, 25 Sep 2018 15:43:23 -0000

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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 list
>>>> mpls@ietf.org <mailto:mpls@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
>>> 
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org <mailto:mpls@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
>> 
>