Subject: New Version Notification for draft-sarikaya-6man-sadr-overview-04.txt

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 15 Jan 2015 15:02:53 -0600

Hi all,

Based on latest comments received, we revised the draft as follows.
Please check.

Regards,

Behcet

A new version of I-D, draft-sarikaya-6man-sadr-overview-04.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-sarikaya-6man-sadr-overview
Revision:       04
Title:          Source Address Dependent Routing and Source Address
Selection for IPv6 Hosts
Document date:  2015-01-15
Group:          Individual Submission
Pages:          15
URL:
http://www.ietf.org/internet-drafts/draft-sarikaya-6man-sadr-overview-04.txt
Status:
https://datatracker.ietf.org/doc/draft-sarikaya-6man-sadr-overview/
Htmlized:       http://tools.ietf.org/html/draft-sarikaya-6man-sadr-overview-04
Diff:
http://www.ietf.org/rfcdiff?url2=draft-sarikaya-6man-sadr-overview-04

Abstract:
   This document presents the source address dependent routing from the
   host perspective.  Multihomed hosts and hosts with multiple
   interfaces are considered.  Different architectures are introduced
   and with their help, why source address selection and next hop
   resolution in view of source address dependent routing is needed is
   explained.  The document concludes with an informative guidelines on
   the different solution approaches.

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

---

From: Ole Troan <[email-masked]>
Date: Fri, 16 Jan 2015 10:13:02 +0100

Behcet,

a few comments if I may.

with regards to section 5.1 and rule 5.5 from rfc6724:
you state that rule 5.5. solves the scenarios in figure 1, 2 and 3. I would rather say that a strong ES model would solve those. rule 5.5. solves the scenario in figure 4.

you also reference rfc7078 in section 5.1. 7078 does not have any means to configure rule 5.5 on a host, if that was what you tried to imply (I might have misread you here though).

given that, I still don't understand the need for section 5.2 and a new router advertisement option.

a minor point on section 4.2 and provisioning domains. in any multi-homed network, I think it is a policy choice if the "external" provisioning domains are presented to the host or if the network presents itself as a single provisioning domain. i.e. the network "merges" the information.

in section 5.4 you mention other solutions and probing as a possibility. if we go back to the multi-homing requirements from rfc3582, there are still many gaps with multi-prefix multi-homing. as far as I can see those gaps need to be closed by changes at the transport layer, a new intermediate layer (aka session) or in the application layer. do you intend for this document also to point out these gaps, or do you intend for this to be dealing with the network layer gaps only?

Best regards,
Ole

> On 15 Jan 2015, at 22:02 , Behcet Sarikaya <[email-masked]> wrote:
> 
> Hi all,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 19 Jan 2015 13:59:41 -0600

Hi Ole,

> a few comments if I may.

Sure.

> you state that rule 5.5. solves the scenarios in figure 1, 2 and 3. I would rather say that a strong ES model would solve those. rule 5.5. solves the scenario in figure 4.

This seems to contradict what you said in your mail:
http://www.ietf.org/mail-archive/web/ipv6/current/msg21639.html

to Pierre.

You said
Rule 5.5 and strict (or strong) host model.

Strong end system defined in RFC 1122 and Rule 5.5 are not the same
thing as you have alluded to in your mail above. Strong ES model is
saying that any multihomed host is a set of logical hosts.

As to Fig. 4 or Scenario 4, I have added this scenario based on Pierre
suggestion, it (this home networking scenario) was described in his
mail. Also in your mail referenced above you said that this case makes
sense.

Scenarios 1,2 and 3 are showing multihomed host (Scenario 2) or
multiple interfaced host (scenarios 1 and 3) cases. These are the
scenarios you need SADR at the host.
BTW I noticed that I put multihomed in all three figure captions by
mistake, I will correct it in the next rev. But the text is clear, I
think.

> you also reference rfc7078 in section 5.1. 7078 does not have any means to configure rule 5.5 on a host, if that was what you tried to imply (I might have misread you here though).

Have you read RFC 7078?
Here is what the abstract says:

RFC 6724 defines default address selection mechanisms for IPv6 that
   allow nodes to select an appropriate address when faced with multiple
   source and/or destination addresses to choose between.  RFC 6724
   allows for the future definition of methods to administratively
   configure the address selection policy information.  This document
   defines a new DHCPv6 option for such configuration,

and that's what I am saying in Section 5.1. Is there any issue with this?

> given that, I still don't understand the need for section 5.2 and a new router advertisement option.

Please see the above comments. Section 5.2 is the solution that Pierre
suggested to Scenario 4.

> a minor point on section 4.2 and provisioning domains. in any multi-homed network, I think it is a policy choice if the "external" provisioning domains are presented to the host or if the network p…

I can add a sentence to this effect to Section 4.2, thanks.

> in section 5.4 you mention other solutions and probing as a possibility. if we go back to the multi-homing requirements from rfc3582, there are still many gaps with multi-prefix multi-homing. as fa…

In the draft on
Experience with IPv6 path probing,

two models have been investigated, one is network layer or REAP and
the other is transport layer or MPTCP.

No, I do not intend to elaborate IPv6 probing and solutions in this
document any further than Section 5.4 because the document
concentrates on host based approaches.

Regards,

Behcet