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

From: Benoit Claise <[email-masked]>
Date: Thu, 6 Aug 2015 01:56:39 +0200

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.
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...

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.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?
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.

     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

    2.  Filter is applied on input side of all external interfaces

Make it clear that you speak about router in figure 1

    4.  Anycast servers receive the PTB error and process packet as
        needed.

"anycast server" make it consistent with the terminology is figure 1

4.
Section 3.2.1
"ECMP hop could distribute the proxy onto the end systems"
Not sure what it means.

  5.
section 4. Improvements to what? The implementation or the potential specification.
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
Your improvement point 2 is the same as the "mitigation" section paragraph 2

nits:
implmentation -> implementation

Regards, Benoit

---

From: joel jaeggli <[email-masked]>
Date: Thu, 6 Aug 2015 08:53:05 -0700

> From the abstract, I(wrongly) assumed a PTB packet sent from the server

yup it's the one from the client. let me see if we can tweak this slightly.

>    on an intermediate device _for a packet sent from a server_
> 

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.

>                      .... <- router ecmp <- nexthop L4/L7 load balancer 
> <- server (*)
> 
>                     ptb -> router ecmp -> nexthop L4/L7 load balancer ->
> server (**)
> 
> <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#section-3.1>.  Alternatives  . . . . . . . . . . . . . . . . . . . . . .   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#section-3.2.1>.  Alternatives  . . . . . . . . . . . . . . . . . . . .   6

3.2 yes is an example mitigiation based  on 3 paragraph 2

> 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.

> border router? make it consistent with the terminology in figure 1

ok routers

> Make it clear that you speak about router in figure 1

external routers

> "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.

> "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.

> 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.

> 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.

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>