Pierre Pfister <mailto:[email protected]>
27 March 2014 08:50
Le 27 mars 2014 à 08:19, Ray Hunter<[email protected]> a écrit :
Mikael Abrahamsson<mailto:[email protected]>
27 March 2014 07:04
On Wed, 26 Mar 2014, Ray Hunter wrote:
HNCP as it stands right now has a "routing protocol" of it's own that is extremely
rudimentary, but it gets the job done. I think this is what is referred to as "zero routing
protcol" because people don't really want to call it a routing protocol (my interpretation).
That is my understanding of the "zero routing protocol » too.
Right, but the way I see it:
If you have an arbitrary topology then you probably need to carry metrics to
prefer one link type over another.
If you want to be able to determine which prefixes to delete from the FIB and
RA when a particular upstream provider link goes down, you probably need some
sort of tagging.
If you want fast convergence around failures you probably need a decent path
discovery algorithm.
If you want to differentiate between a temporary change (due to an incident or
link failure) and a longer term permanent change (due to replugging or device
insertion or removal) then you probably need two different sets of timers and
problem diagnostics.
In other words; we definitely need a routing protocol, and probably a
configuration protocol too.
So isn't the danger than HNCP starts off being very simple, and ends up
duplicating a lot of previous work and experience?
I'm interested to hear the contrarian view.
Except the second point (determine which prefix to delete…), which is done by
the prefix assignment algorithm on top of HNCP, all other points will have to
be answered to decide which routing protocol to use. The current draft doesn’t
intend to answer the routing protocol issue. It was not left blank for the
simple reason we needed to implement it and make it run.
I think that's still an open question "(determine which prefix to
delete…)", and an interesting side effect of a decision to split routing
and prefix assignment.
e.g. looking at
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06
section 5.2
and especially considering any end hosts that do not understand
http://tools.ietf.org/html/draft-troan-homenet-sadr-00,
do you want RA to start or stop advertising a prefix (hat has been
derived from an upstream neighbor) on a local interface as a candidate
default routeto locally connected end systems because the path to that
ISP is down (routing), or because of a configuration timeout (DHCPv6 PD
+ HNCP), or both, or neither?
I dont think we want to run a complex routing protocol in HNCP. It’s more like
either we want to make something very simple, and we use HNCP for this, or we
want all what you said, and we use another existing protocol. The point of the
draft is just to let you know that it is *possible* to route packets, in a very
simple way, by using just HNCP as it is, with no extra information.
Regards,
Pierre
--
Regards,
RayH
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
------------------------------------------------------------------------
--
Regards,
RayH
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
