Dan,
Both good questions !!!
In Ole’s example, a segment endpoint that is not the SR egress node executes a
service instruction. In SRv6+, this kind of service instruction is called a Per
Segment Service Instruction (PSSI). It is encoded in a Destination Options
header that precedes the Routing header. Because IPv6 processes extension
header in the order that they appear in the packet, this Destination Options
header is processed by each segment endpoint, including the SR Path egress node.
The Destination Options header includes one or more options. Options are
processed in the order that they appear in the header. Each option has a unique
type and the first two bits of the type identifier determine how the processing
node will behave if it does not recognize the option.
SRv6+ defines a new IPv6 Option, called the PSSI option. The first two bits of
its type identifier are 00. So, if the processing node does not recognize the
option, or is not configured to process the option, it skips over the option
and continues to process the packet. Typically, core routers won’t execute Per
Segment Service Instructions. So, by default, they will be configured to skip
over the PSSI option. However, devices that provide per segment services (e.g.,
firewall services , DPI services) will process the PSSI.
The PSSI by no means attempts to replace the NSH.
In SRv6+, service instructions that are executed by the SR path egress node
only are called Per Path Service Instructions (PPSI). These instructions are
encoded in another Destination Options header that precedes the upper layer
header. This Destination Options header is processed by the SR path egress node
only.
SRv6+ defines another new IPv6 Option, called the PSSI option. The first two
bits of its type identifier are 10. So, if the processing node does not
recognize the option, it discards the packet and sends an ICMP message to the
packet source.
The benefit of separating the Routing Header from the PPSI are as follows:
* An AH or ESP header can be interposed between the Routing Header and the
Destination Options header. The AH or ESP can be used to protect PPSI.
* The Routing header isn’t bloated with PPSI information. Therefore, ASIC
based intermediate nodes don’t have to load PPSI information into on chip memory
* That there is no need to define a myriad of SID’s, some of which are
valid only when SL is equal to 0 and others that are valid when SL > 0. If an
instruction is valid only when SL = 0, it isn’t a SID. It is a PPSI.
Ron
Juniper Business Use Only
From: spring <spring-boun...@ietf.org> On Behalf Of Bernier, Daniel
Sent: Wednesday, September 11, 2019 11:41 PM
To: xie...@chinatelecom.cn; List <spring@ietf.org>
Cc: Rob Shakir <ro...@google.com>; 6man <6...@ietf.org>; Tarek Saad
<tsaad....@gmail.com>; Robert Raszuk <rob...@raszuk.net>
Subject: Re: [spring] Beyond SRv6.
+1
The ability of using a single SRH to convey behaviour information wether they
are per-segment or per-path has proven to be very simple and quick to define in
various data plane targets.
At first analysis, trying to replicate with CRH + DOH variants, the logic
required for service programs is more complex.
What happens if I need TLVs mid-point in a path but not at its end (e.g.
referring to the Ole's ACME analogy) ? Would they now be defined in a
seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested
midpoint devices will have to lookup beyond the TLVs to get to CRH for next
segment ?
Similar question would be on how would we implement proxy behaviours either
dynamic or static ? If I read
https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04__;!8WoA6RjC81c!X44n64pmIbfHbV6M9TDLFFeeQIEn4zROUOebJ7V5MYncIU31g1sgm7aA1kXfbfNt$>
correctly, we then need NSH for richer service chains constructs (think
Gi-LAN). This means I need CRH, some variants of DOH + NSH.
I fail to see the simplicity there.
Dan B
________________________________
From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on
behalf of xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>
<xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>>
Sent: Wednesday, September 11, 2019 8:57 PM
To: List
Cc: Rob Shakir; 6man; Tarek Saad; Robert Raszuk
Subject: [EXT]Re: [spring] Beyond SRv6.
Hi, folks,
Last year China Telecom begun to implement SRv6 trial in Sichun province for
the bearing and interconnection of video platforms which are located in
different cities, service agilities,secure sepertion, traffic steering and
other features of SRv6 have been demonstrated in this trial. Based on this,
SRv6 will be implementated in larger-scale in CT.
No technologies is 100% perfect,I agree that compression mechanism is needed to
reduce the the overhead of long SID in the long term, but it is better to be
compatible withe SRH, instead of designing a complete new one. CRH is a
complete new design, it move the complexities from SRH to DOH.
Moreover, I hope more efforts of SRv6 should be given on how to support new
services,for instance, Application-aware network (APN). Meanwhile, we should
consider more on how to implmement smooth transition and protect the network
assetof carriers.
Best regards
Chongfeng
From: Dirk Steinberg<mailto:d...@lapishills.com>
Date: 2019-09-09 21:31
To: Gyan Mishra<mailto:hayabusa...@gmail.com>
CC: SPRING WG List<mailto:spring@ietf.org>;
6...@ietf.org<mailto:6...@ietf.org>; Robert Raszuk<mailto:rob...@raszuk.net>;
Rob Shakir<mailto:ro...@google.com>; Tarek Saad<mailto:tsaad....@gmail.com>
Subject: Re: [spring] Beyond SRv6.
There seems to be some confusion regarding TI-LFA.
A couple of comments:
- Remote LFA tunnel is not used with SR, only TI-LFA which
only operates on the node that is the PLR (point of local repair).
- Any encapsulation on the ingress PE with or without EH has nothing
to do with TI-LFA except for the special case where the ingress PE
itself is the PLR.
- TI-LFA is not an IGP extension and does not require one.
It is a purely local computation based on IGP topology.
- The PLR for TI-LFA may need to insert some SIDs into the SID
list to steer the packet around the failure. For the LFA base case
no SIDs are needed at all. If SID insertion is needed, the PLR
will push the required number of labels in the MPLS case.
For SRv6, the equivalent operation to the label push is to
insert an EH with the required SID list. The packet will already
have been encapsulated on the ingress PE and in the most
common Internet or VPN base use case it will not even have
an EH so that this EH insertion will result only in a single EH.
Alternatively, the PLR could also be configured to perform
encapsulation with a new IPv6 header using the repair SID
as IPv6 destination address, without needing any EH.
This will work for the vast majority of cases.
Remember that one 128-bit SID in SRv6 is in most cases
equivalent to 2 MPLS labels, i.e. a node label plus an
adjacency SID can be encoded in a single SRv6 SID.
Only in extreme cases would the PLR need to add an
EH to the new IPv6 header with more SIDs.
- EH insertion for TI-LFA has nothing to do with stitching SRv6 domains.
Hope it helps.
Cheers
Dirk
Am 08.09.2019 um 09:19 schrieb Gyan Mishra
<hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>>:
From reading through all the discussion threads the SR insertion is two fold
one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up
requiring double EH insertions on the Ingress PE tunnel head end SRv6 source
node and then second scenario being a possible EH insertions occurrence on
intermediate nodes. I have not read through the drafts or RFC regarding Ti-LFA
with SR but since that is an IGP extension I am guessing an opaque LSA and is
not the traditional MPLS FRR link/node/path protection that adds an additional
mpls shim so not sure why an EH insertion needs to occur for Ti-LFA. Can
someone clarify that use case for me. Also the EH insertion on intermediate
node what is the use case or reason for that. My guess is it’s for special use
case of stitching SRv6 domains together. Please clarify..
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
