[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt



I am fine with this spec content and objective.  If we have folks use
incompatible transition mechanisms that can be a pain.  

I don't believe IPv6 Dominant networks will cause a problem if there is
not IPv4 traffic edge, where there is an IPv4/IPv6 traffic edge like the
DSTM Border or a GRE router that must be dual IP capable, which is
required for a DSTM border router, so it can be used for dual IP packet
types.

Suggest adding reference to IPv6 Enterprise Scenarios RFC 4057. 

thanks
/jim

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker
> Sent: Monday, August 15, 2005 5:47 PM
> To: jordi.palet@consulintel.es
> Cc: v6ops@ops.ietf.org
> Subject: 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.
> 
>