Subject: [pim] draft-ietf-pim-explicit-tracking pim 2nd wglc

From: Stig Venaas <[email-masked]>
Date: Mon, 22 Apr 2013 15:29:47 -0700

We did a last call for this document in February, but we got hardly any
responses, so it was hard for us chairs to know whether the WG indeed
was happy with the latest revision.

We are now attempting another last call. Please respond to this so that
we can have some progress in the working group. We need to know whether
you are happy with the current version, or if you have any issues that
need to be addressed.

This call ends Monday May 6th.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Mon, 22 Apr 2013 15:53:01 -0700

Here is my response as a WG member to the last call.

The document looks good, but I see two possible issues.

Section 3.1 seems to talk too much about implementation details. In
particular the sentence "In order to simplify the implementation, the
explicit tracking function MAY NOT keep the state of (S,G) joined with
EXCLUDE filter mode."

I think it's wrong here to say what the implementation MAY NOT do, in
particular if it is just a simplification. Advice is OK, but not strict
requirements for an internal implementation detail.

The security considerations could be improved a bit. Potential issues of
maintaining state are discussed, and a rate limit on membership
information. First of all, I don't think it is a rate limit, it's should
be a limit on the maximum amount of memberships at any time. I think.
Further, it should be pointed out that an attack could either cause some
members to not be tracked, or some members to not be able to join and
receive.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 25 Apr 2013 10:42:13 -0700

Not many replies yet! We have one more week, please review this
document. It will be hard for us to make progress if we don't get
any responses.

Stig

On 22.04.2013 15:29, Stig Venaas wrote:
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Tina TSOU <[email-masked]>
Date: Thu, 25 Apr 2013 21:30:24 +0000

Dear all,
The current version looks good to me.

Thank you,
Tina

---

From: "Shuai Gao" <[email-masked]>
Date: Fri, 26 Apr 2013 08:29:14 +0800

Dear Folks,
	I support the adoption of the current version.

Regards,
Shuai

======= 2013-04-26 01:38:17 您在来信中写道：=======

>> This call ends Monday May 6th.

= = = = = = = = = = = = = = = = = = = =

　　　　　　　　致
礼！

Shuai Gao
Associate Professor
National Engineering Lab for Next Generation Internet Interconnection Devices
Beijing Jiaotong University
Beijing, China, 100044
[email-masked]
2013-04-26

---

From: Sérgio <[email-masked]>
Date: Fri, 26 Apr 2013 10:47:49 +0100

Hi,

I support the adoption of this draft.

Regards,
Sérgio

---

From: "Seil Jeon" <[email-masked]>
Date: Fri, 26 Apr 2013 13:42:14 +0100

I think current shape of this document becomes stabilized and it is ready to
go further.
Therefore, I support the adoption of this draft.

Regards,
Seil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stig
Venaas
Sent: Thursday, April 25, 2013 6:42 PM
To: [email-masked]
Subject: [pim] Please respond! Re: draft-ietf-pim-explicit-tracking pim 2nd
wglc

Not many replies yet! We have one more week, please review this document. It
will be hard for us to make progress if we don't get any responses.

Stig

On 22.04.2013 15:29, Stig Venaas wrote:
> We did a last call for this document in February, but we got hardly 
> any responses, so it was hard for us chairs to know whether the WG 
> indeed was happy with the latest revision.
>
> We are now attempting another last call. Please respond to this so 
> that we can have some progress in the working group. We need to know 
> whether you are happy with the current version, or if you have any 
> issues that need to be addressed.
>

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Fri, 26 Apr 2013 12:42:02 +0000

Hi all,

I support the adoption of this document.

I have just two comments.

On section 6, "Compatibility with Older Version protocols" it should be convenient to include an explicit reference for the behavior to be followed for dual stack devices.

On section 8, "Security Considerations", linking with Stig's comment about the maximum amount of memberships. In my understanding, what it is explicitly impacting this document is the number of membership state registers that can be updated/created due to massive subscriptions. So I identified two issues: what to do with the subscription request from the point of view of service delivery, and what to do with the subscription request from the point of view of tracking. The latter is the one relevant for this document. So probably the device on high load could attend the subscriptions but not register the corresponding state to save resources.
Finally it is mentioned that a possible limit could be established for the amount of membership information a device could store per host. In the case that the host is acting as IGMP/MLD proxy, the number of potential membership states could be huge, so a possible indication of that could be included.

Thanks,

Best regards,

Luis

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Stig Venaas
Enviado el: jueves, 25 de abril de 2013 19:42
Para: [email-masked]
Asunto: [pim] Please respond! Re: draft-ietf-pim-explicit-tracking pim 2nd wglc

Not many replies yet! We have one more week, please review this document. It will be hard for us to make progress if we don't get any responses.

Stig

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 30 Apr 2013 13:07:32 +0900 (JST)

Hi Stig,

> The document looks good, but I see two possible issues.

Thanks for your review.

> particular if it is just a simplification. Advice is OK, but not
> strict requirements for an internal implementation detail.

I understand.
I'd replace "MAY NOT" to "may not".

> be a limit on the maximum amount of memberships at any time. I think.

I agree.
I'd change the sentence in the security section as follws.

   In order to prevent
   abuse, a router enabling the explicit tracking function may need to
   limit a total amount of membership information the router can
   store and an amount of membership information the router can store
   per host.

> members to not be tracked, or some members to not be able to join and

Whether report senders are malicious or not, the router can track
their IP addresses (of course it assumes no address spoofing here,
though).

I'd say what the router should do is rate-limiting IGMP/MLD report
transmissions per host. Do you agree on adding the following paragraph
in the security section?

   A router may rate-limit State-Change Report messages per host. When
   the router enables rate-limiting per host, the router MAY ignore
   the received State-Change Report messages to minimize the
   processing overhead or prevent DoS attacks. The rate limit is left
   to the router's implementation.

BTW, while the rate limit itself is left to the router's implementation,
is it better to specify the default timer value for the rate-limiting
function? Or it is not necessary to specify it (as it depends on the
implementation)?

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 30 Apr 2013 13:18:54 +0900 (JST)

Hi Luis,

Thanks for your review.

> On section 6, "Compatibility with Older Version protocols" it should
> be convenient to include an explicit reference for the behavior to
> be followed for dual stack devices.

Ok, I'll add rfc3376 and 3810 as the references.

> On section 8, "Security Considerations", linking with Stig's comment
> about the maximum amount of memberships. In my understanding, what
> it is explicitly impacting this document is the number of membership
> state registers that can be updated/created due to massive
> subscriptions. So I identified two issues: what to do with the
> subscription request from the point of view of service delivery, and
> what to do with the subscription request from the point of view of
> tracking. The latter is the one relevant for this document.

Exactly. This document is relevant to the latter one.

> So probably the device on high load could attend the subscriptions but
> not register the corresponding state to save resources.

Agree.

> Finally it is mentioned that a possible limit could be established
> for the amount of membership information a device could store per
> host. In the case that the host is acting as IGMP/MLD proxy, the
> number of potential membership states could be huge, so a possible
> indication of that could be included.

Well, IMO, whether an IGMP/MLD proxy is attached or not, potentially
the number of tracked member hosts can be huge in some situation.
Nevertheless, I agree on adding rfc4605 as one potential example would
be good. Thanks.

Regards,
--
Hitoshi Asaeda

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 30 Apr 2013 09:06:13 +0000

Dear Hitoshi Asaeda,

       I know I am a bit late in reviewing this draft. I was really held up with other things on my plate.

       Please find my questions/suggestions I have on this draft.

Regards,
Bharat

1. In Abstract, can we remove the usage of 'fast leave' and just keep 'shortening leave latency'. A quick google search on 'fast leave' shows that it is a known term in the context of IGMPv2 where a router does not send the group specific query and stops forwarding multicast traffic for the group on that interface. As here 'fast leave' is not referring to a similar behavior, I suggest to use 'shortening leave latency' instead.

2. In second para of section 1, can we also mention that to avoid loss of unsolicited reports, each unsolicited report is sent out at least robustness count times. After this, we can talk about queries as mentioned in this para.

3. In third par of section 1, first sentence seems complex to me.

Multicast routers are capable of periodically maintaining the
multicast membership state of downstream hosts attached to the same
link by acquiring unsolicited report messages and synchronizing the
actual membership state within the General Query timer interval
(i.e., [Query Interval] value defined in [1][2].) 

Can we reword the above to as mentioned below or something on these lines:

Multicast routers learn multicast membership state of 
downstream hosts by unsolicited report messages. Multicast
routers send periodic queries to keep the membership state
synchronized by solicited report messages.

4. As its mentioned that 'explicit tracking function does not guarantee that the membership state will always be perfectly synchronized', should the task 'Per-host accounting' using this function be really done? It may give incorrect results and to some providers, accounting is very important. Right?

5. Can you please elaborate on 'Maintaining multicast channel characteristics'? What channel characteristics we are referring here? Also how does explicit tracking function helps in this?

6. In section 3.1, I did not get the need of "If there are no more receivers maintained,
   the router may keep the membership state information with an empty
   receiver list.". Does this for any specific purpose? If so, can we add this in the draft.

7. Should not 'Membership State Information' be deleted when the corresponding multicast channel times out in the router? The router should not be maintaining this multicast channel state information forever. For example: if the last hosts who had joined a channel goes down without sending a leave request.

8. In section 3.2, in first sentence,

In accordance with [1] and [2], whenever a router receives the State-
Change Report, it sends the corresponding Group-Specific or Group-
and-Source Specific Query messages to confirm whether or not the
report sender is the sole member host.

Can we reword the above because router does not always send Group-Specific or Group-
and-Source Specific Query messages whenever it receives a State-Change Report? We can reword it to:

In accordance with [1] and [2], whenever a router receives the State-
Change Report, it might send the corresponding Group-Specific or Group-
and-Source Specific Query messages to confirm whether or not the
report sender was the sole member host.

Please also note the change of 'is' to 'was' in the last part of the sentence.

9. In section 3.2, in para 3, "This is in order to confirm whether or not the host is
   the sole member." -> "This is in order to confirm whether or not the host was
   the sole member."

10. In section 3.3, second para, what I infer from the first sentence is that router prunes the channel after LMQI and LLQI. This does not look correct. Later in the same para, last sentence correct this by mentioning LMQT and LLQT is the total time router wait after the first query is sent, to prune the channel. Can we fix the first sentence here?

11. A similar issue exist when LMQC and LLQC is explained in the above para.

12. Last para of section 3.3 tries to describe how a lower values of LMQI/LMQC then the default suggested, can shorten the leave latency. But it does not clearly articulate how explicit tracking function helps if the two parameters are configured to the lower values. Can we add some details on that here?

13. In section 4, in 3rd para, in following sentence:

The second case occurs when a router sends a specific query but does
not receive a State-Change Report from a downstream host within an
LMQT or LLQT period.

I think when a host receives specific query, it generates a current-state
report. Right?

14. As host membership protocols are unreliable, there will always be a possibility of outdated membership state as packets may get lost. I am not sure how does explicit tracking function lowers this possibility.

15. In section 4, last para seems to explain how to fix the outdated membership state that is introduced because of explicit tracking function in a router while the section header seems to suggest that explicit tracking function can lower the possibility of outdated membership state.

16. In section 5, in first para, we established that a MLD report received with unspecified source address is discarded then in second para, we mention that no membership-state information is created for such a request. So should we reword this to talk about only IGMP case here.

17. In section 6, in first para, its mentioned that explicit tracking does not work with older version of protocol. If I am not mistaken, fast/immediate leave implemented by some vendors do explicit tracking of the host. While I agree that hosts does report suppression but that happens only in case its a solicited report. First few (robustness count) unsolicited reports are usually enough to track the host.

18. In section 6, should not we talk about how the membership state information is deleted when the version is lowered and the channel is no more required.

19. If we can assume that the robustness count configured in a router truly represents the robustness of that network and if a packet is sent this many times, the intended destination will receive the packet at least once, this whole draft can be simplified a lot. There is no need to generate group or group-source specific queries even when all the hosts have left that channel. I am sure there is something I have missed because this is how fast/immediate leave is implemented for older version of protocols.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Stig Venaas [[email-masked]]
Sent: Thursday, April 25, 2013 11:12 PM
To: [email-masked]
Subject: [pim] Please respond! Re: draft-ietf-pim-explicit-tracking pim 2nd wglc

Stig

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***