Sure, but please add the TSVWG reference for NAT.


On Thu, Jan 4, 2024 at 11:10 AM Padma Pillay-Esnault <[email protected]>
wrote:

> Would these changes address your feedback?
>
> Clarified the text as we are not building a new NAT solution but rather
> adding LISP extensions needed to make it work.
>
> Original:
> NAT-Traversal: Support for a NAT-traversal solution in deployments where
> LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node).
>
> Proposed:
> NAT-Traversal: *LISP protocol extensions to* support a NAT-traversal
> solution in deployments where LISP tunnel endpoints are separated from by a
> NAT (e.g., LISP mobile node)
>
> and
>
> Original:
> Map Server Reliable Transport: LISP control plane messages are transported
> over UDP, however, in some cases, the use of a reliable transport protocol
> is a better fit, since it actually helps reduce periodic signaling.
>
> Proposed:
> Map Server Reliable Transport: LISP control plane messages are transported
> over UDP, however, in some cases, the use of a reliable transport protocol
>  *(such as TCP)*  is a better fit, since it actually helps reduce
> periodic signaling.
> Thanks
> Padma
>
> On Thu, Jan 4, 2024 at 9:00 AM Martin Duke <[email protected]>
> wrote:
>
>> SG, please mention these points in the text.
>>
>> On Thu, Jan 4, 2024 at 8:38 AM Padma Pillay-Esnault <[email protected]>
>> wrote:
>>
>>> Hi Martin
>>>
>>> Please see PPE for my comments inline
>>>
>>> On Tue, Jan 2, 2024 at 11:50 AM Martin Duke via Datatracker <
>>> [email protected]> wrote:
>>>
>>>> Martin Duke has entered the following ballot position for
>>>> charter-ietf-lisp-04-06: Block
>>>>
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/charter-ietf-lisp/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> BLOCK:
>>>> ----------------------------------------------------------------------
>>>>
>>>> Is the NAT traversal work going to prioritize existing solutions (e.g.
>>>> STUN,
>>>> TURN, ICE), or have all those already been determined to be inadequate?
>>>> If the
>>>> latter, LISP should coordinate with TSVWG on its NAT traversal solution.
>>>>
>>>> PPE - The symmetric or endpoint-address-and-port-dependent mapping NATs
>>>> (ICE, TURN..) have been  have been determined to be inadequate due to
>>>> the nature of LISP that is typically unidirectional traffic and its usage
>>>> of UDP port 4341 without specification of source port.
>>>>
>>> Yes - on coordination with TSVWG.
>>>>
>>>
>>>
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>> Is the reliable transport protocol required to be secure? (e.g., are you
>>>> looking at TCP/TLS, QUIC, and SCTP/DTLS, or just bare TCP/SCTP)
>>>>
>>>> PPE - The current reliable transport draft has a proposal for the use
>>>> of bare TCP and fallback to UDP using the existing mechanisms for security
>>>> in LISP. The document is being evaluated and reviewed.
>>>>
>>>>
>>> Thanks
>>> Padma
>>>
>>
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to