RE: Request for WG adoption of draft-bashandy-rtgwg-bgp-pic-02.txt

[<[e-mail]>]

Hi,

I support this document.

While this document does not describe “bytes on the wire”, IMO it’s useful to have a vendor independent description and terminology.
While this is old stuff, this is (really) good stuff.  (still, doing this 10 years ago would have been more valuable)

I had read it and commented the week before the IETF. Ahmed has already updated it. (some follow up may still be required).

Thanks
-- Bruno

From: rtgwg [mailto:[e-mail]] On Behalf Of Jeff Tantsura
Sent: Tuesday, November 10, 2015 2:47 AM
To: Ahmed Bashandy (bashandy); Chris Bowers
Cc: Pradosh Mohapatra; [e-mail]
Subject: Re: Request for WG adoption of draft-bashandy-rtgwg-bgp-pic-02.txt

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)" <[e-mail]<mailto:[e-mail]>>
Date: Monday, November 9, 2015 at 16:25
To: Jeff Tantsura <[e-mail]<mailto:[e-mail]>>, Chris Bowers <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Clarence Filsfils <[e-mail]<mailto:[e-mail]>>, Pradosh Mohapatra <[e-mail]<mailto:[e-mail]>>
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:

<[e-mail]><mailto:[e-mail]>

To:

Clarence Filsfils <[e-mail]><mailto:[e-mail]>, Ahmed Bashandy <[e-mail]><mailto:[e-mail]>, Prodosh Mohapatra <[e-mail]><mailto:[e-mail]>, "Pradosh Mohapatra" <[e-mail]><mailto:[e-mail]>



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





_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.