Re: [bess] Fwd: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)
On Mon, Mar 14, 2022 at 8:04 AM John E Drake wrote: > > > *[JD] We will change the SHOULD to a MUST in sections 9.1 and 9.1.3. The > SHOULD in sections 9.1.1, 9.2.1, and 9.3.1 are fine; there are RDs of > other types and everything will work if they are used but type 1 is > preferred because it provides the address of the route originator. If you > would like, we can add this explanation to those sections * > > > Yes, that would be ideal. Thanks! -MSK ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Fwd: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)
On Sat, Mar 12, 2022 at 7:00 AM John E Drake wrote: > Hi, > > > > Comments inline below. > > > > Yours Irrespectively, > > > > John > > > > > > Juniper Business Use Only > > *From:* BESS *On Behalf Of * Murray S. Kucherawy > *Sent:* Friday, March 11, 2022 11:41 PM > *To:* BESS ; bess-cha...@ietf.org > *Subject:* [bess] Fwd: Murray Kucherawy's Discuss on > draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT) > > > > *[External Email. Be cautious of content]* > > > > Hi, I'd still like to clear up these points before I clear my DISCUSS. I > see there's been some revision activity on the document, but these issues > haven't been resolved yet. > > > > Thanks, > > > > -MSK > > > > -- Forwarded message - > From: *Murray S. Kucherawy* > Date: Thu, Dec 9, 2021 at 8:03 AM > Subject: Re: Murray Kucherawy's Discuss on > draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT) > To: Mankamana Mishra (mankamis) > Cc: The IESG , Stephane Litkowski (slitkows) < > slitk...@cisco.com>, draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org < > draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>, bess-cha...@ietf.org < > bess-cha...@ietf.org>, bess@ietf.org , > slitkows.i...@gmail.com > > > > On Wed, Nov 17, 2021 at 12:03 PM Mankamana Mishra (mankamis) < > manka...@cisco.com> wrote: > > (0) I suggest making each of the actions you want to take (there are four) > into > > their own subsections of this section. > > > > Any thoughts on this point? > > > > *[JD] We’ll have four subsections* > > > (1) "EVPN Extended Community sub-types registry" should be "EVPN Extended > Community Sub-Types sub-registry of the BGP Extended Communities registry", > which makes it easier to find. > > > > ...or this one? > > > > *[JD] Okay* > I think this one was fixed in -14 already. > > (2) "Multicast Flags Extended Community" appears to be a new registry > you're > > creating in the final action here. BCP 26, for a First Come First Served > registry, advises that a change controller column be included. Are you > intentionally omitting this here? Or if this is referring to an existing > registry, I wasn't able to find it. > > Mankamana :The registry in (1), above, is also FCFS and it does not have a > change controller column. > > Well, BCP 26 says they both should. It's unfortunate the other registry > doesn't, but is that a good reason not to add one here? > > > > *[JD] We will follow the guidance of IANA, which was always our intention > * > OK, I'll watch for a change here. > Section 3 defines "NV" and "NVO", but these terms appear nowhere in the > document. > > Thanks for fixing this. > > > > Every SHOULD in this document, other than the ones that talk about logging, > left me wondering why an implementer might decide not to follow that > advice. > Since SHOULD presents a choice, I suggest including some guidance about why > it's a SHOULD, i.e., when one might decide not to do what it says and still > expect to interoperate. Or should some of these really be MUSTs? > > Mankamana : My understanding should gives more flexibility to > implementation to make choices. And may not be good idea to make every > thing MUST until without it protocol breaks. Is there any specific > instance which you want to make MUST ? > > If the point is just to give choices, then I suggest you consider using > MAY. SHOULD is defined to mean "Do this unless you have a really good > reason not to", and in those cases, the document serves the reader better > if it gives some guidance as to why an implementer might do something other > than what it says. > > > > *[JD] I reviewed each instance of the use of SHOULD and I thought they > all seemed appropriate * > > > Only part of my question is about whether "SHOULD" is appropriate instead of "MUST". What I'm suggesting is some advice to the reader about when I might decide not to do what the SHOULD says. For example, consider the SHOULD in Section 7. You're giving the implementer a choice here. Can they decide to do something other than what it says for any legitimate reason and still interoperate? If yes, I would suggest including such a reason. If not, maybe SHOULD isn't actually right here. Similar point for the one at the end of Section 9.1, or the one in 9.1.1, or in 9.3.1. For the one at the end of 9.1.3, what other procedure might one decide to use, and why? -MSK ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Fwd: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)
Hi, I'd still like to clear up these points before I clear my DISCUSS. I see there's been some revision activity on the document, but these issues haven't been resolved yet. Thanks, -MSK -- Forwarded message - From: Murray S. Kucherawy Date: Thu, Dec 9, 2021 at 8:03 AM Subject: Re: Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT) To: Mankamana Mishra (mankamis) Cc: The IESG , Stephane Litkowski (slitkows) < slitk...@cisco.com>, draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org < draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>, bess-cha...@ietf.org < bess-cha...@ietf.org>, bess@ietf.org , slitkows.i...@gmail.com On Wed, Nov 17, 2021 at 12:03 PM Mankamana Mishra (mankamis) < manka...@cisco.com> wrote: > (0) I suggest making each of the actions you want to take (there are four) > into > > their own subsections of this section. > Any thoughts on this point? (1) "EVPN Extended Community sub-types registry" should be "EVPN Extended > Community Sub-Types sub-registry of the BGP Extended Communities registry", > which makes it easier to find. > ...or this one? (2) "Multicast Flags Extended Community" appears to be a new registry you're > creating in the final action here. BCP 26, for a First Come First Served > registry, advises that a change controller column be included. Are you > intentionally omitting this here? Or if this is referring to an existing > registry, I wasn't able to find it. > > Mankamana :The registry in (1), above, is also FCFS and it does not have > a change controller column. > Well, BCP 26 says they both should. It's unfortunate the other registry doesn't, but is that a good reason not to add one here? Section 3 defines "NV" and "NVO", but these terms appear nowhere in the > document. > Thanks for fixing this. Every SHOULD in this document, other than the ones that talk about logging, > left me wondering why an implementer might decide not to follow that > advice. > Since SHOULD presents a choice, I suggest including some guidance about why > it's a SHOULD, i.e., when one might decide not to do what it says and still > expect to interoperate. Or should some of these really be MUSTs? > > Mankamana : My understanding should gives more flexibility to > implementation to make choices. And may not be good idea to make every > thing MUST until without it protocol breaks. Is there any specific > instance which you want to make MUST ? > > If the point is just to give choices, then I suggest you consider using MAY. SHOULD is defined to mean "Do this unless you have a really good reason not to", and in those cases, the document serves the reader better if it gives some guidance as to why an implementer might do something other than what it says. -MSK > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-srv6-services-11: (with COMMENT)
Hi Ketan, On Thu, Feb 17, 2022 at 12:19 AM Ketan Talaulikar wrote: > This document covers several BGP services and has received contributions > from several people over the past 5 years. The authors will discuss and get > back on the trimming of the front page list. > The limit of 5 is not a hard limit, but we do encourage people to stick to it. Mostly I'm just checking in with Martin here to ensure this is seen as a necessary exception. -MSK ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Murray Kucherawy's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)
On Wed, Nov 17, 2021 at 12:03 PM Mankamana Mishra (mankamis) < manka...@cisco.com> wrote: > (0) I suggest making each of the actions you want to take (there are four) > into > > their own subsections of this section. > Any thoughts on this point? (1) "EVPN Extended Community sub-types registry" should be "EVPN Extended > Community Sub-Types sub-registry of the BGP Extended Communities registry", > which makes it easier to find. > ...or this one? (2) "Multicast Flags Extended Community" appears to be a new registry you're > creating in the final action here. BCP 26, for a First Come First Served > registry, advises that a change controller column be included. Are you > intentionally omitting this here? Or if this is referring to an existing > registry, I wasn't able to find it. > > Mankamana :The registry in (1), above, is also FCFS and it does not have > a change controller column. > Well, BCP 26 says they both should. It's unfortunate the other registry doesn't, but is that a good reason not to add one here? Section 3 defines "NV" and "NVO", but these terms appear nowhere in the > document. > Thanks for fixing this. Every SHOULD in this document, other than the ones that talk about logging, > left me wondering why an implementer might decide not to follow that > advice. > Since SHOULD presents a choice, I suggest including some guidance about why > it's a SHOULD, i.e., when one might decide not to do what it says and still > expect to interoperate. Or should some of these really be MUSTs? > > Mankamana : My understanding should gives more flexibility to > implementation to make choices. And may not be good idea to make every > thing MUST until without it protocol breaks. Is there any specific > instance which you want to make MUST ? > > If the point is just to give choices, then I suggest you consider using MAY. SHOULD is defined to mean "Do this unless you have a really good reason not to", and in those cases, the document serves the reader better if it gives some guidance as to why an implementer might do something other than what it says. -MSK > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Murray Kucherawy's Discuss on draft-ietf-bess-evpn-bum-procedure-updates-11: (with DISCUSS and COMMENT)
On Wed, Oct 20, 2021 at 11:17 PM Benjamin Kaduk wrote: > > I'm pretty sure it's the registry to be created by > draft-ietf-bess-evpn-igmp-mld-proxy (also on this week's telechat), though > the specification there doesn't really provide a clear title for the new > registry itself. > Looks like it's on the 10/28 telechat. I'll have a look at it. A vague title would indeed be a problem. -MSK ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)
These are great, thanks! On Wed, Mar 17, 2021 at 7:33 AM Rabadan, Jorge (Nokia - US/Mountain View) < jorge.raba...@nokia.com> wrote: > Hi Murray, > > > > Thanks for reviewing. Please see my comments in-line with [jorge]. > > We have addressed your comments, you should see the changes in the next > revision. > > > > Thx > > Jorge > > > > *From: *Murray Kucherawy via Datatracker > *Date: *Thursday, January 21, 2021 at 5:23 AM > *To: *The IESG > *Cc: *draft-ietf-bess-evpn-proxy-arp...@ietf.org < > draft-ietf-bess-evpn-proxy-arp...@ietf.org>, bess-cha...@ietf.org < > bess-cha...@ietf.org>, bess@ietf.org , Bocci, Matthew > (Nokia - GB) > *Subject: *Murray Kucherawy's No Objection on > draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT) > > Murray Kucherawy has entered the following ballot position for > draft-ietf-bess-evpn-proxy-arp-nd-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/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-proxy-arp-nd/ > > > > -- > COMMENT: > -- > > In addition to Barry's comments, I found that "BD" appears in the glossary > twice, and "SLLA" appears in the glossary but nowhere else in the document. > > [jorge] fixed both things, thanks. > > > > Are "Address Resolution" and "Large Data Center" formal terms? If not, > they > should be lowercase. > > [jorge] fixed address resolution. Since we are using DC as an acronym, I’m > using DC consistently now, throughout the document. Thanks. > > > > > > Alluding to a lot of things Alvaro pointed out: Many of the SHOULDs in this > document are bare, in that they give the implementer a choice but no > guidance > on how to make that choice. For instance: > >A Proxy-ARP/ND implementation SHOULD support static, dynamic and >EVPN-learned entries. > > How would I decide whether I've got a use case that justifies not doing > one of > those, and what are the interoperability implications of that decision? > > I suggest reviewing these. > > [jorge] we reviewed all those after Alvaro’s review. About the one you > point out, I changed it to: > > “A Proxy-ARP/ND implementation in an EVPN BD MUST support dynamic and > EVPN-learned entries, and SHOULD support static entries.” > > Since if the solution is implemented, at least dynamic and evpn entries > are needed. > > > > > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
Hi Greg, Just to be clear, this is purely a suggestion on my part that might improve the document. It's not a DISCUSS, so you're not obligated to indulge my suggestions unless you think they're a worthwhile improvement. Yes, those all look good to me. For the 4.2 changes, I might suggest a slightly different presentation: NEW: When a PE supporting this specification receives a C-multicast route for a particular (C-S, C-G) for which all of the following are true: o the RT carried in the route results in importing the route into a particular VRF on the PE; o the route carries the Standby PE BGP Community; and o the PE determines (via a method of failure detection that is outside the scope of this document) that C-S is not reachable through some other PE (more details are in Section 4.3), then the PE MAY install VRF PIM state corresponding to this Standby BGP C-multicast route (the result will be that a PIM Join message will be sent to the CE towards C-S, and that the PE will receive (C-S, C-G) traffic), and the PE MAY forward (C-S, C-G) traffic received by the PE to other PEs through a P-tunnel rooted at the PE. -MSK ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Murray Kucherawy's Discuss on draft-ietf-bess-rfc5549revision-04: (with DISCUSS and COMMENT)
Yes, that would work. I don't think you need the first sentence, but I can live with it. On Mon, Aug 31, 2020 at 3:04 AM Stephane Litkowski (slitkows) < slitk...@cisco.com> wrote: > Yep sorry. > > I would like to keep the cap code value that has been allocated. > > > > What about: > > This document does not define any new code point compared to target="RFC5549"/> > > RFC5549 added "Extended Next Hop Encoding" to the Capability Codes > registry, which was created by [RFC5492]. IANA is requested to update the > definition of that entry to refer instead to this document. > > The value allocated for this Capability Code is 5. > > > > > > > > *From:* Murray S. Kucherawy > *Sent:* lundi 31 août 2020 10:53 > *To:* slitkows.i...@gmail.com > *Cc:* The IESG ; draft-ietf-bess-rfc5549revis...@ietf.org; > bess-cha...@ietf.org; bess@ietf.org; Matthew Bocci < > matthew.bo...@nokia.com> > *Subject:* Re: Murray Kucherawy's Discuss on > draft-ietf-bess-rfc5549revision-04: (with DISCUSS and COMMENT) > > > > Hi, > > > > I saw the change. However the text of that section still says "new" > twice. Since the registration was made by RFC 5549, it isn't appropriate > to call it "new". > > > > Any comments on the text I proposed in my DISCUSS? It's more typical of > "bis" style work, in my experience. > > > > -MSK > > > > On Mon, Aug 31, 2020 at 1:49 AM wrote: > > Hi Murray, > > I have uploaded a new revision that clarifies the IANA section. > > -Original Message- > From: Murray Kucherawy via Datatracker > Sent: mercredi 26 août 2020 21:01 > To: The IESG > Cc: draft-ietf-bess-rfc5549revis...@ietf.org; bess-cha...@ietf.org; > bess@ietf.org; Matthew Bocci > Subject: Murray Kucherawy's Discuss on draft-ietf-bess-rfc5549revision-04: > (with DISCUSS and COMMENT) > > Murray Kucherawy has entered the following ballot position for > draft-ietf-bess-rfc5549revision-04: 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-rfc5549revision/ > > > > -- > DISCUSS: > -- > > An easy one, but necessary IMHO: > > I'm confused by the IANA Considerations section. It looks like a verbatim > copy from RFC 5549 which made the original registration for "Extended Next > Hop Encoding", but this isn't actually a new registration. Shouldn't this > therefore be something like the following? > > NEW: > > RFC 5549 added "Extended Next Hop Encoding" to the Capability Codes > registry, which was created by [RFC5492]. IANA is requested to update the > definition of that entry to refer instead to this document. > > > -- > COMMENT: > -- > > Thanks for this document. It was easy to read even for people like me who > don't get involved in routing too much. > > Thank you also for the shepherd writeup, which (unlike most lately) > actually answered the question "Why is this the proper type of RFC?" > > > > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Murray Kucherawy's Discuss on draft-ietf-bess-rfc5549revision-04: (with DISCUSS and COMMENT)
Hi, I saw the change. However the text of that section still says "new" twice. Since the registration was made by RFC 5549, it isn't appropriate to call it "new". Any comments on the text I proposed in my DISCUSS? It's more typical of "bis" style work, in my experience. -MSK On Mon, Aug 31, 2020 at 1:49 AM wrote: > Hi Murray, > > I have uploaded a new revision that clarifies the IANA section. > > -Original Message- > From: Murray Kucherawy via Datatracker > Sent: mercredi 26 août 2020 21:01 > To: The IESG > Cc: draft-ietf-bess-rfc5549revis...@ietf.org; bess-cha...@ietf.org; > bess@ietf.org; Matthew Bocci > Subject: Murray Kucherawy's Discuss on draft-ietf-bess-rfc5549revision-04: > (with DISCUSS and COMMENT) > > Murray Kucherawy has entered the following ballot position for > draft-ietf-bess-rfc5549revision-04: 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-rfc5549revision/ > > > > -- > DISCUSS: > -- > > An easy one, but necessary IMHO: > > I'm confused by the IANA Considerations section. It looks like a verbatim > copy from RFC 5549 which made the original registration for "Extended Next > Hop Encoding", but this isn't actually a new registration. Shouldn't this > therefore be something like the following? > > NEW: > > RFC 5549 added "Extended Next Hop Encoding" to the Capability Codes > registry, which was created by [RFC5492]. IANA is requested to update the > definition of that entry to refer instead to this document. > > > -- > COMMENT: > -- > > Thanks for this document. It was easy to read even for people like me who > don't get involved in routing too much. > > Thank you also for the shepherd writeup, which (unlike most lately) > actually answered the question "Why is this the proper type of RFC?" > > > > > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
