IETF 89: Open Shortest Path First (OSPF) WG Agenda Monday, March 3rd, 2014. 09:00 - 11:30 AM Morning Session Location: Richmond/Chelsea/Tower ======================================================== Chairs: Acee Lindem Abhay Roy WG Status Web Page: http://tools.ietf.org/wg/ospf/ 1) Administrivia - 5 minutes - Blue sheets - Scribe/jabber - Jabber room: ospf@jabber.ietf.org 2) WG Status Update - Abhay Roy (See Slides) 3) OSPFv3 LSA Extendibility Update - Acee Lindem (See Slides) - https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/ Acee: Motivated by source routing extensions (Fred Baker) Tony Przygienda: Good that backwards compatibility is "MAY". Agree very important. New TLVs added over time introduce complications as regards backwards compatibility. Acee: OSPF routers never modifies other routers' LSAs. David Lamparter: Add mode advertisement into Router LSA is needed. Acee: Allows extension of options bits - so using another of the fixed bits is probably OK. 4) OSPFv3 Auto-Configuration Update - Acee Lindem (See Slides) - https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-autoconfig/ Ran Atkinson: Preserving router-id across reboots should be MUST rather than SHOULD. Anton Smirnov: Clarification needed on applicability of draft Using in homenet OK - but could be used elsewhere in the future where collisions could be more likely. Acee: Has added statement that environments that cannot tolerate router-id ID collisions must manually configure router-id. Curtis Villamizar: Only for homenet. Fred Baker: Autoconfiguration can also be a requirement for campus networks (as well as homenet). 5) OSPFv2 Security Extension with Manual Keying - Manav Bhatia - https://datatracker.ietf.org/doc/draft-ietf-ospf-security-extension-manual-keying/ No discussion 6) OSPF Two-Part Metric - Jeffrey Zhang (See slides) - https://datatracker.ietf.org/doc/draft-zzhang-ospf-two-part-metric/ Acee: You don't need new encoding with uplink/downlink symmetric metrics? Jeffrey: Yes Ran: VSAT networks downlink/uplink bandwidths are asymmetric, good idea but not sure it is worth the complexity. Curtis: Loops possible if using inconsistent metrics on different routers. Who advertises the new metric - is it the DR/BDR? Jeffrey: Each Router advertises its own metrics. It is not backwards compatible - protocol changes enforce that compatibility regardless of which option is used. Curtis: Flapping legacy router could cause disruption - therefore Option #1 better. Abhay: Option #2 requires two different LSAs to provide full advertisement. More complex in OSPFv3. Curtis: Requires a flag day for changing to 2-part metrics - should be mentioned in the draft. 7) OSPFv3 over IPv4 Transport - Helen Chen (See slides) - https://datatracker.ietf.org/doc/draft-chen-ospf-transition-to-ospfv3/ Abhay: V6 link local addresses are cheap - but IPv4 address family virtual link solution is interesting. Ran: Have clients who want this. Cuts OAM costs. Even with forklift upgrade it is still worth it. Abhay: Address family draft addresses this in a different way - uses different link local encoding IPv4 address. Ran: Not practical for a known customer. IPv6 header is not allowed for a given customer's devices. Anton: Does savings include cost of converting from V2 to V3? Ran: Yes Abhay: Add text specifying IPv6 headers not allowed is a good deployment use case. Acee: If OSPFv2 is put in maintenance mode and new features are only in OSPFv3, This could be a use case for customers not wanting to migrate to IPv6. 8) OSPF Cross Address Family MPLS TE Tunnels - Anton Smirnov (See slides) - https://datatracker.ietf.org/doc/draft-smirnov-ospf-xaf-te/ Acee: Couldn't you use a OSPFv2 created LSP tunnel for IPv6 traffic? Anton: Yes - but calculating routes is difficult. Curtis: Could use MPLS V6 for V6 connectivity across a non-IPv6 part of the network. Extension could be used here. Anton: Valid - but normally one uses BGP for such a topology. This is targeted at full IPv6 deployment. Acee: This would be Informational draft. Internal implementation issue. Has more detail than IGP shortcuts RFC. Any IPR on this? Anton: No IPR. Interoperablity issues can occur if not all nodes support. Therefore athors think it should be standard. Also, required changes to TE to advertise both AF addresses. Alvaro: RFC 5786 restricts V4/V6 advertisements to OSPFv2/V3 respectively. This requires change therefore need a standards track document. Acee: RFC 6827 updated the same TLV - be sure to look at that. 9) OSPF Advertisement of Entropy Label - Xiaoha Xu (See slides) - https://datatracker.ietf.org/doc/draft-xu-ospf-mpls-elc/ Curtis: Routers do not have Entropy Lable capability - it is a property of each interface. Xiaohu: Unless all interfaces support entropy labels, a router can't support this extension. Curtis: This is problematic. Xiaohu: This has been discussed - decided to keep the same as RFC 6790 which requires all interfaces to support entropy labels. 10) OSPF Node Admin Tag - Chris Bowers (See Slides) - https://datatracker.ietf.org/doc/draft-hegde-ospf-node-admin-tag/ Curtis: Use 32 bits to align with RFC 3209. Align with Osborne RFC to extend that. Chris: These are values - not a bit mask. Acee: Can't use dedicated tag values since local policy defines tag meaning. Chris: Agree. Curtis: Can you use multiple tag values for different route types? Chris: Yes. Acee: The Router Information LSA can be extended to help support beyond the 64 tag limitation. Avoids needing to define new opaque LSAs for new capabilities. --------------------------------- Acee: Coming attractions: TTZ Implementation Experience Derek Yueng: Request OSPF WG to look at YANG OSPF draft. Acee: Please initiate a discussion on the OSPF list.