Subject: Use longest-matching prefix to the next hop

From: FUJIKAWA Kenji <[email-masked]>
Date: Tue, 26 Feb 2008 11:30:52 +0900

Hi all, 

I am submitting an ID,
  http://www.ietf.org/proceedings/staging/draft-fujikawa-ipv6-src-addr-selection-02.txt
and suggesting in the draft that,

   Before Rule 8 (Use longest matching prefix) in section 5.  (Source
   Address Selection) in RFC3484, the rule using longest-matching prefix
   to the next hop is to be added.

The following is an example, 
where the Rule 8 selects the roundabout path via ISP3,
while the method of using longest-matching prefix to the next hop 
selects the shortest and best path,
when EN sends a packet to CN.

# In the previous IETF meeting I only showed a single router case.
# but this method is adaptable and useful to the multiple router case.

I would like to ask if 6man people is interested in this topic, and
this can become working group item.

                         +---+
                         |CN |
                         +-+-+
                           | 2001:db8:2001::CN
                           |
                       +---+---+2001:db8:2000:/36
                       |       |
             +---------+ ISP2  |
             |         |       |
             |         +-------+
             |
         +---+---+2001:db8:1000:/36  +-------+2001:db8:3000::/36
         |       |                   |       |
         | ISP1  +-------------------+ ISP3  |
         |       |                   |       |
         +---+---+                   +---+---+
             |                           |
             |                           |
             +----------+       +--------+
        2001:db8:1000:R1|       |2001:db8:3000:R3
                      +-+-+   +-+-+
    2001:db8:1001::/48|R1 |   |R3 |2001:db8:3001::/48
                      +-+-+   +-+-+
      2001:db8:1001:1:R1|       |2001:db8:3001:1:R3
                        |       |
                      --+---+---+--
         2001:db8:1001:1:EN | 2001:db8:3001:1:EN
                          +-+-+
                          |EN |
                          +---+

     Routing Tables:
       R1:
       Destination         Next Hop
       2001:db8:1000::/36  address_of_ISP1's_router
       2001:db8:2000::/36  address_of_ISP1's_router
       R3:
       2001:db8:3000::/36  address_of_ISP3's_router
       EN:
       Destination         Next Hop
       2001:db8:1000::/36  2001:db8:1001:1:R1
       2001:db8:2000::/36  2001:db8:1001:1:R1
       2001:db8:3000::/36  2001:db8:3001:1:R3

Any questions and comments are welcome.

Regards,
------------------------------------------------------------------
FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory
5F Pias Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan
Mail:  [email-masked], [email-masked]
WWW:   http://www23.atwiki.jp/hudikaha/
Skype: fujikawakenji
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 27 Feb 2008 16:01:27 -0500

The draft should not be considered for 6man as a WG item just yet
because it needs some more work before the draft is even acceptable to
review. Here is some things to look at after I read portions of the
draft at the URL below.

1. Section 1 of the draft says 2001:db8:3001:1:EN is selected as the
source address of a packet directed from CN to EN. Huh? CN has only an
address of 2001:db8:2001::CN, so how can a src of  2001:db8:3001:1:EN be
picked? 

2. Section 1 says:

