[Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-isis-flood-reflection-11: (with COMMENT)

[Murray Kucherawy via Datatracker]

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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/



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



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-isis-flood-reflection-11: (with COMMENT)

[Antoni Przygienda]

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 
Date: Thursday, 1 December 2022 at 09:31
To: The IESG 
Cc: draft-ietf-lsr-isis-flood-reflect...@ietf.org 
, lsr-cha...@ietf.org 
, lsr@ietf.org , a...@cisco.com 

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



--
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr