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

Hi Robert,

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

> -----Original Message-----
> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] 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,
> 
> 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 ?

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
> readvertisement ?

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

> Cheers,
> R.
> 
> 
> On Thu, Dec 25, 2014 at 2:58 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> > Support as a co-author.
> >
> >
> >
> > Best regards,
> >
> > Xiaohu
> >
> >
> >
> > From: Susan Hares [mailto:shares@ndzh.com]
> > 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
> >
> >
> >
> > 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/.
> >
> >
> >
> > In your response, please discuss the pros/cons of this approach and
> > indicate “support” or “no support”.
> >
> >
> >
> > Thank you,
> >
> >
> >
> > Sue Hares
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> >