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

[Melchior Aelmans]

I support adoption. It solve a real life problem in a more elegant way than 
other comparable work does. 
Also it is backwards comparable which makes it an easier conversation with 
customers. 

Thanks,
Melchior

> Op 6 jun. 2020 om 02:12 heeft Jeffrey (Zhaohui) Zhang 
>  het volgende geschreven:
> 
> 
> Support the author’s request for adoption.
>  
> Jeffrey
>  
>  
> Juniper Business Use Only
> From: Lsr  On Behalf Of Tony Przygienda
> Sent: Thursday, June 4, 2020 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
>  
> [External Email. Be cautious of content]
>  
> 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

[Gyan Mishra]

I Support  WG adoption of draft-przygienda-lsr-flood-reflection-01.  This
new ISIS flood reflection extension similar to BGP route reflection
scalability concept, provides a valuable feature to optimize many L1/L2
adjacencies for very large contiguous L2 domains that span L1 areas.

Gyan


On Fri, Jun 5, 2020 at 8:12 PM Jeffrey (Zhaohui) Zhang  wrote:

> Support the author’s request for adoption.
>
>
>
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Lsr  *On Behalf Of * Tony Przygienda
> *Sent:* Thursday, June 4, 2020 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
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
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 Yingzhen,

Thank you very much for your support and comment.
My answer/explanation is inline below.

Best Regards,
Huaimo

From: Yingzhen Qu 
Sent: Friday, June 5, 2020 3:37 PM
To: Acee Lindem (acee) ; lsr@ietf.org 
; Huaimo Chen 
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


Hi,



I support adoption of this draft.



Hi Huaimo,



I have a question regarding the draft. At the end of section 3, it says if 
there is any change in the base topology, the flooding topology MUST be 
re-computed. So in case of a link failure in the base topo, it’s possible that 
the link is not part of the flooding topology (e.g. one of the multiple links 
between two nodes), it might be optimal if we can figure it out and save 
recalculation here.

[HC]: This will make sure that the flooding topologies computed by all the 
routers will be the same. If the algorithm does not compute a new flooding 
topology when a link that is not on the current flooding topology fails, we 
need prove that in any sequence of changes in base topology reaching to 
different LSDBs in different times the flooding topology computed by the 
algorithm on one router will be the same as the one computed by the algorithm 
on another router in this way.  After there is a proof, the optimized algorithm 
can be used.



Thanks,

Yingzhen



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

Date: Friday, June 5, 2020 at 10:09 AM
To: "lsr@ietf.org" 
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
Resent-From: 



Speaking as WG Member:



Hi Authors,



I have a couple technical comments on the draft.



  1.  The algorithm only computes a single graph with single path to each node. 
While I-D.ietf-lsr-dynamic-flooding failure and computation of an updated 
flooding topology, many of the other algorithms (both draft and proprietary) 
attempt to compute two or more paths to each node.
  2.  Since this algorithm is slated for use as a distributed algorithm, all 
routers in the area must use the same value for MaxD or they may compute 
different flooding topologies. This is cannot be guaranteed by a single 
algorithm IANA value unless we allow some number of algorithm specific 
parameters to be advertised by the area leader (which might not be a bad idea).
  3.   Similarly, the constraints in section 4.2 must be applied uniformly and 
different constraints would require new IANA algorithm allocation.



Thanks,
Acee



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

Date: Friday, May 15, 2020 at 3:40 PM
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

[Huaimo Chen]

Hi Acee,

Thank you very much for your valuable comments.
My answers/explanations are inline below.

Best Regards,
Huaimo

From: Lsr  on behalf of Acee Lindem (acee) 

Sent: Friday, June 5, 2020 12:52 PM
To: lsr@ietf.org 
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


Speaking as WG Member:



Hi Authors,



I have a couple technical comments on the draft.



  1.  The algorithm only computes a single graph with single path to each node. 
While I-D.ietf-lsr-dynamic-flooding failure and computation of an updated 
flooding topology, many of the other algorithms (both draft and proprietary) 
attempt to compute two or more paths to each node.
[HC]: The flooding topology (or say a graph) computed by the algorithm has at 
least two paths to each node. At step 4 of the algorithm on page 5 of the 
draft, for each node B that has only one path to it on the flooding topology 
(i.e., the Degree of node B is one) , another path is added to it. Thus the 
final flooding topology (or say graph) computed by the algorithm has  two or 
more paths to every node.
  2.  Since this algorithm is slated for use as a distributed algorithm, all 
routers in the area must use the same value for MaxD or they may compute 
different flooding topologies. This is cannot be guaranteed by a single 
algorithm IANA value unless we allow some number of algorithm specific 
parameters to be advertised by the area leader (which might not be a bad idea).
[HC]: You are right. All the routers must use the same value for MaxD. We will 
update the draft for this accordingly. For now, MaxD has an initial value of 3 
(i.e., every router uses this initial value of 3 for MaxD).  The algorithm 
increases MaxD by one and restarts to compute the flooding topology with this 
new MaxD if it can not compute a flooding topology with the old MaxD. After 
some iterations in some cases, the flooding topology is computed. It is a good 
idea to pass some parameters from the area leader to every router when the 
leader advertises the algorithm number to every router.  MaxD can be one of the 
parameters.
  3.   Similarly, the constraints in section 4.2 must be applied uniformly and 
different constraints would require new IANA algorithm allocation.
[HC]: You are right. All the routers must use the same constraints.  A new (or 
different) set of constraints need a new algorithm number. We will update the 
draft for this accordingly.



Thanks,
Acee



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

Date: Friday, May 15, 2020 at 3:40 PM
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] Call for WG adoption of https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01

[Jeffrey (Zhaohui) Zhang]

Support the author's request for adoption.

Jeffrey



Juniper Business Use Only
From: Lsr  On Behalf Of Tony Przygienda
Sent: Thursday, June 4, 2020 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

[External Email. Be cautious of content]

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] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Yingzhen Qu]

Hi Tony,

Thanks for jumping in and the explanation. I support the idea of tradeoffs 
between pefection and simplicity. Analysis about the change of topology can be 
tricky, especially when adding links, and for a distributed algorithm it’s more 
important to achieve a definitive result. Maybe it’s easier to optimize some 
cases in a centralized-mode, but we always need to consider benefit-cost ratio.

The text in the draft is “MUST be”, so I thought I’d ask to confirm.

Thanks,
Yingzhen

From: Tony Li  on behalf of "tony...@tony.li" 

Date: Friday, June 5, 2020 at 2:56 PM
To: Yingzhen Qu 
Cc: "Acee Lindem (acee)" , "lsr@ietf.org" 
, Huaimo Chen 
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


Hi,



I have a question regarding the draft. At the end of section 3, it says if 
there is any change in the base topology, the flooding topology MUST be 
re-computed. So in case of a link failure in the base topo, it’s possible that 
the link is not part of the flooding topology (e.g. one of the multiple links 
between two nodes), it might be optimal if we can figure it out and save 
recalculation here.


This comment isn’t specific to this algorithm, so you’ll pardon me if I jump in.

Always recomputing the flooding topology is always a safe thing to do and for 
the case of a distributed algorithm is probably the safest design choice.

Doing the analysis about the change is not exactly trivial and computing the 
flooding topology is not that hard.  We are typically not short of CPU cycles 
and recomputing the flooding topology is outside of the critical convergence 
window, so while there is some theoretical benefit, it’s not at all clear that 
it’s of great practical benefit.  But it is up to those specifying the 
algorithm.

Regards,
Tony



___
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

[tony . li]

Hi,


> I have a question regarding the draft. At the end of section 3, it says if 
> there is any change in the base topology, the flooding topology MUST be 
> re-computed. So in case of a link failure in the base topo, it’s possible 
> that the link is not part of the flooding topology (e.g. one of the multiple 
> links between two nodes), it might be optimal if we can figure it out and 
> save recalculation here.


This comment isn’t specific to this algorithm, so you’ll pardon me if I jump in.

Always recomputing the flooding topology is always a safe thing to do and for 
the case of a distributed algorithm is probably the safest design choice.

Doing the analysis about the change is not exactly trivial and computing the 
flooding topology is not that hard.  We are typically not short of CPU cycles 
and recomputing the flooding topology is outside of the critical convergence 
window, so while there is some theoretical benefit, it’s not at all clear that 
it’s of great practical benefit.  But it is up to those specifying the 
algorithm.

Regards,
Tony



___
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

[Yingzhen Qu]

Hi,

I support adoption of this draft.

Hi Huaimo,

I have a question regarding the draft. At the end of section 3, it says if 
there is any change in the base topology, the flooding topology MUST be 
re-computed. So in case of a link failure in the base topo, it’s possible that 
the link is not part of the flooding topology (e.g. one of the multiple links 
between two nodes), it might be optimal if we can figure it out and save 
recalculation here.

Thanks,
Yingzhen

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

Date: Friday, June 5, 2020 at 10:09 AM
To: "lsr@ietf.org" 
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
Resent-From: 

Speaking as WG Member:

Hi Authors,

I have a couple technical comments on the draft.


  1.  The algorithm only computes a single graph with single path to each node. 
While I-D.ietf-lsr-dynamic-flooding failure and computation of an updated 
flooding topology, many of the other algorithms (both draft and proprietary) 
attempt to compute two or more paths to each node.
  2.  Since this algorithm is slated for use as a distributed algorithm, all 
routers in the area must use the same value for MaxD or they may compute 
different flooding topologies. This is cannot be guaranteed by a single 
algorithm IANA value unless we allow some number of algorithm specific 
parameters to be advertised by the area leader (which might not be a bad idea).
  3.   Similarly, the constraints in section 4.2 must be applied uniformly and 
different constraints would require new IANA algorithm allocation.

Thanks,
Acee

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

Date: Friday, May 15, 2020 at 3:40 PM
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

[Acee Lindem (acee)]

Speaking as WG Member:

Hi Authors,

I have a couple technical comments on the draft.


  1.  The algorithm only computes a single graph with single path to each node. 
While I-D.ietf-lsr-dynamic-flooding failure and computation of an updated 
flooding topology, many of the other algorithms (both draft and proprietary) 
attempt to compute two or more paths to each node.
  2.  Since this algorithm is slated for use as a distributed algorithm, all 
routers in the area must use the same value for MaxD or they may compute 
different flooding topologies. This is cannot be guaranteed by a single 
algorithm IANA value unless we allow some number of algorithm specific 
parameters to be advertised by the area leader (which might not be a bad idea).
  3.   Similarly, the constraints in section 4.2 must be applied uniformly and 
different constraints would require new IANA algorithm allocation.

Thanks,
Acee

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

Date: Friday, May 15, 2020 at 3:40 PM
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] Rtgdir last call review of draft-ietf-isis-te-app-13

[Les Ginsberg (ginsberg)]

Bruno -



Inline.



> -Original Message-

> From: bruno.decra...@orange.com 

> Sent: Friday, June 05, 2020 5:55 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 the updated draft.

> Looks ok to me except the point on interoperability.

>

> Indeed, I was asking to reinforce the requirement for interoperability with

> existing attributes, as this interop issue is created by this

> specification/extension. But you chose the opposite direction by calling

> existing routers "legacy routers" and by removing the "must" in the below

> sentence from -13 "must be able to co-exist with use  of the legacy

> advertisements by routers which do not support the extensions defined in

> this document.".

> IMHO this document was primarily motivated by interoperability issues with

> implementations. This was correctly pointed out in [1], more specifically "

> Existing IS-IS standards do not provide a mechanism to explicitly indicate

> whether or not RSVP has been enabled on a link.  Instead, different RSVP-TE

> implementations have used the presence of certain traffic engineering sub-

> TLVs in IS-IS to infer that RSVP signalling is enabled on a given link."

>



[Les:] This is not correct.

The motivations for the draft are stated in the Introduction.

The issue discussed in 
https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-protocols-03#section-1
 has nothing to do with this draft.



> In such condition, IMHO draft-ietf-isis-te-app should not have the potential

> to create new interop issues in the future, otherwise its net gain with 
> regards

> to existing ("legacy") attributes seems debatable to me.

>

> Moving the requirement for interoperability on the deployment side (i.e.,

> network operator) as per -14, may prove difficult or impossible if

> implementers are not willing to accommodate. Given that, as you state it,

> there motivation is what's good for _their_ business, it seems a possibility

> that such vendor would argue that the network operator should just replace

> all their "older" routers with new ones, and as a matter of luck, they do have

> a very good deal to propose. I have seen this movie before (e.g. with LDP &

> TDP).

>

> I also understand your point as a vendor.

> After thinking about it for a while, I'd propose a resolution around 
> indicating

> that interoperability is required but only for implementations supporting

> both new and current attributes. This cover my point for interop and a priori

> cover your point to allow implementation to only support the new attributes.

>

> e.g. with the below text in §6.1

> OLD:

> Under the conditions defined above, implementations which support the

>extensions defined in this document have the choice of using legacy

>advertisements or application specific advertisements in support of

>SRTE and/or LFA.  This will require implementations to provide

>controls specifying which type of advertisements are to be sent/

>processed on receive for these applications.

>

> NEW:

> Under the conditions defined above, implementations which support

> both the legacy advertisements and the extensions defined in this document

> MUST provide controls  specifying which type of

> advertisements are to be sent and which type of advertisements are to be

