Ketan, Pls see inline..
-----Original Message----- From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com] Sent: Thursday, April 20, 2017 10:06 AM To: Acee Lindem (acee) <a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net> Cc: ospf@ietf.org Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt Hi Shraddha/Authors, I would like to share the following comments and feedback on this draft. 1) I did not understand the motivation for the use of link-local scoped RI LSA for the link-overload signalling when we have the ability to do so via the TLV in the area-scoped Extended Link Attribute LSA. I think it may be a good idea (an optimization) to use the TLV in an area-scoped RI LSA to indicate link overload for all the router links instead of signalling individually for all its links in the Extended Link Attribute LSA - but this is not what the draft proposes. So could you explain the reason for the link-local scoped RI LSA TLV usage? <Shraddha> There are many application which may not need an area wide indication and a link level indication would be sufficient. Pls refer section for the applications. 2) The Link Overload TLV is defined with a remote IP address field now. This does not seem like a good idea. We have had traditionally certain TLVs in OSPF LSAs that describe links i.e. Remote Interface IP address and Link Local/Remote Identifiers and cover both numbered and unnumbered links. The draft-ppsenak-ospf-te-link-attr-reuse proposed to specifically re-use these TLVs so that links may be described correctly in the new extended link attribute LSA for generic use-cases such as the Link Overload TLV here. It seems rather odd that we are now introducing these fields like remote address in individual TLVs and proposing *hacky* encoding of link-ids in the remote IP address field for unnumbered links instead of re-using existing well defined generic TLVs. <Shraddha> Pls refer the latest draft draft-ietf-ospf-link-overload-06. New sub-tlvs defined for generic use. 3) I am not sure why the reference to use of OSPFv3 extended LSAs for link level area-scoped signalling was removed from this version of the draft. <Shraddha>Since OSPFv3 entended LSA hasn't progressed, the WG has decided to progress other draft and defer any dependency to a separate document. 4) I also have an objection to the reference of RFC4203 for the procedures for obtaining the remote interface-id since that mechanism is outside the scope of what this draft is trying to standardize. Specifically, I have a problem since it gives an impression that the mechanism described in RFC4203 is *the* procedure for obtaining the remote interface-id since that specification is very specific to the GMPLS/TE use-cases and it is not a generic/based OSPF protocol mechanism. We have proposed an alternate mechanism for doing this in a manner consistent with OSPFv3 and ISIS in draft-ppsenak-ospf-lls-interface-id. We can debate the need for this mechanism in a separate thread, but the reference to RFC4203 does not seem necessary here to me. <Shraddha>This is discussed in other threads. Thanks, Ketan -----Original Message----- From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee) Sent: 20 April 2017 04:02 To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net> Cc: ospf@ietf.org 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" <acee.lin...@gmail.com> 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 <shrad...@juniper.net> >>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:ospf-boun...@ietf.org] On Behalf Of Acee Lindem >>(acee) >> Sent: Saturday, March 18, 2017 2:28 AM >> Cc: ospf@ietf.org >> 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 internet-dra...@ietf.org" >> <ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> 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 >>> 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
