Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC

Thanks for your review, Pekka. A few notes:

> it doesn't go into much detail on how they solved 
> difficult and more interesting issues, for example:
>   - how they solved MTU problems caused by adding hop-by-hop header
>   - given their deployment model, why didn't they try inserting a destination options
>     header instead of hop-by-hop and if they tried, why it didn't work;
>   - how did the rekeying of inter-AS solution work (not described)
>
> These would increase the value of the report.

This would be very useful addition to the document. Authors?

But note that the overall experience from the specific approach chosen
here was that yes, its possible get it to working, but there are
significant issues both for deployment and for the way the protocol bits
are arranged. Remember that this was an experiment, not a design ready
for standardization. MTU problems are in the list that is in Section 5.3.

> I object to 
> publishing the draft as written. At least issue 1) below needs to be 
> fixed before publication because the draft is confusing and 
> misrepresentative of the scope of existing solution solution space.
>
> 1) Access Network SAV and Intra-AS SAV terminology misrepresents the
> applicability of BCP38/84 and needs to be rephrased.
>
>     We use the term "intra-AS source address validation" to mean the IP
>     source address validation at the attachment point of an access
>     network to its provider network, also called the ingress point.  IP
>     source address validation at ingress points can enforce the source IP
>     address correctness at the IP prefix level, assuming the access
>     network owns one or more IP address blocks.  This practice has been
>     adopted as the Internet Best-Current-Practice [RFC2827][RFC3704].
>
> This text (also to some degree the previous paragraph) and Figure 1 
> are confusing.  In Figure 1, Intra-AS SAV occurs between two routers 
> is construed as if it was only applicable between routers. BCP38 and 
> BCP84 are applicable also in scenarios which are in the figure listed 
> under "Access Network SAV", not just under intras-AS SAV. 
> Specifically, BCP38/84 can be applied on each LAN interface of a 
> router.  In case router connects just one host, that is also a 
> sufficient solution and nothing else is needed.
>   

Right. This needs to be corrected in the draft.

I am not commenting on the remaining issues, but I expect the authors to
address them in a new revision of their document.

Jari

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf