Subject: Re: [bmwg] Adoption of Router/Basic BGP Convergence Drafts

From: "Ilya Varlashkin" <[email-masked]>
Date: Mon, 2 Jul 2012 16:55:26 +0200

Hello all,

I've got stuck with my draft - the traffic generator/protocol simulator has
serious issues when I need to simulate same exit/border router reachable via
multiple ports, this severely limit type of test scenarios that can be
simulated. The problem #1 is that BGP session cannot be transferred from one
port to another, so primary path failure results in primary BGP session
going down. The second issue is with trying to work around #1 - when IGP (in
my case it was ISIS) on two ports advertises same node/router, which I
thought I could use as next-hop in BGP updates without actually establishing
session to it from DUT, the two ports advertised actually two independent
routers sharing most of information but having different (and ever
increasing) Sequence Number. The ever increasing Sequence Number caused DUT
to run new SPF right after previous one finished, which in turn kicked up
exponential back-off resulting in much slower convergence and thus
diminishing usefulness of the tests.

I'm now trying to figure out alternative setup that would involve additional
real routers, but need to see if results will be meaningful.

Based on this I'd ask not to adopt my draft at this moment as WG item.

/iLya

From: [email-masked] [mailto:[email-masked]] On Behalf Of Al
Morton
Sent: Thursday, June 28, 2012 5:25 PM
To: [email-masked]
Subject: [bmwg] Adoption of Router/Basic BGP Convergence Drafts

BMWG,

We (still) have a charter item on BGP Convergence:
Basic BGP Convergence Benchmarking Methodology to IESG Review (overdue)

Over the last year or so, we've discussed two drafts that
will help to satisfy the milestone.  We've also seen some results of 
implementation and testing at our last face2face session.

The two drafts are:

Convergence benchmarking on contemporary routers
http://tools.ietf.org/id/draft-varlashkin-router-conv-bench-00.txt

Basic BGP Convergence Benchmarking Methodology for Data Plane Convergence

 <http://tools.ietf.org/html/draft-papneja-bgp-basic-dp-convergence-03> 
http://tools.ietf.org/html/draft-papneja-bgp-basic-dp-convergence-03
 <http://tools.ietf.org/html/draft-papneja-bgp-basic-dp-convergence-03>  

The combination of these drafts address both the milestone and
issues with non-convergence path restoration that has come-up 
in IESG comments in the past.

Therefore, I now ask whether the working group members feel we
should adopt these as WG drafts. So:

1. Please Read the Drafts by July 19th, 2012.

2. Respond with your review, and 

3. give your impressions on whether they are sufficiently clear in their 
approach and direction, such that we can complete them in a timely 
fashion in the working group.

That's it!

regards,
Al
bmwg chair

---

From: Al Morton <[email-masked]>
Date: Mon, 02 Jul 2012 13:49:56 -0400

Ok Ilya, thanks for the update.

BMWG will postpone adoption your draft at this time.

If anyone has suggestions for Ilya, I'm sure they

will be appreciated.

regards,

Al

bmwg chair

At 10:55 AM 7/2/2012, Ilya Varlashkin wrote:

Content-Type:
multipart/alternative;

boundary="----=_NextPart_000_010A_01CD5873.7AEAE470"

Content-Language: en-gb

Hello all,

I’ve got stuck with my draft – the traffic generator/protocol simulator
has serious issues when I need to simulate same exit/border router
reachable via multiple ports, this severely limit type of test scenarios
that can be simulated. The problem #1 is that BGP session cannot be
transferred from one port to another, so primary path failure results in
primary BGP session going down. The second issue is with trying to work
around #1 – when IGP (in my case it was ISIS) on two ports advertises
same node/router, which I thought I could use as next-hop in BGP updates
without actually establishing session to it from DUT, the two ports
advertised actually two independent routers sharing most of information
but having different (and ever increasing) Sequence Number. The ever
increasing Sequence Number caused DUT to run new SPF right after previous
one finished, which in turn kicked up exponential back-off resulting in
much slower convergence and thus diminishing usefulness of the
tests.

I’m now trying to figure out alternative setup that would involve
additional real routers, but need to see if results will be
meaningful.

Based on this I’d ask not to adopt my draft at this moment as WG
item.

/iLya

From: [email-masked]
[
mailto:[email-masked]] On Behalf Of Al Morton

To: [email-masked]

Subject: [bmwg] Adoption of Router/Basic BGP Convergence
Drafts

BMWG,

Basic BGP Convergence Benchmarking Methodology to IESG Review
(overdue)

The two drafts are:

Basic BGP Convergence Benchmarking Methodology for Data Plane
Convergence

That's it!

regards,

Al

bmwg chair

_______________________________________________

bmwg mailing list

[email-masked]
https://www.ietf.org/mailman/listinfo/bmwg