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

[<[e-mail]>]

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.