Leonard Giuliano | 17 Jun 17:27 2015
Picon

Call for MBONED Agenda items in Prague


If you have something you'd like to present in Prague, please let us know 
the draft name and amount of time you'd like.  There are currently 
scheduling challenges (more WG requests than available slots), so if we do 
not have enough agenda items we are considering not having a meeting in 
Prague.  So please send your requests to the chairs by the end of the 
week.

Thanks,
Lenny and Greg

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

Greg Shepherd | 1 Jun 21:01 2015
Picon

MBONED WG Announcement!!

Who's listening?

We have some proposed work that showed solid support in the WG meeting but when asked for support on the list we hear nothing. Is anyone there?? 

As a participant in the MBONED WG, we need your input whether you support the work or not. We can't adopt work without support, but we can't gauge support without any feedback.

PLEASE, somehow we need to wake MBONED out of its coma and see if there's any life left.

So if you get this, read this AND want to participate in the WG in any capacity, please respond to this message.

Thanks,
Chairs.
_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned
Ali C. Begen (abegen | 9 Apr 12:53 2015
Picon

Re: MBONED Digest, Vol 100, Issue 1

As an author, I am not aware of any IPR on this draft.

Dave, are you aware of any IPR?

-----Original Message-----
From: "mboned-request <at> ietf.org"
Reply-To: "mboned <at> ietf.org"
Date: Wednesday, April 8, 2015 at 4:24 PM
To: "mboned <at> ietf.org"
Subject: MBONED Digest, Vol 100, Issue 1

>Send MBONED mailing list submissions to
>	mboned <at> ietf.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://www.ietf.org/mailman/listinfo/mboned
>or, via email, send a message with subject or body 'help' to
>	mboned-request <at> ietf.org
>
>You can reach the person managing the list at
>	mboned-owner <at> ietf.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of MBONED digest..."
>
>
>Today's Topics:
>
>   1.  Adoption of draft-singer-appsawg-mcast-url (Leonard Giuliano)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 8 Apr 2015 06:23:54 -0700
>From: Leonard Giuliano <lenny <at> juniper.net>
>To: MBONED WG <mboned <at> ietf.org>
>Subject: [MBONED] Adoption of draft-singer-appsawg-mcast-url
>Message-ID: <20150408061423.S20335 <at> zircon.juniper.net>
>Content-Type: text/plain; charset="US-ASCII"; format=flowed
>
>
>URLs and HTTP Response Forms for Multicast 
>(https://tools.ietf.org/html/draft-singer-appsawg-mcast-url-00) was 
>presented in MBONED at IETF 92 (Dallas). The authors are requesting 
>official adoption of this draft as a WG document in MBONED (in the 
>meeting, ~7-8 people supported adopting this draft as a WG document, none 
>opposed).
>
>Please respond by Apr 22 if you do/do not support adoption of this draft.
>
>If you are listed as a document author, please respond to this email 
>whether or not you are aware of any relevant IPR.  If you are not listed 
>as an author and are aware of any relevant IPR, please respond as well.
>
>
>-Lenny and Greg
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>MBONED mailing list
>MBONED <at> ietf.org
>https://www.ietf.org/mailman/listinfo/mboned
>
>
>------------------------------
>
>End of MBONED Digest, Vol 100, Issue 1
>**************************************
_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

Leonard Giuliano | 8 Apr 15:23 2015
Picon

Adoption of draft-singer-appsawg-mcast-url


URLs and HTTP Response Forms for Multicast 
(https://tools.ietf.org/html/draft-singer-appsawg-mcast-url-00) was 
presented in MBONED at IETF 92 (Dallas). The authors are requesting 
official adoption of this draft as a WG document in MBONED (in the 
meeting, ~7-8 people supported adopting this draft as a WG document, none 
opposed).

Please respond by Apr 22 if you do/do not support adoption of this draft.

If you are listed as a document author, please respond to this email 
whether or not you are aware of any relevant IPR.  If you are not listed 
as an author and are aware of any relevant IPR, please respond as well.

-Lenny and Greg

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

Stig Venaas | 30 Mar 19:46 2015

Seeking volunteers for multicast YANG model design team

Hi

As I mentioned in the mboned meeting, the pim wg is forming a design
team to work on YANG multicast models. The work will focus on models
related to the pim protocols, but also IGMP/MLD.

We have several vendors, but would like to see operators participating
as well. Please get in touch with me if you're interested. The goal is
to come up with models fairly quickly. We will probably be meeting
virtually every 2 weeks.

Stig

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

Leonard Giuliano | 25 Mar 15:36 2015
Picon

MBONED draft minutes


Draft notes from yesterday's lively and spirited MBONED meeting (thank you 
Duke F. for taking them).  Please take a look while it's fresh on your 
mind and send any edits as it was tough to keep up with all the fast and 
furious discussions.

Agenda begins:
 	Status of Active WG Docs
 	RFC7450 Greg B, finally made to RFC status after  14 years

Percy Tarapore presented : (draft-tarapore-mboned-multicast-cdni)
 	Percy would like to know if name should be changes, what version, 
need guidance
o	Lenny  recommend name change and version to start at zero
 	Lenny questioned relevance of AMT tunnel  (section 3)
 	Percy ask for thoughts where 2 domains my not utilize same 
protocols (section 4.2)
o	From audience
 	1st  recommendation is to put into separate document
 	2nd recommendation is to state in document that this will not be 
addressed
 	3rd recommendation is if there is a consensus that this is not a 
good idea, then do not put into document.  Do not need to include every 
corner case/crazy idea a SP might have.
 	(there were other comments, but they fit into the same as above)
 	Asking for overall feedback (section 4.3)
 	Lenny: what about ASM?  Specifically, should MSDP be mentioned 
since it has been used for peering in the past?
 	Consensus: No, should focus on SSM only for interdomain and not 
document ASM since it is not recommended.
o	Lenny  this document is basically for peering, could we use 
unicast peering guidelines as a template.  Asked audience if anyone knows 
of one.
 	Audience:  Nothing known, but believe there should be docs 
somewhere, and will look
o	Comments on not covering settlement, to keep the document shorter, 
more focused
o	Comment on need of this document.   Is there a need for mcast 
peering between providers?  We tried several years to get global multicast 
to work and failed.
o	Can we add section on troubleshooting and diagnostics
o	Percy summarized that this section should be condensed, but also 
add troubleshooting piece
o	Lenny  would like to get more operator input

Ali Begin presented (draft-singer-appsawg-mcast-url-00)
o	Lenny  asked why fcast
 	Ali asked for general questions: Is there a need for this, do you 
care or not care?
o	Can background on how these are URLs are used in unicast? To 
provide an example, would be helpful
o	How do notify the clients to switch to multicast
 	Redirect to a different URL to join multicast stream
 	Should be done in real time without prior signaling
o	FCAST would like to be used since it is being adopted by much of 
industry
o	Could you bring aspects of AMT into this also?
 	Lenny polled room on who has read the draft?
o	None, but this has not been sent to MBONED working group
o	Please troll the WG before submitted
 	Poll on who thinks should be MBONED working group
o	~ 7-8 support adoption, 0 against

Bill Atwood presented (Secure and Accountable AMT)
 	General questions at the end
o	Was any of the security issues addressed with AMT?   Comment that 
the security issues have been verified.
 	Bill said he will provide additional information on the list

Lenny presented (Multicast Requirements for 2015)
 	Some comments from audience:
o	Bursty sources  not sure if the requirement should be removed
 	Do we want one solution to that covers everything:  Question of
 	discovery of sources
 	Do we want the network to do the discovery or the application
o	Separation of control and data to keep to improve multicast
o	The network already has unicast capability to everyone, why do I
 	need to complicate it with multicast?
 	Belief that live linear is not dead, there is a need for multicast
 	in the future, with future applications?
o	The question is how much do you want to do?  Just how large of
 	scope do you cover?
 	If this WG could provide useful guidance to app developers, that
 	would be great.  The other questions is would it even matter
o	There was a ton of comments and feedback here  too many to
 	document

Greg Shepherd  BIER update
 	Best draft to start reading is the problem statement, then 
architecture
 	If there is a solution in IPv6 please bring to the group

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

Greg Shepherd | 24 Mar 20:11 2015
Picon

Open Source AMT

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned
Toerless Eckert | 6 Mar 17:54 2015
Picon

MBoned: Re: WG Review: L3VPN Service Model (l3sm)

Any thoughts on this ? Anybody from mboned planning to contribute to
this work to ensure that L3VPN multicast would be represented in the
data model created ?

In-Reply-To: <20150306163644.31050.21402.idtracker <at> ietfa.amsl.com>

On Fri, Mar 06, 2015 at 08:36:44AM -0800, The IESG wrote:
> From: The IESG <iesg-secretary <at> ietf.org>
> To: IETF-Announce <ietf-announce <at> ietf.org>
> Subject: 
> 
> A new IETF working group has been proposed in the Operations and
> Management Area. The IESG has not made any determination yet. The
> following draft charter was submitted, and is provided for informational
> purposes only. Please send your comments to the IESG mailing list (iesg
> at ietf.org) by 2015-03-16.
> 
> L3VPN Service Model  (l3sm)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Assigned Area Director:
>   Benoit Claise <bclaise <at> cisco.com>
> 
> 
> Charter:
> 
> The IETF and the industry in general is currently specifying a set of
> YANG models for network element and protocol configuration. This is an
> essential first step, but the end goal is full system configuration that
> allows the deployment of services across networks. Services are built
> from a combination of network element and protocol configuration, but are
> specified to service users in more abstract terms.
> 
> The Layer Three Virtual Private Network Service Model (L3SM) working
> group is a short-lived WG tasked to create a YANG data model that
> describes a L3VPN service (a L3VPN service model) that can be used for
> communication between customers and network operators, and to provide
> input to automated control and configuration applications.
> 
> It needs to be clearly understood that this L3VPN service model is not an
> L3VPN configuration model. That is, it does not provide details for
> configuring network elements or protocols. Instead it contains the
> characteristics of the service, as discussed between the operators and
> their customers. A separate process is responsible for mapping this
> service model onto the protocols and network elements depending on how
> the network operator chooses to realise the service.
> 
> The deliverable from this working group will provide information to
> evaluate the set of YANG models that have already been developed or are
> under development, and will help identify any missing models or details. 
> The deliverable can be viewed as driving requirements for protocol
> configuration model so that the service parameters can be mapped into
> inputs used by the protocol models.
> 
> It is hoped that this working group will provide evidence that such
> service models can be quickly constructed and agreed upon. If successful,
> further service models may be developed in other working groups
> 
> The working group should consider draft-l3vpn-service-yang as a starting
> point.
> 
> Milestones:
>   Jan 2016 - L3VPN Service (YANG) Model to the IESG for publication as
> Proposed Standard RFC
>   Jan 2016 - Close the working group

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

internet-drafts | 4 Mar 08:14 2015
Picon

I-D Action: draft-ietf-mboned-multrans-addr-acquisition-05.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-05.txt
	Pages           : 10
	Date            : 2015-03-03

Abstract:
   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:
https://datatracker.ietf.org/doc/draft-ietf-mboned-multrans-addr-acquisition/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mboned-multrans-addr-acquisition-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mboned-multrans-addr-acquisition-05

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

Leonard Giuliano | 2 Mar 17:02 2015
Picon

Call for MBONED agenda items in Dallas


The MBONED mtg is scheduled for Tues, 3/24, at 1PM.  Rather than trying to 
fit both MBONED and PIM in the same time slot, we will go consecutively in 
the same room (PIM  <at>  9-11:30AM, MBONED  <at>  1-3PM, lunch in between).

If you would like an agenda slot to present in MBONED, please email Greg 
and me with your draft name and the amount of time you'd like.

-Lenny

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

Leonard Giuliano | 19 Feb 00:21 2015
Picon

RFC 7450 on Automatic Multicast Tunneling (fwd)


The AMT spec is finally an RFC- just 2 days shy of it's 14th birthday. 
Thanks go out to the many folks who have coathored, edited and contributed 
to this document over the years.  And very special recognition goes to 
Greg Bumgardner, who for the last 3 years has worked tirelessly to get 
this document passed the longest yard and over the goal line.

-Lenny

---------- Forwarded message ----------
Date: Wed, 18 Feb 2015 15:02:16 -0800
From: rfc-editor <at> rfc-editor.org
To: ietf-announce <at> ietf.org, rfc-dist <at> rfc-editor.org
Cc: mboned <at> ietf.org, drafts-update-ref <at> iana.org, rfc-editor <at> rfc-editor.org
Subject: [MBONED] RFC 7450 on Automatic Multicast Tunneling

A new Request for Comments is now available in online RFC libraries.

         RFC 7450

         Title:      Automatic Multicast Tunneling
         Author:     G. Bumgardner
         Status:     Standards Track
         Stream:     IETF
         Date:       February 2015
         Mailbox:    gbumgard <at> gmail.com
         Pages:      82
         Characters: 188711
         Updates/Obsoletes/SeeAlso:   None

         I-D Tag:    draft-ietf-mboned-auto-multicast-18.txt

         URL:        https://www.rfc-editor.org/info/rfc7450

This document describes Automatic Multicast Tunneling (AMT), a
protocol for delivering multicast traffic from sources in a
multicast-enabled network to receivers that lack multicast
connectivity to the source network.  The protocol uses UDP
encapsulation and unicast replication to provide this functionality.

The AMT protocol is specifically designed to support rapid deployment
by requiring minimal changes to existing network infrastructure.

This document is a product of the MBONE Deployment Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   https://www.ietf.org/mailman/listinfo/ietf-announce
   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned


Gmane