Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Les Ginsberg (ginsberg)]

Tony –

If the choice is to use a prefix, I do not know why you even raise the 
possibility of advertising the SID other than how Prefix SIDs are done today.
Is the current Reachability advertisement inadequate in some way? I don’t think 
so.

   Les


From: Tony Li 
Sent: Thursday, August 06, 2020 11:46 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Bruno Decraene 
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Hi Les,

1)Invent a new type of SID which is associated with an area.
In this case some variation of encodings defined in V2 of the draft are 
appropriate.


But these aren’t backward compatible, which operators clearly want.


2)Use a reachable address to get to the area. That address could be the node 
address of the current Area Leader or an anycast address shared by all IERs.


Either of these is fine by me.  Do others care?



IN which case existing prefix SID advertisement is appropriate coupled with a 
means of identifying the address. There are two proposed encodings for that.


And here we haven’t come to agreement.  Do others have a preference?

Tony


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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Tony Li]

Hi Les,

> 1)Invent a new type of SID which is associated with an area.
> In this case some variation of encodings defined in V2 of the draft are 
> appropriate.


But these aren’t backward compatible, which operators clearly want.

 
> 2)Use a reachable address to get to the area. That address could be the node 
> address of the current Area Leader or an anycast address shared by all IERs.


Either of these is fine by me.  Do others care?


> IN which case existing prefix SID advertisement is appropriate coupled with a 
> means of identifying the address. There are two proposed encodings for that.


And here we haven’t come to agreement.  Do others have a preference?

Tony


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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Les Ginsberg (ginsberg)]

Tony –

There are two options that have been proposed:

1)Invent a new type of SID which is associated with an area.
In this case some variation of encodings defined in V2 of the draft are 
appropriate.

2)Use a reachable address to get to the area. That address could be the node 
address of the current Area Leader or an anycast address shared by all IERs.
IN which case existing prefix SID advertisement is appropriate coupled with a 
means of identifying the address. There are two proposed encodings for that.

Pick either of the two options above and I would find it acceptable.

   Les

From: Tony Li 
Sent: Thursday, August 06, 2020 2:42 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Bruno Decraene 
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Les,

Not sure why this needs to be explained.


Because we are not communicating well. We are each making unstated assumptions 
that do not mesh.

When we do not communicate, it’s time to double check the basics.



Whether you are doing label forwarding or IP forwarding, the path of the packet 
still depends upon reaching the destination.
If I have a unicast destination then the packet needs to reach the unique 
advertiser of that destination.
If I have an anycast destination then the packet needs to reach only one of the 
possibly many advertisers of that destination.


You’re assuming that there’s actually traffic that is destined to the specified 
prefix.  I don’t share that assumption.  [Communication just improved!]

At the end of the day, we’re talking about TE here and path computation is not 
only about destinations.  It’s also about the path itself. The purpose of the 
Area SID is to provide a waypoint for path computation, not to provide a 
destination.


Are you proposing for “Area SID” that we tie the SID to a prefix but alter the 
logic such that nodes which do not advertise the prefix can be considered as 
the final destination?
I would not like to go down that path…


From my perspective, the entire purpose of the Area SID is to provide the SID 
value so that some controller somewhere, in its infinite wisdom, can stick a 
label somewhere in some lable stack and route packets via the Proxy Area.  The 
sole purpose of the prefix is to make SR syntax happy.  [See previous rant 
about encodings in IS-IS.] For my intent, we could use 0.0.0.0/32 and 0::0/128.

Let me turn it around: what’s the simplest thing that we could do that would 
satisfy you?

Tony

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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Tony Li]

Les,

> Not sure why this needs to be explained.


Because we are not communicating well. We are each making unstated assumptions 
that do not mesh.

When we do not communicate, it’s time to double check the basics.


> Whether you are doing label forwarding or IP forwarding, the path of the 
> packet still depends upon reaching the destination.
> If I have a unicast destination then the packet needs to reach the unique 
> advertiser of that destination.
> If I have an anycast destination then the packet needs to reach only one of 
> the possibly many advertisers of that destination.


You’re assuming that there’s actually traffic that is destined to the specified 
prefix.  I don’t share that assumption.  [Communication just improved!]

At the end of the day, we’re talking about TE here and path computation is not 
only about destinations.  It’s also about the path itself. The purpose of the 
Area SID is to provide a waypoint for path computation, not to provide a 
destination.

 
> Are you proposing for “Area SID” that we tie the SID to a prefix but alter 
> the logic such that nodes which do not advertise the prefix can be considered 
> as the final destination?
> I would not like to go down that path…


From my perspective, the entire purpose of the Area SID is to provide the SID 
value so that some controller somewhere, in its infinite wisdom, can stick a 
label somewhere in some lable stack and route packets via the Proxy Area.  The 
sole purpose of the prefix is to make SR syntax happy.  [See previous rant 
about encodings in IS-IS.] For my intent, we could use 0.0.0.0/32 and 0::0/128. 
 

Let me turn it around: what’s the simplest thing that we could do that would 
satisfy you?

Tony

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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Gyan Mishra]

Hi Tony

See section 3.3.1 of RFC 8402 SR Architecture

https://tools.ietf.org/html/rfc8402#section-3.3.1

It has a nice graphical explanation of SR-MPLS Anycast usage.

The concept of Anycast SID is similar to Multicast group GDA conceptually
and similar to IGP routing anycast construct of proximity routing but more
like the former GDA based routing.

Basically you can have a group of nodes in the SR domain that can be
assigned an Anycast SID A and another group an Anycast SID B for the nodes
and a common group outer label Anycast SID is assigned to forward to the
Group of nodes represented by the Anycast SID.  The inner label is
basically a common label to forward to the group of nodes.

You can think of Anycast as similar to SR-TR prefix sid steering ECMP
pathing where all paths are active to get to the unicast destination.

In this case its all paths active but now to a pseudo multicast like
“anycast sid” group destination.

The concept of Anycast SID exists with SRv6 as well.

I think to your point I am not sure why it matters and can the Area prefix
be either unicast or Anycast.  As far at the area leader if that is a
single node then the node sid could be utilized and if the area leader is a
group or more then one node then a Anycast sid could be utilized.  I think
flexibility would be best so it can be either as you pointed out.

Kind Regards


Gyan

On Thu, Aug 6, 2020 at 12:32 PM Tony Li  wrote:

>
>
> Les,
>
> * There then remains the question as to whether the “Area Prefix” is
> anycast or unicast i.e., is it common to all IERs or is it unique to
> whomever gets elected Area Leader?*
>
>
> Does it matter? We have no clear semantics for this prefix. A difference
> that makes no difference is no difference.
>
> *[Les:] This question needs to be directed at those who prefer the Area
> Prefix approach. It matters as it impacts configuration and advertisement
> semantics. An anycast prefix is NOT a Node Prefix.*
> *And it impacts how traffic is forwarded into the area.*
>
>
>
>
> How so?  Traffic will be directed to the SID value (modulo PHP).
> *[Les3:] If the prefix is private to a single router then traffic has to
> pass through that router. If it is anycast the traffic could arrive at any
> one of the routers supporting the anycast address.*
>
>
>
> I must be missing something. My understanding of SR is that you forward
> based on the label.  Please educate me.
>
> 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] draft-ietf-lsr-isis-area-proxy-02

[Les Ginsberg (ginsberg)]

Tony –

Not sure why this needs to be explained.
Whether you are doing label forwarding or IP forwarding, the path of the packet 
still depends upon reaching the destination.
If I have a unicast destination then the packet needs to reach the unique 
advertiser of that destination.
If I have an anycast destination then the packet needs to reach only one of the 
possibly many advertisers of that destination.

Are you proposing for “Area SID” that we tie the SID to a prefix but alter the 
logic such that nodes which do not advertise the prefix can be considered as 
the final destination?
I would not like to go down that path…

   Les


From: Tony Li 
Sent: Thursday, August 06, 2020 9:32 AM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Bruno Decraene 
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02



Les,

 There then remains the question as to whether the “Area Prefix” is anycast or 
unicast i.e., is it common to all IERs or is it unique to whomever gets elected 
Area Leader?

Does it matter? We have no clear semantics for this prefix. A difference that 
makes no difference is no difference.

[Les:] This question needs to be directed at those who prefer the Area Prefix 
approach. It matters as it impacts configuration and advertisement semantics. 
An anycast prefix is NOT a Node Prefix.
And it impacts how traffic is forwarded into the area.



How so?  Traffic will be directed to the SID value (modulo PHP).
[Les3:] If the prefix is private to a single router then traffic has to pass 
through that router. If it is anycast the traffic could arrive at any one of 
the routers supporting the anycast address.



I must be missing something. My understanding of SR is that you forward based 
on the label.  Please educate me.

Tony

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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Tony Li]

Les,

