Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh

From: Mark Smith <[email-masked]>
Date: Fri, 12 Apr 2019 12:59:27 +1000

Hi Robert,

Sorry not to get back to you sooner.

On Mon, 1 Apr 2019 at 01:40, Robert Raszuk <[email-masked]> wrote:
> Hi Mark,
<snip>
>
> Since you correctly observed that now SID can be 32 bit and that is similar to the size of IPv4 my fundamental question is why not use something which already exists instead of defining some sort of new  from scratch ?
>
> It will be perfectly fine to have full proper SRv6 with SRH and LISP or Vector Routing as an alternative options. I really do not see a room or need for yet one more mapping plane. What problem does it solve which would not be already solved elsewhere ?
>

Well, there seems to be or have been concerns about the overhead of
using 128 bit SIDs in IPv6. That seemed to be the motivation for EH
insertion.

I sympathise with the overhead concern, although I'd be quite happy to
put up with the overhead and bandwidth costs of full IPv6-in-IPv6
tunnelling in comparison to non-commodity operations like inserting
the SRH EH into existing IPv6 packets to avoid that overhead.
Bandwidth is always getting cheaper.

I think the value in using IPv6 as the transport for SR is that IPv6
is becoming and will be the future the commodity layer 3 protocol.
MPLS may be fairly commodity, however IPv6 will be more so, and I
think the reason is that it is an end-to-end protocol that hosts use
(I think this is also why Ethernet has become the dominant link-layer
protocol, even for WAN links).

So if SR wants to benefit from and leverage IPv6's commodification,
then it needs to be limited to commodity IPv6 operations. If it
deviates, then it isn't commodity IPv6 any more.

So my motivation for suggesting 32 bit SIDs in IPv6, and I'm guessing
Ron's too for his smaller variable SIDs proposal including 32 bits, is
to try to reduce the overhead of SR over IPv6, while also retaining
commodity IPv6 operation.

Regards,
Mark.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 11 Apr 2019 20:21:06 -0700

So it looks like SR is either turning out to be like LISP or BIER, or both. So where is the unique value?

The next step is you’ll need a control plane (where discussions have begun) where it makes SR even more like LISP and support for multicast (where discussions have begun) where it makes SR even more like BIER. 

Dino

> On Apr 11, 2019, at 7:59 PM, Mark Smith <[email-masked]> wrote:
> 
> Hi Robert,
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 12 Apr 2019 07:25:50 -0700

On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <[email-masked]> wrote:
>
> Hi Mark,
>
> > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and a 32 bit alignment,
> > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 network.
> >
> > As 32 bit SIDs are also the same size as IPv4 addresses, that may also create some opportunities to
> > leverage IPv4 support in existing protocols to suite carrying and processing 32 bit SIDs with some, possibly
> > slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be
> > somehow leveraged to suit SR.
>
>
> Thank you for describing your understanding of fundamentals of SR.
>
> I think SR while indeed started with the story of "less control plane is good for you" now clearly has evolved into not only reduction of control plane but what can be even more important to some users ability to request specific behavior via programmed functions of network elements on a per flow basis without actually per flow or per path signalling or state.
>
> Yes for some it may be very useful feature and I am sure some will call it overload of data plane or . There is no one size fits all.
>
> With that let's observe that till today SR did not require any new mapping plane to be distributed in control plane and to be inserted into data plane. This is clearly a precedent.
>
> Furthermore as we see in companion documents all additional network functionality is being taken away from SRH and is being shifted to Destination Options .
>
> As far as mapping plane I already pointed out in my Vector Routing proposal that we have one already it is called BGP. One needs to also observe that we as industry worked number of years of protocol suite called LISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comments. Note also work for integrating SRv6 with LISP which is already is published.
>
Robert,

I don't see in the SRH draft where 32 bit SIDs are defined. Can you
please provide a reference?

As for trying to use something that already exists, why does SR used a
fixed size format for SIDs instead of a variable length format like
that described in RFC6554? Similarly, why does SR define it's own TLV
format instead of using Hop-by-Hop and Destination Options defined in
RFC8200?

Tom

> Kind regards,
> Robert
>>> 2) Is there an agreement that solutions which require additional per SR path state in both control plane and now in data plane are really something we should be endorsing here ?
>>
>>
>> I think so.
>>
>> My understanding of what SR is fundamentally about is to reduce control plane state and processing. The trade-off for reduced control plane state and processing is to instead carry and encode most or all of that information or its semantics as per-packet overhead.
>>
>> If the per-packet overhead becomes too large and expensive, then pushing some of that information and processing back into the control plane should be ok, as long as there is still a beneficial overall reduction in control plane state and processing.
>>
>> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 network.
>>
>> As 32 bit SIDs are also the same size as IPv4 addresses, that may also create some opportunities to leverage IPv4 support in existing protocols to suite carrying and processing 32 bit SIDs with some, possibly slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be somehow leveraged to suit SR.
>>
>> Regards,
>> Mark.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Fri, 12 Apr 2019 14:38:33 +0000

Dino,

Please stand by for ISIS Extensions To Support the CRH. At the moment, it is ten pages long, including two pages of boilerplate and two pages of references.

                                                                                                                         Ron

Juniper Internal

> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of Dino Farinacci
> Sent: Thursday, April 11, 2019 11:21 PM
> To: Mark Smith <[email-masked]>
> Cc: [email-masked]; SPRING WG <[email-masked]>; [email-masked]; Robert
> Raszuk <[email-masked]>
> Subject: Re: [spring] IPv6-compressed-routing-header-crh
> 
> The next step is you’ll need a control plane (where discussions have begun)
> where it makes SR even more like LISP and support for multicast (where
> discussions have begun) where it makes SR even more like BIER.
> 
> Dino
> 
> >> Since you correctly observed that now SID can be 32 bit and that is similar
> to the size of IPv4 my fundamental question is why not use something which
> already exists instead of defining some sort of new  from scratch ?
> >>
> >> It will be perfectly fine to have full proper SRv6 with SRH and LISP or
> Vector Routing as an alternative options. I really do not see a room or need for
> yet one more mapping plane. What problem does it solve which would not be
> already solved elsewhere ?
> >>
> >
> Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=dnxJ4ZzYGvZ8uKFytr8PMMHi5uD35z5ACAx67
> WEngXc&s=83q1T8NObaNS1omQoJRKsQ-b3a-x-_vIbE_LZmviPJ4&e=

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 12 Apr 2019 09:39:54 -0700

Sounds good for a intra-AS solution.

Dino

> On Apr 12, 2019, at 7:38 AM, Ron Bonica <[email-masked]> wrote:
> 
> Dino,
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 13 Apr 2019 06:48:30 +1000

Hi Tom,

> please provide a reference?

To clarify, I've been thinking about the idea of a smaller SID size
for IPv6 for a while now (since inserting EHs came up), and thought
about what would be a generic single size that might suit SR that
wasn't the same size as an IPv6 address. 32 bits seemed suitable to
me, although if people wanted bigger, I'd be suggesting 64 bits (not
entirely coincidentally the common IID size.)

Ron and others have written this draft, which supports SIDS of various
sizes - 8, 16 or 32 bits - that triggered this discussion.

"The IPv6 Compressed Routing Header (CRH)"
https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 12 Apr 2019 15:09:18 -0700

> sizes - 8, 16 or 32 bits - that triggered this discussion.
Mark,

Why not just put a SID length field in the header (like RFC6554 but
more generic). That would allow lengths of 1-16 bytes. Additional
flags could be used to indicate the semantics of the entries. For
instance, they might be actual addresses (128 bits for IPv6, 32 bits
for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
where the rest of the address can be inferred, indices into a table,
labels, etc.

Tom

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 13 Apr 2019 00:13:03 +0200

Hi Tom,

I already suggested this on March 30th ...

*"PS. But if you choose to go ahead with CRH I would highly advise to make
your CRH SID a variable length. "*

No feedback/response was received from authors.

Thx,
R.

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <[email-masked]> wrote:

> > > > > leverage IPv4 support in existing protocols to suite carrying and
> processing 32 bit SIDs with some, possibly
> > > > I think SR while indeed started with the story of "less control
> plane is good for you" now clearly has evolved into not only reduction of
> control plane but what can be even more important to some users ability to
> request specific behavior via programmed functions of network elements on a
> per flow basis without actually per flow or per path signalling or state.
> > > >
> > > > Yes for some it may be very useful feature and I am sure some will
> call it overload of data plane or . There is no one size fits all.
> > > >
> > > > With that let's observe that till today SR did not require any new
> mapping plane to be distributed in control plane and to be inserted into
> data plane. This is clearly a precedent.
> > > >
> > > > Furthermore as we see in companion documents all additional network
> functionality is being taken away from SRH and is being shifted to
> Destination Options .
> > > >
> > > > As far as mapping plane I already pointed out in my Vector Routing
> proposal that we have one already it is called BGP. One needs to also
> observe that we as industry worked number of years of protocol suite called
> LISP allowing not only very good mapping plane, but also data plane
> integration. CC-ing lisp authors for their comments. Note also work for
> integrating SRv6 with LISP which is already is published.
> > > >
> > > > Since you correctly observed that now SID can be 32 bit and that is
> similar to the size of IPv4 my fundamental question is why not use
> something which already exists instead of defining some sort of new  from
> scratch ?
> > > >
> > > Robert,
> > >
> > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP
> or Vector Routing as an alternative options. I really do not see a room or
> need for yet one more mapping plane. What problem does it solve which would
> not be already solved elsewhere ?
> > > >
> > > > Kind regards,
> > > > Robert
> > > >
> > > >
> > > >>> 2) Is there an agreement that solutions which require additional
> per SR path state in both control plane and now in data plane are really
> something we should be endorsing here ?
> > > >>
> > > >>
> > > >> I think so.
> > > >>
> > > >> My understanding of what SR is fundamentally about is to reduce
> control plane state and processing. The trade-off for reduced control plane
> state and processing is to instead carry and encode most or all of that
> information or its semantics as per-packet overhead.
> > > >>
> > > >> If the per-packet overhead becomes too large and expensive, then
> pushing some of that information and processing back into the control plane
> should be ok, as long as there is still a beneficial overall reduction in
> control plane state and processing.
> > > >>
> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary
> and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform
> SR in an IPv6 network.
> > > >>
> > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may
> also create some opportunities to leverage IPv4 support in existing
> protocols to suite carrying and processing 32 bit SIDs with some, possibly
> slight, modification. For example, perhaps IPv4 Address Family support in
> OSPFv3 (RFC 5838) could be somehow leveraged to suit SR.
> > > >>
> > > >> Regards,
> > > >> Mark.
> > > >

---

From: Mark Smith <[email-masked]>
Date: Sun, 14 Apr 2019 09:21:56 +1000

Hi Tom,

On Sat, 13 Apr 2019 at 08:09, Tom Herbert <[email-masked]> wrote:

<snip>

> more generic). That would allow lengths of 1-16 bytes.

More generally, I think it is better to have a single size field that
is a "one-size-fits-all" for all foreseeable use cases, and some
reasonable overhead to try to cater for future unforeseeable use
cases. It is simpler in design, implementation and operation.

A major operational issue is created if you happen to underestimate
the size you need, and have to go through your network increasing it.
For a production network, that sort of project is a bit like what
replacing an air plane engine would be like while the plane is flying.

The simplest and safest way to avoid a future size upgrade is to pick
a single size that far exceeds all likely use cases. Apparently that
was the practice with CLNS variable length addresses, where people
commonly picked 20 octet addresses regardless, with that practice used
to then decide against variable length IPv6 addresses. So people
preferred and tended to "one-size-fits-all" addressing anyway when
they had a variable length addressing choice. It has been common in
RFC1918 addressed networks to universally or near universally use /24s
for the same reasons.

I think RFC6554's complexity is justified because the links it is
operating over are very bandwidth and MTU constrained. More general
scenarios don't have those sorts of constraints, and constant
technology evolution is also constantly reducing or eliminating them.

>Additional

While not addressing the parts of addresses case, the other choice is
to encode semantics in the addresses indicating what they're
representing and how they should be processed. We already do that in
many cases - unicast address scopes and types (Link-Local scope vs
global ULA/GUA), and functions such as 6to4 or discard (i.e.
100::/64), and multicast address scopes and multicast forwarding via
replication at network junctions itself.

Regards,
Mark.

---

From: Ron Bonica <[email-masked]>
Date: Sun, 14 Apr 2019 23:54:58 +0000

Hi Robert,

In order to make the CRH ASIC-friendly, we have the following constraints:

  *   Support only a small handful of SID lengths
  *   If at all possible, make them align on word boundaries

Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should support a length greater than 32? Is there some length less than 32 that would be beneficial?

                                                     Ron

Juniper Internal
From: spring <[email-masked]> On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <[email-masked]>
Cc: SPRING WG <[email-masked]>; [email-masked]; Mark Smith <[email-masked]>; Dino Farinacci <[email-masked]>; [email-masked] list <[email-masked]>
Subject: Re: [spring] IPv6-compressed-routing-header-crh

Hi Tom,

"PS. But if you choose to go ahead with CRH I would highly advise to make your CRH SID a variable length. "

Thx,
R.

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Tom,
>
> On Sat, 13 Apr 2019 at 00:26, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
> > >
> > > Hi Mark,
> > >
Mark,

Tom

> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2D6man-2Dcomp-2Drtg-2Dhdr-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=GjqK8FoNrV07C15WLojvSxgX5EiIQWc_RaJ_gD9iJAI&s=Btt5PY_Iq3PKjxOHh5GSUQWMX0kPIYqZokMCtz2JA28&e=>
>
> Regards,
> Mark.
>
>
> > > ipv6@ietf..org<mailto:[email-masked]>
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=GjqK8FoNrV07C15WLojvSxgX5EiIQWc_RaJ_gD9iJAI&s=ozK7wzssqc1x3UQrEGZppBNd64FlYwd3RvhzdvZu5Uw&e=>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Apr 2019 21:59:58 -0400

I agree to make the SID align on word boundaries but I am thinking the software should have hardware independence if at all possible.

I think 32 bit is a reasonable size.

Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000

Sent from my iPhone

> On Apr 14, 2019, at 7:54 PM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Hi Robert,
>  
> Support only a small handful of SID lengths
> If at all possible, make them align on word boundaries
>  
> > > > ipv6@ietf...org

---

From: Tom Herbert <[email-masked]>
Date: Wed, 17 Apr 2019 20:02:42 -0700

> Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should support a length greater than 32? Is there some length less than 32 that would be beneficial?
Ron,

I think the term "Compressed Routing Header" is a bit of a misnomer.
It's really a "Mapped Routing Header" where the SIDs are presumably
smaller that the addresses that they map to. But, mapping requires
configuration and state in the network in order for it to work. For
instance, if I just want to send a packet to a list of nodes by IPv6
address, it seems like I'd need to use something else besides CRH (or
set up a possibly complex control plane that might be overkill for
this scenario). We can do that in segment routing since it carries 128
bit addresses, but then that creates giant headers which is what we're
trying to avoid in the first place. A compressed format would remove
redundant information that can be reconstructed at the hops without
additional state beyond what is in the packet. For instance,
compressing a list of IPv6 addresses is possible if they all share a
common prefix that can be compressed-- which is probably very likely
in the closed domains that it seems like source routing is targeted
to.

Tom

> > > > ipv6@ietf..org

---

From: Ron Bonica <[email-masked]>
Date: Thu, 18 Apr 2019 14:01:54 +0000

Gyan,

Let's think about how a network operator might choose a SID size....

Assume that an MAN includes 100 routers. These routers are connected to one another by infrastructure links. Each router has 20 or fewer infrastructure links.

The network operator might assign one loosely routes SID to each router. These loosely routed SIDs have network-wide significance (i.e., the cannot be reused).

The network operator might also assign one strictly routed SID to each link. The strictly routed SIDs have node-local significance only. They can be reused from one node to another.

So, in this case, the network operator only needs 120 SIDs. This fits in eight bits with plenty of room for growth.

Now consider another network that includes 30,000 routers. Each router is connected to its peers by 200 infrastructure links or fewer.  This network would need 30,200 SIDs. This would fit in 16 bits.

A *really big* network might require more than 32,000 SIDs. So, we support a 32-bit SID.

                                                                            Ron

Juniper Internal
From: Gyan Mishra <[email-masked]>
Sent: Wednesday, April 17, 2019 10:00 PM
To: Ron Bonica <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Tom Herbert <[email-masked]>; SPRING WG <[email-masked]>; [email-masked]; Dino Farinacci <[email-masked]>; [email-masked] list <[email-masked]>
Subject: Re: [spring] IPv6-compressed-routing-header-crh

Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_GYAN-2DMISHRA-2DRS-2DSP-2DMPLS-2DIPV6-2DEXPERT&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=7oInX5oGRmd36ozKW9gDLBfD4hBl0G89as-W-cNq90s&s=OVr9Tne6BBif0Ns2o9wbCzeNT3f1qK4Yq0tED0Ba6F8&e=>
Mobile - 202-734-1000<tel:202-734-1000>

Sent from my iPhone

On Apr 14, 2019, at 7:54 PM, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:
Hi Robert,

                                                     Ron

Juniper Internal
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Friday, April 12, 2019 6:13 PM
To: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Mark Smith <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] IPv6-compressed-routing-header-crh

Hi Tom,

Thx,
R.

Mark,

Tom

> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools..ietf.org_html_draft-2Dbonica-2D6man-2Dcomp-2Drtg-2Dhdr-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=GjqK8FoNrV07C15WLojvSxgX5EiIQWc_RaJ_gD9iJAI&s=Btt5PY_Iq3PKjxOHh5GSUQWMX0kPIYqZokMCtz2JA28&e=>
>
> Regards,
> Mark.
>
>
> > > ipv6@ietf....org<mailto:[email-masked]>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=7oInX5oGRmd36ozKW9gDLBfD4hBl0G89as-W-cNq90s&s=DgsqbOLgIMGesxMPjVyRODst-R9NG4CWqnD02hIVOXc&e=>
--------------------------------------------------------------------

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Apr 2019 16:30:29 +0200

Hi Ron,

I must observe that your analysis is incorrect.

SIDs are not only used for TE or traffic steering purposes but what is even
more interesting for various functions - for example NFV.

So you need as much SIDs as possible imagination of your value add network
functions - which will be different from those functions at the encap dst
which as you indicate in other draft can be carried in destination options.

That debate is still I think open.

Thx,
R.

On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica <[email-masked]> wrote:

> Gyan,
>
>
>
> Let’s think about how a network operator might choose a SID size….
>
>
>
> Assume that an MAN includes 100 routers. These routers are connected to
> one another by infrastructure links. Each router has 20 or fewer
> infrastructure links.
>
>
>
> The network operator might assign one loosely routes SID to each router.
> These loosely routed SIDs have network-wide significance (i.e., the cannot
> be reused).
>
>
>
> The network operator might also assign one strictly routed SID to each
> link. The strictly routed SIDs have node-local significance only. They can
> be reused from one node to another.
>
>
>
> So, in this case, the network operator only needs 120 SIDs. This fits in
> eight bits with plenty of room for growth.
>
>
>
> Now consider another network that includes 30,000 routers. Each router is
> connected to its peers by 200 infrastructure links or fewer.  This network
> would need 30,200 SIDs. This would fit in 16 bits.
>
>
>
> A **really big** network might require more than 32,000 SIDs. So, we
> support a 32-bit SID.
>
>
>
>
> Ron
>
>
>
>
>
>
>
>
>
> Juniper Internal
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Wednesday, April 17, 2019 10:00 PM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* Robert Raszuk <[email-masked]>; Tom Herbert <[email-masked]>;
> SPRING WG <[email-masked]>; [email-masked]; Dino Farinacci <
> [email-masked]>; [email-masked] list <[email-masked]>
> *Subject:* Re: [spring] IPv6-compressed-routing-header-crh
>
>
>
>
>
> I agree to make the SID align on word boundaries but I am thinking the
> software should have hardware independence if at all possible.
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_GYAN-2DMISHRA-2DRS-2DSP-2DMPLS-2DIPV6-2DEXPERT&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=7oInX5oGRmd36ozKW9gDLBfD4hBl0G89as-W-cNq90s&s=OVr9Tne6BBif0Ns2o9wbCzeNT3f1qK4Yq0tED0Ba6F8&e=>
>
> Mobile – 202-734-1000
>
>
>
> Sent from my iPhone
>
>
> On Apr 14, 2019, at 7:54 PM, Ron Bonica <
> rbonica=[email-masked]> wrote:
>
> Hi Robert,
>
>
>
>    - Support only a small handful of SID lengths
>    - If at all possible, make them align on word boundaries
>
>
>
> Currently, we support 8, 16 and 32 bytes. Do you see a reason why we
> should support a length greater than 32? Is there some length less than 32
> that would be beneficial?
>
>
>
>                                                      Ron
>
>
>
>
>
>
>
> Juniper Internal
>
> *From:* spring <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* Friday, April 12, 2019 6:13 PM
> *To:* Tom Herbert <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>; [email-masked]; Mark Smith <
> [email-masked]>; Dino Farinacci <[email-masked]>;
> [email-masked] list <[email-masked]>
> *Subject:* Re: [spring] IPv6-compressed-routing-header-crh
>
>
>
> Hi Tom,
>
>
>
> *"**PS. But if you choose to go ahead with CRH I would highly advise to
> make your CRH SID a variable length. "*
>
>
>
> and a 32 bit alignment,
> also create some opportunities to
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools..ietf.org_html_draft-2Dbonica-2D6man-2Dcomp-2Drtg-2Dhdr-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=GjqK8FoNrV07C15WLojvSxgX5EiIQWc_RaJ_gD9iJAI&s=Btt5PY_Iq3PKjxOHh5GSUQWMX0kPIYqZokMCtz2JA28&e=>
> >
> > Regards,
> > Mark.
> >
> >
> > > > ipv6@ietf....org <[email-masked]>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=GjqK8FoNrV07C15WLojvSxgX5EiIQWc_RaJ_gD9iJAI&s=ozK7wzssqc1x3UQrEGZppBNd64FlYwd3RvhzdvZu5Uw&e=>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=7oInX5oGRmd36ozKW9gDLBfD4hBl0G89as-W-cNq90s&s=DgsqbOLgIMGesxMPjVyRODst-R9NG4CWqnD02hIVOXc&e=>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 18 Apr 2019 20:29:43 +0000

Robert,

The Compressed Routing Header (CRH) has exactly one function. That is to route a packet for segment to segment along an SR path. Therefore, SIDs contained by the CRH have only one function. That is to steer packets to the next segment.

Granted, we may want to program a service behavior at a segment endpoint. IPv6 includes a Destination Options header that can be used to convey information segment endpoints and destination options can contain service SIDs. These service SIDs can be as long or short as they need to be. See draft-bonica-6man-vpn-dest-opt for an example.

                                                                              Ron

Juniper Internal
From: Robert Raszuk <[email-masked]>
Sent: Thursday, April 18, 2019 10:30 AM
To: Ron Bonica <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Tom Herbert <[email-masked]>; SPRING WG <[email-masked]>; [email-masked]; Dino Farinacci <[email-masked]>; [email-masked] list <[email-masked]>
Subject: Re: [spring] IPv6-compressed-routing-header-crh

Hi Ron,

SIDs are not only used for TE or traffic steering purposes but what is even more interesting for various functions - for example NFV.

So you need as much SIDs as possible imagination of your value add network functions - which will be different from those functions at the encap dst which as you indicate in other draft can be carried in destination options.

Thx,
R.

On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

                                                                            Ron

Juniper Internal
From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 17, 2019 10:00 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Tom Herbert <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] IPv6-compressed-routing-header-crh

Gyan S. Mishra

Sent from my iPhone

                                                     Ron

Juniper Internal

Hi Tom,

Thx,
R.

Mark,

Tom

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Apr 2019 22:56:09 +0200

Hi Ron,

> The Compressed Routing Header (CRH) has exactly one function. That is to
route a packet for
> segment to segment along an SR path. Therefore, SIDs contained by the CRH
have only one
> function. That is to steer packets to the next segment.

Indeed and that is precisely where the fundamental problem resides with
your proposal.

Let's take a look at RFC8402 - Segment Routing Architecture.

In body of the above RFC we clearly see definition of SID to be either a
topological instruction (your draft meets that requirement) or service
instruction (your draft fails to meet those requirements)

To illustrate along with just a basic example from RFC8402 of service
instruction - different per hop behavior treatment for traversing packets
to be embedded into SID.

So if you are only to associate SID with topological instructions you have
no way to express transit service instructions so it seems pretty obvious
that your proposal does not meet basic SR network programming requirements.

That means that all you can provide is subset of SR Architecture
requirements so perhaps to avoid industry confusion your solution should
avoid use of SID or SR references. Perhaps as Tom already also observed we
should call it MRH Mapped Routing Header instead.

Kind regards,
Robert.

On Thu, Apr 18, 2019 at 10:29 PM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> The Compressed Routing Header (CRH) has exactly one function. That is to
> route a packet for segment to segment along an SR path. Therefore, SIDs
> contained by the CRH have only one function. That is to steer packets to
> the next segment.
>
>
>
> Granted, we may want to program a service behavior at a segment endpoint.
> IPv6 includes a Destination Options header that can be used to convey
> information segment endpoints and destination options can contain service
> SIDs. These service SIDs can be as long or short as they need to be. See
> draft-bonica-6man-vpn-dest-opt for an example.
>
>
>
>
>                              Ron
>
>
>
>
>
> Juniper Internal
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Thursday, April 18, 2019 10:30 AM
> *Cc:* Gyan Mishra <[email-masked]>; Tom Herbert <
> [email-masked]>; SPRING WG <[email-masked]>; [email-masked]; Dino
> Farinacci <[email-masked]>; [email-masked] list <[email-masked]>
> SIDs are not only used for TE or traffic steering purposes but what is
> even more interesting for various functions - for example NFV.
>
>
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 18 Apr 2019 14:30:00 -0700

On Thu, Apr 18, 2019 at 1:56 PM Robert Raszuk <[email-masked]> wrote:
>
> Hi Ron,
>
> > The Compressed Routing Header (CRH) has exactly one function. That is to route a packet for
> > segment to segment along an SR path. Therefore, SIDs contained by the CRH have only one
> Indeed and that is precisely where the fundamental problem resides with your proposal.
>
> In body of the above RFC we clearly see definition of SID to be either a topological instruction (your draft meets that requirement) or service instruction (your draft fails to meet those requirements)
>
> To illustrate along with just a basic example from RFC8402 of service instruction - different per hop behavior treatment for traversing packets to be embedded into SID.
>
> So if you are only to associate SID with topological instructions you have no way to express transit service instructions so it seems pretty obvious that your proposal does not meet basic SR network programming requirements.
>
> That means that all you can provide is subset of SR Architecture requirements so perhaps to avoid industry confusion your solution should avoid use of SID or SR references. Perhaps as Tom already also observed we should call it MRH Mapped Routing Header instead.

Robert,

I think I was actually making the opposite argument. The routing
entries in CRH are not addresses and not in themselves topological,
they're values that need to be mapped at each hop. They require
interpretation in the context of a shared state and network wide
configuration, so effectively all CRH entries _are_ instructions. The
fact that entries in CRH are defined only to map to addresses seems to
be a deliberate design choice as opposed to a limitation in the
design. But, assuming that one did want to allow SIDs to represent
arbitrary instructions, I still don't understand why you'd need 128
bit numbers for that-- it seems like 32 or 16 bits would be enough.

Tom

>> > > > ipv6@ietf....org

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Apr 2019 23:42:24 +0200

Hi Tom,

> The fact that entries in CRH are defined only to map to addresses seems to
> be a deliberate design choice as opposed to a limitation in the design.

Yes this is true - any mapping can be used to express much more then
topological information. See LISP as example :)

My comment was not focused on the choice of solution based on mapping
(modulo embedded question do we really new one more mapping system), but to
the design choice made to *only* bind it to topological instructions. With
that I do think it no longer meets SR Architecture primitives.

Many thx,
Robert.

On Thu, Apr 18, 2019 at 11:30 PM Tom Herbert <[email-masked]> wrote:

> > So if you are only to associate SID with topological instructions you
> have no way to express transit service instructions so it seems pretty
> obvious that your proposal does not meet basic SR network programming
> requirements.
> >
> >> The Compressed Routing Header (CRH) has exactly one function. That is
> to route a packet for segment to segment along an SR path. Therefore, SIDs
> >> Granted, we may want to program a service behavior at a segment
> endpoint. IPv6 includes a Destination Options header that can be used to
> convey information segment endpoints and destination options can contain
> service SIDs. These service SIDs can be as long or short as they need to
> be. See draft-bonica-6man-vpn-dest-opt for an example.
> >>
> >>
> >>
> >>
>        Ron
> >>
>
>

---

From: James N Guichard <[email-masked]>
Date: Thu, 18 Apr 2019 21:57:15 +0000

Hi Ron,

I am wondering about how do you plan to handle service SIDs (or any SID with embedded functions) at intermediate nodes; draft-bonica-6man-vpn-dest-opt seems to only handle the case where the endpoint will process the destination option:

Section 4 says: "It MUST NOT appear in a Hop-by-hop Options header and SHOULD NOT appear in a Destination Options header that precedes a Routing header".

If you relax the latter and encode the SID in a destination option preceding the CRH (or SRH) then wouldn't every node in the segment-list have to process the SID and figure out whether it is a local SID or not? That would seem to be overly complex given you could just encode the SID in the CRH (or SRH) and only the node where said SID is exposed would process it.

Thanks!

Jim

From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, April 18, 2019 4:30 PM
To: Robert Raszuk <[email-masked]>
Cc: SPRING WG <[email-masked]>; [email-masked]; Dino Farinacci <[email-masked]>; [email-masked] list <[email-masked]>
Subject: RE: [spring] IPv6-compressed-routing-header-crh

Robert,

                                                                              Ron

Juniper Internal
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, April 18, 2019 10:30 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Tom Herbert <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] IPv6-compressed-routing-header-crh

Hi Ron,

Thx,
R.

A *really big* network might require more than 32,000 SIDs. So, we support a 32-bit SID..

                                                                            Ron

Juniper Internal

Gyan S. Mishra

Sent from my iPhone

                                                     Ron

Juniper Internal

Hi Tom,

Thx,
R.

Mark,

Tom

> > > ipv6@ietf.....org<mailto:[email-masked]>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 18 Apr 2019 15:04:26 -0700

> Yes this is true - any mapping can be used to express much more then topological information. See LISP as example :) 

With respect to the data-plane, the ELP (Explicit Locator Path, defined in RFC8060 and use-cases in draft-ietf-lisp-te) RLOC-record:

The L-bit, when set, means that Reencap Hop is routable by the underlay (an RLOC). When 0, a mapping system lookup can be performed to get the RLOC. Hence, doing what Tom commented on.

Note this format above is in the *control-plane* and each node along the segment-route(LOL)/reencapsulation path has the ELP stored apriori.

My demo of SR using the LISP mapping system, these ELP formatted records are used and registered in the mapping system. They are registered with L-bit set to 1 and the AFI=2 (an IPv6 RLOC).

But note, if you used this in the control-plane, there would be no packet overhead because the destination address used to find these ELP paths. The authors of SR already know this.

FYI,
Dino

---

From: Ron Bonica <[email-masked]>
Date: Fri, 19 Apr 2019 02:53:24 +0000

Hi Jim,

Thanks for asking this insightful question. The answer depends on the SID type.

Some service SIDs (e.g., END.DX4, END.DX6, END.DT4, END.DT6) are processed only in the following conditions:

  *   When there is no SRH
  *   When there is an SRH and Segments Left is equal to 0

Such SIDs should be encoded in the Destination Options header that immediately precedes the upper-layer header. This is because the Destination Options header that immediately precedes the upper-layer header is only processed when:

  *   When there is no SRH
  *   When there is an SRH and Segments Left is equal to 0

Moreover, Destination options are of variable length. So, each SID can be as long or short as it needs to be. One SID type can be long while another is short and neither needs to be the same length as SIDs that are encoded in the IPv6 Routing header.

The VPN Context Information Option [draft-bonica-6man-vpn-dest-opt] is an example of such an encoding. It serves the same purpose as many of the SID defined in draft-filsfils-spring-srv6-network-programming (e.g., END.DX4, END.DX6, END.DT4, END.DT6). As more service SIDs of this type are identified, more destination options will be defined.

Other Service SIDs can be processed when an SRH is present and Segments Left is greater than zero. Ideally, these SIDs should be encoded in the Destination Options Header that immediately precedes the Routing header. This is because the Destination Options Header that immediately precedes the Routing header is processed by every segment endpoint. Draft-bonica-6man-seg-end-opt offers one such encoding scheme, but it is not the only one.

Another possibility is to encode these SIDs the Destination Options header that immediately precedes the upper-layer header and required Service Function Instances that support these SIDs to look ahead.

                                                                                                                     Ron

Juniper Internal
From: James N Guichard <[email-masked]>
Sent: Thursday, April 18, 2019 5:57 PM
To: Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: SPRING WG <[email-masked]>; [email-masked]; Dino Farinacci <[email-masked]>; [email-masked] list <[email-masked]>; James N Guichard <[email-masked]>
Subject: RE: [spring] IPv6-compressed-routing-header-crh

Hi Ron,

Thanks!

Jim

From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, April 18, 2019 4:30 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] IPv6-compressed-routing-header-crh

Robert,

                                                                              Ron

Juniper Internal

Hi Ron,

Thx,
R.

A *really big* network might require more than 32,000 SIDs. So, we support a 32-bit SID...

                                                                            Ron

Juniper Internal

Gyan S. Mishra

Sent from my iPhone

                                                     Ron

Juniper Internal

Hi Tom,

Thx,
R.

Mark,

Tom

> > > ipv6@ietf......org<mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Apr 2019 09:30:56 +0200

And what happens -

   - When there is an SRH and Segments Left is *not* equal to 0 ?

On Fri, Apr 19, 2019 at 4:53 AM Ron Bonica <[email-masked]> wrote:

>    - When there is no SRH
>    - When there is an SRH and Segments Left is equal to 0
>
>
>
> Such SIDs should be encoded in the Destination Options header that
> immediately precedes the upper-layer header. This is because the
> Destination Options header that immediately precedes the upper-layer header
> is only processed when:
>
>
>
>    - When there is no SRH
>    - When there is an SRH and Segments Left is equal to 0
>
>
>
> Moreover, Destination options are of variable length. So, each SID can be
> as long or short as it needs to be. One SID type can be long while another
> is short and neither needs to be the same length as SIDs that are encoded
> in the IPv6 Routing header.
>
>
>
> The VPN Context Information Option [draft-bonica-6man-vpn-dest-opt] is an
> example of such an encoding. It serves the same purpose as many of the SID
> defined in draft-filsfils-spring-srv6-network-programming (e.g., END.DX4,
> END.DX6, END.DT4, END.DT6). As more service SIDs of this type are
> identified, more destination options will be defined.
>
>
>
> Other Service SIDs can be processed when an SRH is present and Segments
> Left is greater than zero. Ideally, these SIDs should be encoded in the
> Destination Options Header that immediately precedes the Routing header.
> This is because the Destination Options Header that immediately precedes
> the Routing header is processed by every segment endpoint.
> Draft-bonica-6man-seg-end-opt offers one such encoding scheme, but it is
> not the only one.
>
>
>
> Another possibility is to encode these SIDs the Destination Options header
> that immediately precedes the upper-layer header and required Service
> Function Instances that support these SIDs to look ahead.
>
>
>
>
>
>
> Ron
>
>
>
>
>
>
>
> Juniper Internal
>
> *From:* James N Guichard <[email-masked]>
> *Sent:* Thursday, April 18, 2019 5:57 PM
> *To:* Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>; [email-masked]; Dino Farinacci <
> [email-masked]>; [email-masked] list <[email-masked]>; James N
> Guichard <[email-masked]>
> *Subject:* RE: [spring] IPv6-compressed-routing-header-crh
>
>
>
> Hi Ron,
>
>
>
> I am wondering about how do you plan to handle service SIDs (or any SID
> with embedded functions) at intermediate nodes;
> draft-bonica-6man-vpn-dest-opt seems to only handle the case where the
> endpoint will process the destination option:
>
>
>
> Section 4 says: “It MUST NOT appear in a Hop-by-hop Options header and
> SHOULD NOT appear in a Destination Options header that precedes a Routing
> header”.
>
>
>
> If you relax the latter and encode the SID in a destination option
> preceding the CRH (or SRH) then wouldn’t every node in the segment-list
> have to process the SID and figure out whether it is a local SID or not?
> That would seem to be overly complex given you could just encode the SID in
> the CRH (or SRH) and only the node where said SID is exposed would process
> it.
>
>
>
> Thanks!
>
>
>
> Jim
>
>
>
> *From:* ipv6 [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Ron Bonica
> *Sent:* Thursday, April 18, 2019 4:30 PM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>; [email-masked]; Dino Farinacci <
> *Subject:* RE: [spring] IPv6-compressed-routing-header-crh
>
>
>
> Robert,
>
>
>
> support a 32-bit SID...
> > > > ipv6@ietf......org <[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Apr 2019 12:43:41 +0200

Specifically how do you associate different service functions encoded in
Dest. Options with specific segments for selective execution ?

Hint: Execution of all encoded and carried from src or edge of the network
service instructions in destinations options  at each SR node is not an
option. Do you now duplicate each SID into Dest Options  to be able to
choose which service is executed in which of the entire path's mid point ?

Many thx,
Robert.

On Fri, Apr 19, 2019 at 9:30 AM Robert Raszuk <[email-masked]> wrote:

>> Some service SIDs (e.g., END.DX4, END.DX6, END.DT4, END.DT6) are
>> processed only in the following conditions:
>>
>>
>>
>>    - When there is no SRH
>> Another possibility is to encode these SIDs the Destination Options
>> header that immediately precedes the upper-layer header and required
>> Service Function Instances that support these SIDs to look ahead.
>>
>>
>>
>>
>>
>>
>> Ron
>>
>>
>>
>>
>>
>>
>>
>> Juniper Internal
>>
>> So you need as much SIDs as possible imagination of your value add
>> network functions - which will be different from those functions at the
>> encap dst which as you indicate in other draft can be carried in
>> destination options.
>>
>>
>>
>> > > > It will be perfectly fine to have full proper SRv6 with SRH and
>> LISP or Vector Routing as an alternative options. I really do not see a
>> room or need for yet one more mapping plane. What problem does it solve
>> which would not be already solved elsewhere ?
>> > > >
>> > > > Kind regards,
>> > > > Robert
>> > > >
>> > > >

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 19 Apr 2019 17:53:53 -0700

Hi Tom,
in draft-mirsky-6man-unified-id-sr
<https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-02> we've
proposed the use of 20 and 32 bits-long SIDs in SR EH. Two bits-long field
also defined in the Flags to identify the length of SID element in the SR
EH:
      0b00 - 128-bits SID;
      0b01 - 20-bits SID;
      0b10 - 32-bits SID
      0b11 - reserved for future use.

Much appreciate your comments on that draft, suggestions.

Regards,
Greg

On Fri, Apr 12, 2019 at 3:09 PM Tom Herbert <[email-masked]> wrote:

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

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 20 Apr 2019 01:11:51 -0400

Makes sense.

Thank you

Gyan

Sent from my iPhone

> On Apr 19, 2019, at 3:30 AM, Robert Raszuk <[email-masked]> wrote:
> 
> 
> And what happens - 
> 
> When there is an SRH and Segments Left is not equal to 0 ? 
> 
> 
>> When there is no SRH
>> When there is an SRH and Segments Left is equal to 0
>>  
>> 
>> When there is no SRH
>> When there is an SRH and Segments Left is equal to 0
>>  
>> 
>> Section 4 says: “It MUST NOT appear in a Hop-by-hop Options header and SHOULD NOT appear in a Destination Options header that precedes a Routing header”.
>> 
>>  
>> 
>> If you relax the latter and encode the SID in a destination option preceding the CRH (or SRH) then wouldn’t every node in the segment-list have to process the SID and figure out whether it is a local SID or not? That would seem to be overly complex given you could just encode the SID in the CRH (or SRH) and only the node where said SID is exposed would process it.
>> 
>>  
>> 
>> Thanks!
>> 
>>  
>> 
>> Jim
>> 
>>  
>> 
>> The network operator might also assign one strictly routed SID to each link.. The strictly routed SIDs have node-local significance only. They can be reused from one node to another.
>> 
>>  
>> 
>> > > > ipv6@ietf.......org

---

From: Tom Herbert <[email-masked]>
Date: Sat, 20 Apr 2019 12:50:27 -0700

>       0b11 - reserved for future use.

Hi Greg,

20 bit fields in a list seems a little odd; how is this packed in a packet?
It's more typical to have byte alignment at least and if the fields hold
numerical values they would usually be bytes, words, double words, etc.
with natural alignment maintained. In a two bit representation of length, I
think best possibilities are 16, 32, 64, and 128 bits.

Tom

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 21 Apr 2019 12:45:36 -0700

Hi Tom,
thank you for your feedback and the suggestion. In proposing the use of 20
bits-long SID we've followed the existing IGP-SR extensions. Both
draft-ietf-ospf-segment-routing-extensions
and draft-ietf-isis-segment-routing-extensions advertisement of 4
octets-long SIDs as well as 20 bits-long (the latter as 20 rightmost bits
in 3 octets-long field). Though the proposal to using 20 bits-long SIDs in
IPv6 SR EH may be considered as duplication of
the draft-ietf-mpls-sr-over-ip, SR EH has very useful property, for example
in OAM, of preserving the SR path.
I think that we can expand the length of the field in SR EH to support 16
and 64 bits-long SIDs in addition to ones being proposed in the draft.
Much appreciate your comments.

Regards,
Greg

On Sat, Apr 20, 2019 at 12:50 PM Tom Herbert <[email-masked]> wrote:

> 20 bit fields in a list seems a little odd; how is this packed in a
> packet? It's more typical to have byte alignment at least and if the fields
> hold numerical values they would usually be bytes, words, double words,
> etc. with natural alignment maintained. In a two bit representation of
> length, I think best possibilities are 16, 32, 64, and 128 bits.
>
> Tom
>
>
>>> > > > > leverage IPv4 support in existing protocols to suite carrying
>>> and processing 32 bit SIDs with some, possibly
>>> > > > Furthermore as we see in companion documents all additional
>>> network functionality is being taken away from SRH and is being shifted to
>>> Destination Options .
>>> > > >
>>> > > > Since you correctly observed that now SID can be 32 bit and that
>>> is similar to the size of IPv4 my fundamental question is why not use
>>> > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet
>>> boundary and a 32 bit alignment, I'd think 32 bit SIDs would be adequate to
>>> perform SR in an IPv6 network.
>>> > > >>
>>> > > > Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6
>>> > > >