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

This looks good.

Magnus

Martin Stiemerling skrev 2010-01-19 13:36:
> 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
> 


-- 

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