IETF Logo Mail Archive

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> Fri, 03 April 2020 07:39 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 8C6333A133D for <idr@ietfa.amsl.com>; Fri, 3 Apr 2020 00:39:16 -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=ham 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 1nBFsANRwp88 for <idr@ietfa.amsl.com>; Fri, 3 Apr 2020 00:39:09 -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 8D2793A1339 for <idr@ietf.org>; Fri, 3 Apr 2020 00:39:08 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 0310F9EEBFA5B3E01E93 for <idr@ietf.org>; Fri, 3 Apr 2020 08:39:01 +0100 (IST)
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 3 Apr 2020 08:38:31 +0100
Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.59]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0487.000; Fri, 3 Apr 2020 15:38:26 +0800
From: "Chengli (Cheng Li)" <chengli13@huawei.com>
To: Susan Hares <shares@ndzh.com>, 'IDR List' <idr@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+IftQ
Date: Fri, 03 Apr 2020 07:38:26 +0000
Message-ID: <C7C2E1C43D652C4E9E49FE7517C236CB029A907B@dggeml529-mbx.china.huawei.com>
References: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.com>
In-Reply-To: <01a201d6068f$c1f3aaf0$45db00d0$@ndzh.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_C7C2E1C43D652C4E9E49FE7517C236CB029A907Bdggeml529mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jfSEXhwo5Z71MgQ0UkI8Lkis8jM>
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: Fri, 03 Apr 2020 07:39:17 -0000

Hi WG,

I support this document to be adopted since the mechanism is useful and the text is mature.


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

[Cheng ] Yes. The PMTU should be calculated and set for SID list in order to appropriately encapsulate SRv6 Packet.
Also,  overhead of BSID and FRR should be considered when calculating PMTU, so it will be good to provide a protocol interface for Controller to set the PMTU for SID list based on different PMTU considerations.


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

[Cheng] I think no. But the error handling should align with the error handling in https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-08#section-5
Will update it in next revision.


[



When the error determined allows for the router to skip the malformed
   NLRI(s) and continue processing of the rest of the update message,
   then it MUST handle such malformed NLRIs as 'Treat-as-withdraw'.
]

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.

[Cheng]I think it is ready to be adopted.



From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 8:36 PM
To: 'IDR List' <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

v2.23.0 | Report a Bug | By Email