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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Thu, 13 September 2018 17:22 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 046CA130E29 for <mpls@ietfa.amsl.com>; Thu, 13 Sep 2018 10:22:15 -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 nPg9CBMqpKIx for <mpls@ietfa.amsl.com>; Thu, 13 Sep 2018 10:22:12 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 38D27130DF3 for <mpls@ietf.org>; Thu, 13 Sep 2018 10:22:12 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id u12-v6so7076705wrr.4 for <mpls@ietf.org>; Thu, 13 Sep 2018 10:22:12 -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=QKGbR8sjLG/y/BmzcRwOfpBanuGocWoeHH74Y0Zhkag=; b=XVO6oWE52e2A55CoOLWDBvuABr3Eu5qTtV0iS6GCN1wpJGWW5s59GGSSnAbUcAkGtX xBh7eE4Dy9SMfFHlYj7D8nVvHHJsXGL+s7uCPKdNjQex4oWQaCSI9XhkZHNnKFrKfUnK oRSd94uNTGQefcBEz2HLX9HUTs5n5Upa83iBxNSYFIs08e1XTo5dYtoAJXhOdPjc1P+W F0FweCu0ZsZOdWaOswAE+ozfcaEzGa4L9X3gtO4ThSTqkNIoxlocpXwVrq9dC14voK6E /lGV+trBLW07UijBbv0vf1APklnnzu/NvE1A2CVpAkhIihOpkChneZIZ6Sg++T+l731Q dsWA==
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=QKGbR8sjLG/y/BmzcRwOfpBanuGocWoeHH74Y0Zhkag=; b=byYM1DXZsRwtxUQia9fthNoghoOKJZYxCZ9zI9RiSmSmXxagBkaSAiv5Zs5hRDTPoJ mgPONOFZGRZEJC/Xx+slP3OkGdzyJ4mrC+vZj3GeZeM75z6VV+y9KRqBHuJp/kSl8fn/ Gd4XuXMlfFJNnPJQuvyPYzDEuC4HDCv/dQ53lOdVEkQMKcplT+a7IVMC+c3SN0F9Js4C Z2ICnh4NXhVirmYb03T0mbvoBaVAyD7qQK1mretq+t0BtsBZn7flSWYtHmFX/Gg1rH00 KbWX+yVQGnb2GAA/m8B9E3WrOLFtKJZ568M+uPAOenzuJWwuFMq/VXU103e/l1kz+HwJ Q9/A==
X-Gm-Message-State: APzg51C7CnNsHVpfU8UTTvoLkNJPZb3TSmC57VC7J9HWwwKb+FjudUtW mUphiy7n+SoDWH7pW+Gjc8k=
X-Google-Smtp-Source: ANB0VdYIlcBs26ZLBEsrk46Uk7Q/UMV03ix0iID8sQoDWtQnj607rqgSJ54NyGGHMFbEddpQO1Qy4w==
X-Received: by 2002:adf:f504:: with SMTP id q4-v6mr6795632wro.241.1536859330626; Thu, 13 Sep 2018 10:22:10 -0700 (PDT)
Received: from [10.161.106.161] ([212.65.85.100]) by smtp.gmail.com with ESMTPSA id f6-v6sm3474102wrr.68.2018.09.13.10.22.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 10:22:09 -0700 (PDT)
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Message-Id: <D06589AC-990F-4D31-8E68-098D4603CCD7@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EE488C44-C738-40FA-B8B7-57C4892C0969"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 13 Sep 2018 20:22:08 +0300
In-Reply-To: <CA+YzgTt6qPhk83gjf+yG7zYVuDnTiUf=SMYJ3VYvKxqaWSHdQg@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>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/wFh9GzcQKKqdDMkD5Fvv7H3dbpA>
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, 13 Sep 2018 17:22:15 -0000

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