Re: [Gen-art] Gen-ART Telechat review of draft-ietf-v6ops-pmtud-ecmp-problem-04

[Benoit Claise <[e-mail]>]

Thanks Paul.

Regards, B.
> I am the assigned Gen-ART reviewer for this draft. The General Area 
> Review Team (Gen-ART) reviews all IETF documents being processed by 
> the IESG for the IETF Chair. Please wait for direction from your 
> document shepherd or AD before posting a new version of the draft. For 
> more information, please see the FAQ at <​ 
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> [Note: I received no response to my LC comments. Reviewing the message 
> I sent, I wonder if it perhaps was not delivered. The following 
> comments are a duplicate of what I sent as LC comments.]
>
> Summary: This draft is on the right track but has open issues, 
> described in the review.
>
> Major Issues: NONE
>
> Minor Issues:
>
> It would be helpful if this draft described its intended target 
> audience. It would also benefit from having additional references 
> providing background context for the substance of the draft.
>
> In particular, "ECMP" and "PMTUD" are used extensively, in the text 
> and even the title of the draft. While these acronyms are expanded in 
> the text, there are no references to definitions of them.
>
> I sought out references for ECMP. The ones I found are RFC2991 and 
> RFC2992, which are old. Is there a more recent analysis that ought to 
> be considered? It seems that the problem at hand comes when using ECMP 
> for load balancing across multiple servers. Is there some reference 
> that talks about that? (RFCs 2991 and 2992 are more general - they 
> could apply in other contexts and don't mention this use.)
>
> The single reference in the document is to RFC4821. Is it the proper 
> reference for PMTUD? It seems to be closely related, but it seems to 
> be more specialized.
>
> In the Security Considerations section a possible attack is 
> identified, and a mitigation described. But then a seemingly serious 
> drawback to the mitigation is also described. I think this bears more 
> discussion.
>
>     Thanks,
>     Paul
>
> .
>