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

["Ketan Talaulikar Talaulikar (ketant)" <[e-mail]>]

Hi Shraddha,

Please check inline ...

-----Original Message-----
From: Shraddha Hegde [mailto:[e-mail]] 
Sent: 20 April 2017 12:16
To: Ketan Talaulikar Talaulikar (ketant) <[e-mail]>; Acee Lindem (acee) <[e-mail]>; Acee Lindem <[e-mail]>
Cc: [e-mail]
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Ketan,

Pls see inline..

-----Original Message-----
From: Ketan Talaulikar Talaulikar (ketant) [mailto:[e-mail]] 
Sent: Thursday, April 20, 2017 10:06 AM
To: Acee Lindem (acee) <[e-mail]>; 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/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.
[KT] Why the need for link-local RI LSA and not instead use link-local Extended Link Attribute LSA? Also, what are your thoughts on using the TLV in the area-scope RI LSA as an optimization to avoid putting the same in individual Extended Link Attribute LSAs for all router links when the entire router is undergoing maintenance?

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.
[KT] I see, so now you have proposed to reuse these two TLVs which were erstwhile specific to TE LSAs also in the Extended Link Attribute LSA for this link overload use-case. So I wonder then why are you opposed to tackling this problem in a generic way (for multiple applications and use-cases) as proposed in draft-ppsenak-ospf-te-link-attr-reuse? You have yourself come up with a use-case here. We can debate how to do this as part of draft-ppsenak-ospf-te-link-attr-reuse discussions - but I wonder why the reluctance to agree for that requirement and ask for use-case documents on the WG, when we have another use-case right here. I am not in favour of defining these generic TLVs in this draft since their applicability is very generic and better done in the draft-ppsenak-ospf-te-link-attr-reuse draft.

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.
[KT] Ack

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.
[KT] Responded on separate thread

Thanks,
Ketan

-----Original Message-----
From: OSPF [mailto:[e-mail]] On Behalf Of Acee Lindem (acee)
Sent: 20 April 2017 04:02
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
>

_______________________________________________
OSPF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ospf