Subject: [Gen-art] RE: Gen-ART Review of draft-ietf-l2vpn-requirements-05.txt

From: "Amante, Shane" <[email-masked]>
Date: Wed, 4 Jan 2006 16:42:20 -0700

Yetik,
 
Did you run this through id-nits?
 
-shane

________________________________

	From: Serbest, Yetik [mailto:[email-masked]] 
	Sent: Wednesday, January 04, 2006 4:39 PM
	To: Spencer Dawkins; General Area Review Team
	Cc: Amante, Shane; Vach Kompella; Mark Townsley; Russ Housley;
Alex Zinin; Waldemar Augustyn
	Subject: RE: Gen-ART Review of
draft-ietf-l2vpn-requirements-05.txt 

	Hi Everybody,

	Happy New Year!

	Attached is the new version of the draft. I took care of all of
Spencer's comments (It would be nice if Spencer checks).

	I will wait for Vach and Shane's go to submit.

	Thanks,

	yetik

________________________________

	From: Spencer Dawkins [mailto:[email-masked]] 
	Sent: Friday, December 23, 2005 5:38 PM
	To: Serbest, Yetik; General Area Review Team
	Cc: Shane Amante; Vach Kompella; Mark Townsley; Russ Housley;
Alex Zinin; Waldemar Augustyn
	Subject: Re: Gen-ART Review of
draft-ietf-l2vpn-requirements-05.txt 

	Dear Yetik,

	Wow, this is like the Summer of Love, in December ...

	Thanks for the quick turnaround - it looks like we're in sync,
no further comments from me - and happy holidaze to you as well!

	Spencer

		----- Original Message ----- 

		From: Serbest, Yetik <mailto:[email-masked]>

		To: Spencer Dawkins <mailto:[email-masked]>  ;
General Area Review Team <mailto:[email-masked]>  

		Cc: Shane Amante <mailto:[email-masked]>  ;
Vach Kompella <mailto:[email-masked]>  ; Mark Townsley
<mailto:[email-masked]>  ; Russ Housley
<mailto:[email-masked]>  ; Alex Zinin <mailto:[email-masked]>  ;
Waldemar Augustyn <mailto:[email-masked]>  

		Sent: Friday, December 23, 2005 2:05 PM

		Subject: RE: Gen-ART Review of
draft-ietf-l2vpn-requirements-05.txt 

		Hi Spencer,

		Thanks a lot for great commentrs/suggestions. The draft
is getting better for sure with your comments. Please see my responses,
starts with [Yetik+].

		thanks, nad Happy Holidays,

		yetik 

________________________________

		From: Spencer Dawkins [mailto:[email-masked]]
		Sent: Fri 12/23/2005 11:45 AM
		To: Serbest, Yetik; General Area Review Team
		Cc: Shane Amante; Vach Kompella; Mark Townsley; Russ
Housley; Alex Zinin; Waldemar Augustyn
		Subject: Re: Gen-ART Review of
draft-ietf-l2vpn-requirements-05.txt 

		Hi, Yetik,
		
		Thanks for the speedy response and for the explanations.
It looks like most
		of my notes can be closed.
		
		(Please remember to talk to your AD/document shepherd
before submitting an
		updated draft - Brian and Mark could disagree with my
comments - they are
		ADs and I am not - and it depresses the IESG to approve
a document that was
		still wiggling around in e-mail!)
		
		Just to work on closing the last couple of notes - my
comments will be
		tagged as "Spencer+"
		
		Spencer
		
		3.4 VPLS
		
		   In a VPLS, a customer site receives Layer 2 service
from the SP.  The
		   PE is attached via an access connection to one or
more CEs.  The PE
		   performs forwarding of user data packets based on
information in the
		   Layer 2 header, such as a MAC destination address.
The CE sees a
		   bridge.
		
		Spencer: "sees a bridge" doesn't seem particularly clear
here. Section
		4.7.2
		is a good example of what I'm hoping for - calling out
specific
		specifications for the interface that are required. At
the very least,
		Figure 3 shows "backdoor links" - so do all L2VPN
solutions need to
		provide
		802.1D-2004 spanning tree support? I should also note
that I'm currently
		
		involved in some pretty detailed discussion about
"bridging" in TRILL,
		and
		lack of precision about what a "bridge" actually does is
making our work
		
		difficult there, so I'm more sensitive than usual on
this topic.
		
		[Yetik] Again, we will remove that sentence. The details
of the model
		are in framework document. There was a long discussion
in L2VPN design
		team about the model. I can find the e-mail
correspondence if you like.
		Especially, Norm Finn helped us to put the model
together. As for the
		STP support, we really don't care. Again there was a
long discussion
		about this topic. To snoop customer BPDUs (or RSTP TCN)
to avoid
		black-holing for dual-homed customers, or to participate
in the
		customer's STP etc... The requirement is that a solution
should support
		back-door links. I don't think we should talk about the
solutions.
		
		Spencer+ - If I understand correctly, you're saying that
if a customer is
		running STP and connects two L2VPN sites with a
back-door link, L2VPN won't
		make this work better or worse than it would if the
sites were directly
		connected to the rest of the customer's network - if I
got this right,
		removing the sentence would be fine.

		[Yetik+] Exactly.

		4.6 Addressing
		   A L2VPN solution MUST support overlapping addresses
of different
		   L2VPNs.  For instance, customers MUST NOT be
prevented from using the
		   same MAC addresses and/or the same VLAN Ids when used
