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

From: Ron Bonica <[email-masked]>
Date: Tue, 1 Oct 2019 20:30:26 +0000

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?

                                                                                                 Ron

Juniper Business Use Only

---

From: Fernando Gont <[email-masked]>
Date: Wed, 2 Oct 2019 22:11:07 +0300

>   * Can a locator be longer than 64 bits? If so, how can the rest of the

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-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ron Bonica <[email-masked]>
Date: Thu, 3 Oct 2019 16:25:27 +0000

Fernando,

Someone should. I think that the expertise to do this is in 6man.

                                  Ron

-----Original Message-----
From: Fernando Gont <[email-masked]> 
Sent: Wednesday, October 2, 2019 3:11 PM
To: Ron Bonica <[email-masked]>; SPRING WG List <[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming - IPv6 Addresses and SIDs

>   * Can a locator be longer than 64 bits? If so, how can the rest of the

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,

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 9 Oct 2019 19:20:39 -0400

In-line comments 

Thanks 

Gyan

Sent from my iPhone

> On Oct 3, 2019, at 12:25 PM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Fernando,
> 

[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-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Ron Bonica <[email-masked]>
Date: Thu, 10 Oct 2019 00:02:48 +0000

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

-----Original Message-----
From: Gyan Mishra <[email-masked]> 
Sent: Wednesday, October 9, 2019 7:21 PM
To: Ron Bonica <[email-masked]>
Cc: Fernando Gont <[email-masked]>; SPRING WG List <[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming - IPv6 Addresses and SIDs

In-line comments 

Thanks 

Gyan

Sent from my iPhone

> 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

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

> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!8WoA6RjC81c!UP3yJRwYfx17fPimClpX4-wcZU8JT55LIEZGQRTz6hag6LoSzz8K
> kBJW9qEVHARw$

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 9 Oct 2019 22:58:04 -0400

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-masked]> wrote:
> 
> Gyan,
>

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Thu, 10 Oct 2019 08:44:30 +0000

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-masked]> On Behalf Of Gyan Mishra
Sent: 2019年10月10日 10:58
To: Ron Bonica <[email-masked]>
Cc: Fernando Gont <[email-masked]>; SPRING WG List <[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming - IPv6 Addresses and SIDs

Hi Ron, 

Cheers,

Gyan

Sent from my iPhone

> • 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
> 
>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Oct 2019 11:05:28 +0200

> 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) <
[email-masked]> 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.
>
> Cc: Fernando Gont <[email-masked]>; SPRING WG List <[email-masked]
> >
> 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.
>
> > 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.
> >
> > 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:
> >

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Thu, 10 Oct 2019 11:03:00 +0000

Of course, you can do that like your description, but that may lead to complicatedness, because you had better enable security measure for DDOS on SID within SRv6 domain when deploying SRv6, if you have a dedicated and separate SRv6 SID block, you can have only one ACL entry in ingress PE to filter malicious traffic target toward nodes inside SRv6 domain, so it is easy;

And if the SID represent Adj-SID such as END.X, and in further if you can not advertised it with IGP, but anyway it will lead to complexity, because you have to use a Node-SID plus Adj-SID to represent the link segment.

I think, if you have assign a SID prefix to a Node (SID block + parent Node ID),  all SRv6 SIDs instantiated in this Node will be covered within the SID prefix, so all what the Node have to do is  only advertisement for this SID prefix.

WANG Weibin

From: Robert Raszuk <[email-masked]>
Sent: 2019年10月10日 17:05
To: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Ron Bonica <[email-masked]>; Fernando Gont <[email-masked]>; SPRING WG List <[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming - IPv6 Addresses and SIDs

> 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) <[email-masked]<mailto:[email-masked]>> 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.

WANG Weibin

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Gyan Mishra
Sent: 2019年10月10日 10:58
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Fernando Gont <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming - IPv6 Addresses and SIDs

Hi Ron,

Cheers,

Gyan

Sent from my iPhone

> On Oct 9, 2019, at 8:02 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
>
> Gyan,
>
> From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
> To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
> Cc: Fernando Gont <[email-masked]<mailto:[email-masked]>>; SPRING WG List
> <[email-masked]<mailto:[email-masked]>>
>> On Oct 3, 2019, at 12:25 PM, Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Fernando,
>>
>> From: Fernando Gont <[email-masked]<mailto:[email-masked]>>
>> To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; SPRING WG List
>> <[email-masked]<mailto:[email-masked]>>
>> e-mail: [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spr>
>> i

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Oct 2019 14:17:48 +0200

> can have only one ACL entry in ingress PE to filter malicious traffic
target toward nodes inside SRv6 domain, so it is easy;

That is elementary best practice configuration regardless if you are
running SRv6 or not. It would be very dangerous to allow reachability to
your infrastructure addresses from outside in any real network.

Thx,
R.

On Thu, Oct 10, 2019 at 1:03 PM Wang, Weibin (NSB - CN/Shanghai) <
[email-masked]> wrote:

> Of course, you can do that like your description, but that may lead to
> complicatedness, because you had better enable security measure for DDOS on
> SID within SRv6 domain when deploying SRv6, if you have a dedicated and
> separate SRv6 SID block, you can have only one ACL entry in ingress PE to
> filter malicious traffic target toward nodes inside SRv6 domain, so it is
> easy;
>
>
>
> And if the SID represent Adj-SID such as END.X, and in further if you can
> not advertised it with IGP, but anyway it will lead to complexity, because
> you have to use a Node-SID plus Adj-SID to represent the link segment.
>
>
>
> I think, if you have assign a SID prefix to a Node (SID block + parent
> Node ID),  all SRv6 SIDs instantiated in this Node will be covered within
> the SID prefix, so all what the Node have to do is  only advertisement for
> this SID prefix.
>
>
>
> *Cheers !*
> *WANG Weibin  *
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* 2019年10月10日 17:05
> *To:* Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>
> *Cc:* Gyan Mishra <[email-masked]>; Ron Bonica <[email-masked]>;
> Fernando Gont <[email-masked]>; SPRING WG List <[email-masked]>
> *Subject:* Re: [spring] draft-ietf-spring-srv6-network-programming - IPv6
> Addresses and SIDs
>
>
>
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spr>
> >> i

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 10 Oct 2019 12:34:00 -0400

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-masked]> wrote:
>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 11 Oct 2019 14:05:24 +0000

Gyan,

Why exclude link local for adjacency segments?

                            Ron

-----Original Message-----
From: Gyan Mishra <[email-masked]> 
Sent: Thursday, October 10, 2019 12:34 PM
To: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>
Cc: Ron Bonica <[email-masked]>; Fernando Gont <[email-masked]>; SPRING WG List <[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming - IPv6 Addresses and SIDs

Ron

Thanks 

Gyan

Sent from my iPhone

>>>> The document should include a discussion of the relationship 
>>>> between
>>>> IPv6 addresses and SIDs. For example:
>>>> 
>>>> 
>>>> 
>>>> * Can a locator be longer than 64 bits? If so, how can the rest of 
>>>> the
>>>>  /64 be used?
>>> 
>> 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
>>> ng__;!8WoA6RjC81c!UP3yJRwYfx17fPimClpX4-wcZU8JT55LIEZGQRTz6hag6LoSzz
>>> 8
>>> K
>>> kBJW9qEVHARw$
> 
> ng__;!8WoA6RjC81c!Qg1ex-hXVBJKRryAR1Hl5x2o9By4PbwD0gDjfRxlvNtQ4zGljf0E
> omr2PHEsckWh$ _______________________________________________
> spring mailing list
> [email-masked]
> ng__;!8WoA6RjC81c!Qg1ex-hXVBJKRryAR1Hl5x2o9By4PbwD0gDjfRxlvNtQ4zGljf0E
> omr2PHEsckWh$

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 11 Oct 2019 11:06:18 -0400

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-masked]> wrote:
> 
> Gyan,
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Oct 2019 11:12:44 -0400

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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 11 Oct 2019 12:38:58 -0400

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 <[email-masked]>
wrote:

> > 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
> >
> >> Cc: Ron Bonica <[email-masked]>; Fernando Gont <
> [email-masked]>; SPRING WG List <[email-masked]>
> >> 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
> >>
> >>> 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
> >>>>  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.
> >>>>

-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 11 Oct 2019 12:52:29 -0400

in-line comment

On Fri, Oct 11, 2019 at 12:38 PM Gyan Mishra <[email-masked]> wrote:

> So then I believe my statement is correct that the SID would be just ULA
> or GUA and not multicast or link local.
>
> 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.
> 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:
    [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

>> > 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 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
>> >>>> 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.
>> >>>>
>> >>>> I am working on getting this setup in the lab now so that will
>> really help understand the real world implementations.
>> >>>>
>> >>>> SRv6 SID format:
>> >>>>

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Sat, 12 Oct 2019 02:50:14 +0000

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.

WANG Weibin

From: spring <[email-masked]> On Behalf Of Gyan Mishra
Sent: 2019年10月12日 0:52
To: Joel M. Halpern <[email-masked]>; Ron Bonica <[email-masked]>
Cc: SPRING WG List <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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.

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

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 <[email-masked]<mailto:[email-masked]>> 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:
>> On Oct 11, 2019, at 10:05 AM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Gyan,
>>
>> To: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]<mailto:[email-masked]>>
>> Cc: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Fernando Gont <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>
>>> On Oct 10, 2019, at 4:44 AM, Wang, Weibin (NSB - CN/Shanghai) <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>>> On Oct 3, 2019, at 12:25 PM, Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
>>>>>
>>>>> Fernando,
>>>>>
>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/sp>
>>>>> r
>>>>> i
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spri>
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spri>

--
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>
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: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>
www.linkedin.com/in/networking-technologies-consultant<http://www.linkedin.com/in/networking-technologies-consultant>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 12 Oct 2019 09:22:42 -0400

in-line

On Fri, Oct 11, 2019 at 10:50 PM Wang, Weibin (NSB - CN/Shanghai) <
[email-masked]> wrote:

> 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.
>
>
>
   [Gyan]  What section in the draft does it state the addressing to be
used.  Also why can't you use GUA or ULA in the SRV6 domain as the IPv6
dataplane SID locator 64 bit field only has to be reachable within the
domain to get to any node within the domain.

>
>
> *WANG Weibin  *
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Gyan Mishra
> *Sent:* 2019年10月12日 0:52
> *To:* Joel M. Halpern <[email-masked]>; Ron Bonica <
> [email-masked]>
> *Cc:* SPRING WG List <[email-masked]>
> >>> On Oct 10, 2019, at 4:44 AM, Wang, Weibin (NSB - CN/Shanghai) <
> [email-masked] <[email-masked]>> wrote:
> >>>
> >>>>> On Oct 3, 2019, at 12:25 PM, Ron Bonica <rbonica=
> [email-masked] <[email-masked]>> wrote:
> >>>>>
> >>>>> Fernando,
> >>>>>
> >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/sp>
> >>>>> r
> >>>>> i
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spri>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spri>

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Ron Bonica <[email-masked]>
Date: Sun, 13 Oct 2019 20:58:51 +0000

Folks,

I think that we need a global rule that says:

“With a /64, if one /128 represents an IPv6 interface, as described in RFC 4291, all /128 MUST either:

  *   Represent an IPv6 interface, as described in RFC 4291, or
  *   Be unassigned”

The 6man WG will need to make such a statement since it owns RFC 4291.

                                                             Ron

Juniper Business Use Only
From: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>
Sent: Friday, October 11, 2019 10:50 PM
To: Gyan Mishra <[email-masked]>; Joel M. Halpern <[email-masked]>; Ron Bonica <[email-masked]>
Cc: SPRING WG List <[email-masked]>
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming - IPv6 Addresses and SIDs

WANG Weibin

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

in-line comment

https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-04.pdf<https://urldefense.com/v3/__https:/tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-04.pdf__;!8WoA6RjC81c!QHsO_aGu11-D9W5HO3bN9nILQCXi32JwonAfblEnE26hCow8Pxh4Ht1X7kaFJ8iI$>

! Example

Gyan

Yours,
Joel

On 10/11/2019 11:06 AM, Gyan Mishra wrote:
>>>> * 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
> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!QHsO_aGu11-D9W5HO3bN9nILQCXi32JwonAfblEnE26hCow8Pxh4Ht1X7hYjvwpW$>
>

www.linkedin.com/in/networking-technologies-consultant<https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!8WoA6RjC81c!QHsO_aGu11-D9W5HO3bN9nILQCXi32JwonAfblEnE26hCow8Pxh4Ht1X7o_4patq$>

www.linkedin.com/in/networking-technologies-consultant<https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!8WoA6RjC81c!QHsO_aGu11-D9W5HO3bN9nILQCXi32JwonAfblEnE26hCow8Pxh4Ht1X7o_4patq$>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 13 Oct 2019 23:24:06 +0200

Hi Ron,

I disagree.

Your suggestion violates longest prefix match principle in routing.

It is huge waist of address space and is not specific to IPv6 at all.

Let me describe the deployment case where your suggestion would cause it to
break:

I have /64 prefix where a few  /128s from that space I allocate to local
interfaces making it a local v6 destinations on those nodes.

However in the spirit of CIDR I still want to to use some blocks of that
space - say  /126 or /124 as blocks which I only use to trigger local NAT
as per rfc6296. And NAT does not require local address to be a destination
address so it would be a big disservice to kill such deployment option.

Many thx,
R.

On Sun, Oct 13, 2019 at 10:59 PM Ron Bonica <rbonica=
[email-masked]> wrote:

>    - Represent an IPv6 interface, as described in RFC 4291, or
>    - Be unassigned”
>
>
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 14 Oct 2019 08:45:57 +1100

On Mon, 14 Oct 2019, 08:24 Robert Raszuk, <[email-masked]> wrote:

> Let me describe the deployment case where your suggestion would cause it
> to break:
>
> as per rfc6296.

Realise that RFC6296 is Experimental, and therefore nothing standard track
can rely on it.

Don't use NAT. IPv6 is pointless if you do.

RFC2993 - Architectural Implications of NAT
*https://tools.ietf.org/html/rfc2993 <https://tools.ietf.org/html/rfc2993>*

The Touble with NAT - APNIC blog articles

https://blog.apnic.net/2016/10/25/trouble-nat-part-1/

https://blog.apnic.net/2016/10/26/trouble-nat-part-2/

https://blog.apnic.net/2016/10/27/trouble-nat-part-3/

And NAT does not require local address to be a destination address so it
> would be a big disservice to kill such deployment option.
>
> Many thx,
> R.
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 14 Oct 2019 00:06:54 +0200

Hi Mark,

I am in complete agreement with you that NAT is evil and should be avoided
**.

However let me explain my use case of NAT. It is described in section 7
of draft-raszuk-teas-ip-te-np-00 only uses destination address mapping
without requirement that the destination is a local interface on a mid
point TE node:

   As an alternative solution to avoid unnecessary processing of
   extension header by nodes which are not required to do so
   implementation can treat SID with last four bits set to zero as none
   local destination address.  In such scenario source+destination
   lookup will instead of triggering local extension header processing
   invoke destination IPv6 NAT function as defined in [RFC6296
<https://tools.ietf.org/html/rfc6296>].  The
   NAT rules which will be pre-programmed using information contained in

   the PATH_LIST will effectively result in destination address swap.
   Such NAT translation is to be of unidirectional character can can
   remain fully stateless.

The way I read Ron's suggestion - it would result in huge address space
waist for no reason. That's all.

Many thx,
Robert.

PS.
** As side comment let me share that some of my observations lead me to
believe that the biggest obstacle of IPv6 deployment in a lot of
enterprises is the notion of end to end IPv6 transparency. But this is
different topic and different thread.

---

From: Ron Bonica <[email-masked]>
Date: Sun, 13 Oct 2019 22:39:06 +0000

Robert,

If you don't segregate addresses that represent address from addresses that don't represent addresses, how will IPv6 Neighbor Discovery be impacted?

                                          Ron

From: Robert Raszuk <[email-masked]>
Sent: Sunday, October 13, 2019 5:24 PM
To: Ron Bonica <[email-masked]>
Cc: SPRING WG List <[email-masked]>
Subject: IPv6 Addresses and SIDs

Hi Ron,

I disagree.

Let me describe the deployment case where your suggestion would cause it to break:

I have /64 prefix where a few  /128s from that space I allocate to local interfaces making it a local v6 destinations on those nodes.

However in the spirit of CIDR I still want to to use some blocks of that space - say  /126 or /124 as blocks which I only use to trigger local NAT as per rfc6296. And NAT does not require local address to be a destination address so it would be a big disservice to kill such deployment option.

Many thx,
R.

On Sun, Oct 13, 2019 at 10:59 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Folks,

"With a /64, if one /128 represents an IPv6 interface, as described in RFC 4291, all /128 MUST either:

  *   Be unassigned"

                                                             Ron

---

From: Ron Bonica <[email-masked]>
Date: Sun, 13 Oct 2019 22:45:07 +0000

Robert,

I'm having a hard time understanding exactly how I have violated the longest match principle. Could you provide:

  *   A pointer to a statement of the longest match principle
  *   A few words regarding how I have violated it

                                                              Ron

Hi Ron,

I disagree.

Many thx,
R.

                                                             Ron

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 14 Oct 2019 00:45:45 +0200

Ron,

The segregation is very natural - the addresses allocated to the local
interfaces (physical or virtual) are your local addresses. Remaining
addresses are not. Of course local address may be other then /128 as
described in expired Mark's draft:
https://www.ietf.org/archive/id/draft-smith-v6ops-larger-ipv6-loopback-prefix-04.txt

Thx,
R.

On Mon, Oct 14, 2019 at 12:39 AM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> If you don’t segregate addresses that represent address from addresses
> that don’t represent addresses, how will IPv6 Neighbor Discovery be
> impacted?
>
>
>
>                                           Ron
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 14 Oct 2019 00:57:19 +0200

Hi Ron,

/64 prefix is a pile of addresses ... if someone would be to follow your
suggestion I could not allocate some blocks of that prefix on R1, then some
other blocks on R2 then yet more on my servers.

You said:

*“With a /64, if one /128 represents an IPv6 interface, as described in RFC
4291, all /128 MUST either:*

   - *Represent an IPv6 interface, as described in RFC 4291, or*
   - *Be unassigned”*

Maybe you meant to say something else:

*“When a /64 is used as SRv6 locator prefix, if one /128 represents an IPv6
interface, as described in RFC 4291, all /128 MUST either:*

   - *Represent an IPv6 interface, as described in RFC 4291, or*
   - *Be unassigned”*

But then you sent this to SPRINT indicating that 6MAN should be the
audience :).

Best,
R.

On Mon, Oct 14, 2019 at 12:45 AM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> I’m having a hard time understanding exactly how I have violated the
> longest match principle. Could you provide:
>
>
>
>    - A pointer to a statement of the longest match principle
>    - A few words regarding how I have violated it
>
>
>
>                                                               Ron
>
>
>
>
>
> *Sent:* Sunday, October 13, 2019 5:24 PM
> *To:* Ron Bonica <[email-masked]>
> *Subject:* IPv6 Addresses and SIDs
>
>
>
> Hi Ron,
>
>
>
> I disagree.
>
>
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 14 Oct 2019 10:36:50 +1100

On Mon, 14 Oct 2019 at 09:57, Robert Raszuk <[email-masked]> wrote:
>
> Hi Ron,
>
> /64 prefix is a pile of addresses ...

It's more than that, there is an addressing model to follow. From RFC 4291,

"2.1.  Addressing Model

   IPv6 addresses of all types are assigned to interfaces, not nodes.
   An IPv6 unicast address refers to a single interface.  Since each
   interface belongs to a single node, any of that node's interfaces'
   unicast addresses may be used as an identifier for the node."

> if someone would be to follow your suggestion I could not allocate some blocks of that prefix on R1, then some other blocks on R2 then yet more on my servers.
>

You would have to divide your /64 of into smaller subnets to do that.

> Represent an IPv6 interface, as described in RFC 4291, or
> Be unassigned”
>
>
> “When a /64 is used as SRv6 locator prefix, if one /128 represents an IPv6 interface, as described in RFC 4291, all /128 MUST either:
>
>
>
> Represent an IPv6 interface, as described in RFC 4291, or
> Be unassigned”
>
> But then you sent this to SPRINT indicating that 6MAN should be the audience :).
>
> Best,
> R.
>
>
>> I’m having a hard time understanding exactly how I have violated the longest match principle. Could you provide:
>>
>>
>>
>> A pointer to a statement of the longest match principle
>> A few words regarding how I have violated it
>>
>>
>>
>>                                                               Ron
>>
>>
>>
>>
>>
>> On Sun, Oct 13, 2019 at 10:59 PM Ron Bonica <rbonica=[email-masked]> wrote:
>>
>> Folks,
>>
>>
>>
>> Represent an IPv6 interface, as described in RFC 4291, or
>> Be unassigned”
>>
>>
>>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 14 Oct 2019 01:23:17 +0000

Robert,

Yeah, there were a few typos in my original message. What I meant to say was:

  *   If a /64 contains a SID, it MUST NOT contain any addresses that represent interfaces.
  *   If a /64 contains an address that represents an interface, it MUST NOT contain SIDs.

If we don't do this, we have to specify how nodes behave when they receive ICMPv6 NS messages in which the target is:

  *   A locally instantiated SID
  *   A SID learned from the IGP

                                                                      Ron

From: Robert Raszuk <[email-masked]>
Sent: Sunday, October 13, 2019 6:57 PM
To: Ron Bonica <[email-masked]>
Cc: SPRING WG List <[email-masked]>
Subject: Re: IPv6 Addresses and SIDs

Hi Ron,

/64 prefix is a pile of addresses ... if someone would be to follow your suggestion I could not allocate some blocks of that prefix on R1, then some other blocks on R2 then yet more on my servers.

You said:

"When a /64 is used as SRv6 locator prefix, if one /128 represents an IPv6 interface, as described in RFC 4291, all /128 MUST either:

Best,
R.

On Mon, Oct 14, 2019 at 12:45 AM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                              Ron

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>

Hi Ron,

I disagree.

Many thx,
R.

                                                             Ron

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Mon, 14 Oct 2019 05:45:30 +0000

Hi Ron:

Make sense, If there is a dedicated IPv6 block for SRv6 SID within SRv6 domain, then trouble situation you described does NOT occur, because the IPv6 address covered within SRv6 SID prefix does not be involved ICMPv6 ND protocol, because they are not configured under IP interfaces connected to “Link”.  I also think that the authors of NET-PGM draft have indicated that SRv6 SID has a separate IPv6 block in their Draft, but they don’t yet clearly stated which IPv6 block will be used for it.

WANG Weibin

From: spring <[email-masked]> On Behalf Of Ron Bonica
Sent: 2019年10月14日 9:23
To: Robert Raszuk <[email-masked]>
Cc: SPRING WG List <[email-masked]>
Subject: Re: [spring] IPv6 Addresses and SIDs

Robert,

If we don’t do this, we have to specify how nodes behave when they receive ICMPv6 NS messages in which the target is:

                                                                      Ron

Hi Ron,

You said:

Best,
R.

                                                              Ron

Hi Ron,

I disagree.

Many thx,
R.

                                                             Ron

---

From: Mark Smith <[email-masked]>
Date: Mon, 14 Oct 2019 19:07:38 +1100

On Mon, 14 Oct 2019, 16:45 Wang, Weibin (NSB - CN/Shanghai), <
[email-masked]> wrote:

> Hi Ron:
>
>
>
> Make sense, If there is a dedicated IPv6 block for SRv6 SID within SRv6
> domain, then trouble situation you described does NOT occur, because the
> IPv6 address covered within SRv6 SID prefix does not be involved ICMPv6 ND
> protocol, because they are not configured under IP interfaces connected to
> “Link”.
>

That does not comply with the IPv6 Addressing Architecture RFC.

(I think this is the 4th time SPRING have or are ignoring IPv6
specifications.)

I also think that the authors of NET-PGM draft have indicated that SRv6 SID
> has a separate IPv6 block in their Draft, but they don’t yet clearly stated
> which IPv6 block will be used for it.
>
>
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Ron Bonica
> *Sent:* 2019年10月14日 9:23
> *To:* Robert Raszuk <[email-masked]>
> *Subject:* Re: [spring] IPv6 Addresses and SIDs
>
>
>
> Robert,
>
>
>
>    - If a /64 contains a SID, it MUST NOT contain any addresses that
>    represent interfaces.
>    - If a /64 contains an address that represents an interface, it MUST
>    NOT contain SIDs.
>
>
>
> If we don’t do this, we have to specify how nodes behave when they receive
> ICMPv6 NS messages in which the target is:
>
>
>
>    - A locally instantiated SID
>    - A SID learned from the IGP
>
>
>
>                                                                       Ron
>
>
>
>
>
> *Sent:* Sunday, October 13, 2019 6:57 PM
> *Subject:* Re: IPv6 Addresses and SIDs
>
>
>
> Hi Ron,
>
>
>
> *“With a /64, if one /128 represents an IPv6 interface, as described in
> RFC 4291, all /128 MUST either:*
>
>
>
> *“When a /64 is used as SRv6 locator prefix, if one /128 represents an
> IPv6 interface, as described in RFC 4291, all /128 MUST either:*
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Oct 2019 10:12:39 -0400

On Mon, Oct 14, 2019 at 1:45 AM Wang, Weibin (NSB - CN/Shanghai) <
[email-masked]> wrote:

> “Link”.  I also think that the authors of NET-PGM draft have indicated that
> SRv6 SID has a separate IPv6 block in their Draft, but they don’t yet
> clearly stated which IPv6 block will be used for it.
>
>
>
>  [Gyan] I agree with what you are saying that if we allocate a separate
> /64 block GUA or ULA for SID for each node within the SR domain and that is
> separate from interface addressing ranges and is completely dedicated to
> SID.  So this would prevent any conflict with ND NS/NA processing.  Makes
> sense.  We are addressing the violation to the 6MAN RFC 8200 in draft below
> which was rewritten  and does look better with the addition of
> encapsulation but really need to provide an additional IPv6 encapsulation
> every time a EH is inserted "in flight" to be 100% compliant with the IPv6
> specification.   Since SRv6  ubiquitous in nature and can be used for any
> implementation where traffic engineering is necessary when you go
> inter-domain between administrative control it maybe difficult to enforce
> or have either the PSP & USP occur outside of the originating SRv6 domain
> that inserted the 1st EH header which the main use case that would be
> difficult is the "internet" use case.  If we cannot come up with a solution
> for that we would have to exclude the internet or any inter-domain SRv6
> implementations from using SRv6 from a standards track perspective.
>

https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Oct 2019 10:26:43 -0400

On Mon, Oct 14, 2019 at 10:12 AM Gyan Mishra <[email-masked]> wrote:

>>  [Gyan]  Spring WG  -??  Because SRv6 uses the same IPv6 data plan as
>> "Business as Usual" NORMAL IPv6 traffic use case of the "internet"  so
>> the an "SRv6 enabled router" that has the code that supports SRv6 has the
>> software feature to perform the PSP & USP but lets say the packet hits a
>> node that does not support SRv6 then the PSP & USP won't occur and all the
>> EH headers inserted for SRv6 routing header type 4 will remain in the
>> packet to the end destination.   How do we deal with this issue.
>>
>
>>
>> *WANG Weibin  *
>>
>>
>>
>> If we don’t do this, we have to specify how nodes behave when they
>> receive ICMPv6 NS messages in which the target is:
>>
>>
>>

-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 14 Oct 2019 16:34:18 +0200

Gyan,

>>> packet to the end destination.   How do we deal with this issue.

It's not an issue so we do not need to "deal with it".

SRv6 architecture operates just fine over non upgraded (read non SR aware)
IPv6 nodes.

r.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Oct 2019 10:45:18 -0400

> SRv6 architecture operates just fine over non upgraded (read non SR aware)

Ok did a google but could not find a draft on that please forward. So I can
see that is possible for intermediate nodes not necessary to be “SR aware”
I get that but what about the PSP or USP node that removes the SRH EH
header.  I would think that functionality requires that node to be SRv6
aware.

I looked on LSR WG and there is an SRv6 extension for ISIS and OSPF as I
expected. So since there are extensions related to IGP goes back to my
original question of SRv6 aware nodes.

https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Oct 2019 11:18:34 -0400

The SRv6 base document (approved by the 6man working group) does include 
additional behavioral requirements for all nodes in an SRv6-enabled domain.

Yours,
Joel

On 10/14/2019 10:34 AM, Robert Raszuk wrote:
> Gyan,
> 
>             __ [Gyan]  Spring WG  -??  Because SRv6 uses the same IPv6
>             data plan as "Business as Usual" NORMAL IPv6 traffic use
>             case of the "internet"  so the an "SRv6 enabled router" that
>             has the code that supports SRv6 has the software feature to
>             perform the PSP & USP but lets say the packet hits a node
>             that does not support SRv6 then the PSP & USP won't occur
>             and all the EH headers inserted for SRv6 routing header type
>             4 will remain in the packet to the end destination.   How do
>             we deal with this issue.
> 
> 
> 
> SRv6 architecture operates just fine over non upgraded (read non SR 
> aware) IPv6 nodes.
> 
> r.
> 
>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 14 Oct 2019 17:19:41 +0000

Mark,

Clearly, this does not comply with the addressing architecture. But I think that the best we can do is to limit the damage.

                                                                           Ron

From: Mark Smith <[email-masked]>
Sent: Monday, October 14, 2019 4:08 AM
To: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>
Cc: Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>; SPRING WG List <[email-masked]>
Subject: Re: [spring] IPv6 Addresses and SIDs

On Mon, 14 Oct 2019, 16:45 Wang, Weibin (NSB - CN/Shanghai), <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ron:

Make sense, If there is a dedicated IPv6 block for SRv6 SID within SRv6 domain, then trouble situation you described does NOT occur, because the IPv6 address covered within SRv6 SID prefix does not be involved ICMPv6 ND protocol, because they are not configured under IP interfaces connected to “Link”.

(I think this is the 4th time SPRING have or are ignoring IPv6 specifications.)

I also think that the authors of NET-PGM draft have indicated that SRv6 SID has a separate IPv6 block in their Draft, but they don’t yet clearly stated which IPv6 block will be used for it.

WANG Weibin

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Ron Bonica
Sent: 2019年10月14日 9:23
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] IPv6 Addresses and SIDs

Robert,

                                                                      Ron

Hi Ron,

You said:

Best,
R.

                                                              Ron

Hi Ron,

I disagree.

Many thx,
R.

                                                             Ron

Juniper Business Use Only
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!SEkBOAmRsYlBjRKWx1gZ4eegKkzZOKQgTtZuXxMv5TgCiZMT9xl0OH0Q8pbdZee9$>

---

From: Mark Smith <[email-masked]>
Date: Tue, 15 Oct 2019 07:31:12 +1100

On Tue, 15 Oct 2019, 04:19 Ron Bonica, <[email-masked]> wrote:

> Mark,
>
>
>
> Clearly, this does not comply with the addressing architecture. But I
> think that the best we can do is to limit the damage.
>

