Greg Shepherd | 18 Nov 22:06 2015

MBONED WG Minutes?

Who took minutes in Yokohama?

MBONED mailing list
lionel.morand | 5 Nov 09:47 2015

TR: Would you help present draft-ietf-mboned-multrans-addr-acquisition-06 tomorrow ?



De : sunqiong [mailto:sunqiong <at>]
Envoyé : mercredi 4 novembre 2015 16:23
Cc : MORAND Lionel IMT/OLN; Tina; Cathy Zhou(Qian)
Objet : Would you help present draft-ietf-mboned-multrans-addr-acquisition-06 tomorrow ?


Dear Med,


I was planning to present draft-ietf-mboned-multrans-addr-acquisition-06 in this IETF meeting. However, since my flight back to China is at 7:30 pm tomorrow evening, I cannot catch up with mboned session (5:40 pm ~7:40pm). Is it possible that Lionel help to present this draft (see the slides in the attachment) ?


Thanks a lot!


Best wishes




_________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you.
MBONED mailing list
Toerless Eckert | 4 Nov 01:45 2015

Re: multicast over wifi and and IEEE-IETF coordination

[sorry, resending with correct email aliases]


Any reason to choose INTAREA ? 

There is already a draft in mboned:


and... mboned runs in parallel to intarea this time *sigh*
and... i am sure mboned participants would love to hear your preso about IEEE.


On Wed, Nov 04, 2015 at 01:31:52AM +0100, Mikael Abrahamsson wrote:
> Hi,
> I have been involved with the coordination group between IEEE and IETF to 
> discuss multicast over 802.11 issues that have been brought up in different 
> forums, both regarding reliability and power usage on battery powered 
> devices.
> There will be a presentation in INTAREA regarding this and initial 
> discussion on the issue will be had there. In case there is enough interest 
> in the issue, there might be a non-working group mailing list created for 
> further discussion, or something else.
> There will also be presentation in the IEEE meeting next week on this 
> issue, so there is awareness in both forums that the issue has been raised 
> to try to gather all interested parties to work on this problem.
> The presentation tomorrow will be to present what IEEE already has done in 
> this area (for instance GCR), and then there is a need to figure out what 
> part of the problem to be solved where (IETF/IEEE).
> -- 
> Mikael Abrahamsson    email: swmike <at>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 <at>
> Administrative Requests:
> --------------------------------------------------------------------


Toerless Eckert, eckert <at>

MBONED mailing list

Leonard Giuliano | 30 Oct 22:54 2015

MBONED agenda

Draft agenda for MBONED.  We will be meeting on Thurs right after PIM. 
Please let me know if we forgot anyone or if anyone else would like to be 
added to the agenda.

Presenters- please send me your slides by Sunday night so folks have a 
chance to review them.

IETF 94 Yokohama
Thurs, Nov 5, 2015
Rooms 411/412

Status of WG items
Chairs, 5 min

Sun, 10 mins

Tarapore, 10 min

Optimal AMT Relay Discovery
Tarapore, 10 min

McBride, Perkins, 10 min

MBONED mailing list

Dale W. Carder | 22 Oct 18:04 2015

Re: draft-ietf-mboned-interdomain-peering-bcp-00.txt comments

replying to the list...  sorry for the delay.

Thus spake TARAPORE, PERCY S (pt5947 <at> on Thu, Oct 15, 2015 at 02:45:12PM +0000:
> Dale,
> Thanks so much for your detailed set of comments on our BCP Last Call. We appreciate these comments and our
responses are provided in detail below. However, we should point out two aspects regarding the use of
multicast - our BCP is based on these:
> 1.	As you know, AT&T has recently acquired DirecTV - we envision a significant increase in video
distribution both On-Net and Off-Net. There will be many channels including third party channels for
distribution. We envision an increased role for multicast in this process including inter-domain peering.
> 2.	We understand the angst in the IETF against "billing and business" issues. However, this is simply a
BCP and not a prescriptive RFC. As such, these business issues are included as guidance and not as
normative requirements precisely for service providers that may need to multicast content through
their respective domains.
> Onto your specific comments:
> -	Thanks for tipping your hat off to us - getting this through MBONE was a long process.
> -	Section 1 Assumption on compatible multicast protocols: This topic probably needs a separate RFC in
its own right!! We don't feel it is within the scope of a BCP unless there is documentation we can point to on
HOW any incompatibility can be resolved.
> -	Section 1 AMT Assumption - we will add text stating that this is not necessary for Use Cases 3.1 & 3.2.
> -	Section 3.1 Guideline (c) - we will add text per your suggestion.
> -	Section 3.1 Proposal for New Guideline - sure we can add text either here or point to something in the
Security section. Perhaps we can jointly draft some text. As far as "old" references, maybe we can add them
to the Informative Reference Section 9.2. Note that we have added a Draft I-D from 2000 there. Let's see if
that is allowed.

sample text:

e.  The interconnection of AD-1 and AD-2 should minimally follow BCP-38 
    guidelines for traffic filtering between autonomous systems.  
    Filtering guidelines specific to the multicast control-plane and
    data-plane are described in section 6.

> -	Section 3.2 Guideline (e) - OK we are stating the obvious.
> -	Section 4.3 - Please refer to comment 2 above. We are definitely NOT trying to tell anyone how to run their
network. This is a BCP not an RFC. In our SP world, it is important to have such guidelines present.
> -	Section 4.4 - We'll take the complement but we are not sure if you want something added here; please let us know.
> -	Section 5 - looks like you are suggesting we add a description on the "Looking glass style router
proxy"?? We can do that; we would need references as well. Again, maybe we can jointly develop some text?
Please let us know.

Here's an attempt:

Service providers may wish to allow limited read-only administrative
access to their routers via a looking-glass style router proxy to 
facilitate the debugging of multicast control state and peering status.
Software such as the implementations available at can be easily extended to provide
access to commonly-used multicast troubleshooting commands in a secure

> -	Section 6 - Again, maybe we can work jointly on adding new text here?

There exists some pretty good prior work we should reference hopefully
instead of re-documenting the wheel.  Of these, 
draft-chown-mboned-multicast-filtering-02 is probably the most comprehensive.
It looks like this died at ietf-83?


MBONED mailing list

internet-drafts | 9 Oct 09:52 2015

I-D Action: draft-ietf-mboned-mtrace-v2-12.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the MBONE Deployment Working Group of the IETF.

        Title           : Mtrace Version 2: Traceroute Facility for IP Multicast
        Authors         : Hitoshi Asaeda
                          Kerry Meyer
                          WeeSan Lee
	Filename        : draft-ietf-mboned-mtrace-v2-12.txt
	Pages           : 34
	Date            : 2015-10-09

   This document describes the IP multicast traceroute facility, named
   Mtrace version 2 (Mtrace2).  Unlike unicast traceroute, Mtrace2
   requires special implementations on the part of routers.  This
   specification describes the required functionality in multicast
   routers, as well as how an Mtrace2 client invokes a query and
   receives a reply.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

MBONED mailing list

Dale W. Carder | 5 Oct 20:12 2015

draft-ietf-mboned-interdomain-peering-bcp-00.txt comments

I was alerted to the presence of draft-ietf-mboned-interdomain-peering-bcp-00.txt
via another mailing list, so I took some time to look at it & comment
here.  Thus, I am new to this WG.

In general I think this document is useful, but in all honesty it's
proper place in time may have been a decade ago.  The problem space is 
incredibly complex, so my hat is off to the authors who are trying to 
document it.  One disclaimer is that in my experience on the various 
networks I have been involved with, the number of multicast peers I 
have is only decreasing rather than increasing.  I also have never 
witnessed anything better or newer than igmpv2/pim-sm/bgp/msdp in actual 

Section 1, assumption "Network Administrative Domains involved in setting 
up multicast peering points are assumed to adopt compatible protocols. The 
use of different protocols is beyond the scope of this document."
I almost stopped here. :-)  My multicast peering sessions with service 
providers typically fall into this category.  Some reasons include
dense-mode only on one side, sparse on the other, incompatible use of 
rfc1918 on one side and MLDv1 clients on the other... and so on.

Section 1 AMT Relay assumption.  However, this seems not to be necessary 
at all for the topologies described in 3.1 or 3.2 (nor I have I ever seen 

Section 1 last statement, and also for Section 2:  We actually tried for 
some time to run bilateral multicast peering on an exchange switch (that 
we ran) between participating ISP's.  So this is a valid topology, although 
probably even less common than peering on private interconnects.  Plus, 
it does have a multitude of other issues.

Another topology we have much experience with particularly in our
community is with a multicast enabled ISPs between sites.

Section 3.1 guidelines.  for (c) AD-1 may also employ a policy to only
allow certain groups for which AD-2 has paid.  For example I have seen
cherry-picker devices for determining which video channels are eligible
to be injected into AD-2.  

Section 3.1, Can we add a guideline 'e' to include ensuring that proper 
filtering is enabled between networks, or reference the security

I am guessing it may not be possible to reference draft-nickless-ipv4-mcast-unusable-03
but there has been a lot of real-world pain there.  Another (old) 
example is

Section 3.2 guideline (e).  Nearly all aspects of peering between
AS's are manually configured, so I don't see how this is an issue.

Section 4.3.  I think this is where I get to say the IETF doesn't get to
tell me how I operate my network... or something ;-)  This looks like it
is really specific to some sort of market segment of which I am not a
part.  My router doesn't have a "manifest file".  In my world, the
client's IGMP/MLD join is what gets them sprayed with content.  

Section 4.4.   Looks pretty good.  I am not sure if the commentary about
violating SLA's and seeking compensation is needed though.  Having
transparency with the quality monitoring probes is very important.  When
we ran the multicast-enabled IX, we also had a probe deployed there
that could be provisioned for anyone's use to ensure the exchange switch
was behaving (which it often was not... another story)

Section 5:  We have had good luck in exposing a Looking glass style
router proxy to our peers to aid in faster problem resolution and help
with the finger pointing in addition to the stream monitoring probes.
This really helps not only when there is a 3rd party in the middle, but
also when troubleshooting filtering / cherry picking / control state,
particularly when turning up the peering sessions.

Section 6:  Text should be added to invoke BCP-38 style filtering.
Something like each multicast peer MUST (can you say MUST?) employ
BCP-38 style filtering to ensure they are not sourcing multicast content
nor any network control state that should not be legitimately sourced by
that network.

Other commentary:
In general I was a bit surprised by the amount of text focused on billing 
& business issues.


MBONED mailing list

Leonard Giuliano | 2 Oct 20:02 2015

WGLC for draft-ietf-mboned-interdomain-peering-bcp

We would like to begin working group last call for 
draft-ietf-mboned-interdomain-peering-bcp.  Please post any and all 
comments supporting/opposing the draft to the list by Nov 2.  This draft 
will not be advanced for publication unless there is sufficient response 
and support from the WG.  And, of course, substantive comments on the 
actual draft are strongly encouraged as well.

Most recent version of the draft can be found here:

MBONED mailing list

Leonard Giuliano | 2 Oct 19:46 2015

Call for MBONED Agenda items in Yokohama

If you have something you'd like to present in Yokohama, please let us 
know the draft name and amount of time you'd like.  If we do not have 
enough agenda items we are considering not having a meeting in Yokohama.
So please send your requests to the chairs by Oct 12.

Lenny and Greg

MBONED mailing list

Greg Shepherd | 22 Sep 01:07 2015

Re: New Version Notification for draft-ietf-tsvwg-rfc5405bis-06.txt


draft-ietf-tsvwg-rfc5405bis-06.txt is now in WGLC in TSVWG. It contains guidelines for mcast applications as well, so please read and provide feedback.


On Fri, Sep 18, 2015 at 8:17 AM, <internet-drafts <at>> wrote:

A new version of I-D, draft-ietf-tsvwg-rfc5405bis-06.txt
has been successfully submitted by Lars Eggert and posted to the
IETF repository.

Name:           draft-ietf-tsvwg-rfc5405bis
Revision:       06
Title:          UDP Usage Guidelines
Document date:  2015-09-18
Group:          tsvwg
Pages:          50

   The User Datagram Protocol (UDP) provides a minimal message-passing
   transport that has no inherent congestion control mechanisms.  This
   document provides guidelines on the use of UDP for the designers of
   applications, tunnels and other protocols that use UDP.  Congestion
   control guidelines are a primary focus, but the document also
   provides guidance on other topics, including message sizes,
   reliability, checksums, middlebox traversal, the use of ECN, DSCPs,
   and ports.

   Because congestion control is critical to the stable operation of the
   Internet, applications and other protocols that choose to use UDP as
   an Internet transport must employ mechanisms to prevent congestion
   collapse and to establish some degree of fairness with concurrent
   traffic.  They may also need to implement additional mechanisms,
   depending on how they use UDP.

   Some guidance is also applicable to the design of other protocols
   (e.g., protocols layered directly on IP or via IP-based tunnels),
   especially when these protocols do not themselves provide congestion

   If published as an RFC, this document will obsolete RFC5405.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

The IETF Secretariat

MBONED mailing list
internet-drafts | 2 Sep 09:49 2015

I-D Action: draft-ietf-mboned-multrans-addr-acquisition-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the MBONE Deployment Working Group of the IETF.

        Title           : Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions
        Authors         : Tina Tsou
                          Axel Clauberg
                          Mohamed Boucadair
                          Stig Venaas
                          Qiong Sun
	Filename        : draft-ietf-mboned-multrans-addr-acquisition-06.txt
	Pages           : 10
	Date            : 2015-09-02

   Each IPTV operator has their own arrangements for pre-provisioning
   program information including addresses of the multicast groups
   corresponding to broadcast programs on the subscriber receiver.
   During the transition from IPv4 to IPv6, scenarios can occur where
   the IP version supported by the receiver differs from that supported
   by the source.  This memo examines what has to be done to allow the
   receiver to acquire multicast address information in the version it
   supports in such scenarios.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

MBONED mailing list