Robert,
Think about how these things work in SR-MPLS. All of the “END.D functions” are
encoded in an MPLS service label (20 bits) or a VNI (24 bits). We merely moved
those bits into the 32 bit Option Data field of the PPSI.
If it is a good idea in SR-MPLS, why is it a bad idea in SRv6+?
Ron
From: Robert Raszuk <[email protected]>
Sent: Thursday, September 12, 2019 3:34 PM
To: Ron Bonica <[email protected]>
Cc: EXT - [email protected] <[email protected]>; Mark Smith
<[email protected]>; Rob Shakir <[email protected]>; SPRING WG
<[email protected]>; 6man <[email protected]>; [email protected]; Tarek Saad
<[email protected]>
Subject: Re: [spring] Beyond SRv6.
Dear Ron,
I was trying to stop responding but its pretty hard when I see such post like
your last one ...
> A single IPv6 Option, the PPSI, replaces all of the following SID
Please understand that this is like stating that:
"A single new additional airport replaces all the planes which operate to the
old airport. "
At most you could say that single new PPSI could contain 2^32 SR functions
which you call in your draft as "PPSI identifiers" From your documents it also
seems that you are defining a service instruction identifier in a flat space
which can contain the demux for the following technologies:
o Layer 2 VPN (L2VPN)
[RFC6624<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc6624__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvKDlYwG3$>].
o Layer 3 VPN (L3VPN)
[RFC4364<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4364__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvJRj7V9K$>].
o Virtual Private LAN Service (VPLS)
[RFC4761<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4761__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvLKysv2n$>][RFC4762].
o Ethernet VPN (EVPN)
[RFC7432<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7432__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvNdnfcBj$>].
o Pseudowires
[RFC8077<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8077__;!8WoA6RjC81c!Q0LqhRGndRvLABiWpZIc9aUdtjOsc_p_i-3pTF3fsnI_1woNeZgIJ2XEvGvQN6ft$>].
It also needs to be observed that putting all of those services into single
flat table lookup is not a sound design.
But what is most important that common hardware reads just entire header then
starts processing. So it really makes much more sense to encode SR SIDs and
related functions and their parameters in the same EH rather then scatter them
around.
Thank you,
R.
On Thu, Sep 12, 2019 at 8:51 PM Ron Bonica
<[email protected]<mailto:[email protected]>> wrote:
Daniel,
Not really. A single IPv6 Option, the PPSI, replaces all of the following SIDs:
* END.DX2
* END.DX2V
* END.DX2U
* END.DX2M
* END.DT4
* END.DX4
* END.DT6
* END.DX6
* END.DT46
* END.T
Ron
Juniper Business Use Only
Juniper Business Use Only
From: Bernier, Daniel <[email protected]<mailto:[email protected]>>
Sent: Thursday, September 12, 2019 2:26 PM
To: Ron Bonica <[email protected]<mailto:[email protected]>>; Mark Smith
<[email protected]<mailto:[email protected]>>
Cc: Rob Shakir <[email protected]<mailto:[email protected]>>; SPRING WG
<[email protected]<mailto:[email protected]>>; 6man
<[email protected]<mailto:[email protected]>>; Robert Raszuk
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Tarek Saad
<[email protected]<mailto:[email protected]>>
Subject: RE: [spring] Beyond SRv6.
That was precisely my point
Having been involved in pushing SRv6 END behaviours in various targets, I can
first hand say that the primitives behind SRH processing is quite simple to
extend. In your extensibility model, every predefined or custom behavior
becomes a new DOH. On SRH, the EH does not change I just need to inform the
data plane that when receiving a packet with a specific SID in SRH, do this
internal processing.
On 2019-09-12, 12:34 PM, "Ron Bonica"
<[email protected]<mailto:[email protected]>> wrote:
Mark,
I think that you may have exposed yet another elephant in the room……
IPv6 defines a robust extensibility architecture, that includes multiple
extension headers. Initially, IPv6 adoption was slow and router vendors were
not highly motivated commit extension headers to ASICs. Also, in those days,
ASICs were not so capable as they are today.
From the above-mentioned data points, we should not infer that it is beyond the
capability of a modern vendor to develop an ASIC that supports a more complete
set of extension headers. Two things have changed. As IPv6 adoption progresses,
vendors are becoming more committed to IPv6. Beyond that, ASICs have become
more capable over the decades.
We shouldn’t abandon the IPv6 extensibility architecture based on a claim that
ASICs cannot and will never be able to process multiple extension headers.
Ron
From: ipv6 <[email protected]<mailto:[email protected]>> On Behalf Of
Mark Smith
Sent: Thursday, September 12, 2019 1:30 AM
To: EXT - [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Cc: Rob Shakir <[email protected]<mailto:[email protected]>>; SPRING WG
<[email protected]<mailto:[email protected]>>; 6man
<[email protected]<mailto:[email protected]>>; Robert Raszuk
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Tarek Saad
<[email protected]<mailto:[email protected]>>
Subject: Re: [spring] Beyond SRv6.
It's simple because IPv6 doesn't look past the fixed IPv6 header to perform its
forwarding, and matches on the Destination Address to determine if to perform
deeper packet host processing.
You're building much more complicated forwarding services if you're going to be
marching on TLVs etc. past the IPv6 fixed header.
However vendors and carrier engineering groups like selling and deploying new
gear, so I suppose that's ok. They don't have to operate it or fix it when it
breaks.
On Thu, 12 Sep 2019, 13:41 Bernier, Daniel,
<[email protected]<mailto:[email protected]>> wrote:
+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!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJjCZB0f5dp14y8L$>
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 <[email protected]<mailto:[email protected]>> on
behalf of [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
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:[email protected]>
Date: 2019-09-09 21:31
To: Gyan Mishra<mailto:[email protected]>
CC: SPRING WG List<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; Robert Raszuk<mailto:[email protected]>;
Rob Shakir<mailto:[email protected]>; Tarek Saad<mailto:[email protected]>
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
<[email protected]<mailto:[email protected]>>:
>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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJjCZB0f5aWDOXgb$>
Juniper Business Use Only
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
