Okay, thanks! > Am 20.09.2016 um 02:15 schrieb Black, David <[email protected]>: > > Hi Mirja, > > David> Inline ... > > Thanks, --David > >> -----Original Message----- >> From: Mirja Kuehlewind [mailto:[email protected]] >> Sent: Wednesday, September 14, 2016 12:29 PM >> To: The IESG >> Cc: [email protected]; Matthew Bocci; [email protected]; >> [email protected]; [email protected] >> Subject: Mirja Kühlewind's No Objection on draft-ietf-nvo3-arch-07: (with >> COMMENT) >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-nvo3-arch-07: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-nvo3-arch/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Two tiny comments: >> - Call section 4.5 "Virtual Access Point (VAP)" instead of only "VAP" > > David> Done. > >> - 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? > > Ok, they don't ;-). These were taken from RFC 6136 (L2VPN OAM) discussion, > primarily of fault management. However, it's not necessary to reuse those > terms here, as the relationship to RFC 6136 covered in the immediately prior > paragraph. I rewrote this to: > > The relationship between the overlay and underlay networks is a consideration > for > fault and performance management - > >> >> 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)? > > That's a matter best left to future drafts from the nvo3 WG. > > IMHO, the three needed protocols (NVE-to-NVA, NVA federation, split-NVE), > are sufficiently different that we're unlikely to see one protocol cover even > two of the three scenarios, especially as IEEE's VDP protocol has emerged > as the preferred split-NVE protocol. >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
