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 - Meyer: must at least do GRE, no reason to limit it to that - Thaler: what about NOTIFICATION? peer-RPF Rules - See Fenner slides. basically, 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: - if you're doing MBGP, use rules 1,2,3 - if you're not, use rules 1,4 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: - spec - capabilities - traceroute - applicability - mib