[Lsr] Murray Kucherawy's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-ospf-mpls-elc-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/ -- COMMENT: -- As with the IS-IS document, I assume the presence of six authors, above our usual limit of five, was approved by your AD. I agree with Barry's point that this document and the IS-IS document could easily have been combined. Even some of the syntactical things he corrected are present in both documents. When would you ever not do what the two SHOULDs in Section 3 say? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-isis-mpls-elc-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/ -- COMMENT: -- What Barry said. Also, I presume your AD has approved going over the usual limit of five authors. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Barry Leiba's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)
Barry Leiba has entered the following ballot position for draft-ietf-ospf-mpls-elc-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/ -- COMMENT: -- — Section 1 — In cases where LSPs are used (e.g., SR-MPLS [RFC8660], it would be Nit: you need a closing parenthesis instead of the second comma. This capability, referred to as Entropy Readable Label Depth (ERLD) as defined in [RFC8662] may be used by ingress LSRs to Nit: this needs a comma after the citation. — Section 3 — When an OSPF Area Border Router (ABR) distributes information between Nit: the abbreviation “ABR” is not used elsewhere in the document, so there’s no reason to include it. — Section 3.1 — Prefix TLV includes a one octet Flags field. Nit: hyphenate “one-octet” as a compound modifier. — Section 4 — The ERLD is advertised in a Node MSD sub-TLV [RFC8476] using the ERLD-MSD type defined in [I-D.ietf-isis-mpls-elc]. Just checking: is the IS-IS draft the right reference here in this OSPF document? There does seem to be so much common text between that document and this one that I really don’t understand why these (the IS-IS and OSPF signaling) were not put into one document, and this reference really drives that home. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Barry Leiba's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)
Barry Leiba has entered the following ballot position for draft-ietf-isis-mpls-elc-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/ -- COMMENT: -- Just a few editorial nits: — Section 1 — In cases where LSPs are used (e.g., SR-MPLS [RFC8660], it would be Nit: you need a closing parenthesis instead of the second comma. This capability, referred to as Entropy Readable Label Depth (ERLD) as defined in [RFC8662] may be used by ingress LSRs to Nit: this needs a comma after the citation. — Section 3 — originator. Similarly in a multi-domain network, the identity of the Nit: “Similarly” needs a comma after it. When a router propagates a prefix between ISIS levels ([RFC5302], it Nit: remove the open parenthesis. an Autonomous System Boundary Router (ASBR) is outside of the scope Nit: the abbreviation “ASBR” is not used elsewhere in the document, so there’s no reason to include it. — Section 4 — A new MSD-type [RFC8491], called ERLD-MSD is defined to advertise the Nit: 8491 capitalizes the “T” in “MSD-Type”. Nit: there needs to be a comma after “ERLD-MSD”. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Flooding across a network
[as WG member] I think it would be more productive if we stay focused on trying to improve flooding speed/efficiency here. How about let's get some of the proposals being mulled over actually written, and provide some data, and leave all the hand-wringing and theorizing about being too-successful for after we've shown we could be? :) Thanks, Chris. > On May 5, 2020, at 8:03 PM, Robert Raszuk wrote: > > But this proves that consistent convergence time in a domain is rather a good > thing regardless if it takes 2 sec or 50 sec on all nodes. > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Flooding across a network
Hi Les, A side comment but your example shows another - one may say even much more serious issue. Assume we have LFA/TI-LFA enabled in the network and precomputed on B which get's activated and shifts traffic to E when detects that C is down. Detection is fast .. 10s-100s of milliseconds. Now if B converges fast and recomputes topology much faster then D it may remove protection and send packets to D natively. Well clearly as we established D is slow and will loop it back. That is why I mentioned the other day that a fast control plane is not always a good thing (I am sure many will say the opposite - but it is ok ;). But this proves that consistent convergence time in a domain is rather a good thing regardless if it takes 2 sec or 50 sec on all nodes. Best, Robert. On Wed, May 6, 2020 at 1:35 AM Les Ginsberg (ginsberg) wrote: > Bruno - > > > > Seems like it was not too long ago that we were discussing this in > person. Ahhh...the good old days... > > > > First, let's agree that the interesting case does not involve 1 or even a > small number of LSPs. For those cases flooding speed does not matter. > > The interesting cases involve a large number of LSPs (hundreds or > thousands). And in such cases LFA/microloop avoidance techniques are not > applicable. > > > > Take the following simple topology: > > > > * | | ... ||* > > * +---+ +---+* > > * | C | | E |* > > * +---+ +---+* > > * | | 1000* > > * +---+ +---+* > > * | B |-| D |* > > * +---+ 1000 +---+* > > * | |* > > * | |* > > *\ /* > > * \/* > > * \ /* > > * \ /* > > * +---+* > > * | A |* > > * +---+* > > > > There is a topology northbound of C and E (not shown) and a topology > southbound of A (not shown). > > Cost on all links is 10 except B-D and D-E where cost is high. > > > > C is a node with 1000 neighbors. > > When all links are up, shortest path for all northbound destinations is > via C. > > All nodes in the network support fast flooding except for Node D. > > Let’s say fast flooding is 500 LSPs/second and slow flooding (Node D) is > 20 LSPs/seconds. > > If Node C fails we have 1000 LSPs to flood. > > All nodes except for D can receive these in 2 seconds (plus internode > delay time). > > D can receive LSPs in 50 seconds. > > > > When A and B and all southbound nodes receive/process the LSP updates they > will start sending traffic to Northbound destinations via D. > > But for the better part of 50 seconds, Node D has yet to receive all LSP > updates and still believes that shortest path is via B-C. It will loop > traffic. > > > > Had all nodes used slow flooding, it still would have taken 50 seconds to > converge, but there would be significantly less looping. There could be a > good amount of blackholing, but this is preferable to looping. > > > > One can always come up with examples – based on a specific topology and a > specific failure - where things might be better/worse/unchanged in the face > of inconsistent flooding speed support. > > But I hope this simple example illustrates the pitfalls. > > > > Les > > > > > -Original Message- > > > From: bruno.decra...@orange.com > > > Sent: Tuesday, May 05, 2020 8:28 AM > > > To: Les Ginsberg (ginsberg) ; lsr@ietf.org > > > Subject: Flooding across a network > > > > > > Les, > > > > > > > From: Lsr [mailto:lsr-boun...@ietf.org ] On > Behalf Of Les Ginsberg > > > (ginsberg) > > > > Sent: Monday, May 4, 2020 4:39 PM > > > [...] > > > > when only some nodes in the network support faster flooding the > behavior > > > of the whole network may not be "better" when faster flooding is enabled > > > because it prolongs the period of LSDB inconsistency. > > > > > > 1) Do you have data on this? > > > > > > 2) If not, can you provide an example where increasing the flooding rate > on > > > one adjacency prolongs the period of LSDB inconsistency across the > > > network? > > > > > > 3) In the meantime, let's try the theoretical analysis on a simple > scenario > > > where a single LSP needs to be flooded across the network. > > > > > > - Let's call Dij the time needed to flood the LSP from node i to the > adjacent > > > node j. Clearly Dij>0. > > > - Let's call k the node originating this LSP at t0=0s > > > > > > >From t0, the LSDB is inconsistent across the network as all nodes but k > are > > > missing the LSP and hence only know about the 'old' topology. > > > > > > Let's call SPT(k) the SPT rooted on k, using Dij as the metric between > > > adjacent nodes i and j. Let's call SP(k,i) the shortest path from k to > i; and > > > D(k,i) the shortest distance between k and i.. > > > > > > It seems that the time needed: > > > - for node j to learn about the LSP, and get in sync with k, is D(k,j) > > > - for all
Re: [Lsr] Flooding across a network
Bruno - Seems like it was not too long ago that we were discussing this in person. Ahhh...the good old days... First, let's agree that the interesting case does not involve 1 or even a small number of LSPs. For those cases flooding speed does not matter. The interesting cases involve a large number of LSPs (hundreds or thousands). And in such cases LFA/microloop avoidance techniques are not applicable. Take the following simple topology: | | ... || +---+ +---+ | C | | E | +---+ +---+ | | 1000 +---+ +---+ | B |-| D | +---+ 1000 +---+ | | | | \ / \/ \ / \ / +---+ | A | +---+ There is a topology northbound of C and E (not shown) and a topology southbound of A (not shown). Cost on all links is 10 except B-D and D-E where cost is high. C is a node with 1000 neighbors. When all links are up, shortest path for all northbound destinations is via C. All nodes in the network support fast flooding except for Node D. Let's say fast flooding is 500 LSPs/second and slow flooding (Node D) is 20 LSPs/seconds. If Node C fails we have 1000 LSPs to flood. All nodes except for D can receive these in 2 seconds (plus internode delay time). D can receive LSPs in 50 seconds. When A and B and all southbound nodes receive/process the LSP updates they will start sending traffic to Northbound destinations via D. But for the better part of 50 seconds, Node D has yet to receive all LSP updates and still believes that shortest path is via B-C. It will loop traffic. Had all nodes used slow flooding, it still would have taken 50 seconds to converge, but there would be significantly less looping. There could be a good amount of blackholing, but this is preferable to looping. One can always come up with examples - based on a specific topology and a specific failure - where things might be better/worse/unchanged in the face of inconsistent flooding speed support. But I hope this simple example illustrates the pitfalls. Les > -Original Message- > From: bruno.decra...@orange.com > Sent: Tuesday, May 05, 2020 8:28 AM > To: Les Ginsberg (ginsberg) ; lsr@ietf.org > Subject: Flooding across a network > > Les, > > > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg > (ginsberg) > > Sent: Monday, May 4, 2020 4:39 PM > [...] > > when only some nodes in the network support faster flooding the behavior > of the whole network may not be "better" when faster flooding is enabled > because it prolongs the period of LSDB inconsistency. > > 1) Do you have data on this? > > 2) If not, can you provide an example where increasing the flooding rate on > one adjacency prolongs the period of LSDB inconsistency across the > network? > > 3) In the meantime, let's try the theoretical analysis on a simple scenario > where a single LSP needs to be flooded across the network. > > - Let's call Dij the time needed to flood the LSP from node i to the adjacent > node j. Clearly Dij>0. > - Let's call k the node originating this LSP at t0=0s > > >From t0, the LSDB is inconsistent across the network as all nodes but k are > missing the LSP and hence only know about the 'old' topology. > > Let's call SPT(k) the SPT rooted on k, using Dij as the metric between > adjacent nodes i and j. Let's call SP(k,i) the shortest path from k to i; and > D(k,i) the shortest distance between k and i. > > It seems that the time needed: > - for node j to learn about the LSP, and get in sync with k, is D(k,j) > - for all nodes across the network to learn about the LSP, and get in sync > with > k, is Max[for all j] D(k,j) > > Then how can reducing the flooding delay on one adjacency could prolongs > the period of LSDB inconsistency? > It seems to me that it can only improve/decrease it. Otherwise, this would > mean that decreasing the cost on a link can increase the cost of the shortest > path. > > Note: I agree that there are other cases, such as multiple LSPs originated by > the same node, and multiple LSPs originated by multiple nodes, but let's start > with the simple case. > > Thanks, > --Bruno > > > -Original Message- > > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg > (ginsberg) > > Sent: Monday, May 4, 2020 4:39 PM > > > > Henk - > > > > Thanx for your thoughtful posts. > > I have read your later posts on this thread as well - but decided to reply > > to > this one. > > Top posting for better readability. > > > > There is broad agreement that faster flooding is desirable. > > There are now two proposals as to how to address the issue - neither of > which is proposing to use TCP (or equivalent). > >
[Lsr] Flooding across a network
Les, > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg) > Sent: Monday, May 4, 2020 4:39 PM [...] > when only some nodes in the network support faster flooding the behavior of > the whole network may not be "better" when faster flooding is enabled because > it prolongs the period of LSDB inconsistency. 1) Do you have data on this? 2) If not, can you provide an example where increasing the flooding rate on one adjacency prolongs the period of LSDB inconsistency across the network? 3) In the meantime, let's try the theoretical analysis on a simple scenario where a single LSP needs to be flooded across the network. - Let's call Dij the time needed to flood the LSP from node i to the adjacent node j. Clearly Dij>0. - Let's call k the node originating this LSP at t0=0s >From t0, the LSDB is inconsistent across the network as all nodes but k are >missing the LSP and hence only know about the 'old' topology. Let's call SPT(k) the SPT rooted on k, using Dij as the metric between adjacent nodes i and j. Let's call SP(k,i) the shortest path from k to i; and D(k,i) the shortest distance between k and i. It seems that the time needed: - for node j to learn about the LSP, and get in sync with k, is D(k,j) - for all nodes across the network to learn about the LSP, and get in sync with k, is Max[for all j] D(k,j) Then how can reducing the flooding delay on one adjacency could prolongs the period of LSDB inconsistency? It seems to me that it can only improve/decrease it. Otherwise, this would mean that decreasing the cost on a link can increase the cost of the shortest path. Note: I agree that there are other cases, such as multiple LSPs originated by the same node, and multiple LSPs originated by multiple nodes, but let's start with the simple case. Thanks, --Bruno > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg) > Sent: Monday, May 4, 2020 4:39 PM > > Henk - > > Thanx for your thoughtful posts. > I have read your later posts on this thread as well - but decided to reply to > this one. > Top posting for better readability. > > There is broad agreement that faster flooding is desirable. > There are now two proposals as to how to address the issue - neither of which > is proposing to use TCP (or equivalent). > > I have commented on why IS-IS flooding requirements are significantly > different than that for which TCP is used. > I think it is also useful to note that even the simple test case which Bruno > reported on in last week's interim meeting demonstrated that without any > changes to the protocol at all IS-IS was able to flood an order of magnitude > faster than it commonly does today. > This gives me hope that we are looking at the problem correctly and will not > need "TCP". > > Introducing a TCP based solution requires: > > a)A major change to the adjacency formation logic > > b)Removal of the independence of the IS-IS protocol from the address families > whose reachability advertisements it supports - something which I think is a > great strength of the protocol - particularly in environments where multiple > address family support is needed > > I really don't want to do either of the above. > > Your comments regarding PSNP response times are quite correct - and both of > the draft proposals discuss this - though I agree more detail will be > required. > It is intuitive that if you want to flood faster you also need to ACK faster > - and probably even retransmit faster when that is needed. > The basic relationship between retransmit interval and PSNP interval is > expressed in ISO 10589: > > " partialSNPInterval - This is the amount of time between periodic > action for transmission of Partial Sequence Number PDUs. > It shall be less than minimumLSPTransmission-Interval." > > Of course ISO 10589 recommended values (2 seconds and 5 seconds respectively) > associated with a much slower flooding rate and implementations I am aware of > use values in this order of magnitude. These numbers need to be reduced if we > are to flood faster, but the relationship between the two needs to remain the > same. > > It is also true - as you state - that sending ACKs more quickly will result > in additional PDUs which need to be received/processed by IS-IS - and this > has some impact. But I think it is reasonable to expect that an > implementation which can support sending and receiving LSPs at a faster rate > should also be able to send/receive PSNPs at a faster rate. But we still need > to be smarter than sending one PSNP/one LSP in cases where we have a burst. > > LANs are a more difficult problem than P2P - and thus far > draft-ginsberg-lsr-isis-flooding-scale has been silent on this - but not > because we aren't aware of this - just have focused on the P2P behavior first. > What the best behavior on a LAN may be is something I am still considering. > Slowin
Re: [Lsr] AD Review of draft-ietf-ospf-te-link-attr-reuse-10
Hi Alvaro, thanks for your comments. I apologize for the delay in responding to your comments. I tried to address all of them, some have been resolved during ISIS draft review, in which case I took the same resolution for this draf. Please see inline, look for ##PP Dear Authors: Happy New Year! I have finished reading this document, reviewing the e-mail archive and all the various reviews and comments. Quoting one of the authors, "it is essential that the two IGPs provide equivalent functionality" [1] -- so I have considered draft-ietf-isis-te-app-09 in parallel with this one (I'm sending out a separate yet very similar review for it). In general, I think both drafts need some work. When appropriate, I have used "[c]" to highlight comparisons. I tried to put equivalent comments in both documents, but may have missed a few... I have some significant concerns (see details inline) about this document -- and as a result about the ISIS draft. I want to point out a couple of them here: (A) Deployment Considerations This document contains what I would characterize as a "distributed" Deployment Considerations section through §8, §9 and §10. There is a lot of content, but I still made some comments inline about other important information. Please consider consolidating all the deployment-related information in one place. rfc5706 (specially §2) may be useful, please take a look. ##PP I have kept "Attribute Advertisements and Enablement" section (moved it up) and combined "Deployment Considerations" and "Interoperability, Backwards Compatibility and Migration" into single section "Deployment Considerations" similar to what has been done for ISIS [c] This document does not include equivalent information to what is in §7.* in the ISIS draft. Please consider "importing" it (or at least making a reference). ##PP done (B) I was able to identify one significant functional difference which warrants a discussion of the reason for it and maybe the pros/cons: §3 talks about the behavior when "both SABM Length and UDABM Length are 0". This document makes the use of the attributes mandatory by all applications (in conflict with §8.2) while the ISIS draft makes their use optional (§4.1). ##PP removed the text in section 3 and clarified in section "Use of Zero Length Application Identifier Bit Masks" to match what is in ISIS draft. I will wait for this review to be addressed before moving both documents forward together. Thanks! Alvaro. [1] https://mailarchive.ietf.org/arch/msg/ospf/7zkoaLfUe19JxTOWaKWO51wK9gg [Line numbers from idnits.] ... 16 Abstract 18 Various link attributes have been defined in OSPF in the context of 19 the MPLS Traffic Engineering (TE) and GMPLS. Since the original 20 RSVP-TE use case was defined, additional applications (e.g., SRTE, 21 LFA) have been defined which also make use of the link attribute 22 advertisements. This document defines how to distribute link 23 attributes in OSPFv2 and OSPFv3 for applications other than MPLS TE 24 or GMPLS. [c] This abstract is a lot more general, while the ISIS one provides more specifics, including talking about RSVP-TE instead of MPLS TE... [minor] It may not be obvious to all readers what the relationship is between RSVP-TE and MPLS TE... ##PP Made it similar to ISIS draft. ... 89 1. Introduction 91 Various link attributes have been defined in OSPFv2 [RFC2328] and 92 OSPFv3 [RFC5340] in the context of the MPLS TE and GMPLS. All these 93 attributes are distributed by OSPFv2 as sub-TLVs of the Link-TLV 94 advertised in the OSPFv2 TE Opaque LSA [RFC3630]. In OSPFv3, they 95 are distributed as sub-TLVs of the Link-TLV advertised in the OSPFv3 96 Intra-Area-TE-LSA as defined in [RFC5329]. [nit] s/defined in OSPFv2/defined for OSPFv2 [nit] s/context of the MPLS/context of MPLS [minor] "All these attributes..." Which attributes? I'm sure the references are made later, but since they are mentioned here first, please put references here. [[c] The ISIS draft mentions the relevant RFCs from the start.] 98 Many of these link attributes are useful outside of traditional MPLS 99 Traffic Engineering or GMPLS. This brings its own set of problems, 100in particular how to distribute these link attributes in OSPFv2 and 101OSPFv3 when MPLS TE and GMPLS are not deployed or are deployed in 102parallel with other applications that use these link attributes. [nit] "own set of problems" Are there others you want to highlight besides the distribution? [minor] What is an application? I think I can tell the difference between an "application", as used in this document, and an "application" as what the ART area does: "The ART area develops application protocols and architectures in the IETF." [1] Please define what an application is in the context of thi
[Lsr] Rtgdir last call review of draft-ietf-ospf-mpls-elc-13
Reviewer: Dhruv Dhody Review result: Has Issues Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ospf-mpls-elc-13 Reviewer: Dhruv Dhody Review Date: 2020-05-05 IETF LC End Date: 2020-05-05 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Disclaimer: I reviewed an earlier version (-09) as part of the early directorate review, which could be located at - https://datatracker.ietf.org/doc/review-ietf-ospf-mpls-elc-09-rtgdir-early-dhody-2019-09-12/ I have reviewed this and the IS-IS I-D together and you will find similar comments for both I-Ds. You could discuss them in one place. Major Issues: None Minor Issues: (1) Introduction Recently, mechanisms have been defined to signal labels via link- state Interior Gateway Protocols (IGP) such as OSPFv2 [RFC8665] and OSPFv3 [RFC8666]. Is there a better way to introduce OSPF extension for SR (than saying that it is just an example to signal labels)? (2) Section 3 Query: The text says that the ABR "MUST" preserve the ELC setting where as the ASBR "SHOULD" preserve it. What is the reason for using SHOULD in case of ASBR? Maybe we can spell out in which case ASBR might not preserve the ELC setting. (3) Section 4 The absence of ERLD-MSD advertisements indicates only that the advertising node does not support advertisement of this capability. Do you mean to differentiate between support for the capability itself v/s support for 'advertisement' only. But RFC 8662 says that ERLD value is advertised only when following conditions are met: * MUST be entropy label capable and, as a consequence, MUST apply the data-plane procedures defined in [RFC6790]. * MUST be able to read an ELI/EL, which is located within its ERLD value. * MUST take into account an EL within the first ERLD labels in its load-balancing function. Thus, I am not sure about this sentence. Maybe you mean to say that the absence only indicates that the ERLD-MSD value of the node is unknown (and it might still be capable of handling ELI/EL)? (4) Section 4 What would be the behavior if an OSPF router receives a ERLD of the node but no ELC set for the corresponding prefix? That would be an error as per RFC 8662, we should specify how one handles it within OSPF. If it is to just ignore the ERLD, we should explicitly say that. Nits: (1) Change OSPF Working group to LSR Working group in the metadata (first line of the I-D) (2) Abstract - use term LSP instead of tunnel for consistency OLD: An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that tunnel. NEW: An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. END (3) Section 4 s/Node MSD sub-TLV/Node MSD TLV/ (4) Expand BGP-LS on first use. Thanks! Dhruv ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Rtgdir last call review of draft-ietf-isis-mpls-elc-12
Reviewer: Dhruv Dhody Review result: Has Issues Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-isis-mpls-elc-12 Reviewer: Dhruv Dhody Review Date: 2020-05-05 IETF LC End Date: 2020-05-05 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Disclaimer: I reviewed an earlier version (-08) as part of the early directorate review, which could be located at - https://datatracker.ietf.org/doc/review-ietf-isis-mpls-elc-08-rtgdir-early-dhody-2019-09-12/ I have reviewed this and the OSPF I-D together and you will find similar comments for both I-Ds. You could discuss them in one place. Major Issues: None Minor Issues: (1) Introduction Recently, mechanisms have been defined to signal labels via link- state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667]. Is there a better way to introduce IS-IS extension for SR (than saying that it is just an example to signal labels)? (2) Section 3 Query: The text says that the ABR "MUST" preserve the ELC setting where as the ASBR "SHOULD" preserve it. What is the reason for using SHOULD in case of ASBR? Maybe we can spell out in which case ASBR might not preserve the ELC setting. (3) Section 4 The absence of ERLD-MSD advertisements indicates only that the advertising node does not support advertisement of this capability. Do you mean to differentiate between support for the capability itself v/s support for 'advertisement' only. But RFC 8662 says that ERLD value is advertised only when following conditions are met: * MUST be entropy label capable and, as a consequence, MUST apply the data-plane procedures defined in [RFC6790]. * MUST be able to read an ELI/EL, which is located within its ERLD value. * MUST take into account an EL within the first ERLD labels in its load-balancing function. Thus, I am not sure about this sentence. Maybe you mean to say that the absence only indicates that the ERLD-MSD value of the node is unknown (and it might still be capable of handling ELI/EL)? I see similar language in RFC8491 but I think we could be clearer in this I-D for ERLD. (4) Section 4 What would be the behavior if an IS-IS router receives an ERLD of the node but no ELC set for the corresponding prefix? That would be an error as per RFC 8662, we should specify how one handles it within IS-IS. If it is to just ignore the ERLD, we should explicitly say that. (5) Section 4 We need to clearly state that this new MSD Type is carried in Node MSD sub-TLV as described in [RFC8491]. And then I guess we don't really need figure 2? The format is as per RFC 8491! Nits: (1) Abstract - use term LSP instead of tunnel for consistency OLD: An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that tunnel. NEW: An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. END (2) Expand BGP-LS on first use! Thanks! Dhruv ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
