Subject: mboned: Draft minutes of the last mboned session in San Diego (IETF-67)

From: Hiroshi Ohta <[email-masked]>
Date: Wed, 22 Nov 2006 18:36:34 +0900

All,

Attached below is the draft minutes of the last mboned session 
in San Diego (IETF-67) mostly based on the Gorry's note (Thank you, Gorry).

If you have any comment, please post it by the end of the next week (i.e., Dec. 1).

Thank you.
Hiroshi and Marshall

------------- draft minutes ---------------

mboned WG  

THURSDAY, November 9, 2006, Morning Session I

Chair(s):
    Hiroshi Ohta
    Marshall Eubanks

Note-taker:
    Gorry Fairhurst

1. The agenda was presented.

2. WG Chairs reviewed the document status.

    RFCs published since last IETF are:
       draft-ietf-mboned-ssm232-09.txt       -->  RFC4608
       draft-ietf-mboned-msdp-deploy-06.txt  -->  RFC4611
       draft-ietf-mboned-mroutesec-04.txt    -->  RFC4609
       draft-ietf-mboned-msdp-mib-01.txt     -->  RFC4624

    Documents that are in/completed WGLC are:
       draft-ietf-mboned-routingarch-06.txt

Marshall noted that the address architecture I-D had re-entered a WGLC for
rev -05, after changes from rev -04, which had already been WGLC'ed. The
call was now complete. 

Publication requests by the WG Chairs to IESG were being prepared for:
    draft-ietf-mboned-addrarch-05.txt (proto shepherd Hiroshi Ohta)   mini last call, no comments
    draft-ietf-mboned-maccnt-req-04.txt (proto shepherd: Marshall Eubanks)

3. Active Drafts and related issues

---
Report on AMT prototype implementation,  Dino Farinacci

Dino presented a CISCO implementation report for AMT - IPv4 (information may
be available on IPv6, perhaps by the next IETF) Cisco Implementation Status - Coding and Syte Test completed (see slides). 
UDP-replication on road-map for next generation ASICs (zero UDP checksum), agreed in 06 draft
There could be a 2 byte compressed header instead of 4-byte (this would not be backwards
compatible). This could appear in rev -07. Next IETF, there may be
interoperable implementations, and some experience with pilot deployment.
AMT implementations 	microsoft 	cisco -Dino 	freebsd/linux- Tom Pusateri, Greg Shepherd Milestone March 2007 hope to get interoperability between those 3 implementations 
    Tom Pusateri  (TP): We have a temp. prefix and AS number, need approval of doc for IANA to get prefix
    Marshall Ewbanks (ME): We need to get IESG approval to get a
    permanent IANA assignment.

    ME: Was the BSD implementation ever ported to MacOSX?
    TP: The relay works, but not the gateway.
    There is some work to port the TUNtap driver to this OS.
    ME: This port could be a useful thing to do.

    DF: There is a call for interest in performing a trial.
    ME: What is involved to do a trial? What does a content provider need to do to take part? 
    Greg Shepherd (GS): Content providers, etc
    ME: Does VLC support this?

    Tim Chown (TC) : Can you say what is a CISCO PC?
    DF: CISCO OS running on a PC platform. Currently not a product.

---
AAA Framework, draft-ietf-mboned-multiaaa-framework-02.txt, H. Sato

A significant update was presented (see slides).

    ME: How many people had read this 6-7?
    ME: How many people think it should advance? (2)
    ME: Who has reasons why this should not advance? - No response.

    David Kessens (Ops AD): Does anyone need this? - No response.

    ME: Are there implementation plans for the framework?
    Thomas: Operators are interested in this.
    ME: Operators may be interested, but we do need to see their
    inputs here in this WG.
    HOhta: The aim is to bring operator needs to the group. Another author from an operator has been introduced as a coauthor.     ?: is Christian's support institutional or individual?  
    Marshall thinks it should advance, but no reaction
    ME: I don't see a strong interest here. We will take this to
    the list.

---
Multicast MIB draft-ietf-mboned-ip-mcast-mib-03.txt - David McWalter

Now completed WGLC (-02), there is a need now for Routing AD inputs, and MIB
review). Trying to get expert review. Fixed language tag Interface table has statistics Current changes editorial (see slides).
    Martin : Speaking as an operator. When using mrtg, having the
     ifindex in last position is preferred (the ordering as before)
    - please leave the interface index as the last index
    - either have inetversion somewhere else or leave inetversion out (as is).
    DM: Either way, his table should be consistent with the ifstats,  consistency with other table would be good
    I will talk to you.

Counter32s can now be discounted, and just use counter64s.
RFC2932 fields that say which protocol works over an interface will be
removed (recommended by Bill Fenner, Bill Fenner talked to some people-- they think deprecation would be good).

He proposes to make the required changes, take to ML and then to request a further WGLC
(and at the same time request MIB doctor review).

    ME: Please post this to the list. Is anyone unhappy with a WGLC?
    - We can issue the WGLC next week.
question about process for MIB 
    DK: MIB doctors can be requested by the WG Chair, or we can
    request this. It should not be someone who was involved in
    making the MIB.

----
4. Individual Drafts

draft-ycai-mvpn-deploy-00.txt, Michael McBride (MMB)
- comprehensive draft about deployment experience hopes mboned group will adopt 
    Yakov: Do you have one case, where you deploy a MVPN over the general
    Internet?
    MMB: No.
    Yakov: This was recommended to bring it here. this draft is useful but that     not public internet so interlap is zero
    Yakov: This should be done in L3VPN.
    ME: Has it been presented at L3VPN?
    MMB: Yes, as far as I know, it was not requested to be adopted.

    Yakov: This is about VPNs, not use in the general Internet, these
    are different.
    GS: We need to remember these issues, when we re-charter mboned.

    Yakov: The core expertise is in the L3VPN document.

    GF: The technology seems that this talks about seems like the sort
     of things that we know about - operations aspects of mtrace, PIM,
    addressing, etc.
    Yakov: The technology is really a L3VPN issue, that is a different set
    of issues, to those in mboned.
    Leonard Giullard: agree with Yakov, has nothing to do with mboned although a     good draft.  This is the mboned, the document is about
    VPN issues.

    DK: Are you sure that OPS groups know less than non-ops groups
    about multicast deployment?
    Yakov:I was surprised the authors did not send comments to the
    L3VPN group.
    MMB: They had not yet.
    ME: It would be good to see pointers sent to documents on
    both lists (this does not seem to be happening).

---
Benchmarking MVPN, draft-sdry-bmwg-mvpnscale-00.txt, Silvija Dry
MVPN many service providers deploying - no standard way to measure MVPN scalability - wants to define methodology to size networks - scaling for stability and failure recovery capabilities of the network are assured Goals to define the MVPN metric set - can be used by "MVPN Deployment Recommendation" mboned-mvpn-deploy 
The work will be done in the BenchMarking (BM) WG, the question concerns
would these metrics be useful to people here (operators)? doc overview, in addition to single variables, used requirement survey to define scenarios - a few service providers want to contribute - want more people from mboned to contribute 
    ?: How about adding the number of neighbours?
    SD: We have not seen networks with large numbers of PE
    neighbours (just a few), so not currently included, but
    could be added for completeness.
    SD: Are you asking PE<->PE routers?
    ?: Yes.
    SD: We do this.

    ?: The right direction is not to include issues that are already
     covered in other BenchMarking WG RFCs.
    SD: Yes, but there are things that need to be included to offer
    customers ability to understand the impact of PIM choices in
    the core.

    ME: Was this document brought before the BM WG?
    Were there many comments?
    SD: Yes, at this IETF. There was some comments.
    ME: Is this within the BM WG Charter?
    SD: Yes - but, but that group is too general, the specific technical     expertise on multicast is not within the BM WG,     so we need to work with mboned. We will
    also talk about this in L3VPN in the future. We expect to see
    it adopted in the BM WG.
    ME: Will you take responsibility for forwarding comments back from
the mboned list? 
    SD: Yes.
    ME: Can the mboned WG please read and comment to the list?

---
Lightweight IGMP/MLD, draft-liu-magma-igmpv3-mldv2-lite-02.txt, Liu Hui
[see slides]
Updated since rev -01 and has added SSM related requirements, and compliance
to MSF API filter specs. * joke to rename original to IGMPv3 Heavyclarify record types * explanation of tables * merging an unsolicted report option is optional

    ME: Cisco have already use the term "IGMPv3-Light", does the
    name of the current ID need to be changed?
    MMB: We could ask within Cisco. Cisco's use was an interim
    solution.
    ME: Two different names can always lead to confusion.
    ?: We would be wise to change (others also agreed).
Joke to rename original to IGMPv3 Heavy
    GF: Can we confirm that the goal is to be fully interoperable with
    standard IGMPv3? will this be backward compatable?
    ME: Yes, that is my understanding.
    SS: We do have a lightweight implementation and we have confirmed
implementability for SSM deployment.
    ME: Are there any open source versions?
    LH: Yes, and we shall confirm the goal of interoperability.

    ME: Who thinks this should be adopted by the mboned WG?
    (Many hands)
    ME: Those against adopting this? (No hands)
    ME: We'll now take the question of adoption to the list.

---
Mcast.arpa draft-koch-mboned-mcast-arpa-00.txt, Peter Koch

Please can the WG review the draft?

    LG: Why remove 224.1 and 224.2?
    PK: Is this SDP?
    LG: That's one use.
    PK: I didn't see the use. IANA needs clear guidelines.
    LG: I think whatever value for 224.0, it's also valid for 224.1
    and 224.2. If one sees a weird group this can be looked up,
    and that is useful.
    PK: This is not the reverse-mapping part, we can see the value
    in that.
    LG: My statement was on the reverse DNS case.
    ?: If reverse was just used for addressing, then you may wish
    to do both ways.

    Stig Vernaas, SV: I think this is a good idea.
    Can you be sure this will be maintained bette than current use?
    PK: The aim is to setup a policy (amend BCP51).
    SV: OK.
    ME: If I define a new protocol, will IANA make an automatic
    appropriate entry?
    PK: The group allocation for these ranges are made by IANA,
    and they would then allocate the name when the address
    registration was made.

    SV: There are IPv6 prefix-based addresses - a unicast address
     delegation could also get a multicast delegation for the
    corresponding addresses.
    PK: This involves regional registries for addresses.
    SV: Yes.
    PK: This is beyond the scope for this particular document.
    TC: You'd also need to consider scopes. You could also do
    things with Embedded RP addresses.

    ME: GLOP addresses are still used. were you proposing to include glob?
    PK: There are management and maintenance issues.
    These are not done by IANA, RIRs give AS numbers.
    SV: Looks similar to IPv6 unicast prefix addresses.

    ME: Can we adopt this as a WG item? (many hands)
    ME: Those against adopting this? (No hands)
    ME: We'll now take the question of adoption to the list. 

---
SSM Ping, Stig Vernaas.

Presentation of the slide, and a request for IANA for assignments?
    Bill Atwood: Please ensure the slides get on the web page.
    PK: Specification is required for a port assignment.
    A document is required to get an allocation.
    TC: There was a previous SSMPING draft discussed some time ago?
    I'd like to make sure there is no chance of confusion.     ME: Marshall:thinks to get port number, need to go through RFC     can anyone lend for purposes of testing 
    ME: Does anyone know of the use of that? (No one did.)
    GF: You can always publish this as a I-D, at least it gives
    visibility and a known name.
    ME: Yes please do that, and submit an I-D, we can then talk
    about this on the list.

---
5. Charter Discussion/Multicast survey status/AOB

Multicast Survey Results, Eubanks/Leymann
Large scale IP-multicast deployment rarely at ISPs during the last few years but last year IPTV is driver to make it pick up, now considered a best common practice Goal: we did survey kind of focused on 3P issues showed section of the questionaire (see slides) received 9 responses General IPTV/ Multicast requirements - how many content resource - 2 to 30,000 median was 1000 
    ME: Any comments on the survey?
    Yakov:   Caution is needed for surveys, a sample of 9 is very small.

    ME: Greg Shepherd suggested a name change to Multicast OPs.
    ME: is MBONED needed?     most deploying are not IETF participants      some options: either wind it down or expand its reach 
    Yakov:  IGMPv3 is a change to the protocol. This group is not in
    the routing area and this is a protocol spec, it's not in the
    right area. If this is a routing issue, it should be in the
    routing area.
    ME: MAGMA was closed down.
    Yakov:  A discussion needs to be made with routing ADs.

    TC: What about debugging - guidance is a good thing.
    Taking this forward would be a good thing.
    ME: The people who need this are not here - is this an active
    IETF activity?
    TC: There are separate views as a consumer (not provider).

    LG: 2 biggest questions: Scope of networks, needs to be understood;
Protocol development has been talked about and done in mboned.
    ME: On the protocols, it is the same group of people who do the
    work, so thats a complication. On the first point, there is
    expertise here in multicast deployment and protocols, L2VPN
    and L3VPN have other groups working on this.
    Yakov: There's also MPLS. There's also a question of OAM.

Hiroshi Ohta presented a summary presented of the discussion on charter from
the mailing list following the Montreal IETF.

    MMB: PIM is also expanding the charter, expect this to be done
    by the next IETF.
    ME: I think we should talk about where the boundaries should be
    drawn between the new Charters of the two WGs.
    MMB: Yes - both groups are seeking new Charters.
    Tom Morn (TM): Deployment is currently walled-garden.
    This has not been the focus within mboned. Other groups focus
    on the walled garden, and these groups have less experience,
    we need to continue work that is appropriate and profitable
    for a range of business models (AAA and management for as
    an example). This work should be done in the IETF.
    New protocol extensions may be needed.     ME: enterprises have no place to go. idea of setting up a forum
    SV: Some people are trying to develop inter-domain services.

Important tools are beacons, mtrace, etc. These are important to the IETF.
    ME: Should we encourage the dbeacon people to come?
    HAsadea: Mbone is a good place to work on multicast protocols.
    Why is MAGMA closed down?
    ME: The WG was wound up when the work was done.

    JE: How many enterprises are in this room?
    There are many more of these enterprises who do not seem to
    be represented in the room.

-------------- end ----------------

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/