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

["Wang, Weibin (NSB - CN/Shanghai)" <[e-mail]>]

From SRv6 deployment perspective, we should NOT change & impact existing measure of allocating IPv6 address which are used for node’s IP interfaces and basic IGP/BGP routing, such as IPv6 for loopback and physic interfaces within Node, that is basic requirement for normal IPv6 networking operation. So SRv6 SIDs had better be another extra IPv6 block for its purpose.
As far as I know, the IPv6 GUA block which is now being allocated is  that its most significant bits  is “001”, in further, this block has defined as the fixed format “64bits prefix + 64bits IID” in related RFCs, so I think the block May be not available for SRv6 SID. so suggest the authors of NET-PGM draft should clarify it.

--------------------------------------
Cheers !


WANG Weibin

From: spring <[e-mail]> On Behalf Of Gyan Mishra
Sent: 2019年10月12日 0:52
To: Joel M. Halpern <[e-mail]>; Ron Bonica <[e-mail]>
Cc: SPRING WG List <[e-mail]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming - IPv6 Addresses and SIDs


in-line comment

On Fri, Oct 11, 2019 at 12:38 PM Gyan Mishra <[e-mail]<mailto:[e-mail]>> wrote:

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].

    [Gyan]  In section 3.1  I bolded " Each operator is free to use the locator length it chooses." So I guess the locator field is 64 bits but I guess you could have a shorter locator field.
    So I guess what it sounds like  how this would work is imagine a SP core with many P routers hops along a path to an egress PE node and each P has tons of /127s links meshed through the P core.

    I am trying to envision how the addressing plan would work for SRv6 SP core.

   So each P node in the core would have a /64 allocated to it which is in essence a "summary route"  that contains all the contiguous /127s that reside on that P node and has a Loopback or virtual interface that has this /64 that is routable kind of like a BGP summary route and that is advertised into the IGP by every P router and every P router has this special /64 for SRv6 routing that is used for the SRH SID list to build any to any SRv6 TE paths.

So once you route hop by hop to that SID locator which is the /64 then as you land on each node you can do the PSSI and process the function/argument or what ever tasks need to be done hop by hop along the path to the egress PE FEC destination.

So now any ingress PE SRH would have in its RIB/FIB all the /64s for all the loops that represent each P node in the core to build the SID list for the traffic engineered path.

So now this /64 Locator is what the draft is stating can be any length meaning shorter then /64 for either GUI or ULA implementations.



Gyan



On Fri, Oct 11, 2019 at 11:12 AM Joel M. Halpern <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
>>
>> Gyan,
>>
>> Why exclude link local for adjacency segments?
>>
>>                             Ron
>>
>>
>>
>> Juniper Business Use Only
>>
>> -----Original Message-----
>> From: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
>> Sent: Thursday, October 10, 2019 12:34 PM
>> To: Wang, Weibin (NSB - CN/Shanghai) <[e-mail]<mailto:[e-mail]>>
>> Cc: Ron Bonica <[e-mail]<mailto:[e-mail]>>; Fernando Gont <[e-mail]<mailto:[e-mail]>>; SPRING WG List <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Gyan Mishra
>>> Sent: 2019年10月10日 10:58
>>> To: Ron Bonica <[e-mail]<mailto:[e-mail]>>
>>> Cc: Fernando Gont <[e-mail]<mailto:[e-mail]>>; SPRING WG List
>>> <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
>>>> Sent: Wednesday, October 9, 2019 7:21 PM
>>>> To: Ron Bonica <[e-mail]<mailto:[e-mail]>>
>>>> Cc: Fernando Gont <[e-mail]<mailto:[e-mail]>>; SPRING WG List
>>>> <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
>>>>> Sent: Wednesday, October 2, 2019 3:11 PM
>>>>> To: Ron Bonica <[e-mail]<mailto:[e-mail]>>; SPRING WG List
>>>>> <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp<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]<mailto:[e-mail]>
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spri>
>>> ng__;!8WoA6RjC81c!Qg1ex-hXVBJKRryAR1Hl5x2o9By4PbwD0gDjfRxlvNtQ4zGljf0E
>>> omr2PHEsckWh$ _______________________________________________
>>> spring mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spri>
>>> ng__;!8WoA6RjC81c!Qg1ex-hXVBJKRryAR1Hl5x2o9By4PbwD0gDjfRxlvNtQ4zGljf0E
>>> omr2PHEsckWh$
>
> _______________________________________________
> spring mailing list
> [e-mail]<mailto:[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]<mailto:[e-mail]>
www.linkedin.com/in/networking-technologies-consultant<http://www.linkedin.com/in/networking-technologies-consultant>



--
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]<mailto:[e-mail]>
www.linkedin.com/in/networking-technologies-consultant<http://www.linkedin.com/in/networking-technologies-consultant>