Acee, I am OK with changing the wording as you suggested. Will do it in next revision.
Rgds Shraddha -----Original Message----- From: Acee Lindem (acee) [mailto:[email protected]] Sent: Friday, April 21, 2017 7:35 PM To: Shraddha Hegde <[email protected]>; Acee Lindem <[email protected]> Cc: [email protected] Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt <speaking as WG member> On 4/21/17, 6:37 AM, "Shraddha Hegde" <[email protected]> wrote: >Acee, > > >> 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. > >I do not agree with this point. The sub-TLV, local/remote interface id >requires the remote interface-id to be filled and the draft refers to >an existing standard on getting this remote interface id. This is the >standard mechanism we follow in every draft. I think we’re back to the circular argument with respect to the gratuitous repurposing of TE LSAs standardized under to satisfy GMPLS requirements for every purpose. Even in support of your position, the blanket statement is not germane to the draft. I might be ok with “One mechanism to learn the remote-id is described in ….” However, it appears now that we have broached the subject of WG last call, there is much discussion on the draft. Thanks, Acee > >Rgds >Shraddha > >-----Original Message----- >From: Acee Lindem (acee) [mailto:[email protected]] >Sent: Thursday, April 20, 2017 7:07 PM >To: Shraddha Hegde <[email protected]>; Acee Lindem ><[email protected]> >Cc: [email protected] >Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt > >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
