Looks good to me. On Thu, Jan 4, 2024 at 11:35 AM Padma Pillay-Esnault <[email protected]> wrote:
> Sure. New proposed changes. > > 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). The LISP WG will collaborate with the TSVWG > working on NAT-Transversal. > > On Thu, Jan 4, 2024 at 11:12 AM Martin Duke <[email protected]> > wrote: > >> 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
