Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

["Acee Lindem (acee)" <[e-mail]>]

<speaking as WG member>

On 4/21/17, 6:37 AM, "Shraddha Hegde" <[e-mail]> 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:[e-mail]]
>Sent: Thursday, April 20, 2017 7:07 PM
>To: Shraddha Hegde <[e-mail]>; Acee Lindem
><[e-mail]>
>Cc: [e-mail]
>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>
>Hi Shraddha, 
>
>On 4/20/17, 12:46 AM, "Shraddha Hegde" <[e-mail]> 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:[e-mail]]
>>Sent: Thursday, April 20, 2017 4:02 AM
>>To: Acee Lindem <[e-mail]>; Shraddha Hegde
>><[e-mail]>
>>Cc: [e-mail]
>>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" <[e-mail]> 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 <[e-mail]>
>>>>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:[e-mail]] On Behalf Of Acee Lindem
>>>>(acee)
>>>> Sent: Saturday, March 18, 2017 2:28 AM
>>>> Cc: [e-mail]
>>>> 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 [e-mail]"
>>>> <[e-mail] on behalf of [e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>> 
>>>> _______________________________________________
>>>> OSPF mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>> 
>>>> _______________________________________________
>>>> OSPF mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>
>