[OSPF] Draft OSPF IETF 68 Meeting Minutes

[Acee Lindem <[e-mail]>]

Thanks to Adrian Farrel for taking these minutes. The discussion of  
the PW3 multi-segment draft temporarily diverged from OSPF to whether  
or not this was the right way to solve this problem. Note that there  
were some speakers who are listed as "???". If it was you or if you  
remember who made the anonymous comments, send a unicast E-mail to me  
([e-mail]). Also, please unicast me any corrections.


OSPF Meeting IETF 68
Scribe: Adrian Farrel ([e-mail])

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


Thanks,
Acee

_______________________________________________
OSPF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf