I support this draft. s.
> On Nov 10, 2015, at 2:47 AM, Jeff Tantsura <[email protected]> wrote: > > Dear RTGWG, > > The authors have requested the RTGWG to adopt draft-bashandy-rtgwg-bgp-pic-02 > as the working group document with Informational intended status. > > WG expressed support during the last RTGWG meeting (94) in Yokohama. > Please indicate support or no-support by November 15, 2015. > > If you are listed as a document author or contributor please respond to this > email stating of whether or not you are aware of any relevant IPR. The > response needs to be sent to the RTGWG mailing list. The document will not > advance to the next stage until a response has been received from each author > and each individual that has contributed to the document. > > Cheers, > Jeff & Chris > > From: "Ahmed Bashandy (bashandy)" <[email protected]> > Date: Monday, November 9, 2015 at 16:25 > To: Jeff Tantsura <[email protected]>, Chris Bowers > <[email protected]> > Cc: "[email protected]" <[email protected]>, Clarence Filsfils > <[email protected]>, Pradosh Mohapatra <[email protected]> > Subject: Request for WG adoption of draft-bashandy-rtgwg-bgp-pic-02.txt > > Hi, > > This is the latest version of the BGP-PIC draft that was presented on > Nov/2/15 during the IETF-94 meeting in Yokohama > We have addressed the comments as follows: > - Added statements in multiple places, including the abstract, indicating the > need for more than one BGP path > - Added example in Section 2.3.3 with illustrations in Figure 4,5,6 on how to > handle a platform that does not support the required number of hierarchy > levels. Section 4.3 explains the gradual degradation of BGP-PIC benefit as a > result of the reduced platform support > - For handling unlabeled traffic in case PE-CE failure, the last bullet in > Section 4.2.2 indicates that an egress PE must always treat a core facing > path as a backup path to avoid looping the packet in case of PE-CE link > failure. The first statement in Section 5.1 indicates that the draft does not > cover the failure of a CE node > > > We would like to request adoption of the draft. > > Thanks > > Ahmed > > > > -------- Original Message -------- > Subject: New Version Notification for draft-bashandy-rtgwg-bgp-pic-02.txt > Date: Mon, 9 Nov 2015 16:05:59 -0800 > From: <[email protected]> > To: Clarence Filsfils <[email protected]>, Ahmed Bashandy > <[email protected]>, Prodosh Mohapatra <[email protected]>, "Pradosh > Mohapatra" <[email protected]> > > A new version of I-D, draft-bashandy-rtgwg-bgp-pic-02.txt > has been successfully submitted by Ahmed Bashandy and posted to the > IETF repository. > > Name: draft-bashandy-rtgwg-bgp-pic > Revision: 02 > Title: Abstract > Document date: 2015-11-09 > Group: Individual Submission > Pages: 26 > URL: > https://www.ietf.org/internet-drafts/draft-bashandy-rtgwg-bgp-pic-02.txt > > Status: > https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-bgp-pic/ > > Htmlized: > https://tools.ietf.org/html/draft-bashandy-rtgwg-bgp-pic-02 > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-bashandy-rtgwg-bgp-pic-02 > > > Abstract: > In the network comprising thousands of iBGP peers exchanging millions > of routes, many routes are reachable via more than one path. Given > the large scaling targets, it is desirable to restore traffic after > failure in a time period that does not depend on the number of BGP > prefixes. In this document we proposed an architecture by which > traffic can be re-routed to ECMP or pre-calculated backup paths in a > timeframe that does not depend on the number of BGP prefixes. The > objective is achieved through organizing the forwarding chains in a > hierarchical manner and sharing forwarding elements among the maximum > possible number of routes. The proposed technique achieves prefix > independent convergence while ensuring incremental deployment, > complete transparency and automation, and zero management and > provisioning effort. It is noteworthy to mention that the benefits of > BGP-PIC are hinged on the existence of more than one path whether as > ECMP or primary-backup. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
