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

From: Benoit Claise <[email-masked]>
Date: Wed, 16 Sep 2015 11:08:34 +0200

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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>

---

From: joel jaeggli <[email-masked]>
Date: Wed, 16 Sep 2015 12:10:32 -0700

cool,

thanks
joel

On 9/16/15 2:08 AM, Benoit Claise wrote:
>>> 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.
>>> 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
>> 
>> 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.
>> 
>>> 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 
3.1
>>> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#
section-3.1>.
>>>  Alternatives  . . . . . . . . . . . . . . . . . . . . . .   5 
>> 
>> 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 
3.2.1
>>> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#
section-3.2.1>.
>>>  Alternatives  . . . . . . . . . . . . . . . . . . . .   6 
>>> 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).
>>> 
>>> 4.  Anycast servers receive the PTB error and process packet
>>> as needed.
>>> 
>> 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"
>> 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
>> 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 [email-masked]