Well if this would be just to identify the neighbor this would be of no issue.
But it is obviously more than that. The key is to identify not only the neighbor, but mainly the same TLV fragments of the neighbor.
Please see the email exchange where MP-TLV requires to add as a keys interface_id(s) encoded in SUB-TLV of TLV 22.
Regards,
R.
On Tue, Nov 12, 2024 at 12:26 PM Christian Hopps <chopps@xxxxxxxxxx> wrote:
Robert Raszuk <robert@xxxxxxxxxx> writes:
> Hi Chris,
>
> You are 100% correct that today all specifications already define a
> set of values which are necessary to recognize TLVs to be coming from
> the same originator (originator can be a node_id or node_id+link_id
> etc ...).
>
> What seems to be the crux of the matter here is that MP-TLV spec
> recommends with normative MUST that a *subset* of those values (aka
> "keys") should be used when fragmenting TLV into chunks and attach to
> each one of them. It is this lack of definition on what is that
> *subset* which seems to be missing here.
>
> Intuitively, and I think this is highlighted in your and Les's
> responses that *subset* is what makes the TLV unique ... so values
> like metric, down/up bits etc ... would not be part of such
> *subsets*. The issue is that this is nowhere defined.
It's more than intuitive. This key value subset has to be exactly understood or the protocol would not function, you would either be replacing one neighbor with another niehgbor's TLV data (subset too small) or you would be creating multiple fake neighbors for a single actual neighbor (subset too large). The subset has to be exactly understood already or the TLV database would be corrupt on existing IS-IS.
This is why Les mentioned if the data is not actually well-defined in the original RFC then we need to fix that RFC b/c IS-IS operation could be corrupted even when no multi-part TLVs were in use. No example of this has been presented yet though..
Thanks,
Chris.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
