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
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.
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
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?
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"
Gen-art mailing list