I see where the draft defines a set of constraints.
The constraint that there be no other extension headers is a fairly
drastic constraint, which would seem a cause for concern.
Putting that aside however, the draft does not seem to provide any
explanation for why insertion rather than
Hello everyone, we’ve just submitted an updated draft that explains why SRH
insertion is performed in an SR domain, how it is accomplished and why it is
safe within the SR domain.
The authors look forward to your comments and suggestions on how to improve
this document.
Thanks!
Darren (on
Hi Ron, Yes I believe both Binding SID is an important design for inter-domain
signaling, and it is easy to add some mechanisms for SRv6+ to achieve similar
function of Binding SID. :) But I’m not sure if it is feasible to bind one
IPv6 address to ‘BSID’ in SRv6+, because as shown in
Dear SPRING,
As mentioned last week we have just submitted a new revision of
draft-ietf-srv6-network-programming. This is only an editorial update that
brings the pseudocode definition in consistency with the SRH.
Early next week we will submit another revision only with the split of the
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source Packet Routing in Networking WG of the
IETF.
Title : SRv6 Network Programming
Authors : Clarence Filsfils
Pablo
Hi Jeff,
It would be easy enough to add a binding SID to SRv6+. Given customer demand, I
would not be averse to adding one.
However, there is another way to get exactly the same behavior on the
forwarding plane without adding a new SID type.
Assume that on Node N, we have the following SFIB
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 local
address on the router ie. the router is acting as Segment Endpoint.
Thx,
R.
On Fri, Sep 20, 2019 at
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
Likewise, SP core routers would ignore the PSSI and wouldn’t even see the PPSI.
Ron
From: Dirk Steinberg
Sent: Wednesday, September 18, 2019 7:40 PM
To: Tom Herbert
Cc: Darren Dukes (ddukes) ; xie...@chinatelecom.cn; SPRING WG
; 6man
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
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
12 matches
Mail list logo