with different
		   L2VPNs.  Actually, for VLANs, there are two cases.
First, a L2VPN is
		   oblivious to customer VLANs.  In this case, customers
can have
		   overlapping VLAN Ids.  Second, VLAN Ids MAY be used
as service
		   delimiters, in which case it depends on whether the
SP assigns the
		   VLANs or not.  If it does, then there is no overlap.
If it doesn't,
		   then overlapping VLAN Ids can occur and the SP has to
put safeguards
		   in place to avoid this situation.
		
		Spencer: this is a MUST requirement, but it's fairly
confusing to me -
		is it
		saying, "L2VPN solutions MUST allow multiple customers
to use
		overlapping
		MAC addresses and VLAN ID ranges, whether or not the SP
assigns VLAN ID
		ranges"?
		
		[Yetik] If a VLAN is service delimiter, then
service-delimiter VLANs can
		not overlap. Does it make sense? On the other hand,
overlapping MAC
		addresses is a requirement for any case.
		
		Spencer+ - your shorter explanation helps a lot - can
you stick it in the
		document? :-) Something like

		   A L2VPN solution MUST support overlapping addresses
of different
		   L2VPNs.  For instance, customers MUST NOT be
prevented from using the
		   same MAC addresses with different L2VPNs. If a
service provider uses
		   VLANs as service delimiters, the L2VPN solution MUST
ensure that VLAN
		   Ids cannot overlap. If VLANs are not used as service
delimiters, L2VPN
		   solutions MAY allow overlap.

		[Yetik+] I will do it.

		5.6.2  Access Connectivity
		   In case of VPLS, multi-link access for CE devices
SHOULD be
		supported.
		
		Spencer: Got a specific "multi-link" technology in mind?
IEEE
		802.3ad-2000
		link aggregation, or something else?
		
		[Yetik] That is correct.
		
		Spencer+ - could you make this more explicit? PPP also
has a multi-link
		capability (RFC 1990), and I imagine other people could
find other things to
		be confused about...  something like "In case of VPLS,
IEEE 802.3ad-2000
		link aggregation SHOULD be supported"?

		[Yetik+] Great suggestion.

		5.7.2  Packet Re-ordering
		   The queuing and forwarding policies SHOULD preserve
packet order for
		   packets with the same QoS parameters.
		
		Spencer: Is this "in normal operation", or "even during
protection
		events"?
		
		[Yetik] Normal operation.
		
		Spencer+ - could you add the qualifier to the text, as
in "During normal
		operation, the queuing and forwarding policies SHOULD
preserve packet order
		for packets with the same QoS parameters."?

		[Yetik+] Again great suggestion.

		5.7.3  Minimum MTU
		
		   A VPLS MAY fragment packets as long as it is
transparent to the
		   customer.
		
		Spencer: is this really talking about "IP
fragmentation", or something
		more
		like SAR (segmentation and reassembly)?
		
		[Yetik] IP fragmentation.
		
		Spencer+ - I'm still somewhat confused here - and I
apologize for not being
		clearer, but I'm thinking of several questions at once.
May I try one more
		time? (1) "fragment" without explicitly saying
"IP-fragment" isn't clear
		enough to me, 

		[Yetik+] Agree with you, what can I say?

		(2) "it is transparent" isn't clear enough to me - is
this
		saying that the VPLS does reassembly before delivering a
fragmented packet
		to the customer? 

		[Yetik+] Exactly. Your understanding is correct.

		(3) Is there any intention to support IPv6, where we
		typically don't do fragmentation outside the end
systems?

		[Yetik+] Definitely, IPv6 is not excluded. 

		Spencer+ - If I was suggesting text based on what I
think this sentence is
		saying, it might be "A VPLS MAY use IP fragmentation if
it presents
		reassembled IP packets at VPLS customer edge devices"

		[Yetik+] I like your suggestion.

		6.3 Discovering L2VPN Related Information
		
		   A L2VPN solution SHOULD support the means for
attached CEs to
		   authenticate each other and verify that the SP L2VPN
is correctly
		   configured.
		
		Spencer: Is this talking about "correctly connected"
(which I can see
		CEs
		verifying), or something more (which seems harder to
visualize)?
		
		[Yetik] The former.
		
		Spencer+ - suggest "and verify that the SP L2VPN is
correctly connected"?

		[Yetik+] I will do it.

		6.4 SLS Support
		   Typically, a SP offering a L2VPN service commits to
specific SLS as
		   part of a contract with the customer.  Such a SLA
drives the specific
		   SP requirements for measuring specific SLSs for
quality,
		   availability, response time, and configuration
intervals.
		
		Spencer: unclear what is actually being required in 6.4
(I agree with
		the
		paragraph, I just don't see a requirement being stated).
		
		[Yetik] There was a requirement in the early versions,
then removed
		based on some comments. It was decided that it is an
implementation
		detail, and we just kept non-requirement text.
		
		Spencer+ - I'd remove it (since this is a requirements
draft, but doesn't
		require anything).

		[Yetik+] I will.

		6.7 Security
		
		   In addition, a SP network MUST be immune to malformed
or maliciously
		   constructed customer traffic.
		
		Spencer: I don't know what "immune" means in an SP
network context.
		
		[Yetik] It means should be protected against. If you
like I can change
		it as such.
		
		Spencer+ - that would be clearer, I think - thanks!

		[yetik+] Will do it.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Serbest, Yetik" <[email-masked]>
Date: Thu, 5 Jan 2006 09:35:44 -0600

Hi Shane,

I am not sure about the qualification: "set of all L2VPNs". Depending on
the implementation, a VLAN-id can be port significant or platform
significant or network significant. Hence, for the first one, a VLAN-id
can not overlap in a port, but can be re-used among ports. I don't know
how to capture this, that is why, I just left it as "... do not
overlap." without any qualification. Any other suggestions to capture
all these cases?

Thanks,

yetik

From: Amante, Shane [mailto:[email-masked]] 
Sent: Thursday, January 05, 2006 8:20 AM
To: Spencer Dawkins; Serbest, Yetik; General Area Review Team
Cc: Vach Kompella; Mark Townsley; Russ Housley; Alex Zinin; Waldemar
Augustyn
Subject: RE: Gen-ART Review of draft-ietf-l2vpn-requirements-05.txt 

Yetik,

I looked over the suggested changes last night and am OK with all of
them, except one which I think needs a little more clarity.  

1)  In Section 4.6, I'm not sure I like Spencer's proposed new language.
See below for some suggested, improved text:

---cut here---

4.6 Addressing 
   A L2VPN solution MUST support overlapping MAC addresses within
different 
   L2VPNs.  For instance, customers MUST NOT be prevented from using the

   same MAC addresses within different L2VPNs. 

   If a service provider uses VLAN IDs as service delimiters, the L2VPN
solution

   MUST ensure that VLAN IDs do not overlap. If VLAN IDs are not used as

   service delimiters, L2VPN solutions MAY allow VLAN IDs to overlap.

---cut here--

One additional point is: can you clarify the word 'overlap' as it
applies in the 2nd paragraph?  In other words, would the following be a
correct statement?

---cut here---

   If a service provider uses VLAN IDs as service delimiters, the L2VPN
solution

   MUST ensure that VLAN IDs do not overlap among the set of all
L2VPN's.

   If VLAN ID's are not used as service delimiters, L2VPN solutions MAY

   allow VLAN IDs to overlap among the set of all L2VPN's.

---cut here---

(Perhaps there are better words than "set of all L2VPN's", but
sufficient enough to address what the overlap applies to).

2)  I ran it through id-nits checker and it didn't like the Copyright
2005 statement in the boilerplate.  Could you run it through id-nits and
fix that?  

Once we get through 1 and 2 above, I'm OK with publishing -06.

Thanks!

-shane

	

	Sent: Wednesday, January 04, 2006 5:25 PM

	Spencer checked. All the changes are as we discussed (and
thanks!)...

	Spencer

		----- Original Message ----- 

		Sent: Wednesday, January 04, 2006 5:38 PM

		Hi Everybody,

		Happy New Year!

		Attached is the new version of the draft. I took care of
all of Spencer's comments (It would be nice if Spencer checks).

		Thanks,

		yetik

		Dear Yetik,

		Thanks for the quick turnaround - it looks like we're in
sync, no further comments from me - and happy holidaze to you as well!

		Spencer

			----- Original Message ----- 

			From: Serbest, Yetik
<mailto:[email-masked]>  

			To: Spencer Dawkins
<mailto:[email-masked]>  ; General Area Review Team
<mailto:[email-masked]>  

			Cc: Shane Amante
<mailto:[email-masked]>  ; Vach Kompella
<mailto:[email-masked]>  ; Mark Townsley
<mailto:[email-masked]>  ; Russ Housley
<mailto:[email-masked]>  ; Alex Zinin <mailto:[email-masked]>  ;
Waldemar Augustyn <mailto:[email-masked]>  

			Hi Spencer,

			Thanks a lot for great commentrs/suggestions.
The draft is getting better for sure with your comments. Please see my
responses, starts with [Yetik+].

			yetik 

			From: Spencer Dawkins
[mailto:[email-masked]]
			Sent: Fri 12/23/2005 11:45 AM
			To: Serbest, Yetik; General Area Review Team
			Cc: Shane Amante; Vach Kompella; Mark Townsley;
Russ Housley; Alex Zinin; Waldemar Augustyn
			Subject: Re: Gen-ART Review of
draft-ietf-l2vpn-requirements-05.txt 

			Hi, Yetik,
			
			Thanks for the speedy response and for the
explanations. It looks like most
			of my notes can be closed.
			
			(Please remember to talk to your AD/document
shepherd before submitting an
			updated draft - Brian and Mark could disagree
with my comments - they are
			ADs and I am not - and it depresses the IESG to
approve a document that was
			still wiggling around in e-mail!)
			
			Just to work on closing the last couple of notes
- my comments will be
			tagged as "Spencer+"
			
			Spencer
			
			3.4 VPLS
			
			   In a VPLS, a customer site receives Layer 2
service from the SP.  The
			   PE is attached via an access connection to
one or more CEs.  The PE
			   performs forwarding of user data packets
based on information in the
			   Layer 2 header, such as a MAC destination
address.  The CE sees a
			   bridge.
			
			Spencer: "sees a bridge" doesn't seem
particularly clear here. Section
			4.7.2
			is a good example of what I'm hoping for -
calling out specific
			specifications for the interface that are
required. At the very least,
			Figure 3 shows "backdoor links" - so do all
L2VPN solutions need to
			provide
			802.1D-2004 spanning tree support? I should also
note that I'm currently
			
			involved in some pretty detailed discussion
about "bridging" in TRILL,
			and
			lack of precision about what a "bridge" actually
does is making our work
			
			difficult there, so I'm more sensitive than
usual on this topic.
			
			[Yetik] Again, we will remove that sentence. The
details of the model
			are in framework document. There was a long
discussion in L2VPN design
			team about the model. I can find the e-mail
correspondence if you like.
			Especially, Norm Finn helped us to put the model
together. As for the
			STP support, we really don't care. Again there
was a long discussion
			about this topic. To snoop customer BPDUs (or
RSTP TCN) to avoid
			black-holing for dual-homed customers, or to
participate in the
			customer's STP etc... The requirement is that a
solution should support
			back-door links. I don't think we should talk
about the solutions.
			
			Spencer+ - If I understand correctly, you're
saying that if a customer is
			running STP and connects two L2VPN sites with a
back-door link, L2VPN won't
			make this work better or worse than it would if
the sites were directly
			connected to the rest of the customer's network
- if I got this right,
			removing the sentence would be fine.

			[Yetik+] Exactly.

			4.6 Addressing
			   A L2VPN solution MUST support overlapping
addresses of different
			   L2VPNs.  For instance, customers MUST NOT be
prevented from using the
			   same MAC addresses and/or the same VLAN Ids
when used with different
			   L2VPNs.  Actually, for VLANs, there are two
cases.  First, a L2VPN is
			   oblivious to customer VLANs.  In this case,
customers can have
			   overlapping VLAN Ids.  Second, VLAN Ids MAY
be used as service
			   delimiters, in which case it depends on
whether the SP assigns the
			   VLANs or not.  If it does, then there is no
overlap.  If it doesn't,
			   then overlapping VLAN Ids can occur and the
SP has to put safeguards
			   in place to avoid this situation.
			
			Spencer: this is a MUST requirement, but it's
fairly confusing to me -
			is it
			saying, "L2VPN solutions MUST allow multiple
customers to use
			overlapping
			MAC addresses and VLAN ID ranges, whether or not
the SP assigns VLAN ID
			ranges"?
			
			[Yetik] If a VLAN is service delimiter, then
service-delimiter VLANs can
			not overlap. Does it make sense? On the other
hand, overlapping MAC
			addresses is a requirement for any case.
			
			Spencer+ - your shorter explanation helps a lot
- can you stick it in the
			document? :-) Something like

			   A L2VPN solution MUST support overlapping
addresses of different
			   L2VPNs.  For instance, customers MUST NOT be
prevented from using the
			   same MAC addresses with different L2VPNs. If
a service provider uses
			   VLANs as service delimiters, the L2VPN
solution MUST ensure that VLAN
			   Ids cannot overlap. If VLANs are not used as
service delimiters, L2VPN
			   solutions MAY allow overlap.

			[Yetik+] I will do it.

			5.6.2  Access Connectivity
			   In case of VPLS, multi-link access for CE
devices SHOULD be
			supported.
			
			Spencer: Got a specific "multi-link" technology
in mind? IEEE
			802.3ad-2000
			link aggregation, or something else?
			
			[Yetik] That is correct.
			
			Spencer+ - could you make this more explicit?
PPP also has a multi-link
			capability (RFC 1990), and I imagine other
people could find other things to
			be confused about...  something like "In case of
VPLS, IEEE 802.3ad-2000
			link aggregation SHOULD be supported"?

			5.7.2  Packet Re-ordering
			   The queuing and forwarding policies SHOULD
preserve packet order for
			   packets with the same QoS parameters.
			
			Spencer: Is this "in normal operation", or "even
during protection
			events"?

			Spencer+ - could you add the qualifier to the
text, as in "During normal
			operation, the queuing and forwarding policies
SHOULD preserve packet order
			for packets with the same QoS parameters."?

			5.7.3  Minimum MTU

			
			
			Spencer+ - I'm still somewhat confused here -
and I apologize for not being
			clearer, but I'm thinking of several questions
at once. May I try one more
			time? (1) "fragment" without explicitly saying
"IP-fragment" isn't clear
			enough to me, 

			(2) "it is transparent" isn't clear enough to me
- is this
			saying that the VPLS does reassembly before
delivering a fragmented packet
			to the customer? 

			(3) Is there any intention to support IPv6,
where we
			typically don't do fragmentation outside the end
systems?

			Spencer+ - If I was suggesting text based on
what I think this sentence is
			saying, it might be "A VPLS MAY use IP
fragmentation if it presents
			reassembled IP packets at VPLS customer edge
devices"

			
			   A L2VPN solution SHOULD support the means for
attached CEs to
			   authenticate each other and verify that the
SP L2VPN is correctly
			   configured.
			
			Spencer: Is this talking about "correctly
connected" (which I can see
			CEs
			verifying), or something more (which seems
harder to visualize)?
			
			[Yetik] The former.
			
			Spencer+ - suggest "and verify that the SP L2VPN
is correctly connected"?

			[Yetik+] I will do it.

			6.4 SLS Support
			   Typically, a SP offering a L2VPN service
commits to specific SLS as
			   part of a contract with the customer.  Such a
SLA drives the specific
			   SP requirements for measuring specific SLSs
for quality,
			   availability, response time, and
configuration intervals.
			
			Spencer: unclear what is actually being required
in 6.4 (I agree with
			the
			paragraph, I just don't see a requirement being
stated).
			
			[Yetik] There was a requirement in the early
versions, then removed
			based on some comments. It was decided that it
is an implementation
			detail, and we just kept non-requirement text.
			
			Spencer+ - I'd remove it (since this is a
requirements draft, but doesn't
			require anything).

			[Yetik+] I will.

			6.7 Security
			
			   In addition, a SP network MUST be immune to
malformed or maliciously
			   constructed customer traffic.
			
			Spencer: I don't know what "immune" means in an
SP network context.
			
			[Yetik] It means should be protected against. If
you like I can change
			it as such.
			
			Spencer+ - that would be clearer, I think -
thanks!

			[yetik+] Will do it.

---

From: "Amante, Shane" <[email-masked]>
Date: Thu, 5 Jan 2006 11:31:16 -0700

Yetik,
 
How about this, then?
 
---cut here---

   MUST ensure that VLAN IDs do not overlap among a set of L2VPN's
sharing

   a common resource.  (Although this is implementation-dependent, a
common

   resource may be defined as a physical port, a PE or network-wide).
If VLAN ID's

   are not used as service delimiters, L2VPN solutions MAY allow VLAN
IDs to

   overlap.

---cut here---

If you view this as overly pedantic, then I'd be OK with leaving the
existing semi-vague language intact.

-shane

	From: Serbest, Yetik [mailto:[email-masked]] 
	Sent: Thursday, January 05, 2006 8:36 AM
	To: Amante, Shane; Spencer Dawkins; General Area Review Team
	Cc: Vach Kompella; Mark Townsley; Russ Housley; Alex Zinin;
Waldemar Augustyn
	Subject: RE: Gen-ART Review of
draft-ietf-l2vpn-requirements-05.txt 

	Hi Shane,

	I am not sure about the qualification: "set of all L2VPNs".
Depending on the implementation, a VLAN-id can be port significant or
platform significant or network significant. Hence, for the first one, a
VLAN-id can not overlap in a port, but can be re-used among ports. I
don't know how to capture this, that is why, I just left it as "... do
not overlap." without any qualification. Any other suggestions to
capture all these cases?

	Thanks,

	yetik

	Cc: Vach Kompella; Mark Townsley; Russ Housley; Alex Zinin;
Waldemar Augustyn

	Yetik,

	I looked over the suggested changes last night and am OK with
all of them, except one which I think needs a little more clarity.  

	1)  In Section 4.6, I'm not sure I like Spencer's proposed new
language.  See below for some suggested, improved text:

	---cut here---

	4.6 Addressing 
	   A L2VPN solution MUST support overlapping MAC addresses
within different 
	   L2VPNs.  For instance, customers MUST NOT be prevented from
using the 
	   same MAC addresses within different L2VPNs. 

	   If a service provider uses VLAN IDs as service delimiters,
the L2VPN solution

	   MUST ensure that VLAN IDs do not overlap. If VLAN IDs are not
used as

	   service delimiters, L2VPN solutions MAY allow VLAN IDs to
overlap.

	---cut here--

	One additional point is: can you clarify the word 'overlap' as
it applies in the 2nd paragraph?  In other words, would the following be
a correct statement?

	---cut here---

	   If a service provider uses VLAN IDs as service delimiters,
the L2VPN solution

	   If VLAN ID's are not used as service delimiters, L2VPN
solutions MAY

	---cut here---

	2)  I ran it through id-nits checker and it didn't like the
Copyright 2005 statement in the boilerplate.  Could you run it through
id-nits and fix that?  

	Thanks!

	-shane

		

		Cc: Amante, Shane; Vach Kompella; Mark Townsley; Russ

		Spencer checked. All the changes are as we discussed
(and thanks!)...

		Spencer

			----- Original Message ----- 

			From: Serbest, Yetik

			To: Spencer Dawkins

			Cc: Shane Amante

			Hi Everybody,

			Happy New Year!

			Attached is the new version of the draft. I took
care of all of Spencer's comments (It would be nice if Spencer checks).

			Thanks,

			yetik

			From: Spencer Dawkins

			Dear Yetik,

			Wow, this is like the Summer of Love, in
December ...

			Thanks for the quick turnaround - it looks like
we're in sync, no further comments from me - and happy holidaze to you
as well!

			Spencer

				----- Original Message ----- 

				From: Serbest, Yetik

				To: Spencer Dawkins

				Cc: Shane Amante

				Hi Spencer,

				Thanks a lot for great
commentrs/suggestions. The draft is getting better for sure with your
comments. Please see my responses, starts with [Yetik+].

				yetik 

				From: Spencer Dawkins
[mailto:[email-masked]]
				Sent: Fri 12/23/2005 11:45 AM
				To: Serbest, Yetik; General Area Review
Team
				Cc: Shane Amante; Vach Kompella; Mark
Townsley; Russ Housley; Alex Zinin; Waldemar Augustyn
				Subject: Re: Gen-ART Review of
draft-ietf-l2vpn-requirements-05.txt 

				Hi, Yetik,
				
				Thanks for the speedy response and for
the explanations. It looks like most
				of my notes can be closed.
				
				(Please remember to talk to your
AD/document shepherd before submitting an
				updated draft - Brian and Mark could
disagree with my comments - they are
				ADs and I am not - and it depresses the
IESG to approve a document that was
				still wiggling around in e-mail!)
				
				Just to work on closing the last couple
of notes - my comments will be
				tagged as "Spencer+"
				
				Spencer
				
				3.4 VPLS
				
				   In a VPLS, a customer site receives
Layer 2 service from the SP.  The
				   PE is attached via an access
connection to one or more CEs.  The PE
				   performs forwarding of user data
packets based on information in the
				   Layer 2 header, such as a MAC
destination address.  The CE sees a
				   bridge.
				
				Spencer: "sees a bridge" doesn't seem
particularly clear here. Section
				4.7.2
				is a good example of what I'm hoping for
- calling out specific
				specifications for the interface that
are required. At the very least,
				Figure 3 shows "backdoor links" - so do
all L2VPN solutions need to
				provide
				802.1D-2004 spanning tree support? I
should also note that I'm currently
				
				involved in some pretty detailed
discussion about "bridging" in TRILL,
				and
				lack of precision about what a "bridge"
actually does is making our work
				
				difficult there, so I'm more sensitive
than usual on this topic.
				
				[Yetik] Again, we will remove that
sentence. The details of the model
				are in framework document. There was a
long discussion in L2VPN design
				team about the model. I can find the
e-mail correspondence if you like.
				Especially, Norm Finn helped us to put
the model together. As for the
				STP support, we really don't care. Again
there was a long discussion
				about this topic. To snoop customer
BPDUs (or RSTP TCN) to avoid
				black-holing for dual-homed customers,
or to participate in the
				customer's STP etc... The requirement is
that a solution should support
				back-door links. I don't think we should
talk about the solutions.
				
				Spencer+ - If I understand correctly,
you're saying that if a customer is
				running STP and connects two L2VPN sites
with a back-door link, L2VPN won't
				make this work better or worse than it
would if the sites were directly
				connected to the rest of the customer's
network - if I got this right,
				removing the sentence would be fine.

				[Yetik+] Exactly.

				4.6 Addressing
				   A L2VPN solution MUST support
overlapping addresses of different
				   L2VPNs.  For instance, customers MUST
NOT be prevented from using the
				   same MAC addresses and/or the same
VLAN Ids when used with different
				   L2VPNs.  Actually, for VLANs, there
are two cases.  First, a L2VPN is
				   oblivious to customer VLANs.  In this
case, customers can have
				   overlapping VLAN Ids.  Second, VLAN
Ids MAY be used as service
				   delimiters, in which case it depends
on whether the SP assigns the
				   VLANs or not.  If it does, then there
is no overlap.  If it doesn't,
				   then overlapping VLAN Ids can occur
and the SP has to put safeguards
				   in place to avoid this situation.
				
				Spencer: this is a MUST requirement, but
it's fairly confusing to me -
				is it
				saying, "L2VPN solutions MUST allow
multiple customers to use
				overlapping
				MAC addresses and VLAN ID ranges,
whether or not the SP assigns VLAN ID
				ranges"?
				
				[Yetik] If a VLAN is service delimiter,
then service-delimiter VLANs can
				not overlap. Does it make sense? On the
other hand, overlapping MAC
				addresses is a requirement for any case.
				
				Spencer+ - your shorter explanation
helps a lot - can you stick it in the
				document? :-) Something like

				   A L2VPN solution MUST support
overlapping addresses of different
				   L2VPNs.  For instance, customers MUST
NOT be prevented from using the
				   same MAC addresses with different
L2VPNs. If a service provider uses
				   VLANs as service delimiters, the
L2VPN solution MUST ensure that VLAN
				   Ids cannot overlap. If VLANs are not
used as service delimiters, L2VPN
				   solutions MAY allow overlap.

				[Yetik+] I will do it.

				5.6.2  Access Connectivity
				   In case of VPLS, multi-link access
for CE devices SHOULD be
				supported.
				
				Spencer: Got a specific "multi-link"
technology in mind? IEEE
				802.3ad-2000
				link aggregation, or something else?
				
				[Yetik] That is correct.
				
				Spencer+ - could you make this more
explicit? PPP also has a multi-link
				capability (RFC 1990), and I imagine
other people could find other things to
				be confused about...  something like "In
case of VPLS, IEEE 802.3ad-2000
				link aggregation SHOULD be supported"?

				5.7.2  Packet Re-ordering
				   The queuing and forwarding policies
SHOULD preserve packet order for
				   packets with the same QoS parameters.
				
				Spencer: Is this "in normal operation",
or "even during protection
				events"?

				Spencer+ - could you add the qualifier
to the text, as in "During normal
				operation, the queuing and forwarding
policies SHOULD preserve packet order
				for packets with the same QoS
parameters."?

				5.7.3  Minimum MTU
				
				   A VPLS MAY fragment packets as long
as it is transparent to the
				   customer.
				
				Spencer: is this really talking about
"IP fragmentation", or something
				more
				like SAR (segmentation and reassembly)?

				Spencer+ - I'm still somewhat confused
here - and I apologize for not being
				clearer, but I'm thinking of several
questions at once. May I try one more
				time? (1) "fragment" without explicitly
saying "IP-fragment" isn't clear
				enough to me, 

				(2) "it is transparent" isn't clear
enough to me - is this
				saying that the VPLS does reassembly
before delivering a fragmented packet
				to the customer? 

				[Yetik+] Exactly. Your understanding is
correct.

				(3) Is there any intention to support
IPv6, where we
				typically don't do fragmentation outside
the end systems?

				[Yetik+] Definitely, IPv6 is not
excluded. 

				Spencer+ - If I was suggesting text
based on what I think this sentence is
				saying, it might be "A VPLS MAY use IP
fragmentation if it presents
				reassembled IP packets at VPLS customer
edge devices"

				6.3 Discovering L2VPN Related
Information
				
				   A L2VPN solution SHOULD support the
means for attached CEs to
				   authenticate each other and verify
that the SP L2VPN is correctly
				   configured.
				
				Spencer: Is this talking about
"correctly connected" (which I can see
				CEs
				verifying), or something more (which
seems harder to visualize)?
				
				[Yetik] The former.
				
				Spencer+ - suggest "and verify that the
SP L2VPN is correctly connected"?

				[Yetik+] I will do it.

				6.4 SLS Support
				   Typically, a SP offering a L2VPN
service commits to specific SLS as
				   part of a contract with the customer.
Such a SLA drives the specific
				   SP requirements for measuring
specific SLSs for quality,
				   availability, response time, and
configuration intervals.
				
				Spencer: unclear what is actually being
required in 6.4 (I agree with
				the
				paragraph, I just don't see a
requirement being stated).
				
				[Yetik] There was a requirement in the
early versions, then removed
				based on some comments. It was decided
that it is an implementation
				detail, and we just kept non-requirement
text.
				
				Spencer+ - I'd remove it (since this is
a requirements draft, but doesn't
				require anything).

				[Yetik+] I will.

				6.7 Security
				
				   In addition, a SP network MUST be
immune to malformed or maliciously
				   constructed customer traffic.
				
				Spencer: I don't know what "immune"
means in an SP network context.
				
				[Yetik] It means should be protected
against. If you like I can change
				it as such.
				
				Spencer+ - that would be clearer, I
think - thanks!

				[yetik+] Will do it.

---

From: "Serbest, Yetik" <[email-masked]>
Date: Thu, 5 Jan 2006 14:40:45 -0600

Shane,

If we keep the sentence in the parentheses, yes it is pedantic. If we
don't, then the "resource" will be vague.

How about:

   MUST ensure that VLAN IDs do not overlap among a set of L2VPN's in
the span of the VLAN IDs.  If VLAN ID's

   overlap.

Thanks,

yetik

From: Amante, Shane [mailto:[email-masked]] 
Sent: Thursday, January 05, 2006 12:31 PM
To: Serbest, Yetik; Spencer Dawkins; General Area Review Team
Cc: Vach Kompella; Mark Townsley; Russ Housley; Alex Zinin; Waldemar
Augustyn
Subject: RE: Gen-ART Review of draft-ietf-l2vpn-requirements-05.txt 

Yetik,

How about this, then?

---cut here---

   overlap.

---cut here---

-shane

	Hi Shane,

	Thanks,

	yetik

	Yetik,

	---cut here---

	4.6 Addressing 

	---cut here--

	---cut here---

	Thanks!

	-shane

		

		Spencer

			----- Original Message ----- 

			From: Serbest, Yetik

			To: Spencer Dawkins

			Cc: Shane Amante

			Hi Everybody,

			Happy New Year!

			Thanks,

			yetik

			From: Spencer Dawkins

			Dear Yetik,

			Spencer

				----- Original Message ----- 

				From: Serbest, Yetik

				To: Spencer Dawkins

				Cc: Shane Amante

				Hi Spencer,

				Thanks a lot for great

				yetik 

				From: Spencer Dawkins

				Hi, Yetik,

				
				
				Spencer
				
				3.4 VPLS

				

				

				[Yetik+] Exactly.

				4.6 Addressing

				

				[Yetik+] I will do it.

				
				
				[Yetik] That is correct.

				5.7.2  Packet Re-ordering

				

				5.7.3  Minimum MTU

				

				

				[Yetik] The former.

				[Yetik+] I will do it.

				6.4 SLS Support

				

				[Yetik+] I will.

				6.7 Security

				

				[yetik+] Will do it.

---

From: "Amante, Shane" <[email-masked]>
Date: Thu, 5 Jan 2006 16:42:06 -0700

Yetik,
 
I'm not too happy with that compromise, either, as it doesn't make
sense.  Let's go back to something close to Spencer's original.

   MUST ensure that VLAN IDs do not overlap.  If VLAN ID's are not used
as service 

   delimiters, L2VPN solutions MAY allow VLAN IDs to overlap.

After all, this is a reqmt's doc, and the subsequent solutions
adequately address this, so let's just move on.
 
-shane

	Sent: Thursday, January 05, 2006 1:41 PM

	Shane,

	If we keep the sentence in the parentheses, yes it is pedantic.
If we don't, then the "resource" will be vague.

	How about:

	   MUST ensure that VLAN IDs do not overlap among a set of
L2VPN's in the span of the VLAN IDs.  If VLAN ID's

	   are not used as service delimiters, L2VPN solutions MAY allow
VLAN IDs to

	   overlap.

	Thanks,

	yetik

	Yetik,

	How about this, then?

	---cut here---

	   MUST ensure that VLAN IDs do not overlap among a set of
L2VPN's sharing

	   a common resource.  (Although this is
implementation-dependent, a common

	   resource may be defined as a physical port, a PE or
network-wide).  If VLAN ID's

	   are not used as service delimiters, L2VPN solutions MAY allow
VLAN IDs to

	   overlap.

	---cut here---

	If you view this as overly pedantic, then I'd be OK with leaving
the existing semi-vague language intact.

	-shane

		Sent: Thursday, January 05, 2006 8:36 AM
		To: Amante, Shane; Spencer Dawkins; General Area Review
Team
		Cc: Vach Kompella; Mark Townsley; Russ Housley; Alex
Zinin; Waldemar Augustyn
		Subject: RE: Gen-ART Review of
draft-ietf-l2vpn-requirements-05.txt 

		Hi Shane,

		I am not sure about the qualification: "set of all
L2VPNs". Depending on the implementation, a VLAN-id can be port
significant or platform significant or network significant. Hence, for
the first one, a VLAN-id can not overlap in a port, but can be re-used
among ports. I don't know how to capture this, that is why, I just left
it as "... do not overlap." without any qualification. Any other
suggestions to capture all these cases?

		Thanks,

		yetik

		From: Amante, Shane [mailto:[email-masked]] 
		Sent: Thursday, January 05, 2006 8:20 AM
		To: Spencer Dawkins; Serbest, Yetik; General Area Review
Team
		Cc: Vach Kompella; Mark Townsley; Russ Housley; Alex
Zinin; Waldemar Augustyn
		Subject: RE: Gen-ART Review of
draft-ietf-l2vpn-requirements-05.txt 

		Yetik,

		I looked over the suggested changes last night and am OK
with all of them, except one which I think needs a little more clarity.

		1)  In Section 4.6, I'm not sure I like Spencer's
proposed new language.  See below for some suggested, improved text:

		---cut here---

		4.6 Addressing 
		   A L2VPN solution MUST support overlapping MAC
addresses within different 
		   L2VPNs.  For instance, customers MUST NOT be
prevented from using the 
		   same MAC addresses within different L2VPNs. 

		   If a service provider uses VLAN IDs as service
delimiters, the L2VPN solution

		   MUST ensure that VLAN IDs do not overlap. If VLAN IDs
are not used as

		   service delimiters, L2VPN solutions MAY allow VLAN
IDs to overlap.

		---cut here--

		One additional point is: can you clarify the word
'overlap' as it applies in the 2nd paragraph?  In other words, would the
following be a correct statement?

		---cut here---

		   If a service provider uses VLAN IDs as service
delimiters, the L2VPN solution

		   MUST ensure that VLAN IDs do not overlap among the
set of all L2VPN's.

		   If VLAN ID's are not used as service delimiters,
L2VPN solutions MAY

		   allow VLAN IDs to overlap among the set of all
L2VPN's.

		---cut here---

		(Perhaps there are better words than "set of all
L2VPN's", but sufficient enough to address what the overlap applies to).

		2)  I ran it through id-nits checker and it didn't like
the Copyright 2005 statement in the boilerplate.  Could you run it
through id-nits and fix that?  

		Once we get through 1 and 2 above, I'm OK with
publishing -06.

		Thanks!

		-shane

			

			From: Spencer Dawkins
			Cc: Amante, Shane; Vach Kompella; Mark Townsley;

			Spencer checked. All the changes are as we
discussed (and thanks!)...

			Spencer

				----- Original Message ----- 

				From: Serbest, Yetik

				To: Spencer Dawkins

				Cc: Shane Amante

				Sent: Wednesday, January 04, 2006 5:38
PM

				Hi Everybody,

				Happy New Year!

				Attached is the new version of the
draft. I took care of all of Spencer's comments (It would be nice if
Spencer checks).

				I will wait for Vach and Shane's go to
submit.

				Thanks,

				yetik

				From: Spencer Dawkins

				Dear Yetik,

				Thanks for the quick turnaround - it
looks like we're in sync, no further comments from me - and happy
holidaze to you as well!

				Spencer

				----- Original Message ----- 

				From: Serbest, Yetik

				To: Spencer Dawkins

				Cc: Shane Amante

				Hi Spencer,

				Thanks a lot for great

				yetik 

				From: Spencer Dawkins

				Hi, Yetik,

				
				
				Spencer
				
				3.4 VPLS

				

				

				[Yetik+] Exactly.

				4.6 Addressing

				

				[Yetik+] I will do it.

				
				
				[Yetik] That is correct.

				5.7.2  Packet Re-ordering

				

				5.7.3  Minimum MTU

				

				

				[Yetik] The former.

				[Yetik+] I will do it.

				6.4 SLS Support

				

				[Yetik+] I will.

				6.7 Security

				

				[yetik+] Will do it.

---

From: "Serbest, Yetik" <[email-masked]>
Date: Fri, 6 Jan 2006 12:36:10 -0600

I am submitting. 

Thanks,yetik

Sent: Thursday, January 05, 2006 5:42 PM

Yetik,

-shane

	

	Shane,

	How about:

	   overlap.

	Thanks,

	yetik

	Yetik,

	How about this, then?

	---cut here---

	   overlap.

	---cut here---

	-shane

		Hi Shane,

		Thanks,

		yetik

		Yetik,

		---cut here---

		4.6 Addressing 

		---cut here--

		---cut here---

		Thanks!

		-shane

			

			From: Spencer Dawkins

			Spencer

				----- Original Message ----- 

				From: Serbest, Yetik

				To: Spencer Dawkins

				Cc: Shane Amante

				Hi Everybody,

				Happy New Year!

				Thanks,

				yetik

				From: Spencer Dawkins

				Dear Yetik,

				Spencer

				----- Original Message ----- 

				From: Serbest, Yetik

				To: Spencer Dawkins

				Cc: Shane Amante

				Hi Spencer,

				Thanks a lot for great

				yetik 

				From: Spencer Dawkins

				Hi, Yetik,

				
				
				Spencer
				
				3.4 VPLS

				

				

				[Yetik+] Exactly.

				4.6 Addressing

				

				[Yetik+] I will do it.

				
				
				[Yetik] That is correct.

				5.7.2  Packet Re-ordering

				

				5.7.3  Minimum MTU

				

				

				[Yetik] The former.

				[Yetik+] I will do it.

				6.4 SLS Support

				

				[Yetik+] I will.

				6.7 Security

				

				[yetik+] Will do it.