Re: [homenet] Reachability of distributed prefixes
On 01/09/2015 01:24, Gert Doering wrote: > Hi, > > On Sun, Aug 30, 2015 at 10:03:47PM -0700, joel jaeggli wrote: And that's a well-known issue that the IETF needs to finally tackle: source-address failover. >> >> So long as you don't invoke the prospect of either extremely expnesive >> overlay networks, or globably route scalability go right ahead those are >> both in play already. >> >> Hosts in in absence of state as turns out are rather good at >> instantaneous renumbering. e.g. as they roam between networks it >> remains a mystery to me that networks containy hosts are less able to >> cope. I may be in fact that that they are not less able to cope. > > No, that wasn't what I was talking about. Not "I get a new source address > and need to cope it", but "I have two source addresses with global scope, > tried one according to source-selection rules, it did not work, so I > should maybe try the other one now?" Yes, you're correct that shim6 doesn't do that, and has other deployability issues that I noted. But unless we want every application and/or transport protocol to contain its own variant of happy eyeballs, this functionality (suck-it-and-see-until-it-works) would need to be inserted as a shim in the socket layer or somewhere around there. I'm not convinced there's a protocol involved, though. It's more a matter of "history", in the sense used in draft-baker-6man-multi-homed-host. Brian > > No network dynamics of any kind involved, just "a normal homenet > multi-ISP scenario" (with some breakage "somewhere upstream", not > something the host can easily see) - I thought that this would have been > obvious from the thread and WG list context. > > The advertised IETF solution for "(SoHo) multihoming" is "multiple global > IPv6 addresses", but this does not work yet as well as it could, partly > due to this missing piece. > > Gert Doering > -- NetMaster > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
Hi, On Sun, Aug 30, 2015 at 10:03:47PM -0700, joel jaeggli wrote: > >> And that's a well-known issue that the IETF needs to finally tackle: > >> source-address failover. > > So long as you don't invoke the prospect of either extremely expnesive > overlay networks, or globably route scalability go right ahead those are > both in play already. > > Hosts in in absence of state as turns out are rather good at > instantaneous renumbering. e.g. as they roam between networks it > remains a mystery to me that networks containy hosts are less able to > cope. I may be in fact that that they are not less able to cope. No, that wasn't what I was talking about. Not "I get a new source address and need to cope it", but "I have two source addresses with global scope, tried one according to source-selection rules, it did not work, so I should maybe try the other one now?" No network dynamics of any kind involved, just "a normal homenet multi-ISP scenario" (with some breakage "somewhere upstream", not something the host can easily see) - I thought that this would have been obvious from the thread and WG list context. The advertised IETF solution for "(SoHo) multihoming" is "multiple global IPv6 addresses", but this does not work yet as well as it could, partly due to this missing piece. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpx6teaSxGkl.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
Hi, On Mon, Aug 31, 2015 at 01:16:28PM +1200, Brian E Carpenter wrote: > > And that's a well-known issue that the IETF needs to finally tackle: > > source-address failover. > > We did - it's called shim6. The trouble is that we can't deploy it > because of stupid firewalls blocking the necessary extension headers. And that it solves a different problem. But otherwise, yes, shim6 would have been nice to see... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpXzqbgvABJo.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On 8/30/15 6:16 PM, Brian E Carpenter wrote: > On 31/08/2015 09:27, Gert Doering wrote: >> Hi, >> >> On Wed, Aug 26, 2015 at 03:07:50PM +0200, Henning Rogge wrote: Short-term reachability indications are sent to hosts in a reactive manner, using ICMP unreachables. If any applications are unable to do the right thing with ICMP unreachables, we should fix the applications. >>> >>> I am not aware of any application doing anything more than "try to >>> open the connection again". >>> >>> How do you propose the application to react? Most applications leave >>> the source-IP selection to the operation system... >>> >>> does any OS currently change the preference order of IPv6 source >>> prefixes when it gets ICMP unreachable messages? >> >> And that's a well-known issue that the IETF needs to finally tackle: >> source-address failover. So long as you don't invoke the prospect of either extremely expnesive overlay networks, or globably route scalability go right ahead those are both in play already. Hosts in in absence of state as turns out are rather good at instantaneous renumbering. e.g. as they roam between networks it remains a mystery to me that networks containy hosts are less able to cope. I may be in fact that that they are not less able to cope. > We did - it's called shim6. The trouble is that we can't deploy it > because of stupid firewalls blocking the necessary extension headers. Give it a rest. we work with have we have, not might want other people to deploy at great expense for our benfit. >Brian > >> This is way bigger than just homenet-related, >> as it will basically affect every host that has multiple equally-scoped >> IPv6 addresses where one of them has intermittent failures. >> >> Hosts need to learn to cope - the failure could be in the ISP1 network, >> so there is nothing HNCP could do inside the homenet to signal "uh, btw, >> do not use prefix1 for connections to ISP_Z, it's broken right now" (first, >> it does not know the scope, second, it has no mechanism to tell). >> >> Gert Doering >> -- NetMaster >> > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > signature.asc Description: OpenPGP digital signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
Hi, On Wed, Aug 26, 2015 at 03:07:50PM +0200, Henning Rogge wrote: > > Short-term reachability indications are sent to hosts in a reactive manner, > > using ICMP unreachables. If any applications are unable to do the right > > thing with ICMP unreachables, we should fix the applications. > > I am not aware of any application doing anything more than "try to > open the connection again". > > How do you propose the application to react? Most applications leave > the source-IP selection to the operation system... > > does any OS currently change the preference order of IPv6 source > prefixes when it gets ICMP unreachable messages? And that's a well-known issue that the IETF needs to finally tackle: source-address failover. This is way bigger than just homenet-related, as it will basically affect every host that has multiple equally-scoped IPv6 addresses where one of them has intermittent failures. Hosts need to learn to cope - the failure could be in the ISP1 network, so there is nothing HNCP could do inside the homenet to signal "uh, btw, do not use prefix1 for connections to ISP_Z, it's broken right now" (first, it does not know the scope, second, it has no mechanism to tell). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
>> Short-term reachability indications are sent to hosts in a reactive manner, >> using ICMP unreachables. If any applications are unable to do the right >> thing with ICMP unreachables, we should fix the applications. > How do you propose the application to react? Most applications leave > the source-IP selection to the operation system... Right. That's a good point. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, Aug 26, 2015 at 3:27 PM, Philip Homburg wrote: >>I am not aware of any application doing anything more than "try to >>open the connection again". >> >>How do you propose the application to react? Most applications leave >>the source-IP selection to the operation system... >> >>does any OS currently change the preference order of IPv6 source >>prefixes when it gets ICMP unreachable messages? > > I never bothered to automate, but I regularly switch prefixes by changing > the preference times in RAs. That works very well. > > Linking general ICMP unreachable messages to a source prefix sounds very hard > to me. RA's are generated by the HNCP router, so the generation could take the routing table into account (put prefixes WITH routes in preferred places). If the routing protocol would export the "distance" to the destination in form of the routing table metric value, the RA generation could even make sure that the "closest" gateway is always the preferred one. So we can manipulate the published RAs in a way that the hosts will take normally one the HNCP router prefers? Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
In your letter dated Wed, 26 Aug 2015 15:07:50 +0200 you wrote: >On Wed, Aug 26, 2015 at 2:31 PM, Juliusz Chroboczek > wrote: >> What I'm saying is that neither DHCPv4 nor IPv6 RA are designed to deal >> with prefixes that last less than a few hours. See for example RFC 4862 >> Section 5.5.3 paragraph e2. (That's just an example, there are other >> reasons why yo-yo RAs are a bad idea.) >> >> Short-term reachability indications are sent to hosts in a reactive manner, >> using ICMP unreachables. If any applications are unable to do the right >> thing with ICMP unreachables, we should fix the applications. > >I am not aware of any application doing anything more than "try to >open the connection again". > >How do you propose the application to react? Most applications leave >the source-IP selection to the operation system... > >does any OS currently change the preference order of IPv6 source >prefixes when it gets ICMP unreachable messages? I never bothered to automate, but I regularly switch prefixes by changing the preference times in RAs. That works very well. Linking general ICMP unreachable messages to a source prefix sounds very hard to me. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, Aug 26, 2015 at 2:31 PM, Juliusz Chroboczek wrote: >>> So if a route is flapping, hosts get or don't get an IP depending on the >>> exact time when they send a DHCPREQUEST or NS? Is that better than always >>> assigning an IP to hosts, and expecting ICMP to signal route flapping in >>> real time? > >> Are you talking about a route that is created and vanishes every few >> seconds or minutes? > > What I'm saying is that neither DHCPv4 nor IPv6 RA are designed to deal > with prefixes that last less than a few hours. See for example RFC 4862 > Section 5.5.3 paragraph e2. (That's just an example, there are other > reasons why yo-yo RAs are a bad idea.) > > Short-term reachability indications are sent to hosts in a reactive manner, > using ICMP unreachables. If any applications are unable to do the right > thing with ICMP unreachables, we should fix the applications. I am not aware of any application doing anything more than "try to open the connection again". How do you propose the application to react? Most applications leave the source-IP selection to the operation system... does any OS currently change the preference order of IPv6 source prefixes when it gets ICMP unreachable messages? Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
>> So if a route is flapping, hosts get or don't get an IP depending on the >> exact time when they send a DHCPREQUEST or NS? Is that better than always >> assigning an IP to hosts, and expecting ICMP to signal route flapping in >> real time? > Are you talking about a route that is created and vanishes every few > seconds or minutes? What I'm saying is that neither DHCPv4 nor IPv6 RA are designed to deal with prefixes that last less than a few hours. See for example RFC 4862 Section 5.5.3 paragraph e2. (That's just an example, there are other reasons why yo-yo RAs are a bad idea.) Short-term reachability indications are sent to hosts in a reactive manner, using ICMP unreachables. If any applications are unable to do the right thing with ICMP unreachables, we should fix the applications. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, Aug 26, 2015 at 12:06 PM, Juliusz Chroboczek wrote: >> Yes. If DHCP server and radvd wait until the route to the prefix is >> available in the routing table, we keep the decision about >> "reachability" to the routing protocol without having a hard dependency >> on it. > > So if a route is flapping, hosts get or don't get an IP depending on the > exact time when they send a DHCPREQUEST or NS? Is that better than always > assigning an IP to hosts, and expecting ICMP to signal route flapping in > real time? Are you talking about a route that is created and vanishes every few seconds or minutes? I would guess some kind of hysteresis would be okay. Activate a prefix if you had a route for X seconds... deactivate it if you loose it for X seconds. Still, assigning a source IP address without a route to it is a bad thing, some client applications might just keep trying instead of moving to a different source address. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
> Yes. If DHCP server and radvd wait until the route to the prefix is > available in the routing table, we keep the decision about > "reachability" to the routing protocol without having a hard dependency > on it. So if a route is flapping, hosts get or don't get an IP depending on the exact time when they send a DHCPREQUEST or NS? Is that better than always assigning an IP to hosts, and expecting ICMP to signal route flapping in real time? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, Aug 26, 2015 at 11:50 AM, Mikael Abrahamsson wrote: > On Wed, 26 Aug 2015, Henning Rogge wrote: > >> I wonder if HNCP routers should apply all addresses/prefixes to its local >> interfaces, but should check for an existing route to the HNCP router that >> announce the prefix before providing it via DHCP or RA to hosts. > > > Let me rephrase what I think you're saying and tell me if I'm correct: > > Your worry is that HNCP will determine neighbors and speak HNCP well enough, > but the routing protocol thinks the link is so bad, that it's effectively > has partitioned the network (because this was the only link connecting the > two (now) parts), and since there might be two uplinks, you want HNCP to > detect this partition, and only hand out ISP1 prefixes on the side where > ISP1 works, and only ISP2 prefixes, on the ISP2 side that works. Also, if > the network is partitioned, you want prefixes no longer reachable to be sent > corresponding RAs with zero lifetime etc, to make hosts no longer use them > for new connections? This is a good example. > So one way of doing this would be for hnetd to check if the ISPx prefix (for > instance /56) is in the routing table, and if it isn't, it should not use it > to put addresses on interface etc, and if it goes away (at least for any > duration of time), stop using it. Yes. If DHCP server and radvd wait until the route to the prefix is available in the routing table, we keep the decision about "reachability" to the routing protocol without having a hard dependency on it. > I don't remember seeing this discussed anywhere, but it might very well be > something that should be done. I would imagine HNCP is reacting on ISP1 WAN > link going down and stopping to use the ISP1 prefix, but if there is a break > within the homenet (routing protocol wise), nothing is done as long as HNCP > is up. > > One way of solving this would be to create fate-sharing between HNCP and the > routing protocol. Ie, HNCP wouldn't do anything unless there is a valid > routing protocol adjacency with that neighbor (=fate sharing). Yes. HNCP has its own "control plane" (and it needs this control plane), but if we use the neighbor information within HNCP to decide if a prefix is reachable we might create a different view than the routing protocol, which has its own idea what is reachable and what not. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
> If I understand HNCP right then the "uplink" will announce a prefix > which should be used by all routers for the attached hosts. Er... no. The "uplink", or delegating router in Homenet parlance, only announces a source-specific route. It's the routers performing the assignment that announce a route to the prefix. > The problem will appear if HNCP learns about this prefix through DNCP > but the routing protocol cannot provide a route to the uplink (because > hysteresis decided one of the links is too bad). That's not how Babel's hysteresis works. But yes, the link quality estimator and routing metric being used could decide that none of the routes are usable. > I wonder if HNCP routers should apply all addresses/prefixes to its > local interfaces, but should check for an existing route to the HNCP > router that announce the prefix before providing it via DHCP or RA to > hosts. This would cause renumbering whenever the routing protocol has a hiccup. Instead, what HNCP does is that it assigns one prefix for each delegated prefix, and instructs hosts to grab one address for each assigned prefix. Hosts are then expected to do the happy eyeballs/ICMP unreachable dance. Or to run Babel. (Ducks.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, 26 Aug 2015, Henning Rogge wrote: I wonder if HNCP routers should apply all addresses/prefixes to its local interfaces, but should check for an existing route to the HNCP router that announce the prefix before providing it via DHCP or RA to hosts. Let me rephrase what I think you're saying and tell me if I'm correct: Your worry is that HNCP will determine neighbors and speak HNCP well enough, but the routing protocol thinks the link is so bad, that it's effectively has partitioned the network (because this was the only link connecting the two (now) parts), and since there might be two uplinks, you want HNCP to detect this partition, and only hand out ISP1 prefixes on the side where ISP1 works, and only ISP2 prefixes, on the ISP2 side that works. Also, if the network is partitioned, you want prefixes no longer reachable to be sent corresponding RAs with zero lifetime etc, to make hosts no longer use them for new connections? So one way of doing this would be for hnetd to check if the ISPx prefix (for instance /56) is in the routing table, and if it isn't, it should not use it to put addresses on interface etc, and if it goes away (at least for any duration of time), stop using it. I don't remember seeing this discussed anywhere, but it might very well be something that should be done. I would imagine HNCP is reacting on ISP1 WAN link going down and stopping to use the ISP1 prefix, but if there is a break within the homenet (routing protocol wise), nothing is done as long as HNCP is up. One way of solving this would be to create fate-sharing between HNCP and the routing protocol. Ie, HNCP wouldn't do anything unless there is a valid routing protocol adjacency with that neighbor (=fate sharing). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On 26.8.2015, at 12.39, Henning Rogge wrote: > My problem is not with the prefixes assigned to the interfaces of HNCP > routers itself, my problem is with the prefixes provided to attached > hosts. > > If I understand HNCP right then the "uplink" will announce a prefix > which should be used by all routers for the attached hosts. > > The problem will appear if HNCP learns about this prefix through DNCP > but the routing protocol cannot provide a route to the uplink (because > hysteresis decided one of the links is too bad). > > I wonder if HNCP routers should apply all addresses/prefixes to its > local interfaces, but should check for an existing route to the HNCP > router that announce the prefix before providing it via DHCP or RA to > hosts. I think this ties it too tightly to a RP; routes _can_ appear and disappear over time after all, so if you follow this logic to it’s logical conclusion, you would have to make decision that e.g. 95% of the time, this delegated prefix has functioned and it does not flap frequently, so we can subdelegate it. Leading to relatively much state duplicated both within RP (hysteresis) and HNCP daemon (long-term route validity/flap statistics/..). I would personally rather just say ’too bad’ in such a network :) YMMV of course. I would not personally mind _implementations_ that did this, given they knew they used RP with hysteresis, but I disagree with sticking this in base spec itself. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
My problem is not with the prefixes assigned to the interfaces of HNCP routers itself, my problem is with the prefixes provided to attached hosts. If I understand HNCP right then the "uplink" will announce a prefix which should be used by all routers for the attached hosts. The problem will appear if HNCP learns about this prefix through DNCP but the routing protocol cannot provide a route to the uplink (because hysteresis decided one of the links is too bad). I wonder if HNCP routers should apply all addresses/prefixes to its local interfaces, but should check for an existing route to the HNCP router that announce the prefix before providing it via DHCP or RA to hosts. This would not create a dependency loop between routing protocol and HNCP because the routing protocol does only advertise the addresses/prefixes configured on the HNCP interfaces. But it would prevent HNCP to announce a prefix that is not reachable via the routing protocol. Henning Rogge On Wed, Aug 26, 2015 at 11:33 AM, Juliusz Chroboczek wrote: >> It is not uncommon for wireless links to use some kind of hysteresis >> on a routing protocol. The problem/feature of D/HNCP is that it is >> independent of the routing protocol... so it does not know. > > I'm not sure I'm following you. > > All that shncpd does is to announce attached prefixes over the routing > protocol. It is then the routing protocol's business to pick a path to > one of the routers advertising the prefix (or to drop all such routes, if > the link quality has collapsed too much). > > -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
> It is not uncommon for wireless links to use some kind of hysteresis > on a routing protocol. The problem/feature of D/HNCP is that it is > independent of the routing protocol... so it does not know. I'm not sure I'm following you. All that shncpd does is to announce attached prefixes over the routing protocol. It is then the routing protocol's business to pick a path to one of the routers advertising the prefix (or to drop all such routes, if the link quality has collapsed too much). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
> [...] each router connected to said [Common] link: > MUST forward traffic destined to said prefix to the respective link. Here's the mechanism in the shncpd implementation, Steven will hopefully tell me if that's what's intended: - for each locally delegated prefix P, we install: - a source-specific default unreachable route (::/0, P); - an unreachable route to P; - for each prefix Q assigned (and applied) to an interface E, we install: - a route to Q through E. All of those routes are announced over Babel, even the unreachable routes. Babel propagates them in their usual manner. If at a given point in the Homenet the Babel metric for Q is finite, longest-prefix routing will call it to be routed to the nearest (according to Babel's metric) router attached to link E. If the link quality is so bad that the metric for Q is infinite, packets destined for Q will follow the covering route to P and reach the router delegating P, where they will be dropped by the unreachable route. If both routes have infinite metric, then the network is so bad that I really don't care. Note by the way that the non-Homenet routes are *not* announced over Babel, unlike in the hnetd implementation, which announces all routes. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, Aug 26, 2015 at 9:42 AM, Mikael Abrahamsson wrote: > Hm, there must be some preconception here that I do not understand. > > Why would a routing protocol choose to decide not to use a "bad" link if > there are no other alternatives available? Bad links should be avoided if > there are better available, but if this is the only one available it should > be used anyway? It is not uncommon for wireless links to use some kind of hysteresis on a routing protocol. The problem/feature of D/HNCP is that it is independent of the routing protocol... so it does not know. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
Hello Henning, > Does HNCP somehow make sure that there is a route towards the prefix > it distributes? While D/HNCP checks that there is a path of links, the > routing protocol might decide that one of the links is too > unstable/slow for traffic and does not use it for routing. > > What is the preferred way to deal with this situation? HNCP has the following requirement wrt. (applied) assigned prefixes: [...] each router connected to said [Common] link: MUST forward traffic destined to said prefix to the respective link. which should ensure that once traffic for a prefix reaches any router adjacent to a link where it is assigned, is delivered to the link. Everything else wrt. routing and interactions is more or less declared out of scope for HNCP. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Reachability of distributed prefixes
On Wed, 26 Aug 2015, Henning Rogge wrote: Hi, I am experimenting with SHNCPD at the moment and wonder about a detail in the Homenet prefix distribution to attached hosts. Does HNCP somehow make sure that there is a route towards the prefix it distributes? While D/HNCP checks that there is a path of links, the routing protocol might decide that one of the links is too unstable/slow for traffic and does not use it for routing. What is the preferred way to deal with this situation? Hm, there must be some preconception here that I do not understand. Why would a routing protocol choose to decide not to use a "bad" link if there are no other alternatives available? Bad links should be avoided if there are better available, but if this is the only one available it should be used anyway? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Reachability of distributed prefixes
Hi, I am experimenting with SHNCPD at the moment and wonder about a detail in the Homenet prefix distribution to attached hosts. Does HNCP somehow make sure that there is a route towards the prefix it distributes? While D/HNCP checks that there is a path of links, the routing protocol might decide that one of the links is too unstable/slow for traffic and does not use it for routing. What is the preferred way to deal with this situation? Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
