Subject: [Idr] 2 Week Working Group Adoption

From: "Susan Hares" <[email-masked]>
Date: Fri, 13 Sep 2013 15:10:30 -0400

The authors have asked that this implementation report on enhanced route
refresh be adopted as a WG document. 

This starts a 2 week last call on the document.

Enhanced Route Refresh Implementation Report

draft-keyupate-idr-enhanced-refresh-impl-00

http://datatracker.ietf.org/doc/draft-keyupate-idr-enhanced-refresh-impl/

Sue and John 

Idr co-chairs

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Sep 2013 09:22:00 -1000

> draft-keyupate-idr-enhanced-refresh-impl-00

as the spec is sparse, the implementation report is pretty sparse.  so i
guess that's ok.  and i like implementation reports, so i support wg
adoption of this one.

does anyone have any reference for the "APGW Automation" implementation?

randy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Sep 2013 21:50:57 +0200

Hi Randy,

> does anyone have any reference for the "APGW Automation" implementation?

It's NTT I3 internal BGP implementation of VPNv4, VPNv6 and RTC, .
What reference are you looking for ?

Thx,
R.

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Sep 2013 10:22:49 -1000

robert,

> What reference are you looking for ?

thanks.  would have been nice if both implementations were public,
allowing a reproducible experiment.  but what the heck.

randy

---

From: Thomas Mangin <[email-masked]>
Date: Fri, 13 Sep 2013 21:27:51 +0100

Someone give me a week and a bgp session to a BGP speaker supporting the feature and I can have the feature in ExaBGP ...

Sent from my iPad

On 13 Sep 2013, at 21:22, Randy Bush <[email-masked]> wrote:

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Sep 2013 10:30:25 -1000

> Someone give me a week and a bgp session to a BGP speaker supporting
> the feature and I can have the feature in ExaBGP ...
> ...

if keyur can give me an image which supports it, i can set up a
multi-hop bgp peer for you.

randy

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 17 Sep 2013 18:49:51 +0100

>>> allowing a reproducible experiment.  but what the heck.

The code of ExaBGP currently on github has support for the draft since this week-end. Two ExaBGP speaking to each other can exchange enhanced route-refresh messages but the interoperability with other implementation was not yet done.

As I am not sure neither what notification code has been agreed between Cisco and NTT, I did not implement the required notification in case of invalid message yet.

Sending multiple ERR sent at once should work but is untested yet.

Sincerely,

Thomas

---
Self check on a mac :

> ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"
> brew install git

terminal one :

> git clone [email-masked]:Thomas-Mangin/exabgp.git
> cd exabgp/dev/self/refresh
> ./first

terminal two :
> cd exabgp/dev/self/refresh
> ./second

The first peer will display something like this :

received neighbor <ip> update start
received neighbor <ip> announced route 1.0.0.0/25 next-hop 9.9.9.9 origin igp local-preference 100
received neighbor <ip> update end
received
received neighbor <ip> update start
received neighbor <ip> announced route 1.0.0.128/25 next-hop 9.9.9.9 origin igp local-preference 100
received neighbor <ip> update end
received
received neighbor <ip> update start
received neighbor <ip> announced route eor 1/1 (ipv4 unicast)
received neighbor <ip> update end
received

<the following looping every few seconds>

announce route-refresh ipv4 unicast
received neighbor <ip> route-refresh afi ipv4 safi unicast begin
received neighbor <ip> update start
received neighbor <ip> announced route 1.0.0.0/25 next-hop 9.9.9.9 origin igp local-preference 100
received neighbor <ip> update end
received
received neighbor <ip> update start
received neighbor <ip> announced route 1.0.0.128/25 next-hop 9.9.9.9 origin igp local-preference 100
received neighbor <ip> update end
received
received neighbor <ip> route-refresh afi ipv4 safi unicast end