Subject: [bmwg] draft-papneja-bgp-basic-dp-convergence-01

From: "iLya" <[email-masked]>
Date: Tue, 29 Mar 2011 01:49:20 +0200

Hi,

below are some comments on draft-papneja-bgp-basic-dp-convergence-01. Sorry 
for terse wording, I will elaborate during BMWG session, just thought this 
may help.

figure 1: s/Err/Trr/ and s/emulator/tester/ or simulator (Err brings 
associations with error)

Figures 2-4: source and sink ports should probably be on the same tester for 
easier correlation of number of transmitted and received packets, and 
possibly time

section 4: typically iBGP routes are installed (by an implementation 
strictly-conformant to BGP specs) when next-hop is valid & iBGP route 
doesn't invalidate next-hop & route is best.

"helper routers" should probably be replaced by "simulated routers"

"It is RECOMMENDED that the user may consider advertizing the entire
   current Internet routing table per peering session using an Internet
   route mixture with unique or non-unique routes." <- this is not 
repeatable because everyone has different "Internet" view. We need more 
accurate description of the test routes that sufficiently close represent 
typical densely-connected network.

When multiple peers are used it's important to document not only timing 
betweeb sending routes (I'm not sure that this is practical for general case 
due to packing differences) but also PATH attribute distribution among 
peers, variation of PATH attributes between peers. Even better from 
repeatability is to define "standard" collection of PATH mixture that MUST 
be used for tests.

s/minimum policy/minimal policy/

section 4.4: baseline run should be done with configurable parameters set to 
a) default values specified by respective RFC; b) platform-specific 
baseline - set parameters to values that are default for given platform; and 
c) values expected on operational network

add to basic parameters: Max TCP Window size (or fully dynamic if supported) 
and MTU.

Section 4.5: perhaps BGP test specs should require tests at specific set of 
speeds (so operators know if vendor results are comparable)

Section 5.1.1: Step E is impractical because clocks of DUT and the tester 
are not sufficiently sync'ed (NTP stratum 2 is not good enough for 
high-speed links, stratum 1 is extremely difficult to implement), and 
therefore reference to RCV-Rt-time in step H is meaningless. Also, there are 
few different types of Average.

Section 5.1.2: same as 5.1.1 plus: not clear why traffic would ever flow 
towards helper node if route advertised by Tester/Simulator and what is 
"Route Egress Interface toward peer-X" - steps G,H,K are confusing. Also, 
Testers/Simulators typically use "DUT address" as default gateway to forward 
traffic towards anything for which they don't have specific route, this 
means if source port of Tester sends traffic prior receiving route from DUT 
(but DUT already installed route in FIB), traffic will be successfully 
received at the sink port. Need a methodology to overcome this problem.

Section 5.1.4: iBGP convergence should focus on detecting next-hop 
changes/failures both due to directly attached link failure as well as 
remote failure/changes. As currently specified test does not seem to have 
relevance (or alternatively - this section measures something else but not 
iBGP convergence).

Section 5.3: "software ajacency down" on Tester will likely be reported 
immediately to DUT. In real network there is usually communication problem 
(but different from link failure) from Tester to DUT that results in DUT not 
receiving KEEPALIVEs and timing out session with Tester (or in reverse) and 
NOTIFICATION is sent. This process takes longer than described in this 
section, but of far higher practical value. Alternatively: this section 
describes something else (e.g. session termination by peer or even Hard 
Reset as in section 5.4.2) but not adjacency failure.

Section 5.7: Significantly different results may be observed if route in 
step H has better local-pref (on iBGP session) compare to case when it has 
better AS_PATH. For next-hop - when tie-breaking on cost to next-hop in some 
scenarios some platforms have O(1) convergence for N prefixes. To ensure 
comparable results this section must spell out which attributes should be 
better (or require several runs for various attributes).

Section 5.8: This section does not seem to address Graceful Restart. For 
example, Route-Refresh if sent by non-DUT device will either not reach DUT 
(on old session, which is closed) or DUT will not react (per RFC4724) on it 
until it sees EoR from non-DUT (if RR sent on new session). Additionally, 
some implementations may even preserve original session (I'm not aware of 
existence of such, but they're feasible) and nothing happens at all during 
switchover. It's not clear what was intention of the test in this section.

Kind regards,
iLya

---

From: CAUCHIE Grégory <[email-masked]>
Date: Tue, 29 Mar 2011 10:33:13 +0200

Hi group,

as asked by Al during today's meeting, here are the comments I sent 
earlier on to the authors regarding the draft in the subject of this mail.

<Extract>
I have many comments, so I will just focus on the big ones for now.

1) I find the draft very confusing. The title of the draft states that 
it focuses on data plane convergence, but at the same time it looks at 
control plane convergence and refers to RFC4098 which point is to focus 
(see section 6.2) only the control plane in a single unit (that I 
personaly sum up as a pure Route Reflector benchmarking). Therefore, I 
think it is a must for the document to clearly state its scope and how 
it may differ from RFC4098.
And BTW, I think really that your choice of looking at both the control 
plane and dataplane is a valid choice.

2) There is no hypothesis regarding the IGP configuration. If you object 
me that this document is on BGP testing and that as a consequence IGP 
behaviour can twist the results, I will answer you that I am in line 
with you. However, we all know that the IGP cost is many times used in 
the tie-break algorithm and that as such we shall say something arounf 
this. Furthermore, I think it is rather simple to have an IGP configured 
and include in the test a step looking at the time needed by IGP to 
converge so as to finaly remove the time from the BGP+IGP convergence 
time and get the BGP convergence. In that case we would be able to test 
BGP convergence on IGP metric change (implying a new tie-break decision) 
and a next-hop unreachability.

3) The focus of the draft is IPv4 and IPv6 which then implies 
multi-protocol extensions for BGP. From there, one could argue "why not 
address VPN family also?" as it is a big business benchmarking the 
technology. My proposition there would be to just focus on IPv4 and thus 
on BGP. Then, in another document could be addressed the benchmarking of 
MP-BGP where IPv6 testing would reuse the IPv4 methodology of this 
document and then focus on the other important address families like 
unicast VPN and 6PE AFI/SAFIs.

4) getting back to the confusion argument, I think that what we could 
call a "BGP position testing" is missing. RFC4098 introduces the notion 
of subscriber-edge routers, provider-edge routers, core routers, etc. I 
think this document could simplify its structure, especially in section 
5, by updating the names and talk about testing of BGP for routers in a 
position of ASBR, a RR (which BTW is never mentionned) or a core router.

5) I have some concerns on terminology. First, I disagree with you when 
using the term adjacency with BGP. Routers can be adjacent but they only 
establish sessions (adjacency is an IGP terminology). Second, I don't 
follow you on your statement regarding route installation for eBGP. 
RFC4271 clearly states that a route must be resolvable in order to be 
considered in the decision process, with no exception for eBGP or 
multi-hop eBGP sessions. Finally, many acronyms are not detailed as they 
appear in the document, like HLP, Drr, Err, etc (which is minor at the 
end)."
</Extract>

Regards,

Greg

---

From: Rajiv Papneja <[email-masked]>
Date: Wed, 30 Mar 2011 10:59:03 -0400

Hi Greg,

We appreciate your feedback and will try to address your concerns in the
next version. 

I share the summarized responses with group that I had sent you in response
to your email yesterday:

My comments are inline:

> From: CAUCHIE Grégory <[email-masked]>
> Reply-To: <[email-masked]>
> Date: Tue, 29 Mar 2011 10:33:13 +0200
> To: <[email-masked]>
> Subject: [bmwg] Comments on draft-papneja-bgp-basic-dp-convergence-01
> 
> Hi group,
> 

RP>  As part of this effort, we plan on either extending the RFC4098 to
address data plane terminologies or have a separate term document for
addressing the same. Existence of such a document will help us in reducing
the confusion. I am glad that you are in agreement with us on our choice to
begin this effort with the DP convergence.
> and a next-hop unreachability.

RP> What you are suggesting is very valid. We do say in the draft that the
IGP interaction is outside the scope of the document, however we agree that
IGP consequence is an import factor in BGP convergence.  Initially, we did
have IGP & IGP metric test case, but to simplify and restrict our scope to
BGP only, we removed it. Now based on current interest, we will try to
address by adding those test cases.
> unicast VPN and 6PE AFI/SAFIs.

RP> Your point is well taken Greg! We have an agreement here and if there is
interest in the community, we agree to expand the scope of this draft or
probably have a complimenting document addressing the MP-BGP.

> position of ASBR, a RR (which BTW is never mentionned) or a core router.

RP> We will look into it and see how we could best handle this. However, we
did not mention RR benchmarks as we were focusing on the data plane
convergence. Do you imply that we should consider scenarios where is RR is
in the datapath? 

> appear in the document, like HLP, Drr, Err, etc (which is minor at the
RP> Agreed, we will make changes to use sessions instead of adjacencies.
Acronyms will be added and we will address nexthop resolution for eBGP.

Thanks again for taking out time to review the work and providing great
feedback.

Regards,
/Rajiv
> 
> Regards,
> 
> Greg
> 
> 
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bmwg

---

From: CAUCHIE Grégory <[email-masked]>
Date: Wed, 30 Mar 2011 23:42:13 +0200

Thanks Rajiv for this update, I then really look forward to read the 
next version of the draft.

And just to make it clear as per your response on comment 1 and 4, my 
point (as shared by Sara and Ilya at least in the meeting) was that 
_both_ control plane *and* dataplane are an important matter. That said, 
I think indeed that considering the RR specific case is important. 
However, if you want to focus only on testing the dataplane convergence 
then yes, I also think you should consider having a RR in the  datapath 
as it is a common scenario in operational networks where the control 
plane is stressed by the number of session and the differentiation of 
messages from/towards iBGP peers and peers in the cluster.

Greg

Le 30/03/2011 16:59, Rajiv Papneja a écrit :
>> From: CAUCHIE Grégory<[email-masked]>
>> Reply-To:<[email-masked]>
>> To:<[email-masked]>
> have IGP&  IGP metric test case, but to simplify and restrict our scope to