Murray, thanks for review Yes, the draft is written intentionally in such loose way to leave space for implementations/future drafts where a node can be e.g. client of multiple reflectors, a reflector has 2 cluster IDs (migration scenarios and such jazz). Hence, the draft is written to be liberal on accepting the stuff and in this draft clearly enforce the limitations of conceptual model on which it is based (multiplicities).
“ hot potato” is used in the document, so is tunnel endpoint BTW * Tony From: Murray Kucherawy via Datatracker <[email protected]> Date: Thursday, 1 December 2022 at 09:31 To: The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Murray Kucherawy's No Objection on draft-ietf-lsr-isis-flood-reflection-11: (with COMMENT) [External Email. Be cautious of content] Murray Kucherawy has entered the following ballot position for draft-ietf-lsr-isis-flood-reflection-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DO51MT4qeVKj6iS4P5bHIOxsY0_HRozaSp8K0DU6kpUDIJGY4cwNvZBvgkQ2ewvmXt2FfTH6UPR0$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DO51MT4qeVKj6iS4P5bHIOxsY0_HRozaSp8K0DU6kpUDIJGY4cwNvZBvgkQ2ewvmXt2FfTH6UPR0$> for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/__;!!NEt6yMaO-gk!DO51MT4qeVKj6iS4P5bHIOxsY0_HRozaSp8K0DU6kpUDIJGY4cwNvZBvgkQ2ewvmXt2FfQhGRhkK$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/__;!!NEt6yMaO-gk!DO51MT4qeVKj6iS4P5bHIOxsY0_HRozaSp8K0DU6kpUDIJGY4cwNvZBvgkQ2ewvmXt2FfQhGRhkK$> ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work put into this. I just have some minor editorial things to consider. Section 4.1 contains this text: The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. A router receiving one or more Flood Reflection TLVs in the same IIH MUST use the values in the first TLV and it SHOULD log such violations subject to rate limiting. There are several other instances of this pattern in later sections. In each case I'm wondering why an implementer might choose to disregard the SHOULD NOT. Is there ever a legitimate reason to do so? If so, could we include an example? If not, should this simply be a MUST? Several of the other SHOULDs leave me wondering the same thing. Thanks for a good IANA Considerations section. Section 2 defines "Tunnel Endpoint" and "Hot-Potato Routing", but those terms don't appear anywhere in the document. Juniper Business Use Only
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
