Hi all I'm aware of implementations of RFC 8059 by Cisco. Does anyone know of other implementations?
Regards, Stig On Thu, May 6, 2021 at 2:12 AM Vengada Prasad Govindan (venggovi) <[email protected]> wrote: > > 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 <[email protected]> On Behalf Of Vengada Prasad Govindan > (venggovi) > Sent: Tuesday, March 30, 2021 13:54 > To: [email protected] > Cc: [email protected] > 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:[email protected]> > Cc: mailto:[email protected] > 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 > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
