Subject: Comments on draft-bonica-6man-seg-end-opt-01

From: Tom Herbert <[email-masked]>
Date: Wed, 6 Mar 2019 13:34:07 -0800

>From the draft: "Finally, decrement the Segment ID field and process
the next option or header"

Is this supposed to decrement the Segments Left field?

The new option looks really complicated to me. Maintaining a separate
segments left seems redundant to segments left in the routing header.
Introducing containers of options looks quite scary. Also, I don't
think this would easily allow more than one segment process the same
option.

As alternative, I suggest to create a destination option that just
contains a bit map. The meaning of the option is that any options
follow are only processed by segments that are represented in the bit
map. Specifically, at some intermediate destination the options are
processed if the bit corresponding to segments left in the routing
header is set in the bit map.

This scheme does require looking ahead into the routing header to
extract the segments left value. No doubt the protocol purists will
point out that this violates the RFC8200 requirement "extension
headers must be processed strictly in the order they appear". However
in this case, the protocol could be specified with tight constraints
so that the intent of the sender and the order of processing in
intermediate nodes is unambiguous and deterministic, such that the
requirements of RFC8200 are maintained (at least by the spirit of the
law).

Tom

---

From: Ron Bonica <[email-masked]>
Date: Wed, 6 Mar 2019 23:20:43 +0000

Tom,

I thought about exactly that alternative and assumed that the WG would reject it for exactly the reasons that you cite. But I may be wrong?

Could I ask a few other to voice their opinions? I am happy to go with either alternative.

                                                                                               Ron

> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of Tom Herbert
> Sent: Wednesday, March 6, 2019 4:34 PM
> To: 6man <[email-masked]>
> Subject: Comments on draft-bonica-6man-seg-end-opt-01
> 
> Introducing containers of options looks quite scary. Also, I don't think this
> would easily allow more than one segment process the same option.
> 
> As alternative, I suggest to create a destination option that just contains a bit
> map. The meaning of the option is that any options follow are only processed
> by segments that are represented in the bit map. Specifically, at some
> intermediate destination the options are processed if the bit corresponding to
> segments left in the routing header is set in the bit map.
> 
> This scheme does require looking ahead into the routing header to extract the
> segments left value. No doubt the protocol purists will point out that this
> violates the RFC8200 requirement "extension headers must be processed
> strictly in the order they appear". However in this case, the protocol could be
> specified with tight constraints so that the intent of the sender and the order
> of processing in intermediate nodes is unambiguous and deterministic, such
> that the requirements of RFC8200 are maintained (at least by the spirit of the
> law).
> 
> Tom
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwICAg&c=HAkYuh63rsuhr6Sc
> bfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=hrSjubwUobcW--
> L52d8hxZrlOhEhsfBLQ0h1m1HAHEI&s=ZxW3LihSgSAqz0MEuUty_2TOiHeb0-
> CREOrEsHubEOQ&e=
> --------------------------------------------------------------------