Subject: Re: [pim] AD Review of draft-ietf-pim-explicit-tracking

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 15 Jun 2015 19:41:47 +0000

On 6/1/15, 1:44 AM, "Hitoshi Asaeda" <[email-masked]> wrote:

Hitoshi:

Hi!

>> I started looking at this document, and being that it has already been
>>to the IESG, it worries me that not much seems to have changed to
>>address the concerns from the initial visit [1].  At the time there were
>>3 Abstains basically saying that there is really nothing here to
>>standardize.   How are we addressing those concerns?
>
>The discussions given by the last IESG comments were addressed by the
>last revision (-10), because the last IESG review was done with -09.
>Therefore, could you refer to the diffs between the -09 version and -10
>version 
>(https://tools.ietf.org/rfcdiff?url2=draft-ietf-pim-explicit-tracking-10.t
>xt)?
>If there are still some concerns to address, could you kindly point them
>out? I¹ll try to address them and ask whether my thought is feasible or
>not to the mailing list.

Specifically, the concerns that caused several ADs to Abstain (from [1]):

===
Brian Haberman 

I have been involved in the discussion of this document for several years.
 For
the most part, this spec really describes internal implementation details
that
are needed to support explicit tracking.  In other words, it is unclear
where
in this spec there is normative text related to interoperability between
two
(or more) multicast routers.  I don't see a need for this spec even though
there are multiple (different!) implementations of the basic functionality.
===
Barry Leiba 

>From the shepherd writeup:
"There are many implementations of explicit tracking already. They
are not based on this document though, but they should be close
in functionality to what is in this document."

I have a two-part question: (1) Do those implementations interoperate with
each
other and with what's specified in this document, and (2) are those
implementations likely to be changed to match what's specified in this
document, and what would is mean to do so?
===
Benoit Claise

I'm with Brian (and Joel) here: how could two implementations
inter-operate?
===

A couple of rfc2119 keywords were added, but the question of
interoperability remains.

In fact, in Section 9 (Interoperability) you wrote:

. . .
   document.  Yet, the explicit tracking function does not change on-
   wire behavior, and the function or mechanisms described in this
   document do not break the interoperability between the existing
   implementations and the implementation based on this specification.

The above text seems to say to me that it doesn¹t matter how you implement
this function.  Which takes us to: why should this be a standards track
document if it doesn¹t specify a clear way to determine interoperability
*and* existing implementations don¹t follow it?

I fail to see how it addresses the previous Abstain comments.  In fact I
would probably have the same concerns (specially given Section 9) if it
was put up for IESG review.

Thanks!

Alvaro.

>> 
>> [1] 
>>https://datatracker.ietf.org/doc/draft-ietf-pim-explicit-tracking/ballot/
>> [2] http://www.ietf.org/mail-archive/web/pim/current/msg02883.html

---

From: Stig Venaas <[email-masked]>
Date: Mon, 15 Jun 2015 14:13:05 -0700

The reason it is on standards track and some normative language is
that certain things must be done in the correct way in order not to
break the protocol behavior. It is not all internal implementation
details. Hitoshi can explain it more in detail.

Stig

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 16 Jun 2015 16:36:43 +0900

Hi Alvaro,

Thank you for your careful review.

The explicit tracking function does not give any on-wire format change; however if a router having an incorrect explicit tracking implementation becomes an IGMP/MLD querier, it may create wrong membership state and affect other routers’ membership states. This is "another interoperability problem", and it is the reason to make it proposed standard to provide the information for the correct router implementations.

Precisely, this document describes that the explicit tracking function enables "specific query suppression (Sect.4)" and "the standard timer or counter value configuration (Sect.5)”.

Specific query suppression contributes to saving network resources and shortening leave latency (as described in 2nd and 3rd paragraphs in Sect.4). By configuring the standard timer and query count values, the router can shorten the leave latencies as well (as described in 3rd and 4th paragraphs in Sect.5).

However, as described in 4th paragraph in Sect.4 and 5th paragraph in Sect.5, there is a risk of wrong membership state (described in Sect.6) created by this function. Wrong membership state may be caused by the wrong implementations, operations, or configurations, and it affects not only the internal router behavior but also other routers behaviors on the same LAN.

We should avoid such "another interoperability problem”. This document contributes to it, and this is one of other reasons why this specification should be categorized as PS.

Please see my comments below.

> there are multiple (different!) implementations of the basic functionality.

The aim of this document is to avoid the situation in which the wrong implementation or configuration gives wrong membership states internally and externally.
There are no new messages defined in this document and hence no interoperability problem for "on-wire behavior". However, if a router having an incorrect explicit tracking implementation or configuration becomes an IGMP/MLD querier, the membership states on other routers on the same LAN may be also outdated (or corrupted) as these routers cannot update their membership state correctly with the lower number of queries. In this case, forwarding routers on the LAN may not operate correctly (e.g., an active member is not in the tracked membership record and hence routing path is pruned, or an inactive member is in the tracked membership record and hence unneeded routing path is not pruned and unneeded data is forwarded to the LAN for a while).

> document, and what would is mean to do so?

According to the discussions in the previous working group meetings, most (or all?) of the current (existing) implementations seemed to be with the basic implementation described in this document. (The basic implementation means no “specific query suppression with robust link state” implementation (described in 3rd paragraph in Sect.4).)

I’m not sure whether all the current implementations are correctly implemented or not. If not, the implementation must be correctly implemented based on this document. However, if the router is only with the basic function, the risk of wrong membership state that causes “another interoperability problem” mentioned above would be quite low.

In fact, specific query suppression with robust link state is powerful for reducing network resources and shortening leave latency, but requires special attention. This is the key function that may cause the interoperability problem and most existing implementations do not have it. Therefore, as Sect.4 says, “specific query suppression with robust link state” implementation is not mandatory (“MAY”).

> I'm with Brian (and Joel) here: how could two implementations

Correct implementation based on this specification does not give any interoperability problem with other routers on a LAN. However, although there is no on-wire behavior change, in particular a router with incorrect "specific query suppression with robust link state" implementation gives "another interoperability problems" as mentioned above.

> *and* existing implementations don¹t follow it?

Is this question answered above?

> was put up for IESG review.

Should Sect.9 include the information of the potential risk described in Sect.6 and mention it is another interoperability problem and addressed by correct implementation specified in this document?

>>> [2] http://www.ietf.org/mail-archive/web/pim/current/msg02883.html

If you have more concern, please ask us again.
If we still miss some descriptions, I’d try to make them clear in the next revision.

Thanks!

Regards,
--
Hitoshi Asaeda