Re: [homenet] Homenet protocol decisions
Teco, >>> There is something common on prefix distribution in Homenet, small >>> office/home office networks, branch office networks, ad hoc networks and >>> even in enterprise / campus networks. The prefix distribution protocol >>> could be a single protocol. We better not try to converge to a single >>> routing protocol. >> >> how do you do a self-organizing / zero-conf network without making a choice? > > I ment: We better not try to converge to a single routing protocol for > Homenet, small office/home office networks, branch office networks, ad hoc > networks and enterprise / campus networks. OK, but at least we can pick a single routing protocol for the home. > If distributed info semantics for prefix distribution are well defined, it > doesn't matter how it is delivered. Single encoding method helps, it is not > absolutely required. If a box faces two routing domains, it redistributes. > With DV style of flooding, this is simple and straightforward. right. but we don't have to specify that in this working group, or at least not now. > I still believe hosts shall be informed of information on border routers / > exit links and corresponding prefix information. And I prefer hosts shall not > have a need to snoop routing packets for that. Using a NDP extension is a > no-brainer for me. > > So yes, Homenet shall select a single routing protocol for higher data rate > links (next to LLN routing, that one is separate). > We can check how to run a prefix distribution protocol on top of routing, or > use another carrier (e.g. NDP). > > My opinion: put the prefix distribution protocol on top of NDP, so all nodes > are informed. what are the arguments for involving hosts in the prefix assignment protocol? as opposed the existing router to hosts protocols (ND/DHCP). cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Op 31 jan. 2014, om 18:13 heeft Lorenzo Colitti het volgende geschreven: > On Fri, Jan 31, 2014 at 12:37 AM, Mikael Abrahamsson wrote: >>> If the routing protocol and the prefix distribution protocol are separate, >>> then they can end up with different ideas on what prefix is on a given >>> link. That will lead to blackholing. >> >> I don't agree. >> >> I think a valid approach is to have a separate protocol set the address on >> an interface which is then picked up by the routing protocol and >> redistributed just like if it was manually configured. > > And what happens when the routing protocol finds out that, even though the > delegation protocol thinks everything is OK and addresses were delegated just > fine, the network is now partitioned? How do you reassign addresses in that > case? I don't see a problem. If the two partitions have border router(s), addresses for the prefixes for the connected border router keeps functioning. Prefixes for the disconnected border router(s) should be deprecated. Is is an internal function on the router, based on topology information and configured prefixes, provided by routing protocol and prefix distribution protocol. > How do you tell the prefix assignment protocol that it needs to resolve > addressing conflicts when you merge two networks that have the same prefixes? First we have to verify if this can happen. My favorite is using DHCP-PD with server on CPE (edge) box (and elected box for ULA). This box should circumvent your scenario. > You have to tightly couple prefix assignment and routing again. In which case > it's just better to have the same protocol. I can't follow your arguments. > >> Routing protocol deamons normally don't set interface IP addresses, they >> carry de-facto information they get from other places and the only thing >> they update is the RIB/FIB in the machine. >> > Yes, but in that case the responsibility for getting IP addresses correct and > non-overlapping falls on the operator. A self-organizing network doesn't have > an operator. I can't see how strongly coupled routing protocol and prefix distribution protocol can help. > >> So to continue this, even carrying service discovery information leads to >> new information flow in that the routing protocol now needs to update a >> service discovery "Information Base". > > That's different. The assumption at the service layer is that below it, the > network will figure out routing and addressing, and packets either get to the > destination or they don't. What you're talking about is to have two strongly > coupled things in the networking layer (addressing and routing) be run by > separate protocols. Yes, they are (strongly) related. That doesn't mean that they shall be processed by same protocol. Maybe better have two simple protocols, with minimal interaction. Both protocols will have their own life cycle. Teco ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Op 31 jan. 2014, om 12:36 heeft Ole Troan het volgende geschreven: I can see reasons for having shared sub-layer for routing protocol and prefix distribution protocol. As example, in MANET we have such already: RFC 5444 and 5498. If we define a set of TLVs for border router information and prefix distribution, it can run on whatever routing protocol. Don't forget BGP. For Homenet plug&play, I don't suggest to let configure grandma her favorite IGP ;) >>> >>> doesn't that mean we have to pick one? >> >> At least one, for Homenet. Could be OSPF for high speed links, RPL for LLN, >> or OLSRv2 for mix of wireless and wired links including ad hoc radio links. >> >> There is something common on prefix distribution in Homenet, small >> office/home office networks, branch office networks, ad hoc networks and >> even in enterprise / campus networks. The prefix distribution protocol could >> be a single protocol. We better not try to converge to a single routing >> protocol. > > how do you do a self-organizing / zero-conf network without making a choice? I ment: We better not try to converge to a single routing protocol for Homenet, small office/home office networks, branch office networks, ad hoc networks and enterprise / campus networks. If distributed info semantics for prefix distribution are well defined, it doesn't matter how it is delivered. Single encoding method helps, it is not absolutely required. If a box faces two routing domains, it redistributes. With DV style of flooding, this is simple and straightforward. I still believe hosts shall be informed of information on border routers / exit links and corresponding prefix information. And I prefer hosts shall not have a need to snoop routing packets for that. Using a NDP extension is a no-brainer for me. So yes, Homenet shall select a single routing protocol for higher data rate links (next to LLN routing, that one is separate). We can check how to run a prefix distribution protocol on top of routing, or use another carrier (e.g. NDP). My opinion: put the prefix distribution protocol on top of NDP, so all nodes are informed. Teco > > cheers, > Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Le 31/01/2014 09:56, Ole Troan a écrit : Teco, I can see reasons for having shared sub-layer for routing protocol and prefix distribution protocol. As example, in MANET we have such already: RFC 5444 and 5498. If we define a set of TLVs for border router information and prefix distribution, it can run on whatever routing protocol. Don't forget BGP. For Homenet plug&play, I don't suggest to let configure grandma her favorite IGP ;) doesn't that mean we have to pick one? Yes, and here's my preferred: pick DHCP, it satisfies all requirements; where it doesnt update it. Then plug it into OSPF, then onto BGP. Alex cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Le 30/01/2014 22:13, Lorenzo Colitti a écrit : On Thu, Jan 30, 2014 at 2:48 AM, Ole Troan mailto:otr...@employees.org>> wrote: We need to decide, if we want prefix assignment and distribution of other configuration information integrated in a routing protocol. I think the two should be in the same protocol, because routing and addressing are tightly coupled. Fundamentally, there is no point in configuring an address on a host if the homenet doesn't have reachability to it - because you can't use that address to talk to anyone else in the homenet. (just a little point here, because I am encouraged by the beginning of the paragraph; yes, you can use a topologically incorrect address as src in outgoing packets, there are video stream applications for that; they work especially in the small setting of home, where there's no ingress filtering). If the routing protocol and the prefix distribution protocol are separate, then they can end up with different ideas on what prefix is on a given link. That will lead to blackholing. I tend to agree, modulo exception above. And provided I udnerstand the word 'blackholing'... Alex ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Teco Boot wrote: >>> I can see reasons for having shared sub-layer for routing protocol and prefix distribution protocol. As example, in MANET we have such already: RFC 5444 and 5498. If we define a set of TLVs for border router information and prefix distribution, it can run on whatever routing protocol. Don't forget BGP. >>> >>> For Homenet plug&play, I don't suggest to let configure grandma her favorite IGP ;) >> >> doesn't that mean we have to pick one? > At least one, for Homenet. Could be OSPF for high speed links, RPL for > LLN, or OLSRv2 for mix of wireless and wired links including ad hoc > radio links. Lest people worry about who is going to configure all of this, I want to point out that actually each of these protocols run in networks different security profiles. That is, the set of links running OSPF in Homenet are mostly equivalent security/trust-wise (taking into account that Fred and his wife will have tweaked things to live with their seperate corporate policies). The links running RPL are part of the Home *Automation* Network, and depending upon who is doing things, may be less or more trusted than the OSPF parts (probably, also depending upon your point of view). There will be routers/firewalls that speak Homenet/OSPF on one side and RPL on the other. Ditto for the OLSRv2/AODV/Babel adhoc running links: they are essentially alternative "uplinks", which from the Homenet point of view are weird wall-free walled gardens. (Hanging gardens? http://en.wikipedia.org/wiki/Hanging_Gardens_of_Babylon note tower of babeld in the background) I've asked that we come to some decision about how we are going to make the protocol decision. It's been dragging on for over a year now. -- Michael Richardson , Sandelman Software Works pgpmJ4nm87P4A.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Speaking as an interested observer only... On 1/31/14 3:57 AM, Teco Boot wrote: > +1 > > I can see reasons for having shared sub-layer for routing protocol > and prefix distribution protocol. As example, in MANET we have such > already: RFC 5444 and 5498. If we define a set of TLVs for border > router information and prefix distribution, it can run on whatever > routing protocol. Don't forget BGP. > Yes, let's not forget BGP (but probably not for the reasons Teco mentions it). Many folks have expressed regrets over the years with the amount of extra baggage that has been added to BGP. Most of the time, the argument for adding this non-routing stuff is that the distribution model is the same. The results have been less than stellar, IMO. However, we have to consider that the rate of information update for reachability is not the same as the update rate for prefix delegation. Will the transport of that extra information lead to performance issues, incompatibility with other devices speaking the same protocol, or concerns over the security model needed for these two different functions? Just food for thought. Regards, Brian signature.asc Description: OpenPGP digital signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
>>> I can see reasons for having shared sub-layer for routing protocol and >>> prefix distribution protocol. As example, in MANET we have such already: >>> RFC 5444 and 5498. If we define a set of TLVs for border router information >>> and prefix distribution, it can run on whatever routing protocol. Don't >>> forget BGP. >>> >>> For Homenet plug&play, I don't suggest to let configure grandma her >>> favorite IGP ;) >> >> doesn't that mean we have to pick one? > > At least one, for Homenet. Could be OSPF for high speed links, RPL for LLN, > or OLSRv2 for mix of wireless and wired links including ad hoc radio links. > > There is something common on prefix distribution in Homenet, small > office/home office networks, branch office networks, ad hoc networks and even > in enterprise / campus networks. The prefix distribution protocol could be a > single protocol. We better not try to converge to a single routing protocol. how do you do a self-organizing / zero-conf network without making a choice? cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Op 31 jan. 2014, om 09:56 heeft Ole Troan het volgende geschreven: > Teco, > >> I can see reasons for having shared sub-layer for routing protocol and >> prefix distribution protocol. As example, in MANET we have such already: RFC >> 5444 and 5498. If we define a set of TLVs for border router information and >> prefix distribution, it can run on whatever routing protocol. Don't forget >> BGP. >> >> For Homenet plug&play, I don't suggest to let configure grandma her favorite >> IGP ;) > > doesn't that mean we have to pick one? At least one, for Homenet. Could be OSPF for high speed links, RPL for LLN, or OLSRv2 for mix of wireless and wired links including ad hoc radio links. There is something common on prefix distribution in Homenet, small office/home office networks, branch office networks, ad hoc networks and even in enterprise / campus networks. The prefix distribution protocol could be a single protocol. We better not try to converge to a single routing protocol. Teco > > cheers, > Ole > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
On 31.1.2014, at 11.16, Ole Troan wrote:
>> So to continue this, even carrying service discovery information leads to
>> new information flow in that the routing protocol now needs to update a
>> service discovery "Information Base". At least this is less intrusive than
>> having it set interface IP addresses.
>
> there is another choice to make here.
> either the homenet 'control' protocol floods service discovery records, or it
> is used only to boot strap an independent service discovery mechanism.
>
> the hybrid mDNS proxy is an implementation using the latter approach.
>
> SD has turned out to be a lot harder to solve than at least I thought it
> would be.
SD would be much more trivial to solve if we allowed host changes, or at least
would write about desired features there. E.g. no mDNS, just use DNS-SD[1] or
something equally clever, and then you would have really consistent database of
active services across the network that routers could share, or could have god
DNS server, or something else (dtath’s DHT perhaps).
3.1.2 doesn’t sound very promising on that front (or the hundreds of millions
of fruity logo compatible devices that mostly do mDNS and consider that all SD
they ever need; then again, wonder how many of them do IPv6, or more
specifically, non-linklocal IPv6).
Cheers,
-Markus
[1] with insecure dns-update (RFC2136) and allowing only updating records are
related pertain to your IP{v4,v6} address and some sort of expiration logic
based on your L2 presence it might work reasonably well?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Mikael, > So to continue this, even carrying service discovery information leads to new > information flow in that the routing protocol now needs to update a service > discovery "Information Base". At least this is less intrusive than having it > set interface IP addresses. there is another choice to make here. either the homenet 'control' protocol floods service discovery records, or it is used only to boot strap an independent service discovery mechanism. the hybrid mDNS proxy is an implementation using the latter approach. SD has turned out to be a lot harder to solve than at least I thought it would be. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Teco, > I can see reasons for having shared sub-layer for routing protocol and prefix > distribution protocol. As example, in MANET we have such already: RFC 5444 > and 5498. If we define a set of TLVs for border router information and prefix > distribution, it can run on whatever routing protocol. Don't forget BGP. > > For Homenet plug&play, I don't suggest to let configure grandma her favorite > IGP ;) doesn't that mean we have to pick one? cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
+1 I can see reasons for having shared sub-layer for routing protocol and prefix distribution protocol. As example, in MANET we have such already: RFC 5444 and 5498. If we define a set of TLVs for border router information and prefix distribution, it can run on whatever routing protocol. Don't forget BGP. For Homenet plug&play, I don't suggest to let configure grandma her favorite IGP ;) Teco Op 31 jan. 2014, om 09:37 heeft Mikael Abrahamsson het volgende geschreven: > On Thu, 30 Jan 2014, Lorenzo Colitti wrote: > >> If the routing protocol and the prefix distribution protocol are separate, >> then they can end up with different ideas on what prefix is on a given link. >> That will lead to blackholing. > > I don't agree. > > I think a valid approach is to have a separate protocol set the address on an > interface which is then picked up by the routing protocol and redistributed > just like if it was manually configured. > > Routing protocol deamons normally don't set interface IP addresses, they > carry de-facto information they get from other places and the only thing they > update is the RIB/FIB in the machine. > > So to continue this, even carrying service discovery information leads to new > information flow in that the routing protocol now needs to update a service > discovery "Information Base". At least this is less intrusive than having it > set interface IP addresses. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
On Thu, 30 Jan 2014, Lorenzo Colitti wrote: If the routing protocol and the prefix distribution protocol are separate, then they can end up with different ideas on what prefix is on a given link. That will lead to blackholing. I don't agree. I think a valid approach is to have a separate protocol set the address on an interface which is then picked up by the routing protocol and redistributed just like if it was manually configured. Routing protocol deamons normally don't set interface IP addresses, they carry de-facto information they get from other places and the only thing they update is the RIB/FIB in the machine. So to continue this, even carrying service discovery information leads to new information flow in that the routing protocol now needs to update a service discovery "Information Base". At least this is less intrusive than having it set interface IP addresses. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