>  There then remains the question as to whether the “Area Prefix” is anycast 
> or unicast i.e., is it common to all IERs or is it unique to whomever gets 
> elected Area Leader?
>   
> Does it matter? We have no clear semantics for this prefix. A difference that 
> makes no difference is no difference.
>  
> [Les:] This question needs to be directed at those who prefer the Area Prefix 
> approach. It matters as it impacts configuration and advertisement semantics. 
> An anycast prefix is NOT a Node Prefix.
> And it impacts how traffic is forwarded into the area.
>  
>  
>  
> How so?  Traffic will be directed to the SID value (modulo PHP). 
> [Les3:] If the prefix is private to a single router then traffic has to pass 
> through that router. If it is anycast the traffic could arrive at any one of 
> the routers supporting the anycast address.
> 


I must be missing something. My understanding of SR is that you forward based 
on the label.  Please educate me.

Tony

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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Les Ginsberg (ginsberg)]

Tony -

From: Tony Li 
Sent: Wednesday, August 05, 2020 4:26 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Bruno Decraene 
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Les,

This would make the Area Prefix mandatory for Area Proxy, which is not desired. 
 We would prefer it to remain optional and thus part of the Area SID sub-TLV.

[Les2:] You can advertise the Area Prefix in an optional sub-TLV – just as you 
did with the Area SID. That is what I expected you would do.


Good.  I’ve just submitted -03, which does exactly that.  Please review.  Note 
that tools.ietf.org<http://tools.ietf.org> appears to be down at this instant. 
(??!?!?!)

[Les3:] Yes – I saw that after my reply. My comments still stand.

b)The remaining info (reachability and SID) can then be provided using existing 
Prefix Reachability advertisements – no need for new sub-TLV for “Area SID”. 
This eliminates any potential issues if the SID advertised by “Area SID 
sub-TLV” were to differ from the SID advertised in Prefix Reachability for the 
same prefix.


As we discussed privately, we view this as a non-issue.  The Area Leader is the 
one advertising both the Area SID sub-TLV and the Proxy LSP. If there’s a 
coding error, there’s a coding error. There is a single source of truth (the 
Area Leader’s config) and we cannot protect against every possible coding 
error.  Reconciling the prefix with a separate advertisement has a non-trivial 
chance of being broken too, and IMHO, much larger.

[Les2:] You can define the advertisements in a way which reduces the 
possibility of ambiguity – which seems like a good thing to me.
And rest assured that you will be asked by someone to define the expected 
behavior when there is an inconsistency. 


Same question: same answer. :-)



Since prefix SID and Prefix reachability are directly related in forwarding, it 
makes far more sense to me to have those two together.
If you find correlating information in two different TLVs too challenging, you 
could opt for a new bit in the prefix attributes sub-TLV to identify a prefix 
as an “Area Prefix”. Then you would not need any additional info advertised in 
the Area Proxy TLV at all.


We prefer to keep it in the Area Proxy TLV so that its semantics are crystal 
clear.

[Les3:] This will make it more awkward (at best) to reuse the concept outside 
of the  Area Proxy use case. The prefix attributes option would make it very 
easy for any use case to be supported.


 There then remains the question as to whether the “Area Prefix” is anycast or 
unicast i.e., is it common to all IERs or is it unique to whomever gets elected 
Area Leader?

Does it matter? We have no clear semantics for this prefix. A difference that 
makes no difference is no difference.

[Les:] This question needs to be directed at those who prefer the Area Prefix 
approach. It matters as it impacts configuration and advertisement semantics. 
An anycast prefix is NOT a Node Prefix.
And it impacts how traffic is forwarded into the area.



How so?  Traffic will be directed to the SID value (modulo PHP).
[Les3:] If the prefix is private to a single router then traffic has to pass 
through that router. If it is anycast the traffic could arrive at any one of 
the routers supporting the anycast address.

   Les

Tony

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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Tony Li]

Les,

> This would make the Area Prefix mandatory for Area Proxy, which is not 
> desired.  We would prefer it to remain optional and thus part of the Area SID 
> sub-TLV.
>  
> [Les2:] You can advertise the Area Prefix in an optional sub-TLV – just as 
> you did with the Area SID. That is what I expected you would do.


Good.  I’ve just submitted -03, which does exactly that.  Please review.  Note 
that tools.ietf.org  appears to be down at this 
instant. (??!?!?!)


> b)The remaining info (reachability and SID) can then be provided using 
> existing Prefix Reachability advertisements – no need for new sub-TLV for 
> “Area SID”. This eliminates any potential issues if the SID advertised by 
> “Area SID sub-TLV” were to differ from the SID advertised in Prefix 
> Reachability for the same prefix.
>  
>  
> As we discussed privately, we view this as a non-issue.  The Area Leader is 
> the one advertising both the Area SID sub-TLV and the Proxy LSP. If there’s a 
> coding error, there’s a coding error. There is a single source of truth (the 
> Area Leader’s config) and we cannot protect against every possible coding 
> error.  Reconciling the prefix with a separate advertisement has a 
> non-trivial chance of being broken too, and IMHO, much larger.
>  
> [Les2:] You can define the advertisements in a way which reduces the 
> possibility of ambiguity – which seems like a good thing to me.
> And rest assured that you will be asked by someone to define the expected 
> behavior when there is an inconsistency. 


Same question: same answer. :-)


> Since prefix SID and Prefix reachability are directly related in forwarding, 
> it makes far more sense to me to have those two together.
> If you find correlating information in two different TLVs too challenging, 
> you could opt for a new bit in the prefix attributes sub-TLV to identify a 
> prefix as an “Area Prefix”. Then you would not need any additional info 
> advertised in the Area Proxy TLV at all.


We prefer to keep it in the Area Proxy TLV so that its semantics are crystal 
clear.

>  There then remains the question as to whether the “Area Prefix” is anycast 
> or unicast i.e., is it common to all IERs or is it unique to whomever gets 
> elected Area Leader?
>   
> Does it matter? We have no clear semantics for this prefix. A difference that 
> makes no difference is no difference.
>  
> [Les:] This question needs to be directed at those who prefer the Area Prefix 
> approach. It matters as it impacts configuration and advertisement semantics. 
> An anycast prefix is NOT a Node Prefix.
> And it impacts how traffic is forwarded into the area.
>  


How so?  Traffic will be directed to the SID value (modulo PHP). 

Tony

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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Les Ginsberg (ginsberg)]

Tony -

From: Tony Li 
Sent: Wednesday, August 05, 2020 1:08 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Bruno Decraene 
; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Les,



a)Advertise the “Area Prefix” in the Area Proxy TLV – much as we do a router-id 
today in the Router-ID TLV.


This would make the Area Prefix mandatory for Area Proxy, which is not desired. 
 We would prefer it to remain optional and thus part of the Area SID sub-TLV.

[Les2:] You can advertise the Area Prefix in an optional sub-TLV – just as you 
did with the Area SID. That is what I expected you would do.


b)The remaining info (reachability and SID) can then be provided using existing 
Prefix Reachability advertisements – no need for new sub-TLV for “Area SID”. 
This eliminates any potential issues if the SID advertised by “Area SID 
sub-TLV” were to differ from the SID advertised in Prefix Reachability for the 
same prefix.


As we discussed privately, we view this as a non-issue.  The Area Leader is the 
one advertising both the Area SID sub-TLV and the Proxy LSP. If there’s a 
coding error, there’s a coding error. There is a single source of truth (the 
Area Leader’s config) and we cannot protect against every possible coding 
error.  Reconciling the prefix with a separate advertisement has a non-trivial 
chance of being broken too, and IMHO, much larger.

[Les2:] You can define the advertisements in a way which reduces the 
possibility of ambiguity – which seems like a good thing to me.
And rest assured that you will be asked by someone to define the expected 
behavior when there is an inconsistency. 
Since prefix SID and Prefix reachability are directly related in forwarding, it 
makes far more sense to me to have those two together.
If you find correlating information in two different TLVs too challenging, you 
could opt for a new bit in the prefix attributes sub-TLV to identify a prefix 
as an “Area Prefix”. Then you would not need any additional info advertised in 
the Area Proxy TLV at all.


 There then remains the question as to whether the “Area Prefix” is anycast or 
unicast i.e., is it common to all IERs or is it unique to whomever gets elected 
Area Leader?


Does it matter? We have no clear semantics for this prefix. A difference that 
makes no difference is no difference.

[Les:] This question needs to be directed at those who prefer the Area Prefix 
approach. It matters as it impacts configuration and advertisement semantics. 
An anycast prefix is NOT a Node Prefix.
And it impacts how traffic is forwarded into the area.

   Les

Tony

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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Gyan Mishra]

Hi Bruno

>From an operators perspective your creative  idea of using the existing SR
machinery using the node SID to advertise the Area SID in the Proxy LSP is
very attractive to be able to support the feature immediately without
requiring a feature upgrade to support.

This idea really helps the area proxy concept  come to fruition without
impacting operations.

Thanks

Gyan

On Wed, Aug 5, 2020 at 4:08 PM Tony Li  wrote:

>
> Les,
>
>
> *a)Advertise the “Area Prefix” in the Area Proxy TLV – much as we do a
> router-id today in the Router-ID TLV.*
>
>
>
> This would make the Area Prefix mandatory for Area Proxy, which is not
> desired.  We would prefer it to remain optional and thus part of the Area
> SID sub-TLV.
>
>
> *b)The remaining info (reachability and SID) can then be provided using
> existing Prefix Reachability advertisements – no need for new sub-TLV for
> “Area SID”. This eliminates any potential issues if the SID advertised by
> “Area SID sub-TLV” were to differ from the SID advertised in Prefix
> Reachability for the same prefix.*
>
>
>
> As we discussed privately, we view this as a non-issue.  The Area Leader
> is the one advertising both the Area SID sub-TLV and the Proxy LSP. If
> there’s a coding error, there’s a coding error. There is a single source of
> truth (the Area Leader’s config) and we cannot protect against every
> possible coding error.  Reconciling the prefix with a separate
> advertisement has a non-trivial chance of being broken too, and IMHO, much
> larger.
>
>
>  *There then remains the question as to whether the “Area Prefix” is
> anycast or unicast i.e., is it common to all IERs or is it unique to
> whomever gets elected Area Leader?*
>
>
>
> Does it matter? We have no clear semantics for this prefix. A difference
> that makes no difference is no difference.
>
> 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] draft-ietf-lsr-isis-area-proxy-02

[Tony Li]

Les,


> a)Advertise the “Area Prefix” in the Area Proxy TLV – much as we do a 
> router-id today in the Router-ID TLV.


This would make the Area Prefix mandatory for Area Proxy, which is not desired. 
 We would prefer it to remain optional and thus part of the Area SID sub-TLV.


> b)The remaining info (reachability and SID) can then be provided using 
> existing Prefix Reachability advertisements – no need for new sub-TLV for 
> “Area SID”. This eliminates any potential issues if the SID advertised by 
> “Area SID sub-TLV” were to differ from the SID advertised in Prefix 
> Reachability for the same prefix.


As we discussed privately, we view this as a non-issue.  The Area Leader is the 
one advertising both the Area SID sub-TLV and the Proxy LSP. If there’s a 
coding error, there’s a coding error. There is a single source of truth (the 
Area Leader’s config) and we cannot protect against every possible coding 
error.  Reconciling the prefix with a separate advertisement has a non-trivial 
chance of being broken too, and IMHO, much larger.


>  There then remains the question as to whether the “Area Prefix” is anycast 
> or unicast i.e., is it common to all IERs or is it unique to whomever gets 
> elected Area Leader?


Does it matter? We have no clear semantics for this prefix. A difference that 
makes no difference is no difference.

Tony

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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Les Ginsberg (ginsberg)]

Acee -

From: Acee Lindem (acee) 
Sent: Wednesday, August 05, 2020 12:31 PM
To: Tony Li ; Bruno Decraene 
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi Tony, Bruno, Les,

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Tony 
Li mailto:tony1ath...@gmail.com>>
Date: Tuesday, August 4, 2020 at 11:26 AM
To: Bruno Decraene mailto:bruno.decra...@orange.com>>
Cc: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Hi Bruno,



[Bruno] Agreed so far.
Do we agree that draft-ietf-lsr-isis-area-proxy uses the SID/Label sub-TLV? We 
both agree that this sub-TLV has no mention of the global flag nor the routing 
algoto be used.


So far, we do NOT have agreement on that.  Your argument yesterday (backed by 
Robert) is pretty compelling: go ahead and assign a prefix and now the Area SID 
may be advertised as a Node SID in the Proxy LSP. If we take that direction, 
this discussion is moot.

Why wouldn’t we take this approach? Since the border routers are abstracting 
the area as a node, why wouldn’t we do the same for the Node-SID?

[Les:] The original idea proposed by the draft authors was to have a SID which 
could be used to forward traffic to the inside area. Conceptually this does not 
require a prefix – and the encodings currently defined in the draft reflect 
this.

Bruno has since commented that he prefers a prefix to be associated with the 
Area SID.
I agree this is a viable approach, but if we go that way then I think what is 
needed is:

a)Advertise the “Area Prefix” in the Area Proxy TLV – much as we do a router-id 
today in the Router-ID TLV.
b)The remaining info (reachability and SID) can then be provided using existing 
Prefix Reachability advertisements – no need for new sub-TLV for “Area SID”. 
This eliminates any potential issues if the SID advertised by “Area SID 
sub-TLV” were to differ from the SID advertised in Prefix Reachability for the 
same prefix.

There then remains the question as to whether the “Area Prefix” is anycast or 
unicast i.e., is it common to all IERs or is it unique to whomever gets elected 
Area Leader?

   Les

Thanks,
Acee

Tony

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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Acee Lindem (acee)]

Hi Tony, Bruno, Les,

From: Lsr  on behalf of Tony Li 
Date: Tuesday, August 4, 2020 at 11:26 AM
To: Bruno Decraene 
Cc: "Les Ginsberg (ginsberg)" , "lsr@ietf.org" 

Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Hi Bruno,




[Bruno] Agreed so far.
Do we agree that draft-ietf-lsr-isis-area-proxy uses the SID/Label sub-TLV? We 
both agree that this sub-TLV has no mention of the global flag nor the routing 
algoto be used.


So far, we do NOT have agreement on that.  Your argument yesterday (backed by 
Robert) is pretty compelling: go ahead and assign a prefix and now the Area SID 
may be advertised as a Node SID in the Proxy LSP. If we take that direction, 
this discussion is moot.

Why wouldn’t we take this approach? Since the border routers are abstracting 
the area as a node, why wouldn’t we do the same for the Node-SID?

Thanks,
Acee

Tony

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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Tony Li]

Hi Bruno,


> 
> [Bruno] Agreed so far.
> Do we agree that draft-ietf-lsr-isis-area-proxy uses the SID/Label sub-TLV? 
> We both agree that this sub-TLV has no mention of the global flag nor the 
> routing algoto be used.


So far, we do NOT have agreement on that.  Your argument yesterday (backed by 
Robert) is pretty compelling: go ahead and assign a prefix and now the Area SID 
may be advertised as a Node SID in the Proxy LSP. If we take that direction, 
this discussion is moot.

Tony

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

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[bruno.decraene]

Les,

Please see inline.

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, August 4, 2020 4:50 PM
To: DECRAENE Bruno TGI/OLN ; lsr@ietf.org
Subject: RE: draft-ietf-lsr-isis-area-proxy-02

Bruno -

Please see inline.

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Tuesday, August 04, 2020 5:45 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi,

I may be missing something but the SR Binding SID TLV extension  is not clear 
to me.

1)  It does not seem compliant with RFC 8667

Draft says that the advertisement has: T-flag set, M & A flags cleared, 
SID/Label sub-TLV present, Prefix-SID sub-TLV NOT present


The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5)



 When T-flag is set:



M and A flag MUST be clear



Range and Prefix are ignored



  Section 2.4.4 of RFC 
8667 is altered to say:



 "The Prefix-SID sub-TLV MUST be present in the SID/Label

 Binding TLV when the M-Flag and T-flag are both clear.  The

 Prefix-SID sub-TLV MUST NOT be present when either the M-Flag

 or T-flag are set."



  Regarding the SID/Label sub-TLV Section 2.4.5 of RFC 
8667 is

  altered to say:



 "It MUST be present in the SID/Label Binding TLV when either

 the M-Flag or T-flag is set in the Flags field of the parent

 TLV."

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#page-14



By definition, legacy L2 external  node will support vanilla RFC 8667, which 
says:
"The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the 
M-Flag is clear."
https://www.rfc-editor.org/rfc/rfc8667.html#name-sid-label-binding-tlv

So it seems that the extension violates the above MUST in RFC8667, as regarding 
the Prefix-SID sub-TLV
-  Area proxy says "MUST NOT be present" (as T-flag is set)
-  RFC 8667 says "MUST be present" (as M-flag is cleared)


In addition to the above, legacy node _will_ interpret the 'Range' and 'Prefix' 
fields. So there is probably a need to specify which values need to be 
advertised for those legacy nodes. A priori range would be one as a single SID 
is advertised. Prefix seems more problematic as you need to find an IP prefix 
to advertise. And please let's avoid SID conflict and Prefix conflict...
[Les:] Format of the Binding TLV when the new T-bit is set is similar to the 
format when the M-bit is set in that Prefix-SID sub-TLV is NOT present.
A legacy node parsing the Binding TLV would be looking for the Prefix-SID 
sub-TLV (M-bit NOT set) and would not find it. The contents of the Binding TLV 
would therefore be unusable to a legacy node.
The correct behaviour for a legacy node would be to (optionally) report an 
"invalid TLV" and to ignore the TLV.
[Bruno]
Clearly, there is a way to advertise the SID without violating a MUST in a RFC. 
e.g. version -00 of this draft
I don't see a reason to define a spec which deliberately violates another spec. 
In the best case, this would report errors forever to the network operator. In 
the worst case, this could fall into a bug.


