Re: [Last-Call] Opsdir last call review of draft-ietf-lsr-isis-rfc5316bis-03

["Les Ginsberg (ginsberg)" <[e-mail]>]

Menachem -

Thanx for the review.
Responses inline.

> -----Original Message-----
> From: Menachem Dodge via Datatracker <[e-mail]>
> Sent: Wednesday, August 31, 2022 1:02 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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
> 
>