Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem-03: AD review

Thanks Joel,

Sending this to IETF LC.

Regards, Benoit
> On 8/5/15 4:56 PM, Benoit Claise wrote:
>> Dear all,
>>
>> Joel, being a document author, asked me to look into this draft
>> Here is my feedback. I don't have any background on this draft. So a
>> fresh pair of eyes.
>>
>> 1. It took me a little bit of time to grasp the problem behind this draft.
>>  From the abstract, I(wrongly) assumed a PTB packet sent from the server
>> back to the source.
> yup it's the one from the client. let me see if we can tweak this slightly.
>
>> It's only in section 2 that I found my answer (well, the second time I
>> read it)
>>
>>    An ICMPv6 type 2 PTB message generated
>>     on an intermediate device _for a packet sent from a server_
>>
>> And the figure 1 was not too helpful, as, obviously I was wondering
>> about the ptb direction...
> figure 1 contains
>
>    ptb -> router ecmp -> nexthop L4/L7 load balancer -> destination
>
> the limitations of ascii art may be a limitation here, but it's not
> really a state flow since it could be emitted by any device in the path.
> at any time. but I think if we address item 1 the problem of
> directionality is no doubt clear.
>
>> What would have made it crystal-clear is a figure 1 such as:
>>
>>     Topology
>>
>>     client -...-- router -- load balancer 1 --- server 1
>>                        \\-- load balancer 2 --- server 2
>>                         \-- load balancer N --- server N
>>
>>
>>      Sequence 1: packet from source to server
>>          client -> ... -> router ecmp -> nexthop L4/L7 load balancer  ->
>> server (*)
>>     
>>      Sequence 2: reply from server to source
>>                       .... <- router ecmp <- nexthop L4/L7 load balancer
>> <- server (*)
>>
>>      Sequence 3: ptb sent back to the server
>>                      ptb -> router ecmp -> nexthop L4/L7 load balancer ->
>> server (**)
>>
>>      Note: As (*) and (**) are unlikely the same instance, so the ptb
>> could be mis-delivered
>>
>>
>> 2.
>> Confused about the order
>>
>>   3
>> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#section-3>.  Mitigation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
>> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#page-4>
>>       3.1
>> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#section-3.1>.  Alternatives  . . . . . . . . . . . . . . . . . . . . . .   5
>> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#page-5>
> 3.1 can be changed to Alternative mitigations
>
> it's important that clamping the mss doesn't get lost in all if this
> because both the ietf considers that minimum best effort (everything has
> to carry 1280 right) and because people do it.
>
>>       3.2
>> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#section-3.2>.  Implementation  . . . . . . . . . . . . . . . . . . . . .   5
>> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#page-5>
>>         3.2.1
>> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#section-3.2.1>.  Alternatives  . . . . . . . . . . . . . . . . . . . .   6
>> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#page-6>
>>
>>   3.2 is the implementation of what? The intro in section 3?
> 3.2 yes is an example mitigiation based  on 3 paragraph 2
>
>> So why do you insert alternatives 3.1 (which you don't recommend) in
>> between?
>> And 3.2.1 is the alternative to what? the implementation in section 3.2
> 3.2.1 yes. the point being there's more than one way to solve the
> problem. operationally one approach may be more desirable the the other,
> in point of fact when I asked the cloudflare guys came up with their's
> so I added it.
>
>
>> 3.
>>
>>      1. Filter-based-forwarding matches next-header ICMPv6 type-2 and
>>         matches a next-hop on a particular subnet directly attached to
>>         both border routers.  The filter is policed to reasonable limits
>>         (we chose 1000pps, more conservative rates might be required in
>>         other implementations).
>>
>> border router? make it consistent with the terminology in figure 1
> ok routers
>
>>     2.  Filter is applied on input side of all external interfaces
>>
>> Make it clear that you speak about router in figure 1
> external routers
>
>>     4.  Anycast servers receive the PTB error and process packet as
>>         needed.
>>
>> "anycast server" make it consistent with the terminology is figure 1
> figure 1 is bounded by width limitations for ascii art otherwise the
> label would be longer, the fact that it is naycast is brought up in
> section 2. we can probably arrange to us server more freely in the text
> prior to this.
>
>> 4.
>> Section 3.2.1
>> "ECMP hop could distribute the proxy onto the end systems"
>     Alternatively, network designs in which a common layer 2 network
>     exists on the ECMP hop could distribute the proxy onto the end
>     systems, eliminating the need for policy routing.
>
> Proxy in this case refers to the mitigiation proposed in section 3
> paragraph 2 of which this is a sub section.
>
> The excerpt is missing a preposition ( exists on the ECMP hop)  and I
> agree it's hard to parse without that.
>
>> Not sure what it means.
>>
>>   5.
>> section 4. Improvements to what? The implementation or the potential specification.
> These are improvements on the mitigation. they are not specification
> changes rfc 4821 already exists it's just not widely (at all afaik) used.
>
>> I guess the "specification", but then, how is this different that the mitigation section?
>> Your improvement point 1 is the same as the "mitigation" section paragraph 1
> Right but no asic or at least microcode exists today can actually do that.
>
>> Your improvement point 2 is the same as the "mitigation" section paragraph 2
> no it isn't. in the mitigitation it was necessary to build a proxy to
> flood them by  rewritting the L2 nexthop.  that's rather different than
> getting router to forward a unicast packet to say 16 destinations if
> somebody gives me a knob for the latter then all this proxy junk is done.
>
>> nits:
>> implmentation -> implementation
>>
>> Regards, Benoit
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>