Re: Agenda items?
Iljitsch van Beijnum <iljitsch@muada.com> Wed, 27 February 2008 11:12 UTC
Return-Path: <owner-shim6@psg.com>
X-Original-To: ietfarch-shim6-archive-oY2iet1p@core3.amsl.com
Delivered-To: ietfarch-shim6-archive-oY2iet1p@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E433A6A51 for <ietfarch-shim6-archive-oY2iet1p@core3.amsl.com>; Wed, 27 Feb 2008 03:12:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1umBs0xYwji for <ietfarch-shim6-archive-oY2iet1p@core3.amsl.com>; Wed, 27 Feb 2008 03:12:01 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F23A93A69E8 for <shim6-archive-oY2iet1p@lists.ietf.org>; Wed, 27 Feb 2008 03:12:00 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from <owner-shim6@psg.com>) id 1JUJzx-00072u-TQ for shim6-data@psg.com; Wed, 27 Feb 2008 10:58:53 +0000
Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <iljitsch@muada.com>) id 1JUJzv-00072R-26 for shim6@psg.com; Wed, 27 Feb 2008 10:58:52 +0000
Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m1RAwZJc020137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2008 11:58:37 +0100 (CET) (envelope-from iljitsch@muada.com)
Cc: 'shim6' <shim6@psg.com>
Message-Id: <451CAD4F-D0B2-4C34-B8AE-87C9B9ADF603@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Geoff Huston <gih@apnic.net>
In-Reply-To: <47C49EAB.7050608@apnic.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Agenda items?
Date: Wed, 27 Feb 2008 11:58:42 +0100
References: <47AF8A55.4080204@apnic.net> <47C49EAB.7050608@apnic.net>
X-Mailer: Apple Mail (2.919.2)
Sender: owner-shim6@psg.com
Precedence: bulk
On 27 feb 2008, at 0:20, Geoff Huston wrote: > This is a more formal call for agenda items for the next shim6 > meeting, as I'm putting together the agenda right now I think it would be good if we could have a discussion on what's missing from shim6 the way it is now so that we can decide on what new work to take on. Such as: - "initial failures" where the initially chosen address pair doesn't work - ingress filtering - rewriting addresses in routers - proxy shim * with or without NAT - traffic engineering Envelope-to: shim6-data@psg.com Delivery-date: Wed, 27 Feb 2008 11:00:58 +0000 Cc: "'shim6'" <shim6@psg.com> Message-Id: <451CAD4F-D0B2-4C34-B8AE-87C9B9ADF603@muada.com> From: Iljitsch van Beijnum <iljitsch@muada.com> To: Geoff Huston <gih@apnic.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Agenda items? Date: Wed, 27 Feb 2008 11:58:42 +0100 On 27 feb 2008, at 0:20, Geoff Huston wrote: > This is a more formal call for agenda items for the next shim6 > meeting, as I'm putting together the agenda right now I think it would be good if we could have a discussion on what's missing from shim6 the way it is now so that we can decide on what new work to take on. Such as: - "initial failures" where the initially chosen address pair doesn't work - ingress filtering - rewriting addresses in routers - proxy shim * with or without NAT - traffic engineering Envelope-to: shim6-data@psg.com Delivery-date: Tue, 26 Feb 2008 23:22:23 +0000 Message-ID: <47C49EAB.7050608@apnic.net> Date: Wed, 27 Feb 2008 10:20:11 +1100 From: Geoff Huston <gih@apnic.net> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: 'shim6' <shim6@psg.com> Subject: Re: Agenda items? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is a more formal call for agenda items for the next shim6 meeting, as I'm putting together the agenda right now Draft agendas are due Wednesday (tomorrow) at 17:00 ET, so I'd appreciate submission of topics as soon as possible (like, now!) Keep those cards and letters coming! Geoff Envelope-to: shim6-data@psg.com Delivery-date: Tue, 19 Feb 2008 10:59:28 +0000 Message-ID: <47BAB62C.20301@apnic.net> Date: Tue, 19 Feb 2008 21:57:48 +1100 From: Geoff Huston <gih@apnic.net> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: 'shim6' <shim6@psg.com> Cc: Olivier.Bonaventure@uclouvain.be Subject: New drafs on improving shim6 for corporate and campus networks Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I saw this in the moderator's queue, so I'm forwarding it on Geoff -------- Original Message -------- Date: Tue, 19 Feb 2008 11:49:53 +0100 From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Reply-To: Olivier.Bonaventure@uclouvain.be To: shim6@psg.com Subject: New drafs on improving shim6 for corporate and campus networks Folks, We have submitted two drafts that are targeted at improving the behaviour of shim6 hosts in campus and corporate networks by allowing the network operator to provide hints on the paths that hosts should use to reach some destinations. Please find below the abstract of the two drafts. The will appear on the IETF mirrors. In the meantime, they can be retrieved from http://inl.info.ucl.ac.be/publications Title : The case for an informed path selection service Author(s) : O. Bonaventure, D. Saucez, B. Donnet Filename : draft-bonaventure-informed-path-selection-00.txt With today's peer-to-peer applications, more and more content is available from multiple sources. In tomorrow's Internet hosts will have multiple paths to reach one destination host with the deployment of dual-stack IPv4/IPv6 hosts, but also with new techniques such as shim6 or other locator/identifier mechanisms being discussed within the IRTF RRG. All these hosts will need to rank paths in order to select the best paths to reach a given destination/content. In this draft, we propose an informed path selection service that would be queried by hosts and would rank paths based on policies and performance metrics defined by the network operator to meet his traffic engineering objectives. A companion document describes a protocol that implements this service. Title : IDIPS : ISP-Driven Informed Path Selection Author(s) : D. Saucez, et al. Filename : draft-saucez-idips-00.txt This draft describes a simple network-based protocol to facilitate Path Selection and to improve traffic engineering capabilities in multihomed corporate networks. With this protocol, any network device that requires to select a path among a list of different paths asks a Traffic Engineering service called IDIPS (ISP-Driven Informed Path Selection) to obtain an ordered list of the possible paths. The ordering is constructed according to policies and performance requirements of both the host and network provider. Comments are welcome ! Olivier, Damien and Benoit -- http://inl.info.ucl.ac.be , Universite catholique de Louvain, Belgium Envelope-to: shim6-data@psg.com Delivery-date: Thu, 14 Feb 2008 15:23:15 +0000 Cc: <shim6@psg.com> Message-Id: <4819DD1A-138C-48CC-B7F6-45D54DB2FB4A@muada.com> From: Iljitsch van Beijnum <iljitsch@muada.com> To: =?ISO-8859-1?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Question about REAP state transition (draft-ietf-shim6-failure-detection-09) Date: Thu, 14 Feb 2008 16:20:40 +0100 On 14 feb 2008, at 13:34, Alberto Garc=EDa wrote: > Some time after A is not receiving anymore data from B, the Send =20 > timer at A > expires. Then, A moves from Inbound_ok to the Exploring state, The way I see it, you don't go from Inbound_OK to Exploring. The text =20= "received incoming probe since the last transition from Operational to =20= Exploring" is consistent with that and not with the situation where =20 Inbound_OK -> Exploring is possible. However, the advantage of allowing Inbound_OK -> Exploring is that =20 this can work around the situation where a second failure breaks even =20= more a short time after the first failure. On the other hand, this should be rare and eventually, the protocol =20 will converge on what's still working even though selecting a new =20 unidirectional address pair that stops working before the address pair =20= for the other direction will lead to some extra delays. Iljitsch= Envelope-to: shim6-data@psg.com Delivery-date: Thu, 14 Feb 2008 12:36:54 +0000 From: =?iso-8859-15?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es> To: "'Iljitsch van Beijnum'" <iljitsch@muada.com> Cc: <shim6@psg.com> Subject: RE: Question about REAP state transition (draft-ietf-shim6-failure-detection-09) Date: Thu, 14 Feb 2008 13:34:57 +0100 Message-ID: <006201c86f06$022efd60$7d8b75a3@bombo> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Thread-Index: AchooQOhfViBITPHSHCrd6VC9TvdkQGYNljA | -----Mensaje original----- | De: Iljitsch van Beijnum [mailto:iljitsch@muada.com] | Enviado el: mi=E9rcoles, 06 de febrero de 2008 10:17 | Para: Alberto Garc=EDa | CC: shim6@psg.com | Asunto: Re: Question about REAP state transition (draft-ietf-shim6-failure- | detection-09) | =20 | On 5 feb 2008, at 11:22, Alberto Garc=EDa wrote: | =20 | > It is nice to clarify that information related to the received | > probes should | > be included in the probes sent in the InboundOK state. | =20 | > However, I still think that these information MUST be included also = if | > available in the Exploring state (and not optionally, in = "MAY"-style). | =20 | Well, I clarified that the only probes we copy back are the ones = since | the last transition from Operational to Exploring, because otherwise | it's possible to copy back old probes that were received before the | failure happened. And since the reception of an inbound probe means | going from Exploring to InboundOK it's impossible to have any probes | to copy back in Exploring. Maybe it's useful to make copying back one | probe mandatory in Operational too, though. Sorry cause I think I did not manage to explain precisely the problem = (and some mistakes such as "retransmission timer" arose). Lets try again: Suppose to nodes A and B communicating. Only one unidirectional path is available from A to B after a failure (lets name it Pab_ok), and only = one from B to A (Pba_ok).=20 Both A and B are in Exploring. B sends a probe using Pba_ok. Node A in Exploring state receives the = Probe Exploring through Pba_ok, so it moves to Inbound_OK. For the next Probes node A sends (unfortunately, NOT through Pab_ok), A includes the = information about the valid locators for its incoming paths (Pba_ok). But since it = is not able to find a working path from A to B for some time, these probes never arrive to B. So B is still in Exploring state B starts testing other paths (no longer Pba_ok), but these paths are not working.=20 Some time after A is not receiving anymore data from B, the Send timer = at A expires. Then, A moves from Inbound_ok to the Exploring state, and stops including the validity of Pba_ok in its probes [this is the item of the discussion] Both A and B are now in exploring. (we change A and B role) Now A sends a probe to B through Pab_ok, moving B to Inbound_ok. But B = is now exploring non-working paths... Then A tries new paths for its = probes, the Send timer in B expires so it goes back to exploring.... A and B back again in exploring... (do this forever) Two valid unidirectional paths existed, one from A to B, and other from = B to A. Both nodes send probes through them. But the protocol could not move = both ends to an Operational state, because they were not known at a given timeframe by both nodes. Do you think this is a problem? | =20 | > In B, the Retransmission Timer of B expires because a valid path | > from A to B | > was not found, | =20 | What do you mean by "retransmission timer"? There is no timer with | that name. | =20 | Probes are sent at certain intervals without considering whether | they're retransmissions. | =20 | > so B starts testing other paths that are not working. | =20 | B keeps testing paths until it sees A is in state InboundOK. | =20 | > Then, A | > stops receiving data from B, so the Send timer expires (I don't = find | > any | > reason why all the possible paths should be explored in less than = Send | > Timeout time, so A could not test all possible paths from A to B in | > this | > time). | =20 | The Send Timeout is for determining when the probing starts. The | probing process does not depend on the Send Timeout. | =20 | Because probing exponentially backs off, a good number of them are | sent in the first minute or so (I think 17, but it depends on the | exact values for the exponential backoff) but at some point, the | probing rate is only one per minute. In theory, this means you will | find any working address pair if you wait long enough. In practice, This is what I'm questioning. My understanding is that currently it is = not enough to test all, but to be luck to find valid paths for both = directions within a given timeframe; otherwise, both ends don't agree in the paths = even they exist. | you don't really care anymore after 30 - 300 seconds, depending on | transport timers and user patience. This means the number of address | pairs shouldn't be more than 16 or so (4 addresses on each end). | | > Then, A falls to the Exploring state, and (in the supposition of = the | > previous paragraph) forgets about the working path from B to A. May | > be now A | > sends a probe to B through a working path. but in B happens the = same | > (it | > tries now with different paths from B to A that are no valid, so A | > tries | > another paths from A to B abandoning the good one...). | =20 | The inclusion of at least one probe that was received earlier in | outgoing probes should fix this: when you get a packet from the other | side, you know at least one working address pair from here to there. | Obviously this won't work if reachability changes in the interim.=3D Envelope-to: shim6-data@psg.com Delivery-date: Wed, 13 Feb 2008 22:49:28 +0000 Message-ID: <47B3737D.8020102@apnic.net> Date: Thu, 14 Feb 2008 09:47:25 +1100 From: Geoff Huston <gih@apnic.net> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: 'shim6' <shim6@psg.com> Subject: I-D Action:draft-ietf-shim6-failure-detection-11.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming by IPv6 Intermediation Working Group of the IETF. Title : Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming Author(s) : J. Arkko, I. van Beijnum Filename : draft-ietf-shim6-failure-detection-11.txt Pages : 43 Date : 2008-02-13 This document specifies how the level 3 multihoming shim protocol (SHIM6) detects failures between two communicating hosts. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same hosts if a failure occurs and an operational pair can be found. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-shim6-failure-detection-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-shim6-failure-detection-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Envelope-to: shim6-data@psg.com Delivery-date: Tue, 12 Feb 2008 14:35:29 +0000 Cc: shim6@psg.com Message-Id: <D7940985-25EF-4BDC-A512-20E3DB7E3386@it.uc3m.es> From: marcelo bagnulo braun <marcelo@it.uc3m.es> To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <sebastien.barre@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Draft reviews Date: Tue, 12 Feb 2008 15:33:09 +0100 thanks i will address those of the proto, locator in the next reviews El 12/02/2008, a las 14:24, S=E9bastien Barr=E9 escribi=F3: > Hi, > > While writing the shim6-impl draft, I have noted some minor things =20 > with the drafts. Most of them are editorial comments, I have found =20 > also some may/must/should conflicts. > Comments about shim6-proto-09,failure-detection-10, locator-pair-=20 > selection-02 and multihome-shim-api are detailed below. > > regards, > > S=E9bastien. > > > draft-ietf-shim6-proto-09.txt > ----------------------------------------------- > > Section 5.6 : ULID pair : ... addresses in the IPv6 header does not =20= > match -> > do not match > CGA PDS : ...so the receiver...-> so that the receiver > Section 5.15 : C : critical, One if the parameter is critical, and =20 > MUST be recognized by the recipient -> I don't think this is a MUST =20= > in the sense of RFC2119, since currently no option is defined as =20 > critical. The draft thus specifies as an "absolute requirement of =20 > the specification" something that does not exist yet. I would say =20 > that this may be rather a "must" of a given implementation, and as =20 > such I just would prefer to see it in lowercase. > Section 5.15.3 (at the end) : a of a 1 octet flag field followed... -=20= > > a sequence of a 1 octet ... > Section 7.1 : ...cycle through the unstrucutred -> unstructured > Section 7.2 : different than the ULID -> different from the ULID > Section 7.6 : I would add a pointer to section 7.15 : "A more =20 > detailed description of what should be done to detect confusions is =20= > given in section 7.15" > Section 7.15 : Forked Intance Identifier different than the ones... -=20= > > are different from the ones... > Section 7.15 : Conflicting MAY and MUST with section 7.6 : 7.6 says =20= > "The requirement is that the old context which used the context tag =20= > MUST be removed" while 7.15 says "the host MUST NOT use the old =20 > context, it MAY just discard the old context." > Section 8 : with an payload extension header -> with a payload... > Section 11 : Then it there is also no effect -> Then there is also... > Section 12.1 : for reachability detection porpuses -> purposes > Section 12.2 : for packets that does not have -> that do not have > Section 12.3 : it checks that the neither the ->it check that =20 > neither the... > Section 12.3 : I think that the checksum should be verified _after_ =20= > the length > field, since this field is used by the checksum verification =20 > procedure. > Failing to do that could result in reading memory areas past the end > of the IPv6 packet. > Section 12.3 : Conflicting SHOULD and MUST with section 5.15 : 5.15 =20= > says "If a host receives an option that it does not understand and =20 > If C=3D1 then the host SHOULD send back a Shim6 Error Message with =20 > Error Code=3D1..." while 12.3 says "If there is any option in the =20 > message with C=3D1 that isn't known to the host, the host MUST send a =20= > Shim6 Error Message with Error Code=3D1...". > Section 15.1 : it recommended -> it is recommended > Section 15.2 : =A71 : the presudoheader -> pseudoheader > Section 15.2 : =A72 : ...the next header header -> the next header > Section 15.2 : =A73 : unless they implement are able -> unless they =20= > are able > > > draft-ietf-shim6-failure-detection-10.txt > ------------------------------------------------------------------- > > Section 3.3 : =A75 : explicit rechability tests -> reachability > Section 4.1 : "Nodes SHOULD employ techniques listed in Section 3.1 =20= > and > Section 3.2 to track the local situation." : These two sections are =20= > already > completely covered by MUST/MAY statements. IMHO this creates a > SHOULD/MUST/MAY conflict > between section 3.1/3.2 and 4.1. > Section 4.1, item 5 : "REAP keepalive > packets SHOULD continue to be sent at the Keepalive Interval > until either a data packet in the SHIM6 context has been received > from the peer or the Keepalive Timeout expires" : I would replace > "has been received from" with "has been sent to" > Section 4.2 : =A74 : so that the ULP SHOULD be informed -> thus the =20= > ULP SHOULD be informed. > Section 5.1 and 5.2 : The same field has name Reserved1 for =20 > keepalive and Reserved for Probe. Probably it should also be =20 > Reserved1 for probe > (since the probe has a Reserved2 field as well). > Section 5.1 and 5.2 : Strange use of the MUST statement regarding =20 > the Reserved* > fields : All those fields MUST be ignored on receipt, but only > the Reserved2 field of the probe message MUST be set to 0 upon > transmission. I would replace this MUST with the usual 'It is set =20= > to 0 > ...' > > draft-ietf-shim6-locator-pair-selection-02.txt > = --------------------------------------------------------------------------= - > > Section 2.2 : a locator pair is know to be...-> is known to be > > draft-ietf-shim6-multihome-shim-api-03.txt > = ------------------------------------------------------------------------ > > Section 1 : =A75 : a singed integer of... -> a signed integer > > --=20 > S=E9bastien Barr=E9 > Researcher, > CSE department, UCLouvain, Belgium > http://inl.info.ucl.ac.be/sbarre > > Envelope-to: shim6-data@psg.com Delivery-date: Tue, 12 Feb 2008 13:24:54 +0000 Message-ID: <47B19E0A.3030702@uclouvain.be> Date: Tue, 12 Feb 2008 14:24:26 +0100 From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <sebastien.barre@uclouvain.be> User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: shim6@psg.com Subject: Draft reviews Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, While writing the shim6-impl draft, I have noted some minor things with the drafts. Most of them are editorial comments, I have found also some may/must/should conflicts. Comments about shim6-proto-09,failure-detection-10, locator-pair-selection-02 and multihome-shim-api are detailed below. regards, Sébastien. draft-ietf-shim6-proto-09.txt ----------------------------------------------- Section 5.6 : ULID pair : ... addresses in the IPv6 header does not match -> do not match CGA PDS : ...so the receiver...-> so that the receiver Section 5.15 : C : critical, One if the parameter is critical, and MUST be recognized by the recipient -> I don't think this is a MUST in the sense of RFC2119, since currently no option is defined as critical. The draft thus specifies as an "absolute requirement of the specification" something that does not exist yet. I would say that this may be rather a "must" of a given implementation, and as such I just would prefer to see it in lowercase. Section 5.15.3 (at the end) : a of a 1 octet flag field followed... -> a sequence of a 1 octet ... Section 7.1 : ...cycle through the unstrucutred -> unstructured Section 7.2 : different than the ULID -> different from the ULID Section 7.6 : I would add a pointer to section 7.15 : "A more detailed description of what should be done to detect confusions is given in section 7.15" Section 7.15 : Forked Intance Identifier different than the ones... -> are different from the ones... Section 7.15 : Conflicting MAY and MUST with section 7.6 : 7.6 says "The requirement is that the old context which used the context tag MUST be removed" while 7.15 says "the host MUST NOT use the old context, it MAY just discard the old context." Section 8 : with an payload extension header -> with a payload... Section 11 : Then it there is also no effect -> Then there is also... Section 12.1 : for reachability detection porpuses -> purposes Section 12.2 : for packets that does not have -> that do not have Section 12.3 : it checks that the neither the ->it check that neither the... Section 12.3 : I think that the checksum should be verified _after_ the length field, since this field is used by the checksum verification procedure. Failing to do that could result in reading memory areas past the end of the IPv6 packet. Section 12.3 : Conflicting SHOULD and MUST with section 5.15 : 5.15 says "If a host receives an option that it does not understand and If C=1 then the host SHOULD send back a Shim6 Error Message with Error Code=1..." while 12.3 says "If there is any option in the message with C=1 that isn't known to the host, the host MUST send a Shim6 Error Message with Error Code=1...". Section 15.1 : it recommended -> it is recommended Section 15.2 : §1 : the presudoheader -> pseudoheader Section 15.2 : §2 : ...the next header header -> the next header Section 15.2 : §3 : unless they implement are able -> unless they are able draft-ietf-shim6-failure-detection-10.txt ------------------------------------------------------------------- Section 3.3 : §5 : explicit rechability tests -> reachability Section 4.1 : "Nodes SHOULD employ techniques listed in Section 3.1 and Section 3.2 to track the local situation." : These two sections are already completely covered by MUST/MAY statements. IMHO this creates a SHOULD/MUST/MAY conflict between section 3.1/3.2 and 4.1. Section 4.1, item 5 : "REAP keepalive packets SHOULD continue to be sent at the Keepalive Interval until either a data packet in the SHIM6 context has been received from the peer or the Keepalive Timeout expires" : I would replace "has been received from" with "has been sent to" Section 4.2 : §4 : so that the ULP SHOULD be informed -> thus the ULP SHOULD be informed. Section 5.1 and 5.2 : The same field has name Reserved1 for keepalive and Reserved for Probe. Probably it should also be Reserved1 for probe (since the probe has a Reserved2 field as well). Section 5.1 and 5.2 : Strange use of the MUST statement regarding the Reserved* fields : All those fields MUST be ignored on receipt, but only the Reserved2 field of the probe message MUST be set to 0 upon transmission. I would replace this MUST with the usual 'It is set to 0 ...' draft-ietf-shim6-locator-pair-selection-02.txt --------------------------------------------------------------------------- Section 2.2 : a locator pair is know to be...-> is known to be draft-ietf-shim6-multihome-shim-api-03.txt ------------------------------------------------------------------------ Section 1 : §5 : a singed integer of... -> a signed integer -- Sébastien Barré Researcher, CSE department, UCLouvain, Belgium http://inl.info.ucl.ac.be/sbarre Envelope-to: shim6-data@psg.com Delivery-date: Tue, 12 Feb 2008 13:19:23 +0000 Message-ID: <47B19C5A.5010101@uclouvain.be> Date: Tue, 12 Feb 2008 14:17:14 +0100 From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <sebastien.barre@uclouvain.be> User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: shim6@psg.com Subject: Fwd: I-D Action:draft-barre-shim6-impl-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, I have submitted this draft recently to present the state of the LinShim6 implementation. It could also be used as a template for describing the state of other implementations. Hopefully future versions will include a section "interoperability tests". This draft is based on LinShim6 0.6, that has just been released and is available at http://inl.info.ucl.ac.be/LinShim6 Any comment is very welcome. regards, Sébastien. Inicio del mensaje reenviado: > De: Internet-Drafts@ietf.org > Fecha: 5 de febrero de 2008 18:00:01 GMT+01:00 > Para: i-d-announce@ietf.org > Asunto: I-D Action:draft-barre-shim6-impl-00.txt > Responder a: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Shim6 Implementation Report : LinShim6 > Author(s) : S. Barre > Filename : draft-barre-shim6-impl-00.txt > Pages : 19 > Date : 2008-02-05 > > LinShim6 is an implementation of the Shim6 and REAP protocols, on the > Linux platform. This draft provides a brief description of the > architecture and describes the current state of our implementation. > For each feature of the protocols, its level of support is described. > Protocol conformance is evaluated against [1] and [2]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barre-shim6-impl-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-barre-shim6-impl-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-barre-shim6-impl-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2008-02-05085815.I-D\@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > http://www.ietf.org/mailman/listinfo/i-d-announce -- Sébastien Barré Researcher, CSE department, UCLouvain, Belgium http://inl.info.ucl.ac.be/sbarre Envelope-to: shim6-data@psg.com Delivery-date: Sun, 10 Feb 2008 23:38:34 +0000 Message-ID: <47AF8A55.4080204@apnic.net> Date: Mon, 11 Feb 2008 10:35:49 +1100 From: Geoff Huston <gih@apnic.net> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: 'shim6' <shim6@psg.com> Subject: Agenda items? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Shim6 will be meeting at the forthcoming IETF - please let Kurtis and I know if you have a contribution to this meeting thanks Geoff & Kurtis Envelope-to: shim6-data@psg.com Delivery-date: Wed, 06 Feb 2008 09:17:49 +0000 Cc: <shim6@psg.com> Message-Id: <69689EBC-DE88-431F-B67D-86CD90BB0F26@muada.com> From: Iljitsch van Beijnum <iljitsch@muada.com> To: =?ISO-8859-1?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Question about REAP state transition (draft-ietf-shim6-failure-detection-09) Date: Wed, 6 Feb 2008 10:16:43 +0100 On 5 feb 2008, at 11:22, Alberto Garc=EDa wrote: > It is nice to clarify that information related to the received =20 > probes should > be included in the probes sent in the InboundOK state. > However, I still think that these information MUST be included also if > available in the Exploring state (and not optionally, in "MAY"-style). Well, I clarified that the only probes we copy back are the ones since =20= the last transition from Operational to Exploring, because otherwise =20 it's possible to copy back old probes that were received before the =20 failure happened. And since the reception of an inbound probe means =20 going from Exploring to InboundOK it's impossible to have any probes =20 to copy back in Exploring. Maybe it's useful to make copying back one =20= probe mandatory in Operational too, though. > In B, the Retransmission Timer of B expires because a valid path =20 > from A to B > was not found, What do you mean by "retransmission timer"? There is no timer with =20 that name. Probes are sent at certain intervals without considering whether =20 they're retransmissions. > so B starts testing other paths that are not working. B keeps testing paths until it sees A is in state InboundOK. > Then, A > stops receiving data from B, so the Send timer expires (I don't find =20= > any > reason why all the possible paths should be explored in less than Send > Timeout time, so A could not test all possible paths from A to B in =20= > this > time). The Send Timeout is for determining when the probing starts. The =20 probing process does not depend on the Send Timeout. Because probing exponentially backs off, a good number of them are =20 sent in the first minute or so (I think 17, but it depends on the =20 exact values for the exponential backoff) but at some point, the =20 probing rate is only one per minute. In theory, this means you will =20 find any working address pair if you wait long enough. In practice, =20 you don't really care anymore after 30 - 300 seconds, depending on =20 transport timers and user patience. This means the number of address =20 pairs shouldn't be more than 16 or so (4 addresses on each end). > Then, A falls to the Exploring state, and (in the supposition of the > previous paragraph) forgets about the working path from B to A. May =20= > be now A > sends a probe to B through a working path. but in B happens the same =20= > (it > tries now with different paths from B to A that are no valid, so A =20 > tries > another paths from A to B abandoning the good one...). The inclusion of at least one probe that was received earlier in =20 outgoing probes should fix this: when you get a packet from the other =20= side, you know at least one working address pair from here to there. =20 Obviously this won't work if reachability changes in the interim.= Envelope-to: shim6-data@psg.com Delivery-date: Tue, 05 Feb 2008 10:23:56 +0000 From: =?ISO-8859-15?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es> To: "'Iljitsch van Beijnum'" <iljitsch@muada.com> Cc: <shim6@psg.com> Subject: RE: Question about REAP state transition (draft-ietf-shim6-failure-detection-09) Date: Tue, 5 Feb 2008 11:22:22 +0100 Message-ID: <00ba01c867e0$fece0930$7d8b75a3@bombo> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Thread-Index: AchkAmSRMPaM8dL5TOWyweIzGVXIogD3I6Gg Hi, It is nice to clarify that information related to the received probes = should be included in the probes sent in the InboundOK state. However, I still think that these information MUST be included also if available in the Exploring state (and not optionally, in "MAY"-style).=20 Otherwise (I copy a part of a previous mail with an example in which the lack of this information in the probes sent in the Exploring state makes impossible to recover the communication) "if it is possible that the exploration process could not find two valid unidirectional paths (on = each direction) even if they exist. Suppose that a node A in Exploring state receives a Probe Exploring, so it moves to Inbound_OK. For the next = Probes it sends, it includes the information about the valid locators for its incoming paths (B to A), but it is not able to find a working path from = A to B for some time. In B, the Retransmission Timer of B expires because a valid path from A = to B was not found, so B starts testing other paths that are not working. = Then, A stops receiving data from B, so the Send timer expires (I don't find any reason why all the possible paths should be explored in less than Send Timeout time, so A could not test all possible paths from A to B in this time). Then, A falls to the Exploring state, and (in the supposition of = the previous paragraph) forgets about the working path from B to A. May be = now A sends a probe to B through a working path. but in B happens the same (it tries now with different paths from B to A that are no valid, so A tries another paths from A to B abandoning the good one...). In this case, two valid unidirectional paths existed, one from A to B, and other from B to = A, but the protocol could not find them, because they not were known at the same time by both nodes." Any reason why you consider this information should not be mandated to = be included? Best regards, Alberto | -----Mensaje original----- | De: Iljitsch van Beijnum [mailto:iljitsch@muada.com] | Enviado el: jueves, 31 de enero de 2008 13:11 | Para: Alberto Garc=EDa | CC: shim6@psg.com | Asunto: Re: Question about REAP state transition (draft-ietf-shim6-failure- | detection-09) | =20 | Alberto, | =20 | it's been a long time, so I'm not entirely sure if I missed something | else in your message. Please let me know if that's the case. I want = to | change this text: | =20 | <t hangText=3D'Precvd'><vspace blankLines=3D'1'/> | =20 | This is a 4-bit field that indicates the number of received probes | included in this probe message. Received probe fields are copies of = the | same fields received in (recent) earlier probes and may be included = or | omitted as per any logic employed by the implementation. | =20 | =20 | to: | =20 | =20 | <t hangText=3D'Precvd'><vspace blankLines=3D'1'/> | =20 | This is a 4-bit field that indicates the number of received probes | included in this probe message. Received probe fields are copies of = the | same fields in earlier received probes that arrived since the last | transition from state Operational to state Exploring. When a sender = is | in state InboundOk it MUST include copies of the fields of at least | one the inbound probe. A sender MAY include additional sets of these | received probe fields in any state as per any logic employed by the | implementation. | =20 | =20 | I think this addresses the problem where two unidirectional paths | wouldn't be found.
- Agenda items? Geoff Huston
- Re: Agenda items? Geoff Huston
- Re: Agenda items? Iljitsch van Beijnum
- Re: Agenda items? Geoff Huston