Peng �C The quote from Section 3.2.7 provided in my previous response is explicit. It indicates that the database on which conflict resolution operates consists of mapping entries advertised by multiple protocols (when in use). “Mapping Entry” is defined in Section 3 and notably does NOT include protocol source as that is not relevant to the proposed conflict resolution policy. So if we have two protocols in use and they advertise different SIDs for the same prefix, both entries will be included in the conflict resolution database.
So I again state we are in agreement and the draft reflects this agreement. Conflicts SHOULD never occur in practice �C and if we could guarantee that configuration would always meet this requirement there would be no need for this draft. So the “implementation suggestion” you mention below is the expected deployment practice. But since we cannot guarantee that conflicts won’t occur the draft defines how to resolve conflicts consistently when they do occur. In all cases the expectation is that when there is a conflict there is a misconfiguration which needs to be corrected. There has been discussion in the past of cases (e.g. merging of two networks) where conflicting SIDs are assigned and the operator would like to be able to do the merge without having to reassign SIDs in one portion of the network (at least temporarily). This adds complexity to both control and forwarding planes �C but it has been acknowledged that this is a use case which we need to address �C and the draft will do so �C though it is far more important IMO to first agree on how to do conflict resolution in the more prevalent case where no conflicts are expected or intended. Les From: [email protected] [mailto:[email protected]] Sent: Monday, June 06, 2016 3:48 AM To: Les Ginsberg (ginsberg) Cc: [email protected] Subject: 答复: RE: issues of draft-ietf-spring-conflict-resolution Les Thanks for your reply. I think that the meaning of "protocol independent" maybe different between us. As the example in my last mail, my meaning of "protocol independent" is that in the originating router ISIS-SR instance and OSPF-SR instance SHOULD assign same prefix-sid for the same local prefix(such as loopback route, direct connected prefix, etc). If it is not so, caused by misconfiguration for example, other routers will receive conflict advertisements and "prefix conflict" will be applied to them according to this draft. In other words, my meaning of "protocol independent" is a implementation suggestion. I think that SR deploying differently in different IGP/BGP protocols is no valuable. If I have got your point, perhaps your meaning of "protocol independent" aims at the criteria of processing conflicting entries primarily, especially for "prefix conflict"(because "sid conflict" has a large independent declaration which has already included "protocol independent"). And you think that deployment scenarios where different SIDs assigned to the same prefix in different protocols in the same topology is possible and regular in fact, not only by misconfiguration. However, if it is a regular scenario, we must avoid processing "prefix conflict" for it, because both SIDs are valid and need to install forwarding entries in data plane. So, we have to use some mechanism to distinguish whether it is regular or misconfiguration, I think it is not so simple. Anyway, if this deployment scenario is actually in demand, it would be addressed. :) Deccan "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>> 2016-06-05 00:46 收件人 "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, 抄送 "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 主题 RE: issues of draft-ietf-spring-conflict-resolution Peng �C The draft explicitly states that the problem to be addressed is protocol independent. Some excerpts: 1.Introduction … The problem to be addressed is protocol independent i.e., segment related advertisements may be originated by multiple nodes using different protocols and yet the conflict resolution MUST be the same on all nodes regardless of the protocol used to transport the advertisements. 3.2.7. Guaranteeing Database Consistency … o In cases where multiple routing protocols are in use mapping entries advertised by all routing protocols MUST be included. So we are in agreement. That said, there are some deployment scenarios where we may want to have different SIDs for the same prefix in different protocols �C this is what I refer to as “different SR forwarding contexts”. This will be addressed in the next version of the draft (to be published soon). Les From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Saturday, June 04, 2016 3:14 AM To: Les Ginsberg (ginsberg) Cc: [email protected]<mailto:[email protected]> Subject: issues of draft-ietf-spring-conflict-resolution Hi les and other authors One conflict case which has not been discussed fully is prefix-sid conflict in different IGP protocols, such as ISIS and OSPF. Let's focus on the default TOPOLOGY based on SPF, both specified ISIS and OSPF instance deployed, both enabled SR. The RIB entrys of the default TOPOLOGY are selected between ISIS and OSPF by preference. For a specified SID, we all aggree that it can only be assigned to a single prefix, in all TOPOLOGYs, including the above ISIS and OSPF instance's prefix database, because an ILM entry in data plane can not represent two different FECs(suppose the label context is platform). Otherwise "SID Conflict" is applied to determine which prefix can possess the SID. But for one prefix, can it be assigned different SID respectively in the above ISIS and OSPF instance(of the default TOPOLOGY)? Someone would say that SR information is independent of IGP/BGP protocols, the later just distribute the SR information to neighbors. So, in our default TOPOLOGY example, the same prefix in ISIS and OSPF istance are the same SID (also same SRGB). But others would say that SR can be deployed differently in different IGP/BGP protocols, they can be different SIDs (also different SRGBs). I think there must be one is better or reasonable. As SR architecture said, prefix segment forward packet according to the shortest path. It is clearly in SR-IPv6 to see what happend, but it is complex in SR-MPLS because of index SID. Let's look at SR-IPv6, suppose the SR-TE path is calculated by the specified TE database which is produced by ISIS instance and we get an IPv6 address segment list, we can see the forwarding behavior of the SR-TE path is not certainly relevant with ISIS, because the shortest path to an IPv6 prefix segment in data plane maybe a preferred OSPF route. A simple IPv6 address has not restrict which IGP/BGP instance's route can direct forwarding. In SR-IPv6, we reach the simple purpsose, forwarding packet according to the shortest path, and we don't care the protocol type of the preferred route. We can get a conclusion, for the same prefix, the SID in ISIS and OSPF instance are same, which is an IPv6 address. So, in SR-MPLS it is also better for us to assign prefix SID which is independent of route protocol, in other words, both ISIS and OSPF instance(of the default TOPOLOGY) assign same SID for the same prefix, the prefix SID has no protocol implication. Let's look at SR-MPLS more closely, the SR-TE path which is calculated by ISIS-TE database will be translated to the corresponding label-stack, if the translation is done totally based on the ISIS-TE database, we can see: 1) The label-stack will forward the packet according to the expected shortest path, segment by segment, but it is just the ISIS's shortest path, NOT the default TOPOLOGY's shortest path. 2) The label is ISIS instance specified, if OSPF instance don't know it, packet arriving on the node which the corresponding prefix segment FEC is preferred OSPF route will be dropped. In brief, it seems that SR deployed differently in different IGP/BGP protocols brings more complexity. This complexity is no valuable to our simple purpose. If some implementation is like this, do you think it can be applied to "Prefix Conflict"? what's the conflict result? 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.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
