Re: [spring] draft-ietf-spring-srv6-network-programming - IPv6 Addresses and SIDs

[Robert Raszuk <[e-mail]>]

> so they are not overlap each other, but Both of them must advertised by
IGP or BGP protocol

While it is an option it is not "must". You can use your regular routing
addresses as SID locators and it perfectly ok for SRv6 and routing locators
to be identical.

Of course if you want to to create separate address spaces it is fine as
well.

Thx,
R.


On Thu, Oct 10, 2019 at 10:44 AM Wang, Weibin (NSB - CN/Shanghai) <
[e-mail]> 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 <[e-mail]> On Behalf Of Gyan Mishra
> Sent: 2019年10月10日 10:58
> To: Ron Bonica <[e-mail]>
> Cc: Fernando Gont <[e-mail]>; SPRING WG List <[e-mail]
> >
> 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 <[e-mail]> 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 <[e-mail]>
> > Sent: Wednesday, October 9, 2019 7:21 PM
> > To: Ron Bonica <[e-mail]>
> > Cc: Fernando Gont <[e-mail]>; SPRING WG List
> > <[e-mail]>
> > 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 <rbonica=
> [e-mail]> 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 <[e-mail]>
> >> Sent: Wednesday, October 2, 2019 3:11 PM
> >> To: Ron Bonica <[e-mail]>; SPRING WG List
> >> <[e-mail]>
> >> 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: [e-mail]
> >> 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
> >> [e-mail]
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spr
> >> i
> >> ng__;!8WoA6RjC81c!UP3yJRwYfx17fPimClpX4-wcZU8JT55LIEZGQRTz6hag6LoSzz8
> >> K
> >> kBJW9qEVHARw$
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>