Re: [bmwg] Comments on draft-ietf-bmwg-basic-convergence

["UTTARO, JAMES" <[e-mail]>]

Rajiv,

                I think I can help with some of the scenarios.. Maybe we can meet on the phone and discuss over the next couple of weeks.

Jim Uttaro

From: Rajiv Papneja [mailto:[e-mail]]
Sent: Wednesday, May 21, 2014 6:45 PM
To: UTTARO, JAMES; [e-mail]
Cc: MORTON JR., AL
Subject: RE: Comments on draft-ietf-bmwg-basic-convergence

Hi James,

First of all thank you so much for your valuable comments and my sincere apologies for the delay in responding to your comments. Please see inline:


From: bmwg [mailto:[e-mail]] On Behalf Of UTTARO, JAMES
Sent: Thursday, March 27, 2014 11:12 AM
To: [e-mail]<mailto:[e-mail]>
Cc: MORTON JR., AL
Subject: [bmwg] Comments on draft-ietf-bmwg-basic-convergence

Meta Comments.

A picture showing the T0 failure T1 failure detection T3 Control Plane Detects T3 Control Plane Converged T4 Forwarding Plan Converged would be a useful addition to the reporting format.
[rp] <Do you want us to include these as reporting parameters in the reporting matrix?  We only define data plane convergence methodology in this document.


You should indicate your sampling interval.
[rp] We do suggest that the user defines the sampling intervals  but do not recommend any values in the work

As part of the route distribution it should be made clear the various leaf to node ratios you recommend.
[rp] We do recommend the route mixture in section 4.2 which is by using the internet routing table that has a good distribution of route prefixes. Also in testcases we recommend multiple iterations with a varying number of routes and route mixtures to get a complete characterization

This goes way back for me but in the late 90s we used routers that prioritized other protocols/processes over BGP, so part of our convergence testing would be to stress out multiple protocols and get data on how BGP convergence may be affected. It is important when doing this benchmarking to simulate the real world design and behavior..


Section 1

Will VPNV4 be included in subsequent drafts?  Many of our designs are built around providing a quickly converging BGP Control Plane for our VPN customers.
<rp> Yes, this is what we have been considering. We certainly welcome you participating in extending this work to include BGP based services

Section 1.4


"To ensure uniformity of the results all optional
   parameters SHOULD be disabled and all settings SHOULD be changed to
   default, these may include BGP timers as well."


We modify the default parameters to enhance convergence.. It may be useful to solicit from SPs and others what the settings are and use that as a baseline.
<rp> Yes, certainly. We emphasis reporting matrix to include initial conditions (for example, in section 4.4,  recommendations on using the timers). We present a unified methodology and initial conditions that can be defined based on user requirements ( for example -various SP requirements). We also recommend some basic settings 4.4, however we would welcome a typical example from you!

Section 5.1


"Running tests with a varying number of routes and route mixtures is

   important to get a full characterization of a single peer."



I did not see it but having multiple peers with varying route mixtures is an important point. For this type of testing the results change dramatically based on workload profile.

[rp]  we agree with you here, and we recommend multiple peer scenarios in the section 4.1. We also provide the flexibility for the user to document the number of peers should be included in the testing per each user requirement. We will however clarify the importance of using route mixtures for multiple peers.





Section 5.2.1



An interesting addl case of interest would be when both links hot in a load balanced manner. We use this configuration quite a bit and a result of interest would be how long to reprogram the FIB and point the ½ number of entries using RR1 to be re-programmed to use RR2. This is a function of the vendor/platform software design and how it deals with FIB entries ( We hope for indirection )

[rp] If I understand the scenario correctly, I believe this scenario is covered in section 5.2.3.


Section 5.8

Does this address both GR and LLGR?
[rp] currently we only considered GR. The LLGR work we plan on considering it for future extensions/drafts when we include other Address-families