2)  It's not clear to me whether the segment/SID is global or local.
As per my understanding of the draft-ietf-lsr-isis-area-proxy use case, the 
area-proxy SID would be global (in the external L2): "Area SID which will 
direct traffic to any of the Inside Edge Routers."

But the SID/Label Sub-TLV used by area-proxy has no flag (L-flag) indicating 
whether the SID is global or local. One could argue that if it carries a label 
it's a local SID and if it carries and index it's a global SID. But this has 
not been specified.
It has also no "algorithm" indicating how it needs to be routed global, so at 
minimum would not work with different routing algo/flex algo.
I'm not seeing in RFC 8402 or 8667 any text saying that such SID would be 
global hence globally routed in the L2 domain. (To me, this IS-IS SID was 
local, but arguably also can't find text stating this).

[Les:] There is a subtle difference between the Prefix-SID sub-TLV as defined 
in https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1 and the SID/Label 
sub-TLV defined in https://www.rfc-editor.org/rfc/rfc8667.html#SIDLABELSUBTLV

The Prefix-SID sub-TLV has a flags field which includes V-bit/L-bit to indicate 
whether the variable length field which follows is a 3 byte label (both bits 
set to 1) or a 4 byte index (both bits set to 0).

The SID/Label sub-TLV has no flags field. The length of the sub-TLV indicates 
whether the advertised value has is a label (length = 3)  or an index (length = 
4).

[Bruno] Agreed so far.
Do we agree that 

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Les Ginsberg (ginsberg)]

Bruno -

Please see inline.

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Tuesday, August 04, 2020 5:45 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi,

I may be missing something but the SR Binding SID TLV extension  is not clear 
to me.


  1.  It does not seem compliant with RFC 8667

Draft says that the advertisement has: T-flag set, M & A flags cleared, 
SID/Label sub-TLV present, Prefix-SID sub-TLV NOT present


The following extensions to the Binding TLV are defined in order to

   support Area SID:



  A new flag is defined:



 T-flag: The SID directs traffic to an area.  (Bit 5)



 When T-flag is set:



M and A flag MUST be clear



Range and Prefix are ignored



  Section 2.4.4 of RFC 
8667 is altered to say:



 "The Prefix-SID sub-TLV MUST be present in the SID/Label

 Binding TLV when the M-Flag and T-flag are both clear.  The

 Prefix-SID sub-TLV MUST NOT be present when either the M-Flag

 or T-flag are set."



  Regarding the SID/Label sub-TLV Section 2.4.5 of RFC 
8667 is

  altered to say:



 "It MUST be present in the SID/Label Binding TLV when either

 the M-Flag or T-flag is set in the Flags field of the parent

 TLV."

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#page-14



By definition, legacy L2 external  node will support vanilla RFC 8667, which 
says:
"The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the 
M-Flag is clear."
https://www.rfc-editor.org/rfc/rfc8667.html#name-sid-label-binding-tlv

So it seems that the extension violates the above MUST in RFC8667, as regarding 
the Prefix-SID sub-TLV

  *   Area proxy says "MUST NOT be present" (as T-flag is set)
  *   RFC 8667 says "MUST be present" (as M-flag is cleared)


In addition to the above, legacy node _will_ interpret the 'Range' and 'Prefix' 
fields. So there is probably a need to specify which values need to be 
advertised for those legacy nodes. A priori range would be one as a single SID 
is advertised. Prefix seems more problematic as you need to find an IP prefix 
to advertise. And please let's avoid SID conflict and Prefix conflict...
[Les:] Format of the Binding TLV when the new T-bit is set is similar to the 
format when the M-bit is set in that Prefix-SID sub-TLV is NOT present.
A legacy node parsing the Binding TLV would be looking for the Prefix-SID 
sub-TLV (M-bit NOT set) and would not find it. The contents of the Binding TLV 
would therefore be unusable to a legacy node.
The correct behaviour for a legacy node would be to (optionally) report an 
"invalid TLV" and to ignore the TLV.



  1.  It's not clear to me whether the segment/SID is global or local.
As per my understanding of the draft-ietf-lsr-isis-area-proxy use case, the 
area-proxy SID would be global (in the external L2): "Area SID which will 
direct traffic to any of the Inside Edge Routers."

