Hi Roman, Alexy, Thank you for your comments.
> ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ** Section 4.3. Do all the candidates need the Area Proxy System Identifier > TLVs need the same system identifier? I’m not sure I understand the question. Let me prattle on a bit and please let me know if I do not address the question. Vanilla IS-IS requires that each node in the routing domain have a unique system identifier. This is unchanged. Area Proxy extends this by requiring an additional system identifier for the Area Proxy. This is the Area Proxy System Identifier. This is normally advertised by the Area Leader so that all Interior Nodes know the value and it’s used by Interior Edge Nodes. It’s a good idea to have multiple candidates for Area Leader for resiliency, and having them all configured with the same Area Proxy System Identifier is strongly preferred out of consistency. However, it is NOT required. It is not an error for there to be multiple different candidate Area Proxy System Identifiers. In fact, this situation might happen if someone has decided to change the Area Proxy System Identifier and is in the midst of reconfiguring part of the routing domain. This does not cause confusion because Area Leader election is going to elect a single leader and all systems will use the Area Proxy System Identifier that the leader is advertising. Yes, if there is a change in leader, there may be a transient change in the Area Proxy System Identifier. This would cause a set of adjacency flaps, just as changing any regular system identifier would. > -- 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.” The rationale is similar to the above. Is there a separate question? > -- Section 4.3.1 says: “All candidates advertising the Area Proxy System > Identifier TLV MUST be advertising the same system identifier.” I will relax this to a SHOULD. > 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? No. These are key for ensuring the benefits of Area Proxy, most especially scalability, but if they are violated, it is not necessarily catastrophic. Some examples: - If the L1 LSP of an Inside Router is leaked outside of the area, then it would be a protocol error, but other routers should recognize that they are not part of that area and ignore the LSP. - If the L2 LSP of an Inside Router is leaked outside of the area, then it would be accepted by other routers, but it would have no two-way adjacencies with anything else in L2 and effectively be disconnected from the topology. - Incorrect PSNP or CSNPs would prompt the receiving system to send PSNPs for Inside LSPs, but this would not per se cause problems. > -- What are the relevant pointers to IS-IS security considerations? AFAIK, there is no overall document for IS-IS’ security architecture. The only pointers I can suggest are to RFC 5304 and 5310. I will happily add references to these if folks feel that’s helpful. > ---------------------------------------------------------------------- > 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? I don’t have any specific suggestions. My implementation practice is to apply binary exponential backoff, with some ridiculous upper bound, but the specifics are well outside of the boundaries of a protocol spec. > ** 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)? This is not a MUST because it’s a redundancy, not an error. > ** 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. We intentionally left this liberal to allow for a combination of intelligent defaults and local configuration. For example, if the Area Leader is configured for SRv6 and it sees other nodes advertising SRv6 information, then it might be smart to automatically propagate SRv6 information. But we don’t want to say ‘MUST' because not all areas may be using SRv6 and the network operator might want to filter out SRv6. Yes, obviously different implementations that made different choices would have different effects on L2. The rationale for other information is similar. For scalability reasons, we want to default to copying as little as possible. Regards, Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
