Subject: Re: New Version Notification for draft-sarikaya-6man-next-hop-ra-01.txt

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 19 May 2014 14:20:50 -0500

Hi Dan, Brian, all,

I revised the draft based on your comments. The details are below.
Please check it and let me know your comments:

A new version of I-D, draft-sarikaya-6man-next-hop-ra-01.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-sarikaya-6man-next-hop-ra
Revision:       01
Title:          IPv6 RA Options for Next Hop Routes
Document date:  2014-05-19
Group:          Individual Submission
Pages:          12
URL:
http://www.ietf.org/internet-drafts/draft-sarikaya-6man-next-hop-ra-01.txt
Status:
https://datatracker.ietf.org/doc/draft-sarikaya-6man-next-hop-ra/
Htmlized:       http://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-sarikaya-6man-next-hop-ra-01

On Sun, Feb 23, 2014 at 9:35 PM, Brian E Carpenter
<[email-masked]> wrote:
> On 15/02/2014 06:35, Dan Lüdtke wrote:
>> Hi,
>>
>> I have very mixed feelings regarding this draft and I have not yet
>> decided whether it is me or the draft :)
>
> It's probably the fact that the community is very divided as to whether
> this, or a DHCPv6 based solution, is the right one for delivering
> routing information to hosts. Personally I see advantages in defining
> enough in RA that a DHCPv6-free network is possible, but it only
> makes sense if we insist that routing information capable of delivery
> by RA and that capable of delivery by DHCPv6 have *exactly* the same
> semantics (even if the syntax of the messages is different).
> ...
>
>> I also have the feeling that consuming 7 numbers from the registry for
>> new options is a bit too greedy. Do you see any way to reduce the
>> consumption of this very limited resource? I think it would help
>> supporting the draft a lot.
>
> Since an address is the same thing as a /128 prefix, I would
> think that the address TLVs could be replaced by prefixes,
> which would save at least a couple of option numbers. If that
> isn't enough, it would have to go to subtypes.
>
>     Brian
>

---

From: Ray Hunter <[email-masked]>
Date: Wed, 21 May 2014 09:34:55 +0200

Behcet Sarikaya wrote:
> http://www.ietf.org/rfcdiff?url2=aft-sarikaya-6man-next-hop-ra-01
>
I have read this draft. Generally I see the need to inform hosts with 
multiple interfaces about SADR routes.

Will the amount of information required in the worst case deployment fit 
in RA?
In a single frame?
If not, are we storing up more problems for the future than it solves 
(packet loss, re-ordering).

I also think the source address option in Section 9 should explicitly be 
defined as a prefix, given many people's requirement to support multiple 
IIDs per interface (for privacy etc.).

How would the metrics in this draft interact with RA prf and more 
specific routes (RFC 4191)?

AFAICS this scheme is only meant for multi-homed hosts.

I further question how to handle mobile devices with multiple interfaces 
that become routers.

Aren't we rapidly approaching the point where running a routing protocol 
(between the infra and a mobile device acting as a stub router) is 
appropriate?

regards,
RayH
-- 
Regards,
RayH

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 22 May 2014 16:10:39 -0500

Hi Ray,

Thanks for your comments. Please find my replies inline below.

Regards,

Behcet

On Wed, May 21, 2014 at 2:34 AM, Ray Hunter <[email-masked]> wrote:
>> Htmlized:
>> http://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-01
>> Diff:
> Will the amount of information required in the worst case deployment fit in
> RA?
> In a single frame?

The longest option is 56 octets. Why should it not fit in RA in a
single Ethernet frame?
Even if all the options in the draft are used in the same RA, it takes
240 octets which is totally unlikely.
So I think we are not storing up more problems for the future.

> IIDs per interface (for privacy etc.).

Sure, then use the source prefix option in Section 10.

>
> How would the metrics in this draft interact with RA prf and more specific
> routes (RFC 4191)?

The metric field is very much like prf in RFC 4191 but it is 8 bits
long and a lot easier to process (see Dan's mail).

> AFAICS this scheme is only meant for multi-homed hosts.

Yes.

> (between the infra and a mobile device acting as a stub router) is

The draft addresses host configuration and router configuration is out of scope.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 May 2014 11:39:58 +1200

> Hi Ray,

<snip>

> So I think we are not storing up more problems for the future.

OK, assuming only one particular Next Hop is handled at a time.
Are you assuming that if N Next Hops are to be announced, they will
be in N separate messages? If not your worst case would be N*240 octets,
wouldn't it?

In the real world it seems unlikely that N will exceed 3 or 4, so it
would still fit in the IPv6 MTU. But all the same, maybe this needs
to be clarified.

> Sure, then use the source prefix option in Section 10.

But why not merge the two? Prefix length 128 signals a single
address, in any case.

>> AFAICS this scheme is only meant for multi-homed hosts.

More precisely, for multi-addressed hosts. It would be applicable
in a number of scenarios, including RFC7157 (section 6.2) and MIF.

> The draft addresses host configuration and router configuration is out of scope.

Right, but this is a grey area. SADR information could very well be
distributed by a routing protocol, or any kind of configuration
protocol, as well as by DHCP or RA. That's why clarity on the semantics
of SADR is needed, so that all methods are functionally equivalent.

In Ray's scenario, if a host decides it wants to be a router, I think
that giving it SADR information is the least of our worries.

     Brian

---

From: Ray Hunter <[email-masked]>
Date: Fri, 23 May 2014 13:03:26 +0200

> Brian E Carpenter <mailto:[email-masked]>
> 23 May 2014 01:39
Exactly.

Does the draft propose to build up the routing table piecemeal in 
consecutive RA messages one destination prefix at a time, or create a 
single (potentially huge) RA message containing the entire routing table 
sourced from this router?

If the message grows >> 1 frame, what's the chances of it being received 
and re-assembled in it's entirety?

How do you time out old prefix entries? How do you time out information 
learned from old neighbors?

These are all real-world problems that are solved in routing protocols.
> would still fit in the IPv6 MTU. But all the same, maybe this needs
IMHO I think any assumption on routing table size is premature. 
http://tools.ietf.org/html/draft-ietf-6man-why64 Section 3.2 states that 
some enterprises run flat IGP routing tables without route aggregation.
> But why not merge the two? Prefix length 128 signals a single
Exactly.
> in a number of scenarios, including RFC7157 (section 6.2) and MIF.
Ack.
>> The draft addresses host configuration and router configuration is out of scope.

I have a 3G mobile phone (not yet IPv6). I have a cable TV operator that 
provides access to 500000 wifi hotspots "for free" (not yet IPv6).
I also want to use my phone as a wireless access point (tethering) 
whilst riding in the train.

These applications are all possible with IPv4 + NAT. But I do not see 
how this draft will make these use cases any more feasible with IPv6.
> of SADR is needed, so that all methods are functionally equivalent.
Agreed. Otherwise we are very quickly going to get quagmired in issues 
like "administrative distance" between competing information for the 
same prefix, depending on how the SADR table is learned.
> that giving it SADR information is the least of our worries.
OK but the problem of distributing SADR routes to mobile devices acting 
as routers is still one that needs to be solved.
And it seems odd to me that a mobile device has to switch to a 
completely different mode just because tethering is enabled.

-- 
Regards,
RayH

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 26 May 2014 17:12:15 -0500

On Fri, May 23, 2014 at 6:03 AM, Ray Hunter <[email-masked]> wrote:
>>>> in
> consecutive RA messages one destination prefix at a time, or create a single
> (potentially huge) RA message containing the entire routing table sourced
> from this router?
>
> If the message grows >> 1 frame, what's the chances of it being received and
> re-assembled in it's entirety?

[behcet] I will add some text in the next revision on RA size issue
considering the above comments  with the following understanding,
please check:

I think that if it fits in one frame the router should create a single
RA message. If it does not then configuring in consecutive RA messages
should be considered, avoiding any re-assembly issues.

>> But why not merge the two? Prefix length 128 signals a single

[behcet] Yes, will do it in the next rev.
> I also want to use my phone as a wireless access point (tethering) whilst
> riding in the train.
>
> These applications are all possible with IPv4 + NAT. But I do not see how
> this draft will make these use cases any more feasible with IPv6.
>
> Agreed. Otherwise we are very quickly going to get quagmired in issues like
> "administrative distance" between competing information for the same prefix,
> depending on how the SADR table is learned.
>
> OK but the problem of distributing SADR routes to mobile devices acting as
> routers is still one that needs to be solved.

[behcet] As RFC 7157 says, RAs as in this draft can be used.
Also routing protocols like RIPng, OSPFv3 can be used.

> And it seems odd to me that a mobile device has to switch to a completely
> different mode just because tethering is enabled.
>

[behcet] I don't understand this. Please clarify.