[Lsr] [IANA #1239131] expert review for draft-ietf-lsr-isis-rfc5316bis (isis-tlv-codepoints)

[Sabrina Tanamal via RT]

Chris and Hannes (cc: lsr WG),

As the designated experts for the Sub-TLVs for TLVs Advertising Neighbor 
Information registry, can you review the proposed registration in 
draft-ietf-lsr-isis-rfc5316bis for us? Please see

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-rfc5316bis

If this is OK, when the IESG approves the document for publication, we'll make 
the registration at

https://www.iana.org/assignments/isis-tlv-codepoints

Les Ginsberg is also an expert for this registry, but he's one of the authors 
of this document.

If you're available, the due date is September 14th.

thanks,

Sabrina Tanamal
Lead IANA Services Specialist

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Menachem -

Thanx for the review.
Responses inline.

> -Original Message-
> From: Menachem Dodge via Datatracker 
> Sent: Wednesday, August 31, 2022 1:02 AM
> To: ops-...@ietf.org
> Cc: draft-ietf-lsr-isis-rfc5316bis@ietf.org; last-c...@ietf.org; 
> lsr@ietf.org
> 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:

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.


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
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD review of draft-ietf-lsr-flex-algo-20

[Peter Psenak]

Hi John,

thanks a lot for the thorough review.

I incorporated all your edits and almost all of your comments.

For the few that I have not, please see inline (loop for ##PP):


On 16/08/2022 23:45, John Scudder wrote:

Dear Authors,

Thanks for you patience as this document sat in my queue for too long. 
:-( Here’s my review.


I’ve supplied my comments in the form of an edited copy of the draft. 
Minor editorial suggestions I’ve made in place without further comment, 
more substantive comments are done in-line and prefixed with “jgs:”. You 
can use your favorite diff tool to review them; I’ve attached a PDF of 
the iddiff output for your convenience if you’d like to use it. I’ve 
also pasted a traditional diff below in case you want to use it for 
in-line reply. I’d appreciate feedback regarding whether you found this 
a useful way to receive my comments as compared to a more traditional 
numbered list of comments with selective quotation from the draft.


Thanks,

—John



--- draft-ietf-lsr-flex-algo-20.txt 2022-08-16 11:12:37.0 -0400
+++ draft-ietf-lsr-flex-algo-20-jgs-comments.txt    2022-08-16 
17:37:22.0 -0400

@@ -24,7 +24,7 @@
     on the IGP metric assigned to the links.  Many network deployments
     use RSVP-TE based or Segment Routing based Traffic Engineering to
     steer traffic over a path that is computed using different metrics or
-   constraints than the shortest IGP path.  This document proposes a
+   constraints than the shortest IGP path.  This document specifies a
     solution that allows IGPs themselves to compute constraint-based
     paths over the network.  This document also specifies a way of using
     Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
@@ -155,12 +155,12 @@

  1.  Introduction

-   An IGP-computed path based on the shortest IGP metric is often be
-   replaced by a traffic-engineered path due to the traffic requirements
+   An IGP-computed path based on the shortest IGP metric is often
+   replaced by a traffic-engineered path due to requirements
     which are not reflected by the IGP metric.  Some networks engineer
     the IGP metric assignments in a way that the IGP metric reflects the
-   link bandwidth or delay.  If, for example, the IGP metric is
-   reflecting the bandwidth on the link and the user traffic is delay
+   link bandwidth or delay.  If, for example, the IGP metric
+   reflects the bandwidth on the link and user traffic is delay



@@ -171,7 +171,10 @@


     sensitive, the best IGP path may not reflect the best path from such
-   users' perspective.
+   a user's perspective.
+
+jgs: or "from such users' perspectives" but as it was written, there was a
+disagreement in number, so I made it singular 'user'.

     To overcome this limitation, various sorts of traffic engineering
     have been deployed, including RSVP-TE and SR-TE, in which case the TE
@@ -179,7 +182,7 @@
     metrics and/or constraints.  Such paths need to be installed in the
     forwarding tables in addition to, or as a replacement for, the
     original paths computed by IGPs.  Tunnels are often used to represent
-   the engineered paths and mechanisms like one described in [RFC3906]
+   the engineered paths and mechanisms like the one described in [RFC3906]
     are used to replace the native IGP paths with such tunnel paths.

     This document specifies a set of extensions to IS-IS, OSPFv2, and
@@ -193,10 +196,29 @@
     of calculation-type, metric-type, and constraints.

     This document also specifies a way for a router to use IGPs to
-   associate one or more SR Prefix-SIDs or SRv6 locators with a
+   associate one or more Segment Routing (SR) Prefix-SIDs or Segment 
Routing over IPv6 (SRv6) locators with a

     particular Flex-Algorithm.  Each such Prefix-SID or SRv6 locator then
     represents a path that is computed according to the identified Flex-
     Algorithm.
+
+jgs: "SR" is in the well-known abbreviations list
+(https://www.rfc-editor.org/materials/abbrev.expansion.txt 
), but "SRv6"

+isn't. We could suggest the RFC Editor add "SRv6", but really it seems
+reader-friendly to expand these on first use anyway, as I've done with the
+text above.
+
+jgs: Making this edit also led me to wonder -- does "SR" above really mean
+"SR-MPLS"? Because "SR" as such is an architecture, right, not an
+instantiation? (SR-MPLS is also not in the well-known abbreviations 
list...)

+
+jgs: Please provide references for Prefix-SID and SRv6 locator?
+
+jgs: Finally, it seems to me as though a useful piece of context for the
+new reader is something like what I'm suggesting below:
+
+   Not all routers in a given network need to participate in a given
+   Flexible Algorithm. The Flexible Algorithm(s) a given router
+   participates in is determined by configuration.


##PP
we can certainly add this to the document, but I don't think 
Introduction is the right place. I adde

[Lsr] Opsdir last call review of draft-ietf-lsr-isis-rfc5316bis-03

[Menachem Dodge via Datatracker]

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. 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'.
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.

Other than that, the document is ready.

Best Regards,
Menachem



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr