Subject: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 18 Mar 2017 01:49:52 +0000

Hi chairs,

We are implementing
https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09
and would like IANA to allocate the code 9 for the Hard Reset subcode in the
BGP Cease NOTIFICATION message subcodes registry.

Thanks,
Jakob.

---

From: Job Snijders <[email-masked]>
Date: Sat, 18 Mar 2017 10:53:53 +0000

Hi everyone,

Given the 50+ years of combined IETF experience the authors of this draft
possess, I'm somewhat surprised to see a suggested value in the IANA
considerations instead of "TBD". See the last major bullet point here:
https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-related%20draft

Jakob, thanks for kicking of the process to rectify this situation.

Furthermore, shouldn't the "Hard Reset" be called "Really Really Really
Reset"? I am skeptical whether the principles of graceful restart should be
applied to the notification mechanism. In
https://tools.ietf.org/html/draft-iops-grow-bgp-session-culling-00 we are
describing a procedure that strongly relies on the currently understood
semantics of expiration of BGP Hold Timers and the Administrative Shutdown:
"STOP sending traffic".

I find it hard to reconcile how we can have both "My control-plane
temporarily going away, but keep sending traffic" and "data-plane is
broken, bgp subsequently dies, don't send traffic". The exact failure
scenario which triggers the expiration of the BGP Hold Timers cannot be
known at OPEN when the capabilities are exchanged. The GR NOTIFICATION
seems to distort the congruency between data-plane and control-plane.

Perhaps there should be an implementation guideline which encourages
vendors to by default, disable this mechanism on non-RFC3021/RFC6164 links?

Has draft-idr-bgp-gr-notification been vetted in the wild? What were the
results and under which circumstances is the mechanism useful? Am I missing
something?

Kind regards,

Job

On Sat, 18 Mar 2017 at 02:50, Jakob Heitz (jheitz) <[email-masked]> wrote:

Hi chairs,

We are implementing

Thanks,

Jakob.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 18 Mar 2017 10:06:47 -0400

Jakob: 

The steps in this process are IPR call, and then call for the WG for
allocation.   Could you round up your authors to respond rapidly to the IPR
call? 

Sue Hares 

From: Jakob Heitz (jheitz) [mailto:[email-masked]] 
Sent: Friday, March 17, 2017 9:50 PM
To: [email-masked]; [email-masked]
Cc: Mohammed Mirza (mohamirz)
Subject: Early allocation for draft-ietf-idr-bgp-gr-notification

Hi chairs,

We are implementing

Thanks,

Jakob.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 20 Mar 2017 17:49:58 +0000

Keyur, Rex, John, Jeff,

Do you know of any IPR related to the draft?

Thanks,
Jakob.

From: Susan Hares [mailto:[email-masked]]
Sent: Saturday, March 18, 2017 7:07 AM
To: Jakob Heitz (jheitz) <[email-masked]>; [email-masked]; [email-masked]
Cc: Mohammed Mirza (mohamirz) <[email-masked]>
Subject: RE: Early allocation for draft-ietf-idr-bgp-gr-notification

Jakob:

The steps in this process are IPR call, and then call for the WG for allocation.   Could you round up your authors to respond rapidly to the IPR call?

Sue Hares

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi chairs,

We are implementing

Thanks,
Jakob.

---

From: Keyur Patel <[email-masked]>
Date: Mon, 20 Mar 2017 17:54:37 +0000

Jakob,

I am not aware of any IPR related to the draft.

Regards,
Keyur

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Monday, March 20, 2017 at 10:49 AM
To: Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>, Keyur Patel <[email-masked]>, "Rex Fernando (rex)" <[email-masked]>, John Scudder <[email-masked]>, Jeff Haas <[email-masked]>
Cc: "Mohammed Mirza (mohamirz)" <[email-masked]>
Subject: RE: Early allocation for draft-ietf-idr-bgp-gr-notification

Keyur, Rex, John, Jeff,

Thanks,
Jakob.

Jakob:

Sue Hares

Hi chairs,

We are implementing

Thanks,
Jakob.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Mar 2017 15:33:06 -0400

> Do you know of any IPR related to the draft?

I know of know IPR on this draft.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Mar 2017 15:35:02 -0400

> BGP Cease NOTIFICATION message subcodes registry.

Further, Juniper has shipping code for this sub-code (9).

I spent some time looking for my requests for early IANA allocation, and
appear to have missed this in my queue.  Given my prior presentations on
such squatting, I shall accept a mea culpa on behalf of Juniper.

Probably time to do a full draft audit to see what else I've missed.  Sigh.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Mar 2017 15:44:14 -0400

Job,

> https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-related%20draft

Unfortunately it's not an uncommon practice, and one we're moving out of
thankfully.  If you look around other working groups, even other BGP working
groups like bess, it's not uncommon.

> semantics of expiration of BGP Hold Timers and the Administrative Shutdown:

I haven't yet read this draft, so take my further comments with that under
consideration.

> results and under which circumstances is the mechanism useful? Am I missing

The non-obvious connection is it's a requirement of
draft-uttaro-idr-bgp-persistence (long-lived graceful restart).  There's
code shipping for this feature.  I *believe* that it's another vendor as
well, but can't confirm from memory.  

There has been some discussion that LLGR needs to be resurrected from zombie
draft state.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 20 Mar 2017 15:43:15 -0400

Nope.

--John

> On Mar 20, 2017, at 1:49 PM, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 
> Keyur, Rex, John, Jeff,
>  
> From: Jakob Heitz (jheitz) [mailto:[email-masked] <mailto:[email-masked]>] 
> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09 <https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Mar 2017 15:51:31 -0400

Jakob points out:

: Jeff,
:
: I'm not sure how pedantic lawyers get about typos :)
: know-->no

So, yes, I know of *no* IPR on this draft.

-- Jeff (whose brain is apparently running on autopilot homonym mode)

:
: Thanks,
: Jakob.
:
:
: > -----Original Message-----
: > From: Jeffrey Haas [mailto:[email-masked]]
: > Sent: Monday, March 20, 2017 12:33 PM
: > To: Jakob Heitz (jheitz) <[email-masked]>
: > Cc: Susan Hares <[email-masked]>; [email-masked]; Keyur Patel
: > <[email-masked]>; Rex Fernando (rex) <[email-masked]>;
: > John Scudder <[email-masked]>; Jeff Haas <[email-masked]>
: > Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification
: >
: >
: > On Mon, Mar 20, 2017 at 05:49:58PM +0000, Jakob Heitz (jheitz) wrote:
: > > Keyur, Rex, John, Jeff,
: > >
: > > Do you know of any IPR related to the draft?
: >
: > I know of know IPR on this draft.
: >

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 20 Mar 2017 15:45:31 -0400

On Mar 18, 2017, at 6:53 AM, Job Snijders <[email-masked]> wrote:
> Given the 50+ years of combined IETF experience the authors of this draft possess, I'm somewhat surprised to see a suggested value in the IANA considerations instead of "TBD". See the last major bullet point here: https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-related%20draft <https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-related%20draft>
Considering my name's in the list at the top of the draft, and that I wrote the bullet point in question, that's on me. This is what you should not do.

If someone brings a dunce cap for me to wear during the chair's portion of the meeting, I will.

--John

---

From: Job Snijders <[email-masked]>
Date: Mon, 20 Mar 2017 21:14:55 +0100

Hi Jeff,

On Mon, Mar 20, 2017 at 03:44:14PM -0400, Jeffrey Haas wrote:
> > Furthermore, shouldn't the "Hard Reset" be called "Really Really
> > Really Reset"? I am skeptical whether the principles of graceful
> > restart should be applied to the notification mechanism. In
> > describing a procedure that strongly relies on the currently
> > understood semantics of expiration of BGP Hold Timers and the
> > Administrative Shutdown: "STOP sending traffic".
> 

