Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Robert Raszuk
Les,

>  You need to allow that not everything in the world is identified by an
IP/IPv6 address.

Thought we are talking about WAN networks here and not about the world :)

>  assign a common anycast address on all nodes.

First not all nodes need to participate here. At most ABRs.

Then if you already have a summary route from a given area - you do not
need to invent anything else - area summary routes are effectively area
prefixes. And in fact last time I checked routable too.

>  I can associate the SID with an identifier

Do you ping SID or IP address ?

Maybe time for examples.

What would be your MPLS area SID format ? How about SRv6 SID format for the
same ?

Bottom line I think we must not lock ourselves into single transport
technology - that's all I am after here.

Thx,
Robert.


On Mon, Aug 3, 2020 at 7:56 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> You need to allow that not everything in the world is identified by an
> IP/IPv6 address.
>
>
>
> If you want an IP address shared by all nodes in an area there is already
> a mean of doing that: assign a common anycast address on all nodes.
>
>
>
> The value add (if there is any) of an Area SID is that I don’t have to
> assign an anycast address to all nodes. I can associate the SID with an
> identifier that is already shared and known by all nodes in the area.
>
> If you don’t see that as worthwhile, fine, let’s abandon the Area SID idea.
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, August 03, 2020 10:47 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-ietf-lsr-isis-area-proxy-02.txt
>
>
>
> Hi Les,
>
>
>
> Well I am talking about IP routable identifier which I can place on the
> front of the packet and which can assure that the packet will arrive at
> given area.
>
>
>
> Then Area SID becomes analogy of Node SID :)
>
>
>
> Thx
>
>
>
> On Mon, Aug 3, 2020 at 7:40 PM Les Ginsberg (ginsberg) 
> wrote:
>
> Robert –
>
>
>
> Both OSPF and IS-IS have area identifiers which are advertised.
>
> Why would we need to invent another identifier for an area?
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, August 03, 2020 10:31 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-ietf-lsr-isis-area-proxy-02.txt
>
>
>
> *Les,*
>
>
>
> *> But currently the draft is defining a SID which is NOT associated with
> a prefix.*
>
> +
>
> > *But if the proposal is to use a SID associated with a prefix then I
> see no need to invent a new SID advertisement.*
>
>
>
> How about we first define an "Area Prefix" (IP address being a property of
> an area) then assign SID to it ?
>
>
>
> - - -
>
>
>
> How odd it may sound I would like to still be able to direct traffic (read
> ip tunnel) traffic to an area without any SID.
>
>
>
> Thx,
> R.
>
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Les Ginsberg (ginsberg)
Robert –

You need to allow that not everything in the world is identified by an IP/IPv6 
address.

If you want an IP address shared by all nodes in an area there is already a 
mean of doing that: assign a common anycast address on all nodes.

The value add (if there is any) of an Area SID is that I don’t have to assign 
an anycast address to all nodes. I can associate the SID with an identifier 
that is already shared and known by all nodes in the area.
If you don’t see that as worthwhile, fine, let’s abandon the Area SID idea.

   Les



From: Robert Raszuk 
Sent: Monday, August 03, 2020 10:47 AM
To: Les Ginsberg (ginsberg) 
Cc: bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Hi Les,

Well I am talking about IP routable identifier which I can place on the front 
of the packet and which can assure that the packet will arrive at given area.

Then Area SID becomes analogy of Node SID :)

Thx

On Mon, Aug 3, 2020 at 7:40 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert –

Both OSPF and IS-IS have area identifiers which are advertised.
Why would we need to invent another identifier for an area?

   Les


From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Monday, August 03, 2020 10:31 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 
tony...@tony.li<mailto:tony...@tony.li>; lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Les,

> But currently the draft is defining a SID which is NOT associated with a 
> prefix.
+
> But if the proposal is to use a SID associated with a prefix then I see no 
> need to invent a new SID advertisement.

How about we first define an "Area Prefix" (IP address being a property of an 
area) then assign SID to it ?

- - -

How odd it may sound I would like to still be able to direct traffic (read ip 
tunnel) traffic to an area without any SID.

Thx,
R.

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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Robert Raszuk
Hi Les,

Well I am talking about IP routable identifier which I can place on the
front of the packet and which can assure that the packet will arrive at
given area.

Then Area SID becomes analogy of Node SID :)

Thx

On Mon, Aug 3, 2020 at 7:40 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> Both OSPF and IS-IS have area identifiers which are advertised.
>
> Why would we need to invent another identifier for an area?
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Monday, August 03, 2020 10:31 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-ietf-lsr-isis-area-proxy-02.txt
>
>
>
> *Les,*
>
>
>
> *> But currently the draft is defining a SID which is NOT associated with
> a prefix.*
>
> +
>
> > *But if the proposal is to use a SID associated with a prefix then I
> see no need to invent a new SID advertisement.*
>
>
>
> How about we first define an "Area Prefix" (IP address being a property of
> an area) then assign SID to it ?
>
>
>
> - - -
>
>
>
> How odd it may sound I would like to still be able to direct traffic (read
> ip tunnel) traffic to an area without any SID.
>
>
>
> Thx,
> R.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Robert Raszuk
Hi Tony,

If I am not mistaken that additional overhead would only need to happen on
participating in this game ABRs. If so I think this is worthwhile.

> Well, that becomes an anycast tunnel endpoint

Endpoint ? Not midpoint ? Or better sort of ski lift transit point with
embedded direction in the original dst ?

Thx
R.



On Mon, Aug 3, 2020 at 7:37 PM  wrote:

>
> Hi Robert,
>
> How about we first define an "Area Prefix" (IP address being a property of
> an area) then assign SID to it ?
>
>
>
> That’s effectively what Bruno is proposing.  It adds some additional
> configuration and management overhead.  Do you think it’s worthwhile?
>
>
>
> How odd it may sound I would like to still be able to direct traffic (read
> ip tunnel) traffic to an area without any SID.
>
>
>
>
> Well, that becomes an anycast tunnel endpoint, which is actually not one
> of the goals for Area Proxy.
>
> Tony
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Les Ginsberg (ginsberg)
Robert –

Both OSPF and IS-IS have area identifiers which are advertised.
Why would we need to invent another identifier for an area?

   Les


From: Robert Raszuk 
Sent: Monday, August 03, 2020 10:31 AM
To: Les Ginsberg (ginsberg) 
Cc: bruno.decra...@orange.com; tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Les,

> But currently the draft is defining a SID which is NOT associated with a 
> prefix.
+
> But if the proposal is to use a SID associated with a prefix then I see no 
> need to invent a new SID advertisement.

How about we first define an "Area Prefix" (IP address being a property of an 
area) then assign SID to it ?

- - -

How odd it may sound I would like to still be able to direct traffic (read ip 
tunnel) traffic to an area without any SID.

Thx,
R.

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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread tony . li

Hi Robert,

> How about we first define an "Area Prefix" (IP address being a property of an 
> area) then assign SID to it ? 


That’s effectively what Bruno is proposing.  It adds some additional 
configuration and management overhead.  Do you think it’s worthwhile?



> How odd it may sound I would like to still be able to direct traffic (read ip 
> tunnel) traffic to an area without any SID. 



Well, that becomes an anycast tunnel endpoint, which is actually not one of the 
goals for Area Proxy.

Tony


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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread tony . li

Hi Acee,

> [Acee] I know you guys have all thought about this a lot more than myself. 
> However, I’d envisioned this new Area SID as taking one to the closest entry 
> to the abstracted area. The next SID in the stack would either take you to a 
> destination inside the area or would use the abstracted area as transit to 
> another SID.

I believe that is the core of the semantics that we are all agreed upon.  The 
question is how to get there.

Tony


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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Robert Raszuk
*Les,*

*> But currently the draft is defining a SID which is NOT associated with a
prefix.*
+
> *But if the proposal is to use a SID associated with a prefix then I see
no need to invent a new SID advertisement.*

How about we first define an "Area Prefix" (IP address being a property of
an area) then assign SID to it ?

- - -

How odd it may sound I would like to still be able to direct traffic (read
ip tunnel) traffic to an area without any SID.

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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Acee Lindem (acee)

From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 

Date: Monday, August 3, 2020 at 12:32 PM
To: Bruno Decraene , Tony Li 
Cc: "lsr@ietf.org" 
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

Inline.

From: bruno.decra...@orange.com 
Sent: Monday, August 03, 2020 8:52 AM
To: Les Ginsberg (ginsberg) ; tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Les,


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 3, 2020 5:22 PM
To: DECRAENE Bruno TGI/OLN 
mailto:bruno.decra...@orange.com>>; 
tony...@tony.li<mailto:tony...@tony.li>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

The concept of “Area SID” – at least to me – is “please forward to any node in 
the Area advertising the Area SID”.
[Bruno] How is that different from “anycast”? i.e. your option b?

[Les:] It would differ because it would not be associated with a prefix but 
with an area. Any node in the area could make use of the SID.

You, however, seem to be asking for either:

a)The node originating the Proxy LSP to advertise a Node SID for a loopback 
address on that node

OR

b)The node originating the Proxy LSP to advertise an anycast SID which is 
shared by the IERs in the Proxy Area

To do so, it seems to me we need not invent a new type of SID, we can simply 
advertise using the existing Prefix Reachability/Prefix SID sub-TLVs.

So it seems you are not interested in an “Area SID”.

Can you please clarify?

[Bruno] I’m interested in the forwarding behavior defined in the draft: “all of 
the Inside Edge Nodes […] should consume this SID at forwarding time.” How we 
call this, I don’t really care. Could be area SID, or proxy SID or anycast SID… 
but for the external L2 nodes, there is no anycast behavior: just one single 
node/LSP/SID, so calling it anycast could be strange.

[Les:] Agreed – which is why a new type of SID was chosen.

[Acee] I know you guys have all thought about this a lot more than myself. 
However, I’d envisioned this new Area SID as taking one to the closest entry to 
the abstracted area. The next SID in the stack would either take you to a 
destination inside the area or would use the abstracted area as transit to 
another SID.

Thanks,
Acee


For me, the reason to invent a new type of SID and new forms of SID 
advertisements is because we were defining a SID with new functionality i.e., 
send this to another area – which entry point into the area is used should not 
matter.
[Bruno] From the external L2 nodes, the “area” is seen as a single node. “which 
entry point into the area is used ” equals “which interface of the (proxy) node 
is used. I’m not sure that we need a new concept.
From within area internal nodes, we do see the detail of the topology and need 
to advertise & agree on the area SID.
[Les:] You are correct in terms of usage within Area Proxy.
But I was allowing that other use cases for Area SID might be defined in the 
future and the abstraction that is present in Area Proxy would not be relevant.
But if the proposal is to use a SID associated with a prefix then I see no need 
to invent a new SID advertisement.

This seems like a property which might be useful – and might be useful outside 
of Area Proxy use cases as well. If however, we (the WG) see no need for this 
type of SID then we should remove these definitions and simply use the existing 
Prefix-SID advertisements.
[Bruno] The property is useful. I’m fine with the name & encoding in current 
and past draft.
I’m simply raising the point that this new advertisement will not be understood 
by vanilla external L2 nodes. Hence unless you upgrade all those external 
nodes, you have regression in the network, at least in the following use case: 
replacing a big chassis with a set of smaller nodes grouped in one area.

[Les:] A fair point. But currently the draft is defining a SID which is NOT 
associated with a prefix. And you are correctly pointing out that this has an 
impact on both the IER nodes (which MUST support the Area Proxy extensions) and 
the external L2 nodes – which theoretically need not be upgraded at all.
If the impact on external nodes is unacceptable, then a prefix-SID 
advertisement MUST be used. Any new advertisement – whether associated with a 
prefix or not – would raise the same interoperability issue you mention.


One other comment regarding your reference to 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03 .

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-2.1 
already specifies that all inside nodes MUST have the “same SRGB”. So I do not 
see that your reference is relevant – unless you are proposing to change that.
[Bruno] You can safely forget about this reference.
I was trying to say that anycast SID is

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Les Ginsberg (ginsberg)
Bruno –

Inline.

From: bruno.decra...@orange.com 
Sent: Monday, August 03, 2020 8:52 AM
To: Les Ginsberg (ginsberg) ; tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Les,


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 3, 2020 5:22 PM
To: DECRAENE Bruno TGI/OLN 
mailto:bruno.decra...@orange.com>>; 
tony...@tony.li<mailto:tony...@tony.li>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

The concept of “Area SID” – at least to me – is “please forward to any node in 
the Area advertising the Area SID”.
[Bruno] How is that different from “anycast”? i.e. your option b?

[Les:] It would differ because it would not be associated with a prefix but 
with an area. Any node in the area could make use of the SID.

You, however, seem to be asking for either:

a)The node originating the Proxy LSP to advertise a Node SID for a loopback 
address on that node

OR

b)The node originating the Proxy LSP to advertise an anycast SID which is 
shared by the IERs in the Proxy Area

To do so, it seems to me we need not invent a new type of SID, we can simply 
advertise using the existing Prefix Reachability/Prefix SID sub-TLVs.

So it seems you are not interested in an “Area SID”.

Can you please clarify?

[Bruno] I’m interested in the forwarding behavior defined in the draft: “all of 
the Inside Edge Nodes […] should consume this SID at forwarding time.” How we 
call this, I don’t really care. Could be area SID, or proxy SID or anycast SID… 
but for the external L2 nodes, there is no anycast behavior: just one single 
node/LSP/SID, so calling it anycast could be strange.

[Les:] Agreed – which is why a new type of SID was chosen.

For me, the reason to invent a new type of SID and new forms of SID 
advertisements is because we were defining a SID with new functionality i.e., 
send this to another area – which entry point into the area is used should not 
matter.
[Bruno] From the external L2 nodes, the “area” is seen as a single node. “which 
entry point into the area is used ” equals “which interface of the (proxy) node 
is used. I’m not sure that we need a new concept.
From within area internal nodes, we do see the detail of the topology and need 
to advertise & agree on the area SID.
[Les:] You are correct in terms of usage within Area Proxy.
But I was allowing that other use cases for Area SID might be defined in the 
future and the abstraction that is present in Area Proxy would not be relevant.
But if the proposal is to use a SID associated with a prefix then I see no need 
to invent a new SID advertisement.

This seems like a property which might be useful – and might be useful outside 
of Area Proxy use cases as well. If however, we (the WG) see no need for this 
type of SID then we should remove these definitions and simply use the existing 
Prefix-SID advertisements.
[Bruno] The property is useful. I’m fine with the name & encoding in current 
and past draft.
I’m simply raising the point that this new advertisement will not be understood 
by vanilla external L2 nodes. Hence unless you upgrade all those external 
nodes, you have regression in the network, at least in the following use case: 
replacing a big chassis with a set of smaller nodes grouped in one area.

[Les:] A fair point. But currently the draft is defining a SID which is NOT 
associated with a prefix. And you are correctly pointing out that this has an 
impact on both the IER nodes (which MUST support the Area Proxy extensions) and 
the external L2 nodes – which theoretically need not be upgraded at all.
If the impact on external nodes is unacceptable, then a prefix-SID 
advertisement MUST be used. Any new advertisement – whether associated with a 
prefix or not – would raise the same interoperability issue you mention.


One other comment regarding your reference to 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03 .

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-2.1 
already specifies that all inside nodes MUST have the “same SRGB”. So I do not 
see that your reference is relevant – unless you are proposing to change that.
[Bruno] You can safely forget about this reference.
I was trying to say that anycast SID is not new. And no, I’m not proposing to 
change that all node must use the same SRGB. (that been said, sometimes you 
need to use the implementation that are on the market. The concept of index + 
SRGB has only been designed because some nodes could not support a common SRGB.)
[Les:] Understood. But there is a reason why the anycast draft has not been 
progressing. 

  Les

--Bruno

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Monday, August 03, 2020 1:10 AM
To: tony...@tony.li<mailto:ton

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread bruno.decraene
Les,


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 3, 2020 5:22 PM
To: DECRAENE Bruno TGI/OLN ; tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

The concept of “Area SID” – at least to me – is “please forward to any node in 
the Area advertising the Area SID”.
[Bruno] How is that different from “anycast”? i.e. your option b?

You, however, seem to be asking for either:

a)The node originating the Proxy LSP to advertise a Node SID for a loopback 
address on that node

OR

b)The node originating the Proxy LSP to advertise an anycast SID which is 
shared by the IERs in the Proxy Area

To do so, it seems to me we need not invent a new type of SID, we can simply 
advertise using the existing Prefix Reachability/Prefix SID sub-TLVs.

So it seems you are not interested in an “Area SID”.

Can you please clarify?

[Bruno] I’m interested in the forwarding behavior defined in the draft: “all of 
the Inside Edge Nodes […] should consume this SID at forwarding time.” How we 
call this, I don’t really care. Could be area SID, or proxy SID or anycast SID… 
but for the external L2 nodes, there is no anycast behavior: just one single 
node/LSP/SID, so calling it anycast could be strange.


For me, the reason to invent a new type of SID and new forms of SID 
advertisements is because we were defining a SID with new functionality i.e., 
send this to another area – which entry point into the area is used should not 
matter.
[Bruno] From the external L2 nodes, the “area” is seen as a single node. “which 
entry point into the area is used ” equals “which interface of the (proxy) node 
is used. I’m not sure that we need a new concept.
From within area internal nodes, we do see the detail of the topology and need 
to advertise & agree on the area SID.
This seems like a property which might be useful – and might be useful outside 
of Area Proxy use cases as well. If however, we (the WG) see no need for this 
type of SID then we should remove these definitions and simply use the existing 
Prefix-SID advertisements.
[Bruno] The property is useful. I’m fine with the name & encoding in current 
and past draft.
I’m simply raising the point that this new advertisement will not be understood 
by vanilla external L2 nodes. Hence unless you upgrade all those external 
nodes, you have regression in the network, at least in the following use case: 
replacing a big chassis with a set of smaller nodes grouped in one area.

One other comment regarding your reference to 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03 .

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-2.1 
already specifies that all inside nodes MUST have the “same SRGB”. So I do not 
see that your reference is relevant – unless you are proposing to change that.
[Bruno] You can safely forget about this reference.
I was trying to say that anycast SID is not new. And no, I’m not proposing to 
change that all node must use the same SRGB. (that been said, sometimes you 
need to use the implementation that are on the market. The concept of index + 
SRGB has only been designed because some nodes could not support a common SRGB.)
--Bruno

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Monday, August 03, 2020 1:10 AM
To: tony...@tony.li<mailto:tony...@tony.li>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Hi Tony,

From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of 
tony...@tony.li<mailto:tony...@tony.li>
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for the clarification.
[Bruno] You are very welcome. Thank you for listening.

 I understand completely what you’re trying to do and I agree that it’s 
valuable.

The downside of your approach is that the Area Leader will now need 
configuration of a new prefix to advertise as the Node SID.
[Bruno] Agreed.
I believe that the Area SID equally needs to be configured, so configuration is 
required in all cases. Given this, the extra effort seems marginal to me.
Not unthinkable.

What do the Inside Nodes do with this prefix, if anything?
[Bruno] good question. 2 options:
-  Drop traffic to control plane (i.e. IP is not supposed to be used)
-  Nothing really new: it’s an anycast IP/SID. There is even a draft 
for the more complex case where the SRGB is different on the anycast nodes . 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03

Regards,
--Bruno

I am open to this approach, either in addition to, or instead of the approach 
currently in the draft.  I await feedback from the WG.

Regards,
Tony



p.s. The fact that the node SID requires a prefix is just a side effect of the 

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Les Ginsberg (ginsberg)
Bruno –

The concept of “Area SID” – at least to me – is “please forward to any node in 
the Area advertising the Area SID”.

You, however, seem to be asking for either:

a)The node originating the Proxy LSP to advertise a Node SID for a loopback 
address on that node

OR

b)The node originating the Proxy LSP to advertise an anycast SID which is 
shared by the IERs in the Proxy Area

To do so, it seems to me we need not invent a new type of SID, we can simply 
advertise using the existing Prefix Reachability/Prefix SID sub-TLVs.

So it seems you are not interested in an “Area SID”.

Can you please clarify?

For me, the reason to invent a new type of SID and new forms of SID 
advertisements is because we were defining a SID with new functionality i.e., 
send this to another area – which entry point into the area is used should not 
matter. This seems like a property which might be useful – and might be useful 
outside of Area Proxy use cases as well. If however, we (the WG) see no need 
for this type of SID then we should remove these definitions and simply use the 
existing Prefix-SID advertisements.

One other comment regarding your reference to 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03 .

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-2.1 
already specifies that all inside nodes MUST have the “same SRGB”. So I do not 
see that your reference is relevant – unless you are proposing to change that.

   Les

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Monday, August 03, 2020 1:10 AM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Hi Tony,

From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of 
tony...@tony.li<mailto:tony...@tony.li>
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for the clarification.
[Bruno] You are very welcome. Thank you for listening.

 I understand completely what you’re trying to do and I agree that it’s 
valuable.

The downside of your approach is that the Area Leader will now need 
configuration of a new prefix to advertise as the Node SID.
[Bruno] Agreed.
I believe that the Area SID equally needs to be configured, so configuration is 
required in all cases. Given this, the extra effort seems marginal to me.
Not unthinkable.

What do the Inside Nodes do with this prefix, if anything?
[Bruno] good question. 2 options:

  *   Drop traffic to control plane (i.e. IP is not supposed to be used)
  *   Nothing really new: it’s an anycast IP/SID. There is even a draft for the 
more complex case where the SRGB is different on the anycast nodes . 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03

Regards,
--Bruno

I am open to this approach, either in addition to, or instead of the approach 
currently in the draft.  I await feedback from the WG.

Regards,
Tony



p.s. The fact that the node SID requires a prefix is just a side effect of the 
IP address space excluding hosts from addressing. The one, true
way within IS-IS is the system ID, a separate, independent namespace for nodes 
that simply avoids ALL of these problems.  If RFC 8667
encoded node SIDs as their own TLV without the unnecessary prefix that OSPF’s 
style mandates, this would be trivial.




On Jul 31, 2020, at 2:24 AM, 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:

Hi Tony,

Thank you for your reply.
Top posting the description of the use case that I have in mind.

>  First off, the Area SID is 100% optional. If you choose not to use it, then 
> the Proxy LSP should be 100% compatible with a standard L2 node.
Good. But I think that the idea of the Area SID is a good one, and I choose to 
use it. Then I’d like to get it for free ;-)


Please fine below a network topology:



My understanding is that the L2 topology seen by node S is the following


P been the Proxy LSP.

S wants to protect from the failure of link S-C by using TI-LFA. For the 
destination C, it would push 2 (*) node SIDs: P, C
So S needs a Node SID for P:
a)  If P does not redistribute the Node SIDs from its area members, P does 
not seem to advertise any node SID currently. There is a chance that C’s TI-LFA 
implementation would not like it and hence would not install protection for 
this (link, destination)
b)  If P redistributes the Node SIDs from its area members, P advertises 3 
node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the 
forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.

Two solutions I could think of:
- when redistributing the node SID, P changes the SIDs values and replace them 
with the value of the Area SID. This works for this use case, but it is 
borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, we 
have some SID conflict. Let’s try to avoid this subject).
- P could advertise its own Node-SID with 

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread bruno.decraene
Hi Tony,

From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for the clarification.
[Bruno] You are very welcome. Thank you for listening.

 I understand completely what you’re trying to do and I agree that it’s 
valuable.

The downside of your approach is that the Area Leader will now need 
configuration of a new prefix to advertise as the Node SID.
[Bruno] Agreed.
I believe that the Area SID equally needs to be configured, so configuration is 
required in all cases. Given this, the extra effort seems marginal to me.
Not unthinkable.

What do the Inside Nodes do with this prefix, if anything?
[Bruno] good question. 2 options:

-  Drop traffic to control plane (i.e. IP is not supposed to be used)

-  Nothing really new: it’s an anycast IP/SID. There is even a draft 
for the more complex case where the SRGB is different on the anycast nodes . 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03

Regards,
--Bruno

I am open to this approach, either in addition to, or instead of the approach 
currently in the draft.  I await feedback from the WG.

Regards,
Tony



p.s. The fact that the node SID requires a prefix is just a side effect of the 
IP address space excluding hosts from addressing. The one, true
way within IS-IS is the system ID, a separate, independent namespace for nodes 
that simply avoids ALL of these problems.  If RFC 8667
encoded node SIDs as their own TLV without the unnecessary prefix that OSPF’s 
style mandates, this would be trivial.




On Jul 31, 2020, at 2:24 AM, 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:

Hi Tony,

Thank you for your reply.
Top posting the description of the use case that I have in mind.

>  First off, the Area SID is 100% optional. If you choose not to use it, then 
> the Proxy LSP should be 100% compatible with a standard L2 node.
Good. But I think that the idea of the Area SID is a good one, and I choose to 
use it. Then I’d like to get it for free ;-)


Please fine below a network topology:



My understanding is that the L2 topology seen by node S is the following


P been the Proxy LSP.

S wants to protect from the failure of link S-C by using TI-LFA. For the 
destination C, it would push 2 (*) node SIDs: P, C
So S needs a Node SID for P:
a)  If P does not redistribute the Node SIDs from its area members, P does 
not seem to advertise any node SID currently. There is a chance that C’s TI-LFA 
implementation would not like it and hence would not install protection for 
this (link, destination)
b)  If P redistributes the Node SIDs from its area members, P advertises 3 
node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the 
forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.

Two solutions I could think of:
- when redistributing the node SID, P changes the SIDs values and replace them 
with the value of the Area SID. This works for this use case, but it is 
borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, we 
have some SID conflict. Let’s try to avoid this subject).
- P could advertise its own Node-SID with the Area SID value. This is what I’m 
proposing. Both the IP loopback and the Area SID of this Node SID  are likely 
configured by the network operator so this does not seem like a significant 
effort from the implementation.

As you say, this does not involve any protocol extension. But the goal is to 
improve interop with existing/legacy L2 nodes so this may be valuable in the 
draft. This point could be pushed to a deployment consideration section if you 
don’t want any impact on the protocol extension.

Thanks,
--Bruno

(*) Assuming the right metrics on the links. This is not the subject of this 
thread.


From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of 
tony...@tony.li<mailto:tony...@tony.li>
Sent: Thursday, July 30, 2020 7:39 PM
To: DECRAENE Bruno TGI/OLN 
mailto:bruno.decra...@orange.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for your comments.




On Jul 30, 2020, at 9:22 AM, 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.

>  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 866

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-31 Thread tony . li

Hi Bruno,

Thank you for the clarification.  I understand completely what you’re trying to 
do and I agree that it’s valuable.

The downside of your approach is that the Area Leader will now need 
configuration of a new prefix to advertise as the Node SID. Not unthinkable.
What do the Inside Nodes do with this prefix, if anything?  

I am open to this approach, either in addition to, or instead of the approach 
currently in the draft.  I await feedback from the WG.

Regards,
Tony



p.s. The fact that the node SID requires a prefix is just a side effect of the 
IP address space excluding hosts from addressing. The one, true
way within IS-IS is the system ID, a separate, independent namespace for nodes 
that simply avoids ALL of these problems.  If RFC 8667 
encoded node SIDs as their own TLV without the unnecessary prefix that OSPF’s 
style mandates, this would be trivial.



> On Jul 31, 2020, at 2:24 AM, bruno.decra...@orange.com wrote:
> 
> Hi Tony,
>  
> Thank you for your reply.
> Top posting the description of the use case that I have in mind.
>  
> Ø  First off, the Area SID is 100% optional. If you choose not to use it, 
> then the Proxy LSP should be 100% compatible with a standard L2 node.
> Good. But I think that the idea of the Area SID is a good one, and I choose 
> to use it. Then I’d like to get it for free ;-)
>  
>  
> Please fine below a network topology:
> 
>  
>  
> My understanding is that the L2 topology seen by node S is the following
> 
>  
> P been the Proxy LSP.
>  
> S wants to protect from the failure of link S-C by using TI-LFA. For the 
> destination C, it would push 2 (*) node SIDs: P, C 
> So S needs a Node SID for P:
> a)  If P does not redistribute the Node SIDs from its area members, P 
> does not seem to advertise any node SID currently. There is a chance that C’s 
> TI-LFA implementation would not like it and hence would not install 
> protection for this (link, destination)
> b)  If P redistributes the Node SIDs from its area members, P advertises 
> 3 node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the 
> forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.
>  
> Two solutions I could think of:
> - when redistributing the node SID, P changes the SIDs values and replace 
> them with the value of the Area SID. This works for this use case, but it is 
> borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, 
> we have some SID conflict. Let’s try to avoid this subject).
> - P could advertise its own Node-SID with the Area SID value. This is what 
> I’m proposing. Both the IP loopback and the Area SID of this Node SID  are 
> likely configured by the network operator so this does not seem like a 
> significant effort from the implementation.
>  
> As you say, this does not involve any protocol extension. But the goal is to 
> improve interop with existing/legacy L2 nodes so this may be valuable in the 
> draft. This point could be pushed to a deployment consideration section if 
> you don’t want any impact on the protocol extension.
>  
> Thanks,
> --Bruno
>  
> (*) Assuming the right metrics on the links. This is not the subject of this 
> thread.
>  
>  
> From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
> Sent: Thursday, July 30, 2020 7:39 PM
> To: DECRAENE Bruno TGI/OLN 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for 
> draft-ietf-lsr-isis-area-proxy-02.txt
>  
>  
> Hi Bruno,
>  
> Thank you for your comments.
>  
> 
> 
> On Jul 30, 2020, at 9:22 AM, bruno.decra...@orange.com 
> <mailto:bruno.decra...@orange.com> wrote:
>  
> Hi Tony,
>  
> Thanks for the updated draft.
>  
> “ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
>represents the entirety of the Inside Area to the Outside Area.  This
>sub-TLV is learned by all of the Inside Edge Nodes who should consume
>this SID at forwarding time.”
>  
> Excellent, from my perspective.
>  
> Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.
>  
> “When SR is enabled, it may be useful to advertise an Area SID which
>will direct traffic to any of the Inside Edge Routers.  The Binding/
>MT Binding TLVs described in RFC 8667 Section 2.4 
> <https://tools.ietf.org/html/rfc8667#section-2.4> are used to
>advertise such a SID.
>  
>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) »
>  
>  
> This works.
>  
>  
> Excellent.
>  
> 
> 
> However I may have a 

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-31 Thread bruno.decraene
Hi Tony,

Thank you for your reply.
Top posting the description of the use case that I have in mind.


Ø  First off, the Area SID is 100% optional. If you choose not to use it, then 
the Proxy LSP should be 100% compatible with a standard L2 node.
Good. But I think that the idea of the Area SID is a good one, and I choose to 
use it. Then I’d like to get it for free ;-)


Please fine below a network topology:
[cid:image003.jpg@01D6672D.1946D4F0]


My understanding is that the L2 topology seen by node S is the following
[cid:image004.jpg@01D6672D.1946D4F0]

P been the Proxy LSP.

S wants to protect from the failure of link S-C by using TI-LFA. For the 
destination C, it would push 2 (*) node SIDs: P, C
So S needs a Node SID for P:

a)  If P does not redistribute the Node SIDs from its area members, P does 
not seem to advertise any node SID currently. There is a chance that C’s TI-LFA 
implementation would not like it and hence would not install protection for 
this (link, destination)

b)  If P redistributes the Node SIDs from its area members, P advertises 3 
node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the 
forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.


Two solutions I could think of:
- when redistributing the node SID, P changes the SIDs values and replace them 
with the value of the Area SID. This works for this use case, but it is 
borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, we 
have some SID conflict. Let’s try to avoid this subject).
- P could advertise its own Node-SID with the Area SID value. This is what I’m 
proposing. Both the IP loopback and the Area SID of this Node SID  are likely 
configured by the network operator so this does not seem like a significant 
effort from the implementation.

As you say, this does not involve any protocol extension. But the goal is to 
improve interop with existing/legacy L2 nodes so this may be valuable in the 
draft. This point could be pushed to a deployment consideration section if you 
don’t want any impact on the protocol extension.

Thanks,
--Bruno

(*) Assuming the right metrics on the links. This is not the subject of this 
thread.


From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Thursday, July 30, 2020 7:39 PM
To: DECRAENE Bruno TGI/OLN 
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for your comments.



On Jul 30, 2020, at 9:22 AM, 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.

>  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 
2.4<https://tools.ietf.org/html/rfc8667#section-2.4> are used to

   advertise such a SID.



   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) »




This works.


Excellent.



However I may have a different deployment environment than the one you have in 
mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different 
vendors, platforms, software, generations. Requiring all those routers to 
support the new Binding SID TLV T-Flag will take time. Some platform may even 
be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any 
new feature on external L2 nodes, while all existing L2 features keep working, 
in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the 
Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 node.


First off, the Area SID is 100% optional. If you choose not to use it, then the 
Proxy LSP should be 100% compatible with a standard L2 node.



I cannot claim that we’ve exhaustively tested our implementation against all of 
the features that you cite, so there may still be corner cases, but our intent 
is to make that doable.  For exaple, the Proxy LSP can still contain a node 
SID, adjacency SID, and prefix SID as before. There’s no change there.



For SR, I think that this would require this Proxy LSP to advertise a 
Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is 
advertised with an IP address that would need to be provisioned.

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-07-30 Thread tony . li

Hi Bruno,

Thank you for your comments.


> On Jul 30, 2020, at 9:22 AM, bruno.decra...@orange.com wrote:
> 
> Hi Tony,
>  
> Thanks for the updated draft.
>  
> “ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
>represents the entirety of the Inside Area to the Outside Area.  This
>sub-TLV is learned by all of the Inside Edge Nodes who should consume
>this SID at forwarding time.”
>  
> Excellent, from my perspective.
>  
> Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.
>  
> “When SR is enabled, it may be useful to advertise an Area SID which
>will direct traffic to any of the Inside Edge Routers.  The Binding/
>MT Binding TLVs described in RFC 8667 Section 2.4 
>  are used to
>advertise such a SID.
>  
>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) »
>  
>  
> This works.


Excellent.


> However I may have a different deployment environment than the one you have 
> in mind. Even if those issues may be mine, allow me to share them with you.
> In many WAN networks than I’m used to, there are routers from different 
> vendors, platforms, software, generations. Requiring all those routers to 
> support the new Binding SID TLV T-Flag will take time. Some platform may even 
> be end of engineering (evolutions) so would never support such new features.
> In my environment, ideally, I would prefer a solution which do not require 
> any new feature on external L2 nodes, while all existing L2 features keep 
> working, in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would 
> require the Proxy LSP to be not (significantly) different than the LSP of a 
> vanilla L2 node.


First off, the Area SID is 100% optional. If you choose not to use it, then the 
Proxy LSP should be 100% compatible with a standard L2 node. 

I cannot claim that we’ve exhaustively tested our implementation against all of 
the features that you cite, so there may still be corner cases, but our intent 
is to make that doable.  For exaple, the Proxy LSP can still contain a node 
SID, adjacency SID, and prefix SID as before. There’s no change there.


> For SR, I think that this would require this Proxy LSP to advertise a 
> Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID 
> is advertised with an IP address that would need to be provisioned.


That’s certainly doable and requires no new protocol machinery. If the WG 
prefers this mode of operation, I’m not opposed.

 
> Both approaches are not mutually exclusives. I’d be happy enough with an 
> option for the Proxy LSP to advertise an Area Node SID with the Area SID 
> attached.
>  
> Finally, there is no requirement to make me happy ;-) . The above could also 
> be a local implementation knob not mentioned in the draft.


Our goal is to make as many customers as happy as possible.  ;-)

Tony

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