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

[Robert Raszuk <[e-mail]>]

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

> On Thu, Apr 18, 2019 at 1:56 PM Robert Raszuk <[e-mail]> 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
> > > 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.
>
> 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
>
> >
> > Kind regards,
> > Robert.
> >
> > On Thu, Apr 18, 2019 at 10:29 PM Ron Bonica <[e-mail]> 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
> >>
>
>