Meeting Minutes
Multicast Source Discovery Protocol (MSDP) Working Group
IETF 43 - Orlando, FL
9AM Wednesday, December 9, 1998
Scribe: Bob Quinn <[email protected]>

WG Chair: Dave Meyers <[email protected]>

Agenda:
=======
o Agenda Bashing       -- Meyer
o Charter Review       -- Meyer
o Protocol Overview    -- Meyer
o Encapsulation Issues -- Bill Fenner / Tom
o Deployement Update   -- Lothberg
o Anycast and MSDP     -- Dorian
o Closing/Action Items -- Meyer

--------------------------------------
Charter Review -- Dave Meyer (Cisco)

Dave Meyer explained that MSDP is an old-style working group, in the
tradition of former IETF working groups.  It was formed based on
working code, and our plan is to have it get to proposed standard as
quickly as possible.  Other docs would be an applicability statement
and a MIB.  The applicability statement is covered, but we need
someone to volunteer to do the MIB, so if you are interested contact
Dave.

If we meet the proposed milestones, the WG will last about 6 months

--------------------------------------
MSDP Overview -- Dave Meyer (Cisco)
slides: ftp://ftpeng.cisco.com/IETF/MCO/MSDP/MSDP
draft:  "Multicast Source Discovery Protocol (MSDP)",
       <draft-farinacci-msdp-00.txt>, June, 1998.

Dave provided a high-level description of MSDP

Purpose: Inter-Domain Multicast Routing
- Providers want PIM-SM backbone and needed interdomain routing
- Flat RP space was inappropriate
- How to connect multiple shared trees
- No shared 3rd party resource dependencies

BGMP: our desired longer term solution
- seeking near-term solution
- MSDP is short-term

Connecting Shared Trees
- Basic idea: Let RPs know where all sources are
  (RP knows where all receivers are too)
- MSDP just advertises where all sources are
- Uses TCP between RPs
- Can be multihop
- MSDP works entirely in the control plane
+ not data forwarding (unless you use tunneling)
+ After one RP joins group of another, it is not necessarily
  true that data will follow same path as RP-to-RP route.
  The two routes need not be congruent.

Other Design Points
- Idea was to design something MBGP-like
- MSDP speaker can cache SA messages to reduce latency
+ doing so is also very helpful for diagnostic purposes
- SA Messages are fowarded in RPF fashion to prevent looping
+ RPF check is on AS-PATH back to the peer RP

MSDP Open Issue:
- Proxy at DM interconnects??
+ when data is DM flooded across interconnect, it creates (S,G)
   state on the RP
 = in which cases should the RP send SAs for those sources? --->
   this is something that could go into an applicability statement
- Security:
 -  Possibly keyed MD5 so no weaker than BGP, which should be
    sufficient (also like OSPF).

Comment: I think it would be useful to get a picture of how things
hang together

Sue: Can you add an example of split horizon and poison-reverse?

Question: On Rob's question about the applicability of BGP,
something was written up
DM: I think what Rob wants is an applicability statement since there
are different ways to use ASFI (???)

Question: Is there a problem when stub site is in congruent (???
not sure I got question right)
DM: Not required, but makes it easier if it is.

Brad _____: I'm concerned that MSDP has a potential for looping
(??? I missed the condition)
DM: Good point and we had discussed that

Comment: It MD5 the de facto security approach
Comment2: I talked with Jeff Schiller about PIM and he said that
you need to use AH, though the others squeaked by
DM: We will need to bring it to the list.
Comment: An advantage of using AH is that you use security
implementation of the host

Other Open Issues:
Brad (again): The loop potential is a concern
DM: I don''t think this is specific, but may be more general
Bill Fenner: I have been wary of RPF, though don't know of specific
example

-------------------------------------
Encapsulation Issues -- Bill Fenner (Xerox Parc) and Tom

They expressed concern with using TCP for a routing protocol,
and especially to send data along with the SA.

Mark Handley also pointed out that using TCP affected the latency,
which can vary the RTT.  This is a problem since RTT is used by
Reliable Multicast as part of congestion detection algorithm,
so arbitrary changes can have a serious adverse affect ("RM would
be a non-starter").

Bill's suggestion was that SA's should be sent via UDP or
directly over IP.

Others (like Dino Farrinnaci and Peter Lothberg) said the reasons
for using TCP--besides simply emulating BGP--are that
 1) they wanted to ensure that the policy info in an SA was
    delivered before data, and
 2) that the info sent may be too big for a single datagram.

There wasn't any resolution of the issue during the meeting, and
Bill and Dave said they'd pose the question on the mailing list.

PostScript:
There were some small-group discussions immediately after the
meeting in which Dave Thaler pointed out the much larger problem
using TCP with bursty sources, in which the first data packet is
sent via TCP successfully, but all subsequent datagrams are lost.
After some discussion, those in attendence agreed that it would
be possible to send the SA in parallel using *both* TCP *and* UDP.

------------------------------------------
Deployment Update - Peter Lothberg (Sprint)
- we have PIM-SM with MSDP using the MIX <draft-lamaster-mix-01.txt>
- Goal is to make multicast work as stable as unicast
- biggest issue is trouble-shooting a large multicast deployment

Dorian (???)
- We too use the MIX connection
- We are also really short on debugging tools, mechanisms

--------------------------------
Anycast - Dorian
Illustration showed slide with three ASs, each of which have RPs
that talk, and sources, and two of each in the middle.

     AS1:                   AS2:                    AS3:
  +-------+      +------------------------+      +-------+
  | RP, S | <--> | RP, R, S      RP, R, S | <--> | RP, S |
  +-------+      +------------------------+      +-------+

Dave Meyer: so what you are saying is that with Anycast, you can
have the closest RP forward the data to you.  (???)

Dorian: yes.  And we will try to go ahead with it (???)

------------------------------------
Dave Meyer
- We need other implementations to move forward, we need interoperability, so are there any others that
people are willing to talk about
- Tom said he is starting one (under Dorian's orders) and Sue said she is also

Outstanding Issues before Last Call Slide (again):
- Encapsulation (TCP or UDP or both??)
- Security (AH or BGP-like MD5 keying??)
- Sue's example
- Need someone to volunteer to do a MIB for this .  Please speak to me.

Meeting broke at 10:20AM

As mentioned previously, there was a long after-discussion on
the encapsulation issue with a focus on the issues of supporting
bursty sources, in particular.

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.