Subject: progress of draft-ietf-rtgwg-uloop-delay

From: Jeff Tantsura <[email-masked]>
Date: Wed, 2 Mar 2016 19:06:07 +0000

Hi RTGWG,

Chris and I wanted to get a sense of how the working group would like to proceed regarding  draft-ietf-rtgwg-uloop-delay
For sake of simplicity – anyplace further in the email - any changes to  proposed to the existing IGP timers behavior by uloop–delay draft will be called - "uloop–delay algorithm"

The basic question for the working group is:   Should we proceed towards publication of the draft more or less as is, or should we wait to incorporate feedback from one or more implementations of the uloop-delay algorithm?

As far as we know, there haven't been any implementations of the proposed uloop-delay algorithm.  It would be good to get an understanding if any implementations are in progress or planned.

The uloop-delay algorithm proposed in the document seems quite reasonable.  However, it is also quite possible that a single implementation would uncover some unforeseen issues or suggest improvements for the functioning of the algorithm in a single vendor network.  Testing with two or more implementations may provide feedback to improve the algorithm with respect to the goal of having common uloop-delay timers in a multi-vendor network.  But we won't know until that work is done.

If there are implementations in progress or planned, then we think it would be worth waiting to incorporate feedback from those implementations before publishing.

Instead, if there are no implementations planned, we have several options.  We can proceed towards publication more or less as is, with WG last call in the near future.  Or we can explicitly decide to wait to publish the document, leaving it either as an active WG document or as a parked WG document, and wait for one or more implementations.  With the last option, we could leave open the option of publishing at some point in the future, even if no implementations appear.

Personally, I am quite hopeful that there will be at least prototype implementations in the not too distant future.  While it is very unlikely that a vendor would change their defaults, it can easily be implemented with a knob to activate this algorithm.   This gives a simple way to try out the new algorithm incrementally, lowering the bar significantly for at least a prototype implementation.

We look forward to hearing feedback from the WG on how to proceed with the draft.

Cheers,
Jeff

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 2 Mar 2016 23:06:20 +0000

On 02/03/2016 19:06, Jeff Tantsura wrote:
> Instead, if there are no implementations planned, we have several 
> options.  We can proceed towards publication more or less as is, with 
> WG last call in the near future.  Or we can explicitly decide to wait 
> to publish the document, leaving it either as an active WG document or 
> as a parked WG document, and wait for one or more implementations.  
> With the last option, we could leave open the option of publishing at 
> some point in the future, even if no implementations appear. 

.. or we could do as we did with a number of other IPFRR cases where 
there were no implementations and hence no deployment experience, and 
publish as experimental.

At this stage I think experimental would be the way to go.

- Stewart

---

From: <[email-masked]>
Date: Thu, 3 Mar 2016 10:57:42 +0000

Hi Jeff,

There is two existing implementations of the link down.
Based on the feedback from my testing, I need to update the draft to be more clear on the behavior when remote LSP is received before local detection happens. That’s on my task list.

For the link up , there was some feedback that tweaking the flooding machinery as a bad idea.

One option may be to remove the link up.

Best Regards,

From: rtgwg [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Wednesday, March 02, 2016 20:06
To: Routing WG
Subject: progress of draft-ietf-rtgwg-uloop-delay

Hi RTGWG,

Cheers,
Jeff

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 3 Mar 2016 12:00:20 +0000

Stephane

Would some coarse increment version of incremental cost change
be an appropriate compromise approach for link up?

Stewart

On 03/03/2016 10:57, [email-masked] wrote:
> Based on the feedback from my testing, I need to update the draft to 
> be more clear on the behavior when remote LSP is received before local 
> detection happens. That’s on my task list.
>
> *From:*rtgwg [mailto:[email-masked]] *On Behalf Of *Jeff Tantsura
> *Sent:* Wednesday, March 02, 2016 20:06
> *To:* Routing WG
> *Subject:* progress of draft-ietf-rtgwg-uloop-delay
>
> Hi RTGWG,
>
> Chris and I wanted to get a sense of how the working group would like 
> to proceed regarding  draft-ietf-rtgwg-uloop-delay
>
> For sake of simplicity – anyplace further in the email - any changes 
> to  proposed to the existing IGP timers behavior by uloop–delay draft 
> will be called - "uloop–delay algorithm"
>
> The basic question for the working group is:   Should we proceed 
> towards publication of the draft more or less as is, or should we wait 
> to incorporate feedback from one or more implementations of the 
> uloop-delay algorithm?
>
> As far as we know, there haven't been any implementations of the 
> proposed uloop-delay algorithm.  It would be good to get an 
> understanding if any implementations are in progress or planned.
>
> The uloop-delay algorithm proposed in the document seems quite 
> reasonable.  However, it is also quite possible that a single 
> implementation would uncover some unforeseen issues or suggest 
> improvements for the functioning of the algorithm in a single vendor 
> network.  Testing with two or more implementations may provide 
> feedback to improve the algorithm with respect to the goal of having 
> common uloop-delay timers in a multi-vendor network.  But we won't 
> know until that work is done.
>
> If there are implementations in progress or planned, then we think it 
> would be worth waiting to incorporate feedback from those 
> implementations before publishing.
>
> Personally, I am quite hopeful that there will be at least prototype 
> implementations in the not too distant future.  While it is very 
> unlikely that a vendor would change their defaults, it can easily be 
> implemented with a knob to activate this algorithm.   This gives a 
> simple way to try out the new algorithm incrementally, lowering the 
> bar significantly for at least a prototype implementation.
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: <[email-masked]>
Date: Thu, 3 Mar 2016 13:19:52 +0000

Stewart, all,

Multiple incremental cost changes also bring some disadvantage as it turns 1 IGP event into N IGP events. This is an additional cost for process/applications triggering computations in response to an IGP event. e.g. BGP, FRR, some IGP loop free convergence techniques, TE/constraint routing, centralized optimization....
I would not be in favor in putting it in this doc.

One option may be to remove the link up from the document, possibly citing RFC 5715 (RTGWG Frameworkk for Loop-Free convergence which includes the Incremental Cost Advertisement proposal) to cover this case.
Another option could be to make it optional. RFC2026 does not require implementation for STD/Proposed Standard document, so a fortiori do not require the implementation of all options of the document.
Both are equally fine to me.

Best regards,
Bruno

From: rtgwg [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Thursday, March 03, 2016 1:00 PM
To: LITKOWSKI Stephane OBS/OINIS; Jeff Tantsura; Routing WG
Subject: Re: progress of draft-ietf-rtgwg-uloop-delay

Stephane

Stewart
On 03/03/2016 10:57, [email-masked]<mailto:[email-masked]> wrote:
Hi Jeff,

There is two existing implementations of the link down.
Based on the feedback from my testing, I need to update the draft to be more clear on the behavior when remote LSP is received before local detection happens. That's on my task list.

Best Regards,

Hi RTGWG,

Chris and I wanted to get a sense of how the working group would like to proceed regarding  draft-ietf-rtgwg-uloop-delay
For sake of simplicity - anyplace further in the email - any changes to  proposed to the existing IGP timers behavior by uloop-delay draft will be called - "uloop-delay algorithm"

Cheers,
Jeff

Thank you.

rtgwg mailing list

[email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Thu, 3 Mar 2016 14:13:02 +0000

Hi,

Incremental cost change works fine (it has some drawbacks also => takes time), but is a completely different solution (not local delay based) which is already described (partially) in RFC5715.
If we go to remove the current link up proposal (delaying flooding), we can point to proposed solution in RFC5715 without redescribing them or pushing one or the other.

Best Regards,

Stephane

From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, March 03, 2016 13:00
To: LITKOWSKI Stephane OBS/OINIS; Jeff Tantsura; Routing WG
Subject: Re: progress of draft-ietf-rtgwg-uloop-delay

Stephane

Stewart

Best Regards,

Hi RTGWG,

Cheers,
Jeff

Thank you.

rtgwg mailing list