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

Stig Venaas <> Thu, 06 May 2021 22:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D9A63A0D6D for <>; Thu, 6 May 2021 15:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9vEcwGWMoWBq for <>; Thu, 6 May 2021 15:43:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B55423A0D66 for <>; Thu, 6 May 2021 15:43:31 -0700 (PDT)
Received: by with SMTP id u3so10610883eja.12 for <>; Thu, 06 May 2021 15:43:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yY52XJhHARqKcSP9+uZB4Sv+lLfcdAsQQ8V0W7pNyRc=; b=lcXIr0sAILiyQDrvK8eiNBKq1Zn5MF/3xpGi621HqN+SyQQq80DrHzD3TZZhQEaZHN 8uPAcadzrD5gyvstYRctyXNzU3XCTq0iZyiBK5vrC6k7p4fxA1B/tJ/3ddRvU7MTrd7j glnEClfpLFa1Fp6FYW1Iq7YQmC+hRlBr2Jyj3EeoGuPUhCdQ2s+Jrg/82Y0TILnjLadM vmdUwk/oKi6AjqQ3KH0GF9Dtakh6AnzZxIMtAiDnlNoQdl3J3wQUl0VCqVyLBU98YndQ tx1PrjZ+F8DtexFpZEkgzrFrbfnXHM1qcyPHTFWt6ZYTubDRCUBizFhBO/ccy7iS2Nc8 hBpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yY52XJhHARqKcSP9+uZB4Sv+lLfcdAsQQ8V0W7pNyRc=; b=g0/ZBitXa7ZUPHoaDeM/GGkuJ0L/fKe2Vclmt5doexzaMAEmGCnqDe9egwi2mNflwS 05yHzeU/LaF0Yc2JkHHseUPrgYi4f3oc05cOt8SurubDkDvjuRaRHVIhl5h5ndPj0000 /MmB+vw4x2ib1LvbioKTp+seMxy0u05gteB2/kTGhOYIEkSinaqX33EPY/WXUqakv0QS 5yzYiwn+o8slHEP1sG2ljDg2dcq98fvDRRuVuc/MD44mbiJdaxOddA6DO9TupGGWolkJ 6CSwiOwh8vgPcjM+B+P/+NdHBr2qsYZ174I0e/Wg4+l+gD6iFZW9sh0yC/f4GYRngWHA eQ+g==
X-Gm-Message-State: AOAM5335nYrCodRyR5M+wdllLwBaEXps5nEUIW797AL9OB6A+iACSmwP YMJIKGrw8RUKv7YUHH3zriN4nIf6rcjPIsBRMR3YznaCKlY=
X-Google-Smtp-Source: ABdhPJwJilD+92D0jn7r+I9qy9B/DHtdLfkjirp5u24obHXzBQKhDWkglfrSwXRrwcJ9nkv2cqEiKqRoSQpZ27MD8OQ=
X-Received: by 2002:a17:906:3b84:: with SMTP id u4mr6785637ejf.131.1620341009403; Thu, 06 May 2021 15:43:29 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Stig Venaas <>
Date: Thu, 6 May 2021 15:43:18 -0700
Message-ID: <>
To: "Vengada Prasad Govindan (venggovi)" <>
Cc: "" <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [pim] [lisp] Requesting comments on draft-vgovindan-pim-jp-extensions-lisp
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 May 2021 22:43:36 -0000

Hi all

I'm aware of implementations of RFC 8059 by Cisco. Does anyone know of
other implementations?


On Thu, May 6, 2021 at 2:12 AM Vengada Prasad Govindan (venggovi)
<> 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 <> On Behalf Of Vengada Prasad Govindan (venggovi)
> Sent: Tuesday, March 30, 2021 13:54
> To:
> Cc:
> 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 <>
> Cc:
> Subject: Requesting comments on draft-vgovindan-pim-jp-extensions-lisp
> Hello LISP/ PIM WG members,
> 1. Problem Statement : In a multi-site LISP topology [], 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 []
> 4. This draft was to PIM WG @ IETF-110.  Minutes are recorded
> 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: [] - Slides 12-14 in particular provides the protocol sequences. Also explained in RFC 6831
> Thanks
> Prasad
> _______________________________________________
> lisp mailing list