Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

"Chengli (Cheng Li)" <chengli13@huawei.com> Wed, 08 April 2020 09:06 UTC

Return-Path: <chengli13@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB343A0EB6; Wed, 8 Apr 2020 02:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 hiBoVs12d0Ts; Wed, 8 Apr 2020 02:06:12 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79BB63A0EB5; Wed, 8 Apr 2020 02:06:12 -0700 (PDT)
Received: from lhreml705-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D56456173F1E76C9A11F; Wed, 8 Apr 2020 10:06:06 +0100 (IST)
Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 8 Apr 2020 10:06:06 +0100
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Wed, 8 Apr 2020 10:06:06 +0100
Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.59]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0487.000; Wed, 8 Apr 2020 17:05:43 +0800
From: "Chengli (Cheng Li)" <chengli13@huawei.com>
To: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, "Susan Hares" <shares@ndzh.com>, 'IDR List' <idr@ietf.org>
CC: SPRING WG <spring@ietf.org>
Thread-Topic: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)
Thread-Index: AdYGjhUttAt3lPHsTfmnpSciWcUkAAC/+rEwAP1g+aA=
Date: Wed, 8 Apr 2020 09:05:43 +0000
Message-ID: <C7C2E1C43D652C4E9E49FE7517C236CB029AC713@dggeml529-mbx.china.huawei.com>
References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com> <MW3PR11MB45709BBDB2AD9FF81494A0CCC1C70@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB45709BBDB2AD9FF81494A0CCC1C70@MW3PR11MB4570.namprd11.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.203.229]
Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB029AC713dggeml529mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KTH41QjuIl_hr-vUW8Tx8LA6Rno>
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Apr 2020 09:06:14 -0000

Hi Ketan,

Many thanks for your comments, and sorry for my delay, please see my reply inline.

Thanks,
Cheng


From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares <shares@ndzh.com>om>; 'IDR List' <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

Hello,

I have a few questions for the authors of this draft and some discussion points for the WG.

1)      What is precisely the definition of this "path MTU" for an SR Policy? I am guessing that it includes all the labels/SIDs that are used for the SR path?
[Cheng] Yes, The Path MTU describes the largest size of the packet, including the overhead of Labels/SIDs/IPv6 header/SRH and others. When encapsulating a packet, the length of the payload(inner IP packet or something else) should be less than the PMTU minus the overhead of SID List/SRH/ FRR overhead and Binding SID overhead, but it is a implementation choice.

2)      While https://tools.ietf.org/html/rfc3209#section-2.6 defines "path MTU" for RSVP-TE LSPs, it does describe the procedures for the same for handling IP packets/payloads on the headend. It does not cover the scenarios where the incoming packets may be themselves labelled.
[Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rfc3209#section-2.6, but I think it covers the scenarios where the incoming packets may be themselves labelled. I may be wrong.

   "
   The following algorithm applies to all unlabeled IP datagrams and to
   any labeled packets which the node knows to be IP datagrams, to which
   labels need to be added before forwarding.  For labeled packets the
   bottom of stack is found, the IP header examined.


   Using the terminology defined in [5<https://tools.ietf.org/html/rfc3209#ref-5>]5>], an LSR MUST execute the

   following algorithm:



   1. Let N be the number of bytes in the label stack (i.e, 4 times the

      number of label stack entries) including labels to be added by

      this node.
       "

3)      Shouldn't the concept of "path MTU" for SR Policies and its' applicability and operations be first defined in a (Spring WG?) document before we introduce its signalling aspects in protocols like BGP? Note that such a document would bring in requirements and guidelines for how the value is going to be computed and it's usage for different steering mechanisms over SR Policies.
[Cheng] This is a really small but useful and straight forward extensions, it might not need to write a draft to describe the requirement instead of adding text in the current SR policy architecture draft or it current document.



4)      Finally, specific to the proposed encoding here, would this "path MTU" not be more suitable on the CP level since each SL may have different size label stack and different paths and one does not know which SL would be picked for a particular flow? So may be the lowest value computed for all SLs is what gets applied to the packets at the CP (i.e. SR Policy) level?
[Cheng] You are correct. The PMTU is defined for SID List. When we talk about Path MTU for SR policy, it CAN be the lowest value of the PMTU of SID lists. But do we need this value? If we need, then the node can compute it based on PMTUs.




Thanks,
Ketan


From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Susan Hares
Sent: 30 March 2020 18:06
To: 'IDR List' <idr@ietf.org<mailto:idr@ietf.org>>
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-03.txt

You can view this draft at:
https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/

This draft distributes path maximum transmission unit for the
SR policy via BGP.

Any discussion regarding on whether one desires
SR Policy should be clearly distinguished from the
Technical discussions on the mechanisms to pass SR policy MTU.

The questions for the people to discuss on this draft are:

1) Is there a need for this mechanism in networks using
        MPLS-SR or SR-V6 and SR policy?

2) Are there any error handling issues besides what is being
     Taken care of in RFC7752bis-03.txt

3) Do you think this draft is ready to be adopted?
     In this category, please list any concerns you have
     regarding adoption.  This category can include
     general concerns about BGP-LS, MPLS-SR,
    SR-V6, and SR-Policy.

Cheers, Sue Hares