jump in here:) So I think we can agree they have different use cases/application scenarios. Refer to Yong's example again, in CERNET user access(IPv4 & IPv6) is based on Ethernet, pure-IP. Authentication is done through other way. We do want to keep that. ------------------ Peng Wu PhD candidate Department of Computer Science & Technology Tsinghua University, Beijing, China
------------------------------------------------------------- From：Ole Troan Date：2011-03-31 16:46:06 To：Lee, Yiu CC：[email protected] list Subject：Re: [Softwires] Questions on: draft-cui-softwire-host-4over6 Yiu, > Ok. I agree with your definition. How about I rephrase it that dslite and > 4over6 don't require control channel. RFC5571 requires control channel. > Can we agree that control channel requires extra overhead? absolutely. both encapsulation and signalling overhead. that does come with some benefits though, e.g. you can do authentication and so on. cheers, Ole >> Yiu, >> >>> The way to set up the tunnel is similar to ds-lite. The CPE will learn >>> the >>> TC's v6 address, then encap v4 packets into v6 to the TC. To create the >>> v4-v6 mapping in the TC's routing table. This could be done by the TC to >>> look at the dhcp message or by keepalive packets from the cpe. We >>> haven't >>> decided which way is preferred. But the tunnel itself is stateless. >> >> since we have tended to classify mechanisms into 'stateless' and >> 'stateful'. I think we need a common understanding of what mean by these >> terms. >> >> simply stated, if the mechanism scales by the number of >> subscribers/tunnels then it is stateful. if it scales by the amount of >> packets/traffic then it is stateless. >> >> if you agree with that definition I would think 4over6 is stateful, since >> it suggests to integrate the tunnel state into the RIB. i.e. you allocate >> a piece of memory per subscriber and you have to snoop on DHCP messages >> to refresh this state. >> >> cheers, >> Ole > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