But the SID/Label Sub-TLV used by area-proxy has no flag (L-flag) indicating 
whether the SID is global or local. One could argue that if it carries a label 
it's a local SID and if it carries and index it's a global SID. But this has 
not been specified.
It has also no "algorithm" indicating how it needs to be routed global, so at 
minimum would not work with different routing algo/flex algo.
I'm not seeing in RFC 8402 or 8667 any text saying that such SID would be 
global hence globally routed in the L2 domain. (To me, this IS-IS SID was 
local, but arguably also can't find text stating this).

[Les:] There is a subtle difference between the Prefix-SID sub-TLV as defined 
in https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1 and the SID/Label 
sub-TLV defined in https://www.rfc-editor.org/rfc/rfc8667.html#SIDLABELSUBTLV

The Prefix-SID sub-TLV has a flags field which includes V-bit/L-bit to indicate 
whether the variable length field which follows is a 3 byte label (both bits 
set to 1) or a 4 byte index (both bits set to 0).

The SID/Label sub-TLV has no flags field. The length of the sub-TLV indicates 
whether the advertised value has is a label (length = 3)  or an index (length = 
4).

I see no issue here.

I would also point out that the new Area Proxy SID sub-TLV ( 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.3.2 ) 
does include V/L bits - similar to the Prefix-SID sub-TLV.


At minimum, area-proxy would need to specify whether the SID is global and 
local. And if global, with which hard coded algorithm it is routed. (I would 
assume "0")

[Les:]Just as the Mirror SID has no algorithm associated, neither does the Area 
SID.
If you feel that is an issue, please expand on how you intend to use an 
algorithm specific Area SID.
Thus far you seem more inclined to use an anycast  Prefix-SID, so I am not 
clear on what you think is 

Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[Les Ginsberg (ginsberg)]

Bruno -

Regarding the A-flag...
It may not matter much whichever way we decide - but the A-flag was invented 
because at the time (prior to RFC 7794) there was no way to determine from 
looking at a prefix reachability advertisement whether it was originated by the 
advertising node or had been leaked from another area.
If RFC 7794 had existed when the SR-MPLS draft was first being developed there 
would have been no need for the A-flag.

As regards Area-SID, there is no prefix to be leaked - so I do not see that the 
A-flag serves any useful purpose.
If you want it to be set just to be consistent with its use in PSP logic - OK - 
but I think this is unnecessary.

   Les


From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Thursday, July 30, 2020 9:46 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi authors,

Please find below some feedback for information. Feel free to ignore.

4.4.13.  The Area SID  
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.13

   "The following extensions to the Binding TLV are defined in order to
   support Area SID:

  A new flag is defined:

 T-flag: The SID directs traffic to an area.  (Bit 5)

 When T-flag is set:

M and A flag MUST be clear"

My understanding is that the Area SID is installed in the FIB of all inside 
edge routers. Based on this, I would argue that the  A flag could and SHOULD be 
set

https://www.rfc-editor.org/rfc/rfc8667.html#name-flags-2
"A-Flag: Attached Flag. The originator of the SID/Label Binding TLV MAY set the 
A bit in order to signal that the prefixes and SIDs advertised in the SID/Label 
Binding TLV are directly connected to their originators."
---
4.4.7.  Reachability TLVs   
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.4.7


   If the Inside Area supports Segment Routing and the selected TLV

   includes a Prefix Segment Identifier sub-TLV (3) 
[RFC8667], then the

   sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the

   copy of the sub-TLV to indicate that penultimate hop popping SHOULD

   NOT be performed for this prefix.  The E-Flag SHOULD be reset in the

   copy of the sub-TLV to indicate that an explicit NULL is not

   required. The R-Flag SHOULD simply be copied.




May be it would be more generic to say that those prefix are handled as 
redistributed prefix.
https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1.2 and 
https://www.rfc-editor.org/rfc/rfc8667.html#EANDPFLAGS already defines the 
behaviour for respectively Prefix-SID propagation and P and E flags handling, 
so probably no need to re-specify:
When propagating (from either Level-1 to Level-2 or Level-2 to Level-1) a 
reachability advertisement originated by another IS-IS speaker, the router MUST 
set the P-Flag and MUST clear the E-Flag of the related Prefix-SIDs.
That would also cover for the handling of Prefix Attribute Flags sub-TLV 
RFC7794.

I would argue that the R-Flag MUST be set (rather than simply copied). As per 
https://www.rfc-editor.org/rfc/rfc8667.html#name-r-flag-and-n-flag

Best regards,
--Bruno



_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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