Subject: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00

From: Yangang <[email-masked]>
Date: Mon, 21 Oct 2013 01:49:26 +0000

Hi:

We had submitted the a new draft: http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00, we want to discuss the micro-loop problem through another method. Your feedback and comments on the rtgwg mailing list are appreciated. 

Thanks,
Rahul.Yan

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2013年10月18日 15:47
收件人: Zhangxudong (zhangxudong, VRP); Yangang
主题: New Version Notification for draft-zxd-rtgwg-ordered-metric-adjustment-00.txt

A new version of I-D, draft-zxd-rtgwg-ordered-metric-adjustment-00.txt
has been successfully submitted by Xudong Zhang and posted to the
IETF repository.

Filename:	 draft-zxd-rtgwg-ordered-metric-adjustment
Revision:	 00
Title:		 Algorithm for Ordered Metric Adjustment
Creation date:	 2013-10-18
Group:		 Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-ordered-metric-adjustment-00.txt
Status:          http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-metric-adjustment
Htmlized:        http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00

Abstract:
   Upon link down event or link up event, each device in network
   individually schedules route calculation.  Because of different
   hardware capabilities and internal/external environments, the time to
   update forwarding entries on these devices are disordered which can
   cause a transient forwarding loop.  This document introduces a method
   to prevent forwarding loop by adjusting link metric gradually for
   several times.

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: Acee Lindem <[email-masked]>
Date: Mon, 21 Oct 2013 02:06:32 +0000

Can you contrast this with RFC 6976? You include RFC 6976 in the Normative References but it is never referenced (this will show up if you run idnits). 
Acee 
On Oct 20, 2013, at 9:49 PM, Yangang wrote:

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

---

From: Alia Atlas <[email-masked]>
Date: Sun, 20 Oct 2013 22:27:45 -0400

Please also look at RFC 5710 and Sec 6.1 with the Incremental Cost
Adjustment.
It would be helpful to understand where your draft has changes and
improvements.

Alia

On Sun, Oct 20, 2013 at 10:06 PM, Acee Lindem <[email-masked]>wrote:

> Can you contrast this with RFC 6976? You include RFC 6976 in the Normative
> References but it is never referenced (this will show up if you run idnits).
> Acee
> > We had submitted the a new draft:
> http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00,
> we want to discuss the micro-loop problem through another method. Your
> feedback and comments on the rtgwg mailing list are appreciated.
> >
> > Thanks,
> > Rahul.Yan
> >
> > -----邮件原件-----
> > 主题: New Version Notification for
> draft-zxd-rtgwg-ordered-metric-adjustment-00.txt
> >
> >
> > URL:
> http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-ordered-metric-adjustment-00.txt
> > Status:
> http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-metric-adjustment
> > Htmlized:
> http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00
> >
> >
> > Abstract:

---

From: Yangang <[email-masked]>
Date: Tue, 22 Oct 2013 01:30:23 +0000

Our draft is similar with section 6.1 in RFC5715, the cost of changed link will be adjusted and advertised, maybe more than one time, this sequence will base on some pre-calculations. But in RFC 6976, each device should calculate the distance with the failue link, base on this distance, each device decide when the FIB will be updated.

---

From: Acee Lindem <[email-masked]>
Date: Tue, 22 Oct 2013 01:41:49 +0000

I'm aware of the basic premise of the two drafts and was not asking for you to restate the obvious. Specifically, what are the benefits and determents of your draft when compared to RFC 6976? 
Acee

---

From: Yangang <[email-masked]>
Date: Tue, 22 Oct 2013 03:39:55 +0000

OK, I got it.

Actually, we pay attention to two point:

1. Which method will be more nicety? In RFC6976, all devices in network need calculate the schedule time, base on the different hardware and environment, we worry about its effect. In our draft, only failure point adjust the cost, the other device just response the cost change. I think the effect of this kind of difference will be less.

2. Due to no new extension, maybe the distribution will be more smoothly.

---

From: Mike Shand <[email-masked]>
Date: Tue, 22 Oct 2013 10:20:11 +0100

So you have described the difference with OFIB (RFC 6976), but how does 
your proposal differ from "incremental cost advertisement" as described 
in RFC 5715 section 6.1?

Mike

---

From: <[email-masked]>
Date: Wed, 23 Oct 2013 13:54:17 +0200

+1

Don't see also the difference with RFC 5715 section 6.1.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Mike Shand
Envoyé : mardi 22 octobre 2013 11:20
À : [email-masked]
Objet : Re: 答复: 答复: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00

So you have described the difference with OFIB (RFC 6976), but how does your proposal differ from "incremental cost advertisement" as described in RFC 5715 section 6.1?

Mike

On 22/10/2013 04:39, Yangang wrote:
> 主题: Re: 答复: Soliciting WG feedback and comments on 
> draft-zxd-rtgwg-ordered-metric-adjustment-00
>
>> 主题: Re: Soliciting WG feedback and comments on 
>> draft-zxd-rtgwg-ordered-metric-adjustment-00
>>
>>> A new version of I-D, 
>>> 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
>>>

_________________________________________________________________________________________________________________________

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: <[email-masked]>
Date: Wed, 23 Oct 2013 14:01:48 +0200

Hi,

I would need more time to review your algo part. But anyway, could you explain the difference with some old public approach like the paper from Pierre, Mike and Olivier :  http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.8263&rep=rep1&type=pdf

Moreover I would be interested to see in your draft some simulation proving the metric list is quite low ...
I can remember in the paper I'm referencing that the challenge was to compress the KMS list in order to prevent a very very long list which would not be applicable in a live network.

Thanks

Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Yangang
Envoyé : lundi 21 octobre 2013 03:49
À : [email-masked]
Cc : Zhangxudong (zhangxudong, VRP); Yangang
Objet : Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00

Hi:

Thanks,
Rahul.Yan

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2013年10月18日 15:47
收件人: Zhangxudong (zhangxudong, VRP); Yangang
主题: New Version Notification for draft-zxd-rtgwg-ordered-metric-adjustment-00.txt

Abstract:

The IETF Secretariat

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 31 Oct 2013 14:11:31 +0000

Please note Cisco declared IPR on RFC 5715 section 6.1

- Stewart

On 22/10/2013 10:20, Mike Shand wrote:
> So you have described the difference with OFIB (RFC 6976), but how 
> does your proposal differ from "incremental cost advertisement" as 
> described in RFC 5715 section 6.1?
>
> Mike
>
>
>
>> 1. Which method will be more nicety? In RFC6976, all devices in 
>> network need calculate the schedule time, base on the different 
>> hardware and environment, we worry about its effect. In our draft, 
>> only failure point adjust the cost, the other device just response 
>> the cost change. I think the effect of this kind of difference will 
>> be less.
>>
>> I'm aware of the basic premise of the two drafts and was not asking 
>> for you to restate the obvious. Specifically, what are the benefits 
>> and determents of your draft when compared to RFC 6976?
>> Acee
>>
>>> Our draft is similar with section 6.1 in RFC5715, the cost of 
>>> changed link will be adjusted and advertised, maybe more than one 
>>> time, this sequence will base on some pre-calculations. But in RFC 
>>> 6976, each device should calculate the distance with the failue 
>>> link, base on this distance, each device decide when the FIB will be 
>>> updated.
>>>
>>> -----邮件原件-----
>>> Can you contrast this with RFC 6976? You include RFC 6976 in the 
>>> Normative References but it is never referenced (this will show up 
>>> if you run idnits).
>>> Acee
>>>> we want to discuss the micro-loop problem through another method. 
>>>> Your feedback and comments on the rtgwg mailing list are appreciated.
>>>>
>>>> Thanks,
>>>> Rahul.Yan
>>>>
>>>> -----邮件原件-----
>>>> submission

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Pierre Francois <[email-masked]>
Date: Thu, 31 Oct 2013 16:49:24 +0100

Stephane, 

Much progress on the topic has been made since that much preliminary Infocom paper. 
So here come more up-to-date reference points to compare:

Graceful Convergence in Link-State IP Networks
F. Clad, P. Mérindol, J.-J. Pansiot, P. Francois and O. Bonaventure 
In IEEE/ACM Transactions on Networking, 2013

documents the most optimised algorithm known so far for the link shutdown case, with extensive simulation results and performance analysis. 

Graceful Router Updates for Link-State Protocols
F. Clad, P. Mérindol, S. Vissicchio, J.-J. Pansiot and P. Francois
In proceedings of IEEE ICNP 2013, Göttingen, Germany, October 2013

provides an algorithm to do the same in the node shutdown case, smarter than doing one link after the other. 

Cheers,

Pierre.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 31 Oct 2013 11:54:09 -0400

Pierre,

Thanks for the updates.   Can you summarize?  Have the number of changes
become few enough in general to be practical?

Alia

On Thu, Oct 31, 2013 at 11:49 AM, Pierre Francois <[email-masked]
> wrote:

> documents the most optimised algorithm known so far for the link shutdown
> case, with extensive simulation results and performance analysis.
>
>
> I would need more time to review your algo part. But anyway, could you
> explain the difference with some old public approach like the paper from
> Pierre, Mike and Olivier :
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.8263&rep=rep1&type=pdf
>
> I can remember in the paper I'm referencing that the challenge was to
> compress the KMS list in order to prevent a very very long list which would
> not be applicable in a live network.
>
> Thanks
>
> Stephane
>
>
>
> Objet : Soliciting WG feedback and comments on
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Pierre Francois <[email-masked]>
Date: Thu, 31 Oct 2013 17:04:23 +0100

Alia, 

Some corner cases here and there, but yes, Francois' code (Francois Clad, not me) computes these sequences in a ridiculously low amount of time, and the sequences tend to be very short even in large topologies. 

I still think this should be investigated for maintenance cases and metric updates stemming out of a TE exercise. 

I do not think this is a practical approach to apply after a FRR application. 

Cheers,

Pierre.

On Oct 31, 2013, at 4:54 PM, Alia Atlas <[email-masked]> wrote:

> Pierre,
> 
> Thanks for the updates.   Can you summarize?  Have the number of changes become few enough in general to be practical?
> 
> Alia
> 
> 
> On Thu, Oct 31, 2013 at 11:49 AM, Pierre Francois <[email-masked]> wrote:
> Stephane, 
>

---

From: <[email-masked]>
Date: Thu, 31 Oct 2013 17:29:07 +0100

>I do not think this is a practical approach to apply after a FRR application.

+1, in term of operations, I would say that incremental metric would be applicable only for maintenance and may not for outages

De : Pierre Francois [mailto:[email-masked]]
Envoyé : jeudi 31 octobre 2013 17:04
À : Alia Atlas
Cc : LITKOWSKI Stephane DTF/DERX; [email-masked]; Zhangxudong (zhangxudong, VRP); Yangang
Objet : Re: Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00

Alia,

Cheers,

Pierre.

On Oct 31, 2013, at 4:54 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Pierre,

Alia

On Thu, Oct 31, 2013 at 11:49 AM, Pierre Francois <[email-masked]<mailto:[email-masked]>> wrote:
Stephane,

Cheers,

Pierre.

On Oct 23, 2013, at 2:01 PM, [email-masked]<mailto:[email-masked]> wrote:

Hi,

Thanks

Stephane

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:rtgwg-<mailto:rtgwg->[email-masked]<mailto:[email-masked]>] De la part de Yangang
Envoyé : lundi 21 octobre 2013 03:49
À : [email-masked]<mailto:[email-masked]>
Cc : Zhangxudong (zhangxudong, VRP); Yangang
Objet : Soliciting WG feedback and comments on draft-zxd-rtgwg-ordered-metric-adjustment-00

Hi:

Thanks,
Rahul.Yan

-----邮件原件-----
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2013年10月18日 15:47
收件人: Zhangxudong (zhangxudong, VRP); Yangang
主题: New Version Notification for draft-zxd-rtgwg-ordered-metric-adjustment-00.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<http://tools.ietf.org/>.

The IETF Secretariat

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg