Menachem - V4 of the draft has been uploaded which addresses your comments as described in my earlier responses. Please let me know if there are any remaining issues. Thanx. Les > -----Original Message----- > From: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx> > Sent: Wednesday, August 31, 2022 9:53 AM > To: Menachem Dodge <menachemdodge1@xxxxxxxxx>; ops-dir@xxxxxxxx > Cc: draft-ietf-lsr-isis-rfc5316bis.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx > Subject: RE: Opsdir last call review of draft-ietf-lsr-isis-rfc5316bis-03 > > 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
