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

[Les Ginsberg (ginsberg)]

Jouni -

Just to let you know that V14 of the draft was posted today and it includes all 
of the corrections you requested.
Thanx again for your review.

   Les


> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Friday, May 29, 2020 8:02 AM
> To: Jouni Korhonen ; gen-...@ietf.org
> Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org
> Subject: RE: Genart last call review of draft-ietf-isis-te-app-13
> 
> Jouni -
> 
> Thanx for the review.
> 
> I have addressed the editorial issues you raised - though I will wait for
> additional comments from other reviewers before publishing a new version.
> 
>Les
> 
> 
> > -Original Message-
> > From: Jouni Korhonen via Datatracker 
> > Sent: Friday, May 29, 2020 6:11 AM
> > To: gen-...@ietf.org
> > Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org
> > Subject: Genart last call review of draft-ietf-isis-te-app-13
> >
> > Reviewer: Jouni Korhonen
> > Review result: Ready with Nits
> >
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed
> > by the IESG for the IETF Chair.  Please treat these comments just
> > like any other last call comments.
> >
> > For more information, please see the FAQ at
> >
> > .
> >
> > Document: draft-ietf-isis-te-app-??
> > Reviewer: Jouni Korhonen
> > Review Date: 2020-05-29
> > IETF LC End Date: 2020-05-29
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >
> > Not really my area of expertise, however, I did not spot any issues during
> the
> > review. The document is ready for publication.
> >
> > Major issues:
> >
> > None.
> >
> > Minor issues:
> >
> > None.
> >
> > Nits/editorial comments:
> >
> > * There are spacing issues mostly with parenthesis in the text that the RFC
> > editor likely takes care of. * On line 165 SR is used without expanding it. 
> > The
> > expansion is obvious but the RFC has both "Segment Routing" and "Shared
> > Risk"
> > used with SRxx.. * At least Section 5 has "is NOT" and "does NOT" emphasis
> > used. I would use just "is not" and "does not", since those with "NOT" are
> > not
> > in listed in normal "Requirements Language".
> >

___
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

[wangyali]

Hi Peter,

Thanks. Please see inline .

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

Yali,

please see inline:

On 04/06/2020 05:09, wangyali wrote:
> Hi Peter,
> 
> Please see inline . Thanks.
> 
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Wednesday, June 3, 2020 11:04 PM
> To: wangyali ; lsr@ietf.org
> Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
> 
> Yali,
> 
> On 03/06/2020 15:51, wangyali wrote:
>> Hi Peter,
>>
>> Thanks for your reply. please see inline .
>>
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Wednesday, June 3, 2020 7:44 PM
>> To: wangyali ; lsr@ietf.org
>> Subject: Re: [Lsr] I-D Action: draft-ietf-ospf-mpls-elc-15.txt
>>
>> Yali,
>>
>>
>> On 03/06/2020 13:35, wangyali wrote:
>>> Hi authors,
>>>
>>> After reading this draft, I am not clear with following points.
>>>
>>> First,  as said " Even though ELC is a property of the node, in some cases 
>>> it is advantageous to associate and advertise the ELC with a prefix.", what 
>>> are "some cases" in which it is advantageous to associate and advertise the 
>>> ELC with a prefix? And ELC is a property of the node, why don't extend the 
>>> OSPF RI Opaque LSA to carry ELC?
>>
>> this has been discussed on the WG alias endlessly, please go over the 
>> archives.
>>  Thanks. I think I lost some emails. I will search them. While I 
>> suggest give an illustration or some examples about the "some cases" in the 
>> draft. Please take it into account.
> 
> I will not make any changes to the draft at this point. The draft is in the 
> RFC queue, too late to make changes.
>  Thanks. I am going over the mail archive to find these cases. I am 
> very willing to learn and understand key points of this draft.
> 
>>
>>>
>>> Second, as said " If a router has multiple interfaces, the router MUST NOT 
>>> announce ELC unless all of its interfaces are capable of processing ELs. ", 
>>> why do not consider ELC advertisement in link granularity?
>>
>> and how do you as a remote router know over which interface, or better line 
>> card, the traffic that you are sending going to arrive on a remote node? 
>> Does not make much sense.
>>  So can we say that ELC advertisement in node granularity is expressed 
>> by host prefix attributes advertisement?
> 
> yes, pretty much that is the idea.
>  I am appreciate if you could summary the reason.

