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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]>
> *Sent:* Thursday, April 18, 2019 5:57 PM
> *To:* Ron Bonica <[e-mail]>; Robert Raszuk <[e-mail]>
> *Cc:* SPRING WG <[e-mail]>; [e-mail]; Dino Farinacci <
> [e-mail]>; [e-mail] list <[e-mail]>; James N
> Guichard <[e-mail]>
> *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:[e-mail] <[e-mail]>] *On
> Behalf Of *Ron Bonica
> *Sent:* Thursday, April 18, 2019 4:30 PM
> *To:* Robert Raszuk <[e-mail]>
> *Cc:* SPRING WG <[e-mail]>; [e-mail]; Dino Farinacci <
> [e-mail]>; [e-mail] list <[e-mail]>
> *Subject:* RE: [spring] IPv6-compressed-routing-header-crh
>
>
>
> 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 <[e-mail]>
> *Sent:* Thursday, April 18, 2019 10:30 AM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* Gyan Mishra <[e-mail]>; Tom Herbert <
> [e-mail]>; SPRING WG <[e-mail]>; [e-mail]; Dino
> Farinacci <[e-mail]>; [e-mail] list <[e-mail]>
> *Subject:* Re: [spring] IPv6-compressed-routing-header-crh
>
>
>
> 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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Wednesday, April 17, 2019 10:00 PM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* Robert Raszuk <[e-mail]>; Tom Herbert <[e-mail]>;
> SPRING WG <[e-mail]>; [e-mail]; Dino Farinacci <
> [e-mail]>; [e-mail] list <[e-mail]>
> *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.
>
>
>
> 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
> <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=[e-mail]> wrote:
>
> 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 <[e-mail]> *On Behalf Of *Robert Raszuk
> *Sent:* Friday, April 12, 2019 6:13 PM
> *To:* Tom Herbert <[e-mail]>
> *Cc:* SPRING WG <[e-mail]>; [e-mail]; Mark Smith <
> [e-mail]>; Dino Farinacci <[e-mail]>;
> [e-mail] list <[e-mail]>
> *Subject:* Re: [spring] IPv6-compressed-routing-header-crh
>
>
>
> 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 <[e-mail]> wrote:
>
> On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <[e-mail]> wrote:
> >
> > Hi Tom,
> >
> > On Sat, 13 Apr 2019 at 00:26, Tom Herbert <[e-mail]> wrote:
> > >
> > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <[e-mail]>
> 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.
> > > >
> > > > 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,
> > >
> > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you
> > > 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.
> >
> 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
>
> > "The IPv6 Compressed Routing Header (CRH)"
> > 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.
> >
> >
> > > 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
> > >
> > > > 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.
> > > >
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > ipv6@ietf......org <[e-mail]>
> > > > 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=>
> > > > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> 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=>
> --------------------------------------------------------------------
>
>