Re: [Idr] WG Adoption call for draft-peng-idr-segment-routing-te-policy-attr-05 (9/26/2023-10/10/2023)

liu.yao71@zte.com.cn Sun, 15 October 2023 14:46 UTC

Return-Path: <liu.yao71@zte.com.cn>
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 0D8A5C14CF1F for <idr@ietfa.amsl.com>; Sun, 15 Oct 2023 07:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGvwqw4AptxU for <idr@ietfa.amsl.com>; Sun, 15 Oct 2023 07:46:13 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5DDC14CE3F for <idr@ietf.org>; Sun, 15 Oct 2023 07:45:56 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4S7jj96PVnz8XrRB; Sun, 15 Oct 2023 22:45:49 +0800 (CST)
Received: from njb2app07.zte.com.cn ([10.55.22.95]) by mse-fl1.zte.com.cn with SMTP id 39FEjjOw038832; Sun, 15 Oct 2023 22:45:45 +0800 (+08) (envelope-from liu.yao71@zte.com.cn)
Received: from mapi (njb2app06[null]) by mapi (Zmail) with MAPI id mid203; Sun, 15 Oct 2023 22:45:49 +0800 (CST)
Date: Sun, 15 Oct 2023 22:45:49 +0800
X-Zmail-TransId: 2afe652bfb1dffffffffe89-af15f
X-Mailer: Zmail v1.0
Message-ID: <202310152245497970212@zte.com.cn>
In-Reply-To: <CAKEJeo7HDWu=nFH8QC1pYR8c7WPPV9pFDYVnzS9sgU9Lq3om+A@mail.gmail.com>
References: CAKEJeo7LZMekmLAkyffTuwBu7PzUmMp3yA41nc13dvoP247=Mg@mail.gmail.com, 202310131038318048881@zte.com.cn, CAKEJeo7HDWu=nFH8QC1pYR8c7WPPV9pFDYVnzS9sgU9Lq3om+A@mail.gmail.com
Mime-Version: 1.0
From: liu.yao71@zte.com.cn
To: pyxislx@gmail.com
Cc: shares@ndzh.com, idr@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 39FEjjOw038832
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 652BFB1D.000/4S7jj96PVnz8XrRB
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Dush8Cv7bEZwOEsWhBmqF5Q7uHY>
Subject: Re: [Idr] WG Adoption call for draft-peng-idr-segment-routing-te-policy-attr-05 (9/26/2023-10/10/2023)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 15 Oct 2023 14:46:17 -0000

Hi Nat,
Sure, it would be addressed. 

Thanks,
Yao





Original


From: NatKao <pyxislx@gmail.com>
To: 刘尧00165286;
Cc: shares@ndzh.com <shares@ndzh.com>;idr@ietf.org <idr@ietf.org>;
Date: 2023年10月13日 18:19
Subject: Re: [Idr] WG Adoption call for draft-peng-idr-segment-routing-te-policy-attr-05 (9/26/2023-10/10/2023)


Hi, Yao.
 
Thank you for the prompt update.
I am okay with the current version of this draft.
 
Note:
There is a reference to RFC5307 in paragraph 1 of section 3.1.
Since this draft defines new BGP attributes, it might be more
appropriate to refer to RFC7752(BGP-LS) instead of RFC5307(IS-IS).
However, we can address this later since it's pretty minor.
 
Thanks
Nat
 
 
 
On Fri, Oct 13, 2023 at 10:38 AM <liu.yao71@zte.com.cn> wrote:
> 
> Hi Nat,
> 
> 
> Thanks a lot for your support and retailed review!
> 
> Please see my reply with [Yao]. And based on your comments, we've submmitted a new version to refine the wording for better alignment and readability.
> 
> https://www.ietf.org/archive/id/draft-peng-idr-segment-routing-te-policy-attr-07.html
> 
> https://author-tools.ietf.org/iddiff?url2=draft-peng-idr-segment-routing-te-policy-attr-07
> 
> 
> Thanks,
> 
> Yao
> 
> 
> Original
> From: NatKao <pyxislx@gmail.com> 
> To: Susan Hares <shares@ndzh.com>;
> Cc: idr@ietf.org <idr@ietf.org>;
> Date: 2023年10月12日 18:09
> Subject: Re: [Idr] WG Adoption call for draft-peng-idr-segment-routing-te-policy-attr-05 (9/26/2023-10/10/2023)
> Hi, All.
> 
> I support the adoption for this draft.
> These segment types are useful for networks to identify specific
> Adj-SIDs using alternate algorithms.
> 
> The alignment suggestions:
> -For all segment types defined in this document, it might be better to
> change "optional Algorithm" to "optional SR Algorithm" for better
> 
> alignment with RFC9256 & draft-ietf-idr-sr-segtypes-ext.
> 
> [Yao] Yes,  "optional SR Algorithm" is better.
> 
> 
> -In Sec. 3.1, is the paragraph "Other fields have the same ..." 
> 
> redundant? It seems that all fields are defined already.
> 
> [Yao] It has been deleted in the refined version.
> 
> 
> -In Sec. 3.1 for "Local Interface ID": it should be better to
> reference RFC7752 instead of RFC8664 in this section.
>  (ref: https://mailarchive.ietf.org/arch/msg/idr/Nfa1-xwiwcysW-oTSRq0Z5BCWyQ/ )
> -In Sec. 3.3, shouldn't the reference for "Local/Remote Interface ID" 
> be RFC7752 instead of RFC8402?
> 
> [Yao] Both references have been changed, thanks.
> 
> 
> -I knew some terms don't align well between
> 
> draft-ietf-idr-bgp-sr-segtypes-ext and RFC9256(after -04 of
> draft-filsfils-spring-segment-routing-policy)
> However, these terms now appear in the same document, so it's better
> to unify them for readability.
>  *Sec. 3.1: "IPv4 Address", "IPv4 Prefix Address", and "IPv4 Node Address" 
>  *Sec. 3.2: "Local IPv4 Address"/"IPv4 Local Address" & "Remote IPv4
> Address"/"IPv4 Remote Address" 
>  *Sec. 3.3/3.4: "IPv6 Prefix Address"/"IPv6 Local Node Address"/"Local
> Prefix"/"Local IPv6 Address" 
>      & "IPv6 Remote Node Address"/"Remote Address"/"Remote IPv6 Address" 
> 
> 
> [Yao]
> 
> *Sec. 3.1: The term "IPv4 Node Address" is used in the new version.
> 
> *Sec. 3.2: "Local IPv4 Address" and "Remote IPv4 Address" are preferred
> 
> *Sec. 3.3: "IPv6 Node Address" and "IPv6 Local/Remote Node Address" are used.
> 
> *Sec. 3.4: "IPv6 Addresses"/"Local IPv6 Address"/"Remote IPv6 Address" are preferred.
> 
> 
> Thanks
> Nat
> 
> On Wed, Sep 27, 2023 at 10:33 AM Susan Hares <shares@ndzh.com> wrote:
> > 
> > This begins a 2-week WG adoption call for
> > 
> > draft-peng-idr-segment-routing-te-policy-attr-05
> > 
> > (https://datatracker.ietf.org/doc/draft-peng-idr-segment-routing-te-policy-attr/)
> > 
> > 
> > 
> > In your comments, please indicate
> > 
> > “support” or “no support”.
> > 
> > 
> > 
> > Please also consider the following questions:
> > 
> > 
> > 
> > 1) Are these new segment types are useful for networks
> > 
> > Using alternate algorithms?
> > 
> > 
> > 
> > 2) This draft will need to align with the
> > 
> > draft-ietf-idr-segment-routing-te-policy
> > 
> > split into  draft-ietf-idr-segment-routing-te-policy
> > 
> > and draft-ietf-idr-sr-segtypes-ext-01.
> > 
> > 
> > 
> > Do you see any issues with this alignment?
> > 
> > 
> > 
> > Cheerily, Sue Hares
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 
>