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

[Jari Arkko]

On 01 Dec 2016, at 22:01, Dino Farinacci  wrote:

> There is no other text in the email. So can’t be sure what you are saying. 
> I’m guessing you are fine with the proposed text?

yes, the one that you proposed



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Lucy yong]

Thank you, Dino. Good, I understand it now.

Lucy

-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com] 
Sent: Thursday, December 01, 2016 1:53 PM
To: Lucy yong
Cc: Jari Arkko; draft-ietf-pim-join-attributes-for-l...@tools.ietf.org; General 
Area Review Team; Stig Venaas
Subject: Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

> OK, forget my suggestion. I have a difficulty to parse this sentence 
> (second part)
> 
>  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.
> 
> Lucy

First off, let’s include the entire paragraph:

   Knowledge of the receiver ETR's RLOC address is also essential to the
   control plane of the root ITR.  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.

How about we change to this:

   Knowledge of the receiver ETR's RLOC address is also essential to the
   control plane of the root ITR.  The RLOC address determines the downstream
   destination for unicast head-end replication and identifies the
   receiver ETR that needs to be notified should the root ITR of the
   distribution tree move to another site. The root ITR can change when the
   source EID is roaming to another LISP site.

Dino

> 
> -Original Message-
> From: Dino Farinacci [mailto:farina...@gmail.com]
> Sent: Thursday, December 01, 2016 1:45 PM
> To: Lucy yong
> Cc: Jari Arkko; 
> draft-ietf-pim-join-attributes-for-l...@tools.ietf.org; General Area 
> Review Team; Stig Venaas
> Subject: Re: [Gen-art] Review: 
> draft-ietf-pim-join-attributes-for-lisp-05
> 
> 
>> Could you make this sentence more readable?
>> 
>>  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.
>> 
>> "should be", "moving”?
> 
> I do not understand what you are suggesting. Write more words please.
> 
> Dino
> 
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dino Farinacci]

There is no other text in the email. So can’t be sure what you are saying. I’m 
guessing you are fine with the proposed text?

My co-authors have to agree though.  ;-)

Dino

> On Dec 1, 2016, at 11:55 AM, Jari Arkko  wrote:
> 
> That would work for me.
> 
> Jari
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Jari Arkko]

That would work for me.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dino Farinacci]

> OK, forget my suggestion. I have a difficulty to parse this sentence (second 
> part)
> 
>  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.
> 
> Lucy

First off, let’s include the entire paragraph:

   Knowledge of the receiver ETR's RLOC address is also essential to the
   control plane of the root ITR.  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.

How about we change to this:

   Knowledge of the receiver ETR's RLOC address is also essential to the
   control plane of the root ITR.  The RLOC address determines the downstream
   destination for unicast head-end replication and identifies the
   receiver ETR that needs to be notified should the root ITR of the
   distribution tree move to another site. The root ITR can change when the
   source EID is roaming to another LISP site.

Dino

> 
> -Original Message-
> From: Dino Farinacci [mailto:farina...@gmail.com] 
> Sent: Thursday, December 01, 2016 1:45 PM
> To: Lucy yong
> Cc: Jari Arkko; draft-ietf-pim-join-attributes-for-l...@tools.ietf.org; 
> General Area Review Team; Stig Venaas
> Subject: Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05
> 
> 
>> Could you make this sentence more readable?
>> 
>>  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.
>> 
>> "should be", "moving”?
> 
> I do not understand what you are suggesting. Write more words please.
> 
> Dino
> 
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Lucy yong]

OK, forget my suggestion. I have a difficulty to parse this sentence (second 
part)

  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.

Lucy

-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com] 
Sent: Thursday, December 01, 2016 1:45 PM
To: Lucy yong
Cc: Jari Arkko; draft-ietf-pim-join-attributes-for-l...@tools.ietf.org; General 
Area Review Team; Stig Venaas
Subject: Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05


> Could you make this sentence more readable?
> 
>   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.
> 
> "should be", "moving”?

I do not understand what you are suggesting. Write more words please.

Dino


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dino Farinacci]

> Could you make this sentence more readable?
> 
>   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.
> 
> "should be", "moving”?

