Subject: [Idr] Working Group notes for IETF 75

From: "Susan Hares" <[email-masked]>
Date: Thu, 13 Aug 2009 08:00:35 -0400

Please send comments on working group notes to the list.

Thanks to Keyur and Robert for taking the notes!

Sue Hares 

John Scudder 

-----------------------------------------------------------------

 Inter-domain Routing (IDR) WG

 THURSDAY, July 30, 2009

 1300-1500 Afternoon Session I

 Small Stage

 =====================================================

 CHAIR(s):   Susan Hares <[email-masked]>

            John Scudder <[email-masked]>

 SCRIBES: Keyur Patel, Robert Raszuk

 AGENDA

 o Administrivia                                         20 minutes

   Chairs

  - Note Well

  - Scribe

  - Blue Sheets

  - Thank you Yakov!

  - Document Status

 o draft-raszuk-ti-bgp-00.txt                             15 minutes

 Robert Raszuk

 o draft-ietf-idr-bgp-multisession-04                     15 minutes

 John Scudder

 o draft-vvds-add-paths-analysis-00.txt                   15 minutes

 Pierre Francois

 o draft-chen-bgp-ext-opt-param                           15 minutes

 John Scudder

 o draft-scudder-idr-rt-constrain-lite                    15 minutes

 John Scudder

 ===============================================================

 IDR notes

 1) Robert Raszuk: Multiple Transport Instance BGP:

 - Create a possibility for SP to divide BGP applications over two

   different instances

   * Running Separately (Examples): Internet from applications (l3vpns

     versus ipv4).

   * Auto-discovery is another example which can be run independently.

   * Proposal:

 - Current Suggested 2 instances. If need arises for more we need

   further discussion.

 - Complimentary compared to John's Proposal.

 - Suggestion to ask for a well known 2nd port.  Code for running  

   Both the instances should be the same. Easy for migration. No changes to

   BGP protocol other than listening on a separate port.

 - Max CPU, Max Memory, Different tunable sizing of BGP IO queue, Manual

   locking to preferred CPU/core, per instance choice of IP Precedence,

   tunable TCP parameters -- considerations for separating application

   into a different instance

 Questions/Comments:

 Q: (Ilya): Basically the draft proposes a new port? Usage as  

 multiplexing a separate identifier? Wouldn't multisession running over separate

 processes would give enough separation?

 A: It does provide a session separation with no definition on how the

 implementation will handle the instance separation itself. If there

 is a WG interest we will define a set of profiles to clearly indicate what

 levels of separation given platform/code can handle. To define it  

 here seems justified from the point of view of multivendor environments.

 Q:(Chris Morrow): BGP should be multiple process in unix world? Being

 able to demultiplex using different port?  There is no difference in

 how BGP works with the current proposal? Doesn't seem to have any

 difference other than a new port.

 DoS attacks are not fully safe. Though moves control traffic on a

 separate port.

 A Yes. Point of this was different applications over different

 threads. Yes its suggesting to run over a separate port.

 Q: (Peter Lothberg_: The DOS will result flooding forwarding plane  

 And control plane. Doesn't matter where the packet came from.

 Q: Shouldn't standardize software implementation. Not a protocol  

 issue.

 Q: (Unknown person): If need flexibility why have a static port and why two  

 And not N?

 A: Two can address most of the issues. We are allowing n but not

   statically.

 Q: (Unknown person): have requirements where peers would have shorter

 Convergence time? Are these the applications you have in mind? Why static and

 not dynamic?

 A: Applications as VPNs versus IPv4.

 =========================================================================

 (Agenda interruption -- Ross Callon presented a plaque to Yakov for  

 19 years of service as IDR chair.  Applause, etc.)

 ==========================================================================

2) Multisession: John Scudder

 Update: Dynamic Port support. Using redirect.

 Q: Notification should be used for redirect.

 A: Doesn't currently do this, though did consider it.  I will think

 about it more for next revision.

 Q Robert Raszuk: What is your view of doing your proposal using

 pre-configured port ranges.

 A: Seems reasonable.

 Q: (unknown) How about to have the ranges pre-allocated ?

 A: (John) Perhaps it would be too much waste, TCP well-known port space is

 limited.

 Q: (Peter Lothberg) ... it should be TCP thing not related to BGP.

 A: Not clear how to do this without protocol involvement.  Open to

    suggestions.

 Q: (Keyur Patel) .. Notification breaks GR

 A: Thanks.  Will give attention to this in the next revision.

 Q: (Ilya) TCP can address it itself ... no need to have new ports

 A: Let's take it off line.

 Q: (Luca Martini): Good idea to have full dynamic range. LDP has a feature for   

    10 years. Label space.

======================================================================

3)  Pierre Francois: Analysis of paths selection modes for ADD-PATHS.

 Measuring load in terms of # of paths.

 Backup path optimality:  YES.

 Note on terminology -- "RIB charge" is a "false friend" translation

 from French.  "RIB load" would be better.

 RIB charge: N best is the only one that guarantees bound on RIB  

             change. Others don't guarantee any upper bound on paths you store.

 MED Oscillations: All but N-best

 Control plane complexity: Implementation dependent?

 TOOL: We have a tool. Send us your network topology and we can do the

       analysis.  Need data from PEs, not just a few core routers.

 Questions: 

 Ilya: Draft is valuable. Slides are more recent. Please update the

 draft.

 Scudder: Interested in Draft. 

 ==========================================================================

4)  John Scudder: Extended Optional Parameters

 Suggests to extend optional parameters beyond 255 types by reserving

 255, changing encoding when more than 255 bytes needed.

 I propose this as a Working-Group draft.

 Questions/Comments: 

 Q: (Ilya) Backward compatible. If length is more than 255 the session  

 won't come. Not necessary that would be the case with implementations. Once

 the new software is installed is it possible for new implementation  

 to break the old speakers.

 A: Once you have certain number capabilities, you will have to start

 triaging once the count goes beyond 255.  Draft forbids from sending

 new encoding unless you have byte count > 255.

 Q (Alexi): Previous draft suggested to break the capability count by

 running multiple instances.

 A: Scudder: Would like to fix under all circumstances.

 Q: (Sumita) Like to see a better solution for backward compatible  

 routers.

 Q: Scudder: Old implementations can't deal with this issue.  Upgraded

 implementations won't have this issue.  Open to suggestions how to do

 this even better.

 ===============================

 5) John Scudder: RT-Constrain Lite

 Current 4684 is complex from implementation standpoint.  Lite draft

 suggests a subset simpler to implement, useful for PEs.

 Question and Answer/Comments: 

 Q: (Robert Raszuk) Violates with RFC 4684 as the default filtering is  

 DENY which is changed to PERMIT. DEFAULT DENY versus DEFAULT PERMIT.

 A:(Scudder) Technically yes.  More interested in practical

 interoperability.

 Q: (Robert Raszuk) PE simplification can be done without RT Constrain - 

 lite.

 A (Scudder):  Sure.