Deccan �C There is a distinction between what labels may be included in the encapsulation for a packet and what labels will be “top of stack”. It is only the latter which gets installed in the forwarding plane.
To reach destinations in Site B from a node in Site A the packet has to be sent to a CE in site B via a PE accessible to nodes in Site A. So encapsulation to a destination Z in site B would look like: Label for CE-B assigned by PE-A Label for Destination Z Nodes in Site A will never POP the top label �C so they will never receive a packet addressed to Z where the top label is “Z”. Any label (or the SID used to derive it) that won’t be top of stack in Site A is not part of the database used for conflict resolution in Site A. Note that this is standard MPLS forwarding behavior for this deployment �C the use of SR has not changed this in any way. Les From: [email protected] [mailto:[email protected]] Sent: Monday, July 04, 2016 8:57 PM To: Robert Raszuk Cc: Les Ginsberg (ginsberg); [email protected]; [email protected] Subject: 答复: Re: [spring] 答复: RE: draft-ietf-spring-conflict-resolution Hi Robert, I think it is better to add more description to section 4 to eliminate confusion. Now we only get a "statement" that there is no problem, but not how. For example, if separate "contexts" in data plane as you said is a suggestion method to fulfill this case? Note that ILM corresponding to SR label has no "contexts" in data plane currently. Let's first concern issues in control plane. Supposed that there are site A,B,C attaching to provider network through PE1,PE2,PE3 respectively, and A,B,C belong to same vrf network. Supposed that destination 1.1.1.1 in site A, 2.2.2.2 in site B, 3.3.3.3 in site C assign the same prefix-sid. Because I have no entire idea about the solution behind section 4, I just list the questions as following: 1) PE1's BGP will receive VPNv4 prefix(2.2.2.2) from PE2 with prefix-sid same as VPNv4 prefix(3.3.3.3) from PE3, does it do conflict process in this phase? 2) PE1's BGP will import VPNv4 route to local vrf, so in the same VPN routing table, prefix(2.2.2.2) and prefix(3.3.3.3) have the same prefix-sid, does it do conflict process in this phase? 3) PE1's IGP will redistribute BGP routes in the vrf, so IGP will also see two prefixes have the same prefix-sid, does it do conflict process in this phase? 4) Each router in site A will receive perfix flood, so at each router its IGP will also see two prefixes have the same prefix-sid, does it do conflict process in this phase? Thanks Deccan Robert Raszuk <[email protected]<mailto:[email protected]>> 发件人: [email protected]<mailto:[email protected]> 2016-07-04 16:00 收件人 [email protected]<mailto:[email protected]>, 抄送 "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 主题 Re: [spring] 答复: RE: draft-ietf-spring-conflict-resolution 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]<mailto:[email protected]>> wrote: Les, See inline. "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>> 2016-07-02 01:13 收件人 "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, 抄送 "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 主题 RE: [spring] draft-ietf-spring-conflict-resolution Deccan - From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Friday, July 01, 2016 2:46 AM To: Les Ginsberg (ginsberg) Cc: [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring -------------------------------------------------------- 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
