Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

Dino Farinacci <> Wed, 19 October 2016 17:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A2BE1296AA for <>; Wed, 19 Oct 2016 10:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GQKN3r5rzFuz for <>; Wed, 19 Oct 2016 10:14:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 199C81295B0 for <>; Wed, 19 Oct 2016 10:14:41 -0700 (PDT)
Received: by with SMTP id r16so19317972pfg.1 for <>; Wed, 19 Oct 2016 10:14:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dlwAKAMP2HXb4f1tm2Fq65RAzMcJxZ6ZCGqOeMPPeyA=; b=fUO5r0k+IhEkxinpzUiQ2HcYteg2Z/3bWh1BWkrXKsW7iK0hmXSF3X/teQAROi/GSJ U0KlxWe/giar3F7VW+XlY0KCxZOGsBe40meJITTVVVrm+ntDh/uE8s60zFsfO0qJ035b P1muf7icoBiut3GQrlxu5lJU18B78Cgs3iOSzOyPhyooZXEcCUi9xEloTvIzKCO7ya5z fBLi+f6VeQnJ2wPz46rPYGa1xBJjai5XZ5TD+ufR7OwTOkPngRziiX05yKU7h57hhQ7i KNbv08xkg+FICTa6qSS6Cw4Rxkkwo+73OGGYPcwWFzjQ3Kj81GYjFfghId2yR81gVmTc pfBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dlwAKAMP2HXb4f1tm2Fq65RAzMcJxZ6ZCGqOeMPPeyA=; b=jv65lIYKctKTo3QPNZCq156G97HB86FkGtkw46UTn8ObMH3NB+U0hgg0QwlIUHFuTw OO0mwcsVAdNs/IGJRlEHxpY/Da9Lk4n3LhKWEmKoTVUX6vtWjJxv5TjHBLnUEI3XnYQx TIIJA+eEGL9Zr2IxjUJ3hVv/pjbWokiyI0PiCTkRgcBrJ5mNotiQhvL8qcuHPTg13vl1 5ulTz5Gc/+0ZY9BA9pGb0yLh0LffT7YSLNySyaX1VmhuDfknpRnLXVj2yQQ9uIiE2MA7 qoPXqYwFrF8bMH6R/rfs8Pg+1SYcic1BwHO3uOCACOczUWNdlB66teSzEsVztYulzepW p8XA==
X-Gm-Message-State: AA6/9RnOZHII4BAJbVIxZ2mORAn5ArJfDDZpht8FhVePyFb952xQom7wjGaQPc1Cd37AoQ==
X-Received: by with SMTP id o77mr12922432pfi.177.1476897280546; Wed, 19 Oct 2016 10:14:40 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id m25sm14188597pfg.14.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 10:14:40 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Dino Farinacci <>
In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D572E282A@dfweml501-mbb>
Date: Wed, 19 Oct 2016 10:14:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <2691CE0099834E4A9C5044EEC662BB9D572E1B66@dfweml501-mbb> <> <2691CE0099834E4A9C5044EEC662BB9D572E282A@dfweml501-mbb>
To: Lucy Yong <>
X-Mailer: Apple Mail (2.3226)
Archived-At: <>
Cc: "" <>, General Area Review Team <>, Stig Venaas <>
Subject: Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Oct 2016 17:14:42 -0000

>> the draft assumes that PIM works within individual LISP sites but PIM 
>> mcast transport may not be supported among LISP sites. However the 
>> mechanism itself does not enforce a unique (unicast or mcast) underlay 
>> transport among LISP sites. Could some ETRs request unicast transport, 
>> other request multicast transport? The mechanism requires all LISP 
>> xTRs to run PIM protocol, right?
> We are sending a PIM join and we assume that the upstream LIS xTR is supporting PIM. This is similar to RFC 6831. If PIM is not supported, the join message would be ignored. As we mention in section 4 we want to allow a mixture of multicast and unicast forwarding.
> [Lucy] I am thinking that how many PIM protocol instance may run in this case, one is within a LISP 

Two. One at all LISP sites (not one per LISP site) and part of the overlay and possibly one in the underlay.

> site, one is for LISP underlay network, and one among LISP xTRs, is this right? PIM protocol instance running for LISP xTRs is a special version with additional LISP related attributes? When configuring 

I don’t know what you mean by “additional LISP related attributes”. The LISP xTR runs PIM and sends unicast PIM Join/Prune messages to other xTRs.

> PIM protocol on a device, do we need to differ them in configuration? Sorry to ask these, I have not yet read RFC6831 but understand what you want to achieve here.

That is implementation specific. And the details are in RFC6831. And if you are going to do a quality review of this document, you should read RFC 6831.

>> PIM join/prune msg are designed for PIM protocol. These two attributes 
>> are specifically designed for LISP purpose. Any concern here? From PIM 
>> perspective, they are optional attributes; are they "MUST" attributes 
>> for LISP (mcast)?
> It is possible to do multicast according to 6831 without these attributes. As we mention in this 

Yes, if multicast is in the underlay and reaches every LISP site. But the point is, it may not. Plus this draft can be used when RFC 6831 is NOT used but when draft-ietf-lisp-signal-free-multicast is used so the ITR can know if multicast RLOCs can be used. 

But the best test to know if a multicast RLOC should be used is to RLOC-probe it and see all the ETRs that reply. Then you know which ETRs can received the encapsulated multicast packet via a multicast underlay. And the ones that don’t, you unicast replicate. This is the case where multicast partially deployed in the underlay.