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

Vishnu Pavan Beeram <vishnupavan@gmail.com> Sun, 16 September 2018 23:25 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 B8B42130DFD for <mpls@ietfa.amsl.com>; Sun, 16 Sep 2018 16:25:28 -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 TeysCecXkD1L for <mpls@ietfa.amsl.com>; Sun, 16 Sep 2018 16:25:26 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 70D96128C65 for <mpls@ietf.org>; Sun, 16 Sep 2018 16:25:26 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id g23-v6so6513138plq.9 for <mpls@ietf.org>; Sun, 16 Sep 2018 16:25:26 -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=+FAN61RZtrixt4EAgn40y8kKkEtWZubgsQPhMVbBKFc=; b=nbaWLLQtBqa/8HPq26ZKjoc4BvqbA7+DJDBv5Dod1ncCuMIKPsVz82pehMoKwkyrCQ 2QoYdHY+sf+jmJSitwOsqb13sM41fO9hVqZh0+V9PGTBuf4T09yKdOrZoVez2VY7CCMr Bsehy/Gt1Ti8zLlvYbJwUr30fKU7EtznlTZ/7Qi+mgtZ0NP9EFDULQXO7QZlJFlUVx5S mUNpQCFmbOZRtdoRfPjNU6p5dH7dByXj1P+9zEAZtB8va1caRuBDsVPYfoajIIg94v1y Lz0UKlnaI7dJZ/zW10iSyGQKgf5h2mO4ncXX+Cr4Re6xhGHC4x76CDhvDZ+QRizoKAcV RJxw==
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=+FAN61RZtrixt4EAgn40y8kKkEtWZubgsQPhMVbBKFc=; b=qcHK0KGRP3xO2buwD/t4M1vVbP/GOATSbG/a7DJ59K5GFf59LTA1L+w4LFB7gqkHSo +5y3t93jsBhzjjHC3tHzL7XYmkBIhBZSh4O83KVMyqzZpuXXZStxumEZRJLTS8ak3Roc aBQZ0OXRCSlznwUylY/3h/TxiJbAluNu71YvVSA7Rg0Xfp2eZhM05au8m+ibEmAzN/tT EBKkMaq7wM7wAy/XqJRaMbhi8IXusU7EF9Q6jPMu7NfcSY6HH6pweWLRPHcJ2/Qr7wKE RC7FkPAEmLUWHpFufnwKxEtmZUiU9vULVFoVizwYEDKmvzKT5uV4ZvNKE96hpJxMFulf vmmg==
X-Gm-Message-State: APzg51B1vbM+gaAFxslF8rp1iDFJWPM3GBLWupcmx/35U/WW15+MnTxo QRxjEr6GH63h4hx3dUAL9V6N42wlMrU8NqiaiFVTDKTqheU=
X-Google-Smtp-Source: ANB0VdY1TxJ1kYPvJdzZb3unPyhquYFYa3Nre7jvsVl2IghjWvkCJScGtxN5FHJlhwF+PnfZeO+GMo9FW55Ty70GyCw=
X-Received: by 2002:a17:902:ac1:: with SMTP id 59-v6mr22358147plp.18.1537140325901; Sun, 16 Sep 2018 16:25:25 -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>
In-Reply-To: <D06589AC-990F-4D31-8E68-098D4603CCD7@gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Sun, 16 Sep 2018 19:25:41 -0400
Message-ID: <CA+YzgTsANQE8A3MGYf+NOhUywQbctKuyd8pbS_T8unKqJ7OYAg@mail.gmail.com>
To: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Cc: IETF MPLS List <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000186ca60576055fce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/BjoEJACkhEorweALr3ORhCrywxE>
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: Sun, 16 Sep 2018 23:25:29 -0000

Alexander, Hi!

I missed responding to this earlier. Please see inline for responses
(prefixed VPB).



Regards,

-Pavan

On Thu, Sep 13, 2018 at 1:22 PM Alexander Okonnikov <
alexander.okonnikov@gmail.com> wrote:

> 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.
>

[VPB] Your understanding is correct. The logic to determine the MTU value
assigned to the LSP at the ingress may arrive at a relatively conservative
value when it uses the path MTU learnt via signaling and deduces the number
of bytes in the label stack used for the LSP. And yes, the ingress would
arrive at a more accurate value if it knows the MTU used at each hop of the
LSP (to discount the labels accordingly). The mechanisms for learning the
per-hop MTU of the LSP are outside the scope of this draft.


>
> 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
>>
>
>