Has SPRING tried?

Assigning this address space to a virtual interface in the device would
make it comply with the RFC 4291 architecture, and also provide a handle
within the device for any other functions that could be operationally
useful.

For example, the SNMP MIB traffic counters for that virtual interface could
show SR traffic volumes as distinct from other IPv6 traffic to, from or
through the device. If there a different SR address spaces on the device,
the could be attached to different virtual interfaces, providing more
discrete SR traffic counters.

Having a virtual SR interface would also provide a handle to attach a
packet filter ACL to, which may be useful.

Having used IP encryption implementations that both did and didn't
represent traffic encryption paths as virtual tunnel interfaces, the tunnel
virtual interfaces implementations (also eventually adopted by the
non-virtual interface implementations) far more obvious and intuitive to
work with.

Regards,
Mark.

>
>
> Ron
>
>
>
>
>
> *From:* Mark Smith <[email-masked]>
> *Sent:* Monday, October 14, 2019 4:08 AM
> *Cc:* Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>;
> SPRING WG List <[email-masked]>
> I also think that the authors of NET-PGM draft have indicated that SRv6
> SID has a separate IPv6 block in their Draft, but they don’t yet clearly
> stated which IPv6 block will be used for it.
>
>
>
>
>
> *“**With a /64, if one /128 represents an IPv6 interface, as described in
>    - *Be unassigned**”*
> *“**When a /64 is used as SRv6 locator prefix,** if one /128 represents
> an IPv6 interface, as described in RFC 4291, all /128 MUST either:*
>
>
>
>    - *Be unassigned**”*
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!SEkBOAmRsYlBjRKWx1gZ4eegKkzZOKQgTtZuXxMv5TgCiZMT9xl0OH0Q8pbdZee9$>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Oct 2019 16:46:57 -0400

On Mon, Oct 14, 2019 at 4:31 PM Mark Smith <[email-masked]> wrote:

> useful..
> For example, the SNMP MIB traffic counters for that virtual interface
> could show SR traffic volumes as distinct from other IPv6 traffic to, from
> or through the device. If there a different SR address spaces on the
> device, the could be attached to different virtual interfaces, providing
> more discrete SR traffic counters.
>
> Mark..
> [Gyan]. Since we are requiring IPv6 encapsulation anyway on the ingress
> origin source node adding the  SRH EH in flight we could make it a GRE
> tunnel interface which would add 4 extra GRE bytes but would provide an
> interface for traffic statistics and mib counters depicting the IPv6 data
> plane identical to a 6in6 tunnel.
>

 Other even simpler option is to use a loopback with the dedicated SID /64
> prefix defines so its decoupled from any physical interface.
>

Since the traffic for SRv6 reuses the same IPv6 data plane the traffic
would go normally over the IGP routed enabled path to the next hop SID in
the SID list so the only gain from using GRE tunnel is if you want to be
able to decouple the SRv6 traffic from other IPv6 traffic since both share
the same data plane.

>> *“**With a /64, if one /128 represents an IPv6 interface, as described
>> in RFC 4291, all /128 MUST either:*
>>
>>
>>
-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: li zhenqiang <[email-masked]>
Date: Tue, 15 Oct 2019 07:47:24 +0000

Yes, the end destination can handle the IPv6 packet with SRH correctly.
Why do we need PSP or USP? May I know the benefits? Do the behaviors specified for PSP and USP comply with IETF specifications by leaving the outer IPv6 header there and removing the SRH?

Best Regards,
Zhenqiang Li
________________________________
[email-masked]

From: Robert Raszuk<mailto:[email-masked]>
Date: 2019-10-14 22:34
To: Gyan Mishra<mailto:[email-masked]>
CC: Wang, Weibin \(NSB - CN/Shanghai\)<mailto:[email-masked]>; Ron Bonica<mailto:rbonica=[email-masked]>; SPRING WG List<mailto:[email-masked]>
Subject: Re: [spring] IPv6 Addresses and SIDs
Gyan,

 [Gyan]  Spring WG  -??  Because SRv6 uses the same IPv6 data plan as "Business as Usual" NORMAL IPv6 traffic use case of the "internet"  so the an "SRv6 enabled router" that has the code that supports SRv6 has the software feature to perform the PSP & USP but lets say the packet hits a node that does not support SRv6 then the PSP & USP won't occur and all the EH headers inserted for SRv6 routing header type 4 will remain in the packet to the end destination.   How do we deal with this issue.

SRv6 architecture operates just fine over non upgraded (read non SR aware) IPv6 nodes.

r.