Hi Jim, Thanks for your comments on the draft.
First of all, as your email is mostly discussing about solutions, I'd like to remind that this draft defines the _requirements_ to gracefully shutdown a BGP session. Then, indeed you're right that the next step for these requirements is to initiate work and discussion about solutions to fulfil them. > From: [email protected] [mailto:[email protected]] On Behalf Of > UTTARO, JAMES (ATTLABS) > > Could the authors provide further clarification on the following. > > Is the intent to tie path availability and this functionality? I could > see other uses for path availability ie Load Balancing, Fast > Convergence, Minimize Path Hiding. This draft expresses requirements to be able to shutdown a BGP session with no / limited impact on the traffic. It does not take position regarding solutions to achieve these requirements. I'm not sure to exactly see what you mean by "tie path availability and this functionality". I can see 2 interpretations for your "path availability": 1) Indeed, as indicated in the draft (section 3.2. Causes of packet loss) one reason for the packets loss is the "lack of an alternate path on some routers". 2) One (range of) solutions to address this is to advertise (all the time), multiple paths per prefix (and more specifically the back up path). But there could be also other solutions. Such as to get those backup paths only at the time of the shutdown, and only for the specific prefixes needing a backup path. On a side note, I also agree with you that path availability has multiple applicabilities (possibly depending on which additional path you select to advertise). > Availability of Paths. Is the draft proposing a mechanism for a speaker > to discover alternative paths ? There are a number of existing drafts > BGP Best External and Add-Paths for IPV4 and BGP Best External and a > Unique RD ( Not a draft ) per VRF Context ensure that we get the second > best paths to a ASBR Speaker ( Either PE or ASBR ). The draft does not > speak to the approach. The draft does not propose a mechanism to discover alternative path as the draft is a requirement draft and not a solution one. It does say that one reason for packet loss when shutting down or even setting up a BGP session is path unavailability. Indeed, as you pointed out, there are existing and proposed new ways to advertise multiple path per prefixes. The draft was not meant to compare existing solutions or propose new ones but to define the requirements. Then, hopefully, there will be a discussion about solutions. We'd be happy to discuss the solutions with you if you want. I would suggest a different thread as this is not really related to the requirements draft. May be more related to the following drafts http://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-01 or http://tools.ietf.org/html/draft-vvds-add-paths-analysis-00 or http://tools.ietf.org/id/draft-uttaro-idr-add-paths-guidelines-00.txt I think section 4.1 of draft-ietf-grow-bgp-gshut-01 would be specifically relevant to initiate the discussion. > Make before Break. Is this a capabilities negotiation on a per session > basis? I would guess so. You're right that this is enabled on a per session basis. And besides, the draft call for a possible incremental deployment with incremental benefit on a per AS and BGP session basis: " e) An incremental deployment on a per AS or per BGP session basis SHOULD be made possible. In case of partial deployment the proposed solution SHOULD incrementally improve the maintenance process." If by "capabilities negociation" you mean a BGP capability, again this draft is not about solution. As an example of solution, draft-ietf-grow-bgp-gshut-01 does not use BGP capability. > Will the set of affected prefixes need to be sent in a BGP Withdrawal > message to the RRs from the initiator? If so what is the behavior? It > seems that all speakers would then select ASBR2 ( Your Example ).. So > there would be no change from the RR towards the iBGP topology? This requirement draft does not propose a solution. You may wish to look at the draft http://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-01 which seem related to your question. We would welcome comments on it. Thanks Regards, Bruno > Jim Uttaro > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Friday, April 30, 2010 5:15 PM > To: [email protected] > Cc: [email protected] > Subject: [GROW] I-D > ACTION:draft-ietf-grow-bgp-graceful-shutdown-requirements-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Global Routing Operations Working Group > of the IETF. > > Title : Requirements for the graceful shutdown of BGP > sessions > Author(s) : T. Takeda, B. Decraene, P. Francois, c. > pelsser, Z. Ahmad, A. Armengol > Filename : > draft-ietf-grow-bgp-graceful-shutdown-requirements-02.txt > Pages : 16 > Date : 2010-4-30 > > The BGP protocol is heavily used in Service Provider networks both > for Internet and BGP/MPLS VPN services. For resiliency purposes, > redundant routers and BGP sessions can be deployed to reduce the > consequences of an AS Border Router or BGP session breakdown on > customers' or peers' traffic. However simply taking down or even > bringing up a BGP session for maintenance purposes may still induce > connectivity losses during the BGP convergence. This is no more > satisfactory for new applications (e.g. voice over IP, on line > gaming, VPN). Therefore, a solution is required for the graceful > shutdown of a (set of) BGP session(s) in order to limit the amount of > traffic loss during a planned shutdown. This document expresses > requirements for such a solution. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-grow-bgp-graceful-shutdow > n-requirements-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
