Subject: Re: [spring] draft-ietf-spring-conflict-resolution

From: [email-masked]
Date: Fri, 1 Jul 2016 17:45:32 +0800

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.

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.

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 1 Jul 2016 17:13:20 +0000

Deccan -

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 01, 2016 2:46 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]
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.

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.
   Les

Thanks

Deccan

---

From: [email-masked]
Date: Mon, 4 Jul 2016 10:32:42 +0800

Les, 

See inline.

"Les Ginsberg (ginsberg)" <[email-masked]> 
2016-07-02 01:13

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

Deccan -

His Les, 

[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.

[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.

---

From: [email-masked]
Date: Mon, 4 Jul 2016 10:36:55 +0800

Les,

sorry, correct a spelling mistake

彭少富153815/user/zte_ltd
2016-07-04 10:32

收件人
"Les Ginsberg (ginsberg)" <[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>
主题
答复: RE: [spring] draft-ietf-spring-conflict-resolution

Les, 

See inline.

收件人

Deccan -

His Les, 

smallest ones, not for conflict function.

   Les

Thanks 

Deccan

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 4 Jul 2016 10:00:14 +0200

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-masked]> wrote:

> Les,
>
> See inline.
>
>
>
>
>
>
> *"Les Ginsberg (ginsberg)" <[email-masked] <[email-masked]>>*
>
> 2016-07-02 01:13
> 收件人
> *From:* [email-masked] [mailto:[email-masked]
> <[email-masked]>]
> * Sent:* Friday, July 01, 2016 2:46 AM
> * To:* Les Ginsberg (ginsberg)
> * Cc:* [email-masked]
> * Subject:* Re: [spring] draft-ietf-spring-conflict-resolution
>
> His Les,
>
> sources, it will select a preference FEC to provide forwarding information.
> *[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
> 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
> 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.*
> 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
> * [Les:] We have looked at “Carrier of Carrier” and we disagree with your
> 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
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
>

---

From: [email-masked]
Date: Tue, 5 Jul 2016 11:56:58 +0800

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-masked]> 
发件人:  [email-masked]
2016-07-04 16:00

收件人
[email-masked], 
抄送
"Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [spring] 答复: RE: draft-ietf-spring-conflict-resolution

Hi Peng,

Cheers,
R.

See inline. 

收件人

Deccan - 

His Les, 

   Les 

Thanks 

Deccan

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 5 Jul 2016 06:05:17 +0000

Deccan –

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 – 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 – the use of SR has not changed this in any way.

   Les

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 04, 2016 8:57 PM
To: Robert Raszuk
Cc: Les Ginsberg (ginsberg); [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2016-07-04 16:00

收件人

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

抄送

"Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

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-masked]<mailto:[email-masked]>> wrote:
Les,

See inline.

"Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>

2016-07-02 01:13

收件人

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

抄送

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

主题

Deccan -

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, July 01, 2016 2:46 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

His Les,

[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.

[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

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: [email-masked]
Date: Tue, 5 Jul 2016 18:03:37 +0800

Les,

Before SR, for all I know, the MPLS forwarding behavior for "Carrier's 
Carrier" often includes two forms, either an LDP label for Destination Z, 
or a BGP label (under an outer-label for BGP nexthop router) for 
Destination Z, i.e. ingress node in site A use an label directly to 
destination Z rather than first an label to CE-B then an label to 
destination Z.
I don't know if there are other documents, except rfc4364, to define other 
forwarding behaviors. Please prompt me.

However, I agree that it will be more flexible with forwarding behavior 
when using SR. It is possible to encapsulate label stack as you given:

  Label for CE-B assigned by PE-A
  Label for Destination Z (assigned by CE-B ??)

But the problem is still existing:
1) How about if "Label for CE-B" conflict with any prefix-sid in site A ?
2) It is the ingress node in site A to encapsulate "Label for Destination 
Z", so, how about "Label for Destination Z" conflict with any prefix-sid 
in site A? In other words, how does the ingress node in site A to do 
conflict process when the above conflict occurs? And, how does the ingress 
node ensure that it never act as a transit role so that no need to create 
ILM for Destination Z and ignore the sid conflict process (I guess that 
maybe you regard that FTN need not involve conflict questions, as SR label 
is out-label?).

Thanks

Deccan

2016-07-05 14:05

收件人
"[email-masked]" <[email-masked]>, Robert Raszuk 
<[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
RE: Re: [spring] 答复: RE: draft-ietf-spring-conflict-resolution

Deccan –
 
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:

Nodes in Site A will never POP the top label – 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 – 
the use of SR has not changed this in any way.
 
   Les

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 04, 2016 8:57 PM
To: Robert Raszuk
Cc: Les Ginsberg (ginsberg); [email-masked]; [email-masked]
Subject: 答复: Re: [spring] 答复: RE: 
draft-ietf-spring-conflict-resolution
 
Hi Robert, 

Thanks 

Deccan 

收件人
[email-masked], 
抄送
"Les Ginsberg (ginsberg)" <[email-masked]>, "[email-masked]" <
[email-masked]> 
主题
Re: [spring] 答复: RE: draft-ietf-spring-conflict-resolution

Hi Peng, 

Cheers,
R. 

See inline. 

收件人

Deccan - 

His Les, 

   Les 

Thanks 

Deccan