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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/02/2017 23:20, Stewart Bryant wrote:
> 
> 
> On 10/02/2017 03:25, Brian E Carpenter wrote:
>> 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.
> 
> I will not debate whether it is faulty or not, but it seems that in 

It's faulty by the standard of RFC4890 (which is Informational).

> practice the
> Internet breaks the mechanism. However it breaks it is a way that seems
> disruptive to some user traffic. The document is really guidance
> one how hosts might use  ICMP for optimization, and arguable need
> not be a standard at all.

I think that's a mischaracterisation of the mechanism (and the draft).
PMTUD is not an optimisation. Without it, you get black holes.

> 
> My remark about heritage is that this vintage draft is very much a 
> product of
> its time, and really needs modernizing, and after modernizing ought to
> look quite different, and thus maybe we should employ a procedure
> other than a simple replacement.

It's proposed for Internet Standard. That means it must replace the
PS document and must specify the same thing, plus corrections, minus
unused features.

>> ...
>>> 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?
> 
> I don't know if anyone has looked. Since the mechanism is 
> self-correcting albeit
> with some disruption to user traffic it looks to the application and the 
> application
> user, just like the Internet not working for a few moments.
> 
> In a well managed SP network there should not be, but neither should there
> be asymmetric path costs, but there are. The less well manage private
> networks are less well managed.
> 
> 
>>
>>> 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?
> 
> The point that RFC3988 makes is that MPLS looks like a single hop to IP 
> and the
> PE has to fragment or has to reply with an ICMP error message to support
> PMTUD. MPLS has ICMP extensions, but I don't know if they integrate to 
> result
> in the right response at the end node.
> 
> My point is that the draft is silent on the subject, and perhaps it 
> should not be.

Well, in general it's silent on tunnels. They have to emulate links,
as stated in section 2. I still don't see why an MPLS tunnel is a special case.

> 
> However your question make me ask a further question. The draft is also 
> silent
> on NATs. Is there any advice needed for people designing and configuring 
> NATs?

Yes, for NAT64/NAT46 - in RFC6145. For NAT66, the advice is "don't".

>>
>>> ======
>>>
>>>     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.)
> 
> Well the question is whether it is simply limited today, or broken today 
> in a manner that
> is irrecoverable? 

Nothing's broken. It's just underused.

> I don't know, but I do know that the mainstream ECMP
> approach is the five-tuple.

Sure, but see RFC6438 for some of the difficulties that
causes with IPv6.

> There is something akin to the flow label being
> deployed in MPLS. However
> what distinguishes the MPLS Entropy Label is that it is inserted (and 
> removed) by the
> service provider and is therefore trusted by the service provider.

Exactly the same for ECMP tunnels, in RFC6438. Guess what, my co-author
was from a provider.

   Brian

>>
>> I think your other comments are all valuable.
> Thank you.
> 
> Stewart
> .
> 




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]