OSPF Meeting IETF 68 Scribe: Adrian Farrel (adrian@olddog.co.uk) Bill Fenner's last meeting as AD Dave Ward will be new AD *** See Slides as a companion for the minutes. *** ---------------------------------------------------------- Doc Status - Acee ---------------------------------------------------------- - OSPF IANA considerations - Approved but update needed to resolve registry issues - Will get submitted as soon as queue re-opens - Will be approved to RFC Editor at once - TE extensions to OSPFv3 - Time to publish because other I-Ds build on it? - OSPF-node-addr-te - Will try to close this during the week - LLS already implemented and deployed - OSPF v3 mib getting stable - Acee has reviewed - mirtorabi-OSPF-tag - Definitely a requirement - But need implementation commitment Thomas Clausen - Manet draft intended status? - slide says Informational but should be Experimental - is there a jabber scribe? - no answer Acee... Bill Fenner - Note that the bar is lower on experimental drafts than proposed standard but they still go through the IESG. Acee... - OSPF hello reply draft now "dead" ---------------------------------------------------------- RFC 2370-BIS - Lou Berger ---------------------------------------------------------- Lou - What's next? Acee - Update as soon as possible and then last call Lou - Changes are trivial Acee - Ok, we'll do WG LC immediately after meeting - No backward compatible issues ---------------------------------------------------------- OSPF-mpr-ext - Emmanuel Baccelli ---------------------------------------------------------- Acee - What about my suggestion to only calc 2-hop shortest path in one direction only come adjacent with SP Emmanuel - technical issue - advertise as chosen MPR Acee - How many read this version? - about 5 - How many read any MANET? - plenty - Is this different from Chandra draft? - In my opinion, yes. Different criteria for flooding selection MPR versus (MPR U shortest 2-hop path) Emmanuel - Yes mechanisms on slide 3 are different Acee - Only similarity is heuristic to select mpr is very similar - Robustness is very different - So we will have three alternatives in this area with experimental drafts - I think getting these drafts to state where WG is happy (but not necessarily agree which approach is best) is important. So we can experimentation can proceed. ---------------------------------------------------------- OSPF-pwe3-ms-pw - Andrew Dolganow ---------------------------------------------------------- Adrian Farrel - Congrats in OSPF WG in getting requirements from other WGs presented. - Has reservations with the draft - will take up in PW3. - What is t-ldp? Andrew - Targetted LDP ??? - Multi-AS support? interact with bgp Andrew - Limit to single AS now ??? - Don't we need to describe interactions Acee - No, heretofore we haven't standardized internal interactions between protocols ??? - Need to propagate information between instances ??? [2] - There are already BGP extensions! Dimitri Papadimitriou - Propagating this information is not incompatible - This is not dynamic so no churn in OSPF - Full compatible with OSPF Acee - Not agree completely - Given PE could advertise many PW3 access circuits Dimitri - Capacity advert is stable and depends on capacity of the edges Acee - What if resources become unavailable - stop advertising - Will you stop advertising if unavailable - this is dynamic? Dimitri - This is just reachability information Andrew - Tes, it would be painful to advertise changes - Need way to aggregate addresses Acee - So access circuit advertisement will not be withdrawn if temporarily down - Why isn't this like vpls? why not done in LDP as part of discovery provisioning Dimitri - Because it relies on the routing engine to propagate the information Acee - LDP relies on the routing table today. how is this different? Dimitri - You are making use of the segments that are available today - Making use of the informaiton about the next hop over which to propagate the information Acee - At a basic level you are advertising MPLS FECs - This goes to every router in the domain Luca Martini - SPF external routes do exactly what is needed Acee - Can't do it with LDP because the ASBR might not be reachable Luca - No a path is needed - You would need LDP to run in hop-by-hop mode. This is the disadvantage Acee - This is done in L3VPN Luca - but it only distributes labels - I wrote a similar model for BGP for inter-AS Acee - We haven't done this before - For everything I don't like about this draft, it is good that we have requirements from providers - We will talk more on the list about whether this is a good thing to do for OSPF - Not sure if this is better than using LDP Gustav - Before MS PW, PW was single hop - All you had to do was look up your next hop - Didn't have to do routing because IGP did the routing - Now we are switching the pw in the middle of the n/w so there may be routing issues (spf, loops, etc.) Dimitri - LDP is used to make the segment, not to propagate information about the segments Acee - I was making the assumption that the information would be propagated as per labels and prefixes in l3vpn Andrew - figure on slide 3 may be confusing. black lines may have multiple routers on each segment ??? - If you don't have end-to-end signaling you can't request protection - You cannot take advantage of existing mechanisms Andrew - You have per-segment recovery ??? - If there is a degradation of protection availability, this not advertised Andrew - Correct, not our intention ??? - But CPE wants to know that this happened Andrew - Pseudowire goes down Lou - An alternate way to address this problem would be to re-use TE - Treat ms-pw as another switching layer - Bring up virtual links Acee - Would be more painful Lou - It is just a usage profile Acee - It wouldn't scale Andrew - You don't need "TE capabilities" Lou - You can do an equivalent thing using another switching layer - No matter how you do it, it does not scale - Should you implement using existing mechanisms Acee - Treat each AI as a separate TE link Lou - Treat the MS PW layer as another switching layer Acee - Still need to pass around information Lou - Just a small extension Acee - Continue discussion - Application is with pwe3 - Use of OSPF is with OSPF wg - Draft status is "open" ---------------------------------------------------------- Database Exchange Optimizations - Acee ---------------------------------------------------------- -Will last call soon. -No comments on slides ---------------------------------------------------------- OSPF v3 automated group keying Requirements for MSEC - Michael Barnes ---------------------------------------------------------- Acee - Looks like requirements hard to satify - chicken and egg problem Michael - Not an easy problem to solve - Not ready to jump right into solutions, hence this document ---------------------------------------------------------- OSPF WG Document Candidates - Acee ---------------------------------------------------------- - Stronger non-IPsec OSPFv2 security - how many read these drafts? - just 2 - I think there is a lot of support - OSPF v3 showed us there are hurdles to get IPSec to work (e.g., no replay protection) - OSPFv2 ipsec security - How many read? - Zero - Bill Fenner - Advisablity of having both? - If you are doing both, why continue with IPsec because of the limitations - Acee - Because someday we will solve IPsec - Direction from Security Area - Suspect that rpsec community would have read these I-Ds - Graceful restart update - Read? - Three - Need explicit helper signaling? - No one - Want to do something with the draft, not keep discussing it - OSPFv2 optional route/link attributes - Acee is an author, but thinks need commitment from someone to implment it - seems that it could be a moderate amount of work and is complicated - Read? - 4