Hi Jakob,
draft-ietf-grow-simple-va-04 needs another deployment consideration.
Routes in the RIB (not the FIB) are sometimes used
to resolve BGP nexthops and nexthops for static routes.
Not sometimes .. Pretty much every time !
There is a rule not to resolve such nexthops using the default
route.
That is an option - true.
If routes are removed from the RIB, they will no
longer be able to resolve nexthops.
Disconnect ! Simple-va does not remove routes from RIB. It suppresses
overlapping less specific one.
An option is to suppress all by injecting the default, but this would be
configurable. Clearly if you allow that you should not disable next hop
resolution via default. Those two would be mutually exclusive.
Also, when resolving
nexthops, the resolving routes sometimes carry attributes
that are important to the resolving process. If the
default route is used to resolve nexthops, such attributes
would be lost. Examples of such attributes are
IGP distance (it may be the same as the default) and
whether it is on a tunnel.
Again ... default is the special case as described above. Other then
that the less specific would have the same next hop as potentially
suppressed more specific hence IGP distance would be the same.
An implementation may consider not to suppress routes with AIGP
attribute being significantly different but again I do not find it
necessary for routing correctness since the main assumption is identical
next hop.
The reason for that rule is this:
A non default route says: I can reach the advertised
network and all IP addresses covered by it. If any
IP address covered by this prefix is unreachable,
then it doesn't exist.
A default route says: I can reach many IP addresses,
but obviously not all of them. I can not tell you
which I can actually reach and which I can't.
Nothing guarantees that you can reach all destinations covered by a
subnet. (We have been working on negative routes in the past however
that effort has been shelved).
But I think you are missing the applicability of suppressing to the
default versus suppressing to the less specific.
1. Suppression to the default(s):
- Applicable to the edge routers in the POP when default route is
injected from all POP to core boundary routers into the POP.
Note: This mode could be also applicable to AS wide suppression only if
we could guarantee the exact symmetry of ASBR received BGP updates in
the AS.
2. Suppression to the less specific:
- Applicable in all cases.
Routes in the RIB may also be redistributed to other
protocols. If they no longer exist in the RIB, they
will not be redistributed.
In the default case - you are correct.
In the suppression by less specific redistribution will work just fine
routing wise.
The local implementation may tag routes to be suppressed at the BGP to
RIB boundary and only suppress tagged at the RIB to FIB to address
redistribution case. However redistribution of BGP to other protocols is
usually not that good of an idea hence we decided to leave it for now.
These considerations do not break the technique,
but they need to be stated.
I am happy to add above clarification to the text in the draft.
Many thx,
R.
--
Jakob Heitz.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ronald
Bonica
Sent: Monday, April 30, 2012 9:52 AM
To: [email protected]
Cc: [email protected]; [email protected]
Subject: Re: [GROW] draft-ietf-grow-simple-va
Robert,
This sounds reasonable to me. Please issue a new version of the draft, as the
current version has expired. When you issue a new version, change the filename,
so that it won't look like a WG submission. Also, ping me so that I can send
the document on for IETF Last Call.
Ron
-----Original Message-----
From: Robert Raszuk [mailto:[email protected]]
Sent: Monday, April 30, 2012 1:49 AM
To: Ronald Bonica
Cc: [email protected]; [email protected]
Subject: Re: [GROW] draft-ietf-grow-simple-va
Ron,
So, how do we proceed? If you want to demonstrate WG support of
>> draft-ietf-grow-simple-va, let the WG LC proceed. If you want to
publish without demonstrating WG support, I would be glad to AD
sponsor that draft.
Please proceed with AD sponsorship on this draft.
In my view the idea and the draft have already received sufficient
support within this group, other IETF and IRTF groups as well as
outside of IETF in various public forums.
Thx,
R.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
