Re: [lisp] Requesting comments on draft-vgovindan-pim-jp-extensions-lisp

["Vengada Prasad Govindan (venggovi)" <[e-mail]>]

Hello all,
  An update on this thread:
- A good amount of offline discussions happened on this topic, we (Dino Farinacci, Stig Venaas, Victor Moreno and myself) have the following updates:
        o Instead of proposing a new TLV, we have an alternate proposal to extend the Receiver ETR RLOC Attribute [RFC8059].
        o Currently the Receiver ETR RLOC Attribute is specified to carry only unicast IPv4/6 address, but the term RLOC [RFC8378] can also be used to include multicast IPv4/ v6 address.
        o Hence we propose to extend the specification of Receiver ETR RLOC Attribute to carry both unicast and multicast iPv4/6 address.
- We would like to know about concerns/ thoughts from WG members in making the above extension:
        o Are there any functional / interoperability issues expected? What happens when existing implementations of RFC8059 receive a PIM J/P with the above attribute carrying a multicast address ?
        o Are there other design considerations we need to take into account here that go against the proposed extension.
- Based on the outcome of the above discussion a -01 version of draft-vgovindan-pim-jp-extensions-lisp may be resubmitted.

Thanks
Prasad

From: pim <[e-mail]> On Behalf Of Vengada Prasad Govindan (venggovi)
Sent: Tuesday, March 30, 2021 13:54
To: [e-mail]
Cc: [e-mail]
Subject: Re: [pim] Requesting comments on draft-vgovindan-pim-jp-extensions-lisp

Not sure if the LISP WG alias was correct. Apologies if you receive multiple copies.

Thanks
Prasad

From: Vengada Prasad Govindan (venggovi) 
Sent: Tuesday, March 30, 2021 13:50
To: lisp <mailto:[e-mail]>
Cc: mailto:[e-mail]
Subject: Requesting comments on draft-vgovindan-pim-jp-extensions-lisp

Hello LISP/ PIM WG members,
1. Problem Statement : In a multi-site LISP topology [https://www.ietf.org/proceedings/72/slides/RRG-3.pdf], the site border nodes operate in 3 different PIM domains (2 in the underlay, one facing the LISP site and one facing the transit site and the third domain in the overlay): 
a. An important point to consider here would be the practical value of reusing the same locator address of the border node in both site-facing and transit-facing directions.
b. Given the above consideration of reusing the locator address in both directions, using the same underlay multicast address range in the 2 different underlay PIM domains may cause packet loops. 
c. This is because the hashing of the overlay parameters to obtain the underlay group could result in hash collisions as described in Sec 8.1.2 of RFC 6831
d. The LISP border nodes downstream also face similar constraints. 
e. Hence, we propose a reasonable trade-off to make extra copies of the packet at the site border using different multicast address ranges to avoid packet loops. However this need not always de-generate to ingress replication.
2. The base idea of the draft is an extension of the RLOC receiver TLV specified in RFC8059. While RFC8059 defined the TLV for Ingress Replication (LISP Multicast over Unicast tunnels), the new draft tries to define TLVs needed for LISP multicast over Native multicast. 
3. For a background on PIM J/P attribute hierarchy, please see [https://www.ietf.org/proceedings/94/slides/slides-94-pim-1.pdf]  
4. This draft was https://datatracker.ietf.org/meeting/110/materials/slides-110-pim-jp-extension-lisp-multicast-underlay-00.pdf to PIM WG @ IETF-110.  Minutes are recorded https://datatracker.ietf.org/doc/minutes-110-pim/.
5. It has been suggested to consider this draft for presentation at the upcoming LISP WG meeting. Requesting questions/ comments about the draft in the mailing list.

Note: [https://www.ietf.org/proceedings/72/slides/RRG-3.pdf] - Slides 12-14 in particular provides the protocol sequences. Also explained in RFC 6831

Thanks
Prasad