[Lsr] Opsdir telechat review of draft-ietf-lsr-flex-algo-25
Reviewer: Linda Dunbar Review result: Ready I have reviewed this document as part of the Ops area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Ops area directors. Document editors and WG chairs should treat these comments just like any other last-call comments. The authors have addressed my comments on revision 23. I think the draft is ready now. cheers, Linda ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Datatracker State Update Notice:
IANA action state changed to "In Progress" Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'IGP extension for PCEP security capability support in PCE discovery' to Proposed Standard (draft-ietf-lsr-pce-discovery-security-support-13.txt)
The IESG has approved the following document: - 'IGP extension for PCEP security capability support in PCE discovery' (draft-ietf-lsr-pce-discovery-security-support-13.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Andrew Alston and John Scudder. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ Technical Summary This document provides extensions to OSPF and IS-IS to advertisement the PCE Security capabilities of the advertising router. These capabilities could than be used for PCE and PC Client authentication. Working Group Summary While this document has been around for some time, there wasn't much discussion until WG last call. During the WG last call, we received comments from more than a half dozen people and these were incorporated into the document. We also got RTG and SEC directorate reviews. The WG last call included both the LSR and PCE WG lists and there were reviewers from both. Document Quality The document is of high quality with all the required reviews. While there aren't any implementations yet, it is a very straight forward extension. Personnel Document Shepherd: Acee Lindem Responsible AD: John Scudder ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] FW: Directorate Early Reviews
Note that for LSR, we usually do this anyway so this really isn’t a change of policy. At least as a document shepherd, I always try and remember. Thanks, Acee From: Andrew Alston - IETF Date: Wednesday, October 12, 2022 at 3:30 AM To: "rtg-cha...@ietf.org" Subject: Directorate Early Reviews Resent-From: Resent-To: , , Daniele Ceccarelli , , , Yingzhen Qu , , , Gunter Van de Velde , , , Jie Dong , Alvaro Retana , Jeff Haas , , Acee Lindem , , "Joel M. Halpern" , Christian Hopps , Sam Aldrin , , , , John Scudder , , , , , , János Farkas , Luis Contreras , , , Jeff Tantsura , Stewart Bryant , , , , , Loa Andersson , Tarek Saad , , , , , Nic Leymann , Jeffrey Zhang , , , Mach Chen , , , , , , Keyur Patel , Russ White , Bruno Decraene , , , Resent-Date: Wednesday, October 12, 2022 at 3:29 AM Hi All, Following the helpful feedback received during chair’s meeting and further discussion between the routing AD’s, we would like to propose the following: 1.)We will require early directorate reviews before documents come to the AD’s to enter the publication queue 2.)We suggest that these reviews are done either in parallel with the working group last call or between the working group last call and publication request a. In the case of the early directorate review being done in parallel with the last call, it is suggested to use this approach only if there is indication that the document is stable, since we ask that the early review is done on the version of the document that will be received by the AD’s at the time of requested publication. 3.)While we require early review from the routing directorate, it is in the chair’s discretion if they wish to request early review from other directorates. As a guideline, we recommend a security directorate review in addition to the routing area directorate. We are still discussing all the feedback (and there was a lot of substantive feedback), so expect more from us in the coming weeks regarding the rest of the feedback. Thanks Andrew Alston (On Behalf of the Routing AD’s) Internal All Employees ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Datatracker State Update Notice:
IESG state changed: New State: Approved-announcement to be sent (The previous state was IESG Evaluation::AD Followup) Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] RFC 8362 and LSInfinity
One correction: “It should be expanded further” should be “it shouldn’t be expanded further” Aijun Wang China Telecom > On Oct 13, 2022, at 18:53, Aijun Wang wrote: > > Hi, Acee and Peter: > > I think you all misunderstood the intent of his scenario. > The correct understanding are the followings: > 1) When aggregate route is configured in the ABR, the specified detail route > should be withdrawn. > 2) ABR can withdraw the advertised LSA that describes the specific detail > route, via premature mechanism(MaxAge or LSInfinity, the former is preferred > according to RFC2328) > 3) But, withdrawn such specific LSA doesn’t mean the corresponding detail > route unreachable——This destination can be reached via the aggregate route > advertised by ABR instead. > > This is the original usage of LSInfinity defined in RFC2327. It should be > expanded further. > > How to apply it in RFC8362 is another issue, as indicated my responses in > another thread. > > In summary, again, we should constrain or depreciate the confusion usages of > LSInfinity. > > Aijun Wang > China Telecom > >> On Oct 13, 2022, at 18:07, Acee Lindem (acee) >> wrote: >> >> Hi Zhibo, >> >> On 10/13/22, 2:26 AM, "Lsr on behalf of Huzhibo" > behalf of huzhibo=40huawei@dmarc.ietf.org> wrote: >> >> Hi LSR: >> >> LSInfinity >> The metric value indicating that the destination described by an >> LSA is unreachable. Used in summary-LSAs and AS-external-LSAs >> >> I want to clarify the meaning of unreachable in LSifinity, >> Assume that a node advertise specific route of 1.1.1.1/32, and an >> aggregate route 1.1.0.0/16 is configured. >> This node should premature aging of the 1.1.1.1/32 LSA. >> If this node using LSInfinity metric instead of prematuring aging, route >> 1.1.1.1/32 is still reachable. >> Therefore, the "unreachable" described by LSifinity is not really >> unreachable. >> >> If your OSPF implementation includes unreachable LSAs in the summary cost >> computation, it is indeed broken. >> >> Thanks, >> Acee >> >> Thanks >> Zhibo hu >> >>> -Original Message- >>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak >>> Sent: Wednesday, October 5, 2022 5:32 PM >>> To: lsr@ietf.org >>> Subject: [Lsr] RFC 8362 and LSInfinity >>> >>> Hi Folks, >>> >>> metric of LSInfinity (0xFF) has been defined in RFC2328: >>> >>> LSInfinity >>>The metric value indicating that the destination described by an >>>LSA is unreachable. Used in summary-LSAs and AS-external-LSAs >>> as >>>an alternative to premature aging (see Section 14.1). It is >>>defined to be the 24-bit binary value of all ones: 0xff. >>> >>> RFC5340 inherited it from RFC2328: >>> >>> Appendix B. Architectural Constants >>> >>> Architectural constants for the OSPF protocol are defined in >>> Appendix >>> B of [OSPFV2]. The only difference for OSPF for IPv6 is that >>> DefaultDestination is encoded as a prefix with length 0 (see >>> Appendix A.4.1). >>> >>> Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix >>> reachability, so the LSInfinity was not applicable for intra-area prefixes. >>> >>> RFC8362 defines 24-bit metric for all prefix reachability TLVs - >>> Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV. >>> Al > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] RFC 8362 and LSInfinity
Hi, Acee and Peter: I think you all misunderstood the intent of his scenario. The correct understanding are the followings: 1) When aggregate route is configured in the ABR, the specified detail route should be withdrawn. 2) ABR can withdraw the advertised LSA that describes the specific detail route, via premature mechanism(MaxAge or LSInfinity, the former is preferred according to RFC2328) 3) But, withdrawn such specific LSA doesn’t mean the corresponding detail route unreachable——This destination can be reached via the aggregate route advertised by ABR instead. This is the original usage of LSInfinity defined in RFC2327. It should be expanded further. How to apply it in RFC8362 is another issue, as indicated my responses in another thread. In summary, again, we should constrain or depreciate the confusion usages of LSInfinity. Aijun Wang China Telecom > On Oct 13, 2022, at 18:07, Acee Lindem (acee) > wrote: > > Hi Zhibo, > > On 10/13/22, 2:26 AM, "Lsr on behalf of Huzhibo" behalf of huzhibo=40huawei@dmarc.ietf.org> wrote: > >Hi LSR: > >LSInfinity >The metric value indicating that the destination described by an >LSA is unreachable. Used in summary-LSAs and AS-external-LSAs > >I want to clarify the meaning of unreachable in LSifinity, >Assume that a node advertise specific route of 1.1.1.1/32, and an > aggregate route 1.1.0.0/16 is configured. >This node should premature aging of the 1.1.1.1/32 LSA. >If this node using LSInfinity metric instead of prematuring aging, route > 1.1.1.1/32 is still reachable. >Therefore, the "unreachable" described by LSifinity is not really > unreachable. > > If your OSPF implementation includes unreachable LSAs in the summary cost > computation, it is indeed broken. > > Thanks, > Acee > >Thanks >Zhibo hu > >> -Original Message- >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak >> Sent: Wednesday, October 5, 2022 5:32 PM >> To: lsr@ietf.org >> Subject: [Lsr] RFC 8362 and LSInfinity >> >> Hi Folks, >> >> metric of LSInfinity (0xFF) has been defined in RFC2328: >> >> LSInfinity >> The metric value indicating that the destination described by an >> LSA is unreachable. Used in summary-LSAs and AS-external-LSAs >> as >> an alternative to premature aging (see Section 14.1). It is >> defined to be the 24-bit binary value of all ones: 0xff. >> >> RFC5340 inherited it from RFC2328: >> >> Appendix B. Architectural Constants >> >>Architectural constants for the OSPF protocol are defined in >> Appendix >>B of [OSPFV2]. The only difference for OSPF for IPv6 is that >>DefaultDestination is encoded as a prefix with length 0 (see >>Appendix A.4.1). >> >> Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix >> reachability, so the LSInfinity was not applicable for intra-area prefixes. >> >> RFC8362 defines 24-bit metric for all prefix reachability TLVs - >> Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV. >> Al ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Robert Wilton's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)
Hi Dhruv, Sorry for being slow. Yes, these changes look fine. Thanks for accommodating my concerns. I’ve cleared my discuss. Regards, Rob From: iesg On Behalf Of Dhruv Dhody Sent: 05 October 2022 14:03 To: Rob Wilton (rwilton) Cc: The IESG ; draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) ; p...@ietf.org Subject: Re: Robert Wilton's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT) Hi Robert, Thanks for your review. The working copy is at - TXT - https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt DIFF - https://www.ietf.org/rfcdiff?url1=draft-ietf-lsr-pce-discovery-security-support-11=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt On Tue, Oct 4, 2022 at 10:17 PM Robert Wilton via Datatracker mailto:nore...@ietf.org>> wrote: Robert Wilton has entered the following ballot position for draft-ietf-lsr-pce-discovery-security-support-11: Discuss 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ -- DISCUSS: -- Hi, Sorry for the discuss, but I find a couple of specification aspects of this draft to be unclear enough that I think that they probably warrant a discuss, hopefully easy to explain or resolve: In section 3.2, it wasn't clear to me exactly where I find what the Key-Id is. I suspect that this is probably referring to "KeyId" in rfc5925. If so, I think that would be emphasizing. Dhruv: Made this change - The KEY-ID sub-TLV specifies an identifier that can be used by the PCC to identify the TCP-AO key [RFC5925] (referred to as KeyID). In section 3.3, it wasn't clear to me what the Key chain name is, or what exactly it refers to. Is this referring to a local key-chain name installed in a YANG Keystore (given that there is a reference to RFC8177) or something else. Either way, I think that expanding on the description here would probably be very beneficial. Dhruv: Here is the updated text - The KEY-CHAIN-NAME sub-TLV specifies a keychain name that can be used by the PCC to identify the keychain. The keychain name could be manually configured via CLI or installed in the YANG datastore (see [RFC8177]) at the PCC. -- COMMENT: -- One minor comment. I noted that the description of the Key-Id slightly differed for the OSPF encoding vs ISIS encoding and I wanted to check that the difference was intentional. Dhruv: Yes, this is intentional as padding rules are different between OSPF and IS-IS. See this email - https://mailarchive.ietf.org/arch/msg/lsr/T9OLjPkjcvOViHXOZGCJYsi8OJ4/ Thanks! Dhruv Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-pce-discovery-security-support-13: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-pce-discovery-security-support-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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ -- COMMENT: -- Discuss cleared, thanks for accommodating my concerns. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] RFC 8362 and LSInfinity
Hi Zhibo, On 10/13/22, 2:26 AM, "Lsr on behalf of Huzhibo" wrote: Hi LSR: LSInfinity The metric value indicating that the destination described by an LSA is unreachable. Used in summary-LSAs and AS-external-LSAs I want to clarify the meaning of unreachable in LSifinity, Assume that a node advertise specific route of 1.1.1.1/32, and an aggregate route 1.1.0.0/16 is configured. This node should premature aging of the 1.1.1.1/32 LSA. If this node using LSInfinity metric instead of prematuring aging, route 1.1.1.1/32 is still reachable. Therefore, the "unreachable" described by LSifinity is not really unreachable. If your OSPF implementation includes unreachable LSAs in the summary cost computation, it is indeed broken. Thanks, Acee Thanks Zhibo hu > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak > Sent: Wednesday, October 5, 2022 5:32 PM > To: lsr@ietf.org > Subject: [Lsr] RFC 8362 and LSInfinity > > Hi Folks, > > metric of LSInfinity (0xFF) has been defined in RFC2328: > > LSInfinity > The metric value indicating that the destination described by an > LSA is unreachable. Used in summary-LSAs and AS-external-LSAs > as > an alternative to premature aging (see Section 14.1). It is > defined to be the 24-bit binary value of all ones: 0xff. > > RFC5340 inherited it from RFC2328: > > Appendix B. Architectural Constants > > Architectural constants for the OSPF protocol are defined in > Appendix > B of [OSPFV2]. The only difference for OSPF for IPv6 is that > DefaultDestination is encoded as a prefix with length 0 (see > Appendix A.4.1). > > Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix > reachability, so the LSInfinity was not applicable for intra-area prefixes. > > RFC8362 defines 24-bit metric for all prefix reachability TLVs - > Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV. > Although it is silent about the LSInfinity as such, it is assumed that such > metric means unreachability for Inter-Area-Prefix TLV and External-Prefix > TLV. Given that Intra-Area-Prefix TLV now has 24 bits metric as well, it > would make sense to define the LSInfinity as unreachable for > Intra-Area-Prefix TLV as well. > > Would anyone object such a clarification in RFC8362? > > thanks, > Peter > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] RFC 8362 and LSInfinity
Zhibo, On 13/10/2022 08:26, Huzhibo wrote: Hi LSR: LSInfinity The metric value indicating that the destination described by an LSA is unreachable. Used in summary-LSAs and AS-external-LSAs I want to clarify the meaning of unreachable in LSifinity, Assume that a node advertise specific route of 1.1.1.1/32, and an aggregate route 1.1.0.0/16 is configured. This node should premature aging of the 1.1.1.1/32 LSA. If this node using LSInfinity metric instead of prematuring aging, route 1.1.1.1/32 is still reachable. no, it is not. Peter Therefore, the "unreachable" described by LSifinity is not really unreachable. Thanks Zhibo hu -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak Sent: Wednesday, October 5, 2022 5:32 PM To: lsr@ietf.org Subject: [Lsr] RFC 8362 and LSInfinity Hi Folks, metric of LSInfinity (0xFF) has been defined in RFC2328: LSInfinity The metric value indicating that the destination described by an LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as an alternative to premature aging (see Section 14.1). It is defined to be the 24-bit binary value of all ones: 0xff. RFC5340 inherited it from RFC2328: Appendix B. Architectural Constants Architectural constants for the OSPF protocol are defined in Appendix B of [OSPFV2]. The only difference for OSPF for IPv6 is that DefaultDestination is encoded as a prefix with length 0 (see Appendix A.4.1). Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix reachability, so the LSInfinity was not applicable for intra-area prefixes. RFC8362 defines 24-bit metric for all prefix reachability TLVs - Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV. Although it is silent about the LSInfinity as such, it is assumed that such metric means unreachability for Inter-Area-Prefix TLV and External-Prefix TLV. Given that Intra-Area-Prefix TLV now has 24 bits metric as well, it would make sense to define the LSInfinity as unreachable for Intra-Area-Prefix TLV as well. Would anyone object such a clarification in RFC8362? thanks, Peter ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] RFC 8362 and LSInfinity
Acee: The reason that the operator set the metric to one large enough value, is to let the associated route be the non-optimal selection, not let its unreachable. Because there are normally several links away from the ABR to the advertised router which is connected directly the prefix that has such large value metric, it is easily and very possibly that the metric of the summary LSA reaches the so-called LSInfinity and lead to the abnormal behavior within the network. Then, it's time to correct the misstatement within RFC2328, and remove the LSInfinity definition. Such work has been done in https://www.rfc-editor.org/rfc/rfc6987#appendix-A "In addition to editorial updates, this document defines a new architectural constant (MaxLinkMetric in Section 3) to eliminate any confusion about the interpretation of LSInfinity. It also incorporates and explains the use of the R-bit [RFC5340] as a solution to the problem addressed in the text." Best Regards Aijun Wang China Telecom -Original Message- From: lsr-boun...@ietf.org On Behalf Of Acee Lindem (acee) Sent: Wednesday, October 12, 2022 10:07 PM To: Aijun Wang Cc: Peter Psenak (ppsenak) ; Ketan Talaulikar ; lsr@ietf.org Subject: Re: [Lsr] RFC 8362 and LSInfinity Hi Aijun, On 10/12/22, 9:58 AM, "Aijun Wang" wrote: Hi, Acee: Let me give you one more concrete example: The metric of one prefix P is set to 0xFE(not LSInfinity, it can also be other large value), and this prefix is attached at one router that has the link cost 1 to ABR, what the value for the ABR to advertise for this Prefixes P into other attached area as one summary prefix? It's obvious you wouldn’t configure metrics that large unless you were trying to accomplish some prefix reachability scoping (which I wouldn't recommend by the way). Acee Aijun Wang China Telecom > On Oct 12, 2022, at 18:22, Acee Lindem (acee) wrote: > > > > On 10/12/22, 2:31 AM, "Lsr on behalf of Aijun Wang" wrote: > >Hi, Acee: > >Let me state some points more clearly: >1) The LSInfinity is defined almost 30 years, but it is not applied/deployed within the network about 30 years, why to deprecate it? >2) RFC8362 say nothing about LSInifinity, only RFC5340 says it inherits the definition from RFC2328. >3) It is problematic to define again the LSInifinity within RFC8362, as the value of 0xff, because the metric of the normal summary prefixes advertised by ABR may reach this predefined value. > > This is not problematic. Only unreachable prefixes for an algorithm will have a metric of LSInfinity and will, hence, be unreachable and will not contribute to the cost of any summary prefixes. > > Thanks, > Acee > >The most important point is that there is reasonable/sound reason to define such value for its special handling. > >Best Regards > >Aijun Wang >China Telecom > > >-Original Message- >From: lsr-boun...@ietf.org On Behalf Of Acee Lindem (acee) >Sent: Tuesday, October 11, 2022 11:20 PM >To: Peter Psenak (ppsenak) ; Aijun Wang ; 'Ketan Talaulikar' >Cc: lsr@ietf.org >Subject: Re: [Lsr] RFC 8362 and LSInfinity > >Hi Aijun, > >After almost 30 years, we're not going to deprecate OSPF LSInfinity based on your opinion. > >Please be specific as to what you feel is problematic with usage in the 24-bit metric in the E-Intra-Area-Prefix LSA. > >Thanks, >Acee > >On 10/11/22, 12:09 AM, "Peter Psenak" wrote: > >Aijun, > >>On 11/10/2022 05:44, Aijun Wang wrote: >> Hi, Peter: >> >> Let's focus on OSPF itself then. >> >> In OSPFv2(RFC2328) and OSPFv3(RFC5340), the metric length for the link or intra-area prefix is 16 bit; but the metric length for the summary LSA/inter-area is 24bit. >> There will be no problem to define the LSInfinity for the summary LSA as 0xFF( although the usages of such definition is doubtful and should be revaluatedfor example, is there any real deployment for the mentioned possible usages?) >> >> But for OSPFv3(RFC8362), if you still define the LSInifiity as 0xFF, there is possible the cost to some prefixes advertised by the ABR reach this value, it is unreasonable to consider such prefixes are unreachable. Then, rely on such value of the metric to determine the reachability is problematic. > >again, there is no problem. For RFC8362 0xFF already means >LSInfinity for inter/external prefixes. All we propose is to define the >same meaning for that metric for intra-area prefixes as it is 24 bits as >well. > >Peter > >> >> We should decrease or abandon such unsound
Re: [Lsr] RFC 8362 and LSInfinity
And, in https://www.rfc-editor.org/rfc/rfc2328.html#page-135 (Section 12.4.3. Summary-LSAs), it states clearly: "If a router advertises a summary-LSA for a destination which then becomes unreachable, the router must then flush the LSA from the routing domain by setting its age to MaxAge and reflooding (see Section 14.1)."Section 14.1 is about how to "Premature aging of LSAs" Then, if you want to invalidate one of your advertised LSA, you should use MaxAge, not LSInfinity. The LSInfinity, should be limited it's the original meaningthe last resort of the route to the prefixes. Best Regards Aijun Wang China Telecom -Original Message- From: lsr-boun...@ietf.org On Behalf Of Huzhibo Sent: Thursday, October 13, 2022 2:26 PM To: Peter Psenak ; lsr@ietf.org Subject: Re: [Lsr] RFC 8362 and LSInfinity Hi LSR: LSInfinity The metric value indicating that the destination described by an LSA is unreachable. Used in summary-LSAs and AS-external-LSAs I want to clarify the meaning of unreachable in LSifinity, Assume that a node advertise specific route of 1.1.1.1/32, and an aggregate route 1.1.0.0/16 is configured. This node should premature aging of the 1.1.1.1/32 LSA. If this node using LSInfinity metric instead of prematuring aging, route 1.1.1.1/32 is still reachable. Therefore, the "unreachable" described by LSifinity is not really unreachable. Thanks Zhibo hu > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak > Sent: Wednesday, October 5, 2022 5:32 PM > To: lsr@ietf.org > Subject: [Lsr] RFC 8362 and LSInfinity > > Hi Folks, > > metric of LSInfinity (0xFF) has been defined in RFC2328: > > LSInfinity > The metric value indicating that the destination described by an > LSA is unreachable. Used in summary-LSAs and AS-external-LSAs > as > an alternative to premature aging (see Section 14.1). It is > defined to be the 24-bit binary value of all ones: 0xff. > > RFC5340 inherited it from RFC2328: > > Appendix B. Architectural Constants > > Architectural constants for the OSPF protocol are defined in > Appendix > B of [OSPFV2]. The only difference for OSPF for IPv6 is that > DefaultDestination is encoded as a prefix with length 0 (see > Appendix A.4.1). > > Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix > reachability, so the LSInfinity was not applicable for intra-area prefixes. > > RFC8362 defines 24-bit metric for all prefix reachability TLVs - > Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV. > Although it is silent about the LSInfinity as such, it is assumed that > such metric means unreachability for Inter-Area-Prefix TLV and > External-Prefix TLV. Given that Intra-Area-Prefix TLV now has 24 bits > metric as well, it would make sense to define the LSInfinity as > unreachable for Intra-Area-Prefix TLV as well. > > Would anyone object such a clarification in RFC8362? > > thanks, > Peter > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] RFC 8362 and LSInfinity
Hi LSR: LSInfinity The metric value indicating that the destination described by an LSA is unreachable. Used in summary-LSAs and AS-external-LSAs I want to clarify the meaning of unreachable in LSifinity, Assume that a node advertise specific route of 1.1.1.1/32, and an aggregate route 1.1.0.0/16 is configured. This node should premature aging of the 1.1.1.1/32 LSA. If this node using LSInfinity metric instead of prematuring aging, route 1.1.1.1/32 is still reachable. Therefore, the "unreachable" described by LSifinity is not really unreachable. Thanks Zhibo hu > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak > Sent: Wednesday, October 5, 2022 5:32 PM > To: lsr@ietf.org > Subject: [Lsr] RFC 8362 and LSInfinity > > Hi Folks, > > metric of LSInfinity (0xFF) has been defined in RFC2328: > > LSInfinity > The metric value indicating that the destination described by an > LSA is unreachable. Used in summary-LSAs and AS-external-LSAs > as > an alternative to premature aging (see Section 14.1). It is > defined to be the 24-bit binary value of all ones: 0xff. > > RFC5340 inherited it from RFC2328: > > Appendix B. Architectural Constants > > Architectural constants for the OSPF protocol are defined in > Appendix > B of [OSPFV2]. The only difference for OSPF for IPv6 is that > DefaultDestination is encoded as a prefix with length 0 (see > Appendix A.4.1). > > Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix > reachability, so the LSInfinity was not applicable for intra-area prefixes. > > RFC8362 defines 24-bit metric for all prefix reachability TLVs - > Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV. > Although it is silent about the LSInfinity as such, it is assumed that such > metric means unreachability for Inter-Area-Prefix TLV and External-Prefix > TLV. Given that Intra-Area-Prefix TLV now has 24 bits metric as well, it > would make sense to define the LSInfinity as unreachable for > Intra-Area-Prefix TLV as well. > > Would anyone object such a clarification in RFC8362? > > thanks, > Peter > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
