Peng -
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 - 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]]
Sent: Saturday, June 04, 2016 3:14 AM
To: Les Ginsberg (ginsberg)
Cc: [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.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
