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

Dino Farinacci <> Mon, 17 October 2016 19:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91F241294CC for <>; Mon, 17 Oct 2016 12:12:53 -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 Tz8l9BxpG-oV for <>; Mon, 17 Oct 2016 12:12:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 586FC12947E for <>; Mon, 17 Oct 2016 12:12:52 -0700 (PDT)
Received: by with SMTP id w3so123318792ywg.1 for <>; Mon, 17 Oct 2016 12:12:52 -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=LQTLOppw+zraz+VOWVy1XTVFY8bVnLn5CxkMIUAtlsg=; b=IIpi+agTK7RsEH0e8G5v4XFyVhl0Q3IpAeiI6dvCK1BzL8LoXvzK8rFIxWGbkYEK3Y 4uiM2327uYZ3mYjYmOHn+vQUdzGi1zsCWwo2bdBEsXpzSBiNVKXj9Vj8YtOSPLaW+IdV krfsfmA8VZkOJOLl1olLfN7/FBIKUvCPEQJF8vKZDFUuUASBAHrvg+P9f6IITQ5/RpTz atRY7gWD2OaGZ6qeguEv/9Z6/21BbN9vl1yyUrKF61cW6BbbUBNQxKhFvhtUp7MUBLPK KTVH/vu9oRrcbZelkKRjDlv8FrISWM/jEQmG65Pp4ga4xKpSxlk6xr/gvjzRKMW/eumI cGDQ==
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=LQTLOppw+zraz+VOWVy1XTVFY8bVnLn5CxkMIUAtlsg=; b=GV+RXOSzypciETy/TPY78lyV0iILSXPC040sPRIDZzunopeOSDb3kBssb3rSdvIdV3 XnCRxQZW7oV/cccfFCGWl6HCMq5tokTZgAf1tYIFUtMkwqbRLApbiIXl7VW0TdpvbyC8 gAXIRKV2vEP+GMaVJ3l0Li9xlwfIAIADi/vKwW4GtkkQ+9HaGkEjAvnP+lRQ6TI2SP0/ LEaUNpKwKwTNGFF2uxs3kH0iGqaneCJLm2u+ctqJhoJfyJyH3o4FK3iauUIJna43A4nc +H/2LomHjGnYiJ1GQBWtg9vr6daYM4LSHpvSo59qpOMqDFCd+SjnKBVnW2cCx+dVOZS3 KXDw==
X-Gm-Message-State: AA6/9Rk6uhbUhL2LZIxf9Bb8dEY/c7msaSnb/DIxwvFLlO81BuSmoO1/l/k+WkDVm64P6g==
X-Received: by with SMTP id a13mr25116266ywh.242.1476731571620; Mon, 17 Oct 2016 12:12:51 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id u138sm12309909ywe.42.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Oct 2016 12:12:51 -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: <2691CE0099834E4A9C5044EEC662BB9D572E1B48@dfweml501-mbb>
Date: Mon, 17 Oct 2016 12:12:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <2691CE0099834E4A9C5044EEC662BB9D572E1B48@dfweml501-mbb>
To: Lucy Yong <>
X-Mailer: Apple Mail (2.3226)
Archived-At: <>
Cc: "" <>, General Area Review Team <>
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: Mon, 17 Oct 2016 19:12:53 -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?

The draft is explaining how PIM messages are sent across the underlay between xTRs. Not how PIM operates within a LISP site. The way PIM operates within a LISP site is based on the PIM RFC unchanged.

The draft it solving the hard problem where the underlay neither supports multicast, partially supports multicast, or fully supports multicast. All these combinations create the complexity, so it is conveyed from ETRs that unicast PIM messages to ITRs according to RFC6831 (LISP-Multicast).

> 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)?

And the PIM protocol is run (over-the-top) between LISP xTRs.