Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing-01

From: "Susan Hares" <[email-masked]>
Date: Tue, 23 Dec 2014 09:37:23 -0500

This is to begin a 2 Week WG adoption call for
draft-xu-idr-performance-routing-01  (12/23/2014 to 01/6/2014).  The draft
can be accessed at: 

 <http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/>
http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/.

In your response, please discuss the pros/cons of this approach and indicate
"support" or "no support".

Thank you,

Sue Hares

---

From: Mach Chen <[email-masked]>
Date: Wed, 24 Dec 2014 02:17:12 +0000

Support.

Best regards,
Mach

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, December 23, 2014 10:37 PM
To: idr wg
Cc: Xuxiaohu
Subject: [Idr] WG adoption call for draft-xu-idr-performance-routing-01

This is to begin a 2 Week WG adoption call for draft-xu-idr-performance-routing-01  (12/23/2014 to 01/6/2014).  The draft can be accessed at:

In your response, please discuss the pros/cons of this approach and indicate "support" or "no support".

Thank you,

Sue Hares

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 24 Dec 2014 02:35:48 +0000

Support. I've read this draft and think it provides a useful mechanism for performance routing.

One nit: In section 6, [I-D.ietf-isis-te-metric-extensions] was mentioned twice, I guess one of them should be replaced with [I-D.ietf-ospf-te-metric-extensions].

Best regards,
Jie

Thank you,

Sue Hares

---

From: "ALBERT, Benoit (ca-cib)" <[email-masked]>
Date: Wed, 24 Dec 2014 13:33:26 +0000

Support.
One nit : In section 6, there is a « RECOMMENTED » instead of  « RECOMMENDED »

Benoît ALBERT

De : Idr [mailto:[email-masked]] De la part de Susan Hares
Envoyé : mardi 23 décembre 2014 15:37
À : idr wg
Cc : 'Xuxiaohu'
Objet : [Idr] WG adoption call for draft-xu-idr-performance-routing-01

Thank you,

Sue Hares

This message and any attachments are intended for the sole use of its addressee.
If you are not the addressee, please immediately notify the sender and then destroy the message.
As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on Crédit Agricole Corporate and Investment Bank.
All rights reserved.

Ce message et ses pièces jointes sont destinés à l'usage exclusif de leur destinataire.
Si vous recevez ce message par erreur, merci d'en aviser immédiatement l'expéditeur et de le détruire ensuite.
Le présent message pouvant être altéré à notre insu, Crédit Agricole Corporate and Investment Bank ne peut pas être engagé par son contenu.
Tous droits réservés.

---

From: Lucy yong <[email-masked]>
Date: Wed, 24 Dec 2014 15:47:01 +0000

Support!

Cheers,
Lucy

Thank you,

Sue Hares

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 24 Dec 2014 18:44:47 +0000

Yes/support

Regards,
Jeff

On Dec 23, 2014, at 6:37 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

<http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/> http://datatracker.ietf.org/doc/draft-xu-idr-performance-routing/.

In your response, please discuss the pros/cons of this approach and indicate “support” or “no support”.

Thank you,

Sue Hares

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

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 25 Dec 2014 01:07:08 +0000

Hi Benoît,

Thanks for your support. And the nit you pointed out would be fixed in the next version.

Best regards,
Xiaohu

From: ALBERT, Benoit (ca-cib) [mailto:[email-masked]]
Sent: Wednesday, December 24, 2014 9:33 PM
To: Susan Hares; idr wg
Cc: Xuxiaohu
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01

Support.

Benoît ALBERT

Thank you,

Sue Hares

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 25 Dec 2014 01:08:11 +0000

Hi Jie,

Best regards,
Xiaohu

From: Dongjie (Jimmy)
Sent: Wednesday, December 24, 2014 10:36 AM
To: Susan Hares; idr wg
Cc: Xuxiaohu
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01

Best regards,
Jie

Thank you,

Sue Hares

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 25 Dec 2014 01:58:42 +0000

Support as a co-author.

Best regards,
Xiaohu

From: Susan Hares [mailto:[email-masked]]
Sent: Tuesday, December 23, 2014 10:37 PM
To: idr wg
Cc: Xuxiaohu; John G. Scudder
Subject: WG adoption call for draft-xu-idr-performance-routing-01

Thank you,

Sue Hares

---

From: <[email-masked]>
Date: Thu, 25 Dec 2014 09:16:00 +0000

Hello WG,

I too support (as a co-author) the adoption of draft-xu-idr-performance-routing as an idr WG document.

Cheers,

Christian.

De : Idr [mailto:[email-masked]] De la part de Xuxiaohu
Envoyé : jeudi 25 décembre 2014 02:59
À : Susan Hares; idr wg
Objet : Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01

Support as a co-author.

Best regards,
Xiaohu

Thank you,

Sue Hares

_________________________________________________________________________________________________________________________

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: Robert Raszuk <[email-masked]>
Date: Thu, 25 Dec 2014 11:53:23 +0100

Hello Xu,

Few questions before I make my mind on "support" or "no support" :) ...

* How often intermediate nodes are supposed to re-test the latency and
readvertised the new value ?

* What is the permitted hysteresis when change will not trigger the
readvertisement ?

* How do you account for transit delay via network nodes which set
next hop self (example EBGP peers) ?

* In the case of SR being used which allows effectively per prefix
path selection how does test to per next hop helps in anything ?

* Do you intend to allow AIGP type 1 and new type to co-exist ?

- - -

How about talking or at least discussing in this draft a completely
different approach of just marking by regular community ingress to the
domain (or set of domains) an originator address which would not
change across BGP hops?

That would enable quick testing of end to end real path delay by those
BGP speakers which are interested in doing so. The advantages are
flexibility to enable it only for say small subset of very important
prefixes on a perhaps few BGP speakers and no requirement for any new
capability or BGP upgrades domain/set of domains wide.

Last but not least your proposal may perhaps work when you have BGP
control plane present on actual data plane devices. Now think how your
proposal brings any value when your control plane is 100% decoupled
from data plane devices and operates on few x86 blades not co-located
with data plane ?  Or worse how your draft is useful when BGP is moved
to the "cloud".

Cheers,
R.

On Thu, Dec 25, 2014 at 2:58 AM, Xuxiaohu <[email-masked]> wrote:
> “support” or “no support”.
>
>
>
> Thank you,
>
>
>
> Sue Hares
>
>
>
>
>
>
> [email-masked]

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 26 Dec 2014 02:40:39 +0000

Hi Robert,

Thanks a lot for your valuable comments. Please see my response inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
> Raszuk
> Sent: Thursday, December 25, 2014 6:53 PM
> To: Xuxiaohu
> Cc: idr wg
> Subject: Re: [Idr] WG adoption call for draft-xu-idr-performance-routing-01
> 
> Hello Xu,
> 

Regarding how often the latency is supposed to be tested, as it has been stated in the doc, " this document focuses exclusively on BGP matters and therefore all those BGP-irrelevant matters such as the mechanisms for measuring network latency are outside the scope of this document." As for how often the new latency value is advertised, on one hand, it depends on the configured minimum route advertisement interval (MRAI), on the other hand, as it has been stated in the doc, " To keep performance routes stable enough, a BGP speaker SHOULD use a configurable threshold for network latency fluctuation to avoid sending any update which would otherwise be triggered by a minor network latency fluctuation below that threshold."

> * What is the permitted hysteresis when change will not trigger the

There is no recommended value. It may need to be set according to special network conditions.

> * How do you account for transit delay via network nodes which set next hop
> self (example EBGP peers) ?

It said in the doc that " When distributing a performance route learnt from a BGP peer, if this BGP speaker has set itself as the NEXT_HOP of such route, the value of the NETWORK_LATENCY TLV SHOULD be increased by adding the network latency from itself to the previous NEXT_HOP of such route. Otherwise, the NETWORK_LATENCY TLV of such route MUST NOT be modified." I wonder whether the above statement has answered your question.

> * In the case of SR being used which allows effectively per prefix path selection
> how does test to per next hop helps in anything ?

Sorry that I don't understand your question. Could you say more?

> * Do you intend to allow AIGP type 1 and new type to co-exist ?

It's a good question. I believe they shouldn't co-exist. Maybe a sentence should be added to clarify it. Is it OK for you?

> - - -
> 
> How about talking or at least discussing in this draft a completely different
> approach of just marking by regular community ingress to the domain (or set of
> domains) an originator address which would not change across BGP hops?
> 
> That would enable quick testing of end to end real path delay by those BGP
> speakers which are interested in doing so. The advantages are flexibility to
> enable it only for say small subset of very important prefixes on a perhaps few
> BGP speakers and no requirement for any new capability or BGP upgrades
> domain/set of domains wide.

Sound interesting. We can discuss it further offline and then determine whether that different approach should be added into the future version of this draft.

> Last but not least your proposal may perhaps work when you have BGP control
> plane present on actual data plane devices. Now think how your proposal brings
> any value when your control plane is 100% decoupled from data plane devices
> and operates on few x86 blades not co-located with data plane ?  Or worse
> how your draft is useful when BGP is moved to the "cloud".

We have not yet considered that model. By the way, does that mean a common issue for the performance measurement mechanisms to address?

Best regards,
Xiaohu

> > draft-xu-idr-performance-routing-01  (12/23/2014 to 01/6/2014).  The
> > draft can be accessed at:
> >
> >
> >