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

From: Shraddha Hegde <[email-masked]>
Date: Wed, 19 Apr 2017 13:08:53 +0000

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-masked]] On Behalf Of Acee Lindem (acee)
Sent: Saturday, March 18, 2017 2:28 AM
Cc: [email-masked]
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-masked]"
<[email-masked] on behalf of [email-masked]> 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-masked]
>https://www.ietf.org/mailman/listinfo/ospf

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

---

From: Acee Lindem <[email-masked]>
Date: Wed, 19 Apr 2017 09:11:11 -0400

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-masked]> wrote:
> 
> Hi Acee,
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Apr 2017 22:31:59 +0000

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-masked]> 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 
>> 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
>> 
>> 
>> 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
>>

---

From: "Ketan Talaulikar Talaulikar (ketant)" <[email-masked]>
Date: Thu, 20 Apr 2017 04:36:23 +0000

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?

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.

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.

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.

Thanks,
Ketan

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: 20 April 2017 04:02
To: Acee Lindem <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

Thanks,
Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 20 Apr 2017 04:46:53 +0000

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-masked]] 
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]
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-masked]> wrote:

>>>  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  
>>>  This document describes the protocol extensions to disseminate 
>>> link-  overload information in OSPFv2 and OSPFv3.
>>> 
>>> 
>>>

---

From: "Ketan Talaulikar Talaulikar (ketant)" <[email-masked]>
Date: Thu, 20 Apr 2017 05:15:46 +0000

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-masked]] On Behalf Of Shraddha Hegde
Sent: 20 April 2017 10:17
To: Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Acee,

Rgds
Shraddha

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

Thanks,
Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 20 Apr 2017 06:41:17 +0000

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-masked]] 
Sent: Thursday, April 20, 2017 10:46 AM
To: Shraddha Hegde <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

Thanks,
Ketan

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: 20 April 2017 10:17
To: Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Acee,

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-masked]]
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

Thanks,
Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 20 Apr 2017 06:46:05 +0000

Ketan,

Pls see inline..

-----Original Message-----
From: Ketan Talaulikar Talaulikar (ketant) [mailto:[email-masked]] 
Sent: Thursday, April 20, 2017 10:06 AM
To: Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha/Authors,

<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:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: 20 April 2017 04:02
To: Acee Lindem <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

Thanks,
Acee

---

From: "Ketan Talaulikar Talaulikar (ketant)" <[email-masked]>
Date: Thu, 20 Apr 2017 07:01:05 +0000

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-masked]] 
Sent: 20 April 2017 12:11
To: Ketan Talaulikar Talaulikar (ketant) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Ketan,

Rgds
Shraddha

-----Original Message-----
From: Ketan Talaulikar Talaulikar (ketant) [mailto:[email-masked]] 
Sent: Thursday, April 20, 2017 10:46 AM
To: Shraddha Hegde <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

Thanks,
Ketan

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: 20 April 2017 10:17
To: Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Acee,

Rgds
Shraddha

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

Thanks,
Acee

---

From: "Ketan Talaulikar Talaulikar (ketant)" <[email-masked]>
Date: Thu, 20 Apr 2017 07:11:51 +0000

Hi Shraddha,

Please check inline ...

-----Original Message-----
From: Shraddha Hegde [mailto:[email-masked]] 
Sent: 20 April 2017 12:16
To: Ketan Talaulikar Talaulikar (ketant) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
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:[email-masked]] 
Sent: Thursday, April 20, 2017 10:06 AM
To: Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha/Authors,

<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.

[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:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: 20 April 2017 04:02
To: Acee Lindem <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Thu, 20 Apr 2017 09:20:21 +0200

Hi Shraddha,

please see inline:

> <Shraddha> Pls refer the latest draft draft-ietf-ospf-link-overload-06. New sub-tlvs defined for generic use.

these TLVs have been previously defined in 
https://www.ietf.org/id/draft-ppsenak-ospf-te-link-attr-reuse-04.txt, 
please see section 4.1 and 4.2.

thanks,
Peter

> .

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 20 Apr 2017 07:57:11 +0000

Ketan,

OSPF link overload has relevance for TE based applications as well as non-TE applications.
So what's the problem in referring a  well-defined mechanism of getting the interface-ids?

Can you explain why you are so concerned with referencing a standard RFC 
 which is out there and deployed for so many years?

Rgds
Shraddha

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

Shraddha,

Thanks,
Ketan

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

Ketan,

Rgds
Shraddha

-----Original Message-----
From: Ketan Talaulikar Talaulikar (ketant) [mailto:[email-masked]]
Sent: Thursday, April 20, 2017 10:46 AM
To: Shraddha Hegde <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

Thanks,
Ketan

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: 20 April 2017 10:17
To: Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Acee,

Rgds
Shraddha

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 20 Apr 2017 13:37:08 +0000

Hi Shraddha, 

>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
>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

I wasn’t suggesting to reference either document.

Thanks,
Acee

---

From: "Ketan Talaulikar Talaulikar (ketant)" <[email-masked]>
Date: Thu, 20 Apr 2017 15:22:22 +0000

Hi Shraddha,

The well-defined mechanism of getting interface-ids in RFC 4203 that you refer to is specific to TE applications since it is defined for the GMPLS/TE use-case in that RFC. It is not a generic mechanism since it requires use of TE LSAs and hence not clean option for use-cases where TE is not in the picture.

The link-overload draft is generic and applicable to both TE and other generic use-cases and hence the objection to its referring to a mechanism that is TE specific in this draft.

The draft-ppsenak-ospf-lls-interface-id tries to provide a generic option for doing the link-id signalling. It does not preclude any implementation from using the RFC 4203 based mechanism for doing the same.

I think, I've made my point and will now stop going around in circles on this one.

Thanks,
Ketan 

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

Ketan,

Rgds
Shraddha

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

Shraddha,

Thanks,
Ketan

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

Ketan,

Rgds
Shraddha

-----Original Message-----
From: Ketan Talaulikar Talaulikar (ketant) [mailto:[email-masked]]
Sent: Thursday, April 20, 2017 10:46 AM
To: Shraddha Hegde <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

Thanks,
Ketan

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: 20 April 2017 10:17
To: Acee Lindem (acee) <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Acee,

Rgds
Shraddha

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Fri, 21 Apr 2017 10:08:18 +0200

Hi Shraddha,

please find my comments below:

The draft defines two mechanisms:

a) signaling the link overload to the neighbor. The purpose is to 
advertise the link with max-metric from both directions.

b) flooding the Link-Overload sub-TLV inside the area. The purpose is to 
let "LSP ingress routers/controllers can learn of the impending 
maintenance activity"

1. Why do we need two mechanisms? Why is (b) needed, given that (a) 
results in link being advertised with max-metric in both directions?

How is treatement of remote link having max-metric different to the 
treatment of a link that has the Link-Overload sub-TLV? I would 
understand the difference if you say that the link having the 
Link-Overload sub-TLV must not be used during SPF, but nothing like that 
is mentioned in the draft and I understand why.

Is (b) needed to cover the case, where the signaling defined in (a) is 
not understood by the neighbor on the other side of the link? If yes, 
please state it in the draft.

2. For the signaling defined in (a)-  using the Router Information LSA 
for signaling something to the direct neighbor is a very dirty hack. As 
the name of the LSA says, it has been defined to signal capability of 
the node, which has nothing to do with what you are trying to use it 
for. We have to stop polluting the protocol with such hacks. RFC5613 
defines a Link-Local Signaling mechanism for OSPF and that is the one we 
should use for siganling between neighbors.

thanks,
Peter

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 21 Apr 2017 10:37:02 +0000

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.

Rgds
Shraddha

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Thursday, April 20, 2017 7:07 PM
To: Shraddha Hegde <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
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-masked]> 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. 
>understand why there is concern being raised over Referencing an RFC 
>which has been a standard and deployed in the field for many years.
>
>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.

Thanks,
Acee

>(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
>
>
>>>> 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.
>>>> 
>>>> impending maintenance activity on the link.  This information can 
>>>> be used by the network devices to re-route the traffic effectively.
>>>>

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 21 Apr 2017 10:53:08 +0000

Hi Peter,

Thanks for the detailed review. Pls see inline..

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Friday, April 21, 2017 1:38 PM
To: Shraddha Hegde <[email-masked]>; Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

a) signaling the link overload to the neighbor. The purpose is to advertise the link with max-metric from both directions.

b) flooding the Link-Overload sub-TLV inside the area. The purpose is to let "LSP ingress routers/controllers can learn of the impending maintenance activity"

1. Why do we need two mechanisms? Why is (b) needed, given that (a) results in link being advertised with max-metric in both directions?

How is treatement of remote link having max-metric different to the treatment of a link that has the Link-Overload sub-TLV? I would understand the difference if you say that the link having the Link-Overload sub-TLV must not be used during SPF, but nothing like that is mentioned in the draft and I understand why.

Is (b) needed to cover the case, where the signaling defined in (a) is not understood by the neighbor on the other side of the link? If yes, please state it in the draft.
<Shraddha> Metric alone cannot be used as an indication for impending maintenance activity. When other nodes like ingress/controller need to understand the impending maintenance activity, area level advertisement would be needed. Application specific to this is described in sec 7.2

2. For the signaling defined in (a)-  using the Router Information LSA for signaling something to the direct neighbor is a very dirty hack. As the name of the LSA says, it has been defined to signal capability of the node, which has nothing to do with what you are trying to use it for. We have to stop polluting the protocol with such hacks. RFC5613 defines a Link-Local Signaling mechanism for OSPF and that is the one we should use for siganling between neighbors.
<Shraddha>  LLS is a good mechanism to use for signaling link level information that are useful before the adjacency is established. Section 2 RFC 5613  states that the LLS is not expected to be used for use-cases which cause routing changes. Link-overload does result into routing changes and is best handled using link local scope LSAs.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Fri, 21 Apr 2017 13:17:31 +0200

Hi Shraddha,

please see inline:

> <Shraddha> Metric alone cannot be used as an indication for impending maintenance activity. When other nodes like ingress/controller need to understand the impending maintenance activity, area leve…

no argument about the need of area level flooding - Router LSA with the 
max metric will be flooded within the area.

I have read the section 7.2 several times, but I still do not understand 
what is the purpose of the Link-Overload sub-TLV there. What is the 
controller going to do when it receives the area scoped Link-Overload 
sub-TLV and how it is different to the case where the link is advertised 
in the Router LSA with max-metric in both directions?

> <Shraddha>  LLS is a good mechanism to use for signaling link level information that are useful before the adjacency is established. Section 2 RFC 5613  states that the LLS is not expected to be us…

- LLS can be used to signal information prior to adjacency bringup as 
well as when the adjacency is FULL state. There are existing LLS TLVs 
that are send when adjacency is in FULL state.

- in your case the use of LLS would be to change the metric on the link 
in the reverse direction. That is not resulting in any routing changes 
directly (look at it as the remote configuration request). It's the 
max-metric in the Router LSA that is going to change the routing. So 
using LLS to signal what you need is perfectly valid.

I just can not see how we can standardize the use of RI LSA for what you 
are proposing to use it - it's completely wrong IMHO.

thanks,
Peter

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 21 Apr 2017 15:29:03 +0300

Hi Peter,

See my comments inline.

Thanks.

21.04.2017 14:17, Peter Psenak пишет:
>> b) flooding the Link-Overload sub-TLV inside the area. The purpose is 
>> to let "LSP ingress routers/controllers can learn of the impending 
>> maintenance activity"
>>
>> Link-Overload sub-TLV must not be used during SPF, but nothing like 
>> that is mentioned in the draft and I understand why.
>>
>> Is (b) needed to cover the case, where the signaling defined in (a) 
>> is not understood by the neighbor on the other side of the link? If 
>> yes, please state it in the draft.
>> <Shraddha> Metric alone cannot be used as an indication for impending 
>> maintenance activity. When other nodes like ingress/controller need 
>> to understand the impending maintenance activity, area level 
>> advertisement would be needed. Application specific to this is 
>> described in sec 7.2
>
> no argument about the need of area level flooding - Router LSA with 
> the max metric will be flooded within the area.
>
> I have read the section 7.2 several times, but I still do not 
> understand what is the purpose of the Link-Overload sub-TLV there. 
> What is the controller going to do when it receives the area scoped 
> Link-Overload sub-TLV and how it is different to the case where the 
> link is advertised in the Router LSA with max-metric in both directions?
The fact that link metric has been maximized could not be a trigger for 
LSP recalculation. Some implementations consider IGP topology change as 
a trigger for LSP recalculation, but others - don't. Also, max metric 
itself doesn't tell about exact reason for what link metric was 
increased. It could be result of IGP-LDP synchronization, for example, 
which is irrespective to TE LSPs. From the other hand, when 
head-end/controller receives explicit indication (Link-overload), it 
could interpret it safely as a trigger to reroute LSP, even if 
overloaded link is only link that satisfies constrains (from CSPF 
perspective). Otherwise, increased metric could not be enough reason to 
relax constrains for LSP.
>
>>
>> 2. For the signaling defined in (a)-  using the Router Information 
>> LSA for signaling something to the direct neighbor is a very dirty 
>> hack. As the name of the LSA says, it has been defined to signal 
>> capability of the node, which has nothing to do with what you are 
>> trying to use it for. We have to stop polluting the protocol with 
>> such hacks. RFC5613 defines a Link-Local Signaling mechanism for OSPF 
>> and that is the one we should use for siganling between neighbors.
>> <Shraddha>  LLS is a good mechanism to use for signaling link level 
>> information that are useful before the adjacency is established. 
>> Section 2 RFC 5613  states that the LLS is not expected to be used 
>> for use-cases which cause routing changes. Link-overload does result 
>> into routing changes and is best handled using link local scope LSAs.
>
> - in your case the use of LLS would be to change the metric on the 
> link in the reverse direction. That is not resulting in any routing 
> changes directly (look at it as the remote configuration request). 
> It's the max-metric in the Router LSA that is going to change the 
> routing. So using LLS to signal what you need is perfectly valid.
>
> I just can not see how we can standardize the use of RI LSA for what 
> you are proposing to use it - it's completely wrong IMHO.
>
> thanks,
> Peter
>
>>
>> thanks,
>> Peter
>>
>>
>>
>>>> traffic
>>>> link-

---

From: Peter Psenak <[email-masked]>
Date: Fri, 21 Apr 2017 15:08:10 +0200

Hi Alex,

please see inline:

> relax constrains for LSP.

fair enough.
I would propose authors to include the above reasoning in the draft.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 21 Apr 2017 14:04:33 +0000

<speaking as WG member>

On 4/21/17, 6:37 AM, "Shraddha Hegde" <[email-masked]> wrote:

>>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 

>sufficiently defined here. This is completely orthogonal to the
>definition in this draft.
>>
>>

---

From: Christian Hopps <[email-masked]>
Date: Fri, 21 Apr 2017 11:36:20 -0400

> a trigger for LSP recalculation, but others - don't. Also, max metric

But you have to change the code anyway to make a new TLV work, right? So
what old code does isn't really relevant, unless I misunderstand things.

> relax constrains for LSP.

But IGP-LDP synchronization happens when a link initially comes up. Is
the point then of the new TLV to simply avoid this slight delay on
link-up in using the link for TE?

Thanks,
Chris.

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 21 Apr 2017 21:34:09 +0300

Hi Christian,

See inline.

Thank you.

-- Best regards, Alexander Okonnikov

> what old code does isn't really relevant, unless I misunderstand things.
Not sure that understood your point. Yes, implementation that supports this feature will trigger LSP recalculation on receiving Link-overload sub-TLV, but will not necessary do so in response to max metric. Former signals that physical/logical link maintenance is planned, latter - that IGP link property is modified (may be due to planned IGP link or IGP process maintenance). Two are not always correlate. Ignorance of IGP topology changes from LSP recalculation perspective could be design intent, and not unsupported feature or deficiency of particular implementation. In some implementations it could be enabled/disabled by configuration knob. So, even with introducing support of link-overload implementation is not obligated to react to IGP topology changes with LSP recalculation. With 'max metric only' approach it is not possible to distinguish whether link metric was increased due to link overload mode, or due to some other reason.
> link-up in using the link for TE?
Yes, but it is only one of cases. Enabling LDP on link or restarting LDP process, for example, are other viable triggers for 'max metric'. Also, it could be that other usage of 'max metric' will be invented in the future.

---

From: Christian Hopps <[email-masked]>
Date: Sun, 23 Apr 2017 11:17:28 -0400

Alexander Okonnikov <[email-masked]> writes:

> Not sure that understood your point. Yes, implementation that supports this feature will trigger LSP recalculation on receiving Link-overload sub-TLV, but will not necessary do so in response to max
> metric. Former signals that physical/logical link maintenance is planned, latter - that IGP link property is modified (may be due to planned IGP link or IGP process maintenance). Two are not always
> correlate. Ignorance of IGP topology changes from LSP recalculation perspective could be design intent, and not unsupported feature or deficiency of particular implementation. In some implementations
> it could be enabled/disabled by configuration knob. So, even with introducing support of link-overload implementation is not obligated to react to IGP topology changes with LSP recalculation. With 'max
> metric only' approach it is not possible to distinguish whether link metric was increased due to link overload mode, or due to some other reason.

Are these actual scenarios that really matter or would actually be used
by an operator? Do you know of operators that wish to perform "IGP link
maintenance" (not sure how that is different from "link maintenance") on
a link, that doesn't involve simply removing the link from service?

> Yes, but it is only one of cases. Enabling LDP on link or restarting LDP process, for example, are other viable triggers for 'max metric'. Also, it could be that other usage of 'max metric' will be…

Max-metric is meant to signal "don't use link if at all possible" nothing
else, there won't be future use that doesn't mean that as well. You're
adding another TLV to signal the exact same intent. I don't see the need
is all.

Thanks,
Chris.

---

From: Alexander Okonnikov <[email-masked]>
Date: Sun, 23 Apr 2017 22:22:57 +0300

Hi Christian,

See inline.

Thank you.

> a link, that doesn't involve simply removing the link from service?
Yes, I has my own experience with migrating IGP for some operator. We migrated from using of single IS-IS instance to multiple instances of IS-IS. As part of migration we was moving IGP links (not IP links themselves) from one instance to another ones. From IGP point of view this is losing and establishing of adjacencies. If other routers trigger RSVP LSP recalculation, their RSVP LSPs would be rerouted around maintained router. Fortunately, the implementation doesn't consider IGP topology changes as a trigger to make RSVP LSPs recalculation, and data plane worked as if there was no IGP maintaining. Notice that re-establishing RSVP LSPs (even with MBB procedure) has some negative effects, like put additional traffic load on some links (detoured traffic), stress CPU on routers, and out-of-ordering (new path is shorter) or delaying (new path is longer) packets.
> adding another TLV to signal the exact same intent. I don't see the need
RFC 5443 states that suboptimal IP traffic forwarding is a consequence of using this mechanism. I.e. while we use max-metric to avoid blackholing of traffic on LDP LSPs, we are facing unavoidable side effect in that native IP traffic will be needlessly rerouted as well. If other routers interpret max-metric link as a trigger to resignal RSVP LSPs, drawback of this will impact traffic on latter as well. Thus, max-metric mechanism is multi-purpose and covers several applications. Each time one of applications needs to use 'max-metric', other applications will be impacted as well.

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 24 Apr 2017 10:04:41 +0000

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-masked]] 
Sent: Friday, April 21, 2017 7:35 PM
To: Shraddha Hegde <[email-masked]>; Acee Lindem <[email-masked]>
Cc: [email-masked]
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-masked]> wrote:

>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 

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 

>>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 
>>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
>>
>>
>>>review this week and, most likely, start the WG last call. I 
>>>encourage other WG members to do the same.
>>>
>>>Thanks,
>>>Acee
>>>> 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
>>>> 
>>>>> 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.
>>>>>