[Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-originator-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : OSPF Prefix Originator Extension Authors : Aijun Wang Acee Lindem Jie Dong Peter Psenak Ketan Talaulikar Filename: draft-ietf-lsr-ospf-prefix-originator-04.txt Pages : 11 Date: 2019-09-12 Abstract: This document defines Open Shortest Path First (OSPF) encodings to advertise the router-id of the originator of inter-area prefixes for OSPFv2 and OSPFv3 Link-State Advertisements (LSAs). The source originator is needed in several multi-area OSPF use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-04 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-prefix-originator-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Rtgdir early review of draft-ietf-ospf-mpls-elc-09
Reviewer: Dhruv Dhody Review result: Has Issues Subject: RtgDir Early review: draft-ietf-ospf-mpls-elc-09 Hello I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/ The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is in working group last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-ospf-mpls-elc-09 Reviewer: Dhruv Dhody Review Date: 12-09-2019 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG. The draft is focused and straightforward, the reader needs to be aware of RFC6790 and draft-ietf-mpls-spring-entropy-label beforehand. I have reviewed this and the IS-IS I-D together and you will find similar comments for both I-Ds. Minor * (1) Please use updated requirement language text as per RFC 8174, as you do have a mix of upper-case and lower-case terms in your I-D. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. (2) Could you mark that the codepoints mentioned in the draft are early allocated by IANA? This would make it clear that you are not squatting on them. I also suggest following change in Section 7 (IANA Considerations) - OLD: This document requests IANA to allocate one flag from the OSPFv2 Extended Prefix TLV Flags registry: 0x20 - E-Flag (ELC Flag) This document requests IANA to allocate one flag from the OSPFv3 Prefix Options registry: 0x04 - E-Flag (ELC Flag) NEW: IANA is requested to confirm the early allocation of the following code point in the OSPFv2 Extended Prefix TLV Flags registry: 0x20 - E-Flag (ELC Flag) IANA is requested to confirm the early allocation of the following code point in the the OSPFv3 Prefix Options registry: 0x04 - E-Flag (ELC Flag) END (3) Section 4, I think a reference to RFC 8476 is needed as well to state the ERLD is advertised as part of Node MSD advertisement as defined in [RFC8476]. As mentioned in my review of the IS-IS I-D, what happens if one receives ERLD in the Link MSD advertisement? As per my understanding this is not allowed, better to add normative text for the case then. (4) Section 8, suggest to also add one sentence for the impact of advertising incorrect ERLD. If there isn't any, that can also be stated. Nits (1) Suggested ordering of sections - ..ELC/ERLD/BGP-LS/ACK.. [matching between OSPF/ISIS] (2) Section 2, add [I-D.ietf-mpls-spring-entropy-label] for terminology reference (3) Section 3, Add reference to draft-ietf-mpls-spring-entropy-label for the definition and usage of ERLD (4) Section 6, The ERLD MSD-type introduced for OSPF in Section 4 is advertised using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-ext]. I think you mean draft-ietf-idr-bgp-ls-segment-routing-msd here! Also, maybe change the title "BGP-LS Extension" as there is no 'extension' required, ELC/ERLD is BGP-LS would be automatically supported. (5) Expand MSD on first use. Thanks! Dhruv ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Rtgdir early review of draft-ietf-isis-mpls-elc-08
Reviewer: Dhruv Dhody Review result: Has Issues Subject: RtgDir Early review: draft-ietf-isis-mpls-elc-08 Hello I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/ The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is in working group last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-isis-mpls-elc-08 Reviewer: Dhruv Dhody Review Date: 12-09-2019 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG. The draft is focused and straightforward, the reader needs to be aware of RFC6790 and draft-ietf-mpls-spring-entropy-label beforehand. I have reviewed this and the OSPF I-D together and you will find similar comments for both I-Ds. Minor * (1) Could you mark that the codepoints mentioned in the draft are early allocated by IANA? Currently it says the value are desired. I also suggest following change in Section 7 (IANA Considerations) - OLD: IANA is requested to allocate the E-bit (bit position 3 is desired) from the "Bit Values for Prefix Attribute Flags Sub-TLV" registry. IANA is requested to allocate a MSD type (the type code of 2 is desired) from the "IGP MSD Types" registry for ERLD. NEW: IANA is requested to confirm the early allocation of the E-bit (Bit position 3) in the "Bit Values for Prefix Attribute Flags Sub-TLV" registry. IANA is requested to confirm the early allocation of the ERLD (type code of 2) in the "IGP MSD Types" registry. END (2) Section 3 talks about ERLD in Node MSD sub-TLV. But what happens if one receives ERLD in the Link MSD sub-TLV? As per my understanding this is not allowed, better to add normative text for the case then. Also we have this text in draft-ietf-mpls-spring-entropy-label - In a distributed switching architecture, each linecard may have a different capability in terms of ERLD. For simplicity, an implementation MAY use the minimum ERLD of all linecards as the ERLD value for the system. There may also be a case where a router has a fast switching path (handled by an ASIC or network processor) and a slow switching path (handled by a CPU) with a different ERLD for each switching path. Again, for simplicity's sake, an implementation MAY use the minimum ERLD as the ERLD value for the system. The drawback of using a single ERLD for a system lower than the capability of one or more specific component is that it may increase the number of ELI/ELs inserted. This leads to an increase of the label stack size and may have an impact on the capability of the ingress node to push this label stack. If we are deviating from this and opting for the node (marked 'MAY' above) as the only possibility, we need to handle this properly. Maybe check with chairs/AD on this! (3) Section 4, can we add some more description on what the 'E' flags means, in the similar style of other flags [https://tools.ietf.org/html/rfc7794#section-2.1] (4) Section 8, suggest to also add one sentence for the impact of advertising incorrect ERLD. If there isn't any, that can also be stated. Nits (1) Suggested ordering of sections - ..ELC/ERLD/BGP-LS/ACK.. [matching between OSPF/ISIS] (2) Section 2, add [I-D.ietf-mpls-spring-entropy-label] for terminology reference (3) Section 3, Add reference to draft-ietf-mpls-spring-entropy-label for the definition and usage of ERLD (4) Section 6, The ERLD MSD-type introduced for IS-IS in Section 3 is advertised using the Node MSD TLV (TLV 266) of the BGP-LS Node NLRI Attribute as defined in section 3 of [I-D.ietf-idr-bgp-ls-segment-routing-ext]. I think you mean draft-ietf-idr-bgp-ls-segment-routing-msd here! Also, maybe change the title "BGP-LS Extension" as there is no 'extension' required, ELC/ERLD is BGP-LS would be automatically supported. (5) Expand MSD on first use. (6) The first figure is titled Figure 2! (7) Section 4, mark the figure as "Prefix Attribute Flags" (8) All references are marked Normative, please re-check if this is intentional. Thanks! Dhruv ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
