Subject: [Idr] Clarifications on Error handling for malformed sub-tlvs in draft-ietf-idr-tunnel-encaps

From: Nandan Saha <[email-masked]>
Date: Wed, 22 Jan 2020 09:22:53 +0530

Hi folks,

In the following quoted text,
If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that
   is not recognized by a particular BGP speaker, the BGP speaker MUST
   process that TLV as if the unrecognized sub-TLV had not been present.
   If the route carrying the Tunnel Encapsulation attribute is
   propagated with the attribute, the unrecognized TLV MUST remain in
   the attribute
<<<

instead of "unrecognized TLV MUST remain" in the last part of the sentence,
shouldn't it be "unrecognized sub-TLV" (sub-TLV instead of TLV), since the
context is how to handle unrecognized sub-TLVs? (or something like
"unrecognized sub-TLV MUST remain in the TLV")

The same text is referred to for how to deal with malformed sub-TLVs, ie.
In general, if a TLV contains a sub-TLV that is malformed (e.g.,
   contains a length field whose value is not legal for that sub-TLV),
   the sub-TLV should be treated as if it were an unrecognized sub-TLV
<<<

Just want to confirm that the intention is to propagate the malformed
sub-TLV(s). I'm not entirely sure how that's useful though (as opposed to
stripping away just the malformed sub-TLV(s) from the TLV before
propagation)

Thanks,
Nandan

---

From: Srihari Sangli <[email-masked]>
Date: Tue, 28 Jan 2020 11:38:04 +0000

Just want to confirm that the intention is to propagate the malformed sub-TLV(s). I'm not entirely sure how that's useful though (as opposed to stripping away just the malformed sub-TLV(s) from the TLV before propagation)

Yes, the intention is to maintain the entire TLV intact and not drop the unrecognized sub-TLVs.

srihari…