Re: Incremental deployement story fordraft-ietf-nsis-nslp-natfw-20

Hi Magnus, 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Magnus Westerlund
> Sent: Friday, November 27, 2009 1:57 PM
> To: [email protected]; NSIS
> Subject: [NSIS] Incremental deployement story fordraft-ietf-nsis-nslp-
> natfw-20
> 
> Hi,
> 
> I am reviewing the NAT/FW NSLP and have some high level questions about
> this work regarding incremental deployment.
> 
> When reading the document I get the impression that it starts out in
> world where the majority of the nodes have been upgraded and focus on
> mechanism in that world. It is not that it needs to work, but to me the
> main focus would be to ensure that the signaling protocol works well
> when deploying it only in one access network, or even subnet and then
> starts to grow the deployment.

I have to confess that the initial work started with the naïve view of deploying NSIS everywhere, but we backed off with the proxy mode.

> 
> I am missing this story and how to get good performance out of the NSLP
> in such settings. The proxy mode enables this to some degree but seems
> to lack some functionality to allow for incremental deployment. The
> main
> issue seems to be sender proxying that seems to lack a method to
> indicate: Please proxy this but also try end to end. That allows for
> quick setup of the egress to public path, and allows for opening all
> the
> way if the end-to-end actually works.
> 
> I would like to have a section that describes how one can start out
> with
> some end-hosts and edge-NAT/FW that support proxying. Then probe the
> path towards end-to-end to see if there are additional NATFW aware
> entities on the path allowing for a increase functionality scope.

I will draft text and send it. This sounds like an excellent idea.

> 
> I am also a bit worried about the assumption that edge devices must be
> correctly configured. Consider the case of an ISP that does NAT44, i.e.
> the customer - ISP edge has one NAT that may have been the edge
> initially, but then the ISP has run out of addresses and decides to
> deploy its own NAT. For the application running in an end-host the gain
> with the NATFW signalling is lost until the customer edge device is
> reconfigured to not any longer be the edge. I don't know if there is a
> simple solution to this problem. If not I would defer the inclusion but
> it should be noted as a short coming.

We discussed this back in time, but didn't come up with any good and workable solution. That is the reason with simply referred to "correctly configured", as only the ISP can (or should) know its network and the outermost NAT. This might not be the best solution, but seems to be the only workable as it stands right now.

  Martin


> 
> Comments?
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email protected]
> ----------------------------------------------------------------------
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis