date:20231130

[Lsr] Fw:New Version Notification for draft-gong-lsr-ospf-unreachable-link-04.txt

2023-11-30 Thread Liyan Gong





Dear Chairs and WG,





We have updated the draft which incorporated the suggestions from Acee and Loa. 
Thank you very  much.





The main changes are as follows:




add the section 4.1 for "Stub Router Advertisement Backward Compatibility"

correct the "Router Functional Capabilities TLV”with "Router Informational 
Capabilities TLV"

some description optimizations. 





The draft and diff can be found in the following link.


https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/





We would like to request adoption call and look forward to the views of the 
Working Group. 





Best Regards,


Liyan




邮件原文发件人：internet-drafts 收件人：Acee Lindem 
,Changwang Lin ,Liyan Gong 
,Mengxiao Chen ,Ran Chen 
,Weiqiang Cheng ,Yanrong 
Liang 抄　送: (无)发送时间：2023-12-01 11:00:04主题：New 
Version Notification for draft-gong-lsr-ospf-unreachable-link-04.txtA new 
version of Internet-Draft draft-gong-lsr-ospf-unreachable-link-04.txthas been 
successfully submitted by Liyan Gong and posted to theIETF repository.Name: 
draft-gong-lsr-ospf-unreachable-linkRevision: 04Title:Advertising 
Unreachable Links in OSPFDate: 2023-11-27Group:Individual 
SubmissionPages:9URL:  
https://www.ietf.org/archive/id/draft-gong-lsr-ospf-unreachable-link-04.txtStatus:
   
https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/HTMLized: 
https://datatracker.ietf.org/doc/html/draft-gong-lsr-ospf-unreachable-linkDiff: 

https://author-tools.ietf.org/iddiff?url2=draft-gong-lsr-ospf-unreachable-link-04Abstract:
   This document proposes the method to advertise links as unreachable   in 
OSPF. In some scenarios, there are requirements to advertise   unreachable 
links in OSPF for purposes other than building the   normal Shortest Path 
Tree.The IETF SecretariatSubject：New Version Notification for 
draft-gong-lsr-ospf-unreachable-link-04.txtA new version of Internet-Draft 
draft-gong-lsr-ospf-unreachable-link-04.txthas been successfully submitted by 
Liyan Gong and posted to theIETF repository.Name: 
draft-gong-lsr-ospf-unreachable-linkRevision: 04Title:Advertising 
Unreachable Links in OSPFDate: 2023-11-27Group:Individual 
SubmissionPages:9URL:  
https://www.ietf.org/archive/id/draft-gong-lsr-ospf-unreachable-link-04.txtStatus:
   
https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/HTMLized: 
https://datatracker.ietf.org/doc/html/draft-gong-lsr-ospf-unreachable-linkDiff: 

https://author-tools.ietf.org/iddiff?url2=draft-gong-lsr-ospf-unreachable-link-04Abstract:
   This document proposes the method to advertise links as unreachable   in 
OSPF. In some scenarios, there are requirements to advertise   unreachable 
links in OSPF for purposes other than building the   normal Shortest Path 
Tree.The IETF Secretariat

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

Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang

2023-11-30 Thread tom petch

Why is this review on rt...@ietf.org and not on lsr@ietf.org?

Tom Petch

From: rtgwg  on behalf of julien.meu...@orange.com 

Sent: 29 November 2023 16:03
To: rtg-...@ietf.org
Cc: rtg-...@ietf.org; draft-ietf-ospf-sr-yang@ietf.org; rt...@ietf.org
Subject: RtgDir Last Call Review: draft-ietf-ospf-sr-yang

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-ospf-sr-yang-22
Reviewer: Julien Meuric
Review Date: 2023-11-29
Intended Status: Standard Tracks


*Summary:*

This document is basically ready for publication but has nits that
should be considered prior to publication.


*Comments:*

- The very first paragraph of the introduction/overview section
summarizes the basis of YANG, XML, JSON, data models... I believe we are
now far beyond those general considerations and we could skip that
paragraph.
- In the grouping "ospfv3-lan-adj-sid-sub-tlvs" (p23), the leaf
"neighbor-router-id" uses type "dotted-quad". This is consistent with
RFC 8666 which specifies the associated OSPFv3 TLV, but we had a
discussion about the type for router-id in the TE YANG models. The
current resolution on TEAS side will be to consider a union of
dotted-quad and ipv6-address. I wonder how much RTGWG would be ready to
consider a superset of the existing OSPFv3 TLVs.


*Nits:*

- Multiple times in description: s/SR specific/SR-specific/
- Multiple times in description: s/flag bits list/flag list/
- Multiple times in description: s/flags list/flag list/
- The description fields use a mix of "Adj sid", "adj sid", "Adj SID"...
sometimes with hyphens (not to mention the full expansions). A single
phrase should be chosen and used all along the module.
- A few description starts with "The..." (e.g., in
"ospfv2-extended-prefix-range-tlvs" on p 19, or v3 on p 22) while most
of them don't. For consistency, it should be dropped from every brief
description.

- In the grouping "ospfv3-prefix-sid-sub-tlvs" (p 21 and all resulting
pieces of tree): s/perfix-sid-sub-tlvs/prefix-sid-sub-tlvs/
- In the same grouping, the description of the container should be
"Prefix SID sub-TLV *list*." (and "Prefix SID sub-TLV." reserved for the
following list element).
- In the container "ti-lfa" (p 25): s/Enables TI-LFA/Enable TI-LFA/ [Not
wrong, but should be consistent with others.]
- In the same container (p 26): "s/Topology Independent Loop Free
Alternate/Topology-Independent Loop-Free Alternate/
- In section 3 (p 37): s/The YANG modules [...] define/The YANG module
[...] defines/
- In the same section: s/in the modules/in the module/
- In the same section: s/Module ietf-ospf-sr/The module ietf-ospf-sr/


Thanks,

Julien


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

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

2023-11-30 Thread Tony Li


Hi Bruno,

No, we are not going to document the behavior of every implementation for every 
TLV, sub-TLV, and sub-sub-TLV for you. We don’t have that kind of access nor 
would we get permission to do so. And we’re not young enough.

The point of clearly advertising capabilities is so that implementations have a 
scalable, automated way of providing what you ask for: information to network 
management. Modern networking is all about automation, and we are trying to 
push in that direction.

Regards,
Tony

> On Nov 30, 2023, at 2:50 AM, bruno.decra...@orange.com wrote:
> 
> Hi authors,
>  
> We are documenting existing behavior, codifying what we believe most 
> implementations are already doing
>  
> Could the authors share with the WG what are those existing behaviors (TLVs 
> supporting MP-TLV) and implementations?
>  
> Many be this is a reason for some disconnect as
> On one hand, if all implementations already support MP-TLV for all TLVs 
> indicated in this draft, then there is less deployment issues/risks. 
> (Although there are still some risks as not all nodes will get the support at 
> the same time, in particular for legacy platforms which will lack the MP TLV 
> support for years)
> On the other hand, if only a couple of implementations support MP-TLV for a 
> couple of TLVs,  the risk seems much higher.
>  
> If this is not known (1), we can’t assume that this is safe and deployable 
> without risk.
>  
> (1) or not sharable for some reasons, although a priori vendors should be 
> proud of their innovations
>  
> If the MP-TLV support capability declaration  doesn’t mean support all 
> relevant TLVs, and conform to the draft can’t assure the interoperability, 
> then, what the purpose of this draft?
> Same question with :s/draft/capability
> Although I believe I had already raised that point.
>  
> Regards,
> --Bruno
>  
> From: Lsr  On Behalf Of Tony Li
> Sent: Thursday, November 30, 2023 5:06 AM
> To: Aijun Wang 
> Cc: Yingzhen Qu ; 
> draft-pkaneria-lsr-multi-...@ietf.org; lsr 
> Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
> (11/17/2023 - 12/09/2023)
>  
>  
> Hi Aijun,
>  
> If the MP-TLV support capability declaration  doesn’t mean support all 
> relevant TLVs, and conform to the draft can’t assure the interoperability, 
> then, what the purpose of this draft?
>  
>  
> We are documenting existing behavior, codifying what we believe most 
> implementations are already doing, and documenting the direction that we 
> think we should be going.
>  
> 
> 
> If you persist this direction, as proposed by Bruno, I think that documents 
> the capabilities(includes the definition of the key) for every TLV in one 
> Yang file(draft-isis-pics-multi-TLV”?) maybe more better.
>  
>  
> Then YANG model for reporting capabilities is a mostly orthogonal document.
>  
> 
> 
> The operator can compare such yang files from different vendor, and if they 
> support the multipart of the same TLV, and the key is same, then the operator 
> can safely enable the sending and receiving of the multi-part of this TLV.
>  
>  
> That alone is not sufficient.
>  
> 
> 
> Or else, we should think other solution to solve this issue.
>  
>  
> There is no other solution.
>  
> Regards,
> Tony
>  
>  
> 
> 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] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

