Subject: draft-li-6man-ipv6-sfc-ifit-00, and the general problem it raises

From: Brian E Carpenter <[email-masked]>
Date: Sun, 7 Apr 2019 15:09:45 +1200

Hi,

I apologise if some of these comments have been made already as I
missed some discussion last week.

> 1.  According to the encapsulation order recommended in [RFC8200], if
>    the IOAM is encapsulated in the IPv6 Hop-by-Hop options header, in
>    the trace mode of IOAM as the number of nodes traversed by the IPv6
>    packets increases, the recorded IOAM information will increase
>    accordingly.  This will increase the length of the Hop-by-Hop options
>    header...

While a hop-by-hop option value may be changed, the byte count cannot change.
That is not allowed by RFC4302 (page 26), since the option data length is
included in the ICV calculation. It's also not OK because of the implications
for PMTUD. (I haven't read the IAOM draft and thread, so I'm again sorry if this
is a repeat.)

>    ...and cause increasing difficulties in reading the following
>    Segment Routing Extension Header (SRH)
>    [I-D.ietf-6man-segment-routing-header] and thereby reduce the
>    forwarding performance of the data plane greatly.

Why? If the router can follow linked lists, it doesn't matter if
the intervening header is longer. If the router can't follow linked
lists, it can never handle extension headers of any kind.

Pretty much everything discussed in this draft needs each router to
include a network processor to link through header chains etc.
FPGAs and ASICs won't be much use.
 
>    4.  There is unnecessary inconsistency in the current encapsulations
>    for IOAM, IFA and PBT in the IPv6 scenario.  Especially it seems
>    unnecessary to define a new specific IPv6 header for IFA, i.e. IFA
>    header.
> 
>    5.  [I-D.guichard-spring-nsh-sr] is proposed for the solution to
>    encapsulate NSH in SRv6 to support SFC.  But the encapsulation is not
>    defined yet.

Indeed, we are in the process of creating a big mess and I think 6man
needs to take this problem very seriously. From nobody taking much notice
of IPv6 extensibility, we now have lots of people hacking on the topic
and this needs coordination and consensus.

I won't comment on your specific proposals, because I think the most
urgent job is to get consensus on the problem area and how to tackle it.
 
Regards
   Brian Carpenter

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 8 Apr 2019 12:40:09 +0000

Hi,

> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: Sonntag, 7. April 2019 05:10
> To: 6man <[email-masked]>; [email-masked]
> Subject: draft-li-6man-ipv6-sfc-ifit-00, and the general problem it raises
> 
> Hi,
> 
> I apologise if some of these comments have been made already as I missed
> some discussion last week.
> 
> included in the ICV calculation. It's also not OK because of the implications for
> PMTUD. (I haven't read the IAOM draft and thread, so I'm again sorry if this is a
> repeat.)
> 
> Why? If the router can follow linked lists, it doesn't matter if the intervening
> header is longer. If the router can't follow linked lists, it can never handle
> extension headers of any kind.
> 
> Pretty much everything discussed in this draft needs each router to include a
> network processor to link through header chains etc.
> Indeed, we are in the process of creating a big mess and I think 6man needs to
> take this problem very seriously. From nobody taking much notice of IPv6
> extensibility, we now have lots of people hacking on the topic and this needs
> coordination and consensus.
> 
> I won't comment on your specific proposals, because I think the most urgent job
> is to get consensus on the problem area and how to tackle it.

Agreed - and while EH are a 20-year old thing, one key reason for recent interest and the growing amount of proposals seems to be the fact that modern chips are starting to be able to parse and process EH properly with performance. The difference in capabilities of chipsets across different vendors seems, along with the different target deployment domains, seems to be among the reasons why this thread was started. 

And expanding what Mark and others said on the other thread ("draft-ioametal-ippm-6man-ioam-ipv6-options and RFC4302"):  New solutions should leverage existing definitions (read: protocol extensibility via EH) and best practices as much as they can, so that we don't fall into the trap of waiting another 20 years for adoption. Let's refrain from inventing a new IP protocol whenever we spot a new requirement, but instead try hard to leverage existing definitions as much as we can.

Cheers, Frank

> 
> Regards
>    Brian Carpenter
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------