the reason is to support inter-area and inter-domain cases, where node 
attributes are not visible, but prefix attributes are.
Appreciate. While AFAIK, OSPFv2 type-11 RI Opaque LSAs and OSPFv3 
S1S2-01 RI Opaque LSAs are flooded  throughout the Autonomous System. For the 
Inter-Area flooding scope, I am not clear what is the difference?

> 
>>
>>>
>>> Third, as said " If the router supports ELs on all of its interfaces, it 
>>> SHOULD advertise the ELC with every local host prefix it advertises in 
>>> OSPF.", what is the "every local host prefix"?
>>
>> it's a locally generated host prefix.
>>
>>>
>>> Last one, as defined that ERLD is advertised in a Node MSD TLV, why the 
>>> ERLD-MSD type can be received in the OSPFv2 or OSPFv3 Link MSD sub-TLV? " 
>>> When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV 
>>> [RFC8476], it MUST be ignored."
>>
>> yes, what's wrong with that statement?
>>  I think it will not happen. Why is it necessary to specify this case?
> 
> If someone sends this as link MSD, we need to say how to deal with it as in 
> general MSDs can be send as node or link attributes.
>  OK. I think I got your point and I read sec.4 again. So ERLD 
> advertisement in a Node MSD TLV [RFC8476] is an optional method but not 
> mandatory, is it right?

correct.

thanks,
Peter

> 
> regards,
> Peter
> 
> 
> 
>>
>> regards,
>> Peter
>>
>>
>>>
>>> Best regards,
>>> Yali
>>>
>>> -Original Message-
>>> From: internet-dra...@ietf.org [mailto: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:
>>>   

[Lsr] WG Document Adoption Call

[Acee Lindem (acee)]

Note that it is appropriate for draft authors to request a WG adoption call. 
However, the actual adoption call needs to be done by the WG chairs and that is 
when support/objection is requested.
Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Call for WG adoption of https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01

[Jeff Tantsura]

yes/support

Cheers,
Jeff
On Jun 4, 2020, 11:05 AM -0700, Tony Przygienda , wrote:
> I would like to officially call out for adoption of 
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 as WG 
> document
>
> At this point in time flood reflection has been implemented and works meeting 
> use case requirements of multiple customers which neither TTZ nor draft-proxy 
> is addressing or can satisfy in terms of deployment realities. While we would 
> love to not squat on codepoints and ideally have an interoperable solution 
> between vendors it will be the customer reality that will drive deployment 
> and ultimately what runs in their networks.
>
> thanks
>
> --- tony
> ___
> 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] Call for WG adoption of https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01

[Lee, Yiu]

Support to adopt draft-przygienda-lsr-flood-reflection-01 as WG item.

Best,
Yiu

From: Lsr  on behalf of Tony Przygienda 

Date: Thursday, June 4, 2020 at 2:04 PM
To: "lsr@ietf.org" 
Subject: [Lsr] Call for WG adoption of 
https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01

I would like to officially call out for adoption of 
https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01
 as WG document

At this point in time flood reflection has been implemented and works meeting 
use case requirements of multiple customers which neither TTZ nor draft-proxy 
is addressing or can satisfy in terms of deployment realities. While we would 
love to not squat on codepoints and ideally have an interoperable solution 
between vendors it will be the customer reality that will drive deployment and 
ultimately what runs in their networks.

thanks

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

[Lsr] Call for WG adoption of https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01

[Sharma, Alankar]

We support the adoption of draft-przygienda-lsr-flood-reflection.

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

Re: [Lsr] Call for WG adoption of https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01

[Chris Bowers]

I support WG adoption of draft-przygienda-lsr-flood-reflection.

Chris

On Thu, Jun 4, 2020 at 1:05 PM Tony Przygienda  wrote:

