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 

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.


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


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 

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 and 0::0/128.

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


Lsr mailing list

Reply via email to