> processed on receive for these applications.

>

> Or possibly much closer to your original text

> NEW2

> Under the conditions defined above, implementations which support

>  both the legacy advertisements and the extensions defined in this

> document

> have the choice of using legacy

>advertisements or application specific advertisements in support of

>SRTE and/or LFA.  Implementations are REQUIRED to provide

>controls specifying which type of advertisements are to be sent/

>processed on receive for these applications.

>



[Les:] It is not within the purview of the IETF to mandate what features 
vendors support.

What is normative in this draft - as with all protocol enhancements - is the 
definition of how "bits on the wire" are sent/received.



The introduction of any protocol extension in brownfield deployments creates 
the possibility that some routers support the extension and some do not.

How vendors handle this is an implementation issue.

We have provided guidance in this draft as to what issues may arise and what 
strategies can be used to address the interoperability issues - as well as how 
to migrate from a mixture of legacy/new to all new. But I do not believe we can 
make normative statements requiring implementations to support all 
combinations. If we did so, we would then be responsible for declaring when 
implementations are no longer required to support backwards compatibility 
because legacy support is no

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

[bruno.decraene]

Les,

Thanks for the updated draft.
Looks ok to me except the point on interoperability. 

Indeed, I was asking to reinforce the requirement for interoperability with 
existing attributes, as this interop issue is created by this 
specification/extension. But you chose the opposite direction by calling 
existing routers "legacy routers" and by removing the "must" in the below 
sentence from -13 "must be able to co-exist with use  of the legacy 
advertisements by routers which do not support the extensions defined in this 
document.".
IMHO this document was primarily motivated by interoperability issues with 
implementations. This was correctly pointed out in [1], more specifically " 
Existing IS-IS standards do not provide a mechanism to explicitly indicate 
whether or not RSVP has been enabled on a link.  Instead, different RSVP-TE 
implementations have used the presence of certain traffic engineering sub-TLVs 
in IS-IS to infer that RSVP signalling is enabled on a given link."

In such condition, IMHO draft-ietf-isis-te-app should not have the potential to 
create new interop issues in the future, otherwise its net gain with regards to 
existing ("legacy") attributes seems debatable to me.

Moving the requirement for interoperability on the deployment side (i.e., 
network operator) as per -14, may prove difficult or impossible if implementers 
are not willing to accommodate. Given that, as you state it, there motivation 
is what's good for _their_ business, it seems a possibility that such vendor 
would argue that the network operator should just replace all their "older" 
routers with new ones, and as a matter of luck, they do have a very good deal 
to propose. I have seen this movie before (e.g. with LDP & TDP).

I also understand your point as a vendor.
After thinking about it for a while, I'd propose a resolution around indicating 
that interoperability is required but only for implementations supporting both 
new and current attributes. This cover my point for interop and a priori cover 
your point to allow implementation to only support the new attributes.

e.g. with the below text in §6.1
OLD:
Under the conditions defined above, implementations which support the
   extensions defined in this document have the choice of using legacy
   advertisements or application specific advertisements in support of
   SRTE and/or LFA.  This will require implementations to provide
   controls specifying which type of advertisements are to be sent/
   processed on receive for these applications.

NEW:
Under the conditions defined above, implementations which support 
both the legacy advertisements and the extensions defined in this document MUST 
provide controls  specifying which type of
advertisements are to be sent and which type of advertisements are to be 
processed on receive for these applications.

Or possibly much closer to your original text
NEW2
Under the conditions defined above, implementations which support
 both the legacy advertisements and the extensions defined in this document
have the choice of using legacy
   advertisements or application specific advertisements in support of
   SRTE and/or LFA.  Implementations are REQUIRED to provide
   controls specifying which type of advertisements are to be sent/
   processed on receive for these applications.


I would also revert the text in section 6.3 to the one present in version -13.

Thank you
--Bruno

[1] 
https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-protocols-03#section-1
  
 
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
> 
> 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

[Lsr] I-D Action: draft-ietf-ospf-te-link-attr-reuse-13.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   : OSPF Link Traffic Engineering Attribute Reuse
Authors : Peter Psenak
  Les Ginsberg
  Wim Henderickx
  Jeff Tantsura
  John Drake
Filename: draft-ietf-ospf-te-link-attr-reuse-13.txt
Pages   : 21
Date: 2020-06-05

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 in
   OSPFv2 and OSPFv3 which address both of these shortcomings.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-te-link-attr-reuse-13
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-te-link-attr-reuse-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-te-link-attr-reuse-13


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] Query on OSPFv2 Extended Link TLV

[JAZEEL MOHAMMED]

Thanks a lot Acee for quick response.

Regards,
Jazeel Mohammed

On Fri, Jun 5, 2020 at 5:23 PM Acee Lindem (acee)  wrote:

> Hi Jazeel,
>
>
>
>
>
> *From: *Lsr  on behalf of JAZEEL MOHAMMED <
> jazee...@gmail.com>
> *Date: *Friday, June 5, 2020 at 7:41 AM
> *To: *"lsr@ietf.org" 
> *Subject: *[Lsr] Query on OSPFv2 Extended Link TLV
>
>
>
> Hi LSR WG,
>
>
>
> I am finding it hard to understand the below statement under section "3.1.
> OSPFv2 Extended Link TLV" in RFC7684..
>
>
>
> " If this TLV is advertised multiple times in the same OSPFv2
> Extended Link Opaque LSA, only the first instance of the TLV is used
> by receiving OSPFv2 routers. This situation SHOULD be logged as an error."
>
>
>
> is this statement applicable only for multiple Extended Link TLV with
> same Link Type and Link Id or any multiple Extended Link TLV in same OSPFv2
> Extended Link Opaque LSA?
>
>
>
> An OSPFv2 Extended Link Opaque LSA will include attributes for a single
> link so it applies irrespective of Link Type and Link ID.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
>
> Please advise on the same.
>
>
>
> Thank you,
>
> Jazeel Mohammed
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Query on OSPFv2 Extended Link TLV

[Acee Lindem (acee)]

Hi Jazeel,


From: Lsr  on behalf of JAZEEL MOHAMMED 

Date: Friday, June 5, 2020 at 7:41 AM
To: "lsr@ietf.org" 
Subject: [Lsr] Query on OSPFv2 Extended Link TLV

Hi LSR WG,

I am finding it hard to understand the below statement under section "3.1. 
OSPFv2 Extended Link TLV" in RFC7684..

" If this TLV is advertised multiple times in the same OSPFv2 Extended Link 
Opaque LSA, only the first instance of the TLV is used by receiving OSPFv2 
routers. This situation SHOULD be logged as an error."

is this statement applicable only for multiple Extended Link TLV with same Link 
Type and Link Id or any multiple Extended Link TLV in same OSPFv2 Extended Link 
Opaque LSA?

An OSPFv2 Extended Link Opaque LSA will include attributes for a single link so 
it applies irrespective of Link Type and Link ID.

Thanks,
Acee



Please advise on the same.

Thank you,
Jazeel Mohammed
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Query on OSPFv2 Extended Link TLV

[JAZEEL MOHAMMED]

Hi LSR WG,

I am finding it hard to understand the below statement under section "3.1.
OSPFv2 Extended Link TLV" in RFC7684.

" If this TLV is advertised multiple times in the same OSPFv2 Extended Link
Opaque LSA, only the first instance of the TLV is used by receiving OSPFv2
routers. This situation SHOULD be logged as an error."

is this statement applicable only for multiple Extended Link TLV with
same Link Type and Link Id or any multiple Extended Link TLV in same OSPFv2
Extended Link Opaque LSA?

Please advise on the same.

Thank you,
Jazeel Mohammed
___
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

[Acee Lindem (acee)]

Hi Yali, 

On 6/5/20, 4:52 AM, "Lsr on behalf of wangyali"  wrote:

Hi Peter,
Please see inline .
Thanks,
Yali

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

Yali,

On 05/06/2020 06:25, wangyali wrote:
> 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?

it is certainly not flooded across multiple IGP domains.
 I think it's helpful for a case that advertisement by using IGP 
alone. Is it right?

Advertisement outside the OSPF routing domain is dictated by local 
redistribution policy (aka, import/export policy) and is certainly beyond the 
scope of this specification. Whether or not  such advertisement is helpful is 
dependent on the use case but I'm sure there would be situations where it would 
be helpful.

Thanks,
Acee

thanks,
Peter


> 
>>
>>>

 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 

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

[wangyali]

Hi Peter,
Please see inline .
Thanks,
Yali

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

Yali,

On 05/06/2020 06:25, wangyali wrote:
> 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?

it is certainly not flooded across multiple IGP domains.
 I think it's helpful for a case that advertisement by using IGP alone. 
Is it right?

thanks,
Peter


> 
>>
>>>

 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

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

[Peter Psenak]

Yali,

On 05/06/2020 06:25, wangyali wrote:

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?


it is certainly not flooded across multiple IGP domains.

thanks,
Peter










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