Shraddha, There are also other applications that your draft lists which are TE independent and hence the case for not referring to a specific way for signalling interface-ids which is TE specific.
I don't understand why you would be so reluctant to remove a reference which is not even central to the topic of the draft? Thanks, Ketan -----Original Message----- From: Shraddha Hegde [mailto:[email protected]] Sent: 20 April 2017 12:11 To: Ketan Talaulikar Talaulikar (ketant) <[email protected]>; Acee Lindem (acee) <[email protected]>; Acee Lindem <[email protected]> Cc: [email protected] Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt Ketan, We do have traffic engineering applications that require link-overload functionality. Pls refer section 7.2. Rgds Shraddha -----Original Message----- From: Ketan Talaulikar Talaulikar (ketant) [mailto:[email protected]] Sent: Thursday, April 20, 2017 10:46 AM To: Shraddha Hegde <[email protected]>; Acee Lindem (acee) <[email protected]>; Acee Lindem <[email protected]> Cc: [email protected] Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt Hi Shraddha, The RFC 4203 describes the usage and application of TE LSAs for GMPLS/TE use cases. The OSPF link overload RFC is independent of TE and hence it is a concern that an implementation needs to use TE LSAs with link-local scope just for signalling the interface-ids for unnumbered links. Not asking for reference to draft-ppsenak-ospf-lls-interface-id. Just asking to remove reference to RFC 4203 since the mechanism for signalling interface-ids is orthogonal to the subject of the draft which is generic to OSPF and independent of any TE/GMPLS use-case(s). Thanks, Ketan -----Original Message----- From: OSPF [mailto:[email protected]] On Behalf Of Shraddha Hegde Sent: 20 April 2017 10:17 To: Acee Lindem (acee) <[email protected]>; Acee Lindem <[email protected]> Cc: [email protected] Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt Hi Acee, The draft does not mandate use of RFC 4203. There are no MUST statements associated with the recommendation. 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. 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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
