Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Brian E Carpenter <[e-mail]>]

Stewart,

On 10/02/2017 04:19, Stewart Bryant wrote:
...
> I wonder if we would best serve both our future and our heritage
> if we declared RFC1981 as historic, and either left the idea there,
> or declared it as historic and wrote a new text from a clean start?

I don't see that. It's a stable, widely deployed, interoperable
mechanism. That is rather orthogonal to the issue that has been raised,
which is that faulty ICMPv6 filtering blocks it on many, many paths
across the Internet.

...
> It is concerning that the draft does not talk in any detail about
> how modern ECMP works, i.e. using the five tuple, and noting that
> the PMTU may be different depending on the transport layer port
> numbers.

Has this problem been analysed for, say, IPv4? And does the real world
contain ECMP setups with different MTUs on different paths?

> Given that a very large fraction of packets will traverse an MPLS
> network at some point, I am surprised that there is no text talking
> about the importance of providing support for this feature in the 
> MPLS domain. RFC3988 talks to this point, but is only experimental.

I don't understand. How does the fact that there might be some MPLS
segments along the path affect end-to-end PMTUD?

> 
> ======
> 
>    If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation
>    could use the flow id as the local representation of a path. Packets
>    sent to a particular destination but belonging to different flows may
>    use different paths, with the choice of path depending on the flow
>    id.  This approach will result in the use of optimally sized packets
>    on a per-flow basis, providing finer granularity than PMTU values
>    maintained on a per-destination basis.
> 
> SB> How widely is flow-id supported in networks? I thought that the 
> SB> current position was that it was unreliable as an ECMP indicator
> SB> and thus routers tended to glean information from the packet themselves.

This is future-proofing. Agreed, usage today is limited.

(But it would be better to call it the Flow Label for consistency with other
recent RFCs.)

I think your other comments are all valuable.

Regards
    Brian