Subject: Re: New Version Notification for draft-pfister-6man-sadr-ra-00.txt

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 2 Mar 2015 14:40:15 -0600

Pierre,

Please see draft-sarikaya-6man-sadr-ra-00.
 Maybe we should combine these drafts?

Regards,

Behcet

On Fri, Feb 27, 2015 at 6:34 AM, Pierre Pfister <[email-masked]> wrote:
> Hello all,
>
> Following the now 100 mails long thread about how and why hosts may be configured with source address dependent more specific routes, I thought it may be helpful to provide a proposal cleared from elements which, IMHO, would not reach consensus.
>
> In particular, this proposal only defines one single new RA option, inspired from RFC4191 RIO, and *does not* provide any mean to define a route pointing to a different router than the one sending the RA.
>
> Comments are, obviously, welcome/solicited.
>
> Thanks,
>
> - Pierre
>
>
>>
>>
>> A new version of I-D, draft-pfister-6man-sadr-ra-00.txt
>> has been successfully submitted by Pierre Pfister and posted to the
>> IETF repository.
>>
>> Name:         draft-pfister-6man-sadr-ra
>> Revision:     00
>> Title:                Source Address Dependent Route Information Option for Router Advertisements
>> Document date:        2015-02-27
>> Group:                Individual Submission
>> Pages:                8
>> URL:            http://www.ietf.org/internet-drafts/draft-pfister-6man-sadr-ra-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-pfister-6man-sadr-ra/
>> Htmlized:       http://tools.ietf.org/html/draft-pfister-6man-sadr-ra-00
>>
>>
>> Abstract:
>> This document defines the Source Address Dependent Route Information
>> option for Router Advertisements, enabling source address dependent
>> routes to be installed in hosts by neighboring routers.  It also adds
>> a new flag to the existing Route Information option for backward
>> compatibility purposes.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Pierre Pfister <[email-masked]>
Date: Tue, 3 Mar 2015 16:34:22 +0100

Hello Behcet,

With two drafts targeting the same purpose, it looks like we have a real beauty contest here !

We could combine them indeed. But ‘combining’ requires us to identify what should be kept and what should be removed from each document. For that purpose, I think it might be helpful to have some feedback first. Or at least try to comment each other’s proposals.

The following is not a full review, but just a few things that came to my mind while reading your document.

- You say homenet requires the option you define with prefix and source address. I don’t understand what that has to do with homenet.
Actually, I don’t really understand the purpose of the ‘Route Prefix with Source Address option’ at all. You already have the two other options enabling what we want.

- I wonder why we would want 8bits metric in the RA. RFC4191 has only 3 router preference values. Are you thinking about a particular use for it ?

- This part bugs me:
the hosts with 3-4 interfaces or
   links can be easily configured by a single router advertisement
   message carrying the options defined here.

If a host has 4 interfaces. It is likely to be configure by at-least 4 RAs. Unless there is no router on some link.

- We clearly have chosen two different designs. You chose to have 3 different new RA options while I chose to have one new option, and a new flag for backward compatibility with RFC4191. How does your proposal interacts with RFC4191 ? Why do you think it is better to use these 2 RA options instead of the single option I am proposing ?

I would appreciate if you could give a read to my document and tell me the things you dislike about it. I mean, if you don’t dislike anything, there is no point ‘combining’ the two drafts.

Thanks,

- Pierre

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 3 Mar 2015 14:55:50 -0600

Hi Pierre,

> With two drafts targeting the same purpose, it looks like we have a real

No, there are more issues.

>
> We could combine them indeed. But ‘combining’ requires us to identify what
> should be kept and what should be removed from each document. For that
> purpose, I think it might be helpful to have some feedback first. Or at
> least try to comment each other’s proposals.
>
> - You say homenet requires the option you define with prefix and source
> address. I don’t understand what that has to do with homenet.
> Actually, I don’t really understand the purpose of the ‘Route Prefix with
> Source Address option’ at all. You already have the two other options
> enabling what we want.
>
> - I wonder why we would want 8bits metric in the RA. RFC4191 has only 3
> router preference values. Are you thinking about a particular use for it ?
>
> - This part bugs me:
>
> - We clearly have chosen two different designs. You chose to have 3
> different new RA options while I chose to have one new option, and a new
> flag for backward compatibility with RFC4191. How does your proposal
> interacts with RFC4191 ? Why do you think it is better to use these 2 RA
> options instead of the single option I am proposing ?
>

Thanks for these comments.

However, the above text existed in draft-sarikaya-6man-next-hop-ra-04
which was published on December 8 and partly in reply to your comments
on the list. Almost 3 months passed since then.
I had also called for co-authorship. I don't remember receiving any
request from you.

If it is beauty contest, we could have made the solution more
beautiful at least to you as

Beauty is in the eye of the beholder
right?

>
>
> I would appreciate if you could give a read to my document and tell me the
> things you dislike about it. I mean, if you don’t dislike anything, there is
> no point ‘combining’ the two drafts.
>

Well, at this moment, I am soliciting to get the analysis draft
draft-sarikaya-6man-sadr-overview-05 which I published on Feb. 20
accepted as WG draft, rather than working on the solutions.

I presented the drafts twice and we had very good active email
discussions and I believe this is the time for the analysis draft to
go for an adoption call.

 This draft will allow 6man to decide:

a) everything works, no solution work is needed, as in Section 5.1

b) Some solution work is needed, e.g. for SADR which has  wider
application areas, as in Section 5.2

c) More solution work is needed, e.g. next hop which has a narrower
application and SADR as in Section 5.3.

Regards,

Behcet

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 4 Mar 2015 09:26:32 +0100

Hello Behcet,

> I had also called for co-authorship. I don't remember receiving any

I may have missed it. Apologies.

> Beauty is in the eye of the beholder

Indeed. I hope we both get comments from others.

> application and SADR as in Section 5.3.

I had three major concerns about your previous documents.
- Why would we need this next-hop field in any RA option ?
- Why do we need multiple different new options, and not just one ?
- How does that interacts with RFC4191 ?

I raised them at the mike last IETF, and twice on the mailing list.

The purpose of my document is not to override yours. Please feel free to copy-paste any part/ideas you like.
This is just a technical proposal explaining the way I think, IMHO, we should solve this problem.
- No next-hop option.
- One single new option.
- Interoperable with RFC4191.

I am not the only one who had these concerns. And I did not felt like you were willing to address them.
Now, if you actually agree with me on these technical issues. Well, let’s keep going. And let’s discuss technical things instead of politics.

You removed next-hop options. I think it is good.
Please tell me what you think about the other points I raised in my previous mail.

Cheers,

- Pierre