Okay, thanks!

> Am 20.09.2016 um 02:15 schrieb Black, David <david.bl...@dell.com>:
> 
> Hi Mirja,
> 
> David> Inline ...
> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: Mirja Kuehlewind [mailto:i...@kuehlewind.net]
>> Sent: Wednesday, September 14, 2016 12:29 PM
>> To: The IESG
>> Cc: draft-ietf-nvo3-a...@ietf.org; Matthew Bocci; nvo3-cha...@ietf.org;
>> matthew.bo...@alcatel-lucent.com; nvo3@ietf.org
>> 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
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to