Menachem - Thanx for the review. Responses inline. > -----Original Message----- > From: Menachem Dodge via Datatracker <noreply@xxxxxxxx> > Sent: Wednesday, August 31, 2022 1:02 AM > To: ops-dir@xxxxxxxx > Cc: draft-ietf-lsr-isis-rfc5316bis.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx > Subject: Opsdir last call review of draft-ietf-lsr-isis-rfc5316bis-03 > > Reviewer: Menachem Dodge > Review result: Has Nits > > I have reviewed this document as part of the Operational directorate's > ongoing > effort to review all IETF documents being processed by the IESG. These > comments > were written with the intent of improving the operational aspects of the IETF > drafts. Comments that are not addressed in last call may be included in AD > reviews during the IESG review. Document editors and WG chairs should > treat > these comments just like any other last call comments. > > This document describes extensions to the IS-IS protocol to support MPLS > and > GMPLS Traffic Engineering (TE) for multiple ASs. It defines IS-IS extensions > for the flooding of TE information about inter-AS links, which can be used to > perform inter-AS TE path computation. > > This document is well written and very clear and understandable. > > I have some minor nits: > 1. Section 4.1 is rather vague about what information could be taken from > BGP > and I was wondering whether it could be specified more clearly which > information is being referred to. After all, an example is then given in > section 5 regarding the remote AS number which is received in the BGP > OPEN. [LES:] Section 4 provides the list of information types: <snip> Only some essential TE information for the link needs to be advertised; i.e., the Interface Address, the remote AS number, and the remote ASBR ID of an inter-AS TE link. <end snip> This is also "reinforced" by the definition of the new sub-TLVs used to advertise this information defined in Section 3.3. Given that Section 4.1 is only providing descriptive text (not normative text) as to how an IS-IS implementation might obtain this information, the authors did not feel that respecifying the information types in Section 4.1 was necessary. We simply referred to Section 4. So I am a bit surprised at your confusion and am not sure how best to address it. Perhaps modifying the first sentence of the second paragraph: " Although the source of this information..." To " Although the source of the information described in Section 4..." Does this help? > 2. In section 5, it says "e.g., the administration that originally supplied the > information > may be lying,". I thought that 'lying' is rather blunt and whether this may > be rephrased - for example that the information supplied is 'incorrect'. [LES:] OK > 3. In my opinion, in section 5, the security section, it would also be worth > mentioning/discussing to what extent the use of the information supplied > by > the new TLV and sub-TLVs at the entry-point ASBRs and other LSRs in the AS, > could lead to incorrect decisions, and whether it is possible to detect such > incorrect decisions. > [LES:] WE already say: " For example, if a different remote AS number is received in a BGP OPEN [RFC4271] from that locally configured to ISIS-TE, as we describe here, then local policy SHOULD be applied to determine whether to alert the operator to a potential mis-configuration or to suppress the IS-IS advertisement of the inter-AS TE link." So I think we have covered a (non-exhaustive) description of how misconfigs can be detected. As to incorrect decisions, perhaps adding: "Advertisement of incorrect information could result in an inter-AS TE LSP that traverses an unintended AS." ?? Les > Other than that, the document is ready." > > Best Regards, > Menachem > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
