Acee/OSPF WG, I just realized my post on updated draft for -08 version posted on 17-07 was stuck at confirmation stage.
I think it's useful to have normative language to ensure interoperability. I have updated the "elements of procedure" Section accordingly. Please review the -08 version. Thanks Shraddha -----Original Message----- From: Acee Lindem (acee) [mailto:[email protected]] Sent: Tuesday, July 25, 2017 3:59 AM To: Shraddha Hegde <[email protected]>; Peter Psenak (ppsenak) <[email protected]>; Ketan Talaulikar (ketant) <[email protected]> Cc: [email protected] Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt Hi Shraddha, Great - I think we are all in sync. What are your thoughts on using “MUST” for the setting the link metrics in sections 5.1, 5.2, 5.3 and 5.5? I checked RFC 6987 (and RFC 3137) and they don't use normative language since setting the link-metrics to 0xffff is the very definition of OSPF stub router behavior. Also, one more reference to RFC 4203. *** 438,445 **** field in the Extended Link TLV carries the Local interface-id instead of the IP address. The Local/Remote Interface ID sub-TLV MUST be originated when there are multiple parallel unnumbered interfaces ! between two nodes. Procedures to obtain interface-id of the remote ! side are defined in [RFC4203]. --- 438,445 ---- field in the Extended Link TLV carries the Local interface-id instead of the IP address. The Local/Remote Interface ID sub-TLV MUST be originated when there are multiple parallel unnumbered interfaces ! between two nodes. One of the mechanisms to obtain remote ! interface-id is described in [RFC4203]. Thanks, Acee On 7/10/17, 12:52 AM, "Shraddha Hegde" <[email protected]> wrote: >All, > >Link-local flooding was added as an optimization for use-cases that do >not need area level flooding on request from Acee. >I agree flooding area level in all cases is a reasonable way forward as >the overhead isn't much. > >If anyone has objections to removing Link-local scope advertisement, do >let me know. > >Rgds >Shraddha > > >-----Original Message----- >From: Acee Lindem (acee) [mailto:[email protected]] >Sent: Thursday, July 6, 2017 2:55 PM >To: Peter Psenak (ppsenak) <[email protected]>; Ketan Talaulikar >(ketant) <[email protected]>; Shraddha Hegde <[email protected]> >Cc: [email protected] >Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt > >Hi Peter, Shradha, > >On 7/6/17, 3:30 AM, "OSPF on behalf of Peter Psenak (ppsenak)" ><[email protected] on behalf of [email protected]> wrote: > >>On 06/07/17 05:50 , Ketan Talaulikar (ketant) wrote: >>> Hi Shraddha, >>> >>> Thanks for taking care of some of the comments shared previously. >>>Please find below some more that were probably missed or not taken >>>care of. >>> >>> 1) I see that the use of link-local scope RI LSA has still been >>>retained in this version and not sure why. RI LSA is for node >>>attributes and it's use for signalling of link is not right IMO. Why >>>not use the link-local scope Extended Link LSA instead? >> >>an alternative would be to always flood area scope Extended Link LSA. >>It should not harm anything and could be used by other routers in area >>as a "heads-up" that remote link is becoming overloaded. > >I think this would be a good way forward as the OSPF Extended Attribute >LSA will most likely be advertised for SR in OSPF Service Provider >domains anyway. So, just advertising the area-scope for all use cases >would seem to be the simplify this approach and get us past this >discussion. In fact, the -00 version of the draft had area-scope alone >and I, regretfully, had suggested the OSPF RI as possible way to get >support either scope. > >Thanks, >Acee > >> >> >>> >>> 2) Sec 5.1, why is advertising of MAX-METRIC for the link to be >>>overloaded a SHOULD and not a MUST? Isn't this mandatory to ensure >>>backward compatibility? What if the router on which overload is >>>signalled does not do MAX-METRIC but the implementation on the remote >>>side end up doing MAX-METRIC. Would it not result in asymmetric >>>metric in a un-intended manner? Please consider changing all SHOULD >>>here to MUST to ensure backward compatibility. >>> >>> 3) Sec 5.4, can you please make similar change in language related >>>to the RFC4203 reference as you've done in other parts in this version? >>> >>> Also I don't agree with the rationale you've given for not using LLS >>>for the link-local signalling. Even if the hello processing were >>>delegated to the LC, there are already a lot of protocol events which >>>can happen via hello packets (which includes LLS) that require >>>signalling update to the control plane OSPF main process. An >>>implementation aspect such as this should hardly be a good reason to >>>not use LLS for link-local signalling such as overload. >> >>+1 on the above. >> >>thanks, >>Peter >> >>> >>> Thanks, >>> Ketan >>> >>> -----Original Message----- >>> From: OSPF [mailto:[email protected]] On Behalf Of Shraddha >>> Hegde >>> Sent: 03 July 2017 11:11 >>> To: [email protected]; [email protected] >>> Cc: [email protected] >>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt >>> >>> OSPF WG, >>> >>> New version of the ospf-link-overload draft is posted. >>> Editorial comments received so far have been addressed in this version. >>> >>> There was one comments to move the link-overload sub-TLV to LLS in >>>hello messages. >>> Many implementations delegate the Hello processing to >>>linecards/different deamons Once adjacency is established. Hello >>>messages are not sent to control plane post adjacency establishment. >>>The link-overload information typically needs to be processed after >>>adjacency establishment, it introduces unnecessary complexity in >>>hello processing. >>> We had a discussion among authors on this and feel advertising >>>link-overload sub-TLV in the LSAs is the most appropriate mechanism. >>> >>> >>> >>> Rgds >>> Shraddha >>> >>> -----Original Message----- >>> From: OSPF [mailto:[email protected]] On Behalf Of >>>[email protected] >>> Sent: Monday, July 3, 2017 11:01 AM >>> To: [email protected] >>> Cc: [email protected] >>> Subject: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> This draft is a work item of the Open Shortest Path First IGP of the >>>IETF. >>> >>> Title : OSPF Link Overload >>> Authors : Shraddha Hegde >>> Pushpasis Sarkar >>> Hannes Gredler >>> Mohan Nanduri >>> Luay Jalil >>> Filename : draft-ietf-ospf-link-overload-07.txt >>> Pages : 14 >>> Date : 2017-07-02 >>> >>> Abstract: >>> When a link is being prepared to be taken out of service, the >>>traffic >>> needs to be diverted from both ends of the link. Increasing the >>> metric to the highest metric on one side of the link is not >>> sufficient to divert the traffic flowing in the other direction. >>> >>> It is useful for routers in an OSPFv2 or OSPFv3 routing domain >>>to be >>> able to advertise a link being in an overload state to indicate >>> impending maintenance activity on the link. This information >>>can be >>> used by the network devices to re-route the traffic effectively. >>> >>> This document describes the protocol extensions to disseminate >>>link- >>> overload information in OSPFv2 and OSPFv3. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-ospf-link-overload-07 >>> https://datatracker.ietf.org/doc/html/draft-ietf-ospf-link-overload- >>> 0 >>> 7 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-07 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> OSPF mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ospf >>> >>> _______________________________________________ >>> OSPF mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ospf >>> >>> _______________________________________________ >>> OSPF mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ospf >>> . >>> >> >>_______________________________________________ >>OSPF mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
