Robert
Responses in-line
Sent from my iPhone
> On Sep 20, 2019, at 4:44 AM, Robert Raszuk wrote:
>
> Hi Gyan,
>
> > So now talking SRv6 with Ti LFA why is there an EH insertion as we are
> > not using mpls LDP and not doing remote LFA and this is not the traditional
> > mpls TE FRR.
>
>
On Fri, Sep 20, 2019 at 2:30 PM Jeff Tantsura
wrote:
> Hi Gyan,
>
> Always a pleasure!
> See inline, please let me know if you have got any other questions.
>
> [Gyan] Thanks Jeff for the detailed responses!
>
I am with Verizon Communications and SME of Verizon's Network
Engineering & Tec
Hi Gyan,
Always a pleasure!
See inline, please let me know if you have got any other questions.
Cheers,
Jeff
On Sep 20, 2019, 10:20 AM -0700, Gyan Mishra , wrote:
>
>
> Sent from my iPhone
>
> On Sep 19, 2019, at 10:43 PM, Jeff Tantsura wrote:
>
> > Gyan,
> >
> > IPFRR doesn’t use/need any IGP
t;6...@ietf.org>; Rob Shakir ; Tarek
Saad
Subject: Re: [spring] “SRV6+” complexity in forwarding
Hi Ron,
No one is questioning that. If packet's destination is not a local address of a
router all options can be ignored.
Fun however starts when destination address in the packet *is* a lo
40 PM
> *To:* Tom Herbert
> *Cc:* Darren Dukes (ddukes) ; xie...@chinatelecom.cn;
> SPRING WG ; 6man <6...@ietf.org>; Robert Raszuk <
> rob...@raszuk.net>; Ron Bonica ; Rob Shakir <
> ro...@google.com>; Tarek Saad
> *Subject:* Re: [spring] “SRV6+” complexity in
Sent from my iPhone
> On Sep 19, 2019, at 10:43 PM, Jeff Tantsura wrote:
>
> Gyan,
>
> IPFRR doesn’t use/need any IGP extensions and is local to the device
> computing LFA.
> As RTGWG chair - I welcome you to read a number of rather well written RFCs
> on the topic we have published in RTGW
t;6...@ietf.org>; Robert Raszuk ; Ron
Bonica ; Rob Shakir ; Tarek Saad
Subject: Re: [spring] “SRV6+” complexity in forwarding
SRv6 does not require TLV processing for normal forwarding (use case: SP core).
- Dirk
On Wed, Sep 18, 2019 at 5:57 PM Tom Herbert
mailto:t...@herbertland.com>&g
Hi Stewart,
Yes this is exactly what I was trying to say. Your definition of TI-LFA as
expressed below is spot on:
"I think a better description for the technology is that it is not
constrained by topology, i.e. that you can create the repair path
regardless of the topology, although the more per
On 20/09/2019 09:44, Robert Raszuk wrote:
TI - stands for Topology Independent ... all other LFA modes rely on
topologies to be able to compute or not the backup path.
Well so does TI-LFA.
At some level you have to know the topology to calculate *any* path in
SR, else how do you know what
Hi Gyan,
> So now talking SRv6 with Ti LFA why is there an EH insertion as we are
> not using mpls LDP and not doing remote LFA and this is not the
traditional
> mpls TE FRR.
TI - stands for Topology Independent ... all other LFA modes rely on
topologies to be able to compute or not the backup pa
Gyan,
IPFRR doesn’t use/need any IGP extensions and is local to the device computing
LFA.
As RTGWG chair - I welcome you to read a number of rather well written RFCs on
the topic we have published in RTGWG over the last 7 years.
Pay attention on how LFAs are computed, this would clarify your qu
Thomas
Cc: xie...@chinatelecom.cn; SPRING WG ; 6man <6...@ietf.org>;
Dirk Steinberg ; Rob Shakir ; Tarek Saad
; Srihari Sangli
Subject: Re: [spring] “SRV6+” complexity in forwarding
Hi Reji,
Notice what it says: " ... explicitly listed intermediate nodes ... "
CRH which is used i
Hi Robert
I know we have gone through many many lengthy discussions adnosium and I know
the question has come up a few times and I know you replied back a few times
related to the service provider use case where we end up with the multiple
violations of RFC 8200 related to intermediate nodes E
Hi Reji,
Notice what it says: *" ... explicitly listed intermediate nodes ... "*
CRH which is used in SRv6+ does not explicitly list intermediate nodes so I
do not think the procedures in IPv6 spec apply as the way you interpret
them.
But I am i no way authoritative ... still learning IPv6 and t
Hi Robert,
>>I do not know what is the difference between IPv6 Destination Address in
the fixed header and "final destination". Where do you carry "final
destination" address ?
See Section 4.4 in RFC 8200. Hope its clear what's the final destination
and the context in which it is used.
Se
IPv6 fixed header has only one destination address. So TE midpoint is
either a packet's destination or not. It can not be both.
I do not know what is the difference between IPv6 Destination Address in
the fixed header and "final destination". Where do you carry "final
destination" address ?
Many
Hi Robert,
>>Well the crux of the matter is that you still need to process all EHs at each
>>IPv6 destination which here means each transit node per RFC8200
From RFC 8200 that doesn't seem to be the case or at least as I
understand. See Section 4.1 note 1 and note 3. Am I missing
something?
> I disagree. PPSI and PSSI leverages the DOHs in IPv6 architecture better.
> The SRv6+ drafts explain the usecases better FYI.
>
Well the crux of the matter is that you still need to process all EHs at
each IPv6 destination which here means each transit node per RFC8200. That
is regardless what a
Robert,
That is also why IMHO split of PSSI from PPSI is a bit wired as the only reason
for it seems to be to avoid dropping packets at mid points if PPSI is unknown
to it.
I disagree. PPSI and PSSI leverages the DOHs in IPv6 architecture better. The
SRv6+ drafts explain the usecases better FY
Hi Ron,
If you want to push complexity to the edge, put it in a destination option
> that is processed at the edge.
>
> Ron
>
Just curious what is your definition of the "edge" ? If destination address
matches local address that is the "edge" for the packet. So each TE
midpoint is the "edge".
Th
> On Sep 18, 2019, at 4:41 PM, Darren Dukes (ddukes) wrote:
>
> The complexity of "SRv6+" requires ASICs do much more work per packet vs SRv6.
Duh. More processing is more processing, whether done in hardware, software, or
firmware. I'm not a fan of segment routing for several reasons, but t
On Thu, 19 Sep 2019 at 11:16, Tom Herbert wrote:
>
> On Wed, Sep 18, 2019 at 5:33 PM Mark Smith wrote:
> >
> >
> >
> > On Thu, 19 Sep 2019, 09:40 Dirk Steinberg, wrote:
> >>
> >> SRv6 does not require TLV processing for normal forwarding (use case: SP
> >> core).
> >
> >
> > +1
> >
> > The Inte
On Thu, 19 Sep 2019 at 12:03, Ron Bonica wrote:
>
> If you want to push complexity to the edge, put it in a destination option
> that is processed at the edge.
>
Yes!
It might seem like "forwarding" is taking a packet in on one
interface, doing something to it, and then sending it out another.
If you want to push complexity to the edge, put it in a destination option that
is processed at the edge.
Ron
Sent from my phone
On Sep 18, 2019, at 8:33 PM, Mark Smith
mailto:markzzzsm...@gmail.com>> wrote:
On Thu, 19 Sep 2019, 09:40 Dirk Steinberg,
mailto:d...@lapishills.com>> wrote:
SRv
On Wed, Sep 18, 2019 at 5:33 PM Mark Smith wrote:
>
>
>
> On Thu, 19 Sep 2019, 09:40 Dirk Steinberg, wrote:
>>
>> SRv6 does not require TLV processing for normal forwarding (use case: SP
>> core).
>
>
> +1
>
> The Internet scales because complexity is pushed towards the edges.
>
Mark,
I agree,
+1
Agree.
Sent from my iPhone
> On Sep 18, 2019, at 5:32 PM, Mark Smith wrote:
>
>
>
>> On Thu, 19 Sep 2019, 09:40 Dirk Steinberg, wrote:
>> SRv6 does not require TLV processing for normal forwarding (use case: SP
>> core).
>
>
> +1
>
> The Internet scales because complexity is pushed t
None of that means there isn't room for improvement, or that lessons that
can be learned and applied a second time around (just need to watch out for
second system syndrome). The first version isn't always if ever the best
version.
On Thu, 19 Sep 2019, 09:57 Gyan Mishra, wrote:
> Daren
>
> This
On Thu, 19 Sep 2019, 09:40 Dirk Steinberg, wrote:
> SRv6 does not require TLV processing for normal forwarding (use case: SP
> core).
>
+1
The Internet scales because complexity is pushed towards the edges.
> - Dirk
>
> On Wed, Sep 18, 2019 at 5:57 PM Tom Herbert wrote:
>
>> On Wed, Sep 18,
This CISCO LIVE dives deeper into Cisco’s SRv6 implementation.
https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKSPG-3001.pdf
They go through all the SRV6 programmability End SID and SR insertion.
I have to read through to see if Cisco’s Ti-LFA implementation requires so many
EH’
Daren
This is from 2019 CISCO Live presentation
https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKMPL-2132.pdf
IETF Standardization
• The work started by Cisco in 2014
• Significant industry collaboration
• There are over SRv6 50 IETF documents
• The work spans over 13 working gro
SRv6 does not require TLV processing for normal forwarding (use case: SP
core).
- Dirk
On Wed, Sep 18, 2019 at 5:57 PM Tom Herbert wrote:
> On Wed, Sep 18, 2019 at 6:42 AM Darren Dukes (ddukes)
> wrote:
> >
> > Hi Ron.
> >
> > I summarized my argument as follows:
> > "Regardless of ASIC capabi
On Wed, Sep 18, 2019 at 6:42 AM Darren Dukes (ddukes) wrote:
>
> Hi Ron.
>
> I summarized my argument as follows:
> "Regardless of ASIC capabilities there are two performance penalties you will
> not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups.”
>
> You’ve confirmed this additiona
Hi Ron.
I summarized my argument as follows:
"Regardless of ASIC capabilities there are two performance penalties you will
not escape with PSSI+CRH+PPSI: TLV parsing and multiple lookups.”
You’ve confirmed this additional overhead for "SRv6+". Thanks.
You then say "So long as the ASIC can proc
* You also suggest that Juniper’s is the only implementation. Are you sure
that this is correct?
There is a packet capture of CRH for anyone who is interested taken from our
DPDK implementation – in this case – this is from the source node of traffic –
steering through nodes 3 -> 2 -> 5
Hi Darren,
I think that your argument can be summarized as follows:
* SRv6 requires only two FIB searches
* SRv6+ requires 4 or more FIB searches
* Therefore, SRv6+ cannot possibly forward at line speed
Have I summarized your argument correctly? If not, please set me straight. If
s
Hi Ron, I agree ASICs are always improving, indeed this is evident in the
number of successful SRv6 deployments and multiple vendor implementations at
line rate on merchant silicon, and multiple vendor ASICs.
Is “SRv6+” (PSSI+CRH+PPSI) implemented and deployed at line rate?
You’ve been asked thi
36 matches
Mail list logo
