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

Lucy yong <> Wed, 19 October 2016 18:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A7B2126D73 for <>; Wed, 19 Oct 2016 11:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CALfDxPAqd50 for <>; Wed, 19 Oct 2016 11:51:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE48C129428 for <>; Wed, 19 Oct 2016 11:51:07 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id CYO05006; Wed, 19 Oct 2016 18:51:05 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 19 Oct 2016 19:51:04 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Wed, 19 Oct 2016 11:51:02 -0700
From: Lucy yong <>
To: Dino Farinacci <>
Thread-Topic: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05
Date: Wed, 19 Oct 2016 18:51:02 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572E28BC@dfweml501-mbb>
References: <2691CE0099834E4A9C5044EEC662BB9D572E1B66@dfweml501-mbb> <> <2691CE0099834E4A9C5044EEC662BB9D572E282A@dfweml501-mbb> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5807C099.01FF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 65eb77b6b866a05d876ca3563b585257
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 18:51:11 -0000


please see inline below.

>> 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.
[Lucy] Thank, Dino. This is helpful. So the attributes proposed in this draft is used in the first PIM instance, right? These attributes are only used by ETRs to send join/prune msg to ITR (root).

> 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.
[Lucy] I mean the attribute is per LISP specific implementation.

> 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.
[Lucy] PIM is a protocol running on top of IGP. Now we have PIM LISP implementation specific. Within a LISP site, PIM has no change; the LISP implementation are only on XTRs.
 And the details are in RFC6831. And if you are going to do a quality review of this document, you should read RFC 6831.
[Lucy] I hear you. 

>> 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.
[Lucy] You are the expert on this subject. From the draft text, I am not able to picture these.