Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-mpls-elc-13: (with DISCUSS and COMMENT)
On Thu, May 21, 2020 at 12:16:44PM +0200, Peter Psenak wrote: > Hi Benjamin, > > thanks for review. > > Please see inline (##PP) two responses to OSPF specific comments. > > > On 20/05/2020 00:43, Benjamin Kaduk via Datatracker wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-ospf-mpls-elc-13: 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-ospf-mpls-elc/ > > > > > > > > -- > > DISCUSS: > > -- > > > > I have a question about the scope of some normative language, which may > > or may not be problematic but I'm too ignorant of OSPF details to be > > able to answer myself. In Section 3 we say that: > > > > When an OSPF Area Border Router (ABR) distributes information between > > connected areas it MUST preserve the ELC setting. > > > > My undesrtanding is that it's normal operation for an ABR to > > distribution information about prefixes and such between areas, and in > > particular that an ABR does not necessarily need to know the semantic > > details of every bit of information being distributed in that fashion. > > So, I am imagining a scenario where some routers in both areas > > advertise/understand the ELC flag but the ABR between them does not > > implement this spec. What would happen in such a scenario? If the ABR > > is still expected to distribute the ELC setting without change, isn't > > that just a core requirement from the respective OSPF specs, as opposed > > to a new requirement imposed by this spec (which, in this scenario, the > > ABR is not claiming to adhere to anyway)? > > > > There is perhaps a similar question about the ASBR guidance, though when > > doing cross-protocol signalling there is a more clear need for the ASBR > > to understand the semantics of the flags it is redistributing (and it's > > only a "SHOULD"). > > > > > > -- > > COMMENT: > > -- > > > > Section 1 > > > > The abstract is pretty explicit that "this draft defines" both ELC and > > ERLD signaling capabilities, but this section only has a clear statement > > for the ELC. Should we put something at the end of the last paragraph > > about "this document defines a mechanism to signal the ERLD using OSPFv2 > > and OSPFv3"? > > ##PP > this has been already addressed based on previous comments. Latest text > is as follows: > > "Multiprotocol Label Switching (MPLS) has defined a mechanism to > load-balance traffic flows using Entropy Labels (EL). An ingress Label > Switching Router (LSR) cannot insert ELs for packets going into a given > Label Switched Path (LSP) unless an egress LSR has indicated via > signaling that it has the capability to process ELs, referred to as the > Entropy Label Capability (ELC), on that LSP. In addition, it would be > useful for ingress LSRs to know each LSR's capability for reading the > maximum label stack depth and performing EL-based load-balancing, > referred to as Entropy Readable Label Depth (ERLD). This document > defines a mechanism to signal these two capabilities using OSPFv2 and > OSPFv3 and BGP-LS." Great; thanks! > > 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. > > > > Section 3 > > > > If the router supports ELs on all of its interfaces, it SHOULD > > advertise the ELC with every local host prefix it advertises in OSPF. > > > > Do we want to say anything about (not) advertising the ELC for other > > prefixes? > > > > 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? > > > > This document specifies the ability to advertise additional node > > capabilities using OSPF and BGP-LS. As such, the security > > considerations as described in [RFC5340], [RFC7770], [RFC7752], > > [RFC7684], [RFC8476], [RFC8662], > > > > RFC 8662's security considerations have a pretty hard dependency on RFC > > 6790's security considerations; it might be worth mentioning 6790 > > directly in this
Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-mpls-elc-13: (with DISCUSS and COMMENT)
Hi Benjamin, thanks for review. Please see inline (##PP) two responses to OSPF specific comments. On 20/05/2020 00:43, Benjamin Kaduk via Datatracker wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-ospf-mpls-elc-13: 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-ospf-mpls-elc/ -- DISCUSS: -- I have a question about the scope of some normative language, which may or may not be problematic but I'm too ignorant of OSPF details to be able to answer myself. In Section 3 we say that: When an OSPF Area Border Router (ABR) distributes information between connected areas it MUST preserve the ELC setting. My undesrtanding is that it's normal operation for an ABR to distribution information about prefixes and such between areas, and in particular that an ABR does not necessarily need to know the semantic details of every bit of information being distributed in that fashion. So, I am imagining a scenario where some routers in both areas advertise/understand the ELC flag but the ABR between them does not implement this spec. What would happen in such a scenario? If the ABR is still expected to distribute the ELC setting without change, isn't that just a core requirement from the respective OSPF specs, as opposed to a new requirement imposed by this spec (which, in this scenario, the ABR is not claiming to adhere to anyway)? There is perhaps a similar question about the ASBR guidance, though when doing cross-protocol signalling there is a more clear need for the ASBR to understand the semantics of the flags it is redistributing (and it's only a "SHOULD"). -- COMMENT: -- Section 1 The abstract is pretty explicit that "this draft defines" both ELC and ERLD signaling capabilities, but this section only has a clear statement for the ELC. Should we put something at the end of the last paragraph about "this document defines a mechanism to signal the ERLD using OSPFv2 and OSPFv3"? ##PP this has been already addressed based on previous comments. Latest text is as follows: "Multiprotocol Label Switching (MPLS) has defined a mechanism to load-balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load-balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities using OSPFv2 and OSPFv3 and BGP-LS." 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. Section 3 If the router supports ELs on all of its interfaces, it SHOULD advertise the ELC with every local host prefix it advertises in OSPF. Do we want to say anything about (not) advertising the ELC for other prefixes? 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? This document specifies the ability to advertise additional node capabilities using OSPF and BGP-LS. As such, the security considerations as described in [RFC5340], [RFC7770], [RFC7752], [RFC7684], [RFC8476], [RFC8662], RFC 8662's security considerations have a pretty hard dependency on RFC 6790's security considerations; it might be worth mentioning 6790 directly in this list as well. [I-D.ietf-idr-bgp-ls-segment-routing-ext] and [I-D.ietf-idr-bgp-ls-segment-routing-msd] are applicable to this document. Could we also have a brief note that the (respective) OSPF security mechanisms serve to protect the ELC/ERLD information? Incorrectly setting the E flag during origination, propagation or redistribution may lead to black-holing of the traffic on the egress node. This is what happens when the E flag
[Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-mpls-elc-13: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-ospf-mpls-elc-13: 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-ospf-mpls-elc/ -- DISCUSS: -- I have a question about the scope of some normative language, which may or may not be problematic but I'm too ignorant of OSPF details to be able to answer myself. In Section 3 we say that: When an OSPF Area Border Router (ABR) distributes information between connected areas it MUST preserve the ELC setting. My undesrtanding is that it's normal operation for an ABR to distribution information about prefixes and such between areas, and in particular that an ABR does not necessarily need to know the semantic details of every bit of information being distributed in that fashion. So, I am imagining a scenario where some routers in both areas advertise/understand the ELC flag but the ABR between them does not implement this spec. What would happen in such a scenario? If the ABR is still expected to distribute the ELC setting without change, isn't that just a core requirement from the respective OSPF specs, as opposed to a new requirement imposed by this spec (which, in this scenario, the ABR is not claiming to adhere to anyway)? There is perhaps a similar question about the ASBR guidance, though when doing cross-protocol signalling there is a more clear need for the ASBR to understand the semantics of the flags it is redistributing (and it's only a "SHOULD"). -- COMMENT: -- Section 1 The abstract is pretty explicit that "this draft defines" both ELC and ERLD signaling capabilities, but this section only has a clear statement for the ELC. Should we put something at the end of the last paragraph about "this document defines a mechanism to signal the ERLD using OSPFv2 and OSPFv3"? 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. Section 3 If the router supports ELs on all of its interfaces, it SHOULD advertise the ELC with every local host prefix it advertises in OSPF. Do we want to say anything about (not) advertising the ELC for other prefixes? 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? This document specifies the ability to advertise additional node capabilities using OSPF and BGP-LS. As such, the security considerations as described in [RFC5340], [RFC7770], [RFC7752], [RFC7684], [RFC8476], [RFC8662], RFC 8662's security considerations have a pretty hard dependency on RFC 6790's security considerations; it might be worth mentioning 6790 directly in this list as well. [I-D.ietf-idr-bgp-ls-segment-routing-ext] and [I-D.ietf-idr-bgp-ls-segment-routing-msd] are applicable to this document. Could we also have a brief note that the (respective) OSPF security mechanisms serve to protect the ELC/ERLD information? Incorrectly setting the E flag during origination, propagation or redistribution may lead to black-holing of the traffic on the egress node. This is what happens when the E flag should not be set but is erroneously set. Should we also say what happens if we should set the E flag but erroneously clear it (e.g., that poor or no load-balancing may occur)? Section 8 I do see the note in the shepherd writeup about the sixth author (thank you!); if we're already breaking through the 5-author limit, did we consider making those who "should be considered as co-authors" listed as co-authors? Section 10.2 It's slightly surprising to see the core OSPF protocols only listed as informative, but I can see how they are to be considered "basic specifications" in the vein of https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
