Subject: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

From: Warren Kumari <[email-masked]>
Date: Tue, 22 May 2018 11:53:03 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-idr-bgp-gr-notification-15: 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-idr-bgp-gr-notification/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm sure that this has already been discussed somewhere, and that I'll be able
to quickly clear my DISCUSS once pointed at it, but: "To put an upper bound on
the amount of time a router retains the stale routes, an implementation MUST
support a (configurable) timer, called the "stale timer", that imposes this
upper bound. A suggested default value for the stale timer is 180 seconds. An
implementation MAY provide the option to disable the timer (i.e., to provide an
infinite retention time) but MUST NOT do so by default."

The "infinite retention time" part of this makes me deeply uncomfortable -- I
can see a good reason for the stale timer, and the default "feels" fine to me,
but having an infinite retention time (or, really anything over 10 to 15
minutes) feels like a really dangerous idea, and that it will come back and
bite.

I'm hoping that I'm missing something obvious, but can you please explain under
what conditions an infinite retention policy makes sense? It seems like there
would be multiple opportunities for blackholing traffic with this.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 May 2018 21:17:08 +0200

Hi Warren,

To understand this proposal a little lecture of document which was proposed
before this one and which in fact triggered this extension can be helpful:

https://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-03

Effectively here authors propose to allow BGP speaker to run in a headless
mode indefinitely. The root of the idea was born when pure control plane
single vendor RRs go down for hours and otherwise healthy PEs running in
healthy network stop serving 1000s of VPN customers.

I think at this stage I will refrain from stating an opinion on it. All I
can say is that operators today can use so many other dangerous knobs in
various address families of BGP that adding this configuration flexibility
to GR stale timer option here will rather not make it much worse :)

Kind regards,
Robert.

On Tue, May 22, 2018 at 8:53 PM, Warren Kumari <[email-masked]> wrote:

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 May 2018 15:21:53 -0400

Warren,

> On May 22, 2018, at 2:53 PM, Warren Kumari <[email-masked]> wrote:

This is a point where I point at your supposed opeational background and suggest shame on you. :-)

For my part, I would rather see this option discussed and given a caveat rather than elided from the specification.  Otherwise you simply have vendors who've implemented such an option and someone wagging their finger at their supposed non-conformance.  And it's usually some operator that wanted the thing present in the first place!

> would be multiple opportunities for blackholing traffic with this.

There are situations, especially closed L3VPN networks, where infinite retention is potentially desired.  In situations where such a knob is configured and the operator decides that the underlying behavior needs to be addressed, a reset of the necessary session state could be done.  E.g. deconfigure the peer.

It should be noted that earlier forms of the long lived graceful restart feature, which this was intended to service, tried to provide significant caveats about not applying the feature to address families like those carrying the Internet for exactly the reason you're concerned with.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 May 2018 21:35:13 +0200

​Hi Jeff,​

> suggest shame on you. :-)

​I think ​it should be pointed out that there is difference between sound
operational reasons and simply bad network design.

If someone would deploy in a network route reflectors (and in fact also
routers) from multiple vendors (let's be brave and say 3 or 4) probability
that all implementations would go down on given trigger is highly reduced -
perhaps to the extend that no outage would occur and no one would propose
to make BGP state persistent ;-).

Here my only worry is that we are stretching protocol(s) to cover for wrong
choices of network architecture.

Best,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 May 2018 16:12:20 -0400

Robert,

> On May 22, 2018, at 3:35 PM, Robert Raszuk <[email-masked]> wrote:
> 
> ​Hi Jeff,​
>  
> ​I think ​it should be pointed out that there is difference between sound operational reasons and simply bad network design. 
> 
> If someone would deploy in a network route reflectors (and in fact also routers) from multiple vendors (let's be brave and say 3 or 4) probability that all implementations would go down on given trigger is highly reduced - perhaps to the extend that no outage would occur and no one would propose to make BGP state persistent ;-). 
> 
> Here my only worry is that we are stretching protocol(s) to cover for wrong choices of network architecture. 

Since it seems my attempt at humor was overly broad (I believe Warren is likely to have taken it with its original intent), this is more a jab at the focus on a knob that is not usually a good idea usually being something that ends up in code mostly at the pressure of the operators/customers.  We call such features "rope (to hang yourself with)" for good cause.  Warren is thus pointing out the thing that as a customer he may have asked for in the first place. :-)

While I generally sympathize with your approach to network heterogeneity as a mechanism for achieving better fault tolerance, I also consider it optimistic.

-- Jeff

---

From: heasley <[email-masked]>
Date: Tue, 22 May 2018 21:35:49 +0000

Tue, May 22, 2018 at 09:35:13PM +0200, Robert Raszuk:
> I think it should be pointed out that there is difference between sound

be careful not to lecture operators on their financial, regulatory or other
limitations.  Let them make the informed decisions best for their constraints.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 22 May 2018 17:37:43 -0400

On Tue, May 22, 2018 at 4:12 PM Jeffrey Haas <[email-masked]> wrote:

> Since it seems my attempt at humor was overly broad (I believe Warren is
> likely to have taken it with its original intent), this is more a jab at
> the focus on a knob that is not usually a good idea usually being something
> that ends up in code mostly at the pressure of the operators/customers.
>

https://www.youtube.com/watch?v=2HmcrZwb7OA​

>  We call such features "rope (to hang yourself with)" for good cause.
> Warren is thus pointing out the thing that as a customer he may have asked
> for in the first place. :-)
>

​Yeah, but there is also a difference between "​This is might a bad idea,
but we need it for this funky reason, so, er, please?" and "Let's put it in
a Standards Track document, with no warnings. What could go wrong?!" :-P

Perhaps adding something like:
"An implementation MAY provide the option to disable the timer
(i.e., to provide an infinite retention time) but MUST NOT do so
by default. Note that long (or infinite) retention time may cause
operational issues, and should be enabled with care."
or:
The impact of long retention times should be carefully considered
or:
This option should only be used by consenting adults
:-)

​Anyway, the fact that this is in "updating" / "new" text means that we
need to be careful not to overstep, but I think that having some warning
would be useful to help minimize people shooting themselves in the foot.

​W​

> While I generally sympathize with your approach to network heterogeneity
> as a mechanism for achieving better fault tolerance, I also consider it
> optimistic.
>
> -- Jeff
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 22 May 2018 22:02:51 +0000

There were a number of scenarios where the control plane could be compromised. It is important to be aware that the intention here was for services that were configuration i.e VPLS/BGP ( Kompella ), FlowSpec and “staler” services i.e L3VPN where an operator would prefer a degree of incorrectness as opposed to a total outage..

I am speaking from a perspective of AT&T’s network.

a)      RR Plane Failure – AT&T runs a large L3VPN network, the amount of state easily reaches into the tens of millions. To accommodate this state I employed an architecture/design that disseminates the state across multiple planes of RRs with a given VPN’s routes spread across the planes. Assuming each plane accommodates ~1M routes the risk to a significant outage where an entire plane is compromised would be the percentage of that VPNs routes on that given plane. The planes are made of gear from multiple vendors but we have seen an ill formed message from a  bad actor take out an entire plane.

b)      Isolation – Geography in different parts of the world may cause a part of the network to be disconnected from the control plane. I have seen this in Africa, Asia and the states. As an ex… If my RR pair is in Atlanta and provides control plane for Florida a loss of the Atl RRs will cause an intra-FLA failure.. So a BGP/VPWS circuit between Miami and Tampa would be compromised by the loss of the Atl RRs. One may suggest that the answer is simple and one can simple increase the densification of RRs. Of course it would be RR pair * Planes for a given service. This is a poor tradeoff that will be incremental in nature

At the end of the day BGP is used for far more than originally envisioned with many “configuration” applications ( FlowSpec, BGP/VPLS ), reporting applications ( BGP-LS …. ).. BGP Persistence provides a simple method to maintain forwarding and leaves it to the discretion of the operator in terms of stale time, services etc….

Thanks,
                Jim Uttaro

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, May 22, 2018 3:17 PM
To: Warren Kumari <[email-masked]>
Cc: idr wg <[email-masked]>; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

Hi Warren,

To understand this proposal a little lecture of document which was proposed before this one and which in fact triggered this extension can be helpful:

https://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Duttaro-2Didr-2Dbgp-2Dpersistence-2D03&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=955eCkzPnHmGvjeK4BONsl3__kIMKUbrTFi3nkBzyjM&s=Mfi0hMnnFb0vEnycEIXjQgmkfYxT-y3LnpZJ3cFmKzk&e=>

Effectively here authors propose to allow BGP speaker to run in a headless mode indefinitely. The root of the idea was born when pure control plane single vendor RRs go down for hours and otherwise healthy PEs running in healthy network stop serving 1000s of VPN customers.

I think at this stage I will refrain from stating an opinion on it. All I can say is that operators today can use so many other dangerous knobs in various address families of BGP that adding this configuration flexibility to GR stale timer option here will rather not make it much worse :)

Kind regards,
Robert.

On Tue, May 22, 2018 at 8:53 PM, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:
Warren Kumari has entered the following ballot position for
draft-ietf-idr-bgp-gr-notification-15: Discuss

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=955eCkzPnHmGvjeK4BONsl3__kIMKUbrTFi3nkBzyjM&s=3Tbh94yAZspqlfRQHR4YPGTsgU-hJEpeMUuPOkEaZPQ&e=>
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-idr-bgp-gr-notification/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dbgp-2Dgr-2Dnotification_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=955eCkzPnHmGvjeK4BONsl3__kIMKUbrTFi3nkBzyjM&s=kYoC7D2UM0o-LWBCEFUaHYVXhS82I2AZeROv52MtJec&e=>

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=955eCkzPnHmGvjeK4BONsl3__kIMKUbrTFi3nkBzyjM&s=ieg4cO4Kawle23szINir4SwrtTBmGKMSsylYY6gy9qk&e=>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 22 May 2018 22:04:42 +0000

Warren,

                I responded to this thread below.. If you would like to have a meeting to dive deeper to better understand the use cases I would be glad to meet…

Thanks,
                Jim Uttaro

From: Idr [mailto:[email-masked]] On Behalf Of Warren Kumari
Sent: Tuesday, May 22, 2018 5:38 PM
To: Jeffrey Haas <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; The IESG <[email-masked]>; Robert Raszuk <[email-masked]>
Subject: Re: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

On Tue, May 22, 2018 at 4:12 PM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

On May 22, 2018, at 3:35 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

​Hi Jeff,​

Since it seems my attempt at humor was overly broad (I believe Warren is likely to have taken it with its original intent), this is more a jab at the focus on a knob that is not usually a good idea usually being something that ends up in code mostly at the pressure of the operators/customers.

https://www.youtube.com/watch?v=2HmcrZwb7OA<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3D2HmcrZwb7OA&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=-lls2cLjvnTdMdXcY64sd71JtmNGJmp84ERe2zsbRS0&s=9cIoAZ73JHgcML45sV3kvS2_vc7O1YKdUE2-trA43p0&e=>​

 We call such features "rope (to hang yourself with)" for good cause.  Warren is thus pointing out the thing that as a customer he may have asked for in the first place. :-)

​Yeah, but there is also a difference between "​This is might a bad idea, but we need it for this funky reason, so, er, please?" and "Let's put it in a Standards Track document, with no warnings. What could go wrong?!" :-P

​Anyway, the fact that this is in "updating" / "new" text means that we need to be careful not to overstep, but I think that having some warning would be useful to help minimize people shooting themselves in the foot.

​W​

-- Jeff

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

---

From: <[email-masked]>
Date: Wed, 23 May 2018 07:19:23 +0000

Warren, all

I would personally be fine with adding your proposed one sentence warning (possibly in the operational/management consideration section)

That being said, since you asked for a discussion:
1) +1 to James’ email

2) Note that draft-ietf-idr-bgp-gr-notification is making things safer as it is _adding_ a mandated timer to Graceful Restart (GR). IOW, with current BGP GR RFC one may have no way of limiting this duration.

3) I may be wrong (please correct), but my reading of the BGP spec is that RFC 4271 allows for an infinite Hold Time timer (when set to 0).

4) There is no way we’ll all agree on what “max value” should be in general. e.g. you picked “10 to 15 minutes” while BGP Graceful Restart already allows for a 68 minutes restart time and BGP for a 18 hours Hold Time (and the effect of those timers seems “worse” that the stale time IMHO). At some point, e.g. 1 hour, this will be handled by a human; so “Infinite” mostly means that we don’t want the BGP process to make the decision, which is deferred to a human (or any kind of SDN controller in a post human world)

Thanks,
Best regards,
--Bruno

From: Idr [mailto:[email-masked]] On Behalf Of Warren Kumari
Sent: Tuesday, May 22, 2018 11:38 PM
To: Jeffrey Haas
Cc: idr@ietf. org; The IESG; Robert Raszuk
Subject: Re: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

​Hi Jeff,​

​W​

-- Jeff

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 23 May 2018 15:42:01 -0400

On Wed, May 23, 2018 at 3:19 AM <[email-masked]> wrote:

> Warren, all
>
>
>
> I would personally be fine with adding your proposed one sentence warning
> (possibly in the operational/management consideration section)
>

​Awesome, thanks. Mainly I wanted to make sure it had been considered --
I'll go clear my DISCUSS.

> 2) Note that draft-ietf-idr-bgp-gr-notification is making things safer as
> it is _*adding*_ a mandated timer to Graceful Restart (GR). IOW, with
> current BGP GR RFC one may have no way of limiting this duration.
>
>
>
> 3) I may be wrong (please correct), but my reading of the BGP spec is that
> RFC 4271 allows for an infinite Hold Time timer (when set to 0).
>
>
​Yelp! Yeah, this seems to be there from RFC1771, and from RFC1654 before
that. I seem to remember having actually relied on that back in ~1998 to
stop keep alives from making dial-on-demand sessions happen... and now I
feel odl.

> 4) There is no way we’ll all agree on what “max value” should be in
> general. e.g. you picked “10 to 15 minutes” while BGP Graceful Restart
> already allows for a 68 minutes restart time and BGP for a 18 hours Hold
> Time (and the effect of those timers seems “worse” that the stale time
> IMHO). At some point, e.g. 1 hour, this will be handled by a human; so
> “Infinite” mostly means that we don’t want the BGP process to make the
> decision, which is deferred to a human (or any kind of SDN controller in a
> post human world)
>
>
​42!
​
Thanks all,
W

>
>
> Thanks,
>
> Best regards,
>
> --Bruno
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Warren Kumari
> *Sent:* Tuesday, May 22, 2018 11:38 PM
> *To:* Jeffrey Haas
> *Cc:* idr@ietf. org; The IESG; Robert Raszuk
> *Subject:* Re: [Idr] Warren Kumari's Discuss on
> draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)
>
>
>
>
>
>
>

---

From: <[email-masked]>
Date: Wed, 23 May 2018 20:18:30 +0000

Warren,

Thanks for your reply.
1 clarification inline [Bruno]

From: Warren Kumari [mailto:[email-masked]]

On Wed, May 23, 2018 at 3:19 AM <[email-masked]<mailto:[email-masked]>> wrote:
Warren, all

​Awesome, thanks. Mainly I wanted to make sure it had been considered -- I'll go clear my DISCUSS.
[Bruno] To clarify, I was speaking as IDR WG member but I’m not one of the authors. So I was not speaking for the authors.
--Bruno

​Yelp! Yeah, this seems to be there from RFC1771, and from RFC1654 before that. I seem to remember having actually relied on that back in ~1998 to stop keep alives from making dial-on-demand sessions happen... and now I feel odl.

​42!
​
Thanks all,
W

Thanks,
Best regards,
--Bruno

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Warren Kumari
Sent: Tuesday, May 22, 2018 11:38 PM
To: Jeffrey Haas
Cc: idr@ietf. org; The IESG; Robert Raszuk
Subject: Re: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

​Hi Jeff,​

​W​

-- Jeff

Thank you.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 May 2018 21:08:00 -0400

Bruno and Warren: 

Warren has approved so this message is just a follow-up on the message stream. 

As to specifying “0” in Hold Time Timer for RFC4271, the operative text is the following:

   If the negotiated Hold Time interval is zero, then periodic KEEPALIVE

   messages MUST NOT be sent.  (section 4.4) 

This RFC4271 addition (based on deployments)  provided a less “chatty” BGP with Keepalives 

for connection that did not have the need for the “KEEPALIVE” heartbeat. 

Whether this is an infinite timer or something else is a discussion which is academic.  

The important part is the needs of the operators.  

RFC1267 to RFC4271 changed this because the operators needed the less “chatty” KEEPALIVE BGP.   IMHO GR notification improves the situation from RFC4271.    

Sue 

PS - As far as I can tell the state machines for these actions still hang together with all the changes.  However, I’d love to hear from anyone if there is a problem. 

From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, May 23, 2018 3:19 AM
To: Warren Kumari
Cc: idr@ietf. org; UTTARO, JAMES; The IESG; Robert Raszuk
Subject: Re: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

Warren, all

1) +1 to James’ email

Thanks,

Best regards,

--Bruno

 

Robert,

​Hi Jeff,​

 

 

or:

or:

:-)

​W​

-- Jeff

--

---

From: <[email-masked]>
Date: Thu, 24 May 2018 08:36:48 +0000

Sue,

Please see two comments inline [Bruno]

From: Susan Hares [mailto:[email-masked]]
Sent: Thursday, May 24, 2018 3:08 AM
To: DECRAENE Bruno IMT/OLN; 'Warren Kumari'
Cc: 'idr@ietf. org'; 'UTTARO, JAMES'; 'The IESG'; 'Robert Raszuk'
Subject: RE: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

Bruno and Warren:

[Bruno] And also:
      If the negotiated hold time value is zero, then the HoldTimer and
      KeepaliveTimer are not started.
https://tools.ietf.org/html/rfc4271#section-8.2.2  (FSM)

[Bruno] Well, the comment was partly about having an infinite timer for BGP in a STD track document.

Regards,
--Bruno

Sue

Warren, all

Thanks,
Best regards,
--Bruno

​Hi Jeff,​

​W​

-- Jeff

Thank you.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 24 May 2018 05:19:00 -0700

On May 23, 2018 at 4:18:40 PM, [email-masked] (
[email-masked]) wrote:

Hi!

From: Warren Kumari [mailto:[email-masked] <[email-masked]>]

On Wed, May 23, 2018 at 3:19 AM <http://airmail.calendar/2018-05-23
03:19:00 EDT> <[email-masked]> wrote:

Warren, all

[Bruno] To clarify, I was speaking as IDR WG member but I’m not one of the
authors. So I was not speaking for the authors.

Thanks Bruno!  I’ll make sure we do the right thing with this document.

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 24 May 2018 16:31:22 -0400

Bruno:

Agreed – you are correct on the FSM and on the infinite timer.   

When we did RFC4271, we added this feature because it was deployed. 

Sue Hares 

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, May 24, 2018 4:37 AM
To: Susan Hares
Cc: 'idr@ietf. org'; 'UTTARO, JAMES'; 'The IESG'; 'Robert Raszuk'; 'Warren Kumari'
Subject: RE: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

Sue,

Bruno and Warren: 

[Bruno] And also:

 <https://tools.ietf.org/html/rfc4271#section-8.2.2> https://tools.ietf.org/html/rfc4271#section-8.2.2  (FSM)

Regards,

--Bruno

Sue 

 

Warren, all

1) +1 to James’ email

Thanks,

Best regards,

--Bruno

 

Robert,

​Hi Jeff,​

 

 

or:

or:

:-)

​W​

-- Jeff

--