I do not understand what you are suggesting. Write more words please.

Dino


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Lucy yong]

Hi Dino,

Sorry, I did not have time to study RFC6831 for this review work and may not 
interpret the draft properly by reading it. I trust you on the protocol design 
and have no objection on Jari's decision.

Could you make this sentence more readable?

   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.

"should be", "moving"?

Thanks,
Lucy
-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com] 
Sent: Thursday, December 01, 2016 1:07 PM
To: Jari Arkko
Cc: Lucy yong; draft-ietf-pim-join-attributes-for-l...@tools.ietf.org; General 
Area Review Team; Stig Venaas
Subject: Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

> Lucy,
> 
> Many thanks for your review.
> 
> Dino, Stig, does this discussion lead you to consider adding some 
> clarifications to the document? I am not going to require those (just posted 
> a no-obj for the document on today’s telechat), but wanted to give you an 
> opportunity to consider that.
> 
> Jari

The base LISP multicast architecture is all explained in RFC6831. From the type 
of commentary from Lucy’s email, it led me to believe she (1) had not read 
RFC6831 or (2) did not understand the content of RFC6831.

Discussing how LISP multicast works in a PIM document is a misplacement of 
information and risks contradicting what is in the LISP published RFCs.

Dino

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dino Farinacci]

> Lucy,
> 
> Many thanks for your review.
> 
> Dino, Stig, does this discussion lead you to consider adding some 
> clarifications to the document? I am not going to require those (just posted 
> a no-obj for the document on today’s telechat), but wanted to give you an 
> opportunity to consider that.
> 
> Jari

The base LISP multicast architecture is all explained in RFC6831. From the type 
of commentary from Lucy’s email, it led me to believe she (1) had not read 
RFC6831 or (2) did not understand the content of RFC6831.

Discussing how LISP multicast works in a PIM document is a misplacement of 
information and risks contradicting what is in the LISP published RFCs.

Dino

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Jari Arkko]

Lucy,

Many thanks for your review.

Dino, Stig, does this discussion lead you to consider adding some 
clarifications to the document? I am not going to require those (just posted a 
no-obj for the document on today’s telechat), but wanted to give you an 
opportunity to consider that.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dino Farinacci]

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

Right.

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

Well, you could use VXLAN encapsulation as the data-plane (arguably, with 14 
bytes of unnecessary overhead).

> 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 

You are conflating the relationship between PIM and LISP. PIM runs side-by-side 
with BGP, OSPF, IS-IS, and LISP. That is the way to look at it. Do they depend 
on each other? The answer is no. PIM uses the RIB that is populated by BGP, 
OSPF, IS-IS. And LISP uses the mapping database to find RLOCs where then it 
uses the RIB/FIB to forward to RLOCs.

There is no case where PIM messages are encapsulated by LISP. I mean it can be 
but it is not spec’ed anywhere and is not needed unless some new design feature 
is desired by it (like PIM Join/Prune messages need confidentiality so they are 
encapsulated in lisp-crypto).

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

Just taking a holistic view.

Dino


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Lucy yong]

 Dino,

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. 

Regards,
Lucy

Dino

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dino Farinacci]

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

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

> 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. And the details are in RFC6831. And if you are 
going to do a quality review of this document, you should read RFC 6831.

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

Dino

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Lucy yong]

Hi Stig and Dino,

Pls see inline below.

-Original Message-
From: Stig Venaas (svenaas) [mailto:s...@cisco.com] 
Sent: Tuesday, October 18, 2016 3:39 PM
To: Lucy yong; draft-ietf-pim-join-attributes-for-l...@tools.ietf.org; 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; 
> 'draft-ietf-pim-join-attributes-for-lisp....@tool.ietf.org'
> *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

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

[Stig Venaas (svenaas)]

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;
'draft-ietf-pim-join-attributes-for-lisp@tool.ietf.org'
*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.



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.

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.


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.


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.

Thanks,
Stig





Regards,

Lucy







___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dino Farinacci]

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

Dino
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Lucy yong]

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; 
'draft-ietf-pim-join-attributes-for-lisp@tool.ietf.org'
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?



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


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Lucy yong]

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



.



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


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art