Leonard Giuliano | 16 Oct 20:07 2014
Picon

call for agenda items in MBONED


If you have something you'd like to present in MBONED in Honolulu, please 
let the chairs know.  Please include the name of the draft and the amount 
of time you'd like.

We are tentatively scheduled for Tues, 9-11:30AM.  BTW, this will be the 
first time where will hold our meeting jointly with the PIM WG.  We 
welcome feedback on how well this experiment works out.

Thanks,
Greg and Lenny

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

Tom Taylor | 3 Oct 03:50 2014
Picon

Comments on draft-ietf-mboned-64-multicast-address-format-06

I have a couple of comments on 
draft-ietf-mboned-64-multicast-address-format-06.

(1) Sec. 4.3 RFC 3307 requires the low-order 32 bits of a 
dynamically-allocated multicast address to lie in the range 0x80000000 
to 0xFFFFFFFF. That means the high-order bit of any embedded IPv4 
address may have to be flipped. You may potentially need a new flag to 
indicate this, which means another iteration through 6man.

(2) Sec. 3.5 should refer to RFC 5952.

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

Greg Shepherd | 25 Sep 21:53 2014
Picon

Mulit-point (Multicast) BoF of interest

Hi Folks,

If you are interested in a new forwarding mechanism for Multicast, called: Bit Indexed Explicit Replication (BIER), please feel free to register to the BOF list bier <at> ietf.org(https://www.ietf.org/mailman/listinfo/bier)

We have a BOF request pending for Hawaii.

http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Routing

These drafts are available for reading, more will follow later.

https://tools.ietf.org/id/draft-shepherd-bier-problem-statement-00.txt
https://tools.ietf.org/id/draft-wijnands-bier-architecture-00.txt
https://tools.ietf.org/id/draft-wijnands-mpls-bier-encapsulation-00.txt

Please join the email list and help generate discussion if you find this work interesting. I look forward to seeing all of you in Hawaii!

Cheers,
Greg
_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned
IJsbrand Wijnands | 25 Sep 10:57 2014
Picon

BIER BOF

Hi Folks,

If you are interested in a new forwarding mechanism for Multicast, called: Bit Indexed Explicit
Replication (BIER), please feel free to register to the BOF list bier <at> ietf.org (https://www.ietf.org/mailman/listinfo/bier)

We have a BOF request pending for Hawaii.

http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Routing

These drafts are available for reading, more will follow later.

https://tools.ietf.org/id/draft-wijnands-bier-architecture-00.txt
https://tools.ietf.org/id/draft-wijnands-mpls-bier-encapsulation-00.txt

Thx,

Ice.

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

internet-drafts | 24 Sep 11:10 2014
Picon

I-D Action: draft-ietf-mboned-64-multicast-address-format-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           : IPv6 Multicast Address With Embedded IPv4 Multicast Address
        Authors         : Mohamed Boucadair
                          Jacni Qin
                          Yiu L. Lee
                          Stig Venaas
                          Xing Li
                          Mingwei Xu
	Filename        : draft-ietf-mboned-64-multicast-address-format-06.txt
	Pages           : 12
	Date            : 2014-09-24

Abstract:
   This document reserves one bit (M-bit) of the unicast prefix-based
   multicast IPv6 address for ASM and an IPv6 multicast prefix for SSM
   mode to be used in the context of IPv4-IPv6 interconnection.

   The document specifies an algorithmic translation of an IPv6
   multicast address to a corresponding IPv4 multicast address, and vice
   versa.  This algorithmic translation can be used in both IPv4-IPv6
   translation or encapsulation schemes.

   This document updates RFC 7371.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mboned-64-multicast-address-format/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mboned-64-multicast-address-format-06

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

internet-drafts | 3 Sep 05:54 2014
Picon

I-D Action: draft-ietf-mboned-multrans-addr-acquisition-04.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-04.txt
	Pages           : 10
	Date            : 2014-09-02

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-04

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

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 | 25 Jul 18:02 2014
Picon

MBONED draft mins


Below are the mtg mins from yesterday.  Please review while it's still 
fresh in your mind for accuracy and let us know if you see something that 
should be changed.  And thanks to Percy, for taking excellent notes.

MBONE Session
IETF 90
9-11:30AM
July 24, 2014

1. Chairs: Lenny
a. Note Well
b. Status of Agenda
c. Status of Active WG Docs:
i. Geo-distribution: JeffreyZhang- need to address some comments received 
from Toerless
ii. Multrans - Quiet so far
iii. Data Center - Mike to talk about this.
iv. Mtracev2 Also some comments received and perhaps this is ready for 
last call (Lenny)? Pretty extensive revisions from IESG so another round 
of changes needed before WG Last Call. Lenny: Make changes and ask for 
comments from list & then make ready for Last Call.

d. AMT Update:
i. In IESG for long time with lots of comments.
ii. Joel - One issue to resolve: concerns about selection of algorithms by 
Security area; Do need to do to explain to them.
iii. Lenny - Need to get original authors to clarify?
iv. Joel - Yes that would be good. Need to be gentle but firm to point out 
history.
v. Lenny - what if original authors do not remember history?
vi. Joel - It could be worked out as the Transport problem was worked out 
in same way with Security. Issue is with preventing people from injecting 
their own signaling. Needs to be resolved.
vii. Lenny - will work to contact original authors

2. Multicast cdni - Percy
a. 6th version
b. Need to change title draft-ietf-mboned-multicast  version 0.0
c. PT- started Vancouver 2012
d. New are
i. Provisioning Guidelines
ii. Gap we need to develop draft on optimal AMT
iii. Billing guidelines
iv. Logging Guidelines (usage logs, security logs, other logs: access, 
app, syslpog)
v. Settlement Guidelines (aggregation, collection, transport, billing and 
reimbursement)
e. Next Steps
i. Complete section 4
ii. Comments
iii. Goal complete by 1Q15
f. Comments questions
i. How is this different from unicast (it covers the specifics of 
multicast with respect to ADs)? Look at CDNI WG work to perhaps point to 
as appropriate.

3. Multicast in Data Center (MikeMcBride):
a. Per Charter: Create practice documents for various multicast 
experiences.
b. Joel: OK as part of charter
c. Motivation : Emails opinions on use of multicast in DCs?:
i. Document multicast use in DC as part of MBONE work
ii. Goal: Find unique aspects of Multicast use in DCs & describe here.
d. Multicast Apps used in DCs:
i. Windows Media servers
ii. Publish
iii. Marjet
iv. IPTV
v. VRRP
vi. Overlays
vii. Etc:
viii. How are they being used & do they scale well?
e. Challenges:
i. Broadcasts when igmp snooping
ii. VRRP chatty heartbeats
iii. Overlay
iv. VM Scaling
v. Others?
f. Request for MBONE:
i. Seeking co-author & feedback
g. Percy: Data Centers moving to NFV/VNF environment. How does Multicast 
use fit in with NFV?
h. Gorry: consider WAN use in DC for Multicast?
i. Hitoshi: Do we need to address WAN area here?
j. Gorry: Given virtualization, yes this makes sense
k. Hitoshi: Goal could be providing guideline so maybe look at the revived 
draft again to clarify? Specifically for IPv6 issues
l. Gorry & Joel: Scaling issues may not exist for this topic. So MBONE can 
offer useful advice on scaling properties?? Taking into account 
sensitivity of application - find list of do's & don'ts!!
m. Gorry: Not multicast problem per se; rather use of multicast is one way 
to resolve the issue!! Joel agrees.
n. Mike to update I-D

4. Traceroute for MVPNs (Bob Kebler):
a. Current Version description - where Mtrace does not work (list shown)
b. Lenny: Does GTM have same problem??
c. Robert: Yes
i. What Mtrace can do (description of what is new)
ii. Error Conditions
iii. Next Steps - will revise draft to address extensive comments from 
Eric Rosen, then seek WG Adoption
d. Hitoshi - Meaning of Augmented Response blocks??
e. Robert - additional info than standard response blocks; additional 
clarifications between Hitoshi & Robert. No desire to change Mtrace v2.
f. Lenny - Which WG is appropriate? Would other L3VPN WG be comfortable 
with this in MBONE? Robert ? Yes
g. Lenny - Merging this into existing Mtrace I-D or start new work? Robert 
- leave current I-D alone & start new one

5. Multicast Receiver Access Control (Bill Atwood):
a. Trust Relationships (Unicast & Multicast)
b. Use NSP Representative Model
c. Assumptions
d. Problem Size - NSP & EU interaction
e. App Level & Network Level interactions
f. Two Solutions described
g. IGMP drafts could not address this issue
h. Securing IGMP/MLD
i. Goals: List requirements for SPs to interact with CPs & Specify 
architecture
j. Requirements list for application constraints & interaction constraints
k. Building blocks - use IETF protocols
l. Architecture & Environment & Enforcement Points ? Results
m. Four Documents issued with more to come; request for liaison to PIM WG 
on this
n. Mike - Why liaison? Bill - Need clarification from PIM WG for 
permission to proceed. Joel - this is not a formal liaison; just 
interaction needed between WGs. Toerless - Good to get PIM opinion & need 
more Use Cases to motivate this work.
o. Stig - how easy to deploy this? Would it be used widely? Bill - could 
be used at any level including households.

6. Lenny - Open Discussion:
a. Stig:
i. Changes in Routing Area may impact Multicast
ii. PIM & MBONE have similar work & common participants but WGs are in 
different areas. So maybe have PIM & MBONE have a shared 2.5 hour session. 
Lenny - this is great idea as strong overlap. But time may be issue as not 
all sessions may be done in 2.5 hours. Joel - Good idea to do this; allows 
more coordinated activity. Mike - Supports this idea.
Question on MULTRANS status? Lenny - interest waning on MULTRANS; no 
strong consensus on how to develop problem statement. No major interest. 
Joel - many use cases but not enough business support behind them; hence 
not compelling enough to advance work.
Tina - thinks there may be business cases to justify from some SPs.
Joel - still not sufficient motivation.
Tina - wants to know about details as to why no interest.
Lenny - there was discussion on this with not much support for moving 
forward.
Tina - what about problem statement itself.
Lenny - discussions on Toerless' solution proposal seemed to make problem 
statement moot. Suggest to bring this up again on the list and see what 
responses received.
Joel - no broad consensus to advance this from February 2013 discussions.
Lenny - bring this up again on mailing list with Toerless proposal.
Mike - similar question; what is status of Multimob.
Lenny - moved to separate WG.
Joel - Multimob is being used in industry.
Stig - have more generic problem statements & then think as to how to 
advance work.

iii. Lenny - Interest in Internet Multicast seems to be at an all time 
low, yet the need is arguably greater than ever.  And the tools are 
finally available in production to solve the most long-standing problems 
(i.e., AMT).  How to jumpstart interest in Internet Mcast again?  World 
Mcast Day?
Toerless - Can we bring in all our ideas in and discuss what best way to 
proceed? How widely is Internet Multicast being used right now? Can we get 
marketing info to justify work?
Joel - AMT can build Multicast over Unicast; can characterize what 
happened in MBONE and see what role it plays in this  "Getting right" 
topology resulted in lost participants. Experiments are easy (IETF) but 
implementation is hard. So MBONE should move forward accordingly.
Stig - last mile may be an issue??
Joel - if we provide right technology, content delivery will take care of 
itself.
Stig - cases in Europe where millions watch events but maybe not on 
Internet.
Toerless - find pool of folks providing AMT capacity and then provide 
experiment to deliver content?? Engage MANET besides MBONE??
7. Lenny - Meeting Adjourned!!

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

joel jaeggli | 24 Jul 20:33 2014

draft-ietf-mboned-v4v6-mcast-ps recap

One of the issues raised at the mic is what happened to the  ps LC.

To my recollection there what I would characterize as a good amount of
support for advancing this draft. There  were also a significant
concerns raised both about the content  and the potential outcomes of
approving this work. I believe the the chairs concluded that strong
consensus in favor of publication was not to be had.

discussion both before (Orlando)

http://www.ietf.org/proceedings/86/minutes/minutes-86-mboned

and during/after

http://www.ietf.org/proceedings/87/minutes/minutes-87-mboned

appears in the minutes.

http://www.ietf.org/mail-archive/web/mboned/current/maillist.html

It is reasonable to conclude that we did not come out of the WGLC  with
a consensus to publish the extant document at that time.

between feb and july 2013 some pretty important changes occurred to the
document.

To my mind (and I am not the arbiter consensus within the working group,
the chairs are) the case for bandwidth optimization due to
de-duplication between AFs is not that compelling  relative to the
overall benfits from employing ip multicast. Transitions involving CGNs
in walled gardens are not great place to involve ip-multicast AF
transition tools whether those CGNs are stateless devices or not.

Finally section 3 three remains a matrix  of the various modalities of
proposed solutions, I'm not so compelled that hopping over unicast 4
networks is a job for a v6 multicast transition technologies. These
networks are currently in operation, have existing legacy devices, and
the overwhelming approach to them is capital preservation through not
investing in them in ways that take capital away from the future
deployment and upgrade cycle.

Thanks
joel

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned
Leonard Giuliano | 11 Jul 19:36 2014
Picon

call for MBONED agenda items


MBONED is scheduled for Thurs, July 24, 9-11:30AM.  If you have something 
you'd like to present, please let the chairs know the name of the draft 
and the amount of time you'd like.

Thanks,
Lenny and Greg

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

Stefán Atli Jónsson | 6 Jul 06:19 2014
Picon

(no subject)

watt do you expect from me ? :)

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www.ietf.org/mailman/listinfo/mboned
internet-drafts | 4 Jul 21:23 2014
Picon

I-D Action: draft-tarapore-mboned-multicast-cdni-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           : Multicasting Applications Across Inter-Domain Peering Points
        Authors         : Percy S. Tarapore
                          Robert Sayko
                          Greg Shepherd
                          Toerless Eckert
                          Ram Krishnan
	Filename        : draft-tarapore-mboned-multicast-cdni-06.txt
	Pages           : 25
	Date            : 2014-07-04

Abstract:
   This document examines the process of transporting applications via
   multicast across inter-domain peering points. The objective is to
   describe the setup process for multicast-based delivery across
   administrative domains and document supporting functionality to
   enable this process.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-tarapore-mboned-multicast-cdni/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-tarapore-mboned-multicast-cdni-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-tarapore-mboned-multicast-cdni-06

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


Gmane