Greetings,
In terms of UHP, draft-ietf-isis-segment-routing-extensions-16
<https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16#section-2.1.1> describes
2 cases:
- P set, E unset
- P set, E set
However it looks that draft-ietf-spring-segment-routing-15
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.1.2> doesn't
make that distinction and doesn't seem to cover the latter case:
o A remote node M MUST maintain the following FIB entry for any
learned Prefix-SID SID-R attached to IP prefix R:
Incoming Active Segment: SID-R
Ingress Operation:
If the next-hop of R is the originator of R
and instructed to remove the active segment: NEXT
* Else: CONTINUE*
Egress interface: the interface towards the next-hop along the
path computed using the algorithm advertised with
the SID toward prefix R.
Would it make sense to also describe the 2nd option (E+P) given ISIS
draft brings this up as a use case?
thanks,
pk
On Sat, Jun 9, 2018 at 12:01 AM Przemyslaw Krol <[email protected]
<mailto:[email protected]>> wrote:
Greetings,
Few minor, cosmetic/editorial suggestions:
2.5. Incoming Label Collision
[...]
*(Endpoint, Color)* representing an SR policy [I.D.
filsfils-spring-segment-routing-policy]
(Color, Endpoint) is the ordering used by the policy draft. If the
decision is to correct it, there is few references in the draft
2.5.1. Tie-breaking Rules
[...]
o The Color ID is encoded using *16 bits*
*
*
should be 32 bits
(https://tools.ietf.org/html/rfc5512#section-4.3.1 &&
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-00#section-2.1)
2.6. Outgoing Label Collision
[...]
In the general case, the ingress node may not have exactly
*have* the same data of the receiving node
2.7. PUSH, CONTINUE, and NEXT
PUSH, NEXT, and CONTINUE are operations applied by the forwarding
plan*e*.
[...]
2.8. MPLS Label downloaded to FIB corresponding to Global and
Local SIDs
[...]
an IGP with SR extensions
*[*I-D.ietf-isis-segment-routing-extensions,
I-D.ietf-ospf-segment-routing-extensions]
^^^ missing '[' or alternatively both references should be
enclosed in their own []
thanks,
pk
On Fri, Jun 8, 2018 at 11:14 AM Chris Bowers
<[email protected] <mailto:[email protected]>>
wrote:
SPRING WG,
I generally support publication of
draft-ietf-spring-segment-routing-mpls. However, I think
that the text in sections 2.5 and 2.6 (on incoming label
collisions)
needs some work before publication. This text was added to
the draft a few months ago, and has not gotten much review
from the WG as a whole. The review and proposed text below
focuses on these sections.
As I understand the current text of the draft, the general
approach to resolving incoming label collisions seems
well-reasoned and complete. However, it is possible that
my interpretation of these tie-breaking rules is
not what the authors intended.
I'd like to propose the examples below to be included
in the draft to help clarify the tie-breaking rules
for incoming label collisions described in section 2.5.
I have highlighted several cases in these examples,
where I think the rules in section 2.5 need
to be clarified in order to unambiguously determine
the winning FEC in an example.
It may also be the case that the authors or other
WG participants will disagree with the interpretation of the
rules used to choose a winning FEC in some of these
examples. In that case, we should discuss
what is the correct interpretation, and clarify the
text in the draft to make the correct interpretation
clear.
Incoming label collision examples
=========
Node A
OSPF default admin distance for implementation=50
ISIS default admin distance for implementation=60
=========
Example incoming label conflict for label=1005 on node A
FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.5/32
<http://198.51.100.5/32> with index=5
OSPF SRGB on node A = [1000,1999]
Incoming label=1005
FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.105/32
<http://203.0.113.105/32> with index=5
ISIS SRGB on node A = [1000,1999]
Incoming label=1005
FEC1 and FEC2 both use dynamic SID assignment. Since neither of
the FEC types is SR Policy, we use the default admin distances
of 50
and 60 to break the tie. So FEC1 wins.
=========
Example incoming label conflict for label=1006 on node A
FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.6/32
<http://198.51.100.6/32> with index=6
OSPF SRGB on node A = [1000,1999]
Incoming label=1006
FEC2)
ISIS adjacency sid advertisement from node A with label=1006
Incoming label=1006
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.
FEC1 and FEC2 both use dynamic SID assignment. Since neither of
the FEC types is SR Policy, we use the default admin distances
of 50
and 60 to break the tie. So FEC1 wins.
=========
Example incoming label conflict for label=1007 on node A
FEC1)
OSPF prefix sid advertisement from node B for 198.51.100.7/32
<http://198.51.100.7/32> with index=7
OSPF SRGB on node A = [1000,1999]
Incoming label=1007
FEC2)
ISIS adjacency sid advertisement from node A with label=1007
Incoming label=1007
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.
FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID
assignment. So FEC2 wins.
=========
Example incoming label conflict for label=1008 on node A
FEC1)
OSPF prefix sid advertisement from node B for 198.51.100..8/32
<http://198.51.100.8/32> with index=8
OSPF SRGB on node A = [1000,1999]
Incoming label=1008
FEC2)
SR Policy advertisement from controller to node A
Endpoint = 192.0.2.208, color = 100, SID-List = <S1, S2>
Binding-SID label = 1008
FEC1 and FEC2 both use dynamic SID assignment.
Since one of the FEC types is SR Policy, default admin
distance is not used to break the tie.
/* The text in Section 2.5.1 needs to be clarified to specify
whether SR Policy always loses or always wins in this case. */
=========
Example incoming label conflict for label=1009 on node A
FEC1)
OSPF adjacency sid advertisement by node A with label=1009
Incoming label=1009
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.
FEC2)
ISIS adjacency sid advertisement by node A with label=1009
Incoming label=1009
Node A assigns this adjacency SID explicitly via configuration,
so the adjacency SID survives router reboots.
FEC1 and FEC2 both use explicit SID assignment. This kind of
incoming label collision should never occur, since an
implement of explicit SID assignment MUST guarantee
collision freeness on the same router.
========
Example incoming label conflict for label=1010 on node A
FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.110/32
<http://203.0.113.110/32> with index=10
ISIS SRGB on node A = [1000,1999]
Incoming label=1010
FEC2)
ISIS adjacency sid advertisement by node A with label=1010
Incoming label=1010
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.
FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point. FEC1 has FEC type
code-point=120, while FEC2 has FEC type code-point=130.
Therefore, FEC1 wins.
=========
Example incoming label conflict for label=1011 on node A
FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.111/32
<http://203.0.113.111/32> with index=11
ISIS SRGB on node A = [1000,1999]
Incoming label=1011
FEC2)
ISIS prefix sid advertisement from node C for
2001:DB8:1000::11/128 with index=11
ISIS SRGB on node A = [1000,1999]
Incoming label=1011
FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point. Both FECs have FEC type
code-point=120. So we compare address family. Since IPv4 is
preferred over IPv6, FEC1 wins.
=========
Example incoming label conflict for label=1012 on node A
FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.112/32
<http://203.0.113.112/32> with index=12
ISIS SRGB on node A = [1000,1999]
Incoming label=1012
FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.128/30
<http://203.0.113.128/30> with index=12
ISIS SRGB on node A = [1000,1999]
Incoming label=1012
FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point. Both FECs have FEC type
code-point=120. So we compare address family. Both are IPv4
address
family, so we compare prefix length. FEC1 has prefix length=32,
and FEC2 has prefix length=30, so FEC2 wins.
=========
Example incoming label conflict for label=1013 on node A
FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.113/32
<http://203.0.113.113/32> with index=13
ISIS SRGB on node A = [1000,1999]
Incoming label=1013
FEC2)
ISIS prefix sid advertisement from node C for
203.0.113..213/32 <http://203.0.113.213/32> with index=13
ISIS SRGB on node A = [1000,1999]
Incoming label=1013
FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
are from the same MCC, they have the same default admin distance.
So we compare FEC type code-point. Both FECs have FEC type
code-point=120. So we compare address family. Both are IPv4
address
family, so we compare prefix length. Prefix lengths are the same,
so we compare prefix. FEC1 has the lower prefix, so FEC1 wins..
=========
Example incoming label conflict for label=1014 on node A
FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.114/32
<http://203.0.113.114/32> with index=14
Routing Instance ID = 1000
ISIS SRGB on node A = [1000,1999]
Incoming label=1014
FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.114/32
<http://203.0.113.114/32> with index=14
Routing Instance ID = 2000
ISIS SRGB on node A = [1000,1999]
Incoming label=1014
These two FECs match all the way through the prefix length and
prefix.
So Routing Instance ID breaks the tie, with FEC1 winning.
=========
Example incoming label conflict for label=1015 on node A
FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.115/32
<http://203.0.113.115/32> with index=15
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
ISIS SRGB on node A = [1000,1999]
Incoming label=1015
FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.115/32
<http://203.0.113.115/32> with index=15
Routing Instance ID = 1000
ISIS Multi-topology ID = 40
ISIS SRGB on node A = [1000,1999]
Incoming label=1015
These two FECs match all the way through the prefix length,
prefix, and
Routing Instance ID. We compare ISIS Multi-topology ID, so
FEC2 wins.
/* There appears to be a typo in section 2.5.1, with two
different
orderings shown for a prefix-based FEC:
Prefix, Routing Instance, Topology, Algorithm
and
(Prefix Length, Prefix, SR Algorithm, routing_instance_id,
Topology)
This needs to be corrected. */
=========
Example incoming label conflict for label=1016 on node A
FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.116/32
<http://203.0.113.116/32> with index=16
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
SR algorithm = 0
ISIS SRGB on node A = [1000,1999]
Incoming label=1016
FEC2)
ISIS prefix sid advertisement from node C for
203..0.113.116/32 <http://203.0.113.116/32> with index=16
Routing Instance ID = 1000
ISIS Multi-topology ID = 50
SR algorithm = 22
ISIS SRGB on node A = [1000,1999]
Incoming label=1016
These two FECs match all the way through the prefix length,
prefix, and
Routing Instance ID, and Multi-topology ID. We compare SR
algorithm ID, so
FEC1 wins.
=========
Example incoming label conflict for label=1017 on node A
FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.117/32
<http://203.0.113.117/32> with index=17
ISIS SRGB on node A = [1000,1999]
Incoming label=1017
FEC2)
ISIS mapping server advertisement (SID/Label Binding TLV) from
node D:
Range=100, Prefix = 203.0.113.1/32 <http://203.0.113.1/32>
This mapping server advertisment generates 100 mappings, one
of which
maps 203.0.113.17/32 <http://203.0.113.17/32> to index=17.
ISIS SRGB on node A = [1000,1999]
Incoming label=1017
The fact that FEC1 comes from a normal prefix sid
advertisement and
FEC2 is generated from a mapping server advertisement is not
used as a tie-breaking parameter. Both FECs use dynamic SID
assignment,
are from the same MCC, have the same FEC type code-point=120.
Their prefix
lengths are the same as well. FEC2 wins based on lower
numerical prefix value,
since 203.0.113.17 is less than 203.0.113.117.
=========
Example incoming label conflict for label=1018 on node A
FEC1)
ISIS IPv4 adjacency sid advertisement from node A with label=1018
corresponding to next-hop interface address=192.0.2.100,
outgoing interface ID=5
Incoming label=1018
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.
FEC2)
ISIS IPv6 adjacency sid advertisement from node A with label=1018
corresponding to 2001:DB8:2000::100/128, outgoing interface ID=6.
Incoming label=1018
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.
Both FECs use dynamic SID assignment, are from the same MCC,
and have the same FEC type code-point=130. FEC1 wins
because IPv4 address family is preferred over IPv6.
=========
Example incoming label conflict for label=1019 on node A
FEC1)
ISIS IPv4 adjacency sid advertisement from node A with label=1019
corresponding to next-hop interface address=192.0.2.220,
outgoing interface ID=7
Incoming label=1019
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.
FEC2)
ISIS IPv4 adjacency sid advertisement from node A with label=1019
corresponding to next-hop interface address=192.0.2.230,
outgoing interface ID=8
Incoming label=1019
Node A allocates this adjacency SID dynamically,
and it may differ across router reboots.
Both FECs use dynamic SID assignment, are from the same MCC,
and have the same FEC type code-point=130. Both FECs have to
same address family. FEC1 wins based on having the lowest
next-hop
interface address.
/* It is not clear how to construct an example that
would result in using the outgoing interface ID as a tie-breaker.
It would be useful to understand why this is and clarify
it in the text. */
=========
Example incoming label conflict for label=1020 on node A
FEC1)
SR Policy advertisement from controller to node A
Endpoint address=2001:DB8:3000::100, color=100, SID-List=<S1, S2>
Binding-SID label=1020
FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.60, color=100, SID-List=<S3, S4>
Binding-SID label=1020
The FECs match through the tie-breaks up to and including
having the same FEC type code-point=140.
FEC2 wins based on IPv4 address family being preferred
over IPv6.
=========
Example incoming label conflict for label=1021 on node A
FEC1)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.70, color=100, SID-List=<S1, S2>
Binding-SID label=1021
FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.71, color=100, SID-List=<S3, S4>
Binding-SID label=1021
The FECs match through the tie-breaks up to and including
having the same address family. FEC1 wins by having the
lower numerical endpoint address value.
=========
I'd like to propose the examples below to be included
in the draft to help clarify section 2.6
(currently entitled "Outgoing Label Collision").
Examples of the Effect Incoming Label Collision on Outgoing
Label Programming
====================================
Example of effect of incoming label collision for label=1022
on outgoing label programming on node A
FEC1)
ISIS prefix sid advertisement from node B for 203.0.113.122/32
<http://203.0.113.122/32> with index=22
ISIS SRGB on node A = [1000,1999]
Incoming label=1022
FEC2)
ISIS prefix sid advertisement from node C for 203.0.113.222/32
<http://203.0.113.222/32> with index=22
ISIS SRGB on node A = [1000,1999]
Incoming label=1022
FEC1 wins based on lowest numerical prefix value. This means
that node A
installs a transit MPLS forwarding entry to SWAP incoming
label=1022, with outgoing label N,
and use outgoing interace I. N is determined by the index
associated with FEC1 (index=22) and
the SRGB advertised by the next-hop node on the shortest path
to reach
203.0.113.122/32 <http://203.0.113.122/32>.
Node A will generally also install an ingress MPLS forwarding
entry corresponding to FEC1 for
incoming prefix=203.0.113.122/32 <http://203.0.113.122/32>
pushing outgoing label N, and using outgoing interace I.
The rule in section 2.6 means that node A MUST NOT install an
ingress MPLS forwarding entry
corresponding to FEC2 ( which would be for incoming
prefix=203.0.113.222/32 <http://203.0.113.222/32>).
========
Example of effect of incoming label collision for label=1023
on outgoing label programming on node A
FEC1)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.80, color=100, SID-List=<S1, S2>
Binding-SID label=1023
FEC2)
SR Policy advertisement from controller to node A
Endpoint address=192.0.2.81, color=100, SID-List=<S3, S4>
Binding-SID label=1023
FEC1 wins by having the lower numerical endpoint address
value. This means that node A
installs a transit MPLS forwarding entry to SWAP incoming
label=1023, with outgoing labels
and outgoing interface determined by the SID-List for FEC1.
Node A will generally also install an ingress MPLS forwarding
entry corresponding to FEC1 for
incoming prefix=192.0.2.80/32 <http://192.0.2.80/32> pushing
outgoing labels and using the outgoing interface
determined by the SID-List for FEC1.
The rule in section 2.6 means that node A MUST NOT install an
ingress MPLS forwarding entry
corresponding to FEC2 ( which would be for incoming
prefix=192.0.2.81/32 <http://192.0.2.81/32>).
========
General comment:
section 2.6 title:
existing:
Outgoing Label Collision:
proposed:
Effect of Incoming Label Collision on Outgoing Label Programming :
--------------------------------------
Thanks,
Chris
On Thu, May 24, 2018 at 12:14 PM, <[email protected]
<mailto:[email protected]>> wrote:
Hello Working Group,
This email starts a Working Group Last Call on
draft-ietf-spring-segment-routing-mpls-13 [1] which is
considered mature and ready for a final working group review.
Please read this document if you haven't read the most
recent version yet, and send your comments to the list, no
later than *June 08*.
As a reminder, this document had already passed a WGLC
more than a year ago on version -06 [2], had been sent to
the AD but then returned to the WG.
Since then, the document has significantly changed, so
please read it again. In particular, it now includes the
resolution in case of incoming label collision. Hence it
killed draft-ietf-spring-conflict-resolution.
Both co-chairs co-author this document, hence:
- Shraddha has agreed to be the document shepherd... Thank
you Shraddha.
- Martin, our AD, has agreed to evaluate the WG consensus.
Thank you,
Bruno, Rob
[1]
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13
[2]
https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous
avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law;
they should not be distributed, used or copied without
authorisation.
If you have received this email in error, please notify the sender
and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that
have been modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
--
Przemyslaw "PK" Krol | Strategic Network Engineer ing
|[email protected] <mailto:[email protected]>
--
Przemyslaw "PK" Krol | Strategic Network Engineer ing
|[email protected] <mailto:[email protected]>
