Hemant Singh; Thank you for your comments.
At Wed, 27 Feb 2008 16:01:27 -0500, Hemant Singh (shemant) wrote: > > 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? > 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. > 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. > This is typo. > 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! > No, I am 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 see. Thank you for your advice. 2.1 and 2.2 should be "Management Approach" and "Implementation Approach" or something. > 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 > ------------------------------------------------------------------ FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan Mail: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW: http://www23.atwiki.jp/hudikaha/ Skype: fujikawakenji > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > FUJIKAWA Kenji > Sent: Monday, February 25, 2008 9:31 PM > To: ipv6@ietf.org > 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, > > 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 PROTECTED], [EMAIL PROTECTED] > WWW: http://www23.atwiki.jp/hudikaha/ > Skype: fujikawakenji > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
