[Lsr] [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

[Amanda Baber via RT]

Hi Loa, all,

A note about this:

> Yeah - you are requesting code points from registries where the
> registration procedures are "Expert Review". But those are not early
> allocation, they are permanent.

There is a kind of hybrid early allocation/Expert Review procedure for the 
IS-IS Exert Review registries, which is what I understood to be in use here. If 
the experts approve, we mark the registrations as temporary and ask them to 
re-approve a year later. It's described in Section 4 of RFC 7370:

https://tools.ietf.org/html/rfc7370#section-4

thanks,
Amanda

On Tue Jun 02 18:01:21 2020, l...@pi.nu wrote:
> Tony,
> 
> inline plz.
> 
> On 02/06/2020 22:42, Tony Przygienda wrote:
> > Loa, fair points though I would say adoption is kind of a different
> > kettle of fish than early allocation.
> 
> yeah - but the point I made, modulo some small updates in the IANA
> considerations I think the document is ready for wg adoption. And
> really the updates in the IANA considerations is strictly not
> necessary for wg adoption, but I prefer to have the IANA registries
> in scope clearly pointed out.
> >
> > RFC7120 does not seem to apply given ISIS registries are under expert
> > review (largely due to historical reasons AFAIS).
> 
> Yeah - you are right. I missed that, was to focused on the
> requirements
> in 7120.
> >
> > I watch that with lots of interest since due to customer
> > discussions/(deployment) planning we request with experts early
> > allocation for
> > https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-
> > reflection/
> 
> Yeah - you are requesting code points from registries where the
> registration procedures are "Expert Review". But those are not early
> allocation, they are permanent.
> 
> > We have however the benefit of not needing any new registries.
> 
> Yes, that is a blessing, but for a new registry you can actually
> capture
> in the draft and populate it with code point values, the only thing is
> that once you put a value in there it should not be changed.
> Especially
> if you know of early implementations.
> 
> For your draft the registries should be called:
> 
> Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV); and
>  Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS
>  reachability, IS Neighbor Attribute, L2 Bundle Member Attributes,
>  inter-AS reachability information, MT-ISN, and MT IS Neighbor
> Attribute
> TLVs)
> 
> (Don't blame me, I didn't name the registries :) ).
> 
> 
> and both registries are found in the IS-IS TLV Codepoints namespace.
> 
> /Loa
> 
> >
> > thanks
> >
> > -- tony
> >
> > On Tue, Jun 2, 2020 at 1:00 AM Loa Andersson  > > wrote:
> >
> > Folks,
> >
> > I have two questions on the early allocation.
> >
> > RFC 7120 allows early allocation for two types of
> >
> >     The processes described below assume that the document in
> > question is
> >     the product of an IETF Working Group (WG).  If this is not the
> > case,
> >     replace "WG chairs" below with "Shepherding Area Director".
> >
> > draft-li-lsr-isis-area-proxy is an individual document, i.e. not a
> > product of a working group nor shepherded by an AD, and does not seem
> > to
> > meet the criteria for early allocation.
> >
> > Also. draft-li-lsr-isis-area-proxy request that IANA create a new
> > registry, as far as I understand new registries can't be created
> > through
> > early allocation. It is hardly necessary.
> >
> > The code points are requested from "the IS-IS TLV Codepoints
> > registry",
> > howver the "IS-IS TLV Codepoints" is a name space with 14 different
> > registries. I think the the registry you want to allocated code point
> > from the "TLV Codepoints registry"
> >
> > Since the document, at least I read it, well meet the criteria for
> > becoming a working document (minor update to the IANA section), I
> > think
> > that the easy way out is to start the working group adoption poll.
> >
> > /Loa
> >
> >
> > On 02/06/2020 12:52, Tony Li wrote:
> >  >
> >  > Hi Amanda,
> >  >
> >  >> However, the IANA Considerations section is missing some
> > information.
> >  >> How would we fill in the IIH, LSP, SNP, and Purge fields for
> >  >> the
> > TLV
> >  >> Codepoint registrations?
> >  >
> >  >
> >  > We’ve addressed this in
> >  > https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-06..
> >  >
> >  > Thanks,
> >  > Sarah & Tony
> >  >
> >  >
> >  > ___
> >  > Lsr mailing list
> >  > Lsr@ietf.org 
> >  > https://www.ietf.org/mailman/listinfo/lsr
> >  >
> >
> > --
> >
> > My mail server from time to time has come under DOS attacks,
> > we are working to fix it but it may take some time. If you
> > get denial of service sending to me plz try to use
> > loa.pi.nu@gmail
> >
> >
> > Loa Andersson                        email: l...@pi.nu
> > 
> > Senior MPLS Expert
> > Bron

Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

[Tony Przygienda]

On Tue, Jun 2, 2020 at 10:59 AM Loa Andersson  wrote:

>
>
> For your draft the registries should be called:
>
> Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV); and
> Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS
> reachability, IS Neighbor Attribute, L2 Bundle Member Attributes,
> inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute
> TLVs)
>
> (Don't blame me, I didn't name the registries :) ).
>

draft
https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection/
IANA section is calling the registries already what they are called
(without what the sub-TLVs are since the titles would explode). There is no
possiblity of mistaking them IMO

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

Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

[Loa Andersson]

Tony,

inline plz.

On 02/06/2020 22:42, Tony Przygienda wrote:
Loa, fair points though I would say adoption is kind of a different 
kettle of fish than early allocation.


yeah - but the point I made, modulo some small updates in the IANA 
considerations I think the document is ready for wg adoption. And

really the updates in the IANA considerations is strictly not
necessary for wg adoption, but I prefer to have the IANA registries
in scope clearly pointed out.


RFC7120 does not seem to apply given ISIS registries are under expert 
review (largely due to historical reasons AFAIS).


Yeah - you are right. I missed that, was to focused on the requirements
in 7120.


I watch that with lots of interest since due to customer 
discussions/(deployment) planning we request with experts early 
allocation for 
https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection/ 


Yeah - you are requesting code points from registries where the 
registration procedures are "Expert Review". But those are not early

allocation, they are permanent.


We have however the benefit of not needing any new registries.


Yes, that is a blessing, but for a new registry you can actually capture
in the draft and populate it with code point values, the only thing is
that once you put a value in there it should not be changed. Especially
if you know of early implementations.

For your draft the registries should be called:

Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV); and
Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS 
reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, 
inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute 
TLVs)


(Don't blame me, I didn't name the registries :) ).


and both registries are found in the IS-IS TLV Codepoints namespace.

/Loa



thanks

-- tony

On Tue, Jun 2, 2020 at 1:00 AM Loa Andersson > wrote:


Folks,

I have two questions on the early allocation.

RFC 7120 allows early allocation for two types of

     The processes described below assume that the document in
question is
     the product of an IETF Working Group (WG).  If this is not the
case,
     replace "WG chairs" below with "Shepherding Area Director".

draft-li-lsr-isis-area-proxy is an individual document, i.e. not a
product of a working group nor shepherded by an AD, and does not seem to
meet the criteria for early allocation.

Also. draft-li-lsr-isis-area-proxy request that IANA create a new
registry, as far as I understand new registries can't be created through
early allocation. It is hardly necessary.

The code points are requested from "the IS-IS TLV Codepoints registry",
howver the "IS-IS TLV Codepoints" is a name space with 14 different
registries. I think the the registry you want to allocated code point
from the "TLV Codepoints registry"

Since the document, at least I read it, well meet the criteria for
becoming a working document (minor update to the IANA section), I think
that the easy way out is to start the working group adoption poll.

/Loa


On 02/06/2020 12:52, Tony Li wrote:
 >
 > Hi Amanda,
 >
 >> However, the IANA Considerations section is missing some
information.
 >> How would we fill in the IIH, LSP, SNP, and Purge fields for the
TLV
 >> Codepoint registrations?
 >
 >
 > We’ve addressed this in
 > https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-06..
 >
 > Thanks,
 > Sarah & Tony
 >
 >
 > ___
 > Lsr mailing list
 > Lsr@ietf.org 
 > https://www.ietf.org/mailman/listinfo/lsr
 >

-- 


My mail server from time to time has come under DOS attacks,
we are working to fix it but it may take some time. If you
get denial of service sending to me plz try to use
loa.pi.nu@gmail


Loa Andersson                        email: l...@pi.nu 
Senior MPLS Expert
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



--

My mail server from time to time has come under DOS attacks,
we are working to fix it but it may take some time. If you
get denial of service sending to me plz try to use
loa.pi.nu@gmail


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

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

Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

[Loa Andersson]

Tony,

inline plz.

On 02/06/2020 22:42, Tony Przygienda wrote:
Loa, fair points though I would say adoption is kind of a different 
kettle of fish than early allocation.


yeah - but the point I made, modulo some small updates in the IANA 
considerations I think the document is ready for wg adoption. And

really the updates in the IANA considerations is strictly not
necessary for wg adoption, but I prefer to have the IANA registries
in scope clearly pointed out.


RFC7120 does not seem to apply given ISIS registries are under expert 
review (largely due to historical reasons AFAIS).


Yeah - you are right. I missed that, was to focused on the requirements
in 7120.


I watch that with lots of interest since due to customer 
discussions/(deployment) planning we request with experts early 
allocation for 
https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection/ 


Yeah - you are requesting code points from registries where the 
registration procedures are "Expert Review""



We have however the benefit of not needing any new registries.


