On 25-May-20 09:08, Tom Herbert wrote: > 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
That intention is not specified in the text, and IMHO cannot be deduced from the text. Hence my comment on draft-bonica-6man-ext-hdr-update. Brian > 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 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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
