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

[Tony Li <[e-mail]>]

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