Re: [homenet] Running code in Orlando

[joel jaeggli]

On 2/20/13 7:49 PM, David Lamparter wrote:

On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote:

On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson
wrote:


Would/could another foot of such a network be on the IETF network?


If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be
much use.

Even without DHCPv6 PD on the remainder of the IETF network, it might be
possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating part
of the provider network.
that's a straight forward request to the noc, that said time is getting 
tight so if you want support for your experiment during the meeting I'd 
reach out expeditiously.

___
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] Running code in Orlando

[Michael Richardson]

> "Brzozowski," == Brzozowski, John  
> writes:
Brzozowski> Why emulate it?  Is the intention here to test the the code on 
an
Brzozowski> enterprise or corporate network?

Walled Garden :-)


-- 
Michael Richardson , Sandelman Software Works 




pgpHOLEHSus3O.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Running code in Orlando

[David Lamparter]

On Thu, Feb 21, 2013 at 04:17:06AM +, Brzozowski, John wrote:
> David Lamparter wrote:
> >On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote:
> >> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson
> >> wrote:
> >> 
> >> > Would/could another foot of such a network be on the IETF network?
> >> >
> >> 
> >> If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be
> >> much use.
> >
> >Even without DHCPv6 PD on the remainder of the IETF network, it might be
> >possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating part
> >of the provider network.
> 
> Why emulate it?  Is the intention here to test the the code on an
> enterprise or corporate network?

The scope of the plugfest is the interior and border of the homenet.  To
get the border right, we need the service provider side of that border
in some form.  If the IETF network runs DHCPv6-PD, that is an usable
approximation.

My suggestion was for the case that the IETF network won't be running
DHCPv6-PD.  In that case, the easiest way to make the IETF network
usable as one uplink for the homenet plugfest is to ask for a /52 to be
made available for the plugfest in some static way and then provide
DHCPv6-PD from that, running on some random PC box/laptop somewhere.

Actually - controlling the DHCPv6-PD might be advantageous in order to
allow tinkering with it to see how the testbed reacts.


-David
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Running code in Orlando

[Brzozowski, John]

Why emulate it?  Is the intention here to test the the code on an
enterprise or corporate network?

=
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
e) john_brzozow...@cable.comcast.com
o) 609-377-6594
w) www.comcast6.net
=







-Original Message-
From: David Lamparter 
Date: Wednesday, February 20, 2013 8:49 PM
To: Lorenzo Colitti 
Cc: Michael Richardson , Mark Townsley
, "homenet@ietf.org Group" , Jari
Arkko , John Jason Brzozowski

Subject: Re: [homenet] Running code in Orlando

>On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote:
>> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson
>> wrote:
>> 
>> > Would/could another foot of such a network be on the IETF network?
>> >
>> 
>> If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be
>> much use.
>
>Even without DHCPv6 PD on the remainder of the IETF network, it might be
>possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating part
>of the provider network.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Running code in Orlando

[Brzozowski, John]

Plus what media is being tested, ethernet?

=
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
e) john_brzozow...@cable.comcast.com
o) 609-377-6594
w) www.comcast6.net
=







-Original Message-
From: Lorenzo Colitti 
Date: Wednesday, February 20, 2013 8:40 PM
To: Michael Richardson 
Cc: John Jason Brzozowski , Jari Arkko
, "homenet@ietf.org Group" , Mark
Townsley 
Subject: Re: [homenet] Running code in Orlando

>On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson
> wrote:
>
>Would/could another foot of such a network be on the IETF network?
>
>
>
>
>If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be
>much use.
>
>
>

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Running code in Orlando

[Brzozowski, John]

We were delegating /56s last time.  Definitely doable in Orlando.

John
=
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
e) john_brzozow...@cable.comcast.com
o) 609-377-6594
w) www.comcast6.net
=







-Original Message-
From: Lorenzo Colitti 
Date: Wednesday, February 20, 2013 7:21 PM
To: John Jason Brzozowski , Jari Arkko

Cc: Mark Townsley , "homenet@ietf.org Group"

Subject: Re: [homenet] Running code in Orlando

