Hi Shraddha, From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>> Date: Friday, January 12, 2018 at 3:07 AM To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>> Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>> Subject: RE: OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC
Acee, Pls see inline.. From: Acee Lindem (acee) [mailto:a...@cisco.com] Sent: Wednesday, January 10, 2018 7:51 AM To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>> Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>> Subject: OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC Hi Shraddha, We noticed that RFC 5817 sets the TE Metric to 0xffffffff for graceful TE shutdown and the OSPF Link Overload draft uses MAX-TE-METRIC (0xfffffffe). Two Questions: 1. MAX-TE-METRIC is being defined in the OSPF Link Overload draft – correct? It is not a reference from some other RFC or draft? <Shraddha>Yes. This value is introduced in this draft. Given all work on TE, I was inclined to search for this constant in other documents. I think it would be useful to precede the definition with “This document defines MAX-TE-METRIC as 0xffffffe.” to avoid any confusion. The reason was that some implementation treat te-metric 0xffffffff as invalid value and do not setup paths through them. Using 0xffffffff-1 seemed like a safe option I was not aware some TE implementations did this. We definitely want it to be used as the least preferred path in this state. I know that pre-RFC 2383 (not going to look up where it was actually changed) defined 0xffffff as unreachable and this was later deprecated. 2. Why not just use 0xffffffff like RFC 5817? <Shraddha>We can if we have the Working Group Consensus. I don’t feel strongly but would err on the conservative side if there are implementations that treat 0xffffffff as unusable. Thanks, Acee Thanks, Acee
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
