Re: [nvo3] Mirja Kühlewind's No Objection on draft-ietf-nvo3-arch-07: (with COMMENT)

2016-09-20 Thread Mirja Kuehlewind (IETF)
Okay, thanks!

> Am 20.09.2016 um 02:15 schrieb Black, David :
> 
> 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


Re: [nvo3] Mirja Kühlewind's No Objection on draft-ietf-nvo3-arch-07: (with COMMENT)

2016-09-19 Thread Black, David
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