Hi Tony! Thanks for the explanation. See below.
> -----Original Message----- > From: Tony Li <[email protected]> On Behalf Of Tony Li > Sent: Tuesday, January 9, 2024 5:31 PM > To: Roman Danyliw <[email protected]> > Cc: The IESG <[email protected]>; [email protected]; > lsr-chairs > <[email protected]>; lsr <[email protected]>; Christian Hopps <[email protected]> > Subject: Re: Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: > (with > DISCUSS and COMMENT) > > Warning: External Sender - do not click links or open attachments unless you > recognize the sender and know the content is safe. > > > 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. I very much appreciate the explanation. The bottom line issue was the inconsistency between the two statements highlighted by the "--" bullets. The proposed change to SHOULD in Section 4.3.1 addressed my feedback. > > ** 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. Thanks for this explanation. I clear on this point. Adding those references to the SecCons would be 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. I see. I also appreciate this clarification. Thanks, Roman _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
