[MBONED] Interim meeting notes

[Tom Taylor <[e-mail]>]

These are my notes from the interim meeting held on March 1. Thanks to 
Sue Hares for also taking notes and passing them on to me.

Introduction
============

An interim meeting of the MBONED Working Group was held on March 1, 
2012, from 10:00 to 12:00 am EST . The MBONED Chairs, Leonard Giuliano 
<[e-mail]> and Greg Shepherd <[e-mail]>, presided. The 
NOTE WELL may have been displayed, but was not read out. A list of 
attendees and a URL pointing to a recordingt of the meeting have been 
made available in separate messages to the MBONED list.

The agenda suggested by Tina Tsou <[e-mail]> in an 
E-mail to the MBONED list on Wednesday, Feb 29, 2012 at 2:38 AM EST was 
accepted.

Lenny Giuliano introduced the first meeting topic, the work item 
discussion. He noted that feedback from the MULTRANS BOF was that the 
list of topics had to be narrowed. This imperative was reflected in the 
brevity of the Eubanks overview draft compared with the Jaclee problem 
statement.

He asked for comments from the floor before turning over the meeting 
over to Stig Venaas <[e-mail]>. There were none.

Work Item Presentation and Discussion
=====================================

Stig spoke to a presentation (attached to this E-mail) on the work items 
to be accomplished. The four areas of work presented were the overview 
document, multicast address translation, address acquisition, and 
specification of the adaptation function (AF).

Chart 3: Overview Document
--------------------------
No comments.

Chart 4: Multicast Address Translation
--------------------------------------
Lenny Giuliano provided a brief status report. 
Draft-ietf-mboned-64-multicast-address-format has passed WGLC and has 
been forwarded to the V6OPS and 6MAN Working Groups for comments. 
Assuming all goes well, a request for publication should be issued soon.

There was no discussion of whether this draft satisfied all requirements 
for multicast address translation.

Chart 5: Address Acquisition
----------------------------
In response to the question at the bottom of the chart, Stig Venaas 
expressed his belief that the IETF could indeed contribute to the 
resolution of the problem.

The chart provoked a number of comments from Dave Thaler 
<[e-mail]>. He found the (unmentioned) transport protocol 
for delivery of the electronic program guide (EPG) more interesting that 
the encoding of the content. How does the provider ensure that the right 
person gets the right guide content? He wondered if the IETF could work 
on a standard distribution protocol. Aside from that, he wanted to see 
an analysis that would answer the question of whether development of an 
application level gateway (ALG) for EPG translation would be worthwhile.

One of the key issues coming out in subsequent discussion was to what 
extent providers currently use proprietary rather than standardized 
solutions. Another key question is whether there is a requirement that 
there be no change to the receiver.

[Note: discussion of these issues was resumed at a later point. See below.]

Chart 6: Adaptation Function Specification
------------------------------------------
This chart set off a discussion of encapsulation. Ron Bonica 
<[e-mail]> asked whether encapsulation was already solved 
with the work on Automatic Multicast Tunneling (AMT) 
(draft-ietf-mboned-auto-multicast). Toerless Eckert <eckert at 
cisco.com> noted that AMT had limits in scalability and could not handle 
the necessary fanout. Ron asked whether ASM was a requirement, and was 
told that feedback indicated that it was needed. Toerless mentioned a 
6over4 solution by Carpenter and Zheng, encapsulating IPv6 multicast in 
IPv4 multicast. Ron questioned whether, given that we are dealing with a 
transitional situation, it was worthwhile developing a solution for 
encapsulation of multicast. He proposed that we just do encapsulation of 
multicast in unicast, then see if the market demands a more 
sophisticated solution.

Further discussion revolved around the need to look at real scenarios, 
define use cases, and determine the true requirements. Stig Venaas and 
Yiu Lee <[e-mail]> described current work in Softwires, 
of which Ron was unaware. Draft-ietf-softwire-dslite-multicast covers 
IPv4 to IPv4 over an intervening IPv6 network, while 
draft-ietf-softwire-mesh-multicast looks at transport of multicast over 
a full mesh. [Some of this actually occured later, but is reported here.]

Charts 7-8: Adaptation Function Specification (cont'd)
------------------------------------------------------
No comments.

Chart 9: Adaptation Function Specification (cont'd)
---------------------------------------------------
The question on the chart was whether besides the detailed IGMP/MLD and 
PIM translation specifications we also needed a high-level AF 
specification to pull everything together. Dave Thaler suggested that 
the framework document produced by Behave (RFC 6144) be used as a 
precedent. This document provided guidance for the detailed work that 
followed. Ron Bonica asked if we were talking about an overview document 
and a separate AF specification. Yiu Lee noted that a multicast 
framework (draft-venaas-behave-v4v6mc-framework) had already been 
posted. Stig Venaas, the author, said it would have to be reworked 
because our ideas had changed.

The general conclusion at this point was that we do need a framework 
document. However, a further conclusion was that the overview document 
could ultimately fulfill this role. This would leave us with a two-level 
hierarchy: the detailed specifications such as the IGMP/MLD and the 
PIM-to-PIM translators, and the overview document to motivate and tie 
them together.

Dave Thaler asked if people currently deploy reliable multicast 
protocols, making transport part of the transition problem. Lenny 
Giuliano said that would be out of scope, but Dave argued that it could 
be required for a deployable solution. Yiu Lee said that there was some 
use of such protocols for pre-provisioning of Electronic Program Guides. 
Dave said, besides transport, there could be other gaps, such as RADIUS 
or security. Someone mentioned that RTCP is sent multicast as well as 
unicast in some applications, so that has to be investigated. [Section 
2.1 of RFC 3550 provides an example.]

At this point, Ron Bonica questioned whether we might be facing too 
large a problem, particularly if translation at higher protocol layers 
is required. We need a complete picture before we go forward with this work.

Yiu Lee pointed out that there were already drafts in Behave giving 
requirements. As for distribution of the EPG, every operator has their 
own solution. The only common agreement is to use multicast for 
distribution of broadcast content.

Someone else expressed the opinion that we have some problems that we 
know about and can work on now. We can work on others later.

Ron stated that the key question is whether we have a deployable 
solution if the problems described in draft-eubanks are solved. The 
question is whether enough other things are needed that the scope is 
intractable. Speaking as an individual contributor, he was of the 
opinion that the only thing we should work on now is the overview 
document. We shouldn't waste our resources on other work until we 
determine that the problem is tractable.

Tina Tsou asked if we could come to a conclusion on the work items. 
Respondents suggested that we don't have to solve everything at once. 
The key need is to identify which pieces need standardization, and which 
others should be left to the operators to solve individually. At this 
point Ron looked for an operator to identify gaps in what we had 
identified already. Yiu Lee volunteered to canvas his own and other 
operator organizations and bring back the needed information. Ron 
repeated that we should not do further work until the full scope is 
clear. Either Yiu reports back a small list of additional pieces to a 
deployable solution, or the effort is too large and everything should 
stop. Yiu will be recruiting help from other providers.

Ron now asked whether there was anything worth still pursuing while we 
wait for Yiu to report back. Tina Tsou suggested that we might as well 
progress the address translation and IGMP/MLD drafts, and Ron agreed. 
Stig added the PIM-to-PIM translation work to that list, but worried 
that we do not have the non-IPTV requirements that might affect that work.

Yiu Lee asked whether work on the Softwires drafts m,entioned above 
would be affected by these decisions. They basically duplicate work 
being contemplated here. Ron said the basic idea was for MBONED to put 
bounds on the work to be done, then farm it out to other Working Groups 
as required. There was some discussion of the current status of BEHAVE 
as a target of some of the work. Ron's impression was that BEHAVE is 
being closed down, and any outstanding work items will be given either 
to other existing Working Groups or to a new one.

Coming back to the agenda, Ron summarized by saying that the overview 
document appears to have gaps. Tina Tsou asked if the IGMP/MLD draft 
would be a Working Group draft. Stig Venaas said that draft and PIM 
translation should be resubmitted to the PIM Working Group. However, it 
is too soon to make the IGMP/MLD draft a Working Group document, until 
the requirements are fully fleshed out.

Tina asked if address acquisition would stay in MBONED. Stig said it 
could stay there for now. Yiu Lee questioned whether the problem could 
be solved. Again there is the question: can the receiver change, or is 
it a requirement to leave it unchanged? The key question, given the 
proprietary solutions in use now, is whether an IETF solution would be 
adopted. Mohamed Boucadair <[e-mail]> expressed the 
view that changing the receiver would be a cleaner solution. There was 
discussion of whether Set Top Box (STB) updates required a truck roll or 
could be done remotely. Yiu Lee pointed out that there are different 
arrrangements for STBs, and no single answer.

Baseline Overview Document
==========================

Ron turned to the topic of the baseline overview document. Was it 
acceptable to Yiu to build on draft-eubanks? Yiu agreed. (He will be 
added to the list of authors.) Ron asked the meeting at large whether 
this was acceptable. Dave Thaler noted that there is stuff missing from 
from draft-eubanks. draft-jaclee has more information, but he was not 
sure which was the better starting point. Yiu Lee said he would look to 
see if the documents could be merged.

Ron said that the action would be to take the IPTV-related material from 
draft-jaclee and put it into draft-eubanks. Yiu should also add his new 
material there. We could call it a framework later after the AF 
high-level design text had been added. The more detailed documents such 
as the IGMP/MLD draft would be separate. It is too early to incorporate 
the AF specification now, but individuals can start on it now as a 
separate document and add it in later. It should use informative 
language. Dave Thaler suggested we use RFC 6144 as a model.

The question was raised, whether we agree that IPTV is the only use 
case. This was confirmed.

There was a brief discussion on ASM. The requirement for ASM is present 
in draft-eubanks but is unjustified by preceding text. It appears that 
it is needed because operators use it currently in IPv4 networks. SSM 
represents a simplification (as a subset of ASM) in the network core, 
but would require an upgrade at the network edge. Stig Venaas raised the 
possibility of work on interworking IPv4 ASM with IPv6 SSM.

Tina Tsou, as the one co-author common to draft-jaclee and 
draft-eubanks, was given the task of convening a meeting of authors and 
other interested parties to work on merging the drafts.

Greg Shepherd, Mike McBride <[e-mail]>, and Stig Venaas will 
be attending the next NANOG meeting and will work together on a 
presentation to that meeting about the multicast transition work.

Solution-Related Discussion Points
==================================

Stateful/Stateless
------------------
Stig Venaas clarified a point he had raised in earlier discussion about 
the AF. Of course, IGMP, MLD, and PIM have state. What he meant by the 
stateful/stateless terminology was its application to address 
translation. He noted that IPv6 to IPv4 address translation might have 
to be stateful.

Best Strategy For Address Acquisition
-------------------------------------
We need operator input. It could take a while to settle this question.

Reverse Path Forwarding and Loop Avoidance
------------------------------------------
Tom Taylor <[e-mail]> explained the issue. If multiple 
address translations during path setup, it is possible that the path 
gets looped back to a network it has already transited. Stig Venaas had 
pointed out that networks could avoid this if each network knew the true 
source address, Tom Taylor noted that an IPv4 source address would 
always remain available if RFC 6052 was applied for its conversion to 
IPv6 and back again.

Stig Venaas noted that the problem needs further exploration. It should 
be mentioned as a potential problem in the overview, and documented more 
thoroughly when we have developed a fuller view. He said there were 
other issues besides routing loops that are not currently noted in the 
overview.

Translation Between IGMP/MLD and PIM In the Other IP Version
------------------------------------------------------------
Covered by the IGMP/MLD draft.

Wrapping Up
===========

Tina Tsou pressed the chairs to summarized the action items.

1. Merge the relevant information from draft-jaclee into draft-eubanks.

2. Yiu Lee to chase down requirements. What is out there, what is 
needed, what is not.

3. The IGMP/MLD draft to be resubmitted to the PIM WG. Any PIM-to-PIM 
translation draft would also go there.

The MBONED Chairs were asked what the MBONED agenda in Paris would 
cover. Lenny Giuliano said the meeting would cover the standard items 
and an update on the action items in the interim meeting. They would 
leave room for a good discussion on the multicast transition topic. A 
call for agenda items would go out shortly.

The meeting was adjourned.