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 protected]> wrote: > On Thu, Apr 18, 2019 at 1:56 PM Robert Raszuk <[email protected]> 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 <[email protected]> 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 > >> > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
