Subject: [conex] Call for adoption for draft-krishnan-conex-destopt-00

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Jul 2011 10:39:58 +0200

This is the call for adoption for draft-krishnan-conex-destopt-00

You can find it at:

https://datatracker.ietf.org/doc/draft-krishnan-conex-destopt/

Please read it and comment whether you think we should adopt this doc as 
WG doc.
We plan to discuss its adoption during the meeting as well and make a 
decision after the meeting.

Regards, marcelo

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 21 Jul 2011 12:22:44 -0400

> decision after the meeting.

I think it's a good idea to adopt, and may be the most feasible
approach based on the requirements.

It does rely heavily on the companion draft-krishnan-conex-ipv6
document for rationale, and there are a couple things in that
which might need to be added.

I think one thing that bears a little bit of discussion in the
companion draft-krishnan-conex-ipv6 document is whether the
implementation of destination option processing in a conex router
is possible in the fast-path when other destination options are
used in conjunction, or whether there's some assumption about the
number or order of destination options.

There are two sub-goals of R-3 in that document which aren't
currently clearly laid out, and those are (1) to not hit the
slow-path on non-conex routers, and (2) to be implementable
in the fast-path on conex routers.  I think clarifying any
assumptions there might be on the second part would be valuable.

Another question is whether there's a requirement to be
compatible with use of IPsec, which seems like it should at
least be mentioned.

-- 
Wes Eddy
MTI Systems

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Jul 2011 18:31:08 +0200

Right, one thing i have been wondering is what to do with 
draft-krishnan-conex-ipv6

One option would be to publish it as informational for background (we 
don't have that item in our charter, but i would expect we can do that 
anyway)
the other option would be to include it in the destopt draft as an 
appendix. My concern with this last approach is that people may object 
the draft due to discussion related to the material included in the 
appendix, which would be unfortunate.

If people have opinions on this as well, it would be useful to know

Regards, marcelo

---

From: John Leslie <[email-masked]>
Date: Thu, 21 Jul 2011 14:02:31 -0400

marcelo bagnulo braun <[email-masked]> wrote:
> El 21/07/11 18:22, Wesley Eddy escribi?:

   It would seem to me that the amount of text it actually depends on
doesn't exceed 500 words, and would be easy enough to copy into
conex-destopt.

   conex-destopt needs work in any case. We need to specify the three
high-order bits of the option type; and IMHO we need to discuss option
order -- since Destination Options _can_ occur in multiple times and
may follow Authentication and Encapsulation headers.

   We probably need to discuss which routing nodes will process a
ConEx Destination Option, since the IPv6 RFCs suggest these will be
ignored until the packet reaches its Destination Address (but of
course do nothing to prevent this).

   We will very likely recommend that a ConEx Destination Option be
placed as early as possible in a Destination Option header but not
preceding a Routing header (should such an animal ever happen!).

--
John Leslie <[email-masked]>