Minutes for MBONED at interim-2012-mboned-1
minutes-interim-2012-mboned-1-2

3/1/12 Virtual MBONED Interim Notes

Notetaker: Tom Taylor (with assistance from Sue Hares)
Webex Recording:
https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=59066907&rKey=89db506666a6b7ca

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 <lenny at
juniper.net> and Greg Shepherd <gjshep at gmail.com>, 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 <tina.tsou.zouting at huawei.com> 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 <stig at venaas.com>. 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 <dthaler at
microsoft.com>. 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 <rbonica at
juniper.net> 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
<yiu_lee at cable.comcast.com> 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 (correction:
wasn't Lenny, was probably Ron) 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 <mohamed.boucadair
at orange.com> 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 <mmcbride7 at gmail.com>, 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 <tom.taylor.stds at gmail.com> 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.