ack. Please read the draft. We may have a fundamental problem on our
hands here.

> > seems to distort the congruency between data-plane and control-plane.

1/ To emphasize the congruency issue here: BGP Hold Timer expiration
often (from the Operator's perspective) an unplanned event. BGP Hold
Timers usually expire because there is an issue with the lower layer
network. If there is an issue with the lower layer network, we should
not continue to forward traffic over that path. If I understand
draft-ietf-idr-bgp-gr-notification correctly, that is what would happen
if both sides through capabilities negotation understand they both
support draft-ietf-idr-bgp-gr-notification.

"make before break" or "ignore this break" are doable when events are
planned, but this draft touches upon scenarios which happen without
planning from the operator's side, where we should be careful with our
assumptions about why a Hold Timer expired.

> > Has draft-idr-bgp-gr-notification been vetted in the wild? What were
> > the results and under which circumstances is the mechanism useful?
> > Am I missing something?
> 
> draft-uttaro-idr-bgp-persistence (long-lived graceful restart).
> There's code shipping for this feature.  I *believe* that it's another
> vendor as well, but can't confirm from memory.  
> 
> There has been some discussion that LLGR needs to be resurrected from
> zombie draft state.

2/ So draft-uttaro-idr-bgp-persistence is zombie from IETF perspective,
but there is shipping code, so in order to resurrect
draft-uttaro-idr-bgp-persistence properly (and finish the project?),
draft-ietf-idr-bgp-gr-notification needs to move forward, is that the
chain of events?

3/ If I may ask, why isn't BGP Cease NOTIFICATION message subcode 4
"Administrative Reset" used to perform the 'hard reset' function, and
isn't subcode 9 (the suggested value) requested as a new feature called
'soft reset'? This way we don't break people's preconceptions about what
it means to type in "clear neighbor 1.2.3.4"..

By declaring "subcode 9" to be a hard clear, it appears to me the
meaning of 'Administrative Reset (subcode 4)' is redefined, and
redefining existing constructs might not be an easy task.

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 20 Mar 2017 16:41:25 -0400

On Mon, Mar 20, 2017 at 09:14:55PM +0100, Job Snijders wrote:
[session culling]
> ack. Please read the draft. We may have a fundamental problem on our

I read it. It's a weird hack, but it works. :-)

> support draft-ietf-idr-bgp-gr-notification.

I suspect the point you've overlooked is the N-bit is intended to indicate
support for this on a per AFI-SAFI basis.  This is something you have to
explicitly ask for.  It also isn't something that makes sense in many
scenarios, especially Internet.

> draft-ietf-idr-bgp-gr-notification needs to move forward, is that the

It's a dependency, yes.

> it means to type in "clear neighbor 1.2.3.4"..

It will depend on whether you want to trigger this behavior or not.  The
semantics change from simply "I typed clear bgp" to "this session must not
go through this mechanism if you've configured it".

> redefining existing constructs might not be an easy task.

Naming things is one of the two traditionally hard problems of computer
science. 

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 20 Mar 2017 17:49:50 -0400

> I read it. It's a weird hack, but it works. :-)

With respect to what "culling" calls "Voluntary BGP Session Teardown", there's no problem. A pair of implementations that implement gr-notification would already be expected to do the right thing when the session was administratively shut down, by sending a hard reset.

With respect to what "culling" calls "Involuntary BGP Session Teardown", there is potentially a problem, but I think it's not insurmountable. The problem, to the extent it exists, is that "culling" suggests the IX switch fabric should be configured to block BGP traffic, causing the hold time to expire. gr-notification interferes by putting the session into GR mode:

   When a BGP speaker resets its session due to a HOLDTIME expiry, it
   should generate the relevant BGP NOTIFICATION message as mentioned in
   [RFC4271], but subsequently it MUST follow the rules for the
   Receiving Speaker mentioned in Section 4.1.

At first this might seem alarming, but my observation is that the weird hack already relies on waiting several minutes for the hold time to expire. So, it doesn't seem terrible to add a few more minutes to wait for the stale route timeout as well. Although "culling" doesn't discuss how to determine the maintenance can proceed, it would seem both prudent and straightforward to do so by monitoring the traffic level between the affected peers, since presumably the IX operator doesn't have a priori knowledge of the hold time in use. Once routing has converged away from the path, the traffic level will drop, and the maintenance can proceed, regardless of what perversions are in use in the control plane. 

--John

P.S.: I take no position, in this note, as to whether the suggestion in "culling" to filter BGP control traffic as an IX management practice is a good one.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 21 Mar 2017 10:49:34 +0000

John G. Scudder wrote:
> Although "culling" doesn't discuss how to determine the maintenance
> can proceed, it would seem both prudent and straightforward to do so
> by monitoring the traffic level between the affected peers

this is what is done in practice, yes.  Low tech, but it works fine.

> P.S.: I take no position, in this note, as to whether the suggestion
> in "culling" to filter BGP control traffic as an IX management
> practice is a good one.

Purists will argue that it is a hacky layering violation; but from a
production point of view, it's been found to be an effective way of
eliminating the effects of what can otherwise be highly disruptive work.

Nick

---

From: Job Snijders <[email-masked]>
Date: Tue, 21 Mar 2017 16:24:01 +0100

On Mon, Mar 20, 2017 at 04:41:25PM -0400, Jeffrey Haas wrote:
> > > I haven't yet read this draft, so take my further comments with
> > > that under consideration.
> > 
> > network. If there is an issue with the lower layer network, we
> > should not continue to forward traffic over that path. If I
> > understand draft-ietf-idr-bgp-gr-notification correctly, that is
> > what would happen if both sides through capabilities negotation
> > understand they both support draft-ietf-idr-bgp-gr-notification.
> 
> I suspect the point you've overlooked is the N-bit is intended to
> indicate support for this on a per AFI-SAFI basis.  This is something
> you have to explicitly ask for.

Yes, but since a number of days or even weeks, can pass between when you
ask for it at OPEN, and when a NOTIFICATION event actually occurs,
circumstances might have changed.

> It also isn't something that makes sense in many scenarios, especially
> Internet.

I'm happy to read that we're finding common understanding on the
applicability of GR Notification. Perhaps a note to that point would be
useful?

> go through this mechanism if you've configured it".

ack.

> Naming things is one of the two traditionally hard problems of computer

mmm, regardless, since there is code in the wild we may already have
passed the naming station.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Tue, 21 Mar 2017 16:28:31 +0100

On Mon, Mar 20, 2017 at 05:49:50PM -0400, John G. Scudder wrote:
> With respect to what "culling" calls "Involuntary BGP Session
> Teardown", there is potentially a problem, but I think it's not
> insurmountable. The problem, to the extent it exists, is that
> "culling" suggests the IX switch fabric should be configured to block
> BGP traffic, causing the hold time to expire. gr-notification
> interferes by putting the session into GR mode:
> 
> At first this might seem alarming, but my observation is that the
> weird hack already relies on waiting several minutes for the hold time
> to expire. So, it doesn't seem terrible to add a few more minutes to
> wait for the stale route timeout as well.

Your analysis is helpful. We might add a note to the bgp-culling draft
that "GR Notification" could negatively affect with the minimum required
bgp culling time spam.

> by monitoring the traffic level between the affected peers, since
> presumably the IX operator doesn't have a priori knowledge of the hold
> time in use. Once routing has converged away from the path, the
> traffic level will drop, and the maintenance can proceed, regardless
> of what perversions are in use in the control plane. 

Correct.

Kind regards,

Job

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Mar 2017 12:59:03 -0400

John: 

Will you revise the draft prior to early allocation call to remove this code
point? 

Sue Hares

(co-chair hat) 

From: John G. Scudder [mailto:[email-masked]] 
Sent: Monday, March 20, 2017 3:46 PM
To: Job Snijders
Cc: Jakob Heitz (jheitz); [email-masked]; [email-masked]
Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification

Given the 50+ years of combined IETF experience the authors of this draft
possess, I'm somewhat surprised to see a suggested value in the IANA
considerations instead of "TBD". See the last major bullet point here:
https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-rela
ted%20draft

Considering my name's in the list at the top of the draft, and that I wrote
the bullet point in question, that's on me. This is what you should not do.

If someone brings a dunce cap for me to wear during the chair's portion of
the meeting, I will.

--John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Mar 2017 13:09:21 -0400

John, Jeff, Keyur and Job: 

It sounds like these two drafts are protocol and grow operational notes.
Is this correct? 

Sue 

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]] 
Sent: Monday, March 20, 2017 5:50 PM
To: Jeffrey Haas; Job Snijders
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification

On Mar 20, 2017, at 4:41 PM, Jeffrey Haas <[email-masked]> wrote:
>>> I haven't yet read this draft, so take my further comments with that 
>>> under consideration.
>> 

With respect to what "culling" calls "Voluntary BGP Session Teardown",
there's no problem. A pair of implementations that implement gr-notification
would already be expected to do the right thing when the session was
administratively shut down, by sending a hard reset.

With respect to what "culling" calls "Involuntary BGP Session Teardown",
there is potentially a problem, but I think it's not insurmountable. The
problem, to the extent it exists, is that "culling" suggests the IX switch
fabric should be configured to block BGP traffic, causing the hold time to
expire. gr-notification interferes by putting the session into GR mode:

At first this might seem alarming, but my observation is that the weird hack
already relies on waiting several minutes for the hold time to expire. So,
it doesn't seem terrible to add a few more minutes to wait for the stale
route timeout as well. Although "culling" doesn't discuss how to determine
the maintenance can proceed, it would seem both prudent and straightforward
to do so by monitoring the traffic level between the affected peers, since
presumably the IX operator doesn't have a priori knowledge of the hold time
in use. Once routing has converged away from the path, the traffic level
will drop, and the maintenance can proceed, regardless of what perversions
are in use in the control plane. 

--John

P.S.: I take no position, in this note, as to whether the suggestion in
"culling" to filter BGP control traffic as an IX management practice is a
good one.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 21 Mar 2017 13:51:54 -0400

Hi Sue,

On Mar 21, 2017, at 12:59 PM, Susan Hares <[email-masked]> wrote:
> Will you revise the draft prior to early allocation call to remove this code point? 

I have the revised draft queued and ready to go as soon as submissions reopen at 2017-03-26 23:59 CDT. The sole change is to remove the offending "suggested value".

Thanks,

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 21 Mar 2017 15:45:54 -0400

> such squatting, I shall accept a mea culpa on behalf of Juniper.

The thread has prompting me to dig through the idr archives since I didn't                                                                                                                                                    
find the appropriate thing in my work inbox (I have another one to check):                                                                                                                                                    
                                                                                                                                                                                                                              
https://mailarchive.ietf.org/arch/search/?q=subject%3Adraft-ietf-idr-bgp-gr-notification&f_list=idr                                                                                                                           
                                                                                                                                                                                                                              
See message posted 2014-04-28,                                                                                                                                                                                                
subject "[Idr] Early allocation request for
draft-ietf-idr-bgp-gr-notification-01"                                                                                                                                            
                                                                                                                                                                                                                              
Similarly see request for WGLC on May 2014.                                                                                                                                                                                   
                                                                                                                                                                                                                              
-- Jeff