Subject: [pim] Adoption of draft-asaeda-mboned-explicit-tracking-02 as a pim wg doc

From: Stig Venaas <[email-masked]>
Date: Wed, 07 Sep 2011 10:49:00 -0700

At the pim wg meeting in Quebec we discussed adopting this
document. However, only a few people had opinions on this.
According to the minutes, there were 5 in favor, 1 against.

To decide whether to adopt this draft as a pim wg document,
we need your input here on the list.

If you are in favor or against adopting this draft, please
send an email to the pim wg list with your opinion. Please
do so by Wednesday September 21st.

Any other comments you may have on the draft are of course
also welcome.

The draft is available at
http://tools.ietf.org/html/draft-asaeda-mboned-explicit-tracking-02

Note that this was originally considered as an mboned wg
item, but after some discussion with mboned/pim WG chairs and IESG,
it was found to be more appropriate for the pim wg, and our new
charter allows us to work on this if we should decide so.

Also note that I sent an email to the list in May asking whether
we should adopt it if the new charter would allow us. There were
two responses to that, both in favor of adoption. We would however
like to hear from more of you before making a decision.

Stig

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 11:38:56 +0200

Hi,

I do support the adoption as WG document!

  Regards

     Nic

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Stig Venaas
Gesendet: Mittwoch, 7. September 2011 19:49
An: [email-masked]
Cc: Mike McBride
Betreff: [pim] Adoption of draft-asaeda-mboned-explicit-tracking-02 as a pim wg doc

Stig
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Stig Venaas <[email-masked]>
Date: Fri, 16 Sep 2011 11:07:37 -0700

> do so by Wednesday September 21st.

For this draft to be adopted, we need to see more people
supporting it. Please direct any responses to the list.

Stig

---

From: Bill Atwood <[email-masked]>
Date: Fri, 16 Sep 2011 14:12:42 -0400

Yes.

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email: [email-masked]
1455 de Maisonneuve Blvd. West    http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Achmad Husni Thamrin <[email-masked]>
Date: Tue, 20 Sep 2011 19:41:51 +0900

Hi,

This is Husni of AI3.
I vote Yes.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 20 Sep 2011 10:29:57 -0400

Given that:

1. current IGMPv3/MLD protocol already allows an implementation to do explicit tracking
2. explicit tracking itself is really an internal behavior
3. many router vendors already implement explicit tracking
4. no problems of current explicit tracking implementations have been reported by operators or documented by this particular draft

Before it is accepted I'd like to see specific evidence that this work is really needed.

Thanks.
Jeffrey 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stig Venaas
> Sent: Wednesday, September 07, 2011 1:49 PM
> To: [email-masked]
> Cc: Mike McBride
> Subject: [pim] Adoption of 
> draft-asaeda-mboned-explicit-tracking-02 as a pim wg doc
>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 21 Sep 2011 01:56:51 +0900 (JST)

Hi Jeffrey,

> 1. current IGMPv3/MLD protocol already allows an implementation to

Right. But rfc3376 and 3810 very briefly describe the explicit
tracking for accounting. First leave is also mentioned as the possible
reason to enable the explicit tracking but no detail desctiption in
these documents. And one of the impotrant points lacked in them is
that there is no specification how routers enabling explicit tracking
behave when they receive state change reports. 

> 3. many router vendors already implement explicit tracking

It is a positive situation.
We are glad to hear vendors' implementation specs and take them into
account.

> 4. no problems of current explicit tracking implementations have
> been reported by operators or documented by this particular draft

If this document can become the reference, it would be useful for many
situations.
For instance, multimob WG has been discussing multicast support for
mobility and the explicit tracking function is somehow required for it
in resource sensitive wireless link. It would refer this document as
the reference of the explicit tracking, because rfc3376 and 3810 do
not describe its complete specification.

> Before it is accepted I'd like to see specific evidence that this

What do you think about above thoughts?
I'd like to hear vendors' opinion about this draft and appreciate you
would take a look at the draft for more discussion.

Regards,
--
Hitoshi Asaeda

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 20 Sep 2011 13:40:45 -0400

Hitoshi,

Wrt multimob WG's need of referring to an explicit tracking spec, I'll defer to the PIM WG chairs/group.

Whether it is for accounting or for fast leave (I know one implementation that is doing both), as long as an implementation can achieve the result w/o causing interop issue, lack of details is not a problem. It's an internal implementation thing and there is no need for a standard.

I did quickly read the draft, and I don't have a problem with the content. I would like to see more convincing needs, though.

Thanks.

Jeffrey

> From: Hitoshi Asaeda [mailto:[email-masked]] 
> Sent: Tuesday, September 20, 2011 12:57 PM
> To: Jeffrey (Zhaohui) Zhang
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [pim] Adoption of

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 21 Sep 2011 15:49:06 +0900 (JST)

Jeffrey,

> I'll defer to the PIM WG chairs/group.

Agree.

> Whether it is for accounting or for fast leave (I know one
> implementation that is doing both), as long as an implementation can
> achieve the result w/o causing interop issue, lack of details is not
> a problem. It's an internal implementation thing and there is no
> need for a standard.

Your comment is reasonable, while it is better to have the clear
specification for the future implementation.

> I did quickly read the draft, and I don't have a problem with the
> content. I would like to see more convincing needs, though.

Thanks.
I think one necessary discussion is regarding the target of this draft
whether the proposed standard or BCP (or experimental?).

Regards,
--
Hitoshi Asaeda

---

From: Stig Venaas <[email-masked]>
Date: Wed, 21 Sep 2011 10:43:00 -0700

> whether the proposed standard or BCP (or experimental?).

Yes, I that is a good discussion to have. It would be good to hear
what the WG thinks. In addition to those, Informational is also a
possibility.

What is your preference Hitoshi, and why?

I would say an important decision is whether the draft simply describes
one or several ways it is implemented today. Or whether it would give
recommendations or specify a certain behavior.

What do you in the WG think? If you have been supporting it, or not,
please also let us know your thoughts on what you want from the
document, or why you did not support it.

Stig

---

From: Brian Haberman <[email-masked]>
Date: Thu, 22 Sep 2011 13:24:03 -0400

Hitoshi,

> specification for the future implementation.

I view Jeffrey's comment differently.  If the tracking aspect is
completely internal to a router:

- There are no interoperability issues
- The tracking function is specific to the implementation

The purpose of an IETF standard is to ensure that two separate
implementations can inter-operate.  In this case, there is no
interaction of tracking features on two different routers so there is no
need for a protocol specification.

Regards,
Brian

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 22 Sep 2011 15:36:27 -0400

Brian said:

> interaction of tracking features on two different routers so 
> there is no need for a protocol specification.

Exactly.

To expand on the possible categories for this document - if the spec is needed for clarification purpose:

1. standard track - no; because there is nothing to standardize.
2. experimental - no; it is not for "some research or development effort", and more importantly it's been implemented for quite some time w/o a specification.
3. BCP - closer, but does not seem to fit quite nicely; are we documenting best current practices?
4. informational - seems to be the best fit for now. Then, should it be a WG item or Independent submission?

Thanks.

Jeffrey

> Behalf Of Brian Haberman
> Sent: Thursday, September 22, 2011 1:24 PM
> To: [email-masked]

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 23 Sep 2011 16:07:42 +0900 (JST)

>> there is no need for a protocol specification.

It is true that there is no interop issue for this function.
However, the explicit tracking is already (but very briefly) mentioned
in the standard protocol specs (rfc3376 and 3810), and it would be
assumed that the function is in part of the standard protocols.
The problem is that there is no specification of this function, while
this function changes the protocol behavior.

Moreover, in wireless and mobility environment, the explicit tracking
would be the necessary function (i.e. SHOULD) to support multicast.
According to this condition, informational is weak assumption.
I would say BCP is the possibility if proposed standard does not fit
to its definition, but IMO, PS works well.

BTW, to my knowledge of rfc2026, I haven't thought the proposed standard
should be applicable only for the protocols in which interop issue
exists, and hence I thought this function could be in the standard track.

Thank you for your comments.
Regards,
--
Hitoshi Asaeda

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 23 Sep 2011 09:34:14 -0400

Hitoshi, 

> Sent: Friday, September 23, 2011 3:08 AM
> Cc: [email-masked]; [email-masked]

RFC 3376 merely says in the appendix:

   o Hosts no longer perform suppression, to simplify implementations
     and permit explicit membership tracking.

I read it as explicit tracking is not really part of the protocol/standard, though a vendor could implement on its own w/o depedning on another router's behavior (as long as suppression is no longer performed, which is alreay required by the protocol).

I wonder if there was a discussion on this already when IGMPv3/MLD went through the process? Why is there no detail in the spec the first place? Is it because it was already agreed that it would not need standardization?

> to its definition, but IMO, PS works well.

I agree that wireless/mobility environment it is BCP to use explicit tracking, but I think all we need is a BCP document from multimob WG stating that explicit tracking is required/recommended. How it is implemented is an internal thing that does not need standardization. Some parameters in your explicit tracking draft could be part of the igmp/mld tuning spec.

> exists, and hence I thought this function could be in the 

Though we used the "interop" wording, the real thing beind it is that an internal implmentation thing does not need to be standardized (which we did talk about). As an opposite example, other things specified in IGMPv3/MLD need to be in the standard otherwise routers will not be able to work together (interop).

Jeffrey

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 26 Sep 2011 15:40:11 +0900 (JST)

> I read it as explicit tracking is not really part of the
> protocol/standard, though a vendor could implement on its own w/o
> depedning on another router's behavior (as long as suppression is no
> longer performed, which is alreay required by the protocol).

So, what is the spec of your explicit tracking function? When or in
what situation does a router turn on that function? When it turns on
the function, how does the router change its IGMP/MLD protocol
behavior? Describing all the clarifications is useful for the future
implementations.

> I agree that wireless/mobility environment it is BCP to use explicit
> tracking, but I think all we need is a BCP document from multimob
> WG stating that explicit tracking is required/recommended. How it
> is implemented is an internal thing that does not need
> standardization. Some parameters in your explicit tracking draft
> could be part of the igmp/mld tuning spec.

Ok, so you agree on BCP for this draft? If the WG decides it should be
BCP, I'll follow the decision.

BTW, the tuning draft does not require to change the protocol
implementations. It aims to become a guideline how IGMP/MLD timer or
other values could be tuned in resource sensitive wireless links or
mobility env. The explicit tracking function is an implementation that
changes the protocol behavior, e.g., whether the router sends Specific
Queries or not in a proper condition. We cannot mix the semantics in a
single draft.

> Though we used the "interop" wording, the real thing beind it is
> that an internal implmentation thing does not need to be
> standardized (which we did talk about).

I don't know if this is true or not.
But again if the WG decides it should be BCP, I'll follow the decision.

Regards,
--
Hitoshi Asaeda

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 26 Sep 2011 09:33:16 -0400

Hitoshi,

> BCP, I'll follow the decision.

My personal position has been clear. Of course, it is up to the WG.

1. Explicit Tracking is a useful feature. There could be a BCP document from multimob WG stating (among other things) that Explicit Tracking is recommended. This takes care of "why" part.

2. For the details how it is implemented, an informational document is enough. This takes care of "how" part.

Jeffrey

> Sent: Monday, September 26, 2011 2:40 AM
> Cc: [email-masked]

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 28 Sep 2011 11:57:50 -0700

I agree with Brian and Jeffrey here.  The fact that implementations with 
explicit-tracking have existed for years and interop just fine,
along with the risk that unnecessary over-specification can sometimes 
reduce the flexibility of implementations, it is not clear to me this is a 
function that needs to be specified.  If it is adopted, though, I suppose 
informational is a reasonable choice.

-Lenny

On Mon, 26 Sep 2011, Jeffrey (Zhaohui) Zhang wrote:

-) Hitoshi,
-) 
-) > Ok, so you agree on BCP for this draft? If the WG decides it should be
-) > BCP, I'll follow the decision.
-) 
-) My personal position has been clear. Of course, it is up to the WG.
-) 
-) 1. Explicit Tracking is a useful feature. There could be a BCP document from multimob WG stating (among other things) that Explicit Tracking is recommended. This takes care of "why" part.
-) 
-) 2. For the details how it is implemented, an informational document is enough. This takes care of "how" part.
-) 
-) Jeffrey
-) 
-) > -----Original Message-----
-) > From: Hitoshi Asaeda [mailto:[email-masked]] 
-) > Sent: Monday, September 26, 2011 2:40 AM
-) > To: Jeffrey (Zhaohui) Zhang
-) > Cc: [email-masked]
-) > Subject: Re: [pim] Adoption of 
-) > draft-asaeda-mboned-explicit-tracking-02 as a pim wg doc
-) > 
-) > > RFC 3376 merely says in the appendix:
-) > > 
-) > >    o Hosts no longer perform suppression, to simplify 
-) > implementations
-) > >      and permit explicit membership tracking.
-) > > 
-) > > I read it as explicit tracking is not really part of the
-) > > protocol/standard, though a vendor could implement on its own w/o
-) > > depedning on another router's behavior (as long as suppression is no
-) > > longer performed, which is alreay required by the protocol).
-) > 
-) > So, what is the spec of your explicit tracking function? When or in
-) > what situation does a router turn on that function? When it turns on
-) > the function, how does the router change its IGMP/MLD protocol
-) > behavior? Describing all the clarifications is useful for the future
-) > implementations.
-) > 
-) > >> Moreover, in wireless and mobility environment, the 
-) > explicit tracking
-) > >> would be the necessary function (i.e. SHOULD) to support multicast.
-) > >> According to this condition, informational is weak assumption.
-) > >> I would say BCP is the possibility if proposed standard 
-) > does not fit
-) > >> to its definition, but IMO, PS works well.
-) > > 
-) > > I agree that wireless/mobility environment it is BCP to use explicit
-) > > tracking, but I think all we need is a BCP document from multimob
-) > > WG stating that explicit tracking is required/recommended. How it
-) > > is implemented is an internal thing that does not need
-) > > standardization. Some parameters in your explicit tracking draft
-) > > could be part of the igmp/mld tuning spec.
-) > 
-) > Ok, so you agree on BCP for this draft? If the WG decides it should be
-) > BCP, I'll follow the decision.
-) > 
-) > BTW, the tuning draft does not require to change the protocol
-) > implementations. It aims to become a guideline how IGMP/MLD timer or
-) > other values could be tuned in resource sensitive wireless links or
-) > mobility env. The explicit tracking function is an implementation that
-) > changes the protocol behavior, e.g., whether the router sends Specific
-) > Queries or not in a proper condition. We cannot mix the semantics in a
-) > single draft.
-) > 
-) > >> BTW, to my knowledge of rfc2026, I haven't thought the 
-) > >> proposed standard
-) > >> should be applicable only for the protocols in which interop issue
-) > >> exists, and hence I thought this function could be in the 
-) > >> standard track.
-) > > 
-) > > Though we used the "interop" wording, the real thing beind it is
-) > > that an internal implmentation thing does not need to be
-) > > standardized (which we did talk about).
-) > 
-) > I don't know if this is true or not.
-) > But again if the WG decides it should be BCP, I'll follow the 
-) > decision.
-) > 
-) > Regards,
-) > --
-) > Hitoshi Asaeda
-) > 
-) _______________________________________________
-) pim mailing list
-) [email-masked]
-) https://www.ietf.org/mailman/listinfo/pim
-)