IETF 89 London
MBONED Agenda
Tues, Mar 4, 2014
9-11:30AM
Richmond/Chelsea/Tower

Note Taker: Toerless Eckert

Audio log:
http://www.ietf.org/audio/ietf89/ietf89-richmond-chelsea-tower-20140304-0900-am1.mp3

Jabber Log: 
http://www.ietf.org/jabber/logs/mboned/2014-03-04.txt

Status of WG items, AMT
Chairs, 15 min
 - Joel (AD): We need to revisit review of AMT, probably IETF review (not WG),
   AD review has timed out, no critical mass of survived ADs.

---------------------------------------------------------------------------
draft-tarapore-mboned-multicast-cdni
Tarapore, 10 min

Percy S. Tarapore / Rob Sayko ATT:
 - Up to last IETF: Finished 5 use-cases (section 4)

 - This IETF: best current practices section, section 1.
   - interconnection transport guidelines (4.1)

 - Greg S.:
   This doc has no explicit text about congestion control, but given the
   operational experience of the authors, we can imply that this is not
   an operational issue, because commercial services would not survive
   without being able to gracefully deal with congestion. This should
   be stated on thursday TSVWG meeting.

 - Percy explaining to Gory how this would map to use-cases,
   eg: traffic going over peering point.

 - Gory: Going into customers home is a different point. This should be
   well called out.

 - Routing aspect (section 4.2)
 - Routing Aspects for Native (4.2.1) and GRE Tunnels (4.2.2)
 - Routing aspects for AMT (4.2.3)

 - Rob Sayko: DNS resolution is going to be a separate draft
   (figuring the AMT relay closest to the receiver).
   Greg explaining in more detail.

---------------------------------------------------------------------------
draft-zzhang-l3vpn-mvpn-global-table-mcast
Zhang, 15 min
 - first presented in IETF86/L3VPN
 - asking for adoption in L3VPN, but wanted to get comments from MBoned.
 - overall Q. How to apply L3VPN multicast solution (MVPN/BGP) to
 - global table multicast that should be run or tunneled across the core.

 - Toerless:
   - Why L3VPN working group ?
     A: Because we are using L3VPN methodology.
     Q: But 6PE also used L3VPN technologies and was done in MPLS.
   - Thomas Morin:
     Lots of interest, not no big preference which WG it should go into.
     L3VPN maybe better because more experience of all the complexities
     of the signaling. But let's decide and move forward.
   - Ijsbrand Wijnand:
     Also thinks L3VPN is a good place.

 - Ijsbrand:
   There is also a draft for PIM-SM over MLDP, alternative proposal,
   is this draft then still needed ?
   Zhang: think these draft serve different purposes.

 - Zhang:
   There were two other parallel drafts presented in this WG (ZTE, Huawei),
   proposals use different address families. But now those authors have
   joined this draft.

- Toerless:
  Should better distinguish between use-cases in intro section:
  - Interdomain-multicast (full/limited form of Internet Multicast).
    Only SM is a standards option in this, so the procedures to support PIM-SM
    are not applicable (because there is no interdomain standards track solution
    for PIM-SM/ASM).
  - Controlled domain multicast with PIM-SM.

- Toerless:
  how about mentioning 6PE more explicitly ?
  A: Yes, that is a use-case.

- Toerless:
  - Would be good to mention in the introduction what alternative
   procedures exist. Eg: For use-case Internet Multicast or controlled
   global-table multicast with SSM-only, and PIM or mLDP the use
   of simply BGP-SAFI2 plus RPF-Vector.

- Toerless:
  - Would be nice to have a more concise summary of the differences over
    L3VPN procedures, the draft is very detailed.

---------------------------------------------------------------------------
draft-coras-lisp-re
Coras, 15 min

- Florin Coras:

- Greg: There is not really a topology available in the database,
  but just list of available resources, so trying to figure out some
  topology sounds like a fairly complex algorithm. Where is this ?

- Florin: Some slides down. Could use BGP, could use Geo-Coordinates,
  could use ping-measuring. Can register more information to the mapping
  system. Offers ability to clients to choose their upstream.

- Greg: Throughput restrictions because of hop-by-hop unicast replication.

- Greg questioning slide 9.
  Florin: Initially thinking of layer 0 close to sources, layer 1
  close to receivers.

- Greg: (slide 13): You are still binding ? Yes.

- Slide 14: When tree is built:
  ETR asks MS. MS replies with list of available RLOC. Each might carry
  attributes like GeoLoc. ETR caches possible RLOC and chooses. Sends
  LISP or PIM signaling to chosen RLOC. Join-Ack follows.
  RTR2: map-request S-EID to obtain ITR's RLOC. Sends...

  Ongoing development work. 2 very experimental implementations. One from
  Dino, one called "lismal" ?

  Some overlay controller needed ?

  Doing Many-to-Many delivery - ASM ?

- Stig Venaas:
  Interesting part is tree-building. Similarities with AMT ?! How do
  you pick best r

- Toerless: Compare with CDNi, different policy. Unclear how existing
  workflow can work in the face of interdomain deployment.
  A: Yes, it's a two step process, this might help to avoid having all
  policy central on the MS.