Subject: [OSPF] FW: New Version Notification for draft-ietf-ospf-link-overload-03.txt

From: Shraddha Hegde <[email-masked]>
Date: Tue, 14 Feb 2017 03:34:25 +0000

Hi All,

New version of the ospf-link-overload draft is submitted and has below changes

> Area level link-overload sub-TLV reverted back to extended link opaque LSA.
> minor editorial corrections.

Let me know if you have any comments.

Rgds
Shraddha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 13, 2017 11:39 AM
To: Shraddha Hegde <[email-masked]>; Pushpasis Sarkar <[email-masked]>; Mohan Nanduri <[email-masked]>; Hannes Gredler <[email-masked]>; Luay Jalil <[email-masked]>
Subject: New Version Notification for draft-ietf-ospf-link-overload-03.txt

A new version of I-D, draft-ietf-ospf-link-overload-03.txt
has been successfully submitted by Shraddha Hegde and posted to the IETF repository.

Name:		draft-ietf-ospf-link-overload
Revision:	03
Title:		OSPF Link Overload
Document date:	2017-02-12
Group:		ospf
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ospf-link-overload-03.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ospf-link-overload-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-03

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.

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.

The IETF Secretariat

---

From: Karsten Thomann <[email-masked]>
Date: Wed, 15 Feb 2017 12:01:00 -0800 (PST)

Hi Shraddha,

I have some typos and comments...

3.1 [RFC7684] . (space before the point)
3.2 Section 4.The (two missing spaces)
3.2 ipv4 address.The (two missing spaces)
4.2 for OSPFv3.  or in (I think it should be a comma)
5 identified in by (would delete "in")
6 compatible.It is
6 applicable.  .
7.1 directions.The link 
7.2 each link.The
7.2 capacity.  and 

Generally I would clean up the used version of some words as there are many 
different versions like:
Sub-TLV, sub-tlv, sub-TLV
link-overload, Link overload, link overload
ipv4, IP4, IPv4

Reference to I-D.ietf-ospf-ospfv3-lsa-extend should be updated to latest 
version.

Is there a reason why the text for MAX-TE-METRIC wasn't repeated in 5.3?

The section 7.1 isn't really clear, at least for me, as it sounds like that 
the service provider is signaling something within the customers L2 circuit.

Regards
Karsten

Am Dienstag, 14. Februar 2017, 03:34:25 schrieb Shraddha Hegde:
> To: Shraddha Hegde <[email-masked]>; Pushpasis Sarkar
> <[email-masked]>; Mohan Nanduri <[email-masked]>; Hannes
> Gredler <[email-masked]>; Luay Jalil <[email-masked]> Subject:
> New Version Notification for draft-ietf-ospf-link-overload-03.txt
> 
> 
> URL:           
> https://www.ietf.org/internet-drafts/draft-ietf-ospf-link-overload-03.txt
> Status:        
> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ Htmlized:  
>     https://tools.ietf.org/html/draft-ietf-ospf-link-overload-03 Diff:     
>      https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-03
> 
> 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.
> 
> The IETF Secretariat
> 
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Shraddha Hegde <[email-masked]>
Date: Sat, 18 Feb 2017 17:39:05 +0000

Karsten,

Thank you very much for detailed review.
Pls see inline..

Rgds
Shraddha

-----Original Message-----
From: Karsten Thomann [mailto:[email-masked]] 
Sent: Thursday, February 16, 2017 1:31 AM
To: [email-masked]
Cc: Shraddha Hegde <[email-masked]>
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-link-overload-03.txt

Hi Shraddha,

<Shraddha> Corrected all the above typos.
Generally I would clean up the used version of some words as there are many 
different versions like:
Sub-TLV, sub-tlv, sub-TLV
<Shraddha> modified to "sub-TLV ".

link-overload, Link overload, link overload
<Shraddha> modified to Link-Overload for the sub-TLV everywhere

ipv4, IP4, IPv4
<Shraddha> modified to IPv4.

Reference to I-D.ietf-ospf-ospfv3-lsa-extend should be updated to latest 
version.
<Shraddha> This citation is going to be removed.

Is there a reason why the text for MAX-TE-METRIC wasn't repeated in 5.3?
<Shraddha> P2MP mode not defined for TE in RFC 3630.

The section 7.1 isn't really clear, at least for me, as it sounds like that 
the service provider is signaling something within the customers L2 circuit.
<Shraddha> Added more description. Pls check if it looks better now.

Regards
Karsten

---

From: Karsten Thomann <[email-masked]>
Date: Sun, 19 Feb 2017 18:21:04 +0100

Shraddha,

thanks for your reply, please see inline.

Regards
Karsten

> <Shraddha> This citation is going to be removed.
As it isn't removed, I think it will be removed in the 05 version
> <Shraddha> P2MP mode not defined for TE in RFC 3630.
You're correct, but a real description for broadcast networks with more then 2 
routers are also not really descriibed, but I'm fine with the answer.
> <Shraddha> Added more description. Pls check if it looks better now.
I'm now able to understand the intention of the use case, but I think it's a 
bit far fetched to use it as a real example.

In my opinion where an ISP is providing L3 VPN's with CE-PE links with OSPF 
could use it to move traffic from that link in case of maintenance as the 
customer router would also shift the traffic and not only the PE router, how the 
interaction between OSPF and BGP is in that case should be outside the scope, 
but it should be nearer the real world use case.

Another use case where it would be usable without problems should be where the 
ISP is providing an ospf sham link (RFC4577).
It allows the isp to reroute the traffic from the pe undergoing maintenance for 
the customer in both directions, while only configuring it on one pe.

An additional example would be where a customer could remove the traffic from 
all spokes if the hub router (or hub router link) is undergoing maintenance, 
as it only requires the configuration on the hub and not all spokes.
> > 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.
> > 
> > The IETF Secretariat
> >

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 23 Feb 2017 09:38:00 +0000

Hi Karsten,

Pls see inline...

-----Original Message-----
From: Karsten Thomann [mailto:[email-masked]] 
Sent: Sunday, February 19, 2017 10:51 PM
To: Shraddha Hegde <[email-masked]>
Cc: [email-masked]
Subject: Re: [OSPF] FW: New Version Notification for draft-ietf-ospf-link-overload-03.txt

Shraddha,

Regards
Karsten

On Saturday, 18 February 2017 18:39:05 CET Shraddha Hegde wrote:
> Generally I would clean up the used version of some words as there are 
> many different versions like:
> link-overload, Link overload, link overload <Shraddha> modified to 
> Link-Overload for the sub-TLV everywhere
> 
> ipv4, IP4, IPv4
> Reference to I-D.ietf-ospf-ospfv3-lsa-extend should be updated to 
> latest version.
> <Shraddha> P2MP mode not defined for TE in RFC 3630.
You're correct, but a real description for broadcast networks with more then 2 routers are also not really descriibed, but I'm fine with the answer.
> 
> The section 7.1 isn't really clear, at least for me, as it sounds like 
> that the service provider is signaling something within the customers L2 circuit.
I'm now able to understand the intention of the use case, but I think it's a bit far fetched to use it as a real example.
<Shraddha> This usecase actually came from a real deployment.

In my opinion where an ISP is providing L3 VPN's with CE-PE links with OSPF could use it to move traffic from that link in case of maintenance as the customer router would also shift the traffic and not only the PE router, how the interaction between OSPF and BGP is in that case should be outside the scope, but it should be nearer the real world use case.

Another use case where it would be usable without problems should be where the ISP is providing an ospf sham link (RFC4577).
It allows the isp to reroute the traffic from the pe undergoing maintenance for the customer in both directions, while only configuring it on one pe.

An additional example would be where a customer could remove the traffic from all spokes if the hub router (or hub router link) is undergoing maintenance, as it only requires the configuration on the hub and not all spokes.
<Shraddha> sure. All are useful usecases and I have added them to the draft.
> > <[email-masked]>; Mohan Nanduri <[email-masked]>; 
> > Hannes Gredler <[email-masked]>; Luay Jalil <[email-masked]> Subject: