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

[Gyan Mishra <[e-mail]>]

Sorry I should have read through the draft more carefully as its depicted
clearly in an example in section 3. So the SIDs must be "routable" within
the SRv6 domain per the draft.

https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-04.pdf


So the SID is definitely routable reachable and so must be GUI or ULA and
cannot be a link local as it is rewriting the destination address with this
address to route the packet POP a SID entry hop by hop to source route the
packet to the egress node.  As far as the next hop it is still the
traditional IGP OSPF or ISIS link local address which is programmed into
the SID destination FIB entry as the next hop.  Sorry was confusion on my
part as I confused the next hop being overwritten like next hops in TE ERO
where in this case its the IPv6 data plane and the IPv6 header destination
is being overwritten to the next hop by the SRH SID entry being popped hop
by hop.

! Example
show ip route    2001:DB8:B:1:100: fe80::EUI64

So then I believe my statement is correct that the SID would be just ULA or
GUA and not multicast or link local.

  3. SRv6 SID As introduced in RFC8402 an SRv6 Segment Identifier is a
128-bit value. When an SRv6 SID is in the Destination Address field of an
IPv6 header of a packet, it is routed through an IPv6 network as an IPv6
address. Its processing is defined in
[I-D.ietf-6man-segment-routing-header] section 4.3 and reproduced here as a
reminder. Without constraining the details of an implementation, the SR
segment endpoint node creates Forwarding Information Base (FIB) entries for
its local SIDs. When an SRv6-capable node receives an IPv6 packet, it
performs a longest-prefix-match lookup on the packets destination address. This
lookup can return any of the following: - A FIB entry that represents a
locally instantiated SRv6 SID - A FIB entry that represents a local
interface, not locally instantiated as an SRv6 SID - A FIB entry that
represents a non-local route - No Match This document formally defines
behaviors and parameters for SRv6 SIDs.

3.1. SID format 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. The function part of the SID is
an opaque identification of a local behavior bound to the SID. The FUNCT
value zero is invalid.
  The terminology "function" refers to the bit-string in the SRv6 SID. The
terminology "behavior" identifies the pseudocode bound to the SID. The
behaviors are defined in Section 4 of this document. A behavior may require
additional arguments that would be placed immediately after the FUNCT. In
such case, the SRv6 SID will have the form LOC:FUNCT:ARGS::. For this
reason, the SRv6 SIDs are matched on a per longest-prefix-match basis. ARG
may contain information related to the flow, service, or any other
information required by FUNCT. The ARG value of a routed SID SHOULD remain
constant among packets in a given flow. Varying ARG values among packets in
a flow may result in different ECMP hashing and cause re-ordering.

3.2. SID reachability Most often, the node N would advertise IPv6
prefix(es) matching the LOC parts covering its SIDs or shorter-mask prefix.
The distribution of these advertisements and calculation of their
reachability are routing protocol specific aspects that are outside the
scope of this document. An SRv6 SID is said to be routed if its SID belongs
to an IPv6 prefix advertised via a routing protocol. *An SRv6 SID that does
not fulfill this condition is non-routed.* Let’s provide a classic
illustration: Node N is configured explicitly with two SIDs:
2001:DB8:B:1:100:: and 2001:DB8:B:2:101::. The network learns about a path
to 2001:DB8:B:1::/64 via the IGP and hence a packet destined to
2001:DB8:B:1:100:: would be routed up to N. The network does not learn
about a path to 2001:DB8:B:2::/64 via the IGP and hence a packet destined
to 2001:DB8:B:2:101:: would not be routed up to N. A packet could be
steered to a non-routed SID 2001:DB8:B:2:101:: by using a SID list
<...,2001:DB8:B:1:100::,2001:DB8:B:2:101::,...> where the non-routed SID is
preceded by a routed SID to the same node. Routed and non-routed SRv6 SIDs
are the SRv6 instantiation of global and local segments, respectively
[RFC8402].


On Fri, Oct 11, 2019 at 11:12 AM Joel M. Halpern <[e-mail]>
wrote:

> 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 <[e-mail]> wrote:
> >>
> >> Gyan,
> >>
> >> Why exclude link local for adjacency segments?
> >>
> >>                             Ron
> >>
> >>
> >>
> >> Juniper Business Use Only
> >>
> >> -----Original Message-----
> >> From: Gyan Mishra <[e-mail]>
> >> Sent: Thursday, October 10, 2019 12:34 PM
> >> To: Wang, Weibin (NSB - CN/Shanghai) <[e-mail]>
> >> Cc: Ron Bonica <[e-mail]>; Fernando Gont <
> [e-mail]>; SPRING WG List <[e-mail]>
> >> 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) <
> [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/sp
> >>>>> r
> >>>>> i
> >>>>> ng__;!8WoA6RjC81c!UP3yJRwYfx17fPimClpX4-wcZU8JT55LIEZGQRTz6hag6LoSzz
> >>>>> 8
> >>>>> K
> >>>>> kBJW9qEVHARw$
> >>>
> >>> _______________________________________________
> >>> spring mailing list
> >>> [e-mail]
> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> >>> ng__;!8WoA6RjC81c!Qg1ex-hXVBJKRryAR1Hl5x2o9By4PbwD0gDjfRxlvNtQ4zGljf0E
> >>> omr2PHEsckWh$ _______________________________________________
> >>> spring mailing list
> >>> [e-mail]
> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> >>> ng__;!8WoA6RjC81c!Qg1ex-hXVBJKRryAR1Hl5x2o9By4PbwD0gDjfRxlvNtQ4zGljf0E
> >>> omr2PHEsckWh$
> >
> > _______________________________________________
> > spring mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spring
> >
>


-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant