Hi Peng, On the point #2 you are right that externally received SIDs will be installed in the data plane of PEs.
However you need to observe that they will be installed in completely separate "contexts" in data plane hence current addition (after I brought this issue few weeks back) has been accurately addressed in new sections 3.2.6 and 4. All what you are saying is true and the current draft enables one to do that yet to keep consistent base topology in the network. Well modulo comments from Bruno which have not been yet well addressed. Cheers, R. On Mon, Jul 4, 2016 at 4:32 AM, <[email protected]> wrote: > Les, > > See inline. > > > > > > > *"Les Ginsberg (ginsberg)" <[email protected] <[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] > <[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 – 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 > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