2023-11-30 Thread Reshad Rahman

 I support adoption of this document by the WG.
Regards,Reshad.
On Friday, November 17, 2023, 12:24:12 PM EST, Yingzhen Qu 
 wrote:  
 
 Hi,
This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org)
Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.
Thanks,Yingzhen ___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
  ___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

2023-11-30 Thread Henk Smit

Support.
 
As the mechanism described in the draft has already been implemented by the 
three
largest vendors of ISP-class routers, and that software has been deployed in 
real networks
today, we better document this asap in an RFC.
 
henk.
 
 

> On 11/17/2023 6:23 PM CET Yingzhen Qu  wrote:
>  
>  
> Hi,
>  
> This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
> draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org) 
> https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/
>  
> Please send your support or objection to the list before December 9th, 2023. 
> An extra week is allowed for the US Thanksgiving holiday.
>  
> Thanks,
> Yingzhen 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

2023-11-30 Thread bruno . decraene

Hi authors,


  *   We are documenting existing behavior, codifying what we believe most 
implementations are already doing

Could the authors share with the WG what are those existing behaviors (TLVs 
supporting MP-TLV) and implementations?

Many be this is a reason for some disconnect as

  *   On one hand, if all implementations already support MP-TLV for all TLVs 
indicated in this draft, then there is less deployment issues/risks. (Although 
there are still some risks as not all nodes will get the support at the same 
time, in particular for legacy platforms which will lack the MP TLV support for 
years)
  *   On the other hand, if only a couple of implementations support MP-TLV for 
a couple of TLVs,  the risk seems much higher.

If this is not known (1), we can’t assume that this is safe and deployable 
without risk.

(1) or not sharable for some reasons, although a priori vendors should be proud 
of their innovations


  *   If the MP-TLV support capability declaration  doesn’t mean support all 
relevant TLVs, and conform to the draft can’t assure the interoperability, 
then, what the purpose of this draft?
Same question with :s/draft/capability
Although I believe I had already raised that point.

Regards,
--Bruno

From: Lsr  On Behalf Of Tony Li
Sent: Thursday, November 30, 2023 5:06 AM
To: Aijun Wang 
Cc: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)


Hi Aijun,

If the MP-TLV support capability declaration  doesn’t mean support all relevant 
TLVs, and conform to the draft can’t assure the interoperability, then, what 
the purpose of this draft?


We are documenting existing behavior, codifying what we believe most 
implementations are already doing, and documenting the direction that we think 
we should be going.



If you persist this direction, as proposed by Bruno, I think that documents the 
capabilities(includes the definition of the key) for every TLV in one Yang 
file(draft-isis-pics-multi-TLV”?) maybe more better.


Then YANG model for reporting capabilities is a mostly orthogonal document.



The operator can compare such yang files from different vendor, and if they 
support the multipart of the same TLV, and the key is same, then the operator 
can safely enable the sending and receiving of the multi-part of this TLV.


That alone is not sufficient.



Or else, we should think other solution to solve this issue.


There is no other solution.

Regards,
Tony



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] RtgDir Last Call Review: draft-ietf-ospf-sr-yang

2023-11-30 Thread julien . meuric


Hi Tom,

That looks to me like a human mistake on the CC'ed recipients. Using the 
directorate web form may have prevented it, but that would have been 
much less fun.


Thanks for your careful checking. I'd be happy to hear your opinion on 
the router-id type.


Julien


On 29/11/2023 17:33, tom petch wrote:

Why is this review on rt...@ietf.org and not on lsr@ietf.org?

Tom Petch

From: rtgwg  on behalf of julien.meu...@orange.com 

Sent: 29 November 2023 16:03
To: rtg-...@ietf.org
Cc: rtg-...@ietf.org; draft-ietf-ospf-sr-yang@ietf.org; rt...@ietf.org

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-ospf-sr-yang-22
Reviewer: Julien Meuric
Review Date: 2023-11-29
Intended Status: Standard Tracks


*Summary:*

This document is basically ready for publication but has nits that
should be considered prior to publication.


*Comments:*

- The very first paragraph of the introduction/overview section
summarizes the basis of YANG, XML, JSON, data models... I believe we are
now far beyond those general considerations and we could skip that
paragraph.
- In the grouping "ospfv3-lan-adj-sid-sub-tlvs" (p23), the leaf
"neighbor-router-id" uses type "dotted-quad". This is consistent with
RFC 8666 which specifies the associated OSPFv3 TLV, but we had a
discussion about the type for router-id in the TE YANG models. The
current resolution on TEAS side will be to consider a union of
dotted-quad and ipv6-address. I wonder how much RTGWG would be ready to
consider a superset of the existing OSPFv3 TLVs.


*Nits:*

- Multiple times in description: s/SR specific/SR-specific/
- Multiple times in description: s/flag bits list/flag list/
- Multiple times in description: s/flags list/flag list/
- The description fields use a mix of "Adj sid", "adj sid", "Adj SID"...
sometimes with hyphens (not to mention the full expansions). A single
phrase should be chosen and used all along the module.
- A few description starts with "The..." (e.g., in
"ospfv2-extended-prefix-range-tlvs" on p 19, or v3 on p 22) while most
of them don't. For consistency, it should be dropped from every brief
description.

- In the grouping "ospfv3-prefix-sid-sub-tlvs" (p 21 and all resulting
pieces of tree): s/perfix-sid-sub-tlvs/prefix-sid-sub-tlvs/
- In the same grouping, the description of the container should be
"Prefix SID sub-TLV *list*." (and "Prefix SID sub-TLV." reserved for the
following list element).
- In the container "ti-lfa" (p 25): s/Enables TI-LFA/Enable TI-LFA/ [Not
wrong, but should be consistent with others.]
- In the same container (p 26): "s/Topology Independent Loop Free
Alternate/Topology-Independent Loop-Free Alternate/
- In section 3 (p 37): s/The YANG modules [...] define/The YANG module
[...] defines/
- In the same section: s/in the modules/in the module/
- In the same section: s/Module ietf-ospf-sr/The module ietf-ospf-sr/


Thanks,

Julien





smime.p7s
Description: S/MIME Cryptographic Signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Fw:New Version Notification for draft-gong-lsr-ospf-unreachable-link-04.txt

Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

Re: [Lsr] RtgDir Last Call Review: draft-ietf-ospf-sr-yang

7 matches

Site Navigation

Mail list logo

Footer information