> I would like to officially call out for adoption of
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 as
> WG document
>
> At this point in time flood reflection has been implemented and works
> meeting use case requirements of multiple customers which neither TTZ nor
> draft-proxy is addressing or can satisfy in terms of deployment realities.
> While we would love to not squat on codepoints and ideally have an
> interoperable solution between vendors it will be the customer reality that
> will drive deployment and ultimately what runs in their networks.
>
> thanks
>
> --- tony
> ___
> 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] Call for WG adoption of https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01

[Tony Przygienda]

I would like to officially call out for adoption of
https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 as WG
document

At this point in time flood reflection has been implemented and works
meeting use case requirements of multiple customers which neither TTZ nor
draft-proxy is addressing or can satisfy in terms of deployment realities.
While we would love to not squat on codepoints and ideally have an
interoperable solution between vendors it will be the customer reality that
will drive deployment and ultimately what runs in their networks.

thanks

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

Re: [Lsr] Request for Working Group Adoption: Area Proxy

[Tony Przygienda]

Since stuff seems to develop its own dynamics obviously I will start
another thread for official adoption by WG for
https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 in
this thread as well.

Further comments below

On Thu, Jun 4, 2020 at 9:43 AM  wrote:

>
> ...
>
> In IS-IS Flood Reflection (
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01),
> abstraction is achieved by mechanisms similar to ours, but transit service
> is achieved by tunneling transit traffic. That’s not necessary in our
> propsal.  In Flood Reduction, the also is coupled to the flooding
> reduction, whereas in our proposal, the two are independent, tho they do
> share the Area Leader mechanism.
>
>
This is technically incorrect. Flood reflection works fine without any
tunnels as the draft explains. Implemented and working.

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

Re: [Lsr] Request for Working Group Adoption: Area Proxy

[steve ulrich]

support.

On Thu, Jun 4, 2020 at 11:42 AM  wrote:

>
> Dear Gentlebeings,
>
> I would like to formally request working group adoption of “Area Proxy for
> IS-IS” (https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03).
>
> The goal of this work is to improve scalability of IS-IS when transit L1
> areas are in use.  In legacy IS-IS, for the L1 area topology to be utilized
> by L2, part of the topology must be configured as both Level 1 and Level 2.
> In the case where the transit topology is most or all of the L1 area, this
> creates a scalability issue as the size of the L2 LSDB approaches that of
> the entire network.
>
> We propose to address this by injecting only a single LSP into Level 2. We
> call this the Proxy LSP and it contains all reachability information for
> the L1 area plus connectivity from the L1 area to L2 adjacencies. The
> result is that the L1 area is now opaque, reachable, and fully capable of
> providing L2 transit.
>
> Our use case is the deployment of Clos topologies (e.g., spine-leaf
> topologies) as transit nodes, allowing these topologies to replace
> individual routers. We also see applications of this approach to abstract
> entire data centers or POPs as single nodes within the L2 area.
>
> There are two other proposals of note before the working group.
>
> In Topology Transparent Zones (
> https://tools.ietf.org/html/draft-chen-isis-ttz-08), an area (or zone)
> may be represented by a single node or as a full mesh of tunnels between
> the edges of the zone. In addition, there is a mechanism to attempt to
> seamlessly enable and disable the effectiveness of the zone. Relative to
> our proposal and for our use cases, the full mesh of tunnels is not as
> effective at providing scalability. In the specific case of spine-leaf
> networks, the leaves are typically the majority of the nodes in the
> network. As they become the edges of the area, with the full mesh approach,
> the majority of the area is not abstracted out of the L2 LSDB. For our use
> case, we have concerns about enabling and disabling the abstraction
> mechanism. There is added complexity to support this mechanism. In networks
> at scale, disabling abstraction may cause scalability failures. Enabling
> abstraction may cause failures as LSPs age out at dissimlar times. We feel
> that establishing abstraction is fundamental to the architecture of the
> network and that changing it on the fly is a highly risky operation, best
> suited for maintenance windows. Accordingly, the additional complexity of
> the transition mechanism is not required.
>
> In IS-IS Flood Reflection (
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01),
> abstraction is achieved by mechanisms similar to ours, but transit service
> is achieved by tunneling transit traffic. That’s not necessary in our
> propsal.  In Flood Reduction, the also is coupled to the flooding
> reduction, whereas in our proposal, the two are independent, tho they do
> share the Area Leader mechanism.
>
> While both of these proposals are very worthy, we believe that our
> proposal has substantial merit. We ask that the WG adopt Area Proxy for
> further work.
>
> Regards,
> Tony & Sarah
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>


-- 
steve ulrich (sulrich@botwerks.*)
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request for Working Group Adoption: Area Proxy

[Hannes Gredler]

support

Sent from my iPhone

> On 04.06.2020, at 18:43, tony...@tony.li wrote:
> 
> 
> 
> Dear Gentlebeings,
> 
> I would like to formally request working group adoption of “Area Proxy for 
> IS-IS” (https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03).
> 
> The goal of this work is to improve scalability of IS-IS when transit L1 
> areas are in use.  In legacy IS-IS, for the L1 area topology to be utilized 
> by L2, part of the topology must be configured as both Level 1 and Level 2. 
> In the case where the transit topology is most or all of the L1 area, this 
> creates a scalability issue as the size of the L2 LSDB approaches that of the 
> entire network.
> 
> We propose to address this by injecting only a single LSP into Level 2. We 
> call this the Proxy LSP and it contains all reachability information for the 
> L1 area plus connectivity from the L1 area to L2 adjacencies. The result is 
> that the L1 area is now opaque, reachable, and fully capable of providing L2 
> transit.
> 
> Our use case is the deployment of Clos topologies (e.g., spine-leaf 
> topologies) as transit nodes, allowing these topologies to replace individual 
> routers. We also see applications of this approach to abstract entire data 
> centers or POPs as single nodes within the L2 area.
> 
> There are two other proposals of note before the working group.
> 
> In Topology Transparent Zones 
> (https://tools.ietf.org/html/draft-chen-isis-ttz-08), an area (or zone) may 
> be represented by a single node or as a full mesh of tunnels between the 
> edges of the zone. In addition, there is a mechanism to attempt to seamlessly 
> enable and disable the effectiveness of the zone. Relative to our proposal 
> and for our use cases, the full mesh of tunnels is not as effective at 
> providing scalability. In the specific case of spine-leaf networks, the 
> leaves are typically the majority of the nodes in the network. As they become 
> the edges of the area, with the full mesh approach, the majority of the area 
> is not abstracted out of the L2 LSDB. For our use case, we have concerns 
> about enabling and disabling the abstraction mechanism. There is added 
> complexity to support this mechanism. In networks at scale, disabling 
> abstraction may cause scalability failures. Enabling abstraction may cause 
> failures as LSPs age out at dissimlar times. We feel that establishing 
> abstraction is fundamental to the architecture of the network and that 
> changing it on the fly is a highly risky operation, best suited for 
> maintenance windows. Accordingly, the additional complexity of the transition 
> mechanism is not required.
> 
> In IS-IS Flood Reflection 
> (https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01), 
> abstraction is achieved by mechanisms similar to ours, but transit service is 
> achieved by tunneling transit traffic. That’s not necessary in our propsal.  
> In Flood Reduction, the also is coupled to the flooding reduction, whereas in 
> our proposal, the two are independent, tho they do share the Area Leader 
> mechanism.
> 
> While both of these proposals are very worthy, we believe that our proposal 
> has substantial merit. We ask that the WG adopt Area Proxy for further work.
> 
> Regards,
> Tony & Sarah
> ___
> 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] Request for Working Group Adoption: Area Proxy

[tony . li]

Dear Gentlebeings,

I would like to formally request working group adoption of “Area Proxy for 
IS-IS” (https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03 
).

The goal of this work is to improve scalability of IS-IS when transit L1 areas 
are in use.  In legacy IS-IS, for the L1 area topology to be utilized by L2, 
part of the topology must be configured as both Level 1 and Level 2. In the 
case where the transit topology is most or all of the L1 area, this creates a 
scalability issue as the size of the L2 LSDB approaches that of the entire 
network.

We propose to address this by injecting only a single LSP into Level 2. We call 
this the Proxy LSP and it contains all reachability information for the L1 area 
plus connectivity from the L1 area to L2 adjacencies. The result is that the L1 
area is now opaque, reachable, and fully capable of providing L2 transit.

Our use case is the deployment of Clos topologies (e.g., spine-leaf topologies) 
as transit nodes, allowing these topologies to replace individual routers. We 
also see applications of this approach to abstract entire data centers or POPs 
as single nodes within the L2 area.

There are two other proposals of note before the working group.

In Topology Transparent Zones 
(https://tools.ietf.org/html/draft-chen-isis-ttz-08 
), an area (or zone) may be 
represented by a single node or as a full mesh of tunnels between the edges of 
the zone. In addition, there is a mechanism to attempt to seamlessly enable and 
disable the effectiveness of the zone. Relative to our proposal and for our use 
cases, the full mesh of tunnels is not as effective at providing scalability. 
In the specific case of spine-leaf networks, the leaves are typically the 
majority of the nodes in the network. As they become the edges of the area, 
with the full mesh approach, the majority of the area is not abstracted out of 
the L2 LSDB. For our use case, we have concerns about enabling and disabling 
the abstraction mechanism. There is added complexity to support this mechanism. 
In networks at scale, disabling abstraction may cause scalability failures. 
Enabling abstraction may cause failures as LSPs age out at dissimlar times. We 
feel that establishing abstraction is fundamental to the architecture of the 
network and that changing it on the fly is a highly risky operation, best 
suited for maintenance windows. Accordingly, the additional complexity of the 
transition mechanism is not required.

In IS-IS Flood Reflection 
(https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 
), 
abstraction is achieved by mechanisms similar to ours, but transit service is 
achieved by tunneling transit traffic. That’s not necessary in our propsal.  In 
Flood Reduction, the also is coupled to the flooding reduction, whereas in our 
proposal, the two are independent, tho they do share the Area Leader mechanism.

While both of these proposals are very worthy, we believe that our proposal has 
substantial merit. We ask that the WG adopt Area Proxy for further work.

Regards,
Tony & Sarah___
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 IPR Poll

[Acee Lindem (acee)]

I’ve received IPR responses from all the authors but Dean Cheng. Please respond.
Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, May 15, 2020 at 3:48 PM
To: "draft-cc-lsr-flooding-reduct...@ietf.org" 

Cc: "lsr@ietf.org" 
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 IPR Poll

Authors,

Are you aware of any IPR that applies to draft-cc-lsr-flooding-reduction-08.txt.

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

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,
Acee
___
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

[Les Ginsberg (ginsberg)]

Bruno -

Thanx again for your review.
V14 of the draft has been posted to address your comments.

Please let me know if you believe there are still outstanding issues.

A few more remarks inline.

> -Original Message-
> From: bruno.decra...@orange.com 
> Sent: Tuesday, June 02, 2020 9:33 AM
> To: Les Ginsberg (ginsberg) 
> Cc: last-c...@ietf.org; draft-ietf-isis-te-app@ietf.org; lsr@ietf.org; 
> rtg-
> d...@ietf.org
> Subject: RE: Rtgdir last call review of draft-ietf-isis-te-app-13
> 
> 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.
> 

[Les:] I took a second look at this and appreciated your point better.
I changed the text to read:

" Undefined bits which are transmitted MUST be transmitted as 0..."

> 
> > And (repeating)
> >
> > "Bits that are NOT transmitted MUST be treated as if they
>> are set to 0 on receipt.  "
> >
> > And again, you assume 

[Lsr] I-D Action: draft-ietf-isis-te-app-14.txt

[internet-drafts]

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   : IS-IS TE Attributes per application
Authors : Les Ginsberg
  Peter Psenak
  Stefano Previdi
  Wim Henderickx
  John Drake
Filename: draft-ietf-isis-te-app-14.txt
Pages   : 21
Date: 2020-06-04

Abstract:
   Existing traffic engineering related link attribute advertisements
   have been defined and are used in RSVP-TE deployments.  Since the
   original RSVP-TE use case was defined, additional applications (e.g.,
   Segment Routing Traffic Engineering, Loop Free Alternate) have been
   defined which also make use of the link attribute advertisements.  In
   cases where multiple applications wish to make use of these link
   attributes the current advertisements do not support application
   specific values for a given attribute nor do they support indication
   of which applications are using the advertised value for a given
   link.  This document introduces new link attribute advertisements
   which address both of these shortcomings.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-isis-te-app-14
https://datatracker.ietf.org/doc/html/draft-ietf-isis-te-app-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-te-app-14


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] [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

[Les Ginsberg (ginsberg)]

Folks -

Replying to the WG list on this as we believe this is of interest to the entire 
WG.

The designated experts (Chris, Hannes, and myself) have discussed the request 
for early codepoint allocations for draft-li-lsr-isis-area-proxy-04.

Ordinarily such requests are routine. Our task is only to perform due diligence 
to insure that the codepoints are assigned appropriately.

In this case however, we are - for the first time - being asked to provide 
early allocations for a document which has yet to be adopted by the WG.
Guidance for us is provided in RFC7370. 
Specifically

Section 4 which states

"2.  The Designated Experts SHOULD only consider requests that arise
   from I-Ds that have already been accepted as Working Group
   documents or that are planned for progression as AD Sponsored
   documents in the absence of a suitably chartered Working Group."

This recommendation is sound since early allocations for documents which do not 
achieve RFC status ultimately expire and are deallocated under the
procedures defined in rfc7120 . While WG 
adoption is not a guarantee of successful progression to RFC, it does commit 
the WG to working on such documents and greatly enhances the chances of
an RFC being published.

While the language above allows for exceptions, we are reluctant to make an 
exception in this case.

We note that the problem space being addressed by draft-li-lsr-isis-area-proxy 
has stimulated multiple solutions/drafts. The likelihood that some of the 
proposed solutions would be abandoned and/or not achieve market acceptance 
seems high.
Early allocation of code points without a WG commitment then seems to have a 
higher than normal probability that the codepoint allocations would ultimately 
be deallocated.

We believe that the WG needs to invest time in deciding which solutions should 
go forward. We therefore encourage the WG to make expeditious decisions 
regarding WG adoption of one (or perhaps multiple) of the drafts addressing 
this problem space.

We will be happy to quickly review early allocation requests for any documents 
as soon as they achieve WG status.

   Les and Chris and Hannes






> -Original Message-

> From: Lsr  On Behalf Of Amanda Baber via RT

> Sent: Monday, June 01, 2020 6:13 PM

> To: Acee Lindem (acee) 

> Cc: lsr@ietf.org; martin.vigour...@nokia.com

> Subject: [Lsr] [IANA #1171772] Early Allocations request for "Area Proxy for

> IS-IS" - draft-li-lsr-isis-area-proxy-04

>

> Hi Acee, Martin,

>

> We've sent this request to the IS-IS experts for review in accordance with

> the RFC 7370 early allocation procedure for IS-IS Expert Review registries.

>

> We understand that if the experts approve, we would make three

> early/temporary registrations in the TLV Codepoints registry and add one

> entry to the Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV) registry. The

> creation of the sub-registry will have to wait for the document to be

> approved for publication.

>

> 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?

>

> Best regards,

>

> Amanda Baber

> Lead IANA Services Specialist

>

> On Mon Jun 01 19:46:54 2020, a...@cisco.com 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

[Lsr] Change of email address

[Alexander Vainshtein]

Dear colleagues,
Following the acquisition of my employer - ECI Telecom, by Ribbon, starting 
from 09-Jun-20 all the mails I will send to IETF will use 
alexander.vainsht...@rbbn.com as my 
address.

I will still be receiving emails addressed to 
alexander.vainsht...@ecitele..com (at 
least for the time being).

I will re-subscribe to all the IETF mailing lists using my new email once it 
becomes operational.

Regards, and apologies for possible inconvenience,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr