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

From: "Amante, Shane" <[email-masked]>
Date: Thu, 5 Jan 2006 07:19:38 -0700

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 [mailto:[email-masked]] 
	Sent: Wednesday, January 04, 2006 5:25 PM
	To: Serbest, Yetik; 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 

	Spencer checked. All the changes are as we discussed (and
thanks!)...
	 
	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: 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).

		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: "Spencer Dawkins" <[email-masked]>
Date: Thu, 5 Jan 2006 08:39:47 -0600

Re: Gen-ART Review of draft-ietf-l2vpn-requirements-05.txtI'm fine with Shane's suggestion for 4.6, just for Brian's benefit...

Spencer
  ----- Original Message ----- 
  From: Amante, Shane 
  To: Spencer Dawkins ; Serbest, Yetik ; General Area Review Team 
  Cc: Vach Kompella ; Mark Townsley ; Russ Housley ; Alex Zinin ; Waldemar Augustyn 
  Sent: Thursday, January 05, 2006 8:19 AM
  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?  

  Thanks!

  -shane

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

    Spencer 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

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

      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,

      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 

        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 

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

        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? 

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