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   <http://datatracker.ietf.org/doc/draft-ietf-trill-irb/>
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:
<http://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/>
draft-ietf-idr-rs-bfd-01, and
<http://datatracker.ietf.org/doc/draft-jdurand-auto-bfd/>
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