|
Inter-domain Routing (IDR) WG THURSDAY, July 30, 2009 1300-1500 Afternoon Session I Small Stage ===================================================== CHAIR(s): Susan Hares <shares at ghs.com> John Scudder <jgs at juniper.net> 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. |