On Sun, May 24, 2020 at 2:51 PM Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > 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,
I think it can be deduced. Extension headers need to be processed in order, so destination options before the routing header must be processed before the routing header. If the destination options before the routing were only to be processed at the final destination, then we would need to process the routing header before processing the destination options in order to determine if the destination address is indeed the final destination. More practically, if destination options were only to be processed at the final destination then it doesn't seem like there would be any material between destination options before and those after the routing header (or maybe there was some other intent to have two flavors of destination options?).. I agree that the text could be clarified, It seems like another case of potential ambiguity in RFC8200 among the terms destination, destination address, final destination, an intermediate destination. https://tools.ietf.org/html/draft-herbert-ipv6-update-dest-ops-00 was an attempt to calirfy this, at least to clarify the significance of a modifiable destination option (before the routing header). Tom > 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
