Simple Virtual Aggregation (S-VA)
draft-ietf-grow-simple-va-12

I'm inclined to agree with Barry about this being an Informational document. But I don't feel strongly.

These are non-blocking, but please consider them seriously, and feel free to chat with me about them:

This comment is on the edge of being a DISCUSS, but I think I'll try it this way: The document is generally OK, and I have great respect for the work of the non-native-English editors.  But there are some significant bits that are in sufficiently fractured English as to be hard to read and possibly confusing.  I've noted the worst of them below, but I'd like to see one of the native-English-speaking co-editors go over the document and make sure the articles, tenses, plurals, and commas are right.

Also, the document cites RFC 2119 and contains 2119 boilerplate, but I can only find one instance of a "MUST".  My sense is that this Informational document doesn't need 2119 at all, and that it should be removed.

The third paragraph of the Abstract doesn't seem to need to be in the Abstract, and I suggest removing it.  It's the sort of thing that will do fine in the Introduction only.

-- Introduction --

   Finally, provider defaults prevents the ISP from being able to detect
   martian packets.  As a result, the ISP transmits packets that could
   otherwise have been dropped over its expensive provider links.

Is "martian packets" a term of art, a bit of humour, or a typo?  If the first, is it sufficiently well known that it doesn't need explanation?  I don't understand it, but, then, I'm not steeped in this topic.  From the context, I can tell that it refers to packets that can safely be dropped.  [UPDATE... Lookie here!: Thanks to Robert for referring me to RFC 1208.  Who knew?  Shows you how much I don't know about things routing (or Martian).  Never mind this bit, then.  :-) ]

The second sentence, though, reads funny: it seems like you're talking about dropping packets over expensive links (rather than transmitting packets over them).  I think this is clearer:

NEW
As a result, the ISP transmits packets that could have been dropped, and sometimes does so over expensive provider links.

   Edge routers may install a default route to core routers, to ABRs
   which are installed on the Point of Presence (POP) to core boundary
   or to the ASBR routers.

With all the "to"s, and too few commas, I find it impossible to parse this sentence.  Please re-phrase and/or re-punctuate it so it's clearer.

   In configurations where BGP routes are used to resolve other routes
   or where BGP routes are redistributed to other protocols which both
   happen via RIB simple-va can rather then suppressing routes before
   they are installed in global RIB flag them as "suppress eligible".

Another incomprehensible sentence.  Please re-phrase and punctuate it.

-- Security Considerations --
   The authors are not aware of any new security considerations due to
   S-VA.

I believe that, but where *do* the security considerations come from?  From full VA?  If so, then it's probably a good idea to refer the reader to that document for security considerations.

**word smith alert**

1) abstract: Isn't this about the router running out of memory for the FIB?

OLD:

must upgrade router hardware simply because the FIB has run out of space,

NEW:

upgrade router hardware simply because the server has run out of memory to store the FIB,

2) s1, 1st para: same issue as #1

3) s1: what's a partial default?  It's the default some of the time?

- This is not an easy read, but it ought be. For example,
section 2 says: "In both cases simple VA operates in an
identical way however when default route is found and is
eligible to become a less specific prefix by router's
configuration the S-VA may use it. " I'd encourage the
authors to try get some additional editorial review aiming at
significantly increased clarity. (This was also almost a
DISCUSS, but isn't since this algorithm doesn't seem 
to affect security or interop, and if it did, deployments 
would turn it off quickly.)

- Various terms (e.g., ABR, ABSR, SPF, Adj-RIBs-In, Loc-RIB,
NLRI, ...) could be expanded.  The terminology section even
seems to use undefined terms.