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

2020-08-06 Thread Gyan Mishra
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

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

2020-08-06 Thread Tony Li
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 >

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

2020-08-06 Thread Les Ginsberg (ginsberg)
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

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

2020-08-06 Thread Van De Velde, Gunter (Nokia - BE/Antwerp)
Thanks for the clarification and fast answer. Indeed FAD does not encode any attributes. That was not the point I was trying to make. .. The existing description in section 5.1 indicate that legacy encoding (RFC7810 and RFC5305) is used for link attributes. That is not correct based upon

Re: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

2020-08-06 Thread Peter Psenak
Hi Gunter, On 06/08/2020 18:31, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: Hi Authors, All, My understanding is that for new LSR applications we should select either “ASLA encoding” or select “legacy encoding” for all Link attributes. Not a mixture of both. There is a clear long term

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

2020-08-06 Thread Tony Li
Les, > 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

[Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

2020-08-06 Thread Van De Velde, Gunter (Nokia - BE/Antwerp)
Hi Authors, All, My understanding is that for new LSR applications we should select either "ASLA encoding" or select "legacy encoding" for all Link attributes. Not a mixture of both. There is a clear long term technology benefit of using all ASLA encoding. In draft-ietf-lsr-flex-algo-08

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

2020-08-06 Thread Les Ginsberg (ginsberg)
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

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-08-06 Thread Gyan Mishra
Hi Aijun and authors I am catching up with this thread after reading through this draft. I understand the concept that we are trying to send a PUA advertisement which sounds similar to Rift Negative Disaggregation prefix now with a null setting when a longer match component prefix that is part