Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)
Hi Benjamin, Thank you very much. Sure, we'll discuss that, however for the time being we prefer to progress the document as is. We can still make some little changes when at the RFC editor. Thanks again for your thorough review and very useful comments. Jorge -Original Message- From: Benjamin Kaduk Date: Thursday, January 24, 2019 at 9:06 PM To: "Rabadan, Jorge (Nokia - US/Mountain View)" Cc: "Satya Mohanty (satyamoh)" , The IESG , "draft-ietf-bess-evpn-df-election-framew...@ietf.org" , Stephane Litkowski , "bess-cha...@ietf.org" , "bess@ietf.org" Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) Hi Jorge, Version 09 addresses my discuss points, so I have cleared in the datatracker. I do think that it would be better to use "MUST" in "when using the HRW Algorithm for EVPN DF Election, the ESI value in the Weight function SHOULD be set to that of the corresponding ES", and that there could be more discussion about how to provide the non-overlapping property of derived ES-Import RT values, but those are not grounds to block the document from advancing. Thank you for the updates! -Benjamin On Thu, Jan 24, 2019 at 10:46:41AM +, Rabadan, Jorge (Nokia - US/Mountain View) wrote: > Hi Benjamin, > > Satya and I made the changes agreed on this thread and we published version 09. > Version 09 is good to go from our perspective. > > Benjamin, Martin, please let us know if the draft can progress now. > > Thank you. > Jorge > > -Original Message- > From: Benjamin Kaduk > Date: Saturday, January 19, 2019 at 2:13 AM > To: "Satya Mohanty (satyamoh)" > Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" , The IESG , "draft-ietf-bess-evpn-df-election-framew...@ietf.org" , Stephane Litkowski , "bess-cha...@ietf.org" , "bess@ietf.org" > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) > > On Sat, Jan 19, 2019 at 12:38:02AM +, Satya Mohanty (satyamoh) wrote: > > Hi Benjamin, > > > > > > > > Thanks for your comments. My replies inline [Satya] > > > > > > > > On 1/18/19, 8:01 AM, "Benjamin Kaduk" wrote: > > > > > > > > On Thu, Jan 17, 2019 at 10:10:16PM +, Rabadan, Jorge (Nokia - US/Mountain View) wrote: > > > > > Benjamin, > > > > > > > > > > Thank you very much for your review. > > > > > Satya and I have looked at your points one by one, please see in-line. Let us know if you are ok now. We'll publish revision 08 soon. > > > > > > > > I see that the -08 has landed since I started composing this message -- > > > > thanks! Some more comments inline. > > > > > > > > > Thanks. > > > > > Jorge > > > > > > > > > > -Original Message- > > > > > From: Benjamin Kaduk > > > > > Date: Tuesday, January 8, 2019 at 6:52 PM > > > > > To: The IESG > > > > > Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" , Stephane Litkowski , "bess-cha...@ietf.org" , "stephane.litkow...@orange.com" , "bess@ietf.org" > > > > > Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) > > > > > Resent-From: > > > > > Resent-To: , , , , , > > > > > Resent-Date: Tuesday, January 8, 2019 at 6:51 PM > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-bess-evpn-df-election-framework-07: 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-b
Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)
Hi Jorge, Version 09 addresses my discuss points, so I have cleared in the datatracker. I do think that it would be better to use "MUST" in "when using the HRW Algorithm for EVPN DF Election, the ESI value in the Weight function SHOULD be set to that of the corresponding ES", and that there could be more discussion about how to provide the non-overlapping property of derived ES-Import RT values, but those are not grounds to block the document from advancing. Thank you for the updates! -Benjamin On Thu, Jan 24, 2019 at 10:46:41AM +, Rabadan, Jorge (Nokia - US/Mountain View) wrote: > Hi Benjamin, > > Satya and I made the changes agreed on this thread and we published version > 09. > Version 09 is good to go from our perspective. > > Benjamin, Martin, please let us know if the draft can progress now. > > Thank you. > Jorge > > -Original Message- > From: Benjamin Kaduk > Date: Saturday, January 19, 2019 at 2:13 AM > To: "Satya Mohanty (satyamoh)" > Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" , > The IESG , > "draft-ietf-bess-evpn-df-election-framew...@ietf.org" > , Stephane Litkowski > , "bess-cha...@ietf.org" > , "bess@ietf.org" > Subject: Re: Benjamin Kaduk's Discuss on > draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) > > On Sat, Jan 19, 2019 at 12:38:02AM +, Satya Mohanty (satyamoh) wrote: > > Hi Benjamin, > > > > > > > > Thanks for your comments. My replies inline [Satya] > > > > > > > > On 1/18/19, 8:01 AM, "Benjamin Kaduk" wrote: > > > > > > > > On Thu, Jan 17, 2019 at 10:10:16PM +, Rabadan, Jorge (Nokia - > US/Mountain View) wrote: > > > > > Benjamin, > > > > > > > > > > Thank you very much for your review. > > > > > Satya and I have looked at your points one by one, please see > in-line. Let us know if you are ok now. We'll publish revision 08 soon. > > > > > > > > I see that the -08 has landed since I started composing this > message -- > > > > thanks! Some more comments inline. > > > > > > > > > Thanks. > > > > > Jorge > > > > > > > > > > -Original Message- > > > > > From: Benjamin Kaduk > > > > > Date: Tuesday, January 8, 2019 at 6:52 PM > > > > > To: The IESG > > > > > Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" > , Stephane Litkowski > , "bess-cha...@ietf.org" > , "stephane.litkow...@orange.com" > , "bess@ietf.org" > > > > > Subject: Benjamin Kaduk's Discuss on > draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) > > > > > Resent-From: > > > > > Resent-To: , , > , , , > > > > > > Resent-Date: Tuesday, January 8, 2019 at 6:51 PM > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-bess-evpn-df-election-framework-07: 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-bess-evpn-df-election-framework/ > > > > > > > > > > > > > > > > > > > > > -- > > > > > DISCUSS: > > > > > > -- > > > > > > > > > > > > > > > It's not really clear to me that the question of Updating > 7432 has been > > > > > settled by the responses to the directorate reviews; I've > noted a few > > > > > places in the text that are problematic in this regard, > in the COMMENT > > > > > section. > > > > > > > > > >[JORGE] We finally agreed on making it updating 7432 and > explain why in the intro/abstract. Thanks. > > > > > > > > > > > > > > > [concerns about combinatoric explosion were overblown; > removed] > > > > > > > > > > Section 3.3 > > > >
Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)
Hi Benjamin, Satya and I made the changes agreed on this thread and we published version 09. Version 09 is good to go from our perspective. Benjamin, Martin, please let us know if the draft can progress now. Thank you. Jorge -Original Message- From: Benjamin Kaduk Date: Saturday, January 19, 2019 at 2:13 AM To: "Satya Mohanty (satyamoh)" Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" , The IESG , "draft-ietf-bess-evpn-df-election-framew...@ietf.org" , Stephane Litkowski , "bess-cha...@ietf.org" , "bess@ietf.org" Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) On Sat, Jan 19, 2019 at 12:38:02AM +, Satya Mohanty (satyamoh) wrote: > Hi Benjamin, > > > > Thanks for your comments. My replies inline [Satya] > > > > On 1/18/19, 8:01 AM, "Benjamin Kaduk" wrote: > > > > On Thu, Jan 17, 2019 at 10:10:16PM +, Rabadan, Jorge (Nokia - US/Mountain View) wrote: > > > Benjamin, > > > > > > Thank you very much for your review. > > > Satya and I have looked at your points one by one, please see in-line. Let us know if you are ok now. We'll publish revision 08 soon. > > > > I see that the -08 has landed since I started composing this message -- > > thanks! Some more comments inline. > > > > > Thanks. > > > Jorge > > > > > > -Original Message- > > > From: Benjamin Kaduk > > > Date: Tuesday, January 8, 2019 at 6:52 PM > > > To: The IESG > > > Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" , Stephane Litkowski , "bess-cha...@ietf.org" , "stephane.litkow...@orange.com" , "bess@ietf.org" > > > Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) > > > Resent-From: > > > Resent-To: , , , , , > > > Resent-Date: Tuesday, January 8, 2019 at 6:51 PM > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-bess-evpn-df-election-framework-07: 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-bess-evpn-df-election-framework/ > > > > > > > > > > > > -- > > > DISCUSS: > > > -- > > > > > > > > > It's not really clear to me that the question of Updating 7432 has been > > > settled by the responses to the directorate reviews; I've noted a few > > > places in the text that are problematic in this regard, in the COMMENT > > > section. > > > > > >[JORGE] We finally agreed on making it updating 7432 and explain why in the intro/abstract. Thanks. > > > > > > > > > [concerns about combinatoric explosion were overblown; removed] > > > > > > Section 3.3 > > > > > >Section 7.6 of [RFC7432] describes how the value of the ES-Import > > >Route Target for ESI types 1, 2, and 3 can be auto-derived by using > > >the high-order six bytes of the nine byte ESI value. The same auto- > > >derivation procedure can be extended to ESI types 0, 4, and 5 as long > > >as it is ensured that the auto-derived values for ES-Import RT among > > >different ES types don't overlap. > > > > > > How do I ensure that the auto-derived values don't overlap? > > > > > > [JORGE] The autoderivation in RFC7432 for ESI types 1, 2 and 3 can be used "only if it produces ESIs that satisfy the uniqueness requirement specified above." RFC7432 does not specify how the overlap is avoided, it is out of scop
Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)
On Sat, Jan 19, 2019 at 12:38:02AM +, Satya Mohanty (satyamoh) wrote: > Hi Benjamin, > > > > Thanks for your comments. My replies inline [Satya] > > > > On 1/18/19, 8:01 AM, "Benjamin Kaduk" wrote: > > > > On Thu, Jan 17, 2019 at 10:10:16PM +, Rabadan, Jorge (Nokia - > US/Mountain View) wrote: > > > Benjamin, > > > > > > Thank you very much for your review. > > > Satya and I have looked at your points one by one, please see in-line. > Let us know if you are ok now. We'll publish revision 08 soon. > > > > I see that the -08 has landed since I started composing this message -- > > thanks! Some more comments inline. > > > > > Thanks. > > > Jorge > > > > > > -Original Message- > > > From: Benjamin Kaduk > > > Date: Tuesday, January 8, 2019 at 6:52 PM > > > To: The IESG > > > Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" > , Stephane Litkowski > , "bess-cha...@ietf.org" > , "stephane.litkow...@orange.com" > , "bess@ietf.org" > > > Subject: Benjamin Kaduk's Discuss on > draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) > > > Resent-From: > > > Resent-To: , , > , , , > > > > Resent-Date: Tuesday, January 8, 2019 at 6:51 PM > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-bess-evpn-df-election-framework-07: 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-bess-evpn-df-election-framework/ > > > > > > > > > > > > > -- > > > DISCUSS: > > > > -- > > > > > > > > > It's not really clear to me that the question of Updating 7432 > has been > > > settled by the responses to the directorate reviews; I've noted > a few > > > places in the text that are problematic in this regard, in the > COMMENT > > > section. > > > > > >[JORGE] We finally agreed on making it updating 7432 and explain why > in the intro/abstract. Thanks. > > > > > > > > > [concerns about combinatoric explosion were overblown; removed] > > > > > > Section 3.3 > > > > > >Section 7.6 of [RFC7432] describes how the value of the > ES-Import > > >Route Target for ESI types 1, 2, and 3 can be auto-derived > by using > > >the high-order six bytes of the nine byte ESI value. The > same auto- > > >derivation procedure can be extended to ESI types 0, 4, and > 5 as long > > >as it is ensured that the auto-derived values for ES-Import > RT among > > >different ES types don't overlap. > > > > > > How do I ensure that the auto-derived values don't overlap? > > > > > > [JORGE] The autoderivation in RFC7432 for ESI types 1, 2 and 3 can be > used "only if it produces ESIs that satisfy the uniqueness requirement > specified above." RFC7432 does not specify how the overlap is avoided, it is > out of scope, but one may think the operator must manually check that the > values auto-deriving the 9-octet ESI value don't match. We added the > following text, let us know if it is okay: > > > "As in [RFC7432], the mechanism to guarantee that the auto-derived ESI > or ES-import RT values for different ESIs do not match is out of scope of > this document." > > > > That suffices to resolve the Discuss point. > > Having said that, though, Martin did some research and had some good > points > > on the telechat, that type 0 has 9 octets of fully arbitrary value, > whereas > > types 4 and 5 use as a base the router ID and also have a local > > discriminator. (IIRC, types 1, 2, and 3 were generally going to be unique > > as inherent properties of how they are determined, e.g., via the global > > uniqueness of MAC addresses.) I would suggest (but not insist upon) > > mentioning something about the operator being able to use the > discriminator > > and type-0 arbitrary values to ensure the needed non-overlap. > > > > > > > Section 4.2 > > > > > > The ESI value MAY
Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)
Hi Benjamin, Thanks for your comments. My replies inline [Satya] On 1/18/19, 8:01 AM, "Benjamin Kaduk" wrote: On Thu, Jan 17, 2019 at 10:10:16PM +, Rabadan, Jorge (Nokia - US/Mountain View) wrote: > Benjamin, > > Thank you very much for your review. > Satya and I have looked at your points one by one, please see in-line. Let us know if you are ok now. We'll publish revision 08 soon. I see that the -08 has landed since I started composing this message -- thanks! Some more comments inline. > Thanks. > Jorge > > -Original Message- > From: Benjamin Kaduk > Date: Tuesday, January 8, 2019 at 6:52 PM > To: The IESG > Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" , Stephane Litkowski , "bess-cha...@ietf.org" , "stephane.litkow...@orange.com" , "bess@ietf.org" > Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) > Resent-From: > Resent-To: , , , , , > Resent-Date: Tuesday, January 8, 2019 at 6:51 PM > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-bess-evpn-df-election-framework-07: 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-bess-evpn-df-election-framework/ > > > > -- > DISCUSS: > -- > > > It's not really clear to me that the question of Updating 7432 has been > settled by the responses to the directorate reviews; I've noted a few > places in the text that are problematic in this regard, in the COMMENT > section. > >[JORGE] We finally agreed on making it updating 7432 and explain why in the intro/abstract. Thanks. > > > [concerns about combinatoric explosion were overblown; removed] > > Section 3.3 > >Section 7.6 of [RFC7432] describes how the value of the ES-Import >Route Target for ESI types 1, 2, and 3 can be auto-derived by using >the high-order six bytes of the nine byte ESI value. The same auto- >derivation procedure can be extended to ESI types 0, 4, and 5 as long >as it is ensured that the auto-derived values for ES-Import RT among >different ES types don't overlap. > > How do I ensure that the auto-derived values don't overlap? > > [JORGE] The autoderivation in RFC7432 for ESI types 1, 2 and 3 can be used "only if it produces ESIs that satisfy the uniqueness requirement specified above." RFC7432 does not specify how the overlap is avoided, it is out of scope, but one may think the operator must manually check that the values auto-deriving the 9-octet ESI value don't match. We added the following text, let us know if it is okay: > "As in [RFC7432], the mechanism to guarantee that the auto-derived ESI or ES-import RT values for different ESIs do not match is out of scope of this document." That suffices to resolve the Discuss point. Having said that, though, Martin did some research and had some good points on the telechat, that type 0 has 9 octets of fully arbitrary value, whereas types 4 and 5 use as a base the router ID and also have a local discriminator. (IIRC, types 1, 2, and 3 were generally going to be unique as inherent properties of how they are determined, e.g., via the global uniqueness of MAC addresses.) I would suggest (but not insist upon) mentioning something about the operator being able to use the discriminator and type-0 arbitrary values to ensure the needed non-overlap. > Section 4.2 > > The ESI value MAY be set to all 0's in the Weight >function below if the operator so chooses. > > I'm not 100% sure I'm interpreting this correctly, but this sounds like a > piece of device-specific configuration (i.e., configured by the operator) > that must be the same across all devices for correct operation, but is not > covered by the advertisement of the DF Election Exctended Community. This > would decrease the
Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)
On Thu, Jan 17, 2019 at 10:10:16PM +, Rabadan, Jorge (Nokia - US/Mountain View) wrote: > Benjamin, > > Thank you very much for your review. > Satya and I have looked at your points one by one, please see in-line. Let us > know if you are ok now. We'll publish revision 08 soon. I see that the -08 has landed since I started composing this message -- thanks! Some more comments inline. > Thanks. > Jorge > > -Original Message- > From: Benjamin Kaduk > Date: Tuesday, January 8, 2019 at 6:52 PM > To: The IESG > Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" > , Stephane Litkowski > , "bess-cha...@ietf.org" > , "stephane.litkow...@orange.com" > , "bess@ietf.org" > Subject: Benjamin Kaduk's Discuss on > draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) > Resent-From: > Resent-To: , , > , , , > > Resent-Date: Tuesday, January 8, 2019 at 6:51 PM > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-bess-evpn-df-election-framework-07: 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-bess-evpn-df-election-framework/ > > > > -- > DISCUSS: > -- > > > It's not really clear to me that the question of Updating 7432 has > been > settled by the responses to the directorate reviews; I've noted a few > places in the text that are problematic in this regard, in the COMMENT > section. > >[JORGE] We finally agreed on making it updating 7432 and explain why in > the intro/abstract. Thanks. > > > [concerns about combinatoric explosion were overblown; removed] > > Section 3.3 > >Section 7.6 of [RFC7432] describes how the value of the ES-Import >Route Target for ESI types 1, 2, and 3 can be auto-derived by using >the high-order six bytes of the nine byte ESI value. The same auto- >derivation procedure can be extended to ESI types 0, 4, and 5 as > long >as it is ensured that the auto-derived values for ES-Import RT > among >different ES types don't overlap. > > How do I ensure that the auto-derived values don't overlap? > > [JORGE] The autoderivation in RFC7432 for ESI types 1, 2 and 3 can be used > "only if it produces ESIs that satisfy the uniqueness requirement specified > above." RFC7432 does not specify how the overlap is avoided, it is out of > scope, but one may think the operator must manually check that the values > auto-deriving the 9-octet ESI value don't match. We added the following text, > let us know if it is okay: > "As in [RFC7432], the mechanism to guarantee that the auto-derived ESI or > ES-import RT values for different ESIs do not match is out of scope of this > document." That suffices to resolve the Discuss point. Having said that, though, Martin did some research and had some good points on the telechat, that type 0 has 9 octets of fully arbitrary value, whereas types 4 and 5 use as a base the router ID and also have a local discriminator. (IIRC, types 1, 2, and 3 were generally going to be unique as inherent properties of how they are determined, e.g., via the global uniqueness of MAC addresses.) I would suggest (but not insist upon) mentioning something about the operator being able to use the discriminator and type-0 arbitrary values to ensure the needed non-overlap. > Section 4.2 > > The ESI value MAY be set to all 0's in the Weight >function below if the operator so chooses. > > I'm not 100% sure I'm interpreting this correctly, but this sounds > like a > piece of device-specific configuration (i.e., configured by the > operator) > that must be the same across all devices for correct operation, but > is not > covered by the advertisement of the DF Election Exctended Community. > This > would decrease the robustness of the system to basically the > "experimental" > level of DF election algorithm 31, which also relies on universal > agreement > of manual configuration. Is this actually something we want to > include? > > [Satya] This is to accommodate the case in > https://tools.ietf.org/html/draft-mohanty-bess-evpn-bum-opt-00. > Specifically, if the same set of
Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)
FYI We just posted revision 08 which addresses all the comments given during the review (thank you all for that). From the authors perspective, the document is ready to go. Thanks. Jorge -Original Message- From: "Rabadan, Jorge (Nokia - US/Mountain View)" Date: Thursday, January 17, 2019 at 11:10 PM To: Benjamin Kaduk , The IESG Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" , Stephane Litkowski , "bess-cha...@ietf.org" , "bess@ietf.org" Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) Benjamin, Thank you very much for your review. Satya and I have looked at your points one by one, please see in-line. Let us know if you are ok now. We'll publish revision 08 soon. Thanks. Jorge -Original Message- From: Benjamin Kaduk Date: Tuesday, January 8, 2019 at 6:52 PM To: The IESG Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" , Stephane Litkowski , "bess-cha...@ietf.org" , "stephane.litkow...@orange.com" , "bess@ietf.org" Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) Resent-From: Resent-To: , , , , , Resent-Date: Tuesday, January 8, 2019 at 6:51 PM Benjamin Kaduk has entered the following ballot position for draft-ietf-bess-evpn-df-election-framework-07: 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-bess-evpn-df-election-framework/ -- DISCUSS: -- It's not really clear to me that the question of Updating 7432 has been settled by the responses to the directorate reviews; I've noted a few places in the text that are problematic in this regard, in the COMMENT section. [JORGE] We finally agreed on making it updating 7432 and explain why in the intro/abstract. Thanks. [concerns about combinatoric explosion were overblown; removed] Section 3.3 Section 7.6 of [RFC7432] describes how the value of the ES-Import Route Target for ESI types 1, 2, and 3 can be auto-derived by using the high-order six bytes of the nine byte ESI value. The same auto- derivation procedure can be extended to ESI types 0, 4, and 5 as long as it is ensured that the auto-derived values for ES-Import RT among different ES types don't overlap. How do I ensure that the auto-derived values don't overlap? [JORGE] The autoderivation in RFC7432 for ESI types 1, 2 and 3 can be used "only if it produces ESIs that satisfy the uniqueness requirement specified above." RFC7432 does not specify how the overlap is avoided, it is out of scope, but one may think the operator must manually check that the values auto-deriving the 9-octet ESI value don't match. We added the following text, let us know if it is okay: "As in [RFC7432], the mechanism to guarantee that the auto-derived ESI or ES-import RT values for different ESIs do not match is out of scope of this document." Section 4.2 The ESI value MAY be set to all 0's in the Weight function below if the operator so chooses. I'm not 100% sure I'm interpreting this correctly, but this sounds like a piece of device-specific configuration (i.e., configured by the operator) that must be the same across all devices for correct operation, but is not covered by the advertisement of the DF Election Exctended Community. This would decrease the robustness of the system to basically the "experimental" level of DF election algorithm 31, which also relies on universal agreement of manual configuration. Is this actually something we want to include? [Satya] This is to accommodate the case in https://tools.ietf.org/html/draft-mohanty-bess-evpn-bum-opt-00. Specifically, if the same set of PES are multi-homed to the same set of ESes, setting the ES to 0, would result in the "same unique" PE be the D
Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)
Benjamin, Thank you very much for your review. Satya and I have looked at your points one by one, please see in-line. Let us know if you are ok now. We'll publish revision 08 soon. Thanks. Jorge -Original Message- From: Benjamin Kaduk Date: Tuesday, January 8, 2019 at 6:52 PM To: The IESG Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" , Stephane Litkowski , "bess-cha...@ietf.org" , "stephane.litkow...@orange.com" , "bess@ietf.org" Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT) Resent-From: Resent-To: , , , , , Resent-Date: Tuesday, January 8, 2019 at 6:51 PM Benjamin Kaduk has entered the following ballot position for draft-ietf-bess-evpn-df-election-framework-07: 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-bess-evpn-df-election-framework/ -- DISCUSS: -- It's not really clear to me that the question of Updating 7432 has been settled by the responses to the directorate reviews; I've noted a few places in the text that are problematic in this regard, in the COMMENT section. [JORGE] We finally agreed on making it updating 7432 and explain why in the intro/abstract. Thanks. [concerns about combinatoric explosion were overblown; removed] Section 3.3 Section 7.6 of [RFC7432] describes how the value of the ES-Import Route Target for ESI types 1, 2, and 3 can be auto-derived by using the high-order six bytes of the nine byte ESI value. The same auto- derivation procedure can be extended to ESI types 0, 4, and 5 as long as it is ensured that the auto-derived values for ES-Import RT among different ES types don't overlap. How do I ensure that the auto-derived values don't overlap? [JORGE] The autoderivation in RFC7432 for ESI types 1, 2 and 3 can be used "only if it produces ESIs that satisfy the uniqueness requirement specified above." RFC7432 does not specify how the overlap is avoided, it is out of scope, but one may think the operator must manually check that the values auto-deriving the 9-octet ESI value don't match. We added the following text, let us know if it is okay: "As in [RFC7432], the mechanism to guarantee that the auto-derived ESI or ES-import RT values for different ESIs do not match is out of scope of this document." Section 4.2 The ESI value MAY be set to all 0's in the Weight function below if the operator so chooses. I'm not 100% sure I'm interpreting this correctly, but this sounds like a piece of device-specific configuration (i.e., configured by the operator) that must be the same across all devices for correct operation, but is not covered by the advertisement of the DF Election Exctended Community. This would decrease the robustness of the system to basically the "experimental" level of DF election algorithm 31, which also relies on universal agreement of manual configuration. Is this actually something we want to include? [Satya] This is to accommodate the case in https://tools.ietf.org/html/draft-mohanty-bess-evpn-bum-opt-00. Specifically, if the same set of PES are multi-homed to the same set of ESes, setting the ES to 0, would result in the "same unique" PE be the DF for a given EVI for all those ESes. Use can be made of this property in the optimization in https://tools.ietf.org/html/draft-mohanty-bess-evpn-bum-opt-00. Yes, it would need manual configuration to enable this. Section 5 The AC-DF capability MAY be used with any "DF Alg" algorithm. It MUST As written, this suggests that it is true for any current or future algorithm, which is in conflict with the text in Section 3.2 that notes that "for any new DF Alg defined in future, its applicability/compatibility to the existing capabilities must be assessed on a case by case basis." It seems more prudent to make the assessment after the relevant technologies are both extant, so I would suggest this be non-normative text, perhaps "the AC-DF capability is expected to be of general applicability with any
