Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt

From: Warren Kumari <[email-masked]>
Date: Tue, 1 Nov 2011 13:22:11 -0400

On Oct 28, 2011, at 4:51 PM, John Scudder wrote:

> Folks,
> 
> Please send comments to the list prior to the IDR meeting on November 15.

Support.
W

> 
> Thanks,
> 
> --John
> 
> On Oct 28, 2011, at 4:49 PM, Enke Chen wrote:
> 
>> Hi, Sue and John:
>> 
>> We would like to request that the following draft be adopted as an IDR WR document:
>> 
>>     draft-keyur-idr-enhanced-gr-00.txt
>> 
>> It's presented at the last IETF.
>> 
>> Thanks.   -- Enke
>> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Gaurav Dawra <[email-masked]>
Date: Sun, 13 Nov 2011 11:08:36 -0500

Support.

Regards,
-Gaurav

-- 
Gaurav Dawra, Software Eng.
[email-masked]  .:|:.:|:.
NSSTG                        CISCO

---

From: Brian Dickson <[email-masked]>
Date: Sun, 13 Nov 2011 18:16:41 -0500

>>> Please send comments to the list prior to the IDR meeting on November 15.

I have some questions, and some concerns.

First, the questions:

Was consideration given to implementing this as an optional,
non-transitive attribute, instead of as a separate message? Or have
the sending party use an attribute with the responder using a message
type to acknowledge?

Also, have you considered using a "marker" message not associated with
a specific NLRI, to simply indicate the latest "window" of messages
which has been processed (rather than merely queued up)? One that is
sent periodically (and possibly also after N messages). This would
behave similar to the "red card" in a casino multi-deck card "shoe",
although instead of "shuffle the cards", the semantics would be
"everything before this has been received". It would be analogous to
TCP sequence numbers, just covering a much larger range of transmitted
data, or analogous to DNS serial numbers (kind of). This would work,
because each BGP peering session is serialized over a single TCP
session. The "marker" is in effect, meta-data used to inform the GR
machinery what NLRIs have/have-not been processed, and thus where GR
can pick up if GR occurs. IMHO, not only is the overhead less (my
orders of magnitude), I think the implementation would be a lot
easier, especially when considering interoperability.

And, here are the concerns:

First, this puts a burden on implementations as far as linking new
state to out-RIB. This in turn could, depending on previous
implementation choices, have impact on performance tied to things like
locking semantics to ensure reliable updates to data structures.

Second, this creates a fixed per-NLRI set of additional performance
overhead. Consider the "marker" message alternative - how do the two
behave during very high demand periods, when significant route updates
occur due to major outages (and not only does a significant percentage
of the NLRI base get affected, but due to path-hunting, each NLRI is
likely to be revisited several or even several dozen times, in a short
interval.) Not tying the GR state to individual updates, is likely to
minimize the risk of GR degrading performance, at exactly the time
where degraded performance becomes a potential causative factor in
routing instability and further collapse of the routing
infrastructure.

Perhaps these questions could be addressed now, prior to adoption?

I'm in favor in principal of having GR enhanced, just not with the
specific manner embodied in the current draft, with all due respect.

(Currently: not in favor.)

Brian

---

From: Brian Dickson <[email-masked]>
Date: Sun, 13 Nov 2011 21:13:31 -0500

Forgive my previous comments, please.

They were based on a mis-reading of the draft.

Support.

Brian

---

From: "Balaji Pitta Venkatachalapathy (bvenkata)" <[email-masked]>
Date: Mon, 14 Nov 2011 09:46:55 +0530

Support!!

Regards,
Balaji

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Scudder
Sent: Friday, October 28, 2011 1:52 PM
To: [email-masked] List
Cc: Keyur Patel (keyupate)
Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt

Folks,

Please send comments to the list prior to the IDR meeting on November
15.

Thanks,

--John

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 14 Nov 2011 00:18:10 -0500

Very useful addition to GR!

Yes/support

Regards,
Jeff

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 14 Nov 2011 00:26:59 -0500

Support.

--
Jakob Heitz.

---

From: Bhavani Parise <[email-masked]>
Date: Sun, 13 Nov 2011 21:27:15 -0800

Support.

regards,
Bhavani

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 14 Nov 2011 06:31:07 +0100

+1

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhavani Parise
Sent: maandag 14 november 2011 6:27
To: [email-masked]
Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt

Support.

regards,
Bhavani

Folks,

Thanks,

--John

Hi, Sue and John:

Thanks.   -- Enke

Idr mailing list

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

---

From: Pierre Francois <[email-masked]>
Date: Mon, 14 Nov 2011 07:23:30 +0100

Hi,

Support.

Pierre.

On 11/14/11 6:31 AM, Henderickx, Wim (Wim) wrote:
>
> +1
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Bhavani Parise
> *Sent:* maandag 14 november 2011 6:27
> *To:* [email-masked]
> *Subject:* Re: [Idr] draft-keyur-idr-enhanced-gr-00.txt
>
>
> Support.
>
> regards,
> Bhavani
>
> [email-masked]  <mailto:[email-masked]>

---

From: Russ White <[email-masked]>
Date: Mon, 14 Nov 2011 09:17:55 -0500

Support.

:-)

Russ

---

From: Naiming Shen <[email-masked]>
Date: Mon, 14 Nov 2011 08:30:03 -0800

+1.

- Naiming

---

From: "Shyam Sethuram (shsethur)" <[email-masked]>
Date: Mon, 14 Nov 2011 18:04:39 -0800

Support.

thanks--shyam

John Scudder
15.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Nov 2011 10:06:50 +0800

Cannot remember if I already sent this or not, but :
Support.

---

From: Ahmed Bashandy <[email-masked]>
Date: Tue, 15 Nov 2011 10:00:07 -0800

+++1

Support

Ahmed