Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-03.txt
Hello GROW, The draft-ietf-grow-wkc-behavior-03.txt just issued makes just a handful of changes w.r.t. -02: https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-wkc-behavior-03 - We incorporate Nokia implementation details plus editorial comments received from Greg Hankins. - We clarified some imprecise wording. - We re-cast one action item for implementors, to recognize that some implementations' "set" directives do not and were never intended to remove any communities, Well-Known or otherwise. Thanks! Jay B. internet-dra...@ietf.org writes: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Global Routing Operations WG of the IETF. > > Title : Well-Known Community Policy Behavior > Authors : Jay Borkenhagen > Randy Bush > Ron Bonica > Serpil Bayraktar > Filename: draft-ietf-grow-wkc-behavior-03.txt > Pages : 7 > Date: 2019-03-10 > > Abstract: >Well-Known BGP Communities are manipulated inconsistently by current >implementations. This results in difficulties for operators. >Network operators are encouraged to deploy consistent community >handling across their networks, taking the inconsistent behaviors >from the various BGP implementations they operate into consideration. >Also, BGP implementors are expected to not create any further >inconsistencies from this point forward. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-grow-wkc-behavior-03 > https://datatracker.ietf.org/doc/html/draft-ietf-grow-wkc-behavior-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-wkc-behavior-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-02.txt
Hello GROW, The draft-ietf-grow-wkc-behavior-02.txt just posted makes very few very small changes w.r.t. -01: https://tools.ietf.org/rfcdiff?url2=draft-ietf-grow-wkc-behavior-02.txt - We introduce the nomenclature of 'the "set" directive' instead of using "set community" or "community set" when speaking in general terms, addressing a comment from Jakob Heitz. - We slightly re-worded Section 6. "Action Items" in response to comments raised by Job Snijders, adopting suggested wording from John Heasley. (Thanks, Heas.) Regarding David Farmer's suggestion that RFC1997 needs to be updated: speaking for myself, I would be satisfied leaving RFC1997 as-is while this draft documents RFC1997's shortcomings. Anyone with strong feelings to the contrary may write that draft. Thanks! Jay B. internet-dra...@ietf.org writes: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Global Routing Operations WG of the IETF. > > Title : Well-Known Community Policy Behavior > Authors : Jay Borkenhagen > Randy Bush > Ron Bonica > Serpil Bayraktar > Filename: draft-ietf-grow-wkc-behavior-02.txt > Pages : 6 > Date: 2019-01-22 > > Abstract: >Well-Known BGP Communities are manipulated inconsistently by current >implementations. This results in difficulties for operators. >Network operators are encouraged to deploy consistent community >handling across their networks, taking the inconsistent behaviors >from the various bgp implementations they operate into consideration. >Also, bgp implementors are expected to not create any further >inconsistencies from this point forward. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-grow-wkc-behavior-02 > https://datatracker.ietf.org/doc/html/draft-ietf-grow-wkc-behavior-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-wkc-behavior-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-01.txt
Hello Grow, The draft-ietf-grow-wkc-behavior-01.txt posted today makes just a few small changes w.r.t. -00: https://tools.ietf.org/rfcdiff?url2=draft-ietf-grow-wkc-behavior-01.txt Specifically: - the Abstract has been adjusted to indicate more clearly what things vendors should do and what things network operators should do. - some loose wording in the Introduction has been tightened up. - the Section 6 "Action Items" are clarified similarly to the clarifications in the Abstract. Also, in response to WGLC comments from David Farmer, a paragraph was added to urge network operators not to depend on any assumed treatment of bgp communities by any neighbor networks: for example, do not assume that your transmitted NO_EXPORT will be honored, unless the neighbor confirms that it will be. Thank you. Jay B. internet-dra...@ietf.org writes: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Global Routing Operations WG of the IETF. > > Title : Well-Known Community Policy Behavior > Authors : Jay Borkenhagen > Randy Bush > Ron Bonica > Serpil Bayraktar > Filename: draft-ietf-grow-wkc-behavior-01.txt > Pages : 6 > Date: 2019-01-07 > > Abstract: >Well-Known BGP Communities are manipulated inconsistently by current >implementations. This results in difficulties for operators. >Network operators are encouraged to deploy consistent community >handling across their networks, taking the inconsistent behaviors >from the various bgp implementations they operate into consideration. >Also, bgp implementors are expected to not create any further >inconsistencies from this point forward. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-grow-wkc-behavior-01 > https://datatracker.ietf.org/doc/html/draft-ietf-grow-wkc-behavior-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-wkc-behavior-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ymbk-grow-wkc-behavior-00.txt
> > >> i did not realize this was going on. jay, who discovered it, was > > >> surprised. > > > > > > NTT noticed this type of inconsistency between some vendors somewhere > > > in July 2016. [...] [...] > I know of other carriers who are not interested in preserving any > community information and heavily rely on "set community" == 'delete'. > But... at the same time those same carriers are interested in honoring > GRACEFUL_SHUTDOWN. > For what it's worth, I first noticed the special treatment of some well-known communities after Job announced his GRACEFUL_SHUTDOWN beacon prefix. I expected that it would not have passed intact through a "set community foo" policy, but it did. Clearly "set community foo" is not appropriate for use on many classes of connections -- e.g. on connections to one's customers -- but where it is used it should not cause surprises. Jay B. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Opsdir last call review of draft-ietf-grow-bgp-gshut-13
Distro cut *way* down. Regarding the suggestion for "logging knobs": - if it's just logging that a gshut action was taken, that's a local implementation decision -- no need to mention it in the draft. - if it's "Possibly raising alarms when something seems wrong", that would be a bad idea. There *will* be instances when traffic remains on the link even after the graceful shutdown initiator has signaled an approaching shutdown. To keep things simple and to allow the gshut draft to continue making progress, I'd prefer to leave it as-is. Thanks. Jay B. bruno.decra...@orange.com writes: > OK, > Thanks Susan. > > --Bruno > > > -Original Message- > > From: Susan Hares [mailto:sha...@ndzh.com] > > Sent: Thursday, January 18, 2018 12:25 PM > > To: DECRAENE Bruno IMT/OLN > > Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut@ietf.org; i...@ietf.org; > ops-...@ietf.org > > Subject: RE: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 > > > > Bruno: > > > > I'm sorry I'm this late for the review. On the editorial nit, if you > think it helps - send it to the RFC > > editor. > > > > On the logging knobs, you understood my point. Logs should cover what > is section 4.2. However, > > since the document is in the RFC editor's queue - it is your choice. If > you get a chance to edit it in - > > fine. If not, those people who implement the gshut will probably put it > in. > > > > Thanks for asking, Susan Hares > > > > -Original Message- > > From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] > > Sent: Thursday, January 18, 2018 6:19 AM > > To: Susan Hares > > Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut@ietf.org; i...@ietf.org; > ops-...@ietf.org > > Subject: RE: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 > > > > Hi Susan, > > > > Thanks for your time reviewing this document and you below comments. > > > > Please see my replies inline [Bruno] > > > > Note that however fast I'm answering to your review, that document is now > in RFC editor queue, > > and hence technical changes are much more difficult. (AFAIK, would > require specific approval > > from the responsible AD). Thanks for taking this into account. > > > > > > > > > -Original Message- > > > From: Susan Hares [mailto:sha...@ndzh.com] > Sent: Thursday, January > 18, 2018 9:46 AM > > > To: ops-...@ietf.org > Cc: grow@ietf.org; > draft-ietf-grow-bgp-gshut@ietf.org; i...@ietf.org > > > Subject: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 > > > Reviewer: Susan Hares > > > Review result: Has Nits > > Status: Nits > > The operational > procedures described in this > > process for the gshut comment are > accurately covered, and SHOULD work > well. The > > Appendices A-C add to an > operations document and should be retained > for publication. > > > > [Bruno] ok, thanks. > > > > > Technical nit: > > > location of technical nit: (section 4.3) > The document indicats that > the "BGP implementers > > SHOULD provide configuration > knobs that utilize teh GRACEFUL_SHUTDOWN > community." > > > > > > What the problem is: > > > The document does not say is that their should be error reporting > knobs to > track the use of > > GRACEFUL_SHUTDOWN community. This can go in section 4.3 in > one or two > sentences. > > > > [Bruno] > > Could you please elaborate on this? What do you have in mind by "error > reporting knobs"? > > Thinking about this, what I could think of would be logs detailing the > steps in section 4.2. Possibly > > raising alarms when something seems wrong. (e.g. after waiting for BGP > convergence, there is still > > some traffic sent/received over the interface(s) related to the EBGP > session) Is this what you were > > thinking about? > > > > > > > Editorial nit: > > > section 3. paragraph 2, p. 3 > > > > > > /This is because alternate paths can be hidden by knodes of an AS./ > > commment: The implied > > "this" is too vague for a specification. > > > > > > Fix:/This lack of path occurs because alternate paths can be hidden by > nodes of > an AS."/ > > > > > > [Bruno] > > I agree that your proposed text makes it more explicit, which is always > better in a specification > > (when it's not redundant). > > However, I would note 2 points: > > - section 3 is part of the introduction to the problem space. It explains > the root cause of the > > problem. It's not part of the graceful shutdown specification. > > - The text you are referring to is a paragraph starting with: "First, > some routers can have no path > > toward an affected prefix, and drop traffic destined to this prefix. > This is because alternate paths > > can be hidden by nodes of an
Re: [GROW] Opsdir last call review of draft-ietf-grow-bgp-gshut-13
[resend - apologies for any dupes] Distro cut *way* down. Regarding the suggestion for "logging knobs": - if it's just logging that a gshut action was taken, that's a local implementation decision -- no need to mention it in the draft. - if it's "Possibly raising alarms when something seems wrong", that would be a bad idea. There *will* be instances when traffic remains on the link even after the graceful shutdown initiator has signaled an approaching shutdown. To keep things simple and to allow the gshut draft to continue making progress, I'd prefer to leave it as-is. Thanks. Jay B. bruno.decra...@orange.com writes: OK, Thanks Susan. --Bruno -Original Message- From: Susan Hares [mailto:sha...@ndzh.com] Sent: Thursday, January 18, 2018 12:25 PM To: DECRAENE Bruno IMT/OLN Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut@ietf.org; i...@ietf.org; ops-...@ietf.org Subject: RE: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 Bruno: I'm sorry I'm this late for the review. On the editorial nit, if you think it helps - send it to the RFC editor. On the logging knobs, you understood my point. Logs should cover what is section 4.2. However, since the document is in the RFC editor's queue - it is your choice. If you get a chance to edit it in - fine. If not, those people who implement the gshut will probably put it in. Thanks for asking, Susan Hares -Original Message- From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] Sent: Thursday, January 18, 2018 6:19 AM To: Susan Hares Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut@ietf.org; i...@ietf.org; ops-...@ietf.org Subject: RE: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 Hi Susan, Thanks for your time reviewing this document and you below comments. Please see my replies inline [Bruno] Note that however fast I'm answering to your review, that document is now in RFC editor queue, and hence technical changes are much more difficult. (AFAIK, would require specific approval from the responsible AD). Thanks for taking this into account. -Original Message- From: Susan Hares [mailto:sha...@ndzh.com] Sent: Thursday, January 18, 2018 9:46 AM > To: ops-...@ietf.org Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut@ietf.org; i...@ietf.org > Subject: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 Reviewer: Susan Hares > Review result: Has Nits Status: Nits The operational procedures described in this process for the gshut comment are accurately covered, and SHOULD work well. The Appendices A-C add to an operations document and should be retained for publication. [Bruno] ok, thanks. Technical nit: location of technical nit: (section 4.3) The document indicats that the "BGP implementers SHOULD provide configuration knobs that utilize teh GRACEFUL_SHUTDOWN community." > What the problem is: The document does not say is that their should be error reporting knobs to track the use of GRACEFUL_SHUTDOWN community. This can go in section 4.3 in one or two sentences. [Bruno] Could you please elaborate on this? What do you have in mind by "error reporting knobs"? Thinking about this, what I could think of would be logs detailing the steps in section 4.2. Possibly raising alarms when something seems wrong. (e.g. after waiting for BGP convergence, there is still some traffic sent/received over the interface(s) related to the EBGP session) Is this what you were thinking about? Editorial nit: section 3. paragraph 2, p. 3 > /This is because alternate paths can be hidden by knodes of an AS./ commment: The implied "this" is too vague for a specification. > Fix:/This lack of path occurs because alternate paths can be hidden by nodes of an AS."/ [Bruno] I agree that your proposed text makes it more explicit, which is always better in a specification (when it's not redundant). However, I would note 2 points: - section 3 is part of the introduction to the problem space. It explains the root cause of the problem. It's not part of the graceful shutdown specification. - The text you are referring to is a paragraph starting with: "First, some routers can have no path toward an affected prefix, and drop traffic destined to this prefix. This is because alternate paths can be hidden by nodes of an AS." Hence "This" refers to the short sentence which is immediately before. I don't feel that there is much ambiguity. That being said, as you classify your comment as an editorial nit, I could propose to forward it to the RFC editor, and let the RFC editor propose a resolution. Would this be ok for you? Thanks, Best regards, --Bruno ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Genart last call review of draft-ietf-grow-bgp-gshut-11
Job Snijders writes: > > The LOCAL_PREF choice here is a simple thing -- don't make it more > > complicated than it needs to be. > > > > Job's suggested text says all that's necessary: > > > > "The LOCAL_PREF value SHOULD be lower than any of the alternative > > paths. Zero being the lowest value, it MAY be used whichever > > LOCAL_PREF values are used by the AS." > > The above comes from Bruno's hand, I actually proposed the following: > > "The LOCAL_PREF value SHOULD be lower than any of the > alternative paths. It is RECOMMEND to use 0, the lowest LOCAL_PREF > value." > > Kind regards, > > Job Sorry for my mis-citing / mis-quoting. Let me try my hand: The LOCAL_PREF value SHOULD be lower than any of the alternative paths. The RECOMMENDED value is 0. Thanks. Jay B. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Genart last call review of draft-ietf-grow-bgp-gshut-11
David Farmer writes: > I would prefer a normative RECOMMENDED, the rest of the sentence in > RFC2119, just means you should explain the constraints on the alternatives. > How about something like this; > > "The LOCAL_PREF value SHOULD be lower than any of the alternative > paths. A LOCAL_PREF > value of Zero is RECOMMENDED, however any LOCAL_PREF value lower than all > other LOCAL_PREF values used within an AS is an acceptable alternative. > The LOCAL_PREF value used, Zero or otherwise, SHOULD NOT also > have another use or meaning within the AS." > The LOCAL_PREF choice here is a simple thing -- don't make it more complicated than it needs to be. Job's suggested text says all that's necessary: "The LOCAL_PREF value SHOULD be lower than any of the alternative paths. Zero being the lowest value, it MAY be used whichever LOCAL_PREF values are used by the AS." Thanks. Jay B. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] working group last call draft-ietf-grow-bgp-gshut
Thanks, Chris. With the draft-ietf-grow-bgp-gshut-11 that Bruno posted earlier today, I fully support moving ahead with publication. Jay B. On 17-Aug-2017, Christopher Morrow writes: > I agree the document is almost done, I think there's one commentor waiting > on Bruno to return from holidays to chat him up... > > please wait on jayb@att to say something in this thread before sending > along. > > On Thu, Aug 17, 2017 at 10:49 AM, Jeffrey Haas wrote: > > > On Mon, Jul 24, 2017 at 03:13:04PM +, Peter Schoenmaker wrote: > > > As discussed in the working group meeting in Prague, > > draft-ietf-grow-bgp-gshut is ready for last call. The last call will be 3 > > weeks ending August 11th 2017. Please review the document and provide > > feedback. > > > > I'm late in responding, as usual. > > > > The document is ready to go. > > > > -- Jeff > > > > ___ > > GROW mailing list > > GROW@ietf.org > > https://www.ietf.org/mailman/listinfo/grow > > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-blackholing-02.txt
Christopher Morrow writes: > On Tue, Jul 5, 2016 at 10:24 AM, Jay Borkenhagen wrote: > > > confusion and disappointment: "I sent the BLACKHOLE community to > > upstream-X and to upstream-Y, and I got different results. How come?" > > > > Doesn't this presuppose that the community ends up making some action > happen by default? the draft skips talking about default-action (vendor > enforced action), and I think leaves the implementation up to the > provider/operator. > > So... in the end your providerX may accept BLACKHOLE and 'blackhole' or > they may just 'drop on output port'. While providerY may not do anything > with BLACKHOLE, just because they don't believe in that sort of magic. > > This is the same situation as we have today: "I sent 7018:666, nothing > happened?" "Oh! you forgot to do the setup-dance with 7018..." > (s/7018/ANY/). Hi Chris, I'm not presupposing any default action (and I agree router vendors should not attempt any default action in this regard). Here's the comparison I think should be made: Today anyone who wants to use RTBH has a number of things they need to know about their providers' implementations: - is RTBH supported? if so: - what signaling community is used? - in-band or special ebgp-multihop session? - host-route only, or something different? - is any pre-arrangement necessary, and has it been taken care of? - will a maximum duration be enforced? If this draft proceeds and is successful in standardizing a signaling community, only one item has been removed from that list. That doesn't seem like a big win to me. Thanks. Jay B. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-blackholing-02.txt
My comments on draft-ietf-grow-blackholing-02: - If the only purpose of the draft is to standardize the RTBH signaling community, wouldn't a better approach be to attempt to update RFC5635? - Standardizing the RTBH signaling community is insufficient, as the party who wants to use it also needs to know where to signal: "in-band" with all the other route announcements, or via the dedicated ebgp-multihop session that some providers use? The last time I checked, some providers do it one way, and some the other; some customers prefer upstreams who do it one way, some the other. Yes, if you are under attack, I'm sure it's annoying to have to locate the RTBH community of each of your upstream providers. But I would argue that it's critical for anyone using RTBH service from their upstreams to know key aspects of each provider's RTBH implementation: - in-band or ebgp-multihop? - host routes only, or other ranges as well? - does the provider require pre-arrangement? - does the provider enforce a maximum duration of RTBH? - what does the provider do with RTBH announcements on prefix-lengths the provider says are out-of-scope? e.g. if a provider says RTBH only on ipv4 /32 routes, yet the customer announces a /31 or a /24 with the RTBH community? Bottom line, I feel that standardizing the RTBH signaling community does not bring enough benefit, and it sets the stage for customer confusion and disappointment: "I sent the BLACKHOLE community to upstream-X and to upstream-Y, and I got different results. How come?" Thanks. Jay B. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
