Hi Ron, I have one small question on the Destination Option Header you keep referencing to carry for example VPN demux instructions.
As DOH follows Fragment Header it is indeed inspected before CRH. So please kindly clarify what is there in the IPv6 packet header which would stop each segment endpoint (during the transit over SR anchors) which destination is obviously in DA of the arriving packet not to inspect DOH and not trying to execute it ? If you could please also provide reference to RFC8200 defining it. Keep in mind that in number of networks P routers are also PE routers so executing DOH even if CRH still contains many hops to go may result in very unexpected behaviours. I am sure you recall that L3VPN labels are locally significant and there is no mechanism in place to assure uniqueness of VPN demux values across PEs. Why is this important here - because CRH by design is decoupled from any functions or network application handling. Many thx, Robert. On Sun, May 24, 2020 at 3:24 AM Ron Bonica <rbonica= 40juniper....@dmarc.ietf.org> wrote: > Cheng, > > > > The CRH is a building block. It has exactly one function. That is, to > steer a packet along its delivery path. > > > > The CRH does not attempt to deliver parameters or metadata to service > function instances. It relies on other mechanisms. One possibility is a > destination options header that precedes the CRH. I am sure that there are > other mechanisms. CRH should be compatible with all of them. > > > > Personally, I am not an NSH expert. Maybe someone who is can speak up. > > > > > Ron >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
