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