On Sun, May 24, 2020 at 3:23 AM Robert Raszuk <rob...@raszuk.net> wrote: > > 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. > Robert,
Look at Destination Options before the routing header in RFC8200. These are intended to be processed at every intermediate destination in the routing header and precede any fragment header. Tom > 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 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
