Deccan - From: [email protected] [mailto:[email protected]] Sent: Friday, July 01, 2016 2:46 AM To: Les Ginsberg (ginsberg) Cc: [email protected] Subject: Re: [spring] draft-ietf-spring-conflict-resolution
His Les, 1) From implementation, because preference algorithm is protocol independent, it is better to do conflict resolution at a common place, not at individual protocol instance. For example, we can do prefix-conflict resolution when generate the preference FIB entry at the common place. For a preference FIB entry, the routing information may get from OSPF by administrative distance, but the SID information may get from ISIS by prefix-conflict algorithm. Then we can do sid-conflict resolution when generate the SID-LIB entry according to the above FIB entry and other sources, it will select a preference FEC to provide forwarding information. So, preference algorithm per prefix/fec is enough. Per range is possible, but implementation is complex. More complex is for "ignor overlay" per range. [Les:] Implementation-wise, you are free to implement this in any module you like so long as with the same database you come up with the same answer as other nodes in the network. The distinction between "Quarantine" and "Ignore Overlap" is that the latter attempts to use those portions of a range which do not have conflicts with other entries. The cost of doing so is having to create "derived entries" which represent those sub-ranges which do/do not have conflicts. Due to the added complexity this is NOT the first choice of the authors. If I were to categorize the two algorithms using your terminology "Quarantine" would be "per range" while "Ignore Overlap" would be "per prefix/FEC". So it is the latter which is more complex to implement. 2) The restrictions in new section "Scope of SR-MPLS SID Conflicts" maybe not true. Please just consider "Carrier of Carrier" case which deploy IGP+LDP between PE and CE. It is possible to deploy SR LSP in the second level carrier, so that an SR LSP is building from one site to another across the first level carrier, same as an LDP LSP. This means SIDs associated with destinations in Site A will be installed in the forwarding plane of routers in Site B. [Les:] We have looked at "Carrier of Carrier" and we disagree with your conclusion. To reach destinations in Site B from Site A packets will need to traverse the PE(s) connected to Site A. What will be installed in the forwarding plane of routers in Site A will be labels associated with the SID of the PE - not the SIDs for destinations in Site B. In fact, it is possible for destination 1.1.1.1 in Site A to use the same SID as destination 2.2.2.2 in Site B. This is discussed in Section 4 of the draft. Les Thanks Deccan -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
