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

[Ketan Talaulikar]

Hi Yingzhen,

I support the adoption of this document by the WG. The document has been
already widely discussed in the WG for a few years now - the problem is
well acknowledged and the solution/approach is the best/practical way to go
about it in my opinion.

Thanks,
Ketan


On Fri, Nov 17, 2023 at 10:54 PM 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

[Lsr] 答复: WG Adoption IPR Poll for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03

[zhao.detao]

Hi Acee，
I am not aware of any IPR associated with this document.

thanks





赵德涛
软件平台开发一部/有线研究院/有线产品经营部
 
中兴通讯股份有限公司
南京市紫荆花路68号南研一期, 邮编: 210012
T: +86 15951883174  M: +86 15951883174
E: zhao.de...@zte.com.cn




Original


From: AceeLindem 
To: draft-chen-lsr-prefix-extended-fl...@ietf.org 
;
Cc: Lsr ;
Date: 2023年11月17日 23:48
Subject: WG Adoption IPR Poll for "Prefix Flag Extension for OSPFv2 and OSPFv3" 
- draft-chen-lsr-prefix-extended-flags-03

Co-Authors,  
 
Are you aware of any IPR that applies to 
draft-chen-lsr-prefix-extended-flags-03?
 
If so, has this IPR been disclosed in compliance with IETF IPR rules  (see RFCs 
3979, 4879, 3669 and 5378 for more details).
 
There currently aren’t any IPR declarations on this simple protocol extension - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-chen-lsr-prefix-extended-flags
 
If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.
 
If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.
 
As one would hope, there currently aren’t any IPR declarations on this simple 
protocol extension.
 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-chen-lsr-prefix-extended-flags
 
Thanks,
Acee___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption IPR Poll for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03

[chen.ran]

Hi Acee，
I am not aware of any IPR associated with this document.

Best Regards，
Ran



 




Original
 




From:AceeLindem


To:draft-chen-lsr-prefix-extended-fl...@ietf.org;


Cc:Lsr;


Date:2023-11-17 23:49:12


Subject:[Lsr] WG Adoption IPR Poll for "Prefix Flag Extension for OSPFv2 and 
OSPFv3" - draft-chen-lsr-prefix-extended-flags-03






Co-Authors, 

Are you aware of any IPR that applies to 
draft-chen-lsr-prefix-extended-flags-03?

If so, has this IPR been disclosed in compliance with IETF IPR rules  (see RFCs 
3979, 4879, 3669 and 5378 for more details).

There currently aren’t any IPR declarations on this simple protocol extension - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-chen-lsr-prefix-extended-flags

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

As one would hope, there currently aren’t any IPR declarations on this simple 
protocol extension.

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-chen-lsr-prefix-extended-flags

Thanks,
Acee
___
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] Question on draft-qgp-lsr-isis-pics-yang

[Acee Lindem]

Speaking as WG member: 

Ok - I can see that I’m in the minority here in thinking this should be at a 
less granular level than specific TLVs. We can see where the more granular 
definition takes us and I’ll help with the OSPFv2/OSPFv3 models. 

Hopefully, the enthusiasm for implementation will match our IGP protocol 
support modeling efforts. 

Thanks,
Acee

> On Nov 17, 2023, at 4:14 AM, bruno.decra...@orange.com wrote:
> 
>Orange Restricted
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Thursday, November 16, 2023 11:33 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Loa Andersson ; lsr@ietf.org
> Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
>  Speaking as a WG contributor: 
>  Hi Les, 
>  I think a simpler name is better - perhaps ietf-isis-feature-support.yang 
> with YANG prefix isis-fs would be better.  Which brings me to my next and 
> more important point… 
>  Like carbon neutrality, everyone at the LSR WG meeting who had an opinion 
> thought such a YANG model would be operationally useful. However, I think the 
> level of granularity is key.
> [Bruno] +1
> I agree that the level of granularity is key.
> I’d rather call for a significant granularity (but I’d welcome any pushback).
> Personally, I don’t see why per TLV granularity would not be ok: it’s ok to 
> implement which is more work, so just listing the supported TLV and sub-TLV 
> should be doable. In any case, operators, pre-sales and support engineers 
> will likely need this information some day. So let’s just fill it once for 
> all and have it available for all persons.
> I’d would even call for more granularity. E.g. for RFC 5130, for “32-bit 
> Administrative Tag Sub-TLV 1”, “On receipt, an implementation MAY consider 
> only one encoded tag, in which case, the first encoded tag MUST be considered 
> and any additional tags ignored. »
> To me, if the WG bothered making such granularity at the 
> feature/TLV/implementation level, we need such granularity at the reporting 
> level. And that’s not theoretical, I had to check that for a project a month 
> ago. At best, it’s indicated in the vendors documentation, so the data is 
> there, so let’s make it friendly to digest. At worst, we need to involve 
> expensive people .
> If we want less granularity, let’s do less granularity in spec (everything is 
> MUST)
>  https://datatracker.ietf.org/doc/html/rfc5130#section-3.1
>  Thanks,
> --Bruno
>   I believe that having a separate data node for each TLV/sub-TLV as was done 
> in the example ietf-isis-pics-sr-mpls.yang module is way too granular to be 
> useful. Rather, the YANG reporting should be done at the feature level. Also, 
> does a distinction need to be made as to whether the IS-IS node supports the 
> feature or both supports it and has it enabled (as would be the case for 
> non-backward compatible features)? 
>  Thanks, 
> Acee
>  On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg) 
>  wrote:
>  Loa -
> 
> I agree with you that simply "IS-IS Support" may not be the best choice.
> Although, the meeting minutes have not yet been posted, as I recall my 
> response to Tony Li's suggestion of "IS-IS Support" was "Yes - something like 
> that."
> 
> The draft authors have not yet discussed this - but we will and share the 
> proposed new name.
> Other suggestions welcomed.
> 
>   Les
> 
> -Original Message-
> From: Lsr  On Behalf Of Loa Andersson
> Sent: Thursday, November 16, 2023 2:06 AM
> To: lsr@ietf.org
> Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
> 
> Working Group,
> 
> During the presentation of draft-qgp-lsr-isis-pics-yang there was a
> rather strong opposition in the chat against using the ISO-term "PICS"
> in an IETF document.
> 
> I think the term "Support" was suggested (excuse me if I missed
> something), but I'm not that impressed, and would rather like to see
> something like - "Supported Protocol Aspects".
> 
> /Loa
> --
> Loa Anderssonemail: l...@pi.nu
> Senior MPLS Expert  loa.pi...@gmail.com
> Bronze Dragon Consulting phone: +46 739 81 21 64
> 
> ___
> 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
>  
> 
> 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 

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

[Paul Wells (pauwells)]

Support. I've implemented parts of the draft and think it's a practical 
approach.

Thanks,
Paul

On 11/17/23 11:23, 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)

[Les Ginsberg (ginsberg)]

+2 support adoption as coauthor

(Chairs – is it really necessary for the authors to express support for their 
own draft? )

   Les

From: Tony Przygienda 
Sent: Friday, November 17, 2023 10:29 AM
To: Tony Li 
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)

+1, support adoptoinb as co-author

On Fri, Nov 17, 2023 at 6:58 PM Tony Li 
mailto:tony...@tony.li>> wrote:

I support adoption as co-author.

T



On Nov 17, 2023, at 9:23 AM, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> 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)

[Tony Przygienda]

+1, support adoptoinb as co-author

On Fri, Nov 17, 2023 at 6:58 PM Tony Li  wrote:

>
> I support adoption as co-author.
>
> T
>
>
> On Nov 17, 2023, at 9:23 AM, 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)

[Tony Li]

I support adoption as co-author.

T


> On Nov 17, 2023, at 9:23 AM, 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

Re: [Lsr] IPR Poll for draft-pkaneria-lsr-multi-tlv

[Tony Li]

"No, I'm not aware of any IPR that applies to this draft”


> On Nov 17, 2023, at 9:05 AM, Les Ginsberg (ginsberg)  
> wrote:
> 
> "No, I'm not aware of any IPR that applies to this draft"

___
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)

[Acee Lindem]

Speaking as WG member:

This draft has already resulted in a lot of good discussion and iteration. I 
support adoption as formalization of the existing solution with configuration, 
protocol level capability reporting, and IANA multi-TLV specification.

Thanks,
Acee

> On Nov 17, 2023, at 12:23, 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

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

[Yingzhen Qu]

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

Re: [Lsr] IPR Poll for draft-pkaneria-lsr-multi-tlv

[Les Ginsberg (ginsberg)]

"No, I'm not aware of any IPR that applies to this draft"

   Les

From: Yingzhen Qu 
Sent: Friday, November 17, 2023 9:01 AM
To: draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Cc: lsr-chairs 
Subject: IPR Poll for draft-pkaneria-lsr-multi-tlv

Hi,


This is an IPR call for draft-pkaneria-lsr-multi-tlv 
(draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS 
(ietf.org))


The authors and contributors please respond to this IPR call.



Please state either:

"No, I'm not aware of any IPR that applies to this draft"

or

"Yes, I'm aware of IPR that applies to this draft"



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3669, 5378 and 8179 for more details)?



If yes to the above, please state either:



"Yes, the IPR has been disclosed in compliance with IETF IPR rules"

or

"No, the IPR has not been disclosed"



If you answer no, please provide any additional details you think

appropriate.



If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. The response needs to be sent to the LSR WG mailing

list. The document will not advance to the next stage until a

response has been received from each author and contributor.



If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,

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

Re: [Lsr] IPR Poll for draft-pkaneria-lsr-multi-tlv

[Antoni Przygienda]

No, I'm not aware of any IPR that applies to this draf




Juniper Business Use Only

From: Yingzhen Qu 
Date: Friday, 17 November 2023 at 18:00
To: draft-pkaneria-lsr-multi-...@ietf.org 
, lsr 
Cc: lsr-chairs 
Subject: IPR Poll for draft-pkaneria-lsr-multi-tlv
[External Email. Be cautious of content]

Hi,


This is an IPR call for draft-pkaneria-lsr-multi-tlv 
(draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS 
(ietf.org))


The authors and contributors please respond to this IPR call.



Please state either:

"No, I'm not aware of any IPR that applies to this draft"

or

"Yes, I'm aware of IPR that applies to this draft"



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3669, 5378 and 8179 for more details)?



If yes to the above, please state either:



"Yes, the IPR has been disclosed in compliance with IETF IPR rules"

or

"No, the IPR has not been disclosed"



If you answer no, please provide any additional details you think

appropriate.



If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. The response needs to be sent to the LSR WG mailing

list. The document will not advance to the next stage until a

response has been received from each author and contributor.



If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,

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

[Lsr] IPR Poll for draft-pkaneria-lsr-multi-tlv

[Yingzhen Qu]

Hi,

This is an IPR call for draft-pkaneria-lsr-multi-tlv
(draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org)
)

The authors and contributors please respond to this IPR call.

Please state either:
"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.


If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. The response needs to be sent to the LSR WG mailing
list. The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

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

Re: [Lsr] WG Adoption IPR Poll for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03

[Ketan Talaulikar]

Hi Acee,

I am not aware of any IPR associated with this document.

Thanks,
Ketan


On Fri, Nov 17, 2023 at 9:24 PM Peter Psenak  wrote:

> Hi Acee,
>
> I'm not aware of any IPR that applies to
> draft-chen-lsr-prefix-extended-flags-03.
>
> thanks,
> Peter
>
> On 17/11/2023 16:48, Acee Lindem wrote:
> > Co-Authors,
> >
> > Are you aware of any IPR that applies to
> draft-chen-lsr-prefix-extended-flags-03?
> >
> > If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
> >
> > There currently aren’t any IPR declarations on this simple protocol
> extension -
> https://datatracker.ietf.org/ipr/search/?submit=draft=draft-chen-lsr-prefix-extended-flags
> >
> > If you are listed as a document author or contributor please respond
> > to this email regardless of whether or not you are aware of any
> > relevant IPR. *The response needs to be sent to the LSR WG mailing
> > list.* The document will not advance to the next stage until a
> > response has been received from each author and contributor.
> >
> > If you are on the LSR WG email list but are not listed as an author or
> > contributor, then please explicitly respond only if you are aware of
> > any IPR that has not yet been disclosed in conformance with IETF rules.
> >
> > As one would hope, there currently aren’t any IPR declarations on this
> simple protocol extension.
> >
> >
> https://datatracker.ietf.org/ipr/search/?submit=draft=draft-chen-lsr-prefix-extended-flags
> >
> > Thanks,
> > Acee
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)

[Acee Lindem]

Speaking as WG Member:

I support WG adoption. These simple extensions for OSPFv2 and OSPFv3 are 
required for consistent, concise, and extendible advertisement of binary prefix 
attributes. 

Thanks,
Acee

> On Nov 17, 2023, at 11:01 AM, Acee Lindem  wrote:
> 
> LSR WG, 
> 
> This starts the Working Group adoption call for 
> draft-chen-lsr-prefix-extended-flags-03. Please send your 
> support or objection to this list before December 9th, 2023. The extra week 
> is to allow for the US Thanksgiving holiday. 
> 
> 
> Thanks,
> Acee


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

[Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03 (Corrected End Date)

[Acee Lindem]

LSR WG, 

This starts the Working Group adoption call for 
draft-chen-lsr-prefix-extended-flags-03. Please send your 
support or objection to this list before December 9th, 2023. The extra week is 
to allow for the US Thanksgiving holiday. 


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

[Lsr] WG Adoption Call for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03

[Acee Lindem]

LSR WG, 

This starts the Working Group adoption call for 
draft-chen-lsr-prefix-extended-flags-03. Please send your 
support or objection to this list before December 2nd, 2023. The extra week is 
to allow for the US Thanksgiving holiday. 


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

Re: [Lsr] WG Adoption IPR Poll for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03

[Peter Psenak]

Hi Acee,

I'm not aware of any IPR that applies to 
draft-chen-lsr-prefix-extended-flags-03.


thanks,
Peter

On 17/11/2023 16:48, Acee Lindem wrote:

Co-Authors,

Are you aware of any IPR that applies to 
draft-chen-lsr-prefix-extended-flags-03?

If so, has this IPR been disclosed in compliance with IETF IPR rules  (see RFCs 
3979, 4879, 3669 and 5378 for more details).

There currently aren’t any IPR declarations on this simple protocol extension - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-chen-lsr-prefix-extended-flags

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

As one would hope, there currently aren’t any IPR declarations on this simple 
protocol extension.

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-chen-lsr-prefix-extended-flags

Thanks,
Acee


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

[Lsr] WG Adoption IPR Poll for "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-chen-lsr-prefix-extended-flags-03

[Acee Lindem]

Co-Authors, 

Are you aware of any IPR that applies to 
draft-chen-lsr-prefix-extended-flags-03?

If so, has this IPR been disclosed in compliance with IETF IPR rules  (see RFCs 
3979, 4879, 3669 and 5378 for more details).

There currently aren’t any IPR declarations on this simple protocol extension - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-chen-lsr-prefix-extended-flags

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

As one would hope, there currently aren’t any IPR declarations on this simple 
protocol extension.

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-chen-lsr-prefix-extended-flags

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

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

[Ketan Talaulikar]

By this logic, when the Prefix Originator is set to 0.0.0.0, it means there
is no Prefix Originator ... ;-)

Not sure why we are even arguing about this :-(


On Wed, Nov 15, 2023 at 1:50 PM Aijun Wang 
wrote:

> Hi, Ketan:
>
> The logic is that why we can set router-id equal to 0.0.0.0 to indicate
> some information in some standards, but we can’t set prefix originator
> information to 0.0.0.0 to indicate the prefix is unreachable?
>
> Here are again two examples for the usages of router-id’s value as 0.0.0.0
> to indicate some information, one is for OSPF another is for IS-IS:
> 1) For OSPF: https://www.rfc-editor.org/rfc/rfc5340.html#appendix-A.3.2
>
> Designated Router ID
>The sending router's view of the identity of the Designated Router for 
> this network.  The Designated Router is identified by its Router ID.  It is 
> set to 0.0.0.0 if there is no Designated Router.
>
> Backup Designated Router ID
>The sending router's view of the identity of the Backup Designated Router 
> for this network.  The Backup Designated Router is identified by its IP 
> Router ID.  It is set to 0.0.0.0 if there is no Backup Designated Router.
>
>
> 2) For IS-IS: https://www.rfc-editor.org/rfc/rfc7981.html#appendix-A
>
> If the originating node does not support IPv4, then the reserved value 
> 0.0.0.0 MUST be used in the Router ID field, and the IPv6 TE Router ID 
> sub-TLV [RFC5316 ] MUST be present in 
> the TLV.
>
>
> What I insist is that there are already containers that can be used to
> indicate the unreachable information, why we pursue other non-existing,
> non-standard container?
>
> Aijun Wang
> China Telecom
>
> On Nov 7, 2023, at 18:16, Ketan Talaulikar  wrote:
>
> 
> Hi Aijun,
>
> I am not sure what "logic" you are looking for while being somewhat
> dismissive of the arguments/logic provided.
>
> Let us agree to disagree.
>
> At least I've concluded that it is no more fruitful for me to try to
> convince you. C'est la vie ...
>
> Thanks,
> Ketan
>
>
> On Tue, Nov 7, 2023 at 11:08 AM Aijun Wang 
> wrote:
>
>> Hi, Ketan:
>>
>> There are many examples within IETF that special values has special
>> meanings, please see:
>>
>> 1)
>> https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
>>
>> 2)
>> https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
>>
>> 3)
>> https://www.iana.org/assignments/iana-as-numbers-special-registry/iana-as-numbers-special-registry.xhtml
>>
>> 4) LS-Infinity
>>
>> Then, please state clearly that why we cannot define specific value for
>> prefix originator to indicate the unreachability.
>>
>> We need the logic that supports your conclusions. Until now, none.
>>
>> Or anyone else can elaborate the logic more clearly?
>>
>> Aijun Wang
>> China Telecom
>>
>> On Nov 7, 2023, at 10:19, Ketan Talaulikar  wrote:
>>
>> 
>> Hi Aijun,
>>
>> I realize that continuing this argument with you is futile.
>>
>> However, perhaps one last response that I would address not to you but
>> for other WG members (if any one is still following this thread).
>>
>> On Tue, Nov 7, 2023 at 9:54 AM Aijun Wang 
>> wrote:
>>
>>> Hi, Ketan and Les:
>>>
>>> There are two sub-TLVs to indicate the source information of the prefix
>>> within OSPF——“Prefix Source OSPF Router ID” and “Prefix Source OSPF Router
>>> Address”
>>>
>>> What’s you refer to is the first sub-TLV, for the second sub-TLV, we
>>> haven’t such statements, this is also true for IS-IS,  as Les pointed out.
>>>
>>
>> KT> I am not a lawyer. The semantics for Prefix Source OSPF Router
>> Address should be clear to anyone that reads the procedures in Sec 3.
>>
>>
>>>
>>>
>>> So, contrary to your happiness :) this give us the room to define the
>>> specific value to indicate “unreachability”.
>>>
>>> And, to Ketan again, until now, you don’t explain clearly that if we
>>> can’t define specific value for “unreachability” why can we define the
>>> specific value for “LS-Infinity”?
>>>
>>
>> KT> For LS-Infinity - please read RFC2328.
>>
>> Thanks,
>> Ketan
>>
>>
>>>
>>>
>>> Aijun Wang
>>> China Telecom
>>>
>>> On Nov 7, 2023, at 09:23, Les Ginsberg (ginsberg) >> 40cisco@dmarc.ietf.org> wrote:
>>>
>>> 
>>>
>>> Ketan –
>>>
>>>
>>>
>>> I am very happy to be wrong in this case. 
>>>
>>> We are in full agreement.
>>>
>>>
>>>
>>> Les
>>>
>>>
>>>
>>>
>>>
>>> *From:* Lsr  *On Behalf Of * Ketan Talaulikar
>>> *Sent:* Monday, November 6, 2023 11:52 PM
>>> *To:* Les Ginsberg (ginsberg) 
>>> *Cc:* John Drake ; Peter Psenak
>>> (ppsenak) ; Aijun Wang ;
>>> lsr@ietf.org
>>> *Subject:* Re: [Lsr] Technical questions for draft about unreachable
>>> prefixes announcement
>>>
>>>
>>>
>>> Hi Les,
>>>
>>>
>>>
>>> I disagree with your reading of RFC9084 (OSPF Prefix Originator).
>>>
>>>
>>>
>>> Sec 1
>>>
>>> This document proposes extensions to the OSPF protocol for the inclusion
>>> of information associated with the router originating the prefix 

Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

[bruno . decraene]

Orange Restricted
From: Lsr  On Behalf Of Acee Lindem
Sent: Thursday, November 16, 2023 11:33 PM
To: Les Ginsberg (ginsberg) 
Cc: Loa Andersson ; lsr@ietf.org
Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

Speaking as a WG contributor:

Hi Les,

I think a simpler name is better - perhaps ietf-isis-feature-support.yang with 
YANG prefix isis-fs would be better.  Which brings me to my next and more 
important point…

Like carbon neutrality, everyone at the LSR WG meeting who had an opinion 
thought such a YANG model would be operationally useful. However, I think the 
level of granularity is key.
[Bruno] +1
I agree that the level of granularity is key.
I’d rather call for a significant granularity (but I’d welcome any pushback).
Personally, I don’t see why per TLV granularity would not be ok: it’s ok to 
implement which is more work, so just listing the supported TLV and sub-TLV 
should be doable. In any case, operators, pre-sales and support engineers will 
likely need this information some day. So let’s just fill it once for all and 
have it available for all persons.

I’d would even call for more granularity. E.g. for RFC 5130, for “32-bit 
Administrative Tag Sub-TLV 1”, “On receipt, an implementation MAY consider only 
one encoded tag, in which case, the first encoded tag MUST be considered and 
any additional tags ignored. »

To me, if the WG bothered making such granularity at the 
feature/TLV/implementation level, we need such granularity at the reporting 
level. And that’s not theoretical, I had to check that for a project a month 
ago. At best, it’s indicated in the vendors documentation, so the data is 
there, so let’s make it friendly to digest. At worst, we need to involve 
expensive people .

If we want less granularity, let’s do less granularity in spec (everything is 
MUST)

https://datatracker.ietf.org/doc/html/rfc5130#section-3.1

Thanks,
--Bruno


I believe that having a separate data node for each TLV/sub-TLV as was done in 
the example ietf-isis-pics-sr-mpls.yang module is way too granular to be 
useful. Rather, the YANG reporting should be done at the feature level. Also, 
does a distinction need to be made as to whether the IS-IS node supports the 
feature or both supports it and has it enabled (as would be the case for 
non-backward compatible features)?

Thanks,
Acee

On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

Loa -

I agree with you that simply "IS-IS Support" may not be the best choice.
Although, the meeting minutes have not yet been posted, as I recall my response 
to Tony Li's suggestion of "IS-IS Support" was "Yes - something like that."

The draft authors have not yet discussed this - but we will and share the 
proposed new name.
Other suggestions welcomed.

  Les

-Original Message-
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Loa 
Andersson
Sent: Thursday, November 16, 2023 2:06 AM
To: lsr@ietf.org
Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

Working Group,

During the presentation of draft-qgp-lsr-isis-pics-yang there was a
rather strong opposition in the chat against using the ISO-term "PICS"
in an IETF document.

I think the term "Support" was suggested (excuse me if I missed
something), but I'm not that impressed, and would rather like to see
something like - "Supported Protocol Aspects".

/Loa
--
Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert  
loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64

___
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


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