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.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
