Hi Acee, It was a mistake to think 0xffff added to 0xffff will make it 0xffffffff . The metric will be 0x1fffe which is still much greater than 0xffff.
If an operator has assigned metric of 0xffff for a link thinking that this will be the last resort link Since there is no metric beyond 0xffff. This assumption will be broken when two part metric is introduced. As there can be node-node paths with metric Larger than oxffff, so 0xffff is no longer a safe last resort metric. Introducing two-part metric for broadcast links into the network has operational impact and I think it should be stated explicitly in the draft. Rgds Shraddha From: Acee Lindem (acee) [mailto:[email protected]] Sent: Saturday, October 17, 2015 5:36 AM To: Shraddha Hegde <[email protected]>; [email protected] Cc: OSPF WG List <[email protected]> Subject: Re: draft-ietf-ospf-two-part-metric : Max metric handling Hi Shraddha, Even if we set both metrics to 0xffff, the link metric is 0x1FFE. This is far from 0xffffff. Hence, I don’t really understand your concern of this changing the behavior. Thanks, Acee From: Shraddha Hegde <[email protected]<mailto:[email protected]>> Date: Tuesday, October 13, 2015 at 12:30 AM To: Acee Lindem <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: OSPF WG List <[email protected]<mailto:[email protected]>> Subject: RE: draft-ietf-ospf-two-part-metric : Max metric handling Acee, Yes, the metric change for the stub router scenario needs to be updated. This draft is changing the maximum possible metric for a path between two adjacent nodes from 0xffff to oxffffffff. This breaks the existing assumption that 0xffff is the max_metric i.e last resort metric. From operational Perspective it’s better to mention this point explicitly in the draft. Rgds Shraddha From: Acee Lindem (acee) [mailto:[email protected]] Sent: Thursday, October 08, 2015 3:03 PM To: Shraddha Hegde <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: OSPF WG List <[email protected]<mailto:[email protected]>> Subject: Re: draft-ietf-ospf-two-part-metric : Max metric handling Hi Shraddha, Since RFC 2328 and RFC 5340 don’t explicitly call out the case of 0xffff, I don’t see why this should be handled. Perhaps, we should state both metric SHOULD be set to 0xffff in the stub router case. Thanks, Acee From: Shraddha Hegde <[email protected]<mailto:[email protected]>> Date: Tuesday, October 6, 2015 at 5:58 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: OSPF WG List <[email protected]<mailto:[email protected]>> Subject: draft-ietf-ospf-two-part-metric : Max metric handling Authors, As per my understanding of the draft, SPF calculation uses sum of metric from the interface cost and the network to router cost advertised by the neighbor. Handling of MAX metric is not described in the draft. Since the metric will be sum of 2 16 bit numbers it can exceed the normal 0xffff metric value and the draft should talk about how to handle these cases. Rgds Shraddha
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
