Subject: [v6ops] draft-fioccola-v6ops-ipv6-alt-mark

From: Ron Bonica <[email-masked]>
Date: Mon, 24 Sep 2018 13:32:32 +0000

Folks,

Each week between now and IETF 103, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-fioccola-v6ops-ipv6-alt-mark.

                                                      Fred and Ron

---

From: Tom Herbert <[email-masked]>
Date: Mon, 24 Sep 2018 08:10:20 -0700

Comments on the draft:

>From the draft: "Using a new EH assumes that ALL routers in the domain
support this type of headers, which complicates backward compatibility
of the technology."

Hop-by-Hop Options extension header is not new! What I think this
means to say is that a new Hop-by-Hop option would be used. Such an
option could be marked as ignore on unknown option so that legacy
devices don't need to support the option. The "backward compatibility"
problem alluded might be that some intermediate nodes could drop
packets with HBH options. That is a problem of non-conforming
implementations not the protocol, however there are some emerging
mitigations to resolve that issue.

  - RFC8200 allows HBH extension header to be completely ignored
  - RFC6434bis allow implementations to apply reasonable limits to
options to process
  - The use case of this draft is a limited domain, not the open Internet
  - Adding proper support for HBH options (or ignoring them) is
trivial to implement in software stacks (Linux, VPP)
  - Adding support in programmable network devices (P4, eBPF) is straightforward

>From the draft: "There is an advantage of using destination addresses
(DA) to encode the alternate marking method."

I think this would suffer from the same problem that using the flow
label does. Packets within a flow may have different destination
addresses when they transit the domain because of the marking, this
makes routing through ECMP and other steering inconsistent so that out
of order packets result.

>From the draft: "The flow label is an immutable field  recommended to
contain a pseudo-random value, however, often it has the default value
of zero."

"often" is a relative term. I believe all major host OSes not set the
flow label to non-zero by default, so often is becoming "less often"
as end hosts are updated.

"[RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used
in a controlled environment"

I don't see how they're opening the door to allow bits in the flow
label to be repurposed. The intent of these RFCs was to clarify
requirements including the requirement that forwarding nodes can't
modify a non-zero flow label (except for security reasons).

"In addition it is possible to mention
[I-D.krishnan-6man-header-reserved-bits] that tried to set aside 4
bits from the flow label field for future expansion."

That draft is from 2010 so it's really ancient history :-). IMO, the
ship has already sailed on flow label. It's deployed and being used in
packet steering. Trying to steal bits from it for other purposes is
infeasible at this point.

Tom

On Mon, Sep 24, 2018 at 6:32 AM, Ron Bonica <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops