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
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
>
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
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
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
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
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
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
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