Les, See inline.
"Les Ginsberg (ginsberg)" <[email protected]> 2016-07-02 01:13 收件人 "[email protected]" <[email protected]>, 抄送 "[email protected]" <[email protected]> 主题 RE: [spring] draft-ietf-spring-conflict-resolution 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. [Deccan] You are right, as per prefix/FEC is actually to split the original range to the smallest ones. My meaning is that there is no range idea during conflict process phase at the common place, all is done based on the existing data structure per prefix/FEC. Mapping range only appear in the individual protocol instance, but it is always to be split to the smallest ones, for ra for conflict function. 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 �C 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. [Deccan] Sorry, I cannot understand how to fulfill this case yet. IMO, packets from site A need contain SIDs for destinations in site B, so that packets can forward to the specific destination correctly, the SID of the PE can only be used to forward packets to the PE. Although, at the ingress node in site A, we can encapsulate SID of the PE again to hide SID of site B before sending packets, the ingress node in site A and the PE need still see the SID of site B. A node in site A can not ensure it will only act as a transit role. Could you explain more? 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. -------------------------------------------------------- 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. -------------------------------------------------------- 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
