ietf
[Top] [All Lists]

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

2008-03-28 01:47:47
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf