Re: [Teas] 回复： draft-huang-teas-bgp-community-pce-00

["Bhatia, Manav (Nokia - IN/Bangalore)" <[e-mail]>]

Hi Aijun,

The faulty line card comment was for the statement in the draft that said that packet losses will be minimum on the links that are most idle.

I concede that I perhaps don’t understand the idea. I will go through the slides that you have sent and see if that helps.

However, my stand on the section 5 still stands – I think its not entirely correct and the inferences that you have drawn don’t look right.

Cheers, Manav

From: Aijun Wang <[e-mail]>
Date: Monday, 17 July 2017 at 6:08 PM
To: "Bhatia, Manav (Nokia - IN/Bangalore)" <[e-mail]>
Cc: LuHuang <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Teas] 回复： draft-huang-teas-bgp-community-pce-00

Hi，Manav：
It seems that you did not understand the key idea of these solutions. The main use of the loopback address is to differentiate the prefixes group and thus to reduce the specific policy on the on-path routers.
If one line card is fault, it will not be on the calculated path.

From Aijun Wang


在 2017年7月17日，18:06，Bhatia, Manav (Nokia - IN/Bangalore) <[e-mail]<mailto:[e-mail]>> 写道：
Hi LuHang,

I skimmed through draft-wang-teas-pce-native-ip and I still don’t understand what needs to be standardized there.

I don’t think I like the idea of configuring a static route that binds a physical interface to a loopback IP – just looks too fragile to me. And which ironically also defeats the reason you have a loopback interface.

I also find the following text wrong:

“For Flow No.1, we can select the shortest distance path to carry the
   traffic; for Flow No.2, we can select the idle links to form its end
   to end path; for Flow No.3, we can let all the traffic pass one
   single path, no ECMP distribution on the parallel links is required.”

The shortest distance in IP does NOT necessarily mean that the traffic will experience least latency. This is plain wrong. Everything said in Section 5 to me is wrong. Choosing the idle links does NOT mean that the packet losses will be least. HINT: What if you have a faulty line card in that path?

Cheers, Manav

From: LuHuang <[e-mail]<mailto:[e-mail]>>
Reply-To: LuHuang <[e-mail]<mailto:[e-mail]>>
Date: Monday, 17 July 2017 at 11:21 AM
To: "Bhatia, Manav (Nokia - IN/Bangalore)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: 回复： [Teas] draft-huang-teas-bgp-community-pce-00

Hi, Manav

This draft is related to https://datatracker.ietf.org/doc/draft-wang-teas-pce-native-ip/ and propose another optional way to distinguish traffics which is based on BGP community instead of generating multiple BGP sessions.

As same as the method of multiple BGP sessions, in a native ip network PCEP need to be extended to support BGP community based traffic steering.

Thanks.

--------------------
LuHuang
China Mobile Research Institute
Mobile: [phone]



"Bhatia, Manav (Nokia - IN/Bangalore)" <[e-mail]<mailto:[e-mail]>> 于 2017年7月16日, 星期日, 上午 2:50 写道：

Hi,

This draft describes how a standard community could be used to steer traffic. Why do we need an IETF draft for this? What’s there to standardize here?

Cheers, Manav

From: Teas <[e-mail]<mailto:[e-mail]>> on behalf of LuHuang <[e-mail]<mailto:[e-mail]>>
Reply-To: LuHuang <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 13 July 2017 at 9:33 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] draft-huang-teas-bgp-community-pce-00

Hi, all

Please see the attachment for draft-huang-teas-bgp-community-pce-00.

This document is for the same scenario and requirements as [I-D.wang-teas-pce-native-ip], however, a BGP community based method is used for steering traffic instead of dual/multi-BGP sessions.

Hope to receive your comments and suggestions.

Thanks a lot.

--------------------
LuHuang
China Mobile Research Institute
Mobile: [phone]

_______________________________________________
Teas mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas