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

From: "Serbest, Yetik" <[email-masked]>
Date: Wed, 4 Jan 2006 17:38:48 -0600

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: "Vach Kompella" <[email-masked]>
Date: Wed, 4 Jan 2006 15:49:24 -0800

Yetik,
 
I'll read it through tonight.  Change the 2005 to 2006 in the Copyright
(section 15) and ID-nits passes.  Thanks.

-Vach 

-----Original Message-----
From: Serbest, Yetik [mailto:[email-masked]] 
Sent: Wednesday, January 04, 2006 3:39 PM
To: Spencer Dawkins; 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 Everybody,

Happy New Year!

Thanks,

yetik

  _____  

Dear Yetik,

Spencer

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

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

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

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+].

yetik 

  _____  

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

[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.

[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? 

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.

[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.

[yetik+] Will do it.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 4 Jan 2006 18:24:33 -0600

Re: Gen-ART Review of draft-ietf-l2vpn-requirements-05.txtSpencer checked. All the changes are as we discussed (and thanks!)...

Spencer
  ----- Original Message ----- 
  From: Serbest, Yetik 
  To: Spencer Dawkins ; General Area Review Team 
  Cc: Shane Amante ; Vach Kompella ; Mark Townsley ; Russ Housley ; Alex Zinin ; Waldemar Augustyn 
  Sent: Wednesday, January 04, 2006 5:38 PM
  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).

  Thanks,

  yetik

------------------------------------------------------------------------------

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

  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 ; General Area Review Team 

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

    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 

----------------------------------------------------------------------------

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

    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!)

    Spencer

    3.4 VPLS

    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

    Spencer+ - your shorter explanation helps a lot - can you stick it in the
    document? :-) Something like

       Ids cannot overlap. If VLANs are not used as service delimiters, L2VPN

    [Yetik+] I will do it.

    [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

    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? 

    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] The former.

    Spencer+ - suggest "and verify that the SP L2VPN is correctly connected"?

    [Yetik+] I will do it.

    6.4 SLS Support

    Spencer+ - I'd remove it (since this is a requirements draft, but doesn't
    require anything).

    [Yetik+] I will.

    6.7 Security

    [yetik+] Will do it.