If we need to see a running implementation to judge what the behavior is
supposed to be, it sounds like we could use clarifications of the
specification.
Yours,
Joel
On 10/11/2019 11:06 AM, Gyan Mishra wrote:
Good point. I think we need someone who has this in the lab or prod to see the
exact implemented behavior.
So since the URIB entry for the FEC destination egress PE prefix has the next
hop for the IGP used for IPv6 set to the “link local next hop would the SID
entry in the SID list be all link local addresses.
So the SRH header SID list the SID entry’s provide the “next hop” to source
route the traffic to the egress PE. So since normally the IGP next hop is a
link local would all the SID entries be link local and not GUA or ULA.
So the destination in the IPv6 packet be traffic engineered would be the L3 vpn
VRF destination and the FEC to forward to the egress PE that terminates ibgp
for vpnv4 vpnv6 is the loop /128 on the egress PE but to traffic engineer to
get their the SID list would have all the next hops listed similar to a TE ERO
explicit route object static LSP.
Gyan
Sent from my iPhone
On Oct 11, 2019, at 10:05 AM, Ron Bonica <[email protected]> wrote:
Gyan,
Why exclude link local for adjacency segments?
Ron
Juniper Business Use Only
-----Original Message-----
From: Gyan Mishra <[email protected]>
Sent: Thursday, October 10, 2019 12:34 PM
To: Wang, Weibin (NSB - CN/Shanghai) <[email protected]>
Cc: Ron Bonica <[email protected]>; Fernando Gont <[email protected]>; SPRING
WG List <[email protected]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming - IPv6
Addresses and SIDs
Makes sense. I think from Ron’s question is types address which would have to
be a GUA or ULA IPv6 URIB FIB routeable 128 bit prefix so that would exclude
multicast or link local since the prefix has to a unicast address and routable
and reachable within the domain.
Ron
I can take this back to 6MAN WG with regards to SID address types and structure
should be defined clearly as it is not today. Agreed.
Thanks
Gyan
Sent from my iPhone
On Oct 10, 2019, at 4:44 AM, Wang, Weibin (NSB - CN/Shanghai)
<[email protected]> wrote:
The key character of SRv6 is the SRv6 SID has capability of routable function,
it is reachable according to FIBv6, so the SIDs, I think, must be allocated
from unicast IPv6 address space, because the SRv6 domain is limited and
controlled by operator, such as deploying it within it's AS domain, so ULA as
well GUA, I think, are also options for SRv6 SID; and the SID block is separate
from plain IPv6 address block which are usually configured under Node's
interfaces; so they are not overlap each other, but Both of them must
advertised by IGP or BGP protocol, they perform different function within
network; how to allocate the SID and how to indicate length of SID prefix May
be up to operator and its specific network scenario.
--------------------------------------
Cheers !
WANG Weibin
-----Original Message-----
From: spring <[email protected]> On Behalf Of Gyan Mishra
Sent: 2019年10月10日 10:58
To: Ron Bonica <[email protected]>
Cc: Fernando Gont <[email protected]>; SPRING WG List
<[email protected]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming -
IPv6 Addresses and SIDs
Hi Ron,
I read that as well in my SRv6 studies so thinking about it logically from an
IGP ospf or ISIS longest match routing IPv6 FIB entry perspective for me makes
sense to understand the SRv6 IPv6 data plane. So I think my interpretation is
that the 128 bit SID is broken up into hierarchy fields with intelligence but
from a routing perspective it’s an IPv6 address of a connected interface on a P
or PE router which is a /127 for p2p links however it defines your “next hop”
NH or “next next hop” NNH in the legacy MPLS TE FRR node or path protection or
IP-LFA/Remote LFA or you can think of it like a MPLS TE autoroute or FA
(forwarding adjacencies) and to use that path you have to static next hop to
the tunnel but in this SRv6 case it’s a next hop IPv6 address which is a full
128 bit address that is in the SID entry in the SID list as the next hop for
your FEC destination in the IPv6 FIB entry.
To make this easier for me to understand the SRv6 spec and how to interpret
lets think of an example of a service provider core with an IPv6 data plane
path between ingress PE and egress and a egress FEC which is the loopback0 for
your ibgp peering vpn services which is the IPv6 destination last SID entry in
the SID list which the one hop prior P would do it’s normal PSP similar to PHP
in the mpls world. So now imagine each P router along the path to the
destination PE has a bunch of /127 p2p links. So now the 1st SID entry would
be to the next hop P from the originating PE that inserted the EH routing type
4 header SRH to source route the traffic along the engineered path. So now if
you examine that 1st SID entry it is a 128 bit address with embedded
information such as the function and arguments in the station id so the actual
IPv6 FIB entry for the egress PE FEC destination would have a next hop of the P
router which is the SID what the 1st SID contains which is a 128 bit address to
route to the 1st node which is the next hop PE. Once the packet arrives at the
1st node in the case the ingress P the station id IID is decoded for any
functions or argument the need to be executed by the instruction PSSI.
That’s my interpretation but I have to build this out in the lab do dig deeper
into the bits and bytes.
Cheers,
Gyan
Sent from my iPhone
On Oct 9, 2019, at 8:02 PM, Ron Bonica <[email protected]> wrote:
Gyan,
If the Locator were guaranteed to be 64 bits, as you suggest, there would be no
problem. However, the following text from Section 3.1 suggests otherwise.
" An SRv6 SID is represented as LOC:FUNCT where LOC (locator) is the L
most significant bits and FUNCT (function) is the 128-L least
significant bits of the SID. L is called the locator length and is
flexible. Each operator is free to use the locator length it
chooses. Most often the locator is routable and leads to the node
which instantiates that SID. A control-plane protocol might
represent the locator as B:N where B is the SRv6 SID block (IPv6
subnet allocated for SRv6 SIDs by the operator) and N is the
identifier of the parent node."
Ron
Juniper Business Use Only
-----Original Message-----
From: Gyan Mishra <[email protected]>
Sent: Wednesday, October 9, 2019 7:21 PM
To: Ron Bonica <[email protected]>
Cc: Fernando Gont <[email protected]>; SPRING WG List
<[email protected]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming -
IPv6 Addresses and SIDs
In-line comments
Thanks
Gyan
Sent from my iPhone
On Oct 3, 2019, at 12:25 PM, Ron Bonica <[email protected]>
wrote:
Fernando,
Someone should. I think that the expertise to do this is in 6man.
Ron
Juniper Business Use Only
-----Original Message-----
From: Fernando Gont <[email protected]>
Sent: Wednesday, October 2, 2019 3:11 PM
To: Ron Bonica <[email protected]>; SPRING WG List
<[email protected]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming -
IPv6 Addresses and SIDs
On 1/10/19 23:30, Ron Bonica wrote:
Authors,
The document should include a discussion of the relationship
between
IPv6 addresses and SIDs. For example:
* From what address space can SIDs be drawn? Link local? Multicast? ULA?
* Can a locator be longer than 64 bits? If so, how can the rest of
the
/64 be used?
I'm not saying that this shouldn't be done or that it is a bad idea,
but I'm curious if is anybody looking at this from a higher level?
(these seems pretty architectural to me)
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: [email protected]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
[Gyan] The SRv6 SID format is below:
So from an IPv6 data plane forwarding perspective the fixed length 64 bit
Locator is copied hop by hop into the destination address of the IPv6 header to
the tail end FEC destination egress PE and during failover Ti-LFA kicks in
additional EH is inserted {violating RFC 8200} at the PLR NNHOP to the similar
to RLFA PQ node.
So with SRV6 native traffic engineering the locator is either the physical IP
on ingress interface along each hop or loopback along each hop and so is either
a GUA or ULA but not LL or multicast address is what I understand from a
technical standpoint.
From everything I have read the SID is fixed at 64 bit length maximum but I
guess you can have a smaller then 64 bit locator.
I am working on getting this setup in the lab now so that will really help
understand the real world implementations.
SRv6 SID format:
128-bits Segment IDs can be used and allocated for different purposes, for
example:
• The first 64 bits can be used to direct traffic to a specific node
in the network – the “main body” of the program • The next 32 bits
can be used to enforce some actions on the traffic – the
“function”part • The remaining 32 bits can be used to pass some
additional information – the “argument” part 128-bit SRv6 SID
Locator: routed to the node performing the function Function: any
possible function Flexible bit-length selection
_______________________________________________
spring mailing list
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
r
i
ng__;!8WoA6RjC81c!UP3yJRwYfx17fPimClpX4-wcZU8JT55LIEZGQRTz6hag6LoSzz
8
K
kBJW9qEVHARw$
_______________________________________________
spring mailing list
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
ng__;!8WoA6RjC81c!Qg1ex-hXVBJKRryAR1Hl5x2o9By4PbwD0gDjfRxlvNtQ4zGljf0E
omr2PHEsckWh$ _______________________________________________
spring mailing list
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
ng__;!8WoA6RjC81c!Qg1ex-hXVBJKRryAR1Hl5x2o9By4PbwD0gDjfRxlvNtQ4zGljf0E
omr2PHEsckWh$
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
