Hi, Les:

Even for IS-IS, there is already the flag registries example, please see the 
following pointer:

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags

 

And, even for your proposal 2), it is still not concise as the flag registries. 
Considering that we have one flag filed that has 16bit, and there will be 16 
updates to the original document if it defines no bit at the beginning and 
every additional document defines one bit only?

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Monday, March 22, 2021 2:37 PM
To: Tony Li <tony...@tony.li>
Cc: Christian Hopps <cho...@chopps.org>; Alvaro Retana 
<aretana.i...@gmail.com>; lsr-cha...@ietf.org; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; John Scudder <j...@juniper.net>; 
lsr@ietf.org
Subject: Re: [Lsr] When is an IANA Registry Required

 

Tony –

 

I hope I can be forgiven for one more post on this subject. In any case, here 
it is.

 

First, at the risk of some repetition, I want to emphasize that the reason I 
started this thread was to define a consistent policy. Currently we do not have 
registries for the flags fields in various TLVs. In recent document reviews, 
Alvaro strongly suggested that we introduce a registry for the flag field in 
the new TLV(s) which were being defined. I do not think the policy should be 
inconsistent in this regard, so I started this thread to get the WG to agree on 
what the policy will be across all such fields in all TLVs. Whatever the 
outcome of this discussion (i.e., to have such registries or to NOT have them), 
so long as there is a consistent policy, this thread will have served the 
purpose and I will be satisfied. (For those of you who may be fans of Ralph 
Waldo Emerson, I consider this to be NOT a “foolish consistency”. 😊 )

 

Now, as regards the potential usefulness of such registries, I think this has 
nothing to do with “memory”.  I can assure you that I refer to the existing 
registries with great frequency and do not trust my memory on such things.

 

Registries exist today (and are very useful) for number spaces for which 
requests come from a large number of largely unrelated documents. So, for top 
level TLVs, almost every IS-IS related RFC which has been published defines one 
or more codepoints. Without a registry our ability to track what is currently 
allocated and what is available would be severely compromised. Similarly for 
sub-TLVs and the other registries under the TLV Codepoints umbrella. However, 
in regards to flags fields which are part of the fixed portion of a TLV format 
definition, tracking bit allocation has not been an issue – and I argue that it 
is best tracked in other ways which are already defined. To be specific:

 

If an additional flag bit for an existing  TLV is defined in the future, there 
are two possible ways of doing this:

 

1)A bis document is written. The new document then contains all normative 
content from the original document as well as the new content (in this example 
an additional flag bit). The new document is required to be marked as 
“obsoleting” the original version. Once the document is published, the original 
document is marked as “obsoleted by xxx” and the existing entry for the 
affected code point in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
is marked to point to the new document. 

 

2)A separate document is written focused only on the additions to the base 
definition for the TLV. The new document is required to be clearly marked as 
“updating” the original document. The original document is marked as “updated 
by new document”. In addition, the existing entry in 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
would be updated to point to both the original document and the new document.

 

This seems to me be fully functional and easy to use. Even if your memory on 
such matters is not fresh, by simply bookmarking 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml 
you will easily be able to find whatever information you need.

 

The addition of a separate registry for each flags field is then redundant at 
best. And redundancy in such matters introduces additional work and the 
possibility of unintentional inconsistency which I find hard to justify. Hence 
my conclusion that the value of such additional registries does not justify 
their creation.

 

You (and others) may still disagree. And I assure you that as my primary 
motivation for this thread was to have a consistent WG policy for such fields, 
I will abide by whatever policy is chosen by the WG even if it is not my 
preferred choice. But I do think the arguments being made for the creation of 
such registries bear closer scrutiny. Just my opinion of course…

 

Thanx (again) for listening.

 

   Les

 

 

From: Tony Li <tony1ath...@gmail.com <mailto:tony1ath...@gmail.com> > On Behalf 
Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com <mailto:ginsb...@cisco.com> >
Cc: Alvaro Retana <aretana.i...@gmail.com <mailto:aretana.i...@gmail.com> >; 
draft-ietf-lsr-isis-srv6-extensi...@ietf.org 
<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org> ; lsr@ietf.org 
<mailto:lsr@ietf.org> ; John Scudder <j...@juniper.net 
<mailto:j...@juniper.net> >; Christian Hopps <cho...@chopps.org 
<mailto:cho...@chopps.org> >; lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org> 
Subject: Re: [Lsr] When is an IANA Registry Required

 

 

Les,

 

 

IMO, there is no need for registries for the first category. The WG has been 
alive for over 20 years, defined many new TLVs with flags fields, and I am not 
aware of any confusion – so if it ain’t broke don’t fix it.

 

 

With all due respect Les, you appear to operate with an eidetic memory of all 
things IS-IS, so I think that you discount the confusion that the rest of us 
live in. 

 

If a field has values defined in two documents, then there’s confusion. Even 
just finding both is a challenge.

 

Regards,

Tony

 

 

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

Reply via email to