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

From: [email-masked]
Date: Wed, 23 Jun 2010 01:30:02 -0700 (PDT)

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-dist-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.

---

From: "UTTARO, JAMES (ATTLABS)" <[email-masked]>
Date: Wed, 23 Jun 2010 13:42:40 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, June 23, 2010 4:30 AM
To: [email-masked]
Cc: [email-masked]
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-grow-diverse-bgp-path-dis
t-01.txt

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 24 Jun 2010 00:27:58 +0200

Hi Jim,

> disseminate routing state be it the 2,3,...nth path to some dest D..

Not necessarily at all. Multiple channels is just one of possible 
deployment models.

Primary goal is to observe that while today having a pair of best path 
RRs one could easily turn one of the reflector within such pair into a 
backup RR, and without any need for any new IBGP session to be 
provisioned or without any need to add new RRs disseminate backup path 
to all clients.

This provides very easy to deploy mechanism where without any need for 
PE upgrade you provide PEs additional paths for fast connectivity 
restoration, PIC or load balancing needs.

> Comments follow...

So do further replies ...

> monetized?

Not required. You maintain connectivity redundancy even if turning 
existing pair of RRs into primary and backup case. No new purchase order 
required nor need for any logical routers.

The draft describes RR planes to give the formalized description of the 
proposal, but I was hoping that it could be easily interpreted into 
basic deployment styles.

Adding new set of RRs if someone needs to is also possible, but 
completely not necessary for the diverse path deployment.

> Does this approach assume that customers who want fast
> does not usually sit well with the folks that write the checks.

Again .. this is not necessary at all. Contrary if you need to swap your 
all PEs into a new ones which support alternative ways to disseminate 
more then one BGP path .. this is where the check would be rather heavy :).

Comparing that with just code upgrade on the RRs seems clear where the 
savings are.

> From an

Again you are stuck with one particular deployment model. I take as a 
recommendation to clarify this in the next version of the draft that 
provider may simply without adding new RRs nor without touching PEs turn 
one of the existing RRs into a diverse-path RR and disseminate diverse 
BGP paths to the clients.

All what is required on provider side is to upgrade RRs with new code + 
enable client sessions with new knob.

> services and I believe it will eventually be used for IPV4 services..

At peering points I find it very common to set next hop self while 
advertising towards IBGP peers so there is practically no reason to 
advertise mutliple ebgp learned paths towards the core.

VPNv4 PEs require this day one .. many ISPs in their IPv4/IPv6 do it by 
default as well today.

One would need to also note that this quite a common practice to 
provision external peerings on different ASBRs in order to avoid single 
ASBR going down a disconnect of number of external peering sessions.

> subset of edges for some set of routes.

The question one needs to ask is what is overall goal ? As you have 
observed the primary goal SPs are after is to provide fast connectivity 
restoration, load balancing or mitigate oscillations.

To accomplish this in MPLS networks or in IP encapsulation networks you 
need to push additional state to all edges/PEs otherwise you are missing 
the alternative paths where they need to be present.

Pushing more then best path with add-paths requires upgrade of PEs. 
Distributing additional paths with diverse-path proposal does not 
requires any touch to the PE.

So if you can clarify what is the point of using add-paths for "subset 
of edges for some set of routes" ?

> and eliminate this middle step??

The gradual migration may take 10 years. Do you want to offer inferior 
services as compared with other SPs over the next 10 years ?

In my true opinion both add-paths and diverse-path are complimentary to 
each other. Yes they both enable operator to distribute more then 
overall best path, but they do it differently.

I imagine that RRs could be capable of supporting peers which are 
upgraded with the add-paths code as well as those clients which are not 
yet upgraded, but still would benefit with receiving more then best path 
only.

In fact I think that most of the current applications can be easily 
satisfied with just 2nd best path which dissemination diverse path 
proposal addresses.

> constructed the same way across all the vendors.. Will this require

BGP best path algorithm is quite consistent today across vendors. That 
means that calculating best path is consistent. That also means that 
calculating 2nd best path would also be consistent.

So when this could break ?

It could break in step 9 of best path on non co-located RRs where we 
consider IGP metric to a BGP next hop.

In order to address this point there are number of options:

* Make sure from IGP point of view primary RR and backup RR are on the 
same point in the network - nothing additional is needed - that is also 
very often the case in control plane RRs in tunneled networks

* Disable IGP metric check step on RRs - as a matter of fact RRs making 
decision on best path from their point of view makes only sense when RRs 
are in the data plane on the POP to core boundaries. In all other RR 
placements somewhere in the core it is really not necessary.

* No need to worry about any IGP metric step but allow backup RR to 
learn primary RR's best path and accommodate this knowledge when 
advertising diverse path towards clients. Again no need to add any new 
RR is needed nor modify even a single line of configuration of the clients.

Any other BGP mechanism like AS-PATH prepend, Local Pref etc ... would 
be treated identically on both primary and backup RR so no issue.

> Will we have to correctly place the Nth plane corresponding to IGP

See above.

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

Also see above :) And by installation please do not think of physical RR 
installation.  Under this I meant to indicate turning existing set of RR 
into a backup RR plane as well.

> Encouraged? I think it would be required..

I agree it is preferred and I am supporting that.

But one could observe that especially in topologies where you have very 
good POP symmetry towards pairs of RRs or when you would prefer to add 
RR as backup that you may want to turn diverse-path functionality on 
such backup RR on a per SAFI basis.

> the first?? The draft states that full symmetry is not needed.. Pls

As indicated above full symmetry only applies when you want to make sure 
that IGP point of RRs is the same on primary and backup RR. As described 
earlier this is just one of 3 ways to make sure backup RR calculates 
correct backup paths towards it's clients.

And also as described above in this example addition of second plane may 
be as simple as upgrading one of your existing RRs and enabling it to 
distribute diverse path towards the clients.

Initially to one or few on a per session basis .. while to other clients 
still sending duplicate of best path like today - later with more 
experience gained to more and more clients being served by this cluster.

> to VPNV4 this should be accounted for when RR platforms are selected.

I think for RRs platforms scalability concerns for number of routes and 
number of sessions are no longer the issue. Talk to your favorite vendor 
for up to date RR's scalability numbers :) But you are very correct. 
Those need to be considered when RR platforms are selected.

> Scalability concerns.We would be putting our main primary RRs at risk.

Not sure what risk you are referring to. As indicated earlier for 
control plane RRs it is really not necessary step in the best path since 
day one.

> or something of that nature..

See above.

> getting all the routes on the secondary to make a decision.

This is normal introduction process of new RR into the network. But as 
said already few times this is optional.

> maintenance, etc... to get deployed

One needs to pick the right set of tools which he can accomplish the 
task with in the most easy way. My goal is to deliver various deployment 
options and assist in selection of the best set of tools to complete the 
job.

That's why I am not saying to do this one way .. Depending on network 
size, scale, complexity one may find adding a new RR as trivial 
exercise, on the other hand someone else may think of existing RR 
upgrade at the next upgrade window as pretty much free operation which 
needs to be performed anyway. Then enabling diverse path to some clients 
and seeing how it works seems like a very smooth and gradual deployment 
- much easier then any RR based alternatives I can think of today.

> goals of the draft in the intro/abstract.

So do I. Diverse path accommodates both goals just fine.

 > Probably good to be specific about the

Ack.

> routes source by them propagated through the network??

No :) I am saying that if you have 100s of IX of clients by default 
route server would send only one overall best. So if you have two RS 
(and this is common for redundancy) one may send overall best and the 
other one diverse path to the IX customers. 3rd best path would be also 
easy to achieve.

I will clarify this section.

Jim - Many thx for your excellent comments and review,
R.

---

From: Richard Li <[email-masked]>
Date: Wed, 23 Jun 2010 17:10:39 -0700

Let's assume that three planes of RR are deployed: The first plane
distributes the best path for each route as usual, the second plane for the
second best, and the third plane for the third best. Using your example, we
take the IGP distance as the equally-good path tie-breaker.  With different
IGP topology, one RR may view a path as the second best while another RR may
view the same path as the third best. For example, let's consider a route R
with paths P1, P2, P3, where P2 and P3 are equally good and thus need to be
broken by a tie breaker.  On the first plane RR, P1 is viewed as the best,
and is thus distributed as we hoped. On the second plane RR, P2 is viewed as
the second best and is thus distributed. On the third plane RR, however, P2
is viewed as the third best and the P3 is viewed as the second best, and
thus P2 is distributed, but this is not something we hoped to see.

In order to make it work, all RRs on all planes should put all the paths in
the same ordering, otherwise it will not correctly distribute the nth best
path. But can you do that under all circumstances? The above example shows
you can't, unless I have missed something.

Regards,

Renwei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, June 23, 2010 1:30 AM
To: [email-masked]
Cc: [email-masked]
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.

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-dist-01
.txt

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 24 Jun 2010 09:40:59 +0200

Hi Richard,

Your description is missing the concept of RR clusters.

Each plane should be present in each cluster. And all RRs serving paths 
in a given cluster need to either have equal IGP point of the network, 
disabled IGP metric consideration for best path calculation or have a 
way to learn what the best path of other plane is.

With this in mind your statement

"With different IGP topology, one RR may view a path as the second best 
while another RR may view the same path as the third best."

will not take place as the above conditions make sure that there is path 
consistency on a per cluster basis.

Note also that just like in normal IPv4/IPv6 networks where tie breaker 
is IGP metric there is no need for best path consistency across clusters 
without compromising loop free BGP property.

If you agree with the above I will make sure that the text in the draft 
is more clear on that.

Many thx,
R.

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Richard Li <[email-masked]>
Date: Thu, 24 Jun 2010 10:29:43 -0700

Hi Robert,

Certainly RR works with clusters, but this is not something essential to my
concern.

In order to make it work, all planes MUST have a consistent/same view about
whether a path P1 is better than another path P2 for any two paths P1 and P2
associated to the same route so that they will have the same ordering in
terms of "n-best/better" path. Only under this condition, the first plane
will distribute the best path, the second plane will distribute the second
best path, the third plane will distribute the third best path, and so on.
Otherwise, all the paths won't be correctly distributed since some paths
will be lost (e.g. the P3 in my original example).

Let's go back to your remarks. You have assumed three conditions:
(1) RRs have equal IGP point of the network
(2) IGP metric consideration is disabled for best path calculation 
(3) RRs have a way to learn what the best path of other plane is.

Well, if the IGP metric is taken out of consideration, it will work (but IGP
metric is already built into many production codes for best path selection).
But I am not convinced with the other two conditions. For the first
condition, it may be too much for an operator to have to deploy RRs with the
same IGP metric. Technically speaking, it is easy to make a topology to have
RRs with different IGP metrics. For the third condition, there hasn't been
such a spec about how to learn what the best path of another plane is.

Anyhow, I would appreciate it if you spell it out in length about path
consistency in your next draft.

Regards,

/RL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Raszuk
Sent: Thursday, June 24, 2010 12:41 AM
To: [email-masked]
Subject: Re: [GROW] I-D Action:draft-ietf-grow-diverse-bgp-path-dist-01.txt

Hi Richard,

Each plane should be present in each cluster. And all RRs serving paths in a
given cluster need to either have equal IGP point of the network, disabled
IGP metric consideration for best path calculation or have a way to learn
what the best path of other plane is.

Note also that just like in normal IPv4/IPv6 networks where tie breaker is
IGP metric there is no need for best path consistency across clusters
without compromising loop free BGP property.

If you agree with the above I will make sure that the text in the draft is
more clear on that.

Many thx,
R.

> distributes the best path for each route as usual, the second plane 
> for the second best, and the third plane for the third best. Using 
> your example, we take the IGP distance as the equally-good path 
> tie-breaker.  With different IGP topology, one RR may view a path as 
> the second best while another RR may view the same path as the third 
> best. For example, let's consider a route R with paths P1, P2, P3, 
> where P2 and P3 are equally good and thus need to be broken by a tie 
> breaker.  On the first plane RR, P1 is viewed as the best, and is thus 
> distributed as we hoped. On the second plane RR, P2 is viewed as the 
> second best and is thus distributed. On the third plane RR, however, 
> P2 is viewed as the third best and the P3 is viewed as the second best,
and thus P2 is distributed, but this is not something we hoped to see.
>
> In order to make it work, all RRs on all planes should put all the 
> paths in the same ordering, otherwise it will not correctly distribute 
> the nth best path. But can you do that under all circumstances? The 
> above example shows you can't, unless I have missed something.
>
> Regards,
>
> Renwei
>
>
>
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]
> Subject: [GROW] I-D 
> Action:draft-ietf-grow-diverse-bgp-path-dist-01.txt
>
services.
> 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.
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 24 Jun 2010 20:37:31 +0200

Hi Richard,

> terms of "n-best/better" path.

I think RR clusters are essential to your concern as the entire point is 
that the above consistency you are referring to has to be accomplished 
per RR cluster and not per full network to achieve diverse-path 
functional correctness.

> metric is already built into many production codes for best path selection).

AFAIK many shipping implementations have ways already to not consider 
IGP metric to next hops or will have it shortly :).

> same IGP metric.

It is relative to the design, but if you considering control plane RRs 
same IGP metric is reality in most cases. They are usually "on the 
stick" connected to some common switch/router.

> For the third condition, there hasn't been

It is pretty straightforward, does not require any changes to BGP 
protocol on the wire, but stay tuned. I will encourage

> consistency in your next draft.

Ok I will make it more clear.

Thx,
R.

---

From: <[email-masked]>
Date: Fri, 25 Jun 2010 10:57:34 +0200

Hi Robert, all

I share some of Jim's comments. To me the draft tries to cover too many
cases. What about a (additional ?) "simple"-diverse-bgp-path draft which
states that:
- add path is the long term solution
- in the short term, while all routers are not add path compliant, a
(possibly add path compliant) router could advertise multiple paths to
its peer by using multiple parallel standard BGP sessions.
- add path applications (specifications & relative tradeoff) can apply
as-is to diverse-simple.

That deployment model is already covered in the draft. But IMHO the
addition of  multiple (more complex) ones add unnecessary complexity
(given that a typical reader may be mainly interested in a single one).

Besides, that simplified framework would ensure that
"simple"-diverse-path applications (spec and issues) would be aligned
with add-path ones without additional work. This also removes the need
for independent RR in different planes to make coherent routing
decisions, which may be a source of discussions and complexity.

There are still points to be studied such as the correct handling of
parallel BGP sessions. e.g. what if session 0 -which advertise the best
path- goes down? To be safe, I would call for the shutdown (possibly
graceful shutdown :-) ) of the other // sessions

Thanks,
Best regards,
Bruno

> From: Robert Raszuk

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 25 Jun 2010 13:13:16 +0200

Hi Bruno,

Many thx for your comments and input.

> cases. What about a (additional ?) "simple"-diverse-bgp-path draft which

The draft has a simple mechanism defined which in one line can be 
summarized by the ability of RR to calculate a backup path and advertise 
such backup path to the IBGP peers.

Rest "complexity" you may be referring to are just deployment examples.

So if you and others think that some deployment examples are unnecessary 
I will be very happy to remove them in the next rev. Above all I want to 
make the draft clear as real target of the draft are operators and not 
vendors :).

IMHO the draft needs to cover three sections:

* Conditions when backup path calculation will result in diverse path - 
  in this draft I have just focused on one - IGP metric disabling or 
equalization. There is one more way that can be met and that will be 
covered by separate draft.

* Expected functionality on existing or new RRs

* Some deployment scenarios.

So if you think that some sections are not addressing any of the above 
or that there are too much options please point them.

> - add path is the long term solution

I would say that add-path may be a broader solution .. if it is the best 
long term remains to be seen. So far this draft focuses on addressing in 
the most easy way for operators current set of issues mainly need for 
fast connectivity restoration end to end and load-balancing (also end to 
end).

> its peer by using multiple parallel standard BGP sessions.

Parallel sessions is just one of deployment options. In fact practical 
analysis indicates that most deployments have already cluster based RR 
redundancy. In this scenario turning one RR into a diverse path RR for 
the clients is sufficient. It does not require any touch of the PEs 
configuration.

And indeed I think this scenario is missing from current deployment 
options and perhaps adding it will make it applicability of diverse path 
more clear.

> - add path applications (specifications&  relative tradeoff) can apply
> as-is to diverse-simple.
>

Ok .. point taken and will simplify this. I just covered more then 
required hoping that it will enable easy fit to any existing topology. 
But I am happy to simplify it to only one or two basic cases.

Ack.

> graceful shutdown :-) ) of the other // sessions

Good point, but perhaps for simplicity I will remove the parallel 
session case as it seems as not required for discussed functionality.

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 25 Jun 2010 16:19:22 +0200

Dear SPs and ISPs,

While gathering excellent comments on the diverse path scenarios form 
you I am currently evaluating the easiest deployment model.

For the recent few days I have heard both online and offline number of 
recommendations which call for different deployment scenario.

While I understand that it is difficult to fit each network with one 
size I would like to probe the community with a simple operational question:

Could you comment on the level of deployment complexity for the below 
independent operations ..

1. Adding a new IBGP session from PE/ASBR to RR without the need to 
configure new loopback on PE/ASBR

2. Adding a new IBGP session from PE/ASBR to RR with the need to 
configure new loopback on PE/ASBR and inject this loopback into the IGP

3. Enhancing one of existing RRs in each cluster in ability to advertise 
diverse-path to explicitly selected clients without any need to touch 
PE/ASBR configuration ?

4. Ignoring IGP metric consideration into BGP best path decision on RRs 
or making sure pair of given cluster RRs is in the same IGP location ?

5. Introducing new RR per cluster for dedicated diverse path function 
and adding it to client and non client ibgp mesh ?

6. Upgrading both existing primary RRs to make sure that no matter on 
their IGP location one would become a primary and one 
diverse-path/backup and that the path diversity will be assured ?

The answer can be very short something like:

1 - [Easy|Doable|Hard]
2 - [Easy|Doable|Hard]
3 - [Easy|Doable|Hard]
3 - [Easy|Doable|Hard]
4 - [Easy|Doable|Hard]
5 - [Easy|Doable|Hard]
6 - [Easy|Doable|Hard]

Please reply offline not to spam the grow WG list. I will summarize all 
answers anonymously and update the draft with this valuable input.

Many many thx,
R.