2.5.7 Multicast Source Discovery Protocol (msdp)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99

Chair(s):

David Meyer <dmm@cisco.com>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@siara.com>

Routing Area Advisor:

Rob Coltun <rcoltun@siara.com>

Mailing Lists:

General Discussion:msdp@antc.uoregon.edu
To Subscribe: majordomo@antc.uoregon.edu
In Body: subscribe msdp
Archive: ftp://ns.uoregon.edu/mailing-lists/msdp*

Description of Working Group:

The MSDP working group will be charged with standardizing MSDP, the Multicast Source Discovery Protocol. MSDP is a near-term solution for connecting shared trees without the need for inter-domain shared trees (it is envisioned that the Border Gateway Multicast Protocol, BGMP, is the long term solution). MSDP is applicable to shared tree protocols such as PIM-SM and CBT, as well as other protocols that keep active source information at the borders (e.g., MOSPF or PIM-DM with DWRs). This working group will interact closely with both MBONED where operational issues arise, and IDMR where necessary for protocol issues.

Finally, it is envisioned that this working group will have a fairly short live span.

Goals and Milestones:

Dec 98

  

Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items.

Dec 98

  

Submit MSDP Internet-Draft to IESG for consideration as a Proposed Standard.

Apr 99

  

Submit MSDP specifications to IESG for consideration as Draft Standard.

Apr 99

  

Submit MSDP Applicability Statement to IESG for publication as an RFC.

Apr 99

  

Submit MSDP MIB to IESG for consideration as proposed standard.

Internet-Drafts:

No Request For Comments

Current Meeting Report

SPEC UPDATE And OPEN ISSUES

Last Time (see Meyer slides)
Encapsulation Proposal (see Meyer slides)
Comments:
Thaler on limiting encapsulations: spec must limit it to something that can carry additional information; not IPIP

peer-RPF Rules

Accept an SA message originated by RP R from neighbor N in AS A if any of the following is true:
i. If N is R.
ii. If A is the first AS in the AS-Path of the BGP route towards R.
iii. If N is the iBGP advertiser of the BGP route towards R.
iv. If N is the MSDP default-peer. (Note that default-peer needs better definition)

Pusateri: flooding has advantage of "healing" connectivity
Fenner: stricter RPF allows traceroute, which is useful for lots of reasons including being able to track down the black holes that exist with stricter RPF

default-peer:
Meyer: standardize?
Pusatari: objects because pushes problem towards the center of the net
Thaler: should standardize; rules are:

Fenner: maybe could just use 2,3 if you're doing MBGP

Pusateri: How does the peer-rpf stuff interact w/anycast RP?
Lothberg Use the router-ID to MSDP-peer andRP's insert their router-ID in the MSDP message so rule (1) works

Pusatari: the word "accept" isn't well defined
Fenner: "keep" (put in your cache)
"use" (from your cache)
"forward" (to your neighbors)
defining these words allows talking about Tom's debugging-friendly caching without specifying it in the spec.

TCP CONNECTION STUFF:

Dave Oran: worred about tail-drop
Fenner: "hold-down" is the real solution, the TCP thing is the minimal thing - there's a scale along which TCP thing is almost right next to where we are today, but it's a small thing to do and could make things a little better and I don't think makes things worse.
Lothberg: let's never drop TCP connections.

On "hold-down":
Consensus on making hold-down mandatory if caching.
no consensus on making caching non-optional
Lack of consensus on caching optional.
Consensus on hold-down with SA-caching

WG STATUS:

Pusatari: Do we want to go standards track, or just use it for now? If not standards track, why spend a lot of time fixing stuff?
Hall: Now is "later" when we decided to do stuff later (like incr.)
Lothberg: Incremental update has to be able to withdraw, etc.

Meyer: History: wanted periodic so that you didn't have to cache
Dino; it'd be nice to know where we're going to go; if MSDP is short term. Then we shouldn'tmake *any* changes if we know where we're going, put hooks in MSDP to make transition work - so when you throw away MSDP you throw away the hooks
Meyer: msdp is here, SG scaling is what people were worried about but aren't any more. msdp's lifetime won't necessarily be that short (eg anycast RP)
Dino: Scared of interworking between all these protocols (like MSDP & *)
Pusatari: Trend: EGP's becoming IGP's
Cain: It looks like it'll be around, let's do some of this stuff
Meyer: Let's do standards track, fix up encapsulation, RPF, diagnostic
Meylor: characterize it as a way to get data between RP's, don't say inter-domain or intra-domain- just "inter-PIM-domain"
Dino: MSDP is just like DNS - used inside, outside, domains
Hall: We're saying "no way we can put this into the standards track the way it is so let's make up a lie and put it in the AS"
Meyer: MSDP is just here for bootstraping multicast stuff, it's not really dishonest to say we want to standardize it. If intra-domain, MSDP could have a lot of life
Dino: and if it's a subset of the space, it could be used inter-domain
Hall: How much time would it take to fix it? How much time are we wasting on discussing it?
Coultun: "just one AD opinion": wants ops folks to decide whether or not to fix it and move on --they should get together and decide and let us know what they think.
Lothberg: We should fix the protocol and say here it is and document it properly and give proper guidelines for its use (basically supporting what dmm said)
Kim: Pretty much agree with peter - msdpv2 should be decoupled from doing what we've got plus the current fixes
McPherson: Agree.
Meyer: Summary: peter and dorian agree, McPherson summary: new stuff in current spec, capability stuff, applicability statement
OTHER ISSUES

Notification Message

Thaler: Should look exactly the same as BGP or BGMP - it's your way to get an error message to a different organization can it be done in a backwards compatible way? proposal: notification TLV, format like BGP legacy guys will just ignore it when they get it

TODO: dmm & bill do a summary of the tools like mantra & bill-stuff

documents:

Slides

None received.