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 From: Tony Li <tony1ath...@gmail.com> Sent: Thursday, August 06, 2020 2:42 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: Acee Lindem (acee) <a...@cisco.com>; Bruno Decraene <bruno.decra...@orange.com>; lsr@ietf.org Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02 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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
