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

From: Lucy yong <[email-masked]>
Date: Mon, 17 Oct 2016 19:02:50 +0000

Send again.

From: Lucy yong
Sent: Monday, October 17, 2016 1:59 PM
To: A. Jean Mahoney; General Area Review Team; [email-masked]'
Subject: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-tictoc-multi-path-synchronization-05

     Multi-Path Time Synchronization

Reviewer: Joel Halpern

Review Date: 15-Sept-2016

IETF LC End Date: 28-Sept-2016

IESG Telechat date: 29-Sept-2016

Summary: This document specifies two new PIM join/prune attributes for facilitating PIM mcast transports across LISP sites.

Major issues:

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?

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

Minor issues: the draft uses many PIM and LISP terms without any explanation. It is hard for a reader to read it without knowledge of PIM and LISP protocol and terms.

It is not clear if Receiver RLOC attribute only applies to unicast transport or both unicast/mcast transport. Need to clarify.

Backward compatibility, without these two attributes in a join/prune msg from a LISP ETR, what that mean?

Nits/editorial comments:

Section 1: "to be notified should the root of the
   distribution tree move to another site."  Should "should" be "that"?

Section 5: several 'must' should be "MUST"

Regards,
Lucy

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 17 Oct 2016 12:12:47 -0700

> 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…

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.

Dino