AGENDA
------
http://www.maoz.com/~dmm/IETF/47/MSDP/agenda
http://www.maoz.com/~dmm/IETF/47/MSDP/agenda.mgp
http://www.maoz.com/~dmm/IETF/47/MSDP/draft.agenda

1.      Bashing
2.      Spec Update
3.      MIB Update
4.      MSDP Traceroute
5.      MSDP for IPv6
6.      IDMF (Interdomain Multicast Forwarding) [added to agenda

Scribe: Evi Nemeth ([email protected])

2. Spec Update
---------------
Meyer
http://www.maoz.com/~dmm/IETF/47/MSDP/update
http://www.maoz.com/~dmm/IETF/47/MSDP/msdp-spec-update.mgp

       o Point for GRE: Protocol numbers are actually DIX
         Ethernet numbers allocated by XEROX, not IANA. Need a
         solution for this. IANA allocated space?


       o TIMERS-

         -- SA-Advertisement Timer:

            Specified per SA not per (S,G), leaves granularity
            up to implementor. Tom Pusateri: do it per (S,G);
            its harder per SA. Meyer: unless anyone objects
            wants to leave it SA since gives implementor most
            flexibility. No objections.

        -- SA-Holddown Timer:

           New timer. We don't want to blast things out faster
           than receiver can process. Tom Pusateri doesn't think
           we should get to this level of detail, sounds like
           you should forward them.

       o NOTIFICATIONS

         New to the spec. The two of interest are SA-Request Error
         Notification and SA-Message/Response Error
         Notification. No real discussion.

3. MSDP MIB
-----------
Bill Fenner
http://www.aciri.org/fenner/mcast/msdp/msdp200003

       Fenner asked who is implementing the MIB.
       Alcatel going to, Cisco is implementing now.

       Fenner wants to have one MIB for IPv4 and IPv6. Note
       that redoing it would change all IP addresses to an inet
       type and address.  Wants to make that change now. messy
       because OIDS get out of order and need to be renumbered.

       Meyer -- This is not no work, but more work down the line
       if we don't do it now ("never easier than now"
       principle).

       Pusateri --  How do you pick an if_index if you are
       using loopback interface (this is for encapsulated data).
       Bad name for variable not the if_index of the peer its
       the if_index for the encapsulated data.  General
       question, does SNMP deal with encapsulated stuff or just
       direct stuff.

       Meyer -- If we put mesh groups into the MIB we need to
       document what they are; however, it's an implementation
       issue, not a protocol issue so they are not in the spec
       and therefore not in standard part of the MIB, put in
       vendor specific portion of the mib.

       Pusateri -- Mesh groups help with flooding. Not really
       different than default peer. Would like these things in
       the spec not just as implementation hacks.

       Meyer -- Well, default peer is dangerous so it was deemed

       necessary to comments about what not to do with it.

       Pusateri -- Same with mesh groups. so they should be
       in the spec.

       Meyer -- Mesh groups are deployed, so I'll put it in an
       appendix, and put default peer stuff there too.

       Fenner -- Need to clean up read-write read-only stuff,
       renumbering

       Meyer -- Do the stuff for IPv6 now. Agreement on this point.


4. MSDP Traceroute
------------------
Bill Fenner

       Like mtrace from mrouted distribution, want to trace the
       control path not the data path. need to get first packet
       onto the router. There is an issue with host
       implementations getting query packet to a router; the
       current thinking is UDP encapsulation. We'll defer
       discussion until after we talk about the general case.

       The real open issue is how hosts initiate an MSDP
       traceroute, since it is a router to router type function,
       but as is the case with mtrace, we will want host based
       implementations.  The current spec says that you must use
       UDP encapsulation of the TLV, so an MSDP implementation
       will have to understand at least this much UDP
       encapsulation.

       Alternatives:

        o Use SNMP as a generic signaling mechanism

        o Have a general control path type trace, not MSDP
        specific. New TLV space for this (i.e., don't take the
        TLV space from MSDP)

          Meyer --  Write a short doc on what port it uses and
          TLV (type length value) and do MSDP traceroute from
          it. Could have can get (e.g.) BGMP traceroute or
          mtrace too.

          Fenner -- This a big question, use SNMP or the
          Meyer/Pusateri generic version.

          Lothberg and Jhawk think SNMP is a bad idea.

          Pusateri -- Will the IESG let us do this or will they
          make us use some network management protocol.

          Meyer -- The idea here is to have a control protocol
          that is used to have the host ask the router to start
          a trace. Lots of control paths might need to be
          traced. Make the host to first router part be standard
          and not protocol specific (i.e. MSDP).

          Pusateri -- The router to router stuff over TCP hides
          loss, UDP could show loss and host could try again.

          Hall (jhall) -- Doesn't like a host being able to ask
          a router to generate traffic, a la like mtrace. Fenner
          says turn it off, jhawk says just rate limit it.

          Meyer -- MSDP traceroute document will be modified to
          reference the generic general tracing document and
          will get TLV values for it (if the approach is cleared
          by the IESG).

          Meyer -- Lots of folks are turning off ICMP to stop
          loss showing up. The generic approach lets you
          circumvent this and get your traceroutes anyway (and
          this is yet another thing that might need to be turned
          off if you are paranoid).

          Coltun -- I'll take it up with the management people
          in the IESG. The may say that SNMP is already a
          generic host to router signalling protocol.


5. MSDP For IPv6
----------------
Brian Haberman
http://www.maoz.com/~dmm/IETF/47/MSDP/IPv6/msdp_and_ipv6.ppt
http://www.maoz.com/~dmm/IETF/47/MSDP/IPv6/pim_for_ipv6_and_anycast_rp.ppt

       Pusateri -- IPv6 router should not be memory starved, so
       caching won't be turned off, can we make caching
       mandatory.  Question was not answered.

       Lothberg -- It is different, BGP talks between 2
       neighbors, who negotiate capabilities.  With MSDP could
       bring up a session between 2 parts of the network that
       don't speak ipv6 multicast to each other. If you want to
       support IPv6 you have an IPv6 TCP session, and to support
       IPv4 have a IPv4 TCP session.

       Coltun -- Everyone at an ISP has to do the same
       thing. Sounds like you should call out some of these
       things in the draft.  Brian said ok.


6. IDMF (Interdomain Multicast Forwarding)
------------------------------------------
Atsushi Iwata and Masahiro Jibiki from NEC

       This was first presented in MBONED but we ran out of time
       there. However, at the end of the MBONED talk it was
       proposed that the IDMF forwarding model be integrated
       with MSDP. They also asked for the creation of an IDMF WG.
       Meyer stated that we can't create a working group here,
       we are the wrong forum. Preference is to have a separate
       document for MSDP forwarding and submit it to the working
       group as a personal contribution.

       Lothberg -- Packets will not come in on RPF interface and so be
       dropped on the floor, seems like it conflicts with MBGP.
       Unicast source may not be on the same path as the multicast
       source. how do you make internal routers RPF check within
       a domain.

       The conclusion is that the authors will submit a personal
       contribution dealing only with the forwarding component,
       which will be considered by the WG.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.