Yes, that is a blessing, but for a new registry you can actually capture
in the draft and populate it with code point values, the only thing is
that once you put a value in there it should not be changed. Especially
if you know of early implementations.

For your draft the registries should be called:

Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV); and
Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS 
reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, 
inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute 
TLVs)


(Don't blame me, I didn't name the registries :) ).


and both registries are found in the IS-IS TLV Codepoints namespace.

/Loa



thanks

-- tony

On Tue, Jun 2, 2020 at 1:00 AM Loa Andersson > wrote:


Folks,

I have two questions on the early allocation.

RFC 7120 allows early allocation for two types of

     The processes described below assume that the document in
question is
     the product of an IETF Working Group (WG).  If this is not the
case,
     replace "WG chairs" below with "Shepherding Area Director".

draft-li-lsr-isis-area-proxy is an individual document, i.e. not a
product of a working group nor shepherded by an AD, and does not seem to
meet the criteria for early allocation.

Also. draft-li-lsr-isis-area-proxy request that IANA create a new
registry, as far as I understand new registries can't be created through
early allocation. It is hardly necessary.

The code points are requested from "the IS-IS TLV Codepoints registry",
howver the "IS-IS TLV Codepoints" is a name space with 14 different
registries. I think the the registry you want to allocated code point
from the "TLV Codepoints registry"

Since the document, at least I read it, well meet the criteria for
becoming a working document (minor update to the IANA section), I think
that the easy way out is to start the working group adoption poll.

/Loa


On 02/06/2020 12:52, Tony Li wrote:
 >
 > Hi Amanda,
 >
 >> However, the IANA Considerations section is missing some
information.
 >> How would we fill in the IIH, LSP, SNP, and Purge fields for the
TLV
 >> Codepoint registrations?
 >
 >
 > We’ve addressed this in
 > https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-06..
 >
 > Thanks,
 > Sarah & Tony
 >
 >
 > ___
 > Lsr mailing list
 > Lsr@ietf.org 
 > https://www.ietf.org/mailman/listinfo/lsr
 >

-- 


My mail server from time to time has come under DOS attacks,
we are working to fix it but it may take some time. If you
get denial of service sending to me plz try to use
loa.pi.nu@gmail


Loa Andersson                        email: l...@pi.nu 
Senior MPLS Expert
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



--

My mail server from time to time has come under DOS attacks,
we are working to fix it but it may take some time. If you
get denial of service sending to me plz try to use
loa.pi.nu@gmail


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

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

Re: [Lsr] Rtgdir last call review of draft-ietf-isis-te-app-13

[bruno.decraene]

Les,

Thanks for your answers.
Comments inline

> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> Sent: Saturday, May 30, 2020 12:09 AM
> 
> Bruno -
> 
> Thanx for your (as always) meticulous review.
> Responses inline.
> Once we have reached agreement I will send out an updated version.
> 
> > -Original Message-
> > From: Bruno Decraene via Datatracker 
> > Sent: Friday, May 29, 2020 10:18 AM
> > To: rtg-...@ietf.org
> > Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org
> > Subject: Rtgdir last call review of draft-ietf-isis-te-app-13
> > 
> > Reviewer: Bruno Decraene
> > Review result: Has Issues
> > 
> >  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
> > http://trac.tools.ietf.org/area/rtg/trac/wiki/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-isis-te-app-13
> > Reviewer: Bruno Decraene
> > Review Date: 2020-05-29
> > IETF LC End Date: 2020-05-29
> > Intended Status: Standards Track
> > 
> > Summary:
> > I have some minor concerns about this document that I think should be
> > resolved before publication.
> > 
> > Comments:
> >   Draft is clear.
> > 
> > Minor Issues:
> > 
> > §4.1
> > *2 (for SABM & UDABM fields)
> > OLD: The length SHOULD be the minimum required to send all bits which are
> > set.
> > I'd propose
> > NEW: The length SHOULD be the minimum required to send all the
> > meaningful bits
> > which are set.
> > 
> > Motivation; the 'bits which are sent' are the bits in the SABM field. (they 
> > do
> > include non-meaningful and padding bits)
> > 
> 
> [Les:] The definition of what is "meaningful" and what is "padding"  to me is 
> ambiguous.
> Meaningful could be only those bits which are currently defined in the 
> registry (speaking of SABM here). But if there are 10 bits defined in the 
> registry and I only intend to set Bit 5, I do not need to send all 10 bits - 
> I only need to send one octet - because we state:
> 
> "Bits that are NOT transmitted MUST be treated as if they
   > are set to 0 on receipt.  "
> 
> Also, an implementation written when there were only 4 bits defined in the 
> registry might think that "meaningful" is different than an implementation 
> written when more than 8 bits were defined in the registry. Yet they can 
> still interoperate.
> 
> I believe the current language is best.

[Bruno]
I withdraw my comment. Sorry for the noise.
I had read "bits which are sent", while the text is "bits which are set".


> > 
> > 
> > OLD: Undefined bits MUST be transmitted as 0
> > NEW: Undefined transmitted bits MUST be cleared (0)
> > 
> > Motivation: currently the number of undefined bits is 8*8-3. They SHOULD
> > not be
> > transmitted (beyond the first ones fitting in the first N required octet). 
> > The
> > sentence "Undefined bits MUST be transmitted as 0" could be read as all
> > defined
> > bits MUST be transmitted (as 0).
> > ---
> [Les:] I do not see how that could be a valid interpretation given that we 
> state:
> 
> " The length SHOULD  be the minimum required to send all bits which are set."

[Bruno]
So we have
1) The length SHOULD  be the minimum required to send all bits which are set
2) Undefined bits MUST be transmitted as 0

Given the "MUST"  vs "SHOULD" and "transmitted" (which means "sent"), I do 
believe my proposal is better. But I won't insist.

 
> And (repeating)
> 
> "Bits that are NOT transmitted MUST be treated as if they
   > are set to 0 on receipt.  "
> 
> And again, you assume that "defined bits" is the same for all implementations 
> - which isn't guaranteed as I discussed above.

[Bruno] I don't think that this matter as the behavior is specific to the 
sender.
In addition, the term " Undefined bits" is yours.
 
> 
> > User Defined Application Identifier Bits have no name. I'd propose to call
> > them
> > UDABM[0], UDABM[1]... This may avoid that different implementation use
> > different names and, more problematic, that some implementations starting
> > with
> > 1 (the first, the second) while while some other implementations starts as 
> > 0,
> > creating interop issues (SABM[1] on node A is SABM[0] on node B)
> > ---
> 
> [Les:] What implementations may name bits they assign from the User space is 
> out of scope of this document.
> If I were implementing a non-standard User App I likely would give it a 
> meaningful name both in my code and in any documen

Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

[tony . li]

Hi Loa,

> The code points are requested from "the IS-IS TLV Codepoints registry",
> howver the "IS-IS TLV Codepoints" is a name space with 14 different
> registries. I think the the registry you want to allocated code point
> from the "TLV Codepoints registry”


I apologize for the confusion, you are certainly correct.

The confusion arises because the page is named “IS-IS TLV Codepoints” and the 
registry is the “TLV Codepoints Registry” so to be precise, we should request 
an allocation from the “IS-IS TLV Codepoints TLV Codepoints Registry”.  That 
does seem somewhat awkward and redundant redundant.

To reduce confusion in the future, perhaps the entire page should be renamed to 
“IS-IS Codepoints”?

Regards,
Tony

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

Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

[Tony Przygienda]

Loa, fair points though I would say adoption is kind of a different kettle
of fish than early allocation.

RFC7120 does not seem to apply given ISIS registries are under expert
review (largely due to historical reasons AFAIS).

I watch that with lots of interest since due to customer
discussions/(deployment) planning we request with experts early allocation
for https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection/
We have however the benefit of not needing any new registries.

thanks

-- tony

On Tue, Jun 2, 2020 at 1:00 AM Loa Andersson  wrote:

> Folks,
>
> I have two questions on the early allocation.
>
> RFC 7120 allows early allocation for two types of
>
> The processes described below assume that the document in question is
> the product of an IETF Working Group (WG).  If this is not the case,
> replace "WG chairs" below with "Shepherding Area Director".
>
> draft-li-lsr-isis-area-proxy is an individual document, i.e. not a
> product of a working group nor shepherded by an AD, and does not seem to
> meet the criteria for early allocation.
>
> Also. draft-li-lsr-isis-area-proxy request that IANA create a new
> registry, as far as I understand new registries can't be created through
> early allocation. It is hardly necessary.
>
> The code points are requested from "the IS-IS TLV Codepoints registry",
> howver the "IS-IS TLV Codepoints" is a name space with 14 different
> registries. I think the the registry you want to allocated code point
> from the "TLV Codepoints registry"
>
> Since the document, at least I read it, well meet the criteria for
> becoming a working document (minor update to the IANA section), I think
> that the easy way out is to start the working group adoption poll.
>
> /Loa
>
>
> On 02/06/2020 12:52, Tony Li wrote:
> >
> > Hi Amanda,
> >
> >> However, the IANA Considerations section is missing some information.
> >> How would we fill in the IIH, LSP, SNP, and Purge fields for the TLV
> >> Codepoint registrations?
> >
> >
> > We’ve addressed this in
> > https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-06..
> >
> > Thanks,
> > Sarah & Tony
> >
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> >
>
> --
>
> My mail server from time to time has come under DOS attacks,
> we are working to fix it but it may take some time. If you
> get denial of service sending to me plz try to use
> loa.pi.nu@gmail
>
>
> Loa Anderssonemail: l...@pi.nu
> Senior MPLS Expert
> 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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huaimo Chen]

Hi Xuesong,

Thank you very much for your support and comments.
We will add more explanations in “Appendix A.  FT Computation Details 
through Example ” and brief the relation to other work.

Best Regards,
Huaimo

From: Lsr  on behalf of Gengxuesong (Geng Xuesong) 

Sent: Tuesday, June 2, 2020 8:42 AM
To: Acee Lindem (acee) ; lsr@ietf.org 

Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


Hi,



I’ve read the draft and I think the draft is useful and ready for WG adoption.

By the way, when reading the draft, I feel a little difficult to understand the 
mathematical symbols in the draft, especially in the “Appendix A.  FT 
Computation Details through Example .” It will be appreciated if the authors 
could add more explanations about this.  And I believe some brief introduction 
about the relationship between this draft and other existing work in the WG 
will also be very helpful.



Best Regards

Xuesong



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, May 16, 2020 3:40 AM
To: lsr@ietf.org
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call



This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.



https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/



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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Gengxuesong (Geng Xuesong)]

Hi,

I’ve read the draft and I think the draft is useful and ready for WG adoption.
By the way, when reading the draft, I feel a little difficult to understand the 
mathematical symbols in the draft, especially in the “Appendix A.  FT 
Computation Details through Example .” It will be appreciated if the authors 
could add more explanations about this.  And I believe some brief introduction 
about the relationship between this draft and other existing work in the WG 
will also be very helpful.

Best Regards
Xuesong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, May 16, 2020 3:40 AM
To: lsr@ietf.org
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.

https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/

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

Re: [Lsr] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

[Christian Hopps]

Hi folks,

It seems that we followed the wrong procedure for this. The registries in 
question are Expert Review only and so RFC7120 does not apply. I wanted to send 
a quick email indicating that our input as chairs is not technically required 
as part of the process so our email was a NO-OP on that front.

The intent in sending the email to the list was to make the WG aware that the 
request was being made, so that at least worked.

Thanks,
Chris an Acee.

> On Jun 1, 2020, at 3:46 PM, Acee Lindem (acee) 
>  wrote:
> 
> Hi IANA, Martin, 
>  
> We’ve discussed this draft and are going forward with the early allocation 
> request. While there is some overlap with other LSR WG proposals, there is no 
> reason to block all the drafts given that it very unlikely that we will have 
> a combined draft any time soon. 
>  
> Thanks,
> Acee and Chris
> ___
> 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] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[Tianran Zhou]

I think I understand your clarification.
Let me conclude, so your logic is:
We can use IGP to signal labels, though entropy label is not included. So we 
can use IGP to signal entropy label capability.

If so, this logic is not straight forward to me.

Tianran

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Tuesday, June 2, 2020 4:31 PM
To: Tianran Zhou ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Tianran,

On 02/06/2020 10:25, Tianran Zhou wrote:
> Peter,
> 
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Tuesday, June 2, 2020 4:10 PM
> To: Tianran Zhou ; lsr@ietf.org
> Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
> 
> Tianran,
> 
> On 02/06/2020 08:14, Tianran Zhou wrote:
>> Hi Peter,
>>
>> I do not understand how RFC8667 relates to ELC signaling.
> 
> RFC 8667 - IS-IS Extensions for Segment Routing
> 
>> RFC 8667 "have been defined to signal labels", but "This draft defines a 
>> mechanism to signal the ELC using IS-IS."
> 
> yes, and as labels are now signaled by IGPs, we provide a method to signal 
> ELC/ERLD by IGPs as well.
> 
> ZTR> RFC8667 signals different SID. 

no, RFC8667 is ISIS extension for SR MPLS.

> But draft-ietf-ospf-mpls-elc is about entropy label. Or do you mean entropy 
> label is also signaled by IGP?

no, entropy label is not signaled AFAIK.

> 
>>
>> On the other hand, RFC 8667 is the extension for segment routing.
>> Is this draft only for segment routing, or be generic?
> 
> the requirement document is RFC8662, which is SR specific.
> 
> ZTR> "This draft" I mean draft-ietf-ospf-mpls-elc. So is 
> draft-ietf-ospf-mpls-elc SR specific?

SR was a primary motivation.

regards,
Peter



