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

[Lucy yong <[e-mail]>]

Hi Stig and Dino,

Pls see inline below.

-----Original Message-----
From: Stig Venaas (svenaas) [mailto:[e-mail]] 
Sent: Tuesday, October 18, 2016 3:39 PM
To: Lucy yong; [e-mail]; A. Jean Mahoney; General Area Review Team
Subject: Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

Hi

Thanks for the review Lucy, please see comments inline.

On 10/17/2016 12:09 PM, Lucy yong wrote:
> //
>
>
>
> Send again.  fix some template info.
>
> / /
>
> *From:*Lucy yong
> *Sent:* Monday, October 17, 2016 1:59 PM
> *To:* A. Jean Mahoney; General Area Review Team; 
> '[e-mail]'
> *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-pim-join-attributes-for-lisp-05
>
>      PIM Join Attributes for LISP environments.
>
> Reviewer: Lucy Yong
>
> Review Date: 17-Oct-2016
>
> IETF LC End Date: 24-Oct-2016
>
> IESG Telechat date:
>
>
>
> Summary: This document specifies two new PIM join/prune attributes for 
> facilitating PIM mcast transports across LISP sites.*//*Some issues 
> need to be considered prior to publishing.
>
>
>
> 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?

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 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 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.
>
>
> 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 draft, the transport attribute is useful in telling the upstream whether to use unicast or multicast.
6831 only talks about multicast.
[Lucy] This means that without using this attribute, it means use of multicast transport. Good to make that clear in the document for backward compatibility. Alternative is only using this attribute when unicast transport is requested.

We also discuss in this section 5 how the ETR RLOC attribute is helpful in determining the unicast destination address and for root-EID mobility. As we mention, one could without the RLOC attribute instead use the outer source address of the LISP encapsulated J/P message, but that may not necessarily be the best/right address to use. So I think we are explaining how one can do LISP multicast without these new attributes, but there are benefits in using them. So in short, they are not "MUST" attributes, but there are good reasons for using them.
[Lucy] So this attribute is only benefit for unicast case.

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

We could perhaps clarify some, but I think we should expect someone reading this in order to implement it, or in order to understand an implementation, to have some knowledge of both PIM and LISP. At least terms like RLOC, EID, ITR, ETR and xTR.

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

Perhaps we should make this clearer. Currently we have this text in section 5:

    To support root-EID mobility, receiver ETRs must also be tracked by
    the LISP control plane of the root ITR, regardless of the underlying
    transport.

In other words, one could choose not to use it for multicast transport, but that means one may not be able to support root-EID mobility.
Mobility may not always be a requirement, but it often is.

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

An implementation could fall back to assuming multicast transport (per
6831) and the outer source address when the attributes are not present.

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

No, it is used a synonym of "in case" here.
[Lucy] text  "It determines the downstream destination for unicast head-end replication and identifies the
   receiver ETR that needs to be notified should the root of the
   distribution tree move to another site."  I don't understand this sentence.

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

I'm not sure honestly. It is describing what implementations generally need to do (or must), but it is not something we are specifying or enforcing here, it is just information explaining how things generally work.
[Lucy] examples: the PIM control plane of the root ITR must
   maintain an output interface list ("oif-list") entry for the receiver
   ETR and its corresponding RLOC address.

   receiver ETRs must also be tracked by
   the LISP control plane of the root ITR, regardless of the underlying
   transport.  

Maybe I could be wrong.

Regards,
Lucy

Thanks,
Stig

>
>
>
> Regards,
>
> Lucy
>
>
>
>
>