Hi Fernando,
Thanks for responding. See below.
On Nov 17, 2010, at 06:42 MST, Fernando Gont wrote:
> Ok. Here's the text that I've included right bellow the formular:
>
> cut here
> This scheme should be used when a new flow is to be created (e.g., when
> a new TCP connection is to be
On Nov 18, 2010, at 16:17, RJ Atkinson wrote:
>
> Adding any extension header, other than an option carried within the existing
> IPv6 Destination Options header or the IPv6 Hop-by-Hop Options header, breaks
> that important operational capability. We all ought to try really hard to
> avoid bre
All,
This message starts a 6MAN Working Group Last Call on advancing:
Title : Using 127-bit IPv6 Prefixes on Inter-Router Links
Author(s) : M. Kohno, et al.
Filename: draft-ietf-6man-prefixlen-p2p-00.txt
Pages : 9
Date
On 18 Nov 2010, at 16:13 , Suresh Krishnan wrote:
> You said that, in your implementation,
I don't have an implementation. I'm an independent consultant,
primarily to folks who happen to operate some large IP networks.
In that position, I have NDAs in place not only with my clients,
but also wi
Hi Ran,
On 10-11-17 12:19 PM, RJ Atkinson wrote:
On 17 Nov 2010, at 11:39 , Suresh Krishnan wrote:
Another alternative would be to retain your draft,
but edit it along the lines I suggested earlier,
whereby explicit language prohibiting creation of new
extension headers that have either (a) h
In addition to this, what about cases where the end node does not know
how to process an option given in the destination header - this could
happen when some new destination option is being introduced and not
all boxes are upgraded to understand that? The current proposal
provides some extension fl
