Hi Shraddha, On 4/20/17, 12:46 AM, "Shraddha Hegde" <[email protected]> wrote:
>Hi Acee, > >The draft does not mandate use of RFC 4203. There are no MUST statements >associated with the recommendation. I don’t see any need to reference RFC 4203 since the Sub-TLV is sufficiently defined here. This is completely orthogonal to the definition in this draft. > > >RFC 4203 is a standard and has been around for a while. I do not >understand why there is concern being raised over >Referencing an RFC which has been a standard and deployed in the field >for many years. > >https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is >still an independent draft and it does not make sense to refer this draft >in draft-ietf-ospf-link-overload-06 which is ready for WG last call. I wasn’t suggesting to reference either document. Thanks, Acee > >Rgds >Shraddha > >-----Original Message----- >From: Acee Lindem (acee) [mailto:[email protected]] >Sent: Thursday, April 20, 2017 4:02 AM >To: Acee Lindem <[email protected]>; Shraddha Hegde ><[email protected]> >Cc: [email protected] >Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt > >Hi Shraddha, > >The only non-editorial comment that I have is that the draft references >RFC 4203 as the way to learn the remote interface ID on an unnumbered >link >(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As >you know, this is a very controversial topic with some of us wanting this >to be in the hello packets consistent with OSPFv3 and IS-IS as opposed to >using a link-scoped TE Opaque LSA as suggested in the OSPF GMPLS >Extensions RFC (https://www.rfc-editor.org/rfc/rfc4203.txt). I would >suggest removing the reference. > >Thanks, >Acee > > >On 4/19/17, 9:11 AM, "Acee Lindem" <[email protected]> wrote: > >>Hi Shraddha, >> >>I think this version addresses all my comments. I will do a detailed >>review this week and, most likely, start the WG last call. I encourage >>other WG members to do the same. >> >>Thanks, >>Acee >>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <[email protected]> >>>wrote: >>> >>> Hi Acee, >>> >>> New version draft-ietf-ospf-link-overload-06 is posted where the >>>remote-ipv4 addr is moved to a new sub-TLV. >>> Pls review. >>> >>> The authors of the draft believe that draft has undergone multiple >>>revisions/reviews and is ready for WG last call. >>> >>> Rgds >>> Shraddha >>> >>> >>> -----Original Message----- >>> From: OSPF [mailto:[email protected]] On Behalf Of Acee Lindem >>>(acee) >>> Sent: Saturday, March 18, 2017 2:28 AM >>> Cc: [email protected] >>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt >>> >>> Hi Shraddha, et al, >>> >>> With respect to section 4.1, I agree that matching link endpoints in >>> OSPFv2 requires more information. However, this is a general problem >>>and the remote address should be a separate OSPFv2 Link Attribute LSA >>>TLV rather than overloading the link overload TLV ;^) >>> >>> Thanks, >>> Acee >>> >>> On 2/23/17, 11:18 AM, "OSPF on behalf of [email protected]" >>> <[email protected] on behalf of [email protected]> wrote: >>> >>>> >>>> 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-05.txt >>>> Pages : 13 >>>> Date : 2017-02-23 >>>> >>>> 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's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-ospf-link-overload-05 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-05 >>>> >>>> >>>> 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
