> 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