Roman Danyliw has entered the following ballot position for
draft-ietf-lsr-isis-area-proxy-10: Discuss
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-area-proxy/
--
DISCUSS:
--
** Section 4.3. Do all the candidates need the Area Proxy System Identifier
TLVs need the same system identifier?
-- Section 4.2 says “For consistency, all Area Leader candidates SHOULD be
configured with the same Proxy System ID, Proxy Hostname, and any other
information that may be inserted into the Proxy LSP.”
-- Section 4.3.1 says: “All candidates advertising the Area Proxy System
Identifier TLV MUST be advertising the same system identifier.”
The first statement suggests that consistency might not always be required, but
the second statement is clear that it always must be the same identifier.
** Section 8. The following statement doesn’t appear to be accurate.
8. Security Considerations
This document introduces no new security issues. Security of routing
within a domain is already addressed as part of the routing protocols
themselves. This document proposes no changes to those security
architectures.
-- Aren’t a few the filtering activities described in Section 5.2
security-related?
-- What are the relevant pointers to IS-IS security considerations?
--
COMMENT:
--
Thank you to Alexey Melnikov for the SECDIR review.
** Section 4.3.1
However, before withdrawing the Area Proxy
System Identifier, an implementation SHOULD protect against
unnecessary churn from transients by delaying the withdrawal. The
amount of delay is implementation-dependent.
Are there any guidelines on how the delay period should be computed?
** Section 4.4.4.
An entry for a neighbor in both the IS Neighbors TLV and the Extended
IS Neighbors would be functionally redundant, so the Area Leader
SHOULD NOT do this.
Under what circumstances would this advice be ignored (i.e., why not a MUST)?
** Section 4.4.5 and 4.4.6 describe various behavior where fields “SHOULD” be
copied. What governs the choice of not copying these fields? Would operators
be impacted in troubleshooting or even operations if different implementations
applied this advice differently? Would it be up to local configuration? Later
sections in 4.4.* also have “SHOULD” behavior as well where the reason for not
following the behavior is not clear.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