> 
> Thanks,
> Tianran
> 
>>
>> Another thing I am not clear is the difference between "multi-area" and 
>> "multi-domain" here after:
>>  "Even though ELC is a property of the node, in some cases it is
>>  advantageous to associate and advertise the ELC with a prefix.  In a
>>  multi-area network, routers may not know the identity of the prefix
>>  originator in a remote area, or may not know the capabilities of such
>>  originator.  Similarly, in a multi-domain network, the identity of
>>  the prefix originator and its capabilities may not be known to the
>>  ingress LSR."
> 
> 
> multi area is single IGP with multiple areas. Mutli domain is multiple IGPs.
> 
> thanks,
> Peter
> 
>>
>> Tianran
>>
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Monday, June 1, 2020 6:56 PM
>> To: Tianran Zhou ; lsr@ietf.org
>> Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
>>
>> Tianran,
>>
>> On 01/06/2020 12:49, Tianran Zhou wrote:
>>> Hi Authors,
>>>
>>> I see the following words in the introduction.
>>> "   Recently, mechanisms have been defined to signal labels via link-
>>>   state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667].  "
>>>
>>> It's not clear to me what the " mechanisms " are. Could you please add some 
>>> reference or text on this?
>>
>> the reference is there - RFC8667.
>>
>>
>> thanks,
>> Peter
>>
>>>
>>> Thanks,
>>> Tianran
>>>
>>> -Original Message-
>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
>>> internet-dra...@ietf.org
>>> Sent: Monday, June 1, 2020 4:42 PM
>>> To: i-d-annou...@ietf.org
>>> Cc: lsr@ietf.org
>>> Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the Link State Routing WG of the IETF.
>>>
>>>Title   : Signaling Entropy Label Capability and Entropy 
>>> Readable Label Depth Using OSPF
>>>Authors : Xiaohu Xu
>>>  Sriganesh Kini
>>>  Peter Psenak
>>>  Clarence Filsfils
>>>  Stephane Litkowski
>>>  Matthew Bocci
>>> Filename: draft-ietf-ospf-mpls-elc-15.txt
>>> Pages   : 9
>>> Date: 2020-06-01
>>>
>>> Abstract:
>>>   Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
>>>   balance traffic flows using Entropy Labels (EL).  An ingress Label
>>>   Switching Router (LSR) cannot insert ELs for packets going into a
>>>   given Label Switched Path (LSP) unless an egress LSR has indicated
>>>   via signaling that it has the capability to process ELs, referred to
>>>   as the Entropy Label Capability (ELC), on that LSP.  In addition, it
>>>   would be useful for ingress LSRs to know each LSR's capability for
>>>   reading the maximum label stack depth and performing EL-based load-
>>>   balancing, referred to as Entropy Readable Label Depth (ERLD).  This
>>>   document defines a mechanism to signal these two capabilities using
>>>   OSPFv

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[Peter Psenak]

Tianran,

On 02/06/2020 10:25, Tianran Zhou wrote:

Peter,

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Tuesday, June 2, 2020 4:10 PM
To: Tianran Zhou ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Tianran,

On 02/06/2020 08:14, Tianran Zhou wrote:

Hi Peter,

I do not understand how RFC8667 relates to ELC signaling.


RFC 8667 - IS-IS Extensions for Segment Routing


RFC 8667 "have been defined to signal labels", but "This draft defines a mechanism 
to signal the ELC using IS-IS."


yes, and as labels are now signaled by IGPs, we provide a method to signal 
ELC/ERLD by IGPs as well.

ZTR> RFC8667 signals different SID. 


no, RFC8667 is ISIS extension for SR MPLS.


But draft-ietf-ospf-mpls-elc is about entropy label. Or do you mean entropy 
label is also signaled by IGP?


no, entropy label is not signaled AFAIK.





On the other hand, RFC 8667 is the extension for segment routing.
Is this draft only for segment routing, or be generic?


the requirement document is RFC8662, which is SR specific.

ZTR> "This draft" I mean draft-ietf-ospf-mpls-elc. So is 
draft-ietf-ospf-mpls-elc SR specific?


SR was a primary motivation.

regards,
Peter





Thanks,
Tianran



Another thing I am not clear is the difference between "multi-area" and 
"multi-domain" here after:
 "Even though ELC is a property of the node, in some cases it is
 advantageous to associate and advertise the ELC with a prefix.  In a
 multi-area network, routers may not know the identity of the prefix
 originator in a remote area, or may not know the capabilities of such
 originator.  Similarly, in a multi-domain network, the identity of
 the prefix originator and its capabilities may not be known to the
 ingress LSR."



multi area is single IGP with multiple areas. Mutli domain is multiple IGPs.

thanks,
Peter



Tianran

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Monday, June 1, 2020 6:56 PM
To: Tianran Zhou ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Tianran,

On 01/06/2020 12:49, Tianran Zhou wrote:

Hi Authors,

I see the following words in the introduction.
"   Recently, mechanisms have been defined to signal labels via link-
  state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667].  "

It's not clear to me what the " mechanisms " are. Could you please add some 
reference or text on this?


the reference is there - RFC8667.


thanks,
Peter



Thanks,
Tianran

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Monday, June 1, 2020 4:42 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

   Title   : Signaling Entropy Label Capability and Entropy 
Readable Label Depth Using OSPF
   Authors : Xiaohu Xu
 Sriganesh Kini
 Peter Psenak
 Clarence Filsfils
 Stephane Litkowski
 Matthew Bocci
Filename: draft-ietf-ospf-mpls-elc-15.txt
Pages   : 9
Date: 2020-06-01

Abstract:
  Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
  balance traffic flows using Entropy Labels (EL).  An ingress Label
  Switching Router (LSR) cannot insert ELs for packets going into a
  given Label Switched Path (LSP) unless an egress LSR has indicated
  via signaling that it has the capability to process ELs, referred to
  as the Entropy Label Capability (ELC), on that LSP.  In addition, it
  would be useful for ingress LSRs to know each LSR's capability for
  reading the maximum label stack depth and performing EL-based load-
  balancing, referred to as Entropy Readable Label Depth (ERLD).  This
  document defines a mechanism to signal these two capabilities using
  OSPFv2 and OSPFv3 and BGP-LS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-mpls-elc-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-15


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[Tianran Zhou]

Peter,

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Tuesday, June 2, 2020 4:10 PM
To: Tianran Zhou ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Tianran,

On 02/06/2020 08:14, Tianran Zhou wrote:
> Hi Peter,
> 
> I do not understand how RFC8667 relates to ELC signaling.

RFC 8667 - IS-IS Extensions for Segment Routing

> RFC 8667 "have been defined to signal labels", but "This draft defines a 
> mechanism to signal the ELC using IS-IS."

yes, and as labels are now signaled by IGPs, we provide a method to signal 
ELC/ERLD by IGPs as well.

ZTR> RFC8667 signals different SID. But draft-ietf-ospf-mpls-elc is about 
entropy label. Or do you mean entropy label is also signaled by IGP?

> 
> On the other hand, RFC 8667 is the extension for segment routing.
> Is this draft only for segment routing, or be generic?

the requirement document is RFC8662, which is SR specific.

ZTR> "This draft" I mean draft-ietf-ospf-mpls-elc. So is 
draft-ietf-ospf-mpls-elc SR specific?

Thanks,
Tianran

> 
> Another thing I am not clear is the difference between "multi-area" and 
> "multi-domain" here after:
> "Even though ELC is a property of the node, in some cases it is
> advantageous to associate and advertise the ELC with a prefix.  In a
> multi-area network, routers may not know the identity of the prefix
> originator in a remote area, or may not know the capabilities of such
> originator.  Similarly, in a multi-domain network, the identity of
> the prefix originator and its capabilities may not be known to the
> ingress LSR."


multi area is single IGP with multiple areas. Mutli domain is multiple IGPs.

thanks,
Peter

> 
> Tianran
> 
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Monday, June 1, 2020 6:56 PM
> To: Tianran Zhou ; lsr@ietf.org
> Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
> 
> Tianran,
> 
> On 01/06/2020 12:49, Tianran Zhou wrote:
>> Hi Authors,
>>
>> I see the following words in the introduction.
>> "   Recently, mechanisms have been defined to signal labels via link-
>>  state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667].  "
>>
>> It's not clear to me what the " mechanisms " are. Could you please add some 
>> reference or text on this?
> 
> the reference is there - RFC8667.
> 
> 
> thanks,
> Peter
> 
>>
>> Thanks,
>> Tianran
>>
>> -Original Message-
>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
>> internet-dra...@ietf.org
>> Sent: Monday, June 1, 2020 4:42 PM
>> To: i-d-annou...@ietf.org
>> Cc: lsr@ietf.org
>> Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Link State Routing WG of the IETF.
>>
>>   Title   : Signaling Entropy Label Capability and Entropy 
>> Readable Label Depth Using OSPF
>>   Authors : Xiaohu Xu
>> Sriganesh Kini
>> Peter Psenak
>> Clarence Filsfils
>> Stephane Litkowski
>> Matthew Bocci
>>  Filename: draft-ietf-ospf-mpls-elc-15.txt
>>  Pages   : 9
>>  Date: 2020-06-01
>>
>> Abstract:
>>  Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
>>  balance traffic flows using Entropy Labels (EL).  An ingress Label
>>  Switching Router (LSR) cannot insert ELs for packets going into a
>>  given Label Switched Path (LSP) unless an egress LSR has indicated
>>  via signaling that it has the capability to process ELs, referred to
>>  as the Entropy Label Capability (ELC), on that LSP.  In addition, it
>>  would be useful for ingress LSRs to know each LSR's capability for
>>  reading the maximum label stack depth and performing EL-based load-
>>  balancing, referred to as Entropy Readable Label Depth (ERLD).  This
>>  document defines a mechanism to signal these two capabilities using
>>  OSPFv2 and OSPFv3 and BGP-LS.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
>> https://datatracker.ietf.org/doc/html/draft-ietf-ospf-mpls-elc-15
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-15
>>
>>
>> Please note that it may take a couple of minutes from the time of submission 
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mai

Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

[Peter Psenak]

Tianran,

On 02/06/2020 08:14, Tianran Zhou wrote:

Hi Peter,

I do not understand how RFC8667 relates to ELC signaling.


RFC 8667 - IS-IS Extensions for Segment Routing


RFC 8667 "have been defined to signal labels", but "This draft defines a mechanism 
to signal the ELC using IS-IS."


yes, and as labels are now signaled by IGPs, we provide a method to 
signal ELC/ERLD by IGPs as well.




On the other hand, RFC 8667 is the extension for segment routing.
Is this draft only for segment routing, or be generic?


the requirement document is RFC8662, which is SR specific.



Another thing I am not clear is the difference between "multi-area" and 
"multi-domain" here after:
"Even though ELC is a property of the node, in some cases it is
advantageous to associate and advertise the ELC with a prefix.  In a
multi-area network, routers may not know the identity of the prefix
originator in a remote area, or may not know the capabilities of such
originator.  Similarly, in a multi-domain network, the identity of
the prefix originator and its capabilities may not be known to the
ingress LSR."



multi area is single IGP with multiple areas. Mutli domain is multiple IGPs.

thanks,
Peter



Tianran

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Monday, June 1, 2020 6:56 PM
To: Tianran Zhou ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt

Tianran,

On 01/06/2020 12:49, Tianran Zhou wrote:

Hi Authors,

I see the following words in the introduction.
"   Recently, mechanisms have been defined to signal labels via link-
 state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667].  "

It's not clear to me what the " mechanisms " are. Could you please add some 
reference or text on this?


the reference is there - RFC8667.


thanks,
Peter



Thanks,
Tianran

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Monday, June 1, 2020 4:42 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

  Title   : Signaling Entropy Label Capability and Entropy 
Readable Label Depth Using OSPF
  Authors : Xiaohu Xu
Sriganesh Kini
Peter Psenak
Clarence Filsfils
Stephane Litkowski
Matthew Bocci
Filename: draft-ietf-ospf-mpls-elc-15.txt
Pages   : 9
Date: 2020-06-01

Abstract:
 Multiprotocol Label Switching (MPLS) has defined a mechanism to load-
 balance traffic flows using Entropy Labels (EL).  An ingress Label
 Switching Router (LSR) cannot insert ELs for packets going into a
 given Label Switched Path (LSP) unless an egress LSR has indicated
 via signaling that it has the capability to process ELs, referred to
 as the Entropy Label Capability (ELC), on that LSP.  In addition, it
 would be useful for ingress LSRs to know each LSR's capability for
 reading the maximum label stack depth and performing EL-based load-
 balancing, referred to as Entropy Readable Label Depth (ERLD).  This
 document defines a mechanism to signal these two capabilities using
 OSPFv2 and OSPFv3 and BGP-LS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-15
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-mpls-elc-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-mpls-elc-15


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

[Loa Andersson]

Folks,

I have two questions on the early allocation.

RFC 7120 allows early allocation for two types of

   The processes described below assume that the document in question is
   the product of an IETF Working Group (WG).  If this is not the case,
   replace "WG chairs" below with "Shepherding Area Director".

draft-li-lsr-isis-area-proxy is an individual document, i.e. not a
product of a working group nor shepherded by an AD, and does not seem to
meet the criteria for early allocation.

Also. draft-li-lsr-isis-area-proxy request that IANA create a new
registry, as far as I understand new registries can't be created through
early allocation. It is hardly necessary.

The code points are requested from "the IS-IS TLV Codepoints registry",
howver the "IS-IS TLV Codepoints" is a name space with 14 different
registries. I think the the registry you want to allocated code point
from the "TLV Codepoints registry"

Since the document, at least I read it, well meet the criteria for 
becoming a working document (minor update to the IANA section), I think

that the easy way out is to start the working group adoption poll.

/Loa


On 02/06/2020 12:52, Tony Li wrote:


Hi Amanda,

However, the IANA Considerations section is missing some information. 
How would we fill in the IIH, LSP, SNP, and Purge fields for the TLV 
Codepoint registrations?



We’ve addressed this in 
https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-06..


Thanks,
Sarah & Tony


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



--

My mail server from time to time has come under DOS attacks,
we are working to fix it but it may take some time. If you
get denial of service sending to me plz try to use
loa.pi.nu@gmail


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

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