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

[Xuxiaohu <[e-mail]>]

Hi Bruno,

Sorry for my late response. If my understanding of the mechanisms as described in draft-ietf-idr-add-paths and RFC6774 correctly, they are intended for advertising multiple paths for a given NRLI, rather than creating separate routing and forwarding planes from the whole network perspective. However, it does make sense to mention both of them in the draft as they are applicable for a route reflector or a route reflector cluster to reflect all received performance routes when next-hop-self is disabled on the route reflector(s).

Best regards,
Xiaohu


From: [e-mail] [mailto:[e-mail]]
Sent: Friday, January 09, 2015 5:37 PM
To: Xuxiaohu
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01

Hi  Xiaohu,

Thanks for your response.

> As for 1), one major motivation for using a specific SAFI is to allow the performance routing paradigm to coexist with the vanilla routing paradigm.  As such, service providers could thus provide low-latency routing services (as a value-added service) while still offering the vanilla routing services depending on customers' requirements.

I agree with the goal.
Regarding the mean/solution, it could probably also be achieved by distributing multiple PATHs for the same NLRI. e.g. one path having the AIGP delay indication and being selected as per the delay, one vanilia path using the IGP cost.
Then there are already multiple existing solutions to advertise multiple paths for a NLRI: different RD in VPN context, or using ADD PATH, or using a different BGP routing plane (e.g. Robert's RFC 6774: distribution of divers BGP paths. here we would have one plane for delay and one for IGP cost).

Best regards,
Bruno



From: Xuxiaohu [mailto:[e-mail]]
Sent: Friday, January 09, 2015 9:53 AM
To: DECRAENE Bruno IMT/OLN; Susan Hares
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01

Hi Bruno,

Thanks a lot for your valuable comments.

As for 1), one major motivation for using a specific SAFI is to allow the performance routing paradigm to coexist with the vanilla routing paradigm.  As such, service providers could thus provide low-latency routing services (as a value-added service) while still offering the vanilla routing services depending on customers' requirements.

As for 2), we co-authors are considering how to address your comments and will respond to you soon.

Best regards,
Xiaohu

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Wednesday, January 07, 2015 9:24 PM
To: Susan Hares; Xuxiaohu
Cc: idr wg
Subject: RE: [Idr] WG adoption call for draft-xu-idr-performance-routing-01

Hi,

Please find below some comments on the draft:


1)      Main comments:
Why do you need a new specific SAFI? This seem to add complexity and reduce its applicability (e.g. L3 VPN, L2 VPN, any existing and future SAFI)
Why not simply adding the NETWORK_LATENCY TLV to existing routes? (when required)
Why don't you think that the requirement for low delay route is not shared by VPN routes/customers?


2)      Minor comments:
§5: Route Reflector issue
The fact that a RR selects the best path according to itself is not specific to this proposition. IMO this discussion should be moved to §6 "Deployment consideration" rather than §5 "Performance Route Selection". draft-ietf-idr-bgp-optimal-route-reflection is another solution. IMO rather than make a recommendation, I'd rather describe the issue and list possible solutions. e.g. "solutions x, y, z MAY be used to address this."

§6 Deployment consideration
The § have 2 strong RECOMMENDATION. IMHO they are debatable.

"It is strongly RECOMMENDED to deploy this performance-based BGP routing mechanism across multiple ASes which belong to a single administrative domain."
Why exactly? Because an AS from a different organization may lie in BGP info? How is this different from the AS_PATH & MED fields which can be used for route selection? Is it strongly RECOMMENDED that they be only exchanged between ASes which belong to a single administrative domain? What about real forwarding reachability (QoS)?.
Why can't you use or have the requirement between two ASes of different organisation? Following, this line, inter-AS VPN MUST NOT be used between ASes of different organization.
IMO I would rather remove such recommendation and discuss this point in the security section.

"Within each AS, it is RECOMMENTED to deliver a packet from a BGP speaker to the BGP NEXT_HOP via tunnels, typically TE LSP tunnels."
This really depend on your deployement model and I don't see why this is to be RECOMMENDED. e.g. within your AS, the IGP metric may be delay based, or you may be only really concerned about the inter domain issues (selecting the "best" ASBR), not the path within your AS where the delay may be small (or the delay delta between intra AS path may be small).
Same comment for the next RECOMMENDATION about IGP TE metric extension.


In general, I would favor that the document discuss the points that the SP should be aware of, rather than make RECOMMENDATION based on your assumptions of the deployments.

§9 security consideration
"Therefore, it MUST disable Performance Routing Capability negotiation between BGP peers which belong to different administration domains."
same comment as above.

Thanks,
Regards,
Bruno


From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Tuesday, December 23, 2014 3: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:

 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



_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________



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.