Re: [GROW] I-D Action:draft-ietf-grow-diverse-bgp-path-dist-01.txt

["UTTARO, JAMES (ATTLABS)" <[e-mail]>]

The approach as I understand it is two deploy multiple channels to
disseminate routing state be it the 2,3,...nth path to some dest D..
Comments follow...

Jim Uttaro

Section 1.0 

"The parallel route reflector planes solution brings very significant
benefits at a negligible capex and opex deployment price as compared to
the alternative techniques"

A number of points need to be clarified here. The first is the
SP/Operator needs to deploy n number of RR planes to disseminate N
paths. Assuming some form of redundancy we would have to of course buy
the RRs or deploy some type of logical routers. How can this be
monetized? Does this approach assume that customers who want fast
restoration, load balancing, mitigation of oscillation would pay for
this. Or does the draft assume that the addl RRs are of such negligible
capex cost that the operator would simply incur the cost.. This model
does not usually sit well with the folks that write the checks. From an
opex perspective we are putting in addl planes for each AS that is under
the operators authority. So we not only need to pay for it we would need
to establish coherent inter-AS strategies to manage, maintain these addl
RRs.. Additionally the function of these devices is different than a
traditional RR which implies that OpS needs to be cognizant of the
difference and how they should be managed.. As described in the draft
the 2,3..nth plane need not be as robust as it is not the primary path..
This needs to be understood by OpS in terms of their response to failure
or how to perform maintenance.. We are essentially introducing a new
device from these perspectives...

Section 2.1

"This new requirement has its own memory and processing cost.  Suffice
to say that by the middle of 2009 none of the commercial BGP
implementation can claim to support the new add-path behaviour in
production code, in part because of this resource overhead."

A bit confused by this statement.. My thoughts on this was add-paths is
useful for a customer that is advertising multiple paths or at peering
points. In both cases we would anticipate the use of routing policy to
only select a subset of these routes. It is impractical to believe that
we are going to duplicate the same state over and over again on each
plane.. This is not a function of the draft but how operators deploy the
functionality..This functionality has been around a long time in VPNV4
services and I believe it will eventually be used for IPV4 services.. 

" The add paths protocol extensions have to be implemented by all the
routers within an AS in order for the system to work correctly."

Pls explain.. Why do you believe this? It is certainly not practical and
I never envisioned a full upgrade across thousands of edges in multiple
AS domains.. The approach we believe we could take is to deploy on a
subset of edges for some set of routes. 

" It is intended as a way to buy more time allowing for a smoother and
gradual migration where router upgrades will be required for perhaps
different reasons.  It will also allow the time required where standard
RP/RE memory size can easily accommodate the associated overhead with
other techniques without any compromises.'

His statement seems to conflict with the one above.. Above you state
that it is needed everywhere to work correctly here the statement is we
can buy time to gradually migrate.. Why don't we just gradually migrate
and eliminate this middle step??

Section 4

" The proposed solution is based on the use of additional route
reflectors or new functionality enabled on the existing route reflectors
that instead of distributing the best path for each route will
distribute an alternative path other then best. "

Would like to drill down on this a bit..In the first case where addl
deployment of RRs are done I am assuming that these RRs would somehow
prefer the second best path of the first.. How would this be done
customers use many different mechanisms to identify primary, secondary,
etc... AS-PATH prepend, Local Pref, IGP cost etc... are all used..How is
this done on the secondary plane? Regardless of either of these
approaches changes to the BGP implementation to select a different POI
is needed. But where how do you know how a customer is identifying? Pls
expand on this. It would seem that although the protocol definition does
not change the operator needs to ensure that this functionality is
constructed the same way across all the vendors.. Will this require
another draft? 

" The best path (main) reflector plane distributes the best path for
each route as it does today.  The second plane distributes the second
best path for each route and so on.  Distribution of N paths for each
route can be
achieved by using N reflector planes."

How is this done when it is the IGP cost that is the deciding factor..
Will we have to correctly place the Nth plane corresponding to IGP
correctly in the IGP??

" It is easy to observe that the installation of one or more additional
route reflector control planes is much cheaper and an easier than the
need of upgrading 100s of routers in the entire network to support
different protocol encoding."

See Above I do not believe it is all or nothing..

" Diverse path route reflectors need the new ability to calculate and
propagate the Nth best path instead of the overall best path.  An
implementation is encouraged to enable this new functionality on a per
neighbor basis."

Encouraged? I think it would be required..

Section 4.1.  Co-located best and backup path RRs

"To simplify the description let's assume that we only use two route
reflector planes (N=2).  When co-located the additional 2nd best path
reflectors are connected to the network at the same points from the
perspective of the IGP as the existing best path RRs.'

Based upon implementation this may require ports on existing core router
to terminate and a costing paradigm that duplicates the original the
latter may be simple the former would require that there is availability
at these locations.. Doesn't this also imply full symmetry? We could not
deploy a subset for the nth plane and mimic the IGP decision making of
the first?? The draft states that full symmetry is not needed.. Pls
Clarify..

" One of the deployment model of this scenario can be achieved by simple
upgrade of the existing route reflectors without the need to deploy any
new logical or physical platforms.  Such upgrade would allow route
reflectors to service both upgraded to add-paths peers as well as those
peers which can not be immediately upgraded while in
the same time allowing to distribute more than single best path."

The implication here is that the same primary RR would have to "hold"
and disseminate multiple paths to D.. Would this create a scalability
problem on this RR as it would have to hold these addl routes. Even
though the number of BGP routes for the internet is small in comparison
to VPNV4 this should be accounted for when RR platforms are selected.

"The way to accomplish this would be to create a separate IBGP session
for each N-th BGP path.  Such session should be preferably terminated at
a different loopback address of the route reflector.  At the BGP OPEN
stage of each such session a different bgp_router_id should be used.
Correspondingly route reflector should also allow its clients to use the
same bgp_router_id on each such session."

We need simple deployment strategies.

Section 4.2.  Randomly located best and backup path RRs

" The basic premise of this mode of deployment assumes that all
reflector planes have the same information to choose from which includes
the same set of BGP paths.  It also requires the ability to skip the
comparison of the IGP metric to reach the bgp next hop during best-path
calculation."

Scalability concerns. We would be putting our main primary RRs at risk.
Again I am confused about the IGP metric.. If the paths are equal up to
the IGP metric how do decide which is primary/secondary.. The secondary
RR needs to select one of the paths how does it do that??Is it router-id
or something of that nature..

"4.  Fully meshing newly added RRs' with the all other reflectors in
both planes.  That condition does not apply if the newly added RR'(s)
already have peering to all ASBRs/PEs."

I cannot see creating BGP sessions to all ASBR/PEs. There are BGP
session limits that also must be accounted for so I do not see that as a
viable alternative in a large network.. So I guess we would have to
fully mesh to all RRs. This is similar to a full mesh of PEs in terms of
getting all the routes on the secondary to make a decision.

" Any of the existing routers that are not already members of the best
path route reflector plane can be easily configured to serve the 2nd
plane either via using a logical / virtual router partition or by local
implementation hooks."

The term "Easily" is used to liberally. Getting complex functionality
configured on our most important parts of the network is never easy. It
requires a lot of test certification and coordination between OpS,
maintenance, etc... to get deployed

" The additional planes of route reflectors do not need to be fully
redundant as the primary one does.  If we are preparing for a single
network failure event, a failure of a non backed up N-th best-path route
reflector would not result in an connectivity outage of the actual data
plane.  The reason is that this would at most affect the presence of a
backup path (not an active one) on same parts of the network.  If the
operator chooses to build the N-th best path plane redundantly by
installing not one, but two or more route reflectors serving each
additional plane the additional robustness will be achieved."

Yes that may be true but we envision add-paths as being functionality
that not only enables fast restoration but the ability to provide
customer with load balancing. Probably good to be specific about the
goals of the draft in the intro/abstract. 

Section 4.3.  Multi plane route servers for Internet Exchanges

" In such cases 100s of ISPs are interconnected on a common LAN. Instead
of having 100s of direct EBGP sessions on each exchange client, a single
peering is created to the transparent route server. The route server can
only propagate a single best path.  Mandating the upgrade for 100s of
different service providers in order to implement add-path may be much
more difficult as compared to asking them for provisioning one new EBGP
session to an Nth best-path route server plane."

I do not understand. Are you saying that each eBGP session is nailed up
to each plane. Are you implying that we deploy 100 planes? If not how do
we know which one of the 100 ISPs should get the benefit of having
routes source by them propagated through the network??


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Wednesday, June 23, 2010 4:30 AM
To: [e-mail]
Cc: [e-mail]
Subject: [GROW] I-D Action:draft-ietf-grow-diverse-bgp-path-dist-01.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           : Distribution of diverse BGP paths.
	Author(s)       : R. Raszuk, et al.
	Filename        : draft-ietf-grow-diverse-bgp-path-dist-01.txt
	Pages           : 20
	Date            : 2010-06-23

The BGP4 protocol specifies the selection and propagation of a single
best path for each prefix.  As defined today BGP has no mechanisms to
distribute paths other then best path between it's speakers.  This
behaviour results in number of disadvantages for new applications and
services.

This document presents an alternative mechanism for solving the
problem based on the concept of parallel route reflector planes.  It
also compares existing solutions and proposed ideas that enable
distribution of more paths than just the best path.

This proposal does not specify any changes to the BGP protocol
definition.  It does not require upgrades to provider edge or core
routers nor does it need network wide upgrades.  The authors believe
that the GROW WG would be the best place for this work.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-grow-diverse-bgp-path-dis
t-01.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.