Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt

[Tom Herbert <[e-mail]>]

On Thu, Nov 30, 2017 at 4:15 PM, Brian E Carpenter
<[e-mail]> wrote:
> On 01/12/2017 10:27, Mark Smith wrote:
>> On 1 Dec. 2017 6:35 am, "Robert Raszuk" <[e-mail]> wrote:
>>
>> Hi Fernando,
>>
>> So in the case of encapsulation you normally put the node performing the
>> encap as source address. That may impact how you handle this packet via
>> number of services or even by src-dst routing correct ?
>>
>> So while perhaps some may consider it "cleaner" I think both variants have
>> their own use cases and should be supported.
>>
>>
>>
>> The trouble is they're not explained at all.
>>
>> All there is is an assertion that "operators want this", which is the
>> logical fallacy of an appeal to authority.
>>
>>  I'm an operator, and I don't want it. I think it'll be harder to
>> troubleshoot than NAT over the Internet and NAT is bad enough.
>
> What I'm seeing in this thread are rational arguments for and against
> the proposal. I agree about the logical fallacy in the abstract of the
> current draft, but that's fixable with a few seconds use of the cursor
> and Delete key. I'd like to see the rational arguments in the next version
> of the draft.
>
It's not just the abstact that promote the logical fallacy, it occurs
elsewhere in the draft. For instance:

"Obviously, this FRR service increases the size of the packet during
its journey within domain D.  This is well-known to operators.
Well-known mitigation techniques have been deployed for more than 15
years"

This seems like a pretty useless statement in a protocol
specification. Either the mitigations should be articulated here or
the applicable RFCs describing them should be referenced.

Tom

>    Brian
>
>>
>>
>> Thx,
>> R.
>>
>> On Thu, Nov 30, 2017 at 2:14 PM, Fernando Gont <[e-mail]>
>> wrote:
>>
>>> On 11/30/2017 08:45 PM, Ole Troan wrote:
>>>>>
>>>>> IMO, #1 thing to be discussed is why normal encapsulation wouldn't work
>>>>> -- this is the standard, straightforward and most clean approach.
>>>>
>>>> The best example I've heard is when you don't have a natural tunnel
>>> endpoint to encapsulate to.
>>>
>>> What's a natural tunnel-endpoint here? Aren't you expecting such
>>> endpoint to exist, to remove the inserted EH, after all? (and listing it
>>> in the RH)
>>>
>>> I seem to remember some folks arguing that the rationale for EH
>>> insertion is that performance go to hell if they do proper encapsulation...
>>>
>>> --
>>> Fernando Gont
>>> SI6 Networks
>>> e-mail: [e-mail]
>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>>
>>>
>>>
>>>
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------