An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)
draft-ietf-nvo3-arch-08

I agree with Stephen's last comment and would like to see text added to address that.

Two tiny comments:
- Call section 4.5 "Virtual Access Point (VAP)" instead of only "VAP"
-  I don't really understand this: "As is the case for L2VPN, there is a client/server relationship
   between the overlay and underlay networks..." How do the terms client and server help me here?

More general:
I was hoping to find a discussion on how existing protocols would be applicable to the three needed control protocols. Also do these three protocols need to be three different protocols or could all three cases potentially be covered by the same protocol (because the protocol mechanisms are the same and maybe even sometimes the same information needs to be exchanged)?

I found a small number of nits that I couldn't error-correct while reading, but I'm especially interested in Suresh's Discuss on TTL decrementing.

I couldn't parse 

   L3 VN to Legacy L2:  This type of gateway forwards packets on between
         L3 VNs and legacy L2 networks such as VLANs or L2 VPNs.  The
         MAC address in any frames forwarded between the legacy L2
                                             ^^^^^^^^^^^^^^^^^^^^^
         network would be the MAC address of the gateway.
         ^^^^^^^
         
I could guess, but something is borked, and I'm not sure what is meant.

I'm having the same problem with 

   L3 VN to L2 VN:  This type of gateway forwards packets on between L3
         VNs and L2 VNs.  The MAC address in any frames forwarded
         between the L2 VN would be the MAC address of the gateway.
         ^^^^^^^^^^^^^^^^^
         
further down.

I know what "hard" and "soft" errors are in my world, but I'm not sure what's meant here. 

   o  Delivered to correct NVE, but could not deliver packet to TS-X
      (soft error).

   o  Delivered to correct NVE, but could not deliver packet to TS-X
      (hard error).
      
Are these clearly understood terms of art in NV03? If not, could you provide some parenthetical "i.e.", as you do for other items in the same list, or some reference if an appropriate reference exists?

Is

   o  Allow different protocols and architectures to be used to for
                                                             ^^ ^^^
      intra- vs. inter-NVA communication.  
      
just a typo, or is there something missing between "to" and "for"?

- (This comment is just a generic remark, offered in the hope
that future IPR declarations might be more tightly targeted,
so there's no need to respond to it.) It's not clear to me
how an architecture with 2 RAND-with-fee IPR declarations
amounts to a win here.  Well, unless the IPR is rubbish maybe
- I did take a look at those and do have an opinion, but I'll
leave you to guess what that is:-) But the IPR declarations
seem like they were timely, and the last call did mention
them, so I guess it is what it is.  Generally though, I think
it'd be way better if IPR declarations were attached to
specific protocol documents that the IPR holders consider
relevant and not to architecture documents or similar. I can
understand that making an IPR declaration on a document like
this might be seen as getting the declaration out earlier (a
good thing), but one has to wonder how anything here
represents a credible invention. If that's the case I'd note
that IPR declarations can be made that don't point at an
Internet-draft which might be a better way to provide earlier
notification to a WG. And declarations can be updated later
to be associated with specific drafts if/when that's needed.

- Generally this was pretty well written, thanks.

- abstract/intro: "work with other components with no changes
to other components" isn't great, suggest re-wording.

- 4.2: ToR could do with an expansion on 1st use

- 4.2.1: TS - I assume that's "tenant system" (from 7635) but
you should say as it's used a good bit (and 7635 also defines
"tenant separation" making TS potentially ambiguous). Mostly,
uses of TS seem clear from context, but I think it'd be good
to fix this and to check over where TS is used in this draft
as there could be some subtlety there, e.g.  whether or not a
TSI is part of a TS or not (and is somehow architecturally
"beside" a TS) could affect some later protocol work.

- section 16: I think it might be worth noting here that
meta-data and operational data could be unexpectedly
sensitive, for example performance statistics could be used
to infer what's being done in a VM or VN. So in addition to
encrypting data in transit or storage, one might also want to
consider minimising the types of data that NVEs/NVAs collect.
That could have an impact on protocols defined later so may
well be worth noting here too. If you do add text on that you
may also want to recognise the tension between such data
minimisation and the operational need to detect misbehaviours
or errors happening within VNs.