Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Peter Psenak]

Hi Shraddha,

draft-ietf-lsr-flex-algo-00 was published May 15, 2018 (over two years 
ago). 




It clearly stated:

https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00#section-9

"To advertise a link affinity in a form of the AG or EAG that is used
 during Flex-Algorithm calculation, an Application Specific Link
 Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV
 of Extended Link TLV as described in [I-D.ietf-ospf-te-link-attr-reuse]
 MUST be used. The advertisement MUST indicate that it is usable by the
 Flex-Algorithm application."

This is consistent with normative statements in both 
https://tools.ietf.org/html/draft-ietf-isis-te-app-19 and 
https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/ 
which REQUIRE the use of application specific advertisements by all 
applications other than the legacy applications (RSVP-TE, Segment 
Routing Policy,  Loop Free Alternate).


draft-hegdeppsenak-isis-sr-flex-algo had a lifetime of 10 months(V00 
published in July 2017) and draft-ppsenak-ospf-sr-flex-algo only 3 
months (V00 published in Feb 2018).


Juniper may have its own reasons why over the course of the past two 
years it has chosen not to modify its early implementation to be 
compatible with what is defined in the WG adopted draft. We do not 
question this choice. But it seems the most appropriate way to 
communicate this is for Juniper to document in its vendor specific 
documents that its implementation is based on a pre-WG draft and is 
incompatible with the IETF defined standard. IETF documents are not the 
correct place for such proprietary information.


It is obvious that the implementation that is not following the
final specification will not interoperate with other implementations 
that do so. There is no need to mention that in the RFC.


thanks,
Peter and Les



On 25/08/2020 17:27, Shraddha Hegde wrote:

Hi All,

draft-lsr-flex-algo-00 was created by combining

draft-hegdeppsenak-isis-sr-flex-algo-02 and 
draft-ppsenak-ospf-sr-flex-algo-00.


When draft-lsr-flex-algo-00 was published as a WG document, it included

a requirement for using te-app encodings that did not exist in either

draft-hegdeppsenak-isis-sr-flex-algo-02 and 
draft-ppsenak-ospf-sr-flex-algo-00.


Juniper's currently released implementation of flex-algo uses legacy 
encodings,


as opposed to te-app encodings.  I would like the following text added to

draft-lsr-flex-algo in order to record the history of these changes and 
to make


operators aware of possible inter-op problems that may arise due to the

non-backward compatible nature of mandating ASLA encodings.

=

11.  Advertisement of Link Attributes for Flex-Algorithm

" Earlier versions of this draft did not mandate the use of ASLA TLVs 
for encoding the


link attributes. There may be implementations that depend on legacy 
encodings as defined in


RFC 5305, RFC 7810 , RC 3630 and RFC 7471. Implementations that look at 
only ASLA encodings


for flex-algo based on this version of the document will not 
interoperate with versions


that use legacy advertisements. "



Rgds

Shraddha

Juniper Business Use Only

*From:*olivier.dug...@orange.com 
*Sent:* Thursday, August 20, 2020 7:56 PM
*To:* Peter Psenak ; tony...@tony.li; Robert Raszuk 

*Cc:* Christian Hopps ; 
draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
; lsr@ietf.org; lsr-...@ietf.org; 
Acee Lindem (acee) 

*Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

*[External Email. Be cautious of content]*

Peter,

Le 20/08/2020 à 14:12, Peter Psenak a écrit :

Hi Olivier,

On 20/08/2020 13:58, olivier.dug...@orange.com
 wrote:

Hi Peter,

Thank for the new version.

Le 19/08/2020 à 14:00, Peter Psenak a écrit :

Olivier,

[ ... ]

So, to speed up the deployment, I would prefer a
reference to a delay value that could be advertise by
means of RFC7471, RFC8570 and/or TE-App draft. It is
then up to the operator to ensure the coherency of what
it is announced in its network by the different routers.


I know you don't like the app specific link advertisement,
but I'm afraid what you ask for is absolutely wrong.

We defined the ASLA encoding to address a real problems for
advertising the link attributes. We allow the link
attributes to be advertised in both legacy and ASLA
advertisement for legacy application (RSVP-TE, SRTE) to
address the backward compatibility. Flex-algo is a new
application, there is absolutely no need to use the legacy
advertisement. Doing so would just extend the problem to the
flex-algo application.


Regarding the new version you provided, new section 5.1 (for
IS-IS) and section 5.2 (for OSPF) mention respectively RF

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[reta Yang]

I support the adoption.
This protocol can ease the deployment overhead.

Thanks,
Reta


From: Lsr  on behalf of Acee Lindem (acee) 

Sent: Tuesday, August 18, 2020 10:16 PM
To: lsr@ietf.org 
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt




Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.



These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.



We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.



Thanks,

Acee and Chris


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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[ruoxin huang]

I support working group adoption of this draft.

Best,
Ruoxin

Sent from Outlook


From: Lsr  on behalf of reta Yang 
Sent: Thursday, August 27, 2020 7:48 PM
To: lsr@ietf.org 
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

I support the adoption.
This protocol can ease the deployment overhead.

Thanks,
Reta


From: Lsr  on behalf of Acee Lindem (acee) 

Sent: Tuesday, August 18, 2020 10:16 PM
To: lsr@ietf.org 
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt




Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.



These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.



We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.



Thanks,

Acee and Chris


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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[Les Ginsberg (ginsberg)]

Tony –

Inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Wednesday, August 26, 2020 8:56 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi Les,

[Les:] Any one of the IERs can be elected Area Leader, therefore all of them 
have to be configured with the Area Prefix and associated SID.


The Area Leader may not be an IER.  In fact, in an important use case for us, 
the area is a leaf-spine topology.  The Area Leader is one of the spines.  The 
leaves are the edge routers.  For resource reasons, we do NOT want the Area 
Leader to be a leaf.

[Les:] Thanx for clarifying this. A careful reading of the draft supports what 
you say, but as this point could be easily overlooked it might be worth 
emphasizing this in the draft.
In any case this isn’t significant for the points we are debating here.

We do NOT require that the Area Leader candidates have identical 
configurations.  In fact, if there is a configuration change, it may be 
beneficial to configure one candidate differently and then raise its priority.  
It’s a simple way of effecting an area-wide configuration change.

[Les:] Section 4.2 states:

“For consistency, all Area Leader candidates SHOULD be configured with
   the same Proxy System Id, Proxy Hostname, and any other information
   that may be inserted into the Proxy LSP.”

I would agree that the flexibility to easily propagate a config change to be 
reflected in the Proxy LSP content requires relaxation of this rule.
But again, not significant for the points we are debating here.


Perhaps you are allowing that each IER could choose a different Area 
Prefix/SID. Not sure why you would want to do that – but even if you did, the 
behavior of the winning prefix/SID is analogous to an anycast address.
The difference here is that the advertisement of the Prefix Reachability 
associated with the area prefix is within the Proxy LSP – which appears to OERs 
as if it was originated by all of the IERs i.e., the set of IERs appears as a 
single node to the OERs. Still, all IERs are aware of the winning prefix 
reachability advertisement and will do what is required in forwarding based on 
that content.


They will not be aware of it unless we tell them via the Area Proxy TLV.  For 
obvious reasons, the Inside Nodes do NOT do anything with the Proxy LSP other 
than flood it.


Which is why we’re using the Prefix SID.

[Les:] You are using the prefix-SID, but the advertisement is not associated 
with a prefix reachability  advertisement, yet you want nodes to install 
forwarding entries based on this advertisement. This is what seems 
inappropriate.


We want outside nodes to install forwarding entries on the Prefix SID.  This is 
entirely backward compatible.  How is that inappropriate?

[Les:] Installation of forwarding entries today is based on Prefix Reachability 
advertisements. You are proposing to extend that by requiring a forwarding 
entry to be installed based on the context of the Area Proxy TLV.
I would prefer that you not introduce this.
In addition, since there will also be a Prefix Reachability Advertisement for 
the Area Prefix in the Proxy LSP, the IERs will have two sources of information 
for the SID associated with the Area prefix (Area SID sub-TLV from Area leader 
L2 LSP and Prefix Reachability advertisement in the Proxy LSP). Which 
introduces the possibility of inconsistency.
If you do NOT advertise the SID in the Area Proxy TLV then you both eliminate 
the introduction of installing forwarding entries based on non-reachability 
advertisements and you eliminate the possibility of inconsistency.
That is what I am asking you to do.


The only current case where a prefix-SID is advertised and is NOT associated 
with prefix reachability is in the Binding TLVs. This has two use cases:

  *   Advertising SIDs for prefixes associated with nodes which are NOT SR 
capable
  *   As an alternative to per prefix advertisement if the operator prefers to 
use a centralized SID assignment service

In both of these cases if a SID were to be advertised in prefix reachability 
TLV for the same prefix the SID in the prefix reachability advertisement would 
be preferred.
You don’t discuss this at all in the draft i.e., what happens if the SID in the 
prefix reachability advertisement for the Area Prefix differs from that 
advertised in the Area Proxy TLV. What I am pushing for is eliminating the need 
to do so by relying on the existing prefix SID advertisements and not 
introducing a new one in the Area Proxy TLV.


The existing ones do not have the required semantics.

[Les:] That’s wasn’t the point. The point was that when a SID is advertised in 
prefix reachability it is used in preference to advertisements in other TLVs.


[Les:] The semantics you require are functionally equivalent to anycast 
behavior – which is supported already.


Please point me to anycast semantics that will ONLY be selected by IERs.
[Les:] You

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[tony . li]

Les,

 
> [Les:] Thanx for clarifying this. A careful reading of the draft supports 
> what you say, but as this point could be easily overlooked it might be worth 
> emphasizing this in the draft.


Noted and enhanced.

> We do NOT require that the Area Leader candidates have identical 
> configurations.  In fact, if there is a configuration change, it may be 
> beneficial to configure one candidate differently and then raise its 
> priority.  It’s a simple way of effecting an area-wide configuration change.  
>  
> [Les:] Section 4.2 states:
>  
> “For consistency, all Area Leader candidates SHOULD be configured with
>the same Proxy System Id, Proxy Hostname, and any other information
>that may be inserted into the Proxy LSP.”
>  
> I would agree that the flexibility to easily propagate a config change to be 
> reflected in the Proxy LSP content requires relaxation of this rule.


This is exactly why it says SHOULD and not MUST.


> We want outside nodes to install forwarding entries on the Prefix SID.  This 
> is entirely backward compatible.  How is that inappropriate?
>  
> [Les:] Installation of forwarding entries today is based on Prefix 
> Reachability advertisements. You are proposing to extend that by requiring a 
> forwarding entry to be installed based on the context of the Area Proxy TLV.
> I would prefer that you not introduce this.


I am well aware of that.

Perhaps it would help if I tell you that I am 100% impervious to Persuasion by 
Repetition.  I understand what you want. I disagree with you on the tradeoffs.


> In addition, since there will also be a Prefix Reachability Advertisement for 
> the Area Prefix in the Proxy LSP, the IERs will have two sources of 
> information for the SID associated with the Area prefix (Area SID sub-TLV 
> from Area leader L2 LSP and Prefix Reachability advertisement in the Proxy 
> LSP). Which introduces the possibility of inconsistency.


No, since the IERs are supposed to ignore the Proxy LSP for any purpose other 
than flooding. I’m adding an explicit statement to this effect. The only source 
of truth is the Area Proxy TLV generated by the Area Leader.


> The existing ones do not have the required semantics.
>  
> [Les:] That’s wasn’t the point.



That is the entire point.  You insist that we advertise the Area SID as a 
Prefix SID in addition to the a prefix in the Area Proxy TLV.  The additional 
Prefix SID does NOT have the semantics that we want and causes deleterious 
side-effects.



> The point was that when a SID is advertised in prefix reachability it is used 
> in preference to advertisements in other TLVs.


Except when it is part of the Proxy LSP, in which case we want the Inside 
Routers to ignore it.  We do NOT want Inside Routers creating forwarding state 
or SPF state for every prefix and SID in the Proxy LSP.


> [Les:] The semantics you require are functionally equivalent to anycast 
> behavior – which is supported already.
>  
>  
> Please point me to anycast semantics that will ONLY be selected by IERs. 
> [Les:] You have specified that only IERs and Outside Routers process Proxy 
> LSP content.  So why do you ask this question?


You’re asking me to use another mechanism.  I don’t see how it applies.  I’m 
open to you educating me.

IERs do NOT process Proxy LSP content other than to flood it.

Tony


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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[Les Ginsberg (ginsberg)]

Tony –

The statement “the … Prefix SID does NOT have the semantics that we want and 
causes deleterious side-effects” is FALSE.

Other than  that,  we understand each other and we disagree.
You have my input.

There is an alternative here:

Given that there isn’t any defined use case for the Area Prefix/SID, you could 
choose to defer its definition until such time as a use case arises.
I agree that the concept is appealing and is potentially useful – which is why 
I thought it worthwhile to invest time in defining it. But a conservative 
approach might be to wait until we actually need it before defining it. It is 
always possible that when the use case arises we will find that there are some 
other issues which have been overlooked which might alter how this would be 
advertised.

   Les


From: Tony Li  On Behalf Of tony...@tony.li
Sent: Thursday, August 27, 2020 8:19 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Les,


[Les:] Thanx for clarifying this. A careful reading of the draft supports what 
you say, but as this point could be easily overlooked it might be worth 
emphasizing this in the draft.


Noted and enhanced.

We do NOT require that the Area Leader candidates have identical 
configurations.  In fact, if there is a configuration change, it may be 
beneficial to configure one candidate differently and then raise its priority.  
It’s a simple way of effecting an area-wide configuration change.

[Les:] Section 4.2 states:

“For consistency, all Area Leader candidates SHOULD be configured with
   the same Proxy System Id, Proxy Hostname, and any other information
   that may be inserted into the Proxy LSP.”

I would agree that the flexibility to easily propagate a config change to be 
reflected in the Proxy LSP content requires relaxation of this rule.


This is exactly why it says SHOULD and not MUST.



We want outside nodes to install forwarding entries on the Prefix SID.  This is 
entirely backward compatible.  How is that inappropriate?

[Les:] Installation of forwarding entries today is based on Prefix Reachability 
advertisements. You are proposing to extend that by requiring a forwarding 
entry to be installed based on the context of the Area Proxy TLV.
I would prefer that you not introduce this.


I am well aware of that.

Perhaps it would help if I tell you that I am 100% impervious to Persuasion by 
Repetition.  I understand what you want. I disagree with you on the tradeoffs.



In addition, since there will also be a Prefix Reachability Advertisement for 
the Area Prefix in the Proxy LSP, the IERs will have two sources of information 
for the SID associated with the Area prefix (Area SID sub-TLV from Area leader 
L2 LSP and Prefix Reachability advertisement in the Proxy LSP). Which 
introduces the possibility of inconsistency.


No, since the IERs are supposed to ignore the Proxy LSP for any purpose other 
than flooding. I’m adding an explicit statement to this effect. The only source 
of truth is the Area Proxy TLV generated by the Area Leader.


The existing ones do not have the required semantics.

[Les:] That’s wasn’t the point.



That is the entire point.  You insist that we advertise the Area SID as a 
Prefix SID in addition to the a prefix in the Area Proxy TLV.  The additional 
Prefix SID does NOT have the semantics that we want and causes deleterious 
side-effects.




The point was that when a SID is advertised in prefix reachability it is used 
in preference to advertisements in other TLVs.


Except when it is part of the Proxy LSP, in which case we want the Inside 
Routers to ignore it.  We do NOT want Inside Routers creating forwarding state 
or SPF state for every prefix and SID in the Proxy LSP.



[Les:] The semantics you require are functionally equivalent to anycast 
behavior – which is supported already.


Please point me to anycast semantics that will ONLY be selected by IERs.
[Les:] You have specified that only IERs and Outside Routers process Proxy LSP 
content.  So why do you ask this question?


You’re asking me to use another mechanism.  I don’t see how it applies.  I’m 
open to you educating me.

IERs do NOT process Proxy LSP content other than to flood it.

Tony


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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[tony . li]

Les,

 
> The statement “the … Prefix SID does NOT have the semantics that we want and 
> causes deleterious side-effects” is FALSE.


Ahem.  I disagree.  No need to be rude about it.


> There is an alternative here:
>  
> Given that there isn’t any defined use case for the Area Prefix/SID, you 
> could choose to defer its definition until such time as a use case arises.
> I agree that the concept is appealing and is potentially useful – which is 
> why I thought it worthwhile to invest time in defining it. But a conservative 
> approach might be to wait until we actually need it before defining it. It is 
> always possible that when the use case arises we will find that there are 
> some other issues which have been overlooked which might alter how this would 
> be advertised.


You’ve heard two of our customers here on the list tell you that they want 
this.  Therefore, we’re going to ship it.

Tony


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