[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Hi Alain,
The point is not only the IETF docs ... Is more all the vendor documents and
operational guidelines.
So, if we decide to rename 6over4 (6overm4, for example), we still need to
have a document that says 6in4=6over4 from now on.
I was referring only to 6in4, 4in6, not foo over bar, but in any case, I'm
not absolutely sure if we really need to modify the IETF documents as I
indicate in this document, or if just the document itself is enough
clarification and must reinforce the change for any new publications
(specially for vendor documents, etc.).
Regards,
Jordi
> De: "Durand, Alain" <Alain_Durand@cable.comcast.com>
> Responder a: <alain_durand@cable.comcast.com>
> Fecha: Sun, 16 Oct 2005 19:10:47 -0400
> Para: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
> Conversación: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
> Asunto: RE: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
>
> Few comments:
>
> a) I have seen much more confusion with 6to4 that with anything else. Most
> people think of it
> as NAT IPv6 -> IPv4.
>
> b) Many other encapsulation exists, not just v6/v4 & friends. The jargon
> "over" is used very widely,
> like ATM over Sonnet, and, for instance, many of the documents in the Int
> area can be described
> as "IP over foo". So creating a new jargon for just IPvx over IPvy may
> introduce even more
> confusion.
>
> c) More, asking all the standard bodies that used "foo over bar" terminology
> to
> change to "foo in bar" just because there is a little use IETF protocol
> named "6over4"
> does not sound very realistic.
>
> d) 6over4 as a transition mechanism isn't used much, it might be simpler to
> just suggest to
> either deprecate it or rename it, then restoring the original "foo over
> bar" terminology
> as semantically equivalent to "foo in far".
>
> - Alain.
>
> ________________________________
>
> From: owner-v6ops@ops.ietf.org on behalf of JORDI PALET MARTINEZ
> Sent: Sun 10/16/2005 5:54 PM
> To: v6ops@ops.ietf.org
> Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
>
>
>
> Clue accepted ;-)
>
> A new document has been submitted (attached for those that want to start
> commenting already).
>
> Regards,
> Jordi
>
>
>
>
>> De: Fred Baker <fred@cisco.com>
>> Responder a: <owner-v6ops@ops.ietf.org>
>> Fecha: Mon, 15 Aug 2005 14:47:02 -0700
>> Para: <jordi.palet@consulintel.es>
>> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
>> Asunto: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
>>
>> On Aug 15, 2005, at 2:25 PM, JORDI PALET MARTINEZ wrote:
>>> Overall, agree with your conclusions about 3.3, but I think there
>>> is one more scenario, which is the one that we are facing, and
>>> seems to me the right way to go, actually the natural one, being
>>> deployed with some of our customers.
>>>
>>> ,---. ,---.
>>> / \ / \
>>> / \ / \
>>> ; IPv4+6 : ; IPv4+6 :
>>> | Network | | Network |
>>> : +----+---. ,---. ,---. ,---+----+ ;
>>> \ |GW-A| \ / \ / \ / |GW-D| /
>>> \ +----+ +----+ \ / +----+ +----+ /
>>> `---' ; IPv6 |GW-B| IPv4 : ; IPv4 |GW-C| IPv6 : `---'
>>> | Network+----+ + | | + +----+Network |
>>> ,---. :Transition : IPv6 : : IPv6 ,---.
>>> / +----+A / \ B / \ C / \ D+----+ \
>>> / |GW-A| / \ / \ / \ |GW-D| \
>>> ; IPv4+6+----+--' `---' `---' `--+----+IPv4+6 :
>>> | Network | | Network |
>>> : ; : ;
>>> \ / \ /
>>> \ / \ /
>>> `---' `---'
>>>
>>> Network A and D are IPv6-only, with GW-A and GW-B taking care of
>>> the v4-in-v6 tunneling, automatically.
>>
>> There are certainly cases in which a consistent transition strategy
>> is being followed and is working. I think I said something in the
>> document about granting that the use of a single consistent strategy
>> that works will probably work :^).
>>
>> What I am concerned about is the proliferation of inconsistent
>> strategies, and the set of cases I can come up with in which they do
>> not work. That is the issue I am trying to raise.
>>
>>> One more comment. I've discovered a lot of confusion in several
>>> documents regarding 6over4 and 6in4, which is being followed by
>>> confusing documents from vendors. I think is very important to make
>>> a general recommendation, may be not just to this WG, but in
>>> general to all the IETF documents which mention tunneling, to
>>> clearly make a distinction between both mechanisms, probably
>>> avoiding using "over" when actually is referring 6in4
>>> encapsulation. Not sure if this should be raised at IESG level or
>>> whatever. What do you think ?
>>
>> What you expect clue? :^)
>>
>> Yes, it would be good if people would say clueful things in a clueful
>> way. There is probably room for an internet draft on the subject.
>>
>
>
>