Re: [Lsr] New Version Notification for draft-chen-lsr-anycast-flag-05.txt

[chen.ran]

Hi WG,

This version addresses all comments from the IETF117th meeting.
The updates mainly include:
1. Added the use case for AC-flag.
2.Added description of how router will use AC-flag.

Any comments or suggestions are welcome.

Best Regards,
Ran


Original


From: internet-dra...@ietf.org 
To: 赵德涛10132546;Ketan Talaulikar ;Peter Psenak 
;陈然00080434;
Date: 2024年01月25日 15:38
Subject: New Version Notification for draft-chen-lsr-anycast-flag-05.txt

A new version of Internet-Draft draft-chen-lsr-anycast-flag-05.txt has been
successfully submitted by Ran Chen and posted to the
IETF repository.
 
Name: draft-chen-lsr-anycast-flag
Revision: 05
Title:Updates to Anycast Property advertisement for OSPFv2
Date: 2024-01-25
Group:Individual Submission
Pages:6
URL:  https://www.ietf.org/archive/id/draft-chen-lsr-anycast-flag-05.txt
Status:   https://datatracker.ietf.org/doc/draft-chen-lsr-anycast-flag/
HTMLized: https://datatracker.ietf.org/doc/html/draft-chen-lsr-anycast-flag
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-chen-lsr-anycast-flag-05
 
Abstract:
 
   Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast
   and as such the same value can be advertised by multiple routers.  It
   is useful for other routers to know that the advertisement is for an
   anycast identifier.
 
   Each prefix is advertised along with an 8-bit field of
   capabilities,by using the flag flield in the OSPFv2 Extended Prefix
   TLV [RFC7684], but the definition of anycast flag to identify the
   prefix as anycast has not yet been defined.
 
   This document updates [RFC7684], by defining a new flag in the OSPFv2
   Extended Prefix TLV Flags [RFC7684] to advertise the anycast
   property.
 
 
 
The IETF Secretariat___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Genart last call review of draft-ietf-lsr-ospfv3-extended-lsa-yang-27

[Meral Shirazipour via Datatracker]

Reviewer: Meral Shirazipour
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-lsr-ospfv3-extended-lsa-yang-27
Reviewer: Meral Shirazipour
Review Date: 2024-01-24
IETF LC End Date: 2024-01-25
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is almost ready to be published as Standards Track RFC.

Major issues:

Minor issues:

Nits/editorial comments:


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ietf-lsr-isis-fast-flooding IANA section

[John Scudder]

On Jan 24, 2024, at 12:51 PM, bruno.decra...@orange.com wrote:
> 
> as a correction we are proposing the following two changes

Looks good to me.

—John
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ietf-lsr-isis-fast-flooding IANA section

[bruno . decraene]

Hi John,

> From: John Scudder  
> Sent: Wednesday, January 24, 2024 1:46 PM

> Hi Authors,
>
> This isn't a full review of your document, however, I was looking at it and 
> noticed that in the IANA section, you create two registries with the "expert 
> review" policy. RFC 8126 says that you need to provide guidance to the 
> designated experts for such registries. If you plan on having these 
> registries grouped under 
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
>  then you will be covered since there is blanket guidance for all registries 
> in that group, but then you should mention in your IANA section that you want 
> them grouped there.

Thank you for your initial review, your comment and your suggestion.

You are very correct, and as a correction we are proposing the following two 
changes


§7.2
OLD: This document creates the following sub-TLV Registry
NEW: This document creates the following sub-TLV Registry under the "IS-IS TLV 
Codepoints" grouping

§7.3
OLD: This document also requests IANA to create a new registry for assigning 
Flag bits advertised in the Flags sub-TLV.
NEW: This document requests IANA to create a new registry, under the "IS-IS TLV 
Codepoints" grouping, for assigning Flag bits advertised in the Flags sub-TLV.


https://github.com/Bruno007/draft-lsr-isis-fast-flooding/commit/cbcbbd6d0aa21c91a073dd211609bd4ae95f8ab0

(modulo 2 typos that I've corrected on my local repo)

Comments are welcome.
We can also publish a new draft at your convenience. Just say so.

Thanks

--Bruno, on behalf of co-authors

> Thanks,

> -John

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Acee Lindem]

Speaking as WG Co-Chair and Document Shepherd: 

With the draft-ietf-lsr-isis-sr-vtn-mt-07 version, I believe we have reached 
consensus on publishing this informational document as a lower-scale mechanism 
for deployment of NRPs using IS-IS MT. 

However, before I request publication, I will be waiting for the following 
documents to progress in the SPRING WG. Both of these are normative references 
and I believe they are required components of the documented solution. 

[I-D.ietf-spring-resource-aware-segments]  
   
https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-08
[I-D.ietf-spring-sr-for-enhanced-vpn]
   
https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-for-enhanced-vpn-06  

From the standpoint of the LSR WG, the chairs view this work as completed and 
will be shifting focus to other LSR documents. 

Thanks,
Acee
  
> On Jan 8, 2024, at 5:50 PM, Acee Lindem  wrote:
> 
> This begins a two week LSR Working Group last call for the “Applicability of 
> IS-IS Multi-Topology (MT) for Segment Routing based Network Resource 
> Partition (NRP)”. Please express your support or objection prior to Tuesday, 
> January 23rd, 2024. 
> 
> Thanks,
> Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] draft-ietf-lsr-isis-fast-flooding IANA section

[John Scudder]

Hi Authors,

This isn't a full review of your document, however, I was looking at it and 
noticed that in the IANA section, you create two registries with the "expert 
review" policy. RFC 8126 says that you need to provide guidance to the 
designated experts for such registries. If you plan on having these registries 
grouped under 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
then you will be covered since there is blanket guidance for all registries in 
that group, but then you should mention in your IANA section that you want them 
grouped there.

Thanks,

—John
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [RTG-DIR] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05

[Hejia (Jia)]

Hi Acee and Chongfeng,

Yes, the latest version has addressed my comments. Thank you very much. The 
review can be closed.

B.R.
Jia

-邮件原件-
发件人: rtg-dir [mailto:rtg-dir-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2024年1月24日 3:16
收件人: Hejia (Jia) 
抄送: Chongfeng Xie ; Routing Directorate 
; draft-ietf-lsr-isis-sr-vtn-mt.all 
; last-call ; 
lsr 
主题: Re: [RTG-DIR] [Lsr] Rtgdir last call review of 
draft-ietf-lsr-isis-sr-vtn-mt-05

Hi Chongfeng, Jia, 

I believe that version -06 had the changes to align with the TEAS terminology - 
correct? This review is closed. 

Thanks,
Acee

> On Dec 14, 2023, at 2:29 AM, Hejia (Jia)  
> wrote:
> 
> Hi Chongfeng,
>  Thanks for your reply. Your reply looks reasonable.
>   B.R.
> Jia
>   发件人: Chongfeng Xie [mailto:chongfeng@foxmail.com]
> 发送时间: 2023年12月12日 13:14
> 收件人: Hejia (Jia) ; rtg-...@ietf.org
> 抄送: draft-ietf-lsr-isis-sr-vtn-mt.all 
> ; last-call 
> ; lsr 
> 主题: Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05
>Hi Jia,
>  Thanks for the review comments.
>  I see your major comment is about the terminology alignment, as replied to 
> Daniele, we will follow the decision in TEAS to update the terminologies in 
> next revision.
>  Please see some replies to the minor issues inline:
>   From: He Jia via Datatracker
> Date: 2023-12-11 16:09
> To: rtg-...@ietf.org
> CC: draft-ietf-lsr-isis-sr-vtn-mt.all; last-call; lsr
> Subject: [Lsr] Rtgdir last call review of 
> draft-ietf-lsr-isis-sr-vtn-mt-05
> Reviewer: He Jia
> Review result: Not Ready
>  Hello,
>  I have been selected as the Routing Directorate reviewer for this 
> draft. The Routing Directorate seeks to review all routing or 
> routing-related drafts as they pass through IETF last call and IESG 
> review, and sometimes on special request. The purpose of the review is to 
> provide assistance to the Routing ADs.
> For more information about the Routing Directorate, please see 
> https://wiki.ietf.org/en/group/rtg/RtgDir
>  Although these comments are primarily for the use of the Routing ADs, 
> it would be helpful if you could consider them along with any other 
> IETF Last Call comments that you receive, and strive to resolve them 
> through discussion or by updating the draft.
>  Document: draft-ietf-lsr-isis-sr-vtn-mt-05
> Reviewer: Jia He
> Review Date: December 10, 2023
> IETF LC End Date: date-if-known
> Intended Status: Informational
>  Summary:
> I have read the review comments from Daniele about the concept of 
> enhanced VPN, and the relationship with other existing terms. I agree 
> with his suggestion to follow the discussion and align the draft with 
> the output. In addition, some minor issues and also nits are found out 
> as follows and should be considered prior to publication.
>  Minor Issues:
> 1、In Section 1, it is said "Segment Identifiers (SIDs) can be used to 
> represent both the topological instructions and the set of network 
> resources allocated by network nodes to a VTN." Is it "allocated by 
> network nodes" or "allocated to network nodes"? If it is "network 
> resources allocated by network nodes", why not "allocated by 
> centralized controllers" as well? If it is "network resources 
> allocated to network nodes" which are assocated with a VTN, why not " 
> allocated to network links" as well? Is there any special consideration by 
> saying "network nodes" only here?
>  [Chongfeng]： The description is a little bit confusing, actually it should 
> be "network resources of the network nodes and links which are allocated to a 
> VTN/NRP". We will update it in next revision.
> 2、In Section 4, "For SRv6 data plane, the SRv6 SIDs associated 
> with the same VTN can be used together to build SRv6 paths with the 
> topological and resource constraints of the VTN taken into consideration." Is 
> "SRv6 Locator" missing?
>  [Chongfeng] SRv6 Locator is the covering prefix part of the SRv6 SIDs. In 
> SRv6 segment list, the SRv6 SIDs are used to indicate the forwarding path and 
> the set of resources used for packet processing. So the description is 
> correct.
>   Nits:
> 1、Section 2, TLV 223 (MT IS Neighbor Attribute) is defined in RFC 
> 5311, which is not referenced in the draft. 2、Section 1,  Paragraph 3, 
> last sentence, s/...need to be distributed using control plane/...need 
> to be distributed using a control plane 3、Section 2, Paragraph 1, last 
> sentecne, s/MT-ID could be used as the identifier of VTN in control 
> plane./MT-ID could be used as the identifier of VTN in the control 
> plane. 4、Section 2, "IS-IS Multi-Topology [RFC5120]" and "IS-IS 
> Multi-Topology Routing (MTR) [RFC5120]" are both used in the draft. It is 
> suggested to keep consistent throughout the draft.
>   [Chongfeng] Thanks for catching the nits, we will resolve them in next 
> revision.
>  Best regards,
> Chongfeng
>___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>