Re: [IPv6] Fwd: Updated review of draft-ietf-6man-eh-limits-08

[Tom Herbert <[e-mail]>]

On Fri, Nov 10, 2023, 1:33 AM Frank Brockners (fbrockne)
<fbrockne=[e-mail]> wrote:
>
> Hi Tom,
>
> Thanks for taking on the challenge - or call it fun journey - to tackle this topic.
>
> >
> > >
> > > We think that terms like limited domains will make this challenging to
> > > get through the IESG given it’s lack of clear IETF definition.  Note,
> > > we are not suggesting that it be defined here, better to remove it.
> > > The text about explicit knowledge should cover this.
> >
> > Note that limited domain is not referred to in any of the normative
> > requirements specified in the draft. We could reference RFC8799 if that
> > would help, or remove all instances of the term. Which would be better?
>
> Given that the definition of "limited domain" seems to distinguish whether "this draft applies to me or not" (whether I'm an equipment vendor and/or deployer of equipment), IMHO it is very important to be specific of what this "limited domain" is.
>

Frank,

Sorry for log response time, this was in my Drafts.

> Per your note, RFC8799 isn't a useful reference, given that it is not an IETF document.

It's useful as an informative reference.

>
> SRv6 defines a "segment routing domain" (RFC8402), IOAM defines an "IOAM domain" (RFC9486). Both RFCs don't define a "limited domain".

Right, there's no normative definition of "limited domain", but they
are limited domains in the sense that they are controlled domains and
not the open Internet.

>
>
> As such, would the definitions in the document apply to IOAM domains? Would they apply to SRv6 domains? The document seems to imply that the answer would be "no", by stating "For instance, the IOAM Hop-by-Hop option is intended for use in limited domains" in Section 2.2.
> I.e., if I'm an equipment vendor that builds equipment for data center and enterprise networks that might deploy IOAM, this draft isn't for me. Similarly, if I'm a service provider that deploys an SRv6 backbone, this draft isn't for me either.

The draft is specific here. "If it is known that all communicating
parties for a particular communication, including destination hosts
and any routers in the path, are capable of supporting more than the
baseline then these default limits may be freely exceeded." and
requirements for limits for sending hosts has a normative exception to
that effect, for instance "A source host SHOULD NOT send a packet with
an IPv6 header chain larger than 104 bytes unless it has explicit
knowledge that all possible routers, intermediate nodes, and the
destination host in the path are able to process a larger IPv6 header
chain." So if a host is sending IOAM or SR to a destination within the
respective domain then the limits can be exceeded because all the
paths are well known and intended to support the EH. But, if the
destination is outside of the IOAM domain or SR domain then the limits
would be applicable since part of the path traverses networks that may
or may not have sufficient support. Without additional information, a
host doesn't know what the capabilities of a path are so the default
limits would apply.

Also, you may want to look at draft-herbert-eh-inflight-removal, this
would allow hosts to exceed the limits assuming extension headers are
removed if a packet egresses the network. For instance, this would be
useful to use segment routing to route a packet to an egress router
into the open Internet. While the packet is in the SR domain, SR EH is
productively used, and at the egress HBH SR is removed since it
contains information not useful to the outside world and forwarding
the packet without HBH increases probability of successful delivery.

>
>
> What I'd personally appreciate is a definition where the draft applies, rather than try to specify where is does not apply.

The limits are the defaults on a sending host. The defaults don't
apply "If it is known that all communicating parties for a particular
communication, including destination hosts and any routers in the
path, are capable of supporting more than the baseline then these
default limits may be freely exceeded.". In practice, these are only
guidelines for the sending application that we likely wouldn't enforce
in the (Linux) stack. If someone configures IOAM or SR for some routes
then we assume that they are sending into an IOAM or SR domain and not
into the Internet and they understand the ramifications if those
packets leak out of the domain.

Tom


>
>
> Cheers, Frank
>
>
>