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

From: [email-masked]
Date: Sun, 02 Jul 2017 22:30:55 -0700

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-07.txt
	Pages           : 14
	Date            : 2017-07-02

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 are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-link-overload-07
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-link-overload-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-07

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/

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 3 Jul 2017 05:41:19 +0000

OSPF WG,

New version of the ospf-link-overload draft is posted.
Editorial comments received so far have been addressed in this version.

There was one comments to move the link-overload sub-TLV to LLS in hello messages.
Many implementations delegate the Hello processing to linecards/different deamons
Once adjacency is established. Hello messages are not sent to control plane
post adjacency establishment. The link-overload information typically needs to be processed
after adjacency establishment, it introduces unnecessary complexity in hello processing.
We had a discussion among authors on this and feel advertising link-overload sub-TLV 
in the LSAs is the most appropriate mechanism.

Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 3, 2017 11:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

Abstract:

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.

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

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 6 Jul 2017 03:50:09 +0000

Hi Shraddha,

Thanks for taking care of some of the comments shared previously. Please find below some more that were probably missed or not taken care of. 

1) I see that the use of link-local scope RI LSA has still been retained in this version and not sure why. RI LSA is for node attributes and it's use for signalling of link is not right IMO. Why not use the link-local scope Extended Link LSA instead?

2) Sec 5.1, why is advertising of MAX-METRIC for the link to be overloaded a SHOULD and not a MUST? Isn't this mandatory to ensure backward compatibility? What if the router on which overload is signalled does not do MAX-METRIC but the implementation on the remote side end up doing MAX-METRIC. Would it not result in asymmetric metric in a un-intended manner? Please consider changing all SHOULD here to MUST to ensure backward compatibility.

3) Sec 5.4, can you please make similar change in language related to the RFC4203 reference as you've done in other parts in this version?

Also I don't agree with the rationale you've given for not using LLS for the link-local signalling. Even if the hello processing were delegated to the LC, there are already a lot of protocol events which can happen via hello packets (which includes LLS) that require signalling update to the control plane OSPF main process. An implementation aspect such as this should hardly be a good reason to not use LLS for link-local signalling such as overload.

Thanks,
Ketan

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: 03 July 2017 11:11
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

OSPF WG,

Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 3, 2017 11:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

Abstract:

---

From: Peter Psenak <[email-masked]>
Date: Thu, 06 Jul 2017 09:30:17 +0200

> 1) I see that the use of link-local scope RI LSA has still been retained in this version and not sure why. RI LSA is for node attributes and it's use for signalling of link is not right IMO. Why no…

an alternative would be to always flood area scope Extended Link LSA. It 
should not harm anything and could be used by other routers in area as a 
"heads-up" that remote link is becoming overloaded.

> Also I don't agree with the rationale you've given for not using LLS for the link-local signalling. Even if the hello processing were delegated to the LC, there are already a lot of protocol events…

+1 on the above.

thanks,
Peter

> .

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 6 Jul 2017 09:24:47 +0000

Hi Peter, Shradha, 

On 7/6/17, 3:30 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
<[email-masked] on behalf of [email-masked]> wrote:

>> Thanks for taking care of some of the comments shared previously.
>>Please find below some more that were probably missed or not taken care
>>of.
>>
>> 1) I see that the use of link-local scope RI LSA has still been
>>retained in this version and not sure why. RI LSA is for node attributes
>>and it's use for signalling of link is not right IMO. Why not use the
>>link-local scope Extended Link LSA instead?
>

I think this would be a good way forward as the OSPF Extended Attribute
LSA will most likely be advertised for SR in OSPF Service Provider domains
anyway. So, just advertising the area-scope for all use cases would seem
to be the simplify this approach and get us past this discussion. In fact,
the -00 version of the draft had area-scope alone and I, regretfully, had
suggested the OSPF RI as possible way to get support either scope.

Thanks,
Acee 

>
>
>>
>> 2) Sec 5.1, why is advertising of MAX-METRIC for the link to be
>>overloaded a SHOULD and not a MUST? Isn't this mandatory to ensure
>>backward compatibility? What if the router on which overload is
>>signalled does not do MAX-METRIC but the implementation on the remote
>>side end up doing MAX-METRIC. Would it not result in asymmetric metric
>>in a un-intended manner? Please consider changing all SHOULD here to
>>MUST to ensure backward compatibility.
>>
>> 3) Sec 5.4, can you please make similar change in language related to
>>the RFC4203 reference as you've done in other parts in this version?
>>
>> Also I don't agree with the rationale you've given for not using LLS
>>for the link-local signalling. Even if the hello processing were
>>delegated to the LC, there are already a lot of protocol events which
>>can happen via hello packets (which includes LLS) that require
>>signalling update to the control plane OSPF main process. An
>>implementation aspect such as this should hardly be a good reason to not
>>use LLS for link-local signalling such as overload.
>
>+1 on the above.
>
>thanks,
>Peter
>
>>
>> Thanks,
>> Ketan
>>
>> 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.
>>

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 10 Jul 2017 04:52:11 +0000

All,

Link-local flooding was added as an optimization for use-cases that do not need area level flooding on request from Acee.
I agree flooding area level in all cases is a reasonable way forward as the overhead isn't much.

If anyone has objections to removing Link-local scope advertisement, do let me know.

Rgds
Shraddha

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Thursday, July 6, 2017 2:55 PM
To: Peter Psenak (ppsenak) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

Hi Peter, Shradha, 

On 7/6/17, 3:30 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
<[email-masked] on behalf of [email-masked]> wrote:

>>Please find below some more that were probably missed or not taken 
>>care of.
>>
>>retained in this version and not sure why. RI LSA is for node 
>>attributes and it's use for signalling of link is not right IMO. Why 
>>not use the link-local scope Extended Link LSA instead?
>
>an alternative would be to always flood area scope Extended Link LSA. 
>It should not harm anything and could be used by other routers in area 
>as a "heads-up" that remote link is becoming overloaded.

I think this would be a good way forward as the OSPF Extended Attribute LSA will most likely be advertised for SR in OSPF Service Provider domains anyway. So, just advertising the area-scope for all use cases would seem to be the simplify this approach and get us past this discussion. In fact, the -00 version of the draft had area-scope alone and I, regretfully, had suggested the OSPF RI as possible way to get support either scope.

Thanks,
Acee 

>>implementation aspect such as this should hardly be a good reason to 
>>not use LLS for link-local signalling such as overload.
>
>+1 on the above.
>
>thanks,
>Peter
>
>>
>> Thanks,
>> Ketan
>>
>> Many implementations delegate the Hello processing to 
>>linecards/different deamons  Once adjacency is established. Hello 
>>messages are not sent to control plane  post adjacency establishment. 
>>The link-overload information typically needs to be processed  after 
>>adjacency establishment, it introduces unnecessary complexity in hello 
>>processing.
>> We had a discussion among authors on this and feel advertising 
>>link-overload sub-TLV  in the LSAs is the most appropriate mechanism.
>>
>>
>>
>> Rgds
>> Shraddha
>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 24 Jul 2017 22:28:55 +0000

Hi Shraddha, 

Great - I think we are all in sync.

What are your thoughts on using “MUST” for the setting the link metrics in
sections 5.1, 5.2, 5.3 and 5.5? I checked RFC 6987 (and RFC 3137) and they
don't use normative language since setting the link-metrics to 0xffff is
the very definition of OSPF stub router behavior.

Also, one more reference to RFC 4203.

*** 438,445 ****
     field in the Extended Link TLV carries the Local interface-id instead
     of the IP address.  The Local/Remote Interface ID sub-TLV MUST be
     originated when there are multiple parallel unnumbered interfaces
!    between two nodes.  Procedures to obtain interface-id of the remote
!    side are defined in [RFC4203].

--- 438,445 ----
     field in the Extended Link TLV carries the Local interface-id instead
     of the IP address.  The Local/Remote Interface ID sub-TLV MUST be
     originated when there are multiple parallel unnumbered interfaces
!    between two nodes.  One of the mechanisms to obtain remote
!    interface-id is described in [RFC4203].

Thanks,
Acee 

On 7/10/17, 12:52 AM, "Shraddha Hegde" <[email-masked]> wrote:

>All,
>
>Link-local flooding was added as an optimization for use-cases that do
>not need area level flooding on request from Acee.
>To: Peter Psenak (ppsenak) <[email-masked]>; Ketan Talaulikar (ketant)
><[email-masked]>; Shraddha Hegde <[email-masked]>
>Cc: [email-masked]
>LSA will most likely be advertised for SR in OSPF Service Provider
>domains anyway. So, just advertising the area-scope for all use cases
>would seem to be the simplify this approach and get us past this
>discussion. In fact, the -00 version of the draft had area-scope alone
>and I, regretfully, had suggested the OSPF RI as possible way to get
>support either scope.
>
>Thanks,
>Acee 
>
>>
>>
>>>

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 27 Jul 2017 10:03:29 +0000

Acee/OSPF WG,

I just realized my post on updated draft for -08 version posted on 17-07 was stuck at confirmation stage.

I think it's useful to have normative language to ensure interoperability. I have updated the "elements of procedure"
Section accordingly. Please review the -08 version.

Thanks
Shraddha

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Tuesday, July 25, 2017 3:59 AM
To: Shraddha Hegde <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

Hi Shraddha, 

What are your thoughts on using “MUST” for the setting the link metrics in sections 5.1, 5.2, 5.3 and 5.5? I checked RFC 6987 (and RFC 3137) and they don't use normative language since setting the link-metrics to 0xffff is the very definition of OSPF stub router behavior.

*** 438,445 ****

--- 438,445 ----

Thanks,
Acee 

On 7/10/17, 12:52 AM, "Shraddha Hegde" <[email-masked]> wrote:

>To: Peter Psenak (ppsenak) <[email-masked]>; Ketan Talaulikar 
>(ketant) <[email-masked]>; Shraddha Hegde <[email-masked]>
>Cc: [email-masked]
>>>side end up doing MAX-METRIC. Would it not result in asymmetric 
>>>metric in a un-intended manner? Please consider changing all SHOULD 
>>>here to MUST to ensure backward compatibility.
>>>
>>> 3) Sec 5.4, can you please make similar change in language related 
>>>to the RFC4203 reference as you've done in other parts in this version?
>>>
>>>adjacency establishment, it introduces unnecessary complexity in 
>>>hello processing.
>>> https://datatracker.ietf.org/doc/html/draft-ietf-ospf-link-overload-
>>> 0
>>> 7
>>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 27 Jul 2017 21:49:07 +0000

Hi Shraddha, Co-authors,

I just read the draft and I there shouldn’t be any more contention.
However, I have a couple questions on the use cases.

  1. In the pseudowire use case (7.1), I don’t understand where OSPF
link-overload is being advertised. I guess the assumption is that the
pseudowires are running OSPF? Also, the use case references a private VLAN
with 3 CEs. However, I see pseudowires as P2P.

  2. In the OSPF L3VPN use case, mention that the CEs are dual-homed. This
include in my editorial comments.

  3. In the Hub-and-Spoke use case (7.4), why wouldn’t one just use RFC
6987 rather than advertising link-overload for all the links?

I’ll send my editorial comments offline.

Thanks,
Acee 

On 7/27/17, 6:03 AM, "Shraddha Hegde" <[email-masked]> wrote:

>I think it's useful to have normative language to ensure
>interoperability. I have updated the "elements of procedure"
>To: Shraddha Hegde <[email-masked]>; Peter Psenak (ppsenak)
><[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>
>Cc: [email-masked]
>What are your thoughts on using “MUST” for the setting the link metrics
>in sections 5.1, 5.2, 5.3 and 5.5? I checked RFC 6987 (and RFC 3137) and
>they don't use normative language since setting the link-metrics to
>0xffff is the very definition of OSPF stub router behavior.
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 27 Jul 2017 21:58:58 +0000

>with 3 CEs. However, I see pseudowires as P2P.

I guess VPLS is also characterized as a pseudowire service.

Thanks,
Acee

---

From: Julien Meuric <[email-masked]>
Date: Fri, 28 Jul 2017 11:04:26 +0200

Hi Shraddha,

Sorry for joining the discussion on -08.

>From your ID:
" It is useful to be able to advertise the impending maintenance
activity on the link and to have LSP re-routing policies at the ingress
to route the LSPs away from the link."

>From RFC 5817:
"a Service Provider may desire to gracefully (temporarily or
indefinitely) remove a TE link, a group of TE links, or an entire node
for administrative reasons such as link maintenance, software/hardware
upgrade at a node, or significant TE configuration changes."

There is a clear overlap. I am aware that RFC 5817 is informational, but
is there a technical reason why the work in progress starts from scratch
instead of building from section 4.1 in the former?

Thanks,

Julien (starting to feel as an old IETFer)

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 31 Jul 2017 16:55:18 +0000

Hi Julien,

Thanks for your comments.
RFC 5817  is specific to TE enabled links where as ospf-link-overload is generic
For an IGP topology. One of the goals of this draft is also to automate the process
Re-routing traffic in reverse direction. I do not think there is complete overlap
Between the two drafts also this draft is not contradicting RFC 5817. I'll add a reference to
RFC 5817 for TE related processing.

Rgds
shraddha

-----Original Message-----
From: Julien Meuric [mailto:[email-masked]] 
Sent: Friday, July 28, 2017 2:34 PM
To: Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt

Hi Shraddha,

>From your ID:
" It is useful to be able to advertise the impending maintenance activity on the link and to have LSP re-routing policies at the ingress to route the LSPs away from the link."

"a Service Provider may desire to gracefully (temporarily or
indefinitely) remove a TE link, a group of TE links, or an entire node for administrative reasons such as link maintenance, software/hardware upgrade at a node, or significant TE configuration changes."

There is a clear overlap. I am aware that RFC 5817 is informational, but is there a technical reason why the work in progress starts from scratch instead of building from section 4.1 in the former?

Thanks,

Jul. 27, 2017 - [email-masked]:
>> Link-local flooding was added as an optimization for use-cases that 
>> do not need area level flooding on request from Acee.
>>>> attributes and it's use for signalling of link is not right IMO. 
>>>> Why not use the link-local scope Extended Link LSA instead?
>>>
>>> It should not harm anything and could be used by other routers in 
>>> area as a "heads-up" that remote link is becoming overloaded.
>>
>> I think this would be a good way forward as the OSPF Extended 
>> Attribute LSA will most likely be advertised for SR in OSPF Service 
>> Provider domains anyway. So, just advertising the area-scope for all 
>> use cases would seem to be the simplify this approach and get us past 
>> this discussion. In fact, the -00 version of the draft had area-scope 
>> alone and I, regretfully, had suggested the OSPF RI as possible way 
>> to get support either scope.
>>
>> Thanks,
>> Acee
>>
>>>
>>>
>>>>
>>>> signalled does not do MAX-METRIC but the implementation on the 
>>>> remote side end up doing MAX-METRIC. Would it not result in 
>>>> asymmetric metric in a un-intended manner? Please consider changing 
>>>> all SHOULD here to MUST to ensure backward compatibility.
>>>>
>>>> Also I don't agree with the rationale you've given for not using 
>>>> LLS for the link-local signalling. Even if the hello processing 
>>>> were delegated to the LC, there are already a lot of protocol 
>>>> events which can happen via hello packets (which includes LLS) that 
>>>> require signalling update to the control plane OSPF main process. 
>>>> An implementation aspect such as this should hardly be a good 
>>>> reason to not use LLS for link-local signalling such as overload.
>>>
>>> +1 on the above.
>>>
>>> thanks,
>>> Peter
>>>
>>>>
>>>> Thanks,
>>>> Ketan
>>>>
>>>> The link-overload information typically needs to be processed