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

Hi Magnus,

Here is a text proposal for the incremental deployment, including path probing, and about the edge-devices that need to be properly configured. Let me know your comments.

  Martin

> -----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
> 
[...]
> 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.

**Added a new flag in the NSLP header:


**Added a new section describing the incremental deployment usage
3.7.6.3.  Incremental Deployment using the Proxy Mode

   The above sections described the the proxy mode for cases where the
   NATFW NSLP is solely deployed at the network edges.  However, the
   NATFW NSLP might be incrementally deployed first in some network
   edges, but later on also in other parts of the network.  Using the
   proxy mode only, would prevent the NI to determine whether the other
   parts of the network have also been upgraded to use the NATFW NSLP.
   One way of determining whether the path from the NI to the NR is
   NATFW NSLP capable is to use the regular CREATE message and to wait
   for a successful response or an error response.  This will lead to
   extra messages being sent, as a CREATE message in addition to the
   anyhow required CREATE-PROXY message is sent from the NI.

   The NATFW NSLP allows the usage of the proxy-mode and a further
   probing of the path by the edge-NAT or edge-firewall.  The NI can
   request proxy-mode handling as described, and can set the E flag (see
   Section Figure 20) to request the edge-NAT or edge-firewall to probe
   the further path for NATFW NSLP enabled NFs or NR.

   The edge-NAT or edge-firewall MUST continue to send the CREATE-PROXY
   or EXTERNAL-proxy towards the NR, if the received proxy-mode message
   has the E flag set, in addition to the regular proxy mode handling.
   The edge-NAT or edge-firewall relies on the NTLP measures to
   determine whether there is no other NATFW NSLP reachable towards NR.
   A failed attempt to forward the request message to the NR will be
   silently discarded.  A successful attempt of forwarding the request
   message to the NR will be acknowledged by the NR with a successful
   response message, which is subject to the regular behavior described
   in the proxy-mode sections.


> 
> 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 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.


Added this section to address this:
3.7.6.4.  Deployment Considerations for Edge-Devices

   The proxy mode assumes that the edge-NAT or edge-firewall are
   properly configured by network operator, i.e., the edge-device is
   really the final NAT or firewall of that particular network.  There
   is currently no known way of letting the NATFW NSLP automatically
   detect which of the NAT or firewalls are the actual edge of a
   network.  Therefore, it is important for the network operator to
   configure the edge-NAT or edge-firewall and also to re-configure
   these devices if they are not at the edge anymore.  For instance, an
   edge-NAT is located within an ISP and the ISP chooses to place another
   NAT in front of this edge-NAT.  In this case, the ISP needs to
   reconfigure the old edge-NAT to be a regular NATFW NLSP NAT and to
   configure the newly installed NAT to be the edge-NAT.




[email protected]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014