Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
I think it will work for me as well -- thanks! -Ben On Tue, May 26, 2020 at 08:03:17AM -0700, Alvaro Retana wrote: > Just for the record, I’m ok with the latest text. > > Thanks! > > Alvaro. > > On May 26, 2020 at 10:25:38 AM, Peter Psenak (ppse...@cisco.com) wrote: > > Hi Acee, > > updated the text based on your comments. > > thanks, > Peter > > > On 26/05/2020 16:07, Acee Lindem (acee) wrote: > > Hi Peter, > > > > This is in response to the previous Email on your suggested text. > > > > On 5/26/20, 4:26 AM, "Peter Psenak" wrote: > > > > Hi Alvaro, > > > > please see inline (##PP) > > > > On 22/05/2020 16:59, Alvaro Retana wrote: > > > On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote: > > > > > > > > > Peter: > > > > > > Hi! > > > > > > > > >> With respect to Alvaro's clarification, your answer for (1) makes > sense; > > >> thanks! I think Alvaro has offered to help work out what (if any) > > >> additional text we might want to be sure that the answer to (2) is > clear in > > >> the document. > > > > > > I think that #1 is where some clarification could be useful. :-) > > > > > > > > > I'm including both ISIS and OSPF suggestions below to consolidate the > > > discussion. > > > > > > > > > ... > > >>> My interpretation of Ben's question is two-fold: > > >>> > > >>> (1) Would ISIS routers normally propagate the information to a > > >>> different level? The ELC is a new prefix attribute flag -- are prefix > > >>> attributes always propagated (unchanged) to other levels? If so, then > > >>> the requirement (MUST) is not needed. My reading of rfc7794 is that > > >>> the propagation is optional... > > >> > > >> depends on the attribute or a bit. Some are propagated some are not. > > >> That's why we are saying this one MUST be preserved. > > > > > > Right. > > > > > > For ISIS I think the current text is in line with the specification of > > > the other bits in rfc7794. No changes are needed. > > > > > > If anything, you may want to change the order of this sentence to > > > address Ben's comment: > > > > > > OLD> > > > When a router propagates a prefix between ISIS levels ([RFC5302], it > > > MUST preserve the ELC signaling for this prefix. > > > > > > NEW> > > > The ELC signaling MUST be preserved when a router propagates a prefix > > > between ISIS levels ([RFC5302]). > > > > > > [Similar for OSPF.] > > > > ##PP > > done. > > > > > > > > > > > > > > > > I think that for OSPF it is not that simple... > > > > > > For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix > > > Opaque LSA depends on the scope of the advertised prefixes", which I > > > assume means that for intra-area prefixes the scope will be > > > area-local...so the ABR wouldn't simply propagate it; it would have to > > > originate a new LSA. > > > > ##PP > > correct. It is always a new LSA that ABR needs to generate. Here it's > > actually two LSAs. > > > > > > > > Suggestion (Add to 3.1)> > > > When an OSPFv2 Area Border Router (ABR) distributes information between > > > connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque > LSA > > > [RFC7684] including the received ELC setting. If the received > information > > > is included in an LSA with an AS-wide scope, then the new LSA is not > needed. > > > > Here's my suggestion for OSPFv2 ABR related text: > > > > "The ELC signaling MUST be preserved when an OSPF Area Border Router > > (ABR) distributes information between connected areas. To do so, ABR > > MUST originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including > > the received ELC setting." > > > > Ok - I change "connected areas" to "areas" and "ABR MUST" to "an ABR > MUST". > > > > Here's my suggested text for OSPFv2 ASBR case: > > > > "When an OSPF Autonomous System Boundary Router (ASBR) redistributes a > > prefix from another instance of OSPF or from some other protocol, it > > SHOULD preserve the ELC signaling for the prefix if it exists. To do so, > > ASBR SHOULD originate Extended Prefix Opaque LSA [RFC7684] including the > > ELC setting of the redistributed prefix. The flooding scope of the > > Extended Prefix Opaque LSA MUST match the flooding scope of the LSA that > > ASBR originates as a result of the redistribution. The exact mechanism > > used to exchange ELC between protocol instances on the ASBR is outside > > of the scope of this document." > > > > Sure - replace "ASBR SHOULD" with "an ASBR SHOULD", "that ASBR" with > "that an ASBR", and "the ASBR is" with "an ASBR is" to be consistent. > > Also, "originate Extended" with "originate an Extended". > > > > > > > > > > > > > > > For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find > > > anything in rfc5340 saying that the received values should be copied > > > into the Inter-Area-Prefix-LSA (nor that they should not). > > > > > > Suggestion (Add to 3.2)> > > > When an OSPFv3 Area Border Router (ABR) distributes information between > > > connected areas, the setting of the ELC Flag in the >
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
Just for the record, I’m ok with the latest text. Thanks! Alvaro. On May 26, 2020 at 10:25:38 AM, Peter Psenak (ppse...@cisco.com) wrote: Hi Acee, updated the text based on your comments. thanks, Peter On 26/05/2020 16:07, Acee Lindem (acee) wrote: > Hi Peter, > > This is in response to the previous Email on your suggested text. > > On 5/26/20, 4:26 AM, "Peter Psenak" wrote: > > Hi Alvaro, > > please see inline (##PP) > > On 22/05/2020 16:59, Alvaro Retana wrote: > > On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote: > > > > > > Peter: > > > > Hi! > > > > > >> With respect to Alvaro's clarification, your answer for (1) makes sense; > >> thanks! I think Alvaro has offered to help work out what (if any) > >> additional text we might want to be sure that the answer to (2) is clear in > >> the document. > > > > I think that #1 is where some clarification could be useful. :-) > > > > > > I'm including both ISIS and OSPF suggestions below to consolidate the > > discussion. > > > > > > ... > >>> My interpretation of Ben's question is two-fold: > >>> > >>> (1) Would ISIS routers normally propagate the information to a > >>> different level? The ELC is a new prefix attribute flag -- are prefix > >>> attributes always propagated (unchanged) to other levels? If so, then > >>> the requirement (MUST) is not needed. My reading of rfc7794 is that > >>> the propagation is optional... > >> > >> depends on the attribute or a bit. Some are propagated some are not. > >> That's why we are saying this one MUST be preserved. > > > > Right. > > > > For ISIS I think the current text is in line with the specification of > > the other bits in rfc7794. No changes are needed. > > > > If anything, you may want to change the order of this sentence to > > address Ben's comment: > > > > OLD> > > When a router propagates a prefix between ISIS levels ([RFC5302], it > > MUST preserve the ELC signaling for this prefix. > > > > NEW> > > The ELC signaling MUST be preserved when a router propagates a prefix > > between ISIS levels ([RFC5302]). > > > > [Similar for OSPF.] > > ##PP > done. > > > > > > > > > > I think that for OSPF it is not that simple... > > > > For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix > > Opaque LSA depends on the scope of the advertised prefixes", which I > > assume means that for intra-area prefixes the scope will be > > area-local...so the ABR wouldn't simply propagate it; it would have to > > originate a new LSA. > > ##PP > correct. It is always a new LSA that ABR needs to generate. Here it's > actually two LSAs. > > > > > Suggestion (Add to 3.1)> > > When an OSPFv2 Area Border Router (ABR) distributes information between > > connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA > > [RFC7684] including the received ELC setting. If the received information > > is included in an LSA with an AS-wide scope, then the new LSA is not needed. > > Here's my suggestion for OSPFv2 ABR related text: > > "The ELC signaling MUST be preserved when an OSPF Area Border Router > (ABR) distributes information between connected areas. To do so, ABR > MUST originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including > the received ELC setting." > > Ok - I change "connected areas" to "areas" and "ABR MUST" to "an ABR MUST". > > Here's my suggested text for OSPFv2 ASBR case: > > "When an OSPF Autonomous System Boundary Router (ASBR) redistributes a > prefix from another instance of OSPF or from some other protocol, it > SHOULD preserve the ELC signaling for the prefix if it exists. To do so, > ASBR SHOULD originate Extended Prefix Opaque LSA [RFC7684] including the > ELC setting of the redistributed prefix. The flooding scope of the > Extended Prefix Opaque LSA MUST match the flooding scope of the LSA that > ASBR originates as a result of the redistribution. The exact mechanism > used to exchange ELC between protocol instances on the ASBR is outside > of the scope of this document." > > Sure - replace "ASBR SHOULD" with "an ASBR SHOULD", "that ASBR" with "that an ASBR", and "the ASBR is" with "an ASBR is" to be consistent. > Also, "originate Extended" with "originate an Extended". > > > > > > > > > For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find > > anything in rfc5340 saying that the received values should be copied > > into the Inter-Area-Prefix-LSA (nor that they should not). > > > > Suggestion (Add to 3.2)> > > When an OSPFv3 Area Border Router (ABR) distributes information between > > connected areas, the setting of the ELC Flag in the Inter-Area-Prefix-LSA > > MUST be the same as the received value. > > Here's my suggestion for OSPFv3 ABR and ASBR: > > "The ELC signaling MUST be preserved when an OSPFv3 Area Border Router > (ABR) distributes information between connected areas. The setting of > the ELC Flag in the Inter-Area-Prefix-LSA [RFC5340] or in the > Inter-Area-Prefix TLV [RFC8362], generated by ABR, MUST be the same as > the value the ELC Flag
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
Hi Peter, Thanks - hopefully this will more than satisfy Ben's discuss. Acee On 5/26/20, 10:25 AM, "Peter Psenak" wrote: Hi Acee, updated the text based on your comments. thanks, Peter On 26/05/2020 16:07, Acee Lindem (acee) wrote: > Hi Peter, > > This is in response to the previous Email on your suggested text. > > On 5/26/20, 4:26 AM, "Peter Psenak" wrote: > > Hi Alvaro, > > please see inline (##PP) > > On 22/05/2020 16:59, Alvaro Retana wrote: > > On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote: > > > > > > Peter: > > > > Hi! > > > > > >> With respect to Alvaro's clarification, your answer for (1) makes sense; > >> thanks! I think Alvaro has offered to help work out what (if any) > >> additional text we might want to be sure that the answer to (2) is clear in > >> the document. > > > > I think that #1 is where some clarification could be useful. :-) > > > > > > I'm including both ISIS and OSPF suggestions below to consolidate the > > discussion. > > > > > > ... > >>> My interpretation of Ben's question is two-fold: > >>> > >>> (1) Would ISIS routers normally propagate the information to a > >>> different level? The ELC is a new prefix attribute flag -- are prefix > >>> attributes always propagated (unchanged) to other levels? If so, then > >>> the requirement (MUST) is not needed. My reading of rfc7794 is that > >>> the propagation is optional... > >> > >> depends on the attribute or a bit. Some are propagated some are not. > >> That's why we are saying this one MUST be preserved. > > > > Right. > > > > For ISIS I think the current text is in line with the specification of > > the other bits in rfc7794. No changes are needed. > > > > If anything, you may want to change the order of this sentence to > > address Ben's comment: > > > > OLD> > > When a router propagates a prefix between ISIS levels ([RFC5302], it > > MUST preserve the ELC signaling for this prefix. > > > > NEW> > > The ELC signaling MUST be preserved when a router propagates a prefix > > between ISIS levels ([RFC5302]). > > > > [Similar for OSPF.] > > ##PP > done. > > > > > > > > > > I think that for OSPF it is not that simple... > > > > For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix > > Opaque LSA depends on the scope of the advertised prefixes", which I > > assume means that for intra-area prefixes the scope will be > > area-local...so the ABR wouldn't simply propagate it; it would have to > > originate a new LSA. > > ##PP > correct. It is always a new LSA that ABR needs to generate. Here it's > actually two LSAs. > > > > > Suggestion (Add to 3.1)> > > When an OSPFv2 Area Border Router (ABR) distributes information between > > connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA > > [RFC7684] including the received ELC setting. If the received information > > is included in an LSA with an AS-wide scope, then the new LSA is not needed. > > Here's my suggestion for OSPFv2 ABR related text: > > "The ELC signaling MUST be preserved when an OSPF Area Border Router > (ABR) distributes information between connected areas. To do so, ABR > MUST originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including > the received ELC setting." > > Ok - I change "connected areas" to "areas" and "ABR MUST" to "an ABR MUST". > > Here's my suggested text for OSPFv2 ASBR case: > > "When an OSPF Autonomous System Boundary Router (ASBR) redistributes a > prefix from another instance of OSPF or from some other protocol, it > SHOULD preserve the ELC signaling for the prefix if it exists. To do so, > ASBR SHOULD originate Extended Prefix Opaque LSA [RFC7684] including the > ELC setting of the redistributed prefix. The flooding scope of the > Extended Prefix Opaque LSA MUST match the flooding scope of the LSA that > ASBR originates as a result of the redistribution. The exact mechanism > used to exchange ELC between protocol instances on the ASBR is outside > of the scope of this document." > > Sure - replace "ASBR SHOULD" with "an ASBR SHOULD", "that
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
Hi Acee, updated the text based on your comments. thanks, Peter On 26/05/2020 16:07, Acee Lindem (acee) wrote: Hi Peter, This is in response to the previous Email on your suggested text. On 5/26/20, 4:26 AM, "Peter Psenak" wrote: Hi Alvaro, please see inline (##PP) On 22/05/2020 16:59, Alvaro Retana wrote: > On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote: > > > Peter: > > Hi! > > >> With respect to Alvaro's clarification, your answer for (1) makes sense; >> thanks! I think Alvaro has offered to help work out what (if any) >> additional text we might want to be sure that the answer to (2) is clear in >> the document. > > I think that #1 is where some clarification could be useful. :-) > > > I'm including both ISIS and OSPF suggestions below to consolidate the > discussion. > > > ... >>> My interpretation of Ben's question is two-fold: >>> >>> (1) Would ISIS routers normally propagate the information to a >>> different level? The ELC is a new prefix attribute flag -- are prefix >>> attributes always propagated (unchanged) to other levels? If so, then >>> the requirement (MUST) is not needed. My reading of rfc7794 is that >>> the propagation is optional... >> >> depends on the attribute or a bit. Some are propagated some are not. >> That's why we are saying this one MUST be preserved. > > Right. > > For ISIS I think the current text is in line with the specification of > the other bits in rfc7794. No changes are needed. > > If anything, you may want to change the order of this sentence to > address Ben's comment: > > OLD> > When a router propagates a prefix between ISIS levels ([RFC5302], it > MUST preserve the ELC signaling for this prefix. > > NEW> > The ELC signaling MUST be preserved when a router propagates a prefix > between ISIS levels ([RFC5302]). > > [Similar for OSPF.] ##PP done. > > > > I think that for OSPF it is not that simple... > > For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix > Opaque LSA depends on the scope of the advertised prefixes", which I > assume means that for intra-area prefixes the scope will be > area-local...so the ABR wouldn't simply propagate it; it would have to > originate a new LSA. ##PP correct. It is always a new LSA that ABR needs to generate. Here it's actually two LSAs. > > Suggestion (Add to 3.1)> > When an OSPFv2 Area Border Router (ABR) distributes information between > connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA > [RFC7684] including the received ELC setting. If the received information > is included in an LSA with an AS-wide scope, then the new LSA is not needed. Here's my suggestion for OSPFv2 ABR related text: "The ELC signaling MUST be preserved when an OSPF Area Border Router (ABR) distributes information between connected areas. To do so, ABR MUST originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including the received ELC setting." Ok - I change "connected areas" to "areas" and "ABR MUST" to "an ABR MUST". Here's my suggested text for OSPFv2 ASBR case: "When an OSPF Autonomous System Boundary Router (ASBR) redistributes a prefix from another instance of OSPF or from some other protocol, it SHOULD preserve the ELC signaling for the prefix if it exists. To do so, ASBR SHOULD originate Extended Prefix Opaque LSA [RFC7684] including the ELC setting of the redistributed prefix. The flooding scope of the Extended Prefix Opaque LSA MUST match the flooding scope of the LSA that ASBR originates as a result of the redistribution. The exact mechanism used to exchange ELC between protocol instances on the ASBR is outside of the scope of this document." Sure - replace "ASBR SHOULD" with "an ASBR SHOULD", "that ASBR" with "that an ASBR", and "the ASBR is" with "an ASBR is" to be consistent. Also, "originate Extended" with "originate an Extended". > > > For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find > anything in rfc5340 saying that the received values should be copied > into the Inter-Area-Prefix-LSA (nor that they should not). > > Suggestion (Add to 3.2)> > When an OSPFv3 Area Border Router (ABR) distributes information between > connected areas, the setting of the ELC Flag in the Inter-Area-Prefix-LSA > MUST be the same as the received value. Here's my suggestion for OSPFv3 ABR and ASBR: "The ELC signaling MUST be preserved when an OSPFv3 Area Border Router (ABR) distributes information between connected
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
Hi Peter, On 5/26/20, 8:22 AM, "Peter Psenak" wrote: Hi Acee, have you looked at the texts that I suggested in my response to Alvaro earlier today? I found it - let me reply to that Email. Thanks, Acee Please see inline: On 26/05/2020 13:49, Acee Lindem (acee) wrote: > Hi Alvaro, > > See inline. > > On 5/22/20, 10:59 AM, "Alvaro Retana" wrote: > > On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote: > > > Peter: > > Hi! > > > > With respect to Alvaro's clarification, your answer for (1) makes sense; > > thanks! I think Alvaro has offered to help work out what (if any) > > additional text we might want to be sure that the answer to (2) is clear in > > the document. > > I think that #1 is where some clarification could be useful. :-) > > > I'm including both ISIS and OSPF suggestions below to consolidate the > discussion. > > > ... > > > My interpretation of Ben's question is two-fold: > > > > > > (1) Would ISIS routers normally propagate the information to a > > > different level? The ELC is a new prefix attribute flag -- are prefix > > > attributes always propagated (unchanged) to other levels? If so, then > > > the requirement (MUST) is not needed. My reading of rfc7794 is that > > > the propagation is optional... > > > > depends on the attribute or a bit. Some are propagated some are not. > > That's why we are saying this one MUST be preserved. > > Right. > > For ISIS I think the current text is in line with the specification of > the other bits in rfc7794. No changes are needed. > > If anything, you may want to change the order of this sentence to > address Ben's comment: > > OLD> > When a router propagates a prefix between ISIS levels ([RFC5302], it > MUST preserve the ELC signaling for this prefix. > > NEW> > The ELC signaling MUST be preserved when a router propagates a prefix > between ISIS levels ([RFC5302]). > > [Similar for OSPF.] > > > > I think that for OSPF it is not that simple... > > For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix > Opaque LSA depends on the scope of the advertised prefixes", which I > assume means that for intra-area prefixes the scope will be > area-local...so the ABR wouldn't simply propagate it; it would have to > originate a new LSA. > > I agree with the changes but have suggested alternate text. > > Suggestion (Add to 3.1)> > When an OSPFv2 Area Border Router (ABR) distributes information between > connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA > [RFC7684] including the received ELC setting. If the received information > is included in an LSA with an AS-wide scope, then the new LSA is not needed. when would ABR do inter area propagation of what is advertised in AS scope LSA? I can not think of such a case. thanks, Peter > > I'd suggest: > >When an OSPFv2 Area Border Router (ABR) advertises prefix information between >areas and ELC information is was advertised for the prefix in the source area, the >ABR SHOULD originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] propagating >the prefix's source area setting. If the ELC setting, is also advertised in an OSPFv2 >Extended Prefix Opaque LSA with AS-wide scope, the additional LSA origination >Is not needed. > > > For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find > anything in rfc5340 saying that the received values should be copied > into the Inter-Area-Prefix-LSA (nor that they should not). > > Suggestion (Add to 3.2)> > When an OSPFv3 Area Border Router (ABR) distributes information between > connected areas, the setting of the ELC Flag in the Inter-Area-Prefix-LSA > MUST be the same as the received value. > > I'd suggest: > >When an OSPFv3 Area Border Router (ABR) advertises information between >areas, the setting of the ELC flag in the Inter-area-prefix-LSA MUST be the >propagated unchanged. > > Thanks, > Acee > > > > > > > (2) If the propagation is not automatic, and the L1L2 router doesn't > > > support this specification, then what are the drawbacks/failure > > > scenarios? IOW, for multi-level operation is it a requirement that
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
Hi Acee, have you looked at the texts that I suggested in my response to Alvaro earlier today? Please see inline: On 26/05/2020 13:49, Acee Lindem (acee) wrote: Hi Alvaro, See inline. On 5/22/20, 10:59 AM, "Alvaro Retana" wrote: On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote: Peter: Hi! > With respect to Alvaro's clarification, your answer for (1) makes sense; > thanks! I think Alvaro has offered to help work out what (if any) > additional text we might want to be sure that the answer to (2) is clear in > the document. I think that #1 is where some clarification could be useful. :-) I'm including both ISIS and OSPF suggestions below to consolidate the discussion. ... > > My interpretation of Ben's question is two-fold: > > > > (1) Would ISIS routers normally propagate the information to a > > different level? The ELC is a new prefix attribute flag -- are prefix > > attributes always propagated (unchanged) to other levels? If so, then > > the requirement (MUST) is not needed. My reading of rfc7794 is that > > the propagation is optional... > > depends on the attribute or a bit. Some are propagated some are not. > That's why we are saying this one MUST be preserved. Right. For ISIS I think the current text is in line with the specification of the other bits in rfc7794. No changes are needed. If anything, you may want to change the order of this sentence to address Ben's comment: OLD> When a router propagates a prefix between ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix. NEW> The ELC signaling MUST be preserved when a router propagates a prefix between ISIS levels ([RFC5302]). [Similar for OSPF.] I think that for OSPF it is not that simple... For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix Opaque LSA depends on the scope of the advertised prefixes", which I assume means that for intra-area prefixes the scope will be area-local...so the ABR wouldn't simply propagate it; it would have to originate a new LSA. I agree with the changes but have suggested alternate text. Suggestion (Add to 3.1)> When an OSPFv2 Area Border Router (ABR) distributes information between connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including the received ELC setting. If the received information is included in an LSA with an AS-wide scope, then the new LSA is not needed. when would ABR do inter area propagation of what is advertised in AS scope LSA? I can not think of such a case. thanks, Peter I'd suggest: When an OSPFv2 Area Border Router (ABR) advertises prefix information between areas and ELC information is was advertised for the prefix in the source area, the ABR SHOULD originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] propagating the prefix's source area setting. If the ELC setting, is also advertised in an OSPFv2 Extended Prefix Opaque LSA with AS-wide scope, the additional LSA origination Is not needed. For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find anything in rfc5340 saying that the received values should be copied into the Inter-Area-Prefix-LSA (nor that they should not). Suggestion (Add to 3.2)> When an OSPFv3 Area Border Router (ABR) distributes information between connected areas, the setting of the ELC Flag in the Inter-Area-Prefix-LSA MUST be the same as the received value. I'd suggest: When an OSPFv3 Area Border Router (ABR) advertises information between areas, the setting of the ELC flag in the Inter-area-prefix-LSA MUST be the propagated unchanged. Thanks, Acee > > (2) If the propagation is not automatic, and the L1L2 router doesn't > > support this specification, then what are the drawbacks/failure > > scenarios? IOW, for multi-level operation is it a requirement that > > the L1L2 support this specification? > > drawback are identical to what is mentioned in the Security > Considerations section. I think that text is ok. Thanks! Alvaro. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
Hi Alvaro, See inline. On 5/22/20, 10:59 AM, "Alvaro Retana" wrote: On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote: Peter: Hi! > With respect to Alvaro's clarification, your answer for (1) makes sense; > thanks! I think Alvaro has offered to help work out what (if any) > additional text we might want to be sure that the answer to (2) is clear in > the document. I think that #1 is where some clarification could be useful. :-) I'm including both ISIS and OSPF suggestions below to consolidate the discussion. ... > > My interpretation of Ben's question is two-fold: > > > > (1) Would ISIS routers normally propagate the information to a > > different level? The ELC is a new prefix attribute flag -- are prefix > > attributes always propagated (unchanged) to other levels? If so, then > > the requirement (MUST) is not needed. My reading of rfc7794 is that > > the propagation is optional... > > depends on the attribute or a bit. Some are propagated some are not. > That's why we are saying this one MUST be preserved. Right. For ISIS I think the current text is in line with the specification of the other bits in rfc7794. No changes are needed. If anything, you may want to change the order of this sentence to address Ben's comment: OLD> When a router propagates a prefix between ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix. NEW> The ELC signaling MUST be preserved when a router propagates a prefix between ISIS levels ([RFC5302]). [Similar for OSPF.] I think that for OSPF it is not that simple... For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix Opaque LSA depends on the scope of the advertised prefixes", which I assume means that for intra-area prefixes the scope will be area-local...so the ABR wouldn't simply propagate it; it would have to originate a new LSA. I agree with the changes but have suggested alternate text. Suggestion (Add to 3.1)> When an OSPFv2 Area Border Router (ABR) distributes information between connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including the received ELC setting. If the received information is included in an LSA with an AS-wide scope, then the new LSA is not needed. I'd suggest: When an OSPFv2 Area Border Router (ABR) advertises prefix information between areas and ELC information is was advertised for the prefix in the source area, the ABR SHOULD originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] propagating the prefix's source area setting. If the ELC setting, is also advertised in an OSPFv2 Extended Prefix Opaque LSA with AS-wide scope, the additional LSA origination Is not needed. For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find anything in rfc5340 saying that the received values should be copied into the Inter-Area-Prefix-LSA (nor that they should not). Suggestion (Add to 3.2)> When an OSPFv3 Area Border Router (ABR) distributes information between connected areas, the setting of the ELC Flag in the Inter-Area-Prefix-LSA MUST be the same as the received value. I'd suggest: When an OSPFv3 Area Border Router (ABR) advertises information between areas, the setting of the ELC flag in the Inter-area-prefix-LSA MUST be the propagated unchanged. Thanks, Acee > > (2) If the propagation is not automatic, and the L1L2 router doesn't > > support this specification, then what are the drawbacks/failure > > scenarios? IOW, for multi-level operation is it a requirement that > > the L1L2 support this specification? > > drawback are identical to what is mentioned in the Security > Considerations section. I think that text is ok. Thanks! Alvaro. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
Hi Alvaro, please see inline (##PP) On 22/05/2020 16:59, Alvaro Retana wrote: On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote: Peter: Hi! With respect to Alvaro's clarification, your answer for (1) makes sense; thanks! I think Alvaro has offered to help work out what (if any) additional text we might want to be sure that the answer to (2) is clear in the document. I think that #1 is where some clarification could be useful. :-) I'm including both ISIS and OSPF suggestions below to consolidate the discussion. ... My interpretation of Ben's question is two-fold: (1) Would ISIS routers normally propagate the information to a different level? The ELC is a new prefix attribute flag -- are prefix attributes always propagated (unchanged) to other levels? If so, then the requirement (MUST) is not needed. My reading of rfc7794 is that the propagation is optional... depends on the attribute or a bit. Some are propagated some are not. That's why we are saying this one MUST be preserved. Right. For ISIS I think the current text is in line with the specification of the other bits in rfc7794. No changes are needed. If anything, you may want to change the order of this sentence to address Ben's comment: OLD> When a router propagates a prefix between ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix. NEW> The ELC signaling MUST be preserved when a router propagates a prefix between ISIS levels ([RFC5302]). [Similar for OSPF.] ##PP done. I think that for OSPF it is not that simple... For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix Opaque LSA depends on the scope of the advertised prefixes", which I assume means that for intra-area prefixes the scope will be area-local...so the ABR wouldn't simply propagate it; it would have to originate a new LSA. ##PP correct. It is always a new LSA that ABR needs to generate. Here it's actually two LSAs. Suggestion (Add to 3.1)> When an OSPFv2 Area Border Router (ABR) distributes information between connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including the received ELC setting. If the received information is included in an LSA with an AS-wide scope, then the new LSA is not needed. Here's my suggestion for OSPFv2 ABR related text: "The ELC signaling MUST be preserved when an OSPF Area Border Router (ABR) distributes information between connected areas. To do so, ABR MUST originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including the received ELC setting." Here's my suggested text for OSPFv2 ASBR case: "When an OSPF Autonomous System Boundary Router (ASBR) redistributes a prefix from another instance of OSPF or from some other protocol, it SHOULD preserve the ELC signaling for the prefix if it exists. To do so, ASBR SHOULD originate Extended Prefix Opaque LSA [RFC7684] including the ELC setting of the redistributed prefix. The flooding scope of the Extended Prefix Opaque LSA MUST match the flooding scope of the LSA that ASBR originates as a result of the redistribution. The exact mechanism used to exchange ELC between protocol instances on the ASBR is outside of the scope of this document." For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find anything in rfc5340 saying that the received values should be copied into the Inter-Area-Prefix-LSA (nor that they should not). Suggestion (Add to 3.2)> When an OSPFv3 Area Border Router (ABR) distributes information between connected areas, the setting of the ELC Flag in the Inter-Area-Prefix-LSA MUST be the same as the received value. Here's my suggestion for OSPFv3 ABR and ASBR: "The ELC signaling MUST be preserved when an OSPFv3 Area Border Router (ABR) distributes information between connected areas. The setting of the ELC Flag in the Inter-Area-Prefix-LSA [RFC5340] or in the Inter-Area-Prefix TLV [RFC8362], generated by ABR, MUST be the same as the value the ELC Flag associated with the prefix in the source area." "When an OSPFv3 Autonomous System Boundary Router (ASBR) redistributes a prefix from another instance of OSPFv3 or from some other protocol, it SHOULD preserve the ELC signaling for the prefix if it exists. The setting of the ELC Flag in the AS-External-LSA [RFC5340] or in the External-Prefix TLV [RFC8362], generated by ASBR, MUST be the same as the value the ELC Flag associated with the prefix in the source domain. The exact mechanism used to exchange ELC between protocol instances on the ASBR is outside of the scope of this document." thanks, Peter (2) If the propagation is not automatic, and the L1L2 router doesn't support this specification, then what are the drawbacks/failure scenarios? IOW, for multi-level operation is it a requirement that the L1L2 support this specification? drawback are identical to what is mentioned in the Security Considerations section. I think that text
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
On May 21, 2020 at 3:39:03 PM, Benjamin Kaduk wrote: Peter: Hi! > With respect to Alvaro's clarification, your answer for (1) makes sense; > thanks! I think Alvaro has offered to help work out what (if any) > additional text we might want to be sure that the answer to (2) is clear in > the document. I think that #1 is where some clarification could be useful. :-) I'm including both ISIS and OSPF suggestions below to consolidate the discussion. ... > > My interpretation of Ben's question is two-fold: > > > > (1) Would ISIS routers normally propagate the information to a > > different level? The ELC is a new prefix attribute flag -- are prefix > > attributes always propagated (unchanged) to other levels? If so, then > > the requirement (MUST) is not needed. My reading of rfc7794 is that > > the propagation is optional... > > depends on the attribute or a bit. Some are propagated some are not. > That's why we are saying this one MUST be preserved. Right. For ISIS I think the current text is in line with the specification of the other bits in rfc7794. No changes are needed. If anything, you may want to change the order of this sentence to address Ben's comment: OLD> When a router propagates a prefix between ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix. NEW> The ELC signaling MUST be preserved when a router propagates a prefix between ISIS levels ([RFC5302]). [Similar for OSPF.] I think that for OSPF it is not that simple... For OSPFv2: rfc7684 says that the "scope of the OSPFv2 Extended Prefix Opaque LSA depends on the scope of the advertised prefixes", which I assume means that for intra-area prefixes the scope will be area-local...so the ABR wouldn't simply propagate it; it would have to originate a new LSA. Suggestion (Add to 3.1)> When an OSPFv2 Area Border Router (ABR) distributes information between connected areas it SHOULD originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including the received ELC setting. If the received information is included in an LSA with an AS-wide scope, then the new LSA is not needed. For OSPFv3: The PrefixOptions are *in* the LSA, but I couldn't find anything in rfc5340 saying that the received values should be copied into the Inter-Area-Prefix-LSA (nor that they should not). Suggestion (Add to 3.2)> When an OSPFv3 Area Border Router (ABR) distributes information between connected areas, the setting of the ELC Flag in the Inter-Area-Prefix-LSA MUST be the same as the received value. > > (2) If the propagation is not automatic, and the L1L2 router doesn't > > support this specification, then what are the drawbacks/failure > > scenarios? IOW, for multi-level operation is it a requirement that > > the L1L2 support this specification? > > drawback are identical to what is mentioned in the Security > Considerations section. I think that text is ok. Thanks! Alvaro. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
Hi Peter, On Thu, May 21, 2020 at 12:05:39PM +0200, Peter Psenak wrote: > Benjamin, > > thanks for review, please see inline (##PP): > > On 20/05/2020 00:44, Benjamin Kaduk via Datatracker wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-isis-mpls-elc-12: 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/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/ > > > > > > > > -- > > DISCUSS: > > -- > > > > As for other reviewers, many of my comments duplicate those for the OSPF > > document; I expect that the analogous responses apply and am fine if > > they only appear for one document's review. > > > > Here, the question I have about normative language applies to the text > > in Section 3: > > > > When a router propagates a prefix between ISIS levels ([RFC5302], it > > MUST preserve the ELC signaling for this prefix. > > > > The scenario in question is analogous to the OSPF cross-area case: is > > the router propagating the prefix between ISIS levels required to > > implement this document; is preservation of the flag value a new > > requirement from this document vs. a preexisting property; and is this > > document trying to make normative requirements of devices that don't > > implement this document? > > ##PP > this is a new requirement and only applies to the routers that support > this document. We are not making normative requirements of devices that > don't implement this document, we cannot. > > Maybe we can add that it only applies to the routers that supports this > extension: > > "When a router supporting this extension propagates a prefix between > ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix." > > Would it work? That would work, yes. I think what bothers me about the current text is that it feels like a global statement that holds universally everywhere (and as such would be "scope overreach"). Even to say something like "ELC signaling MUST be preserved when a router propagates a prefix between ISIS levels" (which is superficially similar) does not bother me very much, since it presumes a knowledge of what ELC signaling is (and thus, implementation of this document) in a way that "unknown prefix attribute flag 3" does not. That is, we clearly (given your above explanation) don't expect the "unknown prefix attribute flag 3" to get propagaged, and only when we know that it's the ELC signalling does the requirement kick in, if that makes sense. With respect to Alvaro's clarification, your answer for (1) makes sense; thanks! I think Alvaro has offered to help work out what (if any) additional text we might want to be sure that the answer to (2) is clear in the document. > > > > > Likewise, the ASBR case for cross-protocol redistribution seems to > > rather inherently require understanding the semantics of the flags being > > translated. > > similarly to the above I can chnage to: > > "When a router supporting this extension redistribute a prefix ..." > > > > > > > > -- > > COMMENT: > > -- > > > > Section 1 > > > > Should we add a sentence at the end of the last paragraph about how > > "this document defines a mechanism to signal the ERLD using IS-IS"? > > not sure I understand, how is described in the body of the document. I think I maybe put a little more detail on the motivation for this question in the OSPF document's comments. Basically, it's about parity between Abstract and Introduction -- the Introduction says clearly "this draft defines a mechanism to signal the ELC using IS-IS", but there is not an analogous statement about the ERLD signaling mechanism. As such, it's an editorial matter of style and you should feel free to ignore the comment or do what you see fit. > > > > In cases where LSPs are used (e.g., SR-MPLS [RFC8660], it would be > > > > side note(?): I don't know that SR-MPLS is so popular so as to be > > privileged as the only example given for LSP usage. If we instead > > talked about using IGPs to signal labels, this selection would seem less > > surprising to me. > > this document describes the ELC/ERLD capability signaling for SR MPLS. > For non SR MPLS cases, thee are existing mechanisms to learn ELC/ERLD. > > I can replace the text with: > > "In cases where SR is used with the MPLS Data
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
Hi Alvaro, On 21/05/2020 13:44, Alvaro Retana wrote: On May 21, 2020 at 6:05:41 AM, Peter Psenak wrote: Peter: Hi! -- DISCUSS: -- As for other reviewers, many of my comments duplicate those for the OSPF document; I expect that the analogous responses apply and am fine if they only appear for one document's review. Here, the question I have about normative language applies to the text in Section 3: When a router propagates a prefix between ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix. The scenario in question is analogous to the OSPF cross-area case: is the router propagating the prefix between ISIS levels required to implement this document; is preservation of the flag value a new requirement from this document vs. a preexisting property; and is this document trying to make normative requirements of devices that don't implement this document? ##PP this is a new requirement and only applies to the routers that support this document. We are not making normative requirements of devices that don't implement this document, we cannot. Maybe we can add that it only applies to the routers that supports this extension: "When a router supporting this extension propagates a prefix between ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix." Would it work? You're right, we can only apply requirements to routers that support this specification. IOW, adding the clarification is not necessary. My interpretation of Ben's question is two-fold: (1) Would ISIS routers normally propagate the information to a different level? The ELC is a new prefix attribute flag -- are prefix attributes always propagated (unchanged) to other levels? If so, then the requirement (MUST) is not needed. My reading of rfc7794 is that the propagation is optional... depends on the attribute or a bit. Some are propagated some are not. That's why we are saying this one MUST be preserved. (2) If the propagation is not automatic, and the L1L2 router doesn't support this specification, then what are the drawbacks/failure scenarios? IOW, for multi-level operation is it a requirement that the L1L2 support this specification? drawback are identical to what is mentioned in the Security Considerations section. thanks, Peter Thanks! Alvaro. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
On May 21, 2020 at 6:05:41 AM, Peter Psenak wrote: Peter: Hi! > > -- > > DISCUSS: > > -- > > > > As for other reviewers, many of my comments duplicate those for the OSPF > > document; I expect that the analogous responses apply and am fine if > > they only appear for one document's review. > > > > Here, the question I have about normative language applies to the text > > in Section 3: > > > > When a router propagates a prefix between ISIS levels ([RFC5302], it > > MUST preserve the ELC signaling for this prefix. > > > > The scenario in question is analogous to the OSPF cross-area case: is > > the router propagating the prefix between ISIS levels required to > > implement this document; is preservation of the flag value a new > > requirement from this document vs. a preexisting property; and is this > > document trying to make normative requirements of devices that don't > > implement this document? > > ##PP > this is a new requirement and only applies to the routers that support > this document. We are not making normative requirements of devices that > don't implement this document, we cannot. > > Maybe we can add that it only applies to the routers that supports this > extension: > > "When a router supporting this extension propagates a prefix between > ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix." > > Would it work? You're right, we can only apply requirements to routers that support this specification. IOW, adding the clarification is not necessary. My interpretation of Ben's question is two-fold: (1) Would ISIS routers normally propagate the information to a different level? The ELC is a new prefix attribute flag -- are prefix attributes always propagated (unchanged) to other levels? If so, then the requirement (MUST) is not needed. My reading of rfc7794 is that the propagation is optional... (2) If the propagation is not automatic, and the L1L2 router doesn't support this specification, then what are the drawbacks/failure scenarios? IOW, for multi-level operation is it a requirement that the L1L2 support this specification? Thanks! Alvaro. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-mpls-elc-12: (with DISCUSS and COMMENT)
Benjamin, thanks for review, please see inline (##PP): On 20/05/2020 00:44, Benjamin Kaduk via Datatracker wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-isis-mpls-elc-12: 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/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/ -- DISCUSS: -- As for other reviewers, many of my comments duplicate those for the OSPF document; I expect that the analogous responses apply and am fine if they only appear for one document's review. Here, the question I have about normative language applies to the text in Section 3: When a router propagates a prefix between ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix. The scenario in question is analogous to the OSPF cross-area case: is the router propagating the prefix between ISIS levels required to implement this document; is preservation of the flag value a new requirement from this document vs. a preexisting property; and is this document trying to make normative requirements of devices that don't implement this document? ##PP this is a new requirement and only applies to the routers that support this document. We are not making normative requirements of devices that don't implement this document, we cannot. Maybe we can add that it only applies to the routers that supports this extension: "When a router supporting this extension propagates a prefix between ISIS levels ([RFC5302], it MUST preserve the ELC signaling for this prefix." Would it work? Likewise, the ASBR case for cross-protocol redistribution seems to rather inherently require understanding the semantics of the flags being translated. similarly to the above I can chnage to: "When a router supporting this extension redistribute a prefix ..." -- COMMENT: -- Section 1 Should we add a sentence at the end of the last paragraph about how "this document defines a mechanism to signal the ERLD using IS-IS"? not sure I understand, how is described in the body of the document. In cases where LSPs are used (e.g., SR-MPLS [RFC8660], it would be side note(?): I don't know that SR-MPLS is so popular so as to be privileged as the only example given for LSP usage. If we instead talked about using IGPs to signal labels, this selection would seem less surprising to me. this document describes the ELC/ERLD capability signaling for SR MPLS. For non SR MPLS cases, thee are existing mechanisms to learn ELC/ERLD. I can replace the text with: "In cases where SR is used with the MPLS Data Plane" Would it work? Section 3 unless all of its interfaces are capable of processing ELs. If a router supports ELs on all of its interfaces, it SHOULD set the ELC for every local host prefix it advertises in IS-IS. Do we want to say anything about (not) advertising the ELC for other prefixes? Do we have to? I can add "MUST NOT set ELC with for any other prefix", but I find it unneeded. Section 4 I agree with Roman's comment about code 2 vs TBD2. that has been fixed already. ERLD in the range between 0 to 255. The scope of the advertisement depends on the application. If a router has multiple interfaces with Just to check: w.r.t. "scope", both this document and the OSPF one only define usage of this MSD type at the scope of a single node, right? (I don't see a particular reason to preclude using it at a different scope.) the scope here means where the information will be flooded - area only or network wide. No such thing as a node scope. Section 6 - Bit 3 in the Bit Values for Prefix Attribute Flags Sub-TLV registry has been assigned to the ELC Flag. IANA is asked to Is there an "IS-IS" in the name of this registry? no the registry name is "Bit Values for Prefix Attribute Flags Sub-TLV". Section 7 Should we say anything about considerations for redistributing ELC/ERLD information at the ASBR with respect to exposing "internal information" to external parties? why would this be "internal information" and why redistribution would be "external party"? Redistribution between IGPs is predominantly done between IGPs under same administrative domain. This document specifies the ability to advertise additional node capabilities using IS-IS and BGP-LS. As such, the security
