Roman, thanks for review,
1. As to SHOULD NOT vs. MUST NOT was answered in Murray’s comment already.
Quote
“
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).
“
Even it’s a MUST NOT the behavior on duplicates must be specified based
on experience with ISIS In the wild since a long time
1. I clarified by saying
“
Carries encapsulation type and further attributes necessary for tunnel
establishment
as defined in <xref target="RFC9012"/>. In context of this
attribute the
protocol Type sub-TLV as defined in
<xref target="RFC9012"/> MAY be included to ensure proper
encapsulation of
IS-IS frames.
“
1. Editiorials taken in
Thanks
* Tony
From: Roman Danyliw via Datatracker <nore...@ietf.org>
Date: Thursday, 17 November 2022 at 23:09
To: The IESG <i...@ietf.org>
Cc: draft-ietf-lsr-isis-flood-reflect...@ietf.org
<draft-ietf-lsr-isis-flood-reflect...@ietf.org>, lsr-cha...@ietf.org
<lsr-cha...@ietf.org>, lsr@ietf.org <lsr@ietf.org>, a...@cisco.com
<a...@cisco.com>, a...@cisco.com <a...@cisco.com>
Subject: Roman Danyliw's No Objection on
draft-ietf-lsr-isis-flood-reflection-11: (with COMMENT)
[External Email. Be cautious of content]
Roman Danyliw 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!CWoApv0D9YDjxPLTcCeM13U00gUlkId0eNK_efgsSMfEPTPo3nmvU6uhyCtPRAfRhW0mDIs1tsns$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!CWoApv0D9YDjxPLTcCeM13U00gUlkId0eNK_efgsSMfEPTPo3nmvU6uhyCtPRAfRhW0mDIs1tsns$>
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!CWoApv0D9YDjxPLTcCeM13U00gUlkId0eNK_efgsSMfEPTPo3nmvU6uhyCtPRAfRhW0mDGkkOxTS$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/__;!!NEt6yMaO-gk!CWoApv0D9YDjxPLTcCeM13U00gUlkId0eNK_efgsSMfEPTPo3nmvU6uhyCtPRAfRhW0mDGkkOxTS$>
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you to Rich Salz for the SECDIR review.
** Section 4.1
The Flood Reflection TLV SHOULD NOT appear more than once in an IIH.
Why isn’t the guidance here “MUST NOT” appear since any subsequent, duplicate
Flood Reflection TLVs are ignored?
Same comment on the discovery Sub-TLV in Section 4.2, and Section 4.4
** Section 4.3
Carries encapsulation type and
further attributes necessary for tunnel establishment as defined
in [RFC9012]. The Protocol Type sub-TLV as defined in [RFC9012]
MAY be included.
The first sentence suggests that the semantics of this field are defined by
RFC9012. The second sentence suggests that it is optional to support the
Protocol Type sub-TLV per Section 3.4.1 of RFC9012. This is confusing to me
because RFC9012 supports a number of sub-TLVs to include the Protocol Type one
explicitly called out. Is that the only sub-TLV supported for use?
Editorial
** Section 1. Typo. s/Maintainance/Maintenance/
** Section 1. Editorial. Consider using a less colloquial phrase than
“Deployment-wise”.
** Section 4.2. Editorial. s/one ore more/one or more/
Juniper Business Use Only
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