>+1 for stuff that works in the real world. "Running code" isn't running
>code if it doesn't, well, run. :-)
>
>
>Mark, Jari, is it possible to revive the autoconfig/source-routing demo
>that we had in Atlanta? Even if it's only for a limited time, I think
>it's important to show that (or "whether", depending on your point of
>view) this stuff can work in the
> real world.
>
>
>John: assuming it's possible to revive the demo, then I think it would be
>enough to have two cable modems connected to a live network that hands
>out "something larger than /64" by default. If we don't have PD or if we
>don't have greater than /64
> then there's not much point in attempting routing. :-)
>
>
>Does that sound possible?
>
>
>
>On Thu, Feb 21, 2013 at 5:24 AM, Brzozowski, John
> wrote:
>
>Folks,
>
>I expect to have a DOCSIS network available during IETF86 for Bits-n-Bytes
>if there is interest in having real broadband equipment in the HOMENET lab
>please let me know I will do my best to accommodate.  After we got
>everything up an running I recall that some (or all) of the running code
>that was available during IETF85 had some issue interoperating with a live
>IPv6 enabled broadband network.  The cable broadband network was
>functioning as it does today in production.
>
>I wanted to make sure everyone was aware that the environment would be
>available again in case there was an interest in testing (and/or fixing)
>their implementations.
>
>Regards,
>
>John
>=
>John Jason Brzozowski
>Comcast Cable
>m) +1-609-377-6594 
>e) mailto:john_brzozow...@cable.comcast.com
>o) +1-484-962-0060 
>w) http://www.comcast6.net
>=
>
>
>
>
>
>-Original Message-
>From: Mark Townsley 
>Date: Monday, January 21, 2013 12:25 PM
>To: "homenet@ietf.org Group" 
>Subject: [homenet] Running code in Orlando
>
>>
>>Group,
>>
>>Happy new year everyone. The next IETF will be upon us soon.
>>
>>Last IETF, we had two implementations based on
>>draft-arkko-homenet-prefix-assignment and
>>draft-ietf-ospf-ospfv3-autoconfig running about. Bugs in code as well as
>>bugs in specs were found. We had a number of people bringing along their
>>hosts and plugging them into the various router ports, and people
>>randomly changing the wiring to see if would keep working. Ironically,
>>uplinks to the outside world gave us some of the biggest headaches, and
>>with better planning we should be able to alleviate those problems if we
>>do this again. In any case, it was overall a positive experience, and
>>we're considering now whether or not to try and do it again.
>>
>>If you have an implementation of a protocol within the scope of the
>>homenet charter and homenet architecture (draft-ietf-homenet-arch-06)
>>based on an internet draft targeted to the homenet working group that you
>>would like to test with others, please send the list or chairs an email
>>so we can evaluate whether or not to schedule a place for you to get
>>together and work with others in person in Orlando. Note that this isn't
>>for "showcasing", but for working... so be expected to configure,
>>reconfigure, and change code on the fly accordingly.
>>
>>Please let us know ASAP, as March is coming soon!
>>
>>Thanks,
>>
>>- Mark & Ray
>>
>>
>>
>>
>>
>>___
>>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
>
>
>
>
>

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Running code in Orlando

[David Lamparter]

On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote:
> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson
> wrote:
> 
> > Would/could another foot of such a network be on the IETF network?
> >
> 
> If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be
> much use.

Even without DHCPv6 PD on the remainder of the IETF network, it might be
possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating part
of the provider network.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Running code in Orlando

[Lorenzo Colitti]

On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson
wrote:

> Would/could another foot of such a network be on the IETF network?
>

If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be
much use.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Running code in Orlando

[Michael Richardson]

> "Lorenzo" == Lorenzo Colitti  writes:
Lorenzo> +1 for stuff that works in the real world. "Running code" isn't 
running
Lorenzo> code if it doesn't, well, run. :-)

Lorenzo> Mark, Jari, is it possible to revive the autoconfig/source-routing 
demo
Lorenzo> that we had in Atlanta? Even if it's only for a limited time, I 
think it's
Lorenzo> important to show that (or "whether", depending on your point of 
view) this
Lorenzo> stuff can work in the real world.

Lorenzo> John: assuming it's possible to revive the demo, then I think it 
would be
Lorenzo> enough to have two cable modems connected to a live network that 
hands out
Lorenzo> "something larger than /64" by default. If we don't have PD or if 
we don't
Lorenzo> have greater than /64 then there's not much point in
Lorenzo> attempting routing. :-)

Would/could another foot of such a network be on the IETF network?

-- 
Michael Richardson , Sandelman Software Works 




pgpGxHpAuul1_.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Running code in Orlando

[Lorenzo Colitti]

+1 for stuff that works in the real world. "Running code" isn't running
code if it doesn't, well, run. :-)

Mark, Jari, is it possible to revive the autoconfig/source-routing demo
that we had in Atlanta? Even if it's only for a limited time, I think it's
important to show that (or "whether", depending on your point of view) this
stuff can work in the real world.

John: assuming it's possible to revive the demo, then I think it would be
enough to have two cable modems connected to a live network that hands out
"something larger than /64" by default. If we don't have PD or if we don't
have greater than /64 then there's not much point in attempting routing. :-)

Does that sound possible?


On Thu, Feb 21, 2013 at 5:24 AM, Brzozowski, John <
john_brzozow...@cable.comcast.com> wrote:

> Folks,
>
> I expect to have a DOCSIS network available during IETF86 for Bits-n-Bytes
> if there is interest in having real broadband equipment in the HOMENET lab
> please let me know I will do my best to accommodate.  After we got
> everything up an running I recall that some (or all) of the running code
> that was available during IETF85 had some issue interoperating with a live
> IPv6 enabled broadband network.  The cable broadband network was
> functioning as it does today in production.
>
> I wanted to make sure everyone was aware that the environment would be
> available again in case there was an interest in testing (and/or fixing)
> their implementations.
>
> Regards,
>
> John
> =
> John Jason Brzozowski
> Comcast Cable
> m) +1-609-377-6594
> e) mailto:john_brzozow...@cable.comcast.com
> o) +1-484-962-0060
> w) http://www.comcast6.net
> =
>
>
>
>
>
> -Original Message-
> From: Mark Townsley 
> Date: Monday, January 21, 2013 12:25 PM
> To: "homenet@ietf.org Group" 
> Subject: [homenet] Running code in Orlando
>
> >
> >Group,
> >
> >Happy new year everyone. The next IETF will be upon us soon.
> >
> >Last IETF, we had two implementations based on
> >draft-arkko-homenet-prefix-assignment and
> >draft-ietf-ospf-ospfv3-autoconfig running about. Bugs in code as well as
> >bugs in specs were found. We had a number of people bringing along their
> >hosts and plugging them into the various router ports, and people
> >randomly changing the wiring to see if would keep working. Ironically,
> >uplinks to the outside world gave us some of the biggest headaches, and
> >with better planning we should be able to alleviate those problems if we
> >do this again. In any case, it was overall a positive experience, and
> >we're considering now whether or not to try and do it again.
> >
> >If you have an implementation of a protocol within the scope of the
> >homenet charter and homenet architecture (draft-ietf-homenet-arch-06)
> >based on an internet draft targeted to the homenet working group that you
> >would like to test with others, please send the list or chairs an email
> >so we can evaluate whether or not to schedule a place for you to get
> >together and work with others in person in Orlando. Note that this isn't
> >for "showcasing", but for working... so be expected to configure,
> >reconfigure, and change code on the fly accordingly.
> >
> >Please let us know ASAP, as March is coming soon!
> >
> >Thanks,
> >
> >- Mark & Ray
> >
> >
> >
> >
> >
> >___
> >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
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Ray Hunter]

> Ole Troan 
> 20 February 2013 14:58
> Ray,
>
> thinking out loud.
>
> the border router includes in the advertisement of the aggregate prefix:
> - it's own global IPv6 address
> - list of external routes
>
> each internal router:
> - installs (S,D) routes for all of the external routes with the
> border's global as next-hop.
>
> normal unicast routing is used to get to the border.
>
> yep, that should work too. and be completely independent of routing
> protocol.
Agreed.
> but at the cost of being dependent on the prefix assignment mechanism.
True. Which anyway has still to be solved for Homenet.
> leaving the question open I suppose, does SADR have a wider
> applicability outside of the home network...
>
Almost certainly, if you believe in stateful firewalls, and multiple
alternate paths, but do not want to deploy either NAT66 or rfc6296
Network Prefix Translation (to guarantee a symmetric return path).

You could consider an approach like the CIDR RFC, split into 3 topics:
1) Semantics of making a forwarding decision given a SADR table
2) Considerations for (routing) protocols that maintain the SADR table
3) Homenet specific solution (potentially tied to prefix autoconfiguration)
> cheers,
> Ole
> Ray Hunter 
> 20 February 2013 11:06
>> Ole Troan 
>> 20 February 2013 09:59
>> Ray,
>>
>>> I have read this draft and find it useful.
>>>
 A routing entry may have both  (S, D) paths and (*, D) paths.  The
>>> longest match wins
>>>
>>> Section 5 seems to suggest SADR is just a tie breaker applied to the
>>> subset of equal length D routes, but I think you probably should be more
>>> specific on the phrase "longest match" in this sentence, as there are 2
>>> length comparisons (one on D and one on S)
>> yes, right now we say:
>>
>>"First a longest match lookup is done in the routing table for the
>>destination address, then for the resulting set a longest matching
>>lookup is done for the source address."
>>
>> what if we also included some RIB entry examples?
>> e.g.
>>
>> ::/0 (route)
>>   2001:db8::/56 -> NH1 (path #1)
>>   2001:db9::/56 -> NH2 (path #2)
>>   -> NH#3 (path #3)
>>
>> would that make it clearer?
> Yes I think so. It's just a readability thing.
>
> Suggest including various combinations e.g. (*,::/0) 
> (2001:db8:1::/56,::/0)  (*,2001:db8:2::/56) &
> (2001:db8:1::/56,2001:db8:2::/56)
>>> Section 6.2.
>>>
>>> During autoconfig, if the prefix is delegated to other Homenet routers
>>> on a hop by hop basis, the Homenet router receiving a new prefix could
>>> indeed install a default SADR route for (parent_prefix/x,0:/0) -> the
>>> upstream delegating router. So in this case your requirement 2 to
>>> strongly couple autoconfiguration  and routing would not seem onerous.
>> right, in that case the parent prefix wouldn't really be the aggregate 
>> prefix though, and not
>> identify the border exit. in a strict routed hierarchy then I guess you 
>> wouldn't need SADR.
> I don't see why it would not include this info. AFAIK we haven't yet
> settled on a prefix delegation mechanism, so the mechanism could carry
> both the aggregate prefix as well as the parent prefix at this point in
> the hierarchy, and even the border exit id/address. But then we're
> pretty much getting into a combined routing protocol and delegation
> mechanism exactly as you already indicated.
>>> But alternatively, if the delegation of prefixes within Homenet occurs
>>> via a mechanism like DHCP PD, the receiving router could instead install
>>> a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD source
>>> address, and then recurse the standard unicast routing table to find the
>>> appropriate next hop toward the Homenet BR. This is a trick that works
>>> very well in BGP networks (with next BGP hop being a software/loopback
>>> interface of the AS egress router that is always up and stable, combined
>>> with an IGP containing just the loopback addresses of the BGP speaking
>>> AS egress routers)
>> yes, now we tie the aggregate prefix and the advertising border router using 
>> the router-id.
>> if the border router had a global address, that was included in the 
>> aggregate route advertisement
>> as well as the external route advertisements, we could use that instead.
> Right. Why wouldn't a border router have a global address if it is
> connected to the Internet?
> Am I missing something?
>> it would certainly make the routing tables more clearer and more explicit.
> And possibly converge faster too on local topology changes.
>>> In which case there's no requirement for a hard link between the routing
>>> protocol and the prefix autoconfiguration mechanism, and thus no
>>> requirement to update the IGP to carry SADR routes, which I think is
>>> potentially a big win.
>> that would be a big win, but I don't quite see how you avoid the hard link?
> Thinking about this some more, it's specifically the requirement 

Re: [homenet] Running code in Orlando

[Brzozowski, John]

Folks,

I expect to have a DOCSIS network available during IETF86 for Bits-n-Bytes
if there is interest in having real broadband equipment in the HOMENET lab
please let me know I will do my best to accommodate.  After we got
everything up an running I recall that some (or all) of the running code
that was available during IETF85 had some issue interoperating with a live
IPv6 enabled broadband network.  The cable broadband network was
functioning as it does today in production.

I wanted to make sure everyone was aware that the environment would be
available again in case there was an interest in testing (and/or fixing)
their implementations.

Regards,

John
=
John Jason Brzozowski
Comcast Cable
m) +1-609-377-6594
e) mailto:john_brzozow...@cable.comcast.com
o) +1-484-962-0060
w) http://www.comcast6.net
=





-Original Message-
From: Mark Townsley 
Date: Monday, January 21, 2013 12:25 PM
To: "homenet@ietf.org Group" 
Subject: [homenet] Running code in Orlando

>
>Group,
>
>Happy new year everyone. The next IETF will be upon us soon.
>
>Last IETF, we had two implementations based on
>draft-arkko-homenet-prefix-assignment and
>draft-ietf-ospf-ospfv3-autoconfig running about. Bugs in code as well as
>bugs in specs were found. We had a number of people bringing along their
>hosts and plugging them into the various router ports, and people
>randomly changing the wiring to see if would keep working. Ironically,
>uplinks to the outside world gave us some of the biggest headaches, and
>with better planning we should be able to alleviate those problems if we
>do this again. In any case, it was overall a positive experience, and
>we're considering now whether or not to try and do it again.
>
>If you have an implementation of a protocol within the scope of the
>homenet charter and homenet architecture (draft-ietf-homenet-arch-06)
>based on an internet draft targeted to the homenet working group that you
>would like to test with others, please send the list or chairs an email
>so we can evaluate whether or not to schedule a place for you to get
>together and work with others in person in Orlando. Note that this isn't
>for "showcasing", but for working... so be expected to configure,
>reconfigure, and change code on the fly accordingly.
>
>Please let us know ASAP, as March is coming soon!
>
>Thanks,
>
>- Mark & Ray 
>
>
>
>
>
>___
>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

[homenet] FW: New Version Notification for draft-grundemann-homenet-hipnet-00.txt

[Chris Grundemann]

Dear Homenet,

CableLabs, in cooperation with our members and vendor companies, is
enhancing our eRouter specification to support multirouter home networks.
As we have in the past, we are presenting our eRouter updates to the IETF
in the spirit of sharing.  We believe that these enhancements meet the
principles of the homenet-arch document, while not relying on new protocol
development.

In addition, we are prototyping these enhancements, and are planning to
demonstrate them in Orlando.

Cheers,
~Chris



On 2/16/13 8:27 AM, "internet-dra...@ietf.org" 
wrote:

>
>A new version of I-D, draft-grundemann-homenet-hipnet-00.txt
>has been successfully submitted by Chris Donley and posted to the
>IETF repository.
>
>Filename:   draft-grundemann-homenet-hipnet
>Revision:   00
>Title:  A Near Term Solution for Home IP Networking (HIPnet)
>Creation date:  2013-02-15
>Group:  Individual Submission
>Number of pages: 22
>URL: 
>http://www.ietf.org/internet-drafts/draft-grundemann-homenet-hipnet-00.txt
>Status:  
>http://datatracker.ietf.org/doc/draft-grundemann-homenet-hipnet
>Htmlized:
>http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-00
>
>
>Abstract:
>   Home networks are becoming more complex.  With the launch of new
>   services such as home security, IP video, Smart Grid, etc., many
>   Service Providers are placing additional IPv4/IPv6 routers on the
>   subscriber network.  This document describes a self-configuring home
>   router that is capable of operating in such an environment, and that
>   requires no user interaction to configure it.  Compliant with
>   draft-ietf-homenet-arch, it uses existing protocols in new ways
>   without the need for a routing protocol.
>
>
>  
>
>
>
>The IETF Secretariat
>

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Mattia Rossi]

Am 20.02.2013 11:06, schrieb Ray Hunter:



given that border routers may or may not advertise a default route, and may 
also advertise
more specifics...

True. My assumption is that the 99% use case will be a simple default
route to "the Internet." That could be incorrect.

What's the use case behind more specific routes (in the walled garden)?

What would be so bad in the case of a walled garden if we always
installed a default SADR route associated with the prefix learned
specifically from the walled garden i.e.
(walled_garden_derived_prefix/56,::/0) -> NH_walled_garden_homenet_BR?
True, generally it seems to me, that more specific routes are only 
needed in the case the Source Prefix in SADR is *.

Otherwise the route is constrained by the source address anyway.
The walled garden route is needed though, if the table looks like this:

(*, ::/0) -> ISP_A  # Default route to ISP A
(*, ::/0) -> ISP_B  # Default route to ISP B
(*, 2001:db8::/64) -> R1# Internal network, prefix from A
(*, 2001:db8:1::/64) -> R2  # Internal network, prefix from A
(*, 2001:db9::/64) -> R1# Internal network, prefix from B
(*, 2001:db9:1::/64) -> R2  # Internal network, prefix from B
(*, fd00::/64) -> R3# Internal network ULA
(2001:db9::/56, 2001:420::/32) -> ISP_B # Walled garden route from ISP B

Maybe that should be listed as an example as well. And maybe a line 
about how to  behave if there's a tie with the multiple default route 
constellation:


(*, ::/0) -> ISP_A  # Default route to ISP A
(*, ::/0) -> ISP_B  # Default route to ISP B

If we don't propose a solution , we should add a line which says that 
it's up to the implementation or load balancing mechanism or whatever to 
solve that, like:


   A router forwarding a packet does a longest match look-up on the
   destination address.  If this is a (*, D) entry, it forwards the
   packet out the best next-hop as before (doing equal cost multi path
   load balancing etc). This applies also to multiple (*, ::/0) entries.



We've anyway still got to sort out correct source address selection even
once we've got the basic packet routing in place. Source address
selection   could be the point where the real "routing" decision is
made, whilst SADR would be used to select the correct Homenet BR and to
avoid the ingress filters once the correct source address has been decided.



The hosts could perform NAT upon receipt of the ICMP code 5. Of course, 
if you have a low power device then you might have a problem... just a 
thought.


I like the draft and find it very useful.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Lorenzo Colitti]

On Wed, Feb 20, 2013 at 10:58 PM, Ole Troan  wrote:

> thinking out loud.
>
> the border router includes in the advertisement of the aggregate prefix:
>  - it's own global IPv6 address
>  - list of external routes
>
> each internal router:
>  - installs (S,D) routes for all of the external routes with the border's
> global as next-hop.
>
> normal unicast routing is used to get to the border.
>

This is what is done in network backbones with next-hop-self. That requires
that you can do recursive loopbacks and that the border router's IP address
is stable - i.e., if it's a loopback address.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Ole Troan]

Ray,

thinking out loud.

the border router includes in the advertisement of the aggregate prefix:
 - it's own global IPv6 address
 - list of external routes

each internal router:
 - installs (S,D) routes for all of the external routes with the border's 
global as next-hop.

normal unicast routing is used to get to the border.

yep, that should work too. and be completely independent of routing protocol. 
but at the cost of being dependent on the prefix assignment mechanism. leaving 
the question open I suppose, does SADR have a wider applicability outside of 
the home network...

cheers,
Ole
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Ray Hunter]

> Ole Troan 
> 20 February 2013 09:59
> Ray,
>
>> I have read this draft and find it useful.
>>
>>> A routing entry may have both  (S, D) paths and (*, D) paths.  The
>> longest match wins
>>
>> Section 5 seems to suggest SADR is just a tie breaker applied to the
>> subset of equal length D routes, but I think you probably should be more
>> specific on the phrase "longest match" in this sentence, as there are 2
>> length comparisons (one on D and one on S)
>
> yes, right now we say:
>
>"First a longest match lookup is done in the routing table for the
>destination address, then for the resulting set a longest matching
>lookup is done for the source address."
>
> what if we also included some RIB entry examples?
> e.g.
>
> ::/0 (route)
>   2001:db8::/56 -> NH1 (path #1)
>   2001:db9::/56 -> NH2 (path #2)
>   -> NH#3 (path #3)
>
> would that make it clearer?
Yes I think so. It's just a readability thing.

Suggest including various combinations e.g. (*,::/0) 
(2001:db8:1::/56,::/0)  (*,2001:db8:2::/56) &
(2001:db8:1::/56,2001:db8:2::/56)
>> Section 6.2.
>>
>> During autoconfig, if the prefix is delegated to other Homenet routers
>> on a hop by hop basis, the Homenet router receiving a new prefix could
>> indeed install a default SADR route for (parent_prefix/x,0:/0) -> the
>> upstream delegating router. So in this case your requirement 2 to
>> strongly couple autoconfiguration  and routing would not seem onerous.
>
> right, in that case the parent prefix wouldn't really be the aggregate prefix 
> though, and not
> identify the border exit. in a strict routed hierarchy then I guess you 
> wouldn't need SADR.
I don't see why it would not include this info. AFAIK we haven't yet
settled on a prefix delegation mechanism, so the mechanism could carry
both the aggregate prefix as well as the parent prefix at this point in
the hierarchy, and even the border exit id/address. But then we're
pretty much getting into a combined routing protocol and delegation
mechanism exactly as you already indicated.
>> But alternatively, if the delegation of prefixes within Homenet occurs
>> via a mechanism like DHCP PD, the receiving router could instead install
>> a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD source
>> address, and then recurse the standard unicast routing table to find the
>> appropriate next hop toward the Homenet BR. This is a trick that works
>> very well in BGP networks (with next BGP hop being a software/loopback
>> interface of the AS egress router that is always up and stable, combined
>> with an IGP containing just the loopback addresses of the BGP speaking
>> AS egress routers)
>
> yes, now we tie the aggregate prefix and the advertising border router using 
> the router-id.
> if the border router had a global address, that was included in the aggregate 
> route advertisement
> as well as the external route advertisements, we could use that instead.
Right. Why wouldn't a border router have a global address if it is
connected to the Internet?
Am I missing something?
> it would certainly make the routing tables more clearer and more explicit.
And possibly converge faster too on local topology changes.
>> In which case there's no requirement for a hard link between the routing
>> protocol and the prefix autoconfiguration mechanism, and thus no
>> requirement to update the IGP to carry SADR routes, which I think is
>> potentially a big win.
>
> that would be a big win, but I don't quite see how you avoid the hard link?
Thinking about this some more, it's specifically the requirement to
select and modify a single IGP that is bothering me. That seems to make
a big assumption about the autoconfiguration mechanism that we have yet
to choose.

Although that in the end modified OSPFv3 might be the best overall
solution, it would seem to me easier and more correct to say that the
prefix autoconfiguration mechanism should distribute the SADR
information, as the Homenet BR anyway has to initiate the prefix
delegation and provide the necessary Homenet BR egress information.

The SADR specific information would to my mind be more tightly coupled
to changes in prefix delegation from the upstream provider, or
availability of the upstream provider link, and not directly with any
local routing protocol or topology change. We're not planning on running
OSPF to providers' PE routers...
> given that border routers may or may not advertise a default route, and may 
> also advertise
> more specifics... 
True. My assumption is that the 99% use case will be a simple default
route to "the Internet." That could be incorrect.

What's the use case behind more specific routes (in the walled garden)?

What would be so bad in the case of a walled garden if we always
installed a default SADR route associated with the prefix learned
specifically from the walled garden i.e.
(walled_garden_derived_prefix/56,::/0) -> NH_walled_garden_homenet_BR?

We've anyway still got to sort out co

Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Ole Troan]

Ray,

> I have read this draft and find it useful.
> 
>> A routing entry may have both  (S, D) paths and (*, D) paths.  The
> longest match wins
> 
> Section 5 seems to suggest SADR is just a tie breaker applied to the
> subset of equal length D routes, but I think you probably should be more
> specific on the phrase "longest match" in this sentence, as there are 2
> length comparisons (one on D and one on S)

yes, right now we say:

   "First a longest match lookup is done in the routing table for the
   destination address, then for the resulting set a longest matching
   lookup is done for the source address."

what if we also included some RIB entry examples?
e.g.

::/0 (route)
  2001:db8::/56 -> NH1 (path #1)
  2001:db9::/56 -> NH2 (path #2)
  -> NH#3 (path #3)

would that make it clearer?

> Section 6.2.
> 
> During autoconfig, if the prefix is delegated to other Homenet routers
> on a hop by hop basis, the Homenet router receiving a new prefix could
> indeed install a default SADR route for (parent_prefix/x,0:/0) -> the
> upstream delegating router. So in this case your requirement 2 to
> strongly couple autoconfiguration  and routing would not seem onerous.

right, in that case the parent prefix wouldn't really be the aggregate prefix 
though, and not
identify the border exit. in a strict routed hierarchy then I guess you 
wouldn't need SADR.

> But alternatively, if the delegation of prefixes within Homenet occurs
> via a mechanism like DHCP PD, the receiving router could instead install
> a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD source
> address, and then recurse the standard unicast routing table to find the
> appropriate next hop toward the Homenet BR. This is a trick that works
> very well in BGP networks (with next BGP hop being a software/loopback
> interface of the AS egress router that is always up and stable, combined
> with an IGP containing just the loopback addresses of the BGP speaking
> AS egress routers)

yes, now we tie the aggregate prefix and the advertising border router using 
the router-id.
if the border router had a global address, that was included in the aggregate 
route advertisement
as well as the external route advertisements, we could use that instead.

it would certainly make the routing tables more clearer and more explicit.

> In which case there's no requirement for a hard link between the routing
> protocol and the prefix autoconfiguration mechanism, and thus no
> requirement to update the IGP to carry SADR routes, which I think is
> potentially a big win.

that would be a big win, but I don't quite see how you avoid the hard link?
given that border routers may or may not advertise a default route, and may 
also advertise
more specifics... 

cheers,
Ole
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet