On 2011/07/08, at 2:16, Mark Townsley wrote: > > Sure, based on your review of the document that's fine. But, not "the thread > from a WG chair perspective" as stated above. That's ridiculous. >
I hope that the chair take adoption to be a WG document. Please discriminate your chair role from your personal technical view. >> For example, no logging has been presented as a strong reason to do >> sateless. However, no logging can be achieved >> with static port allocation on a centralized NAT. On this particular logging >> point, there are no obvious differences between the >> 'distributed on CPE' NAT solution and the centralized NAT solution. > > As you point out, the "no logging" part is really a function of the use of a > static mapping to a range of ports. Any centralized NAPT function can use > static mapping. When you use static mapping, then you get all the pros and > cons that go along with it. > >> More generally, it seems that what is described as a 'stateless' solution >> should be characterized as a >> 'distributed state' solution. As such, the tradeoff of maintaining the state >> centrally vs globally >> needs to be analyzed. > > "stateless operation" if you prefer. The point is that within the ISP > network, there is no per-flow state that resides on any single endpoint > running the protocol in question. So, config can be static, and BRs can be > reached via anycast. That's the heart of a stateless solution. Just like 6rd, > if you will. Good point. 'no per-flow state' is goodness for redundancy, load-sharing, etc., These are usual expectations of IP network operations. > >> Also, it is not clear from this document which set of issues listed in >> RFC6269 are mitigated and which ones are not. >> In particular, I'd hold that a so-called 'stateless' solution does not >> change anything about the recommendations in RFC6302/BCP162 >> that are derived from RFC6269... The draft explains motivation of stateless solution for ISP networks where are going to share IPv4 address. Consequence of server side should be same with other solutions. -- snip -- > > Section 18: Single Points of Failure - here, stateless wins pretty much hands > down as it is not introducing any new single points of failure. > Yes. > Perhaps there are a few more, but "most" should be insignificant by the own > document's admission. > Agree. >> We, chairs, would like to prepare a 'organized' discussion around these >> points (and others). We need a small number of >> volunteers to help frame this discussion. Please contact me and Yong >> directly if you want to help. >> This is an important topic, and we intend to make sure there is ample time >> for discussion in Quebec. > > Why don't we just discuss it on the list and have a consensus call instead? > > If we had a thread of 200 messages as we did for moving 6to4 to historic, OK > maybe we need to have a big coordinated discussion. But, I'm not seeing > anything on the thread here that would suggest that we need to spend a lot of > time preparing some big discussion among a group of people you and Yong > select. Again, would you take appropriate procedure for the adoption? Best regards, --satoru _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
