Hi Shraddha, Co-authors, I just read the draft and I there shouldn’t be any more contention. However, I have a couple questions on the use cases.
1. In the pseudowire use case (7.1), I don’t understand where OSPF link-overload is being advertised. I guess the assumption is that the pseudowires are running OSPF? Also, the use case references a private VLAN with 3 CEs. However, I see pseudowires as P2P. 2. In the OSPF L3VPN use case, mention that the CEs are dual-homed. This include in my editorial comments. 3. In the Hub-and-Spoke use case (7.4), why wouldn’t one just use RFC 6987 rather than advertising link-overload for all the links? I’ll send my editorial comments offline. Thanks, Acee On 7/27/17, 6:03 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote: >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:a...@cisco.com] >Sent: Tuesday, July 25, 2017 3:59 AM >To: Shraddha Hegde <shrad...@juniper.net>; Peter Psenak (ppsenak) ><ppse...@cisco.com>; Ketan Talaulikar (ketant) <ket...@cisco.com> >Cc: ospf@ietf.org >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" <shrad...@juniper.net> 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:a...@cisco.com] >>Sent: Thursday, July 6, 2017 2:55 PM >>To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Ketan Talaulikar >>(ketant) <ket...@cisco.com>; Shraddha Hegde <shrad...@juniper.net> >>Cc: ospf@ietf.org >>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)" >><ospf-boun...@ietf.org on behalf of ppse...@cisco.com> 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:ospf-boun...@ietf.org] On Behalf Of Shraddha >>>> Hegde >>>> Sent: 03 July 2017 11:11 >>>> To: internet-dra...@ietf.org; i-d-annou...@ietf.org >>>> Cc: ospf@ietf.org >>>> 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:ospf-boun...@ietf.org] On Behalf Of >>>>internet-dra...@ietf.org >>>> Sent: Monday, July 3, 2017 11:01 AM >>>> To: i-d-annou...@ietf.org >>>> Cc: ospf@ietf.org >>>> 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 >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>>> . >>>> >>> >>>_______________________________________________ >>>OSPF mailing list >>>OSPF@ietf.org >>>https://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf