Jeff, Chris, Petr, Ariff, and Jon: 

 

This is a second routing directorate review of draft-ietf-rtgwg-bgp-routing-large-dc-05.  The rtgwg chairs asked me to provide my insights as a BGP person for many years.   

 

 

Status:  Publish after correcting a few BGP issues 

·

         

Great leaps forward from the Original document, and an interested document to read.

·

         

A few minor technical issues, 

 

Editorial issues: As the second reviewer, I did not focus on the editorial nits and errors.   The English could still be improved in many sections.  If the chairs wish me to pull out my scholarly red pen,  I will do so. 

 

Minor technical issues: 

 

1)

      

P. 5 – ANYCAST and ECMP have been a fine idea for 8-10 years.

2)

      

P. 10 – Your TRILL comments could use a bit more clarity. 

 

Here’s the facts 

 

2-a) TRILL (Huawei) and “early TRILL”  (Cisco, Brocade) – have been deployed in the Layers 2 design.  TRILL requires special forwarding (due to header), but there is a draft to use  TRILL over IP (   http://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/) . 

 

The TRILL forwarding has had active-active added to its capability which deal with the broadcast/undefined multicast (BUM traffic).  

 

TRILL deployment make use of the proprietary directory services in order to reduce the BUM traffic or the IP/MAC look up traffic.   Five new drafts are heading toward the IESG that allow a standardized directory service (2 provide over-all designs for service, and 3 provide additions to standard trill). 

 

TRILL shares its OAM with the 802.1ag OAM so that the fault-management and performance management can utilize the automatic features design by 802.1. 

 

The  

draft-ietf-trill-irb-06

 solution may help your L2/L3 Design by providing a clear TRILL/Layer-3 gateway.  

 

3)

      

Section 5.1 page 12 

a.

       

“BGP deployment within an Autonomous system typically assumes the presence of an IGP for next-hop resolution” 

 

Here – BGP can run without an IGP by using the features of ARP/RARP and ND.   This feature has been true of BGP since 1987. 

  

4)

      

P.AGE 13 “This meets REQ 3 and REQ 4.  It is worth mentioning”

I suspect you mean “This use of E-BGP meets REQ3 and REQ4.”

 

However, I could not tell and that’s important for the technology.

 

 

5)

      

You should cross reference AS-Migration and other drafts that have “Remove-PRIVATE-AS” before sending out. 

 

6)

      

Multipath-relax should be described in specific detail in a different document if you think is very useful (p. 20) 

 

7)

      

Section 7.1 IDR drafts: 

draft-ietf-idr-rs-bfd-01

, and 

draft-jdurand-auto-bfd-00

 are proposing BFD/BGP interactions for Route-servers.  You should review this documents and link to these documents in your draft. 

 

8)

      

Section 7.2 – You mention Add Paths in many section, but a lot of your problems might be solved with Add-Paths and a guideline on how to reduce the FIB.   One way to also aid Add-Paths is to allow for custom cost community to be added at certain points.  You do not consider this option. 

 

 

Sue Hares