Subject: Re: [pim] <draft-ietf-pim-explicit-tracking-09.txt> updated by Cindy Morgan

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 4 Jan 2014 12:23:40 -0000

All, re-sending this email in the hope of getting something more of a response than the one private email that said "Yes, why was this document ever changed from Informational to Standards Track?"

To be clear, if we leave this as it is, the document will not get published as an RFC!

We must choose from options 1, 2, and 3 (or some other option as yet undreamed of) and act. 

The ideal timeline has an action completed by Tuesday of next week (7th). Failure to get resolution by Thursday will result in the I-D being returned to the working group and the working group having to sort it out and make a new publication request later if it wants to continue.

The stuckees for resolving this are the document authors under guidance from the WG chairs and the whole WG.

Thanks,
Adrian

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 28 December 2013 19:51
> To: [email-masked]
> Cc: [email-masked]'
> Subject: RE: <draft-ietf-pim-explicit-tracking-09.txt> updated by Cindy Morgan
> 
> Authors and chairs (WG copied for information),
> 
> This document had a bit of a lumpy ride when it was in front of the IESG. A
> number of ADs said words to the effect of "What is being standardised here?
> There is nothing that affects on-wire behavior, and there are many ways that this
> function could be implemented in a router."
> 
> I tried several approaches in discussion, mainly saying that while this document
> does not tell you how to achieve interoperability, it does tell you how to not
> break interoperability. That is, this document provides a core (default) suggestion
> of how the function can be achieved in a way that will not break PIM. My
> arguments fell, however, on stony ground since the document does not say this.
> 
> Currently we have three Abstain positions and four ADs still to ballot. We need
> two more No Objection ballots to get the document through. I have put the
> document back on the agenda for the next telechat, but I think we should take
> some proactive steps. These could be any of:
> 
> 1. Downgrade to Informational and add a small piece of text explaining how this
> document describes a safe mechanism for achieving the function.
> 
> 2. Remain at Standards Track and add a more substantial piece of text explaining
> how this document ensure interoperability by describing the black-box behavior
> of an implementation and offering a safe mechanism for achieving the function
> while acknowledging that other methods of implementation exist. In effect, this
> text must say that interoperability will not be broken if the method described is
> used.
> 
> 3. Dig in our heals and say that the document is fine as it is (giving reasons!).
> 
> Your thoughts?
> Adrian
> 
> 
> > -----Original Message-----
> > From: DraftTracker Mail System [mailto:[email-masked]]
> > Sent: 19 December 2013 18:41
> > To: Adrian Farrel
> > Subject: <draft-ietf-pim-explicit-tracking-09.txt> updated by Cindy Morgan
> >
> >
> > Please DO NOT reply to this email.
> >
> > I-D: <draft-ietf-pim-explicit-tracking-09.txt>
> > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-pim-explicit-tracking/
> >
> > State changed to IESG Evaluation::AD Followup from IESG Evaluation

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sun, 05 Jan 2014 00:52:15 +0900 (JST)

Adrian,

I'm very sorry for my late response.

> This document had a bit of a lumpy ride when it was in front of the
> IESG. A number of ADs said words to the effect of "What is being
> standardised here? There is nothing that affects on-wire behavior,
> and there are many ways that this function could be implemented in a
> router."
> 
> I tried several approaches in discussion, mainly saying that while
> this document does not tell you how to achieve interoperability, it
> does tell you how to not break interoperability. That is, this
> document provides a core (default) suggestion of how the function
> can be achieved in a way that will not break PIM. My arguments fell,
> however, on stony ground since the document does not say this.

Traditional IGMP/MLD query/reply communication works well in a legacy
LAN, ethernet, but gives serious scalability issues especially in a
data center in which massive amounts of hosts connect to a logical
LAN, or wireless and mobile network environments that are resource
sensitive but a number of users attach to. These use cases are
indispensable for our current communications but were not deeply
considered when the traditional IGMP/MLD protocol suite was designed.

In fact, in the recent PIM, MBONED, and multimob WGs, there are
several drafts that have been discussed IGMP/MLD tuning and extension
for wireless/mobility support and a data center IGMP/MLD. The
objectives are how IGMP/MLD works well in a resource sensitive but
robust link condition. The explicit tracking function significantly
contributes to that situation, and hence will be necessarily their
normative reference.

It is true that the current document does not describe how it affects
on-wire behavior. It is because the on-wire behavior corresponding to
the explicit tracking function will depend on the multicast routing
protocol, e.g., PIM, not IGMP/MLD, and this document does not include
routing protocol dependent behavior. For instance, we discussed the
case in which multiple multicast routers exist on a LAN and the
querier router is not the forwarder router. In this document, we only
say the "specific query suppression", which is part of the explicit
tracking function, should be simply disabled in such case, as there
are no IGMP/MLD messages defined to synchronize the membership
information to the forwarder. This is the simplest way to avoid the
interoperability issue. Some mechanism or message to synchonize the
membership information with routers on a LAN will be defined in a
router-to-router communication; potentially with a PIM extension.

One might also say there are many ways that explicit tracking could be
implemented in a router. However, it is not so simple. For instance,
this document defines "specific query suppression". What's the effort?
For what kind of situation we need it? What are the pros and cons of
this sub function?
What the standard track document must clarify is the minimum
requirements; for the explicit tracking, what should be implemented as
the standard and what (or which (sub)functions) should be optional. If
no such definition, it's hard to make further protocol improvements
for IP multicast. And the more important thing is that we agreed on
the minimum requirements described in this document.

> Currently we have three Abstain positions and four ADs still to
> ballot. We need two more No Objection ballots to get the document
> through. I have put the document back on the agenda for the next
> telechat, but I think we should take some proactive steps. These
> could be any of:
> 
> 1. Downgrade to Informational and add a small piece of text
> explaining how this document describes a safe mechanism for
> achieving the function.
> 
> 2. Remain at Standards Track and add a more substantial piece of
> text explaining how this document ensure interoperability by
> describing the black-box behavior of an implementation and offering
> a safe mechanism for achieving the function while acknowledging that
> other methods of implementation exist. In effect, this text must say
> that interoperability will not be broken if the method described is
> used.
> 

I'd say, 4, which is "Keep this as Standard Track. If necessary, we
revise the draft and try to clarify the background why the explicit
tracking function is nowadays indispensable. We'll also add some text
(or paragraph? section?) for the interoperability, which will be
discussed with a routing protocol extension, if needed."

What do you think?

Regards,
--
Hitoshi Asaeda

---

From: Stig Venaas <[email-masked]>
Date: Mon, 06 Jan 2014 19:01:43 -0800

> We must choose from options 1, 2, and 3 (or some other option as yet undreamed of) and act.

Option 1 is downgrading to informational. The document was initially
informational, but before we started WGLC we decided to make it
standards track. There were different opinions though. I wonder if
people in the group have thoughts on standards track or informational
now.

RFC 4605 on IGMP/MLD proxying is standards track. I think in a similar
way, explicit tracking may not require different routers to
interoperate (although it may be an issue if querier and forwarder are
different routers), but it must be done right for the IGMP/MLD protocol
not to break. Here are the minutes from Atlanta where the decision to
go for PS was made.

Adrian, would you agree that the situation here is similar to 4605?

draft-ietf-pim-explicit-tracking-02
Hitoshi Asaeda
- IGMP/MLD-based explicit membership tracking function for multicast routers
Stig: We should decide on the intended status before WGLC.
Mike: WG adopted the draft because it was informational. We do not want 
to do bait-and-switch.
Stig: Status change can happen but needs good support.
(3 people have read this draft)
(3 people say it should be standard)
(0 people say it should be informational)
Sue Hares: Why do you want to go to standard? Explicit tracking has some 
very valuable debugging stuff.
Hitoshi: When other protocols want to refer to explicit tracking, they 
cannot do it as normative reference if it is informational.
Sue: Why does that matter?
Dino: The subject matter is IGMP/MLD explicit tracking. If it's 
compelling enough, why go halfway? Make it full standard.
Adrian Farrell: Decide the track based on contents, not based on who 
wants to refer to it. If this is an implementable protocol, make it 
standard track.
Dino: Explicit tracking is an importnat feature that we need to have. We 
should go full steam ahead (full standard).
Sue: Yes, it should go for standard.
Toerless: Default preference should be IGMPv3 + explicit tracking.
Dino: Maybe we should do IGMPv4.
Toerless: There once was IGMPv3 lite.
(6 people want it to be standard)
(0 people want it to be informational)
(Will be asked on the list. If the people that wanted it adopted as 
informational don't speak up, then it will change to standard.)

One argument is references, but I don't think that in itself should
make us go for PS. But there are other arguments.

Stig

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Jan 2014 11:21:19 -0000

Hi Stig,

Thanks or this explanation. I can appreciate the points you make. Indeed, one of
the things I tried to explain to the IESG was that getting this wrong could
break interoperability. 

The counter argument made to me was that there are many ways to achieve the
function and that (as far as the ADs knew) none of the existing implementations
(some of which are quite old) actually does what this draft describes. Maybe the
issue here is that there is a difference between:
- black-box behavior
- principles of operation of the function
- sample (example) mechanism.

OK. It seems that there is history in the WG for considering this as Standards
Track so we need to construct a message to the IESG about why this is
reasonable.

Anyone want to take a first cut at that or shall I?

Adrian

> From: Stig Venaas [mailto:[email-masked]]
> Sent: 07 January 2014 03:02
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [pim] <draft-ietf-pim-explicit-tracking-09.txt> updated by Cindy
> Morgan
> 
> > All, re-sending this email in the hope of getting something more of a
response
> than the one private email that said "Yes, why was this document ever changed
> from Informational to Standards Track?"
> >
> > To be clear, if we leave this as it is, the document will not get published
as an
> RFC!
> > The ideal timeline has an action completed by Tuesday of next week (7th).
> Failure to get resolution by Thursday will result in the I-D being returned to
the
> working group and the working group having to sort it out and make a new
> publication request later if it wants to continue.
> >
> >> There is nothing that affects on-wire behavior, and there are many ways
that
> this
> >> text must say that interoperability will not be broken if the method
described
> is

---

From: Stig Venaas <[email-masked]>
Date: Tue, 07 Jan 2014 10:27:19 -0800

Hi

> (some of which are quite old) actually does what this draft describes. Maybe the

Yes, there are multiple ways of doing this. I think existing
implementations are close to what the draft specifies (with
some variations and not all that is mentioned here).

This draft started out as informational, and my understanding of
this was that we view this as important functionality and that it
was worth describing how to implement it in a good way. That sounds
like a typical informational draft to me.

The main reasons it was changed to standards track are roughly:

1. It is a very useful feature and widely implemented and deployed.

2. Interoperability. IGMP/MLD may break if not implemented correctly.
    There have been examples of this done wrong I think (although I
    cannot remember for sure now. There have been issues with various
    snooping/proxy implementations where explicit tracking is one part).

3. There are other documents that are/were planned for standards track
    referencing it.

I think 1 was the main argument brought up in the meeting (see the
minutes included below), but IMO 2 is the strongest argument for PS.
3 is not that strong as it is still possible to reference it (just more
difficult).

> - sample (example) mechanism.

I guess the concern here might be that existing implementations might
work fine, but not necessarily follow this draft, and that there are
several valid ways to implement it. But a lot of what is described in
the document is not required, it talks about several ways things can
be done. It only uses requirements language in a few places where I
think it is really needed. Note that there were key people from
different vendors stating that they wanted it standards track.

> Track so we need to construct a message to the IESG about why this is

I mentioned RFC 4605 here, which is PS and came out of magma with Brian
as one of the authors. There are similarities between that document and
this, and both have some normative language required to not break the
IGMP/MLD protocols.

Happy for input from others in the group, but I believe the WG wants it
to be standards track.

> Anyone want to take a first cut at that or shall I?

I think it would be helpful if you can do at least a very rough first
cut, giving us an idea what points are worth bringing up.

Stig

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Jan 2014 19:53:41 -0000

Thanks again Stig,

I'm going to play devil's advocate here because I know that various ADs will ask
the hard questions. I also know that you are trying to represent what you heard
in the WG (so we are both arguing representative corners rather than our own
positions - perhaps we could get jobs playing lawyers on TV).

> > Thanks or this explanation. I can appreciate the points you make. Indeed,
> > one of the things I tried to explain to the IESG was that getting this wrong
> > could break interoperability.
> >
> > The counter argument made to me was that there are many ways to
> > achieve the function and that (as far as the ADs knew) none of the
> > existing implementations (some of which are quite old) actually does
> > what this draft describes. Maybe the
> 

Hmmm. OK.
So we have "Here is a document that describes something similar to what some
implementations do to achieve this function."

> like a typical informational draft to me.

Yes.
So let's work though the reasoning below before I say "I agree. Let's make this
Informational and be done with it."

> 1. It is a very useful feature and widely implemented and deployed.

That is without doubt.
But that is not a reason for Standards Track especially since the document
doesn't describe precisely what is implemented and deployed.

>     snooping/proxy implementations where explicit tracking is one part).

I think this is the strongest claim.
There are some uses of 2119 language (not many) in the I-D, and it is my take
that ignoring those would break interop.
We could improve the standing as Standards Track if we made a stronger case for
this I-D setting guidelines that implementations of this function must follow.

> 3. There are other documents that are/were planned for standards track

That is pretty poor as a reason.
Normative references can and are made to Informational RFCs from Standards Track
documents.

> 3 is not that strong as it is still possible to reference it (just more

OK.
We reached the same conclusions.

> cut, giving us an idea what points are worth bringing up.

OK. That will follow. But I think it is also going to result in some reworking
of the draft to make it clear what is necessary/advised to avoid breaking stuff,
and what is a descriptive example of how the function could be achieved within
that guidance.

Cheers,
Adrian