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

From: <[email-masked]>
Date: Tue, 4 Aug 2020 12:45:25 +0000

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<https://tools.ietf.org/html/rfc8667#section-2.4.4> 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<https://tools.ietf.org/html/rfc8667#section-2.4.5> 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...

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

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

Thanks,
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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 4 Aug 2020 14:49:52 +0000

Bruno -

Please see inline.

From: Lsr <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, August 04, 2020 5:45 AM
To: [email-masked]
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi,

  1.  It does not seem compliant with RFC 8667

   support Area SID:

      A new flag is defined:

         When T-flag is set:

      Section 2.4.4 of RFC 8667<https://tools.ietf.org/html/rfc8667#section-2.4..4> is altered to say:

         or T-flag are set."

      altered to say:

         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."

[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.

[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 needed here and why.
I would agree that if algorithm is required it is currently not available - but it is not yet clear that algorithm is required.

   Les

Thanks,
Regards,
--Bruno

Thank you.

---

From: <[email-masked]>
Date: Tue, 4 Aug 2020 15:17:30 +0000

Les,

Please see inline.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, August 4, 2020 4:50 PM
To: DECRAENE Bruno TGI/OLN <[email-masked]>; [email-masked]
Subject: RE: draft-ietf-lsr-isis-area-proxy-02

Bruno -

Please see inline.

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, August 04, 2020 5:45 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi,

   support Area SID:

      A new flag is defined:

         When T-flag is set:

         or T-flag are set."

      altered to say:

         TLV."

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.

[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 algo to be used.
Coming back to my first question, is this segment expected to be global or local within the (external) L2?
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.
[Bruno] yes but that one is only advertised within the area. I'm referring to the L2 advertisement external to the area.

[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.
[Bruno]
My understanding is that the IGP Mirror SID is a local segment.
For the area SID, I think it should be global, but I see no mention of this in the draft. Let's begin with the first question: in the (external) L2, is the area SID a global or local segment?

--Bruno

   Les

Thanks,
Regards,
--Bruno

Thank you.

---

From: Tony Li <[email-masked]>
Date: Tue, 4 Aug 2020 08:25:45 -0700

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 5 Aug 2020 19:31:08 +0000

Hi Tony, Bruno, Les,

From: Lsr <[email-masked]> on behalf of Tony Li <[email-masked]>
Date: Tuesday, August 4, 2020 at 11:26 AM
To: Bruno Decraene <[email-masked]>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi Bruno,

[Bruno] Agreed so far.

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 5 Aug 2020 19:54:12 +0000

Acee -

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

Hi Tony, Bruno, Les,

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Tony Li <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 4, 2020 at 11:26 AM
To: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Cc: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi Bruno,

[Bruno] Agreed so far.

[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

---

From: Tony Li <[email-masked]>
Date: Wed, 5 Aug 2020 13:08:24 -0700

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…

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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 5 Aug 2020 17:22:31 -0400

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 5 Aug 2020 23:02:44 +0000

Tony -

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

Les,

[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.

[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.

[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

---

From: Tony Li <[email-masked]>
Date: Wed, 5 Aug 2020 16:25:43 -0700

Les,

> [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. (!!!!??!?!?!)

> And rest assured that you will be asked by someone to define the expected behavior when there is an inconsistency. 😊

Same question: same answer. :-)

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

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

> And it impacts how traffic is forwarded into the area.

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

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 6 Aug 2020 00:06:27 +0000

Tony -

Sent: Wednesday, August 05, 2020 4:26 PM

Les,

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.

[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.

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

---

From: Tony Li <[email-masked]>
Date: Thu, 6 Aug 2020 09:31:42 -0700

Les,

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 6 Aug 2020 21:28:03 +0000

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

Sent: Thursday, August 06, 2020 9:32 AM

Les,

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 6 Aug 2020 17:34:27 -0400

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 <[email-masked]> wrote:

>
>
> Les,
>
> * There then remains the question as to whether the “Area Prefix” is
> *[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.*
>
>
>
>
> *[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.*
>
>
>
-- 

*Gyan Mishra*

---

From: Tony Li <[email-masked]>
Date: Thu, 6 Aug 2020 14:42:15 -0700

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.

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

> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 7 Aug 2020 05:58:06 +0000

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

Sent: Thursday, August 06, 2020 2:42 PM

Les,

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 6 Aug 2020 23:45:48 -0700

Hi Les,

> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 7 Aug 2020 07:11:25 +0000

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

Sent: Thursday, August 06, 2020 11:46 PM

Hi Les,

Tony