[Here, in the above IPv6 address notation, CN, R1, R2, and EN indicates
64bit Interface ID's.]

There is no router R2 in the picture of Fig. 1.

How can one review this document with such basic mistakes/typos in the
picture?

3. In section 3 you say:

[Before Rule 8 (Use longest matching prefix) in section 5.  (Source
 Address Selection) in RFC3484, the rule using longest-matching prefix
 to the next hop is to be added.]

Did I get is right that you are changing src-addr based on next hop?
Basic IP data forwarding and routing ships packets between consecutive
hops using L2 addresses. For packet flow from src to dest with multiple
hops in between, the L3 src and dest addresses do not change! Src and
dest L3 addresses can only be changed by some proxy node in the path. I
hope you are not suggesting changing L3 src-addr from hop to hop!

I suggest you forget about the solution. First define your src-addr
selection problem and let the mailer first agree you have a problem.
Then we'll see what is the solution. You have a lot of sections in the
draft with problems/issues, viz.,

1. A Problem of at Source Address Selection Rule 8. in RFC3484
2.1 Management Issue
2.2 Implementation Issue

It confuses the reader as to what is the one single problem you are
trying to solve. Or if you are solving multiple problems, list them at
the beginning of the draft. Sorry, if I have missed such problem
definitions in the mailer earlier than one year from now.

I suggest the same to the authors of
draft-ietf-6man-addr-select-sol-00.txt. Could you please first describe
what is the problem with SAS as specified in RFC 3484. 

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
FUJIKAWA Kenji
Sent: Monday, February 25, 2008 9:31 PM
To: [email-masked]
Subject: Use longest-matching prefix to the next hop

Hi all, 

I am submitting an ID,
 
http://www.ietf.org/proceedings/staging/draft-fujikawa-ipv6-src-addr-sel
ection-02.txt
and suggesting in the draft that,

The following is an example,
where the Rule 8 selects the roundabout path via ISP3, while the method
of using longest-matching prefix to the next hop selects the shortest
and best path, when EN sends a packet to CN.

I would like to ask if 6man people is interested in this topic, and this
can become working group item.

                         +---+
                         |CN |
                         +-+-+
                           | 2001:db8:2001::CN
                           |

     Routing Tables:
       R1:
       Destination         Next Hop

Regards,
------------------------------------------------------------------
FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias
Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan
Mail:  [email-masked], [email-masked]
WWW:   http://www23.atwiki.jp/hudikaha/
Skype: fujikawakenji
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: FUJIKAWA Kenji <[email-masked]>
Date: Thu, 28 Feb 2008 13:33:58 +0900

Hemant Singh;

Thank you for your comments.

At Wed, 27 Feb 2008 16:01:27 -0500,
> address of 2001:db8:2001::CN, so how can a src of  2001:db8:3001:1:EN be

Because 2001:db8:3001:1:EN longer-matches to 2001:db8:2001::CN
than 2001:db8:1001:1:EN. 

# Note that 1 = 01, 2 = 10, and 3 = 11 in binary form.

> There is no router R2 in the picture of Fig. 1.

This is typo.

> hope you are not suggesting changing L3 src-addr from hop to hop!

No, I am not suggesting changing L3 src-addr from hop to hop.

> definitions in the mailer earlier than one year from now.

I see. Thank you for your advice.
2.1 and 2.2 should be "Management Approach" and "Implementation Approach"
or something.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 28 Feb 2008 12:57:45 -0500

Sorry, you missed my point about your -02 draft with another typo where
the text says [is selected as the source address of a packet directed
from CN to EN] - this is text towards the end of section 1. The text
should say [packet directed from EN to CN] or I don't understand what
are you trying in this SAS example.

Further RFC 3484 considers a multi-homed example in section 10.5 and
clearly says 

[This predicament demonstrates the limitations of the
longest-matching-prefix heuristic in multi-homed situations.]

There are more than one set of means to figure out an optimized routing
for multi-homed sites. I think the WG should decide if we want to
propose a formal solution to the multi-homed scenario.

Thanks. 

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
FUJIKAWA Kenji
Sent: Wednesday, February 27, 2008 11:34 PM
To: [email-masked]
Subject: Re: Use longest-matching prefix to the next hop

Hemant Singh;

> address of 2001:db8:2001::CN, so how can a src of  2001:db8:3001:1:EN 
> be picked?
> 

Because 2001:db8:3001:1:EN longer-matches to 2001:db8:2001::CN than
2001:db8:1001:1:EN. 

> 2. Section 1 says:
> 
> [Here, in the above IPv6 address notation, CN, R1, R2, and EN 
> indicates 64bit Interface ID's.]
> 

This is typo.

> hops using L2 addresses. For packet flow from src to dest with 
> multiple hops in between, the L3 src and dest addresses do not change!

> Src and dest L3 addresses can only be changed by some proxy node in 
> the path. I hope you are not suggesting changing L3 src-addr from hop
to hop!

I see. Thank you for your advice.
2.1 and 2.2 should be "Management Approach" and "Implementation
Approach"
or something.

> draft-ietf-6man-addr-select-sol-00.txt. Could you please first 
> describe what is the problem with SAS as specified in RFC 3484.
> 
> Hemant
>  

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of FUJIKAWA Kenji
> where the Rule 8 selects the roundabout path via ISP3, while the 
> method of using longest-matching prefix to the next hop selects the 
> shortest and best path, when EN sends a packet to CN.
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 28 Feb 2008 14:14:11 -0500

Fujikawa san,

I leave it to the WG to decide what to do with this draft. What you are
suggesting for a solution is already mentioned in RFC 3484. So I don't
know understand why we need your draft? Maybe it can be an Information
draft. I don't see a category of Standards Track or Informational in
your draft. 

What you are suggesting for solution is already motioned in RFC 3484.
Here is that information.

Section 5, Rule 8 says 

[Rule 8 may be superseded if the implementation has other means of
 choosing among source addresses.  For example, if the implementation
 somehow knows which source address will result in the "best"
 communications performance.]

"best" communication performance can mean best routing path. 

Further section 7 of the same RFC explains how does SAS interface with
routing. Snipped below is a text that says 

[Implementations may also use the choice of router to influence the
 choice of source address.  For example, suppose a host is on a link
 with two routers.  One router is advertising a global prefix A and
 the other router is advertising global prefix B. Then when sending via
the first router, the host may prefer source addresses with
 prefix A and when sending via the second router, prefer source
 addresses with prefix B.]

The text above is your solution described in section 2.2 of your draft.
You look up the routing entry for the destination first (like how
section 7 of RFC 3484 also says), and then on seeing that the routing
entry shows path thru router R1 (in your example), then EN will use the
2001:db8:1001:1:EN for src-addr (this is what the sentence in section 7
of RFC 3484 also says). 

Is your solution any different from what is already described in RFC
3284? What am I missing?

Thanks.

Hemant

-----Original Message-----

Hemant Singh;

This is typo.

to hop!

---

From: FUJIKAWA Kenji <[email-masked]>
Date: Fri, 29 Feb 2008 10:31:18 +0900

Hi Hemant Singh,

At Thu, 28 Feb 2008 12:57:45 -0500,
> are you trying in this SAS example.

It's my mistake as you indicated. Sorry.

At Thu, 28 Feb 2008 14:14:11 -0500,
Hemant Singh (shemant) wrote:
> draft. 
> I don't see a category of Standards Track or Informational in
> your draft. 
> 

Yes, my draft is one of means of choosing the best source address.

As a standard track, adding my method before Rule 8. is RFC3484 is the best, 
I think, but being published as an Informational is also further useful
for source address selection in multihomed sites.
This is what I would like to ask to 6man people.

> Is your solution any different from what is already described in RFC

First, my draft clarifies one implementationable algorithm of 
the method in RFC3484 you mentioned.
Then, it requires the interfaces of the routers should be assigned 
global IP addresses.
In addition, the draft shows the algorithm is applicable to a 
single router case.

Thank you for your comments, I will re-write my draft so that it clarifies
the relationship between RFC3484 you indicated.

Regards
Tel:   +66 8-4773-3252