[MBONED] Raw notes from mboned

[Leonard Giuliano <[e-mail]>]

Here are the raw minutes from MBONED mtg yesterday (thanks Gorry for the 
excellent, detailed notes).  Please take a look while this is all fresh in 
the mind and let us know if you see anything that should be 
added/modified.



MBONED IETF 86 Orlando
Tues, Mar 12, 2013

The status of the WG items was reviewed.
There had been a recharter proposal, to be reviewed by the AD.

* AMT was submitted to the IESG, there were issued to be addressed.

* Multrans Problem Statement
Ron Bonica: I'm not sure who wants the PS.
Joel: I do not know which items the WG should work on. If there are
implementers, it would be good to know what they are working on. I would
be fairly uncomfortable taking proposed work to the IESG with section 5
the way it currently is, and we do not have commitments to work on this.
Chair: There are people who want to work on this.
Joel: Running code and running away would be really helpful to know about.
An INFO document from an implementor that says they need the work would be
valuable. I don't know such a document exists. I think this document
should go to WGLC and people should then comment on the list and say what
they think.
Ron: When we asked the operator community, they said there is a way to
deliver to IPv4 and IPv6 users: They could replicate the content - why do
we need a more complex system?
-: We want to understand how to deploy IPv6 in multicast with IPv4.
Joel: Do you have a vendor that you are working with to implement this?
-: Yes, we are working on 4-6-4 and 6-4-6.
Ron: These are transit solutions, not 4 to 6 or 6 to 4?
Greg Shepherd: Softwires has similar work. I describe 4-6-4 and 6-4-6 as
transport methods, rather than transition mechanisms.
-: 6-6-4 is also a case. We have v6-only receivers.
Dino (via jabber): Note that terminology is different in different groups.
Greg: There is unfortunate acronym re-use.
Greg: Most systems that support v6 also support v4?
-: No.
Bill : The use case I was thinking of was an IPTV solution where set top
boxes will not be updated, and are fed from a HFC network. It is not a
possibility to simultaneously carry all traffic twice.
Greg: This community is not well-represented in this room.
Tina (via Jabber): There are use cases in the problem statement.
Chairs: Please send drafts to define appropriate use-cases.

The PS has been adopted and has beenworked upon. The AD has suggested we
should move to an early WGLC to understand the arguments and clarify
things. It's not a guarantee that the document will advance. It may
provoke questions and comments and a further WGLC may be needed. Please
speak-up on the list, especially about section 5.

Joel: If you are an implementor or a customer, please surface some
information to help define what work mboned will be doing a year from now.
Section 5 is a roadmap, let's understand if this should happen.

SSMPING testers are required.

Tim Chown noted there is a new version of the tool that reflects the draft
- please contact Tim or the author.

draft-tarapore-mboned-muticast-cdni
Tarapore

Chair: Who has read the draft?
<6>
Chair: How many in favour of adopting this?
<5>
The adoption decision will be taken on the list.

Toerless: What about if there are more domains? Do you really want to
constrain this to only 2 domains?
Greg: This seems like a useful work to do to support the CDNI work.
Tarapore: This is the simplest case.
- Is this documentation of how CDNIs are using multicast, or what they
plan to do in the future?
Tarapore: Both documenting, and operational issues.
Greg: I see merit in documenting this.
Stig: Are we trying to describe all the uses? It would be good to also
consider how AMT could be used in this context.
Bob: I am not aware of providers working across peerings and we have good
reasons to think this is useful.

draft-ietf-moboned-auto-multicast-14
draft-shepherd-udp-multicast-guidelines
Shepherd

IESG discussions suggested that the WG consider EXP status for AMT,
because there were things to be understood. The authors want to continue
draft-ietf-moboned-auto-multicast-14 as standards track.

Greg presented a need for draft-shepherd-udp-multicast-guidelines.

Toerless: It is worthwhile to have a BCP document for multicast.
Concerning AMT, I am not sure we need to care about congestion control in
a tunnelling mechanism. This is not required for other tunnels.

Greg: There needs to be a deployment case for this.
Gorry: Some RMT methods require feedback that isn't talked about in AMT,
which is unidirectional.
Greg: You can still do feedback, but we didn't write this.

Gorry: GRE has been used to tunnel multicast for a long time, and we have
experience.
Greg: Other tunnels also carry multicast, e.g. LISP.
Dino (via jabber): LISP does multicast but this is not tunnelling.

Greg: AMT is receiver-driven, there is an RPF so some problems are better
protected than for unicast.

Toerless: We are conflating two issues. What is the state of the art for
CC in multicast? The AMT discussion is something else.
Joel: An IESG "discuss" is a way to work through the issues. The new
document is useful.

Gorry: I'm not sure IPTV is multicast, it's a provider network solution.
IPTV, Often sending at constant rate also have an interest in knowing if
there customers get loss-less service - so there are operational tools to
ensure that networks do not beak.
Joel: A difference here is that traditional multicast trees were built
between people who understand multicast, and this is not the case for AMT.

Greg: We could take draft-shepherd-udp-multicast-guidelines to TSVWG.
There is no Agenda time this IETF.
Gorry: As TSVWG Co-Chair, this document appears to fall within the charter
of TSVWG, I would encourage you to take it there and ask for adoption.
There is no agenda time this IETF, but we will do heads-up announcement
that the draft exists.

Who has read the Guidelines I-D?
<7>

draft-boucadair-6man-multicast-addr-arch-update
Stig Venaas

Tim: This seems useful to do. It may be worth clarifying the way in which
the flags fields are inherited.
Stig: I think it is useful to know if they are bit flags or a field.
Tim: I think they are bit flags.

draft-zhou-mboned-multrans-path-optimization
Zhou

Ron: There was a criticism that this work starts on the basis of a problem
statement that has yet to be agreed.
Joel: I am happy to see discussion on this document.
Ron: After we make a decision on mast PS, then we decide if this is useful
to adopt.
Stig: I think we need more than to agree the problem, we need to determine
to work on translation and then see optimisation. Keep this document
around, it may be a useful future input.

The authors noted that they would like to see the PS and optimisation
should work in parallel.
Joel: This is not yet an adopted WG document. I think it is also not a
stand-alone document, so we need to consider this after we have decided
what to do next.

Chairs: The next stage is to determine the use cases, and then decide if
there is need to write a companion document that could sit alongside this.

draft-wang-mboned-glo-ipv6-mcast-reachability
Meng

Toerless: Is this inter or intra-domain?
-: There is another draft on this problem also seeking work on multicast
VPN. It would be good to see proposals discussed in the same place.
Ron: If this draft defines a new NLRI does it go beyond mboned?
Joel: I think this belongs in the INT area.

Please take discussions to the list, and we should discuss there.

On Friday there are simultaneous presentations on multicast in LISP in PIM
and LISP.

End.