Subject: [spring] issues of draft-ietf-spring-conflict-resolution

From: [email-masked]
Date: Sat, 4 Jun 2016 18:14:20 +0800

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 4 Jun 2016 16:46:51 +0000

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-masked] [mailto:[email-masked]]
Sent: Saturday, June 04, 2016 3:14 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]
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

---

From: [email-masked]
Date: Mon, 6 Jun 2016 18:47:43 +0800

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-masked]> 
2016-06-05 00:46

收件人
"[email-masked]" <[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>
主题
RE: issues of draft-ietf-spring-conflict-resolution

Peng –
 
The draft explicitly states that the problem to be addressed is protocol 
independent. Some excerpts:
 
1.Introduction
…
 
…
 
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

Hi les and other authors 

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 6 Jun 2016 14:22:19 +0000

Peng –

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 – 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 – but it has been acknowledged that this is a use case which we need to address – and the draft will do so – 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-masked] [mailto:[email-masked]]
Sent: Monday, June 06, 2016 3:48 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]
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-masked]<mailto:[email-masked]>>

2016-06-05 00:46

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

Peng –

1.Introduction
…

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-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Saturday, June 04, 2016 3:14 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]<mailto:[email-masked]>
Subject: issues of draft-ietf-spring-conflict-resolution

Hi les and other authors

Thanks

Deccan

---

From: [email-masked]
Date: Tue, 7 Jun 2016 11:43:39 +0800

Les

"different SR forwarding contexts" you mentioned below let me understand 
that in some rare cases both sides of the conflict can win, so that both 
sides can install forwarding entries in data plane and use "different SR 
forwarding contexts" to distinguish. If I understand correctly, I refer to 
these rare cases as "win-win" case(also I refer to as regular scenario in 
my last mail, i.e. not really conflict), and other prevalent cases as 
"win-lose" case.

Undoubtedly, I agree on your opinon to form a standard rules to do 
conflict resolution. But I think it is also important to identify which 
belongs to "win-win" case, and which belongs to "win-lose" case, because 
the conflict resolution rules are different for these two class cases.

My original attention is trying to classify "SR deployed different 
prefix-sid&SRGB in different IGP/BGP protocols of the same TOPOLOGY" as a 
"win-lose" case, but if anybody others say that it is a "win-win" case, 
how to do conflict resolution? So, unambiguous classification need to be 
added in this draft. 

Perhaps I have misunderstand the meaning of "different SR forwarding 
contexts", please just correct my mistakes.

Deccan

2016-06-06 22:22

收件人
"[email-masked]" <[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>
主题
RE: RE: issues of draft-ietf-spring-conflict-resolution

Peng –
 
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 – 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 – but it has been acknowledged that this is 
a use case which we need to address – and the draft will do so – 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

Les 

Thanks for your reply. 

Deccan 

收件人

Peng – 

1.Introduction 
… 

So we are in agreement. 

   Les 

Hi les and other authors 

Thanks 

Deccan