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
