Hi Enke,
On Sat, 2 Sep 2006, Enke Chen wrote:
As I said many times, in some applications the router-id would work
fine, and in others the opaque numbers will be needed. It is
application specific and configuration driven. The spec needs to
support different types of path-id types.
I'm sorry, but you can't have your cake and eat it.
The discussion on problems with add-path /started/ with the problems
of router-ID. Are we just going to gloss over those? Suggesting they
can be worked around by allowing a speaker to still generate an
opaque-ID if a clash arises just brings us back to the problems raised
with that which lead you to return to router-ID.
You can't configure around it either.
In my reply to Curtis, I listed the condition under which the
router-id can be used as the path-id to emulate the full-mesh:
o client advertise only the bestpath (which is the current
paradigm). In other words, each speaker sources at most one path to
ibgp. Therefore (prefix, router-id) would be unique.
This doesn't work for the "seperate confeds which share one IGP and
leave external next-hops unchanged" case, which Curtis and you gave in
an earlier email.
It's an unusual case, but it seemed important..
I am amused that after all the discussions of and objections to the
'restrictions' of nexthop, we'd then be happy with something with even
greater restrictions.
Met vriendelijke groeten,