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

From: "Serbest, Yetik" <[email-masked]>
Date: Thu, 22 Dec 2005 16:48:56 -0600

Hi Spencer,

Thanks for the great review. Please find my comments in-line.

Thanks,
yetik

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

I was selected as General Area Review Team reviewer for this
specification (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Summary: This document is on the right track for publication as an 
Informational RFC, but some work remains. Most of the comments I list
below 
are nits, but the comments on 3.4, 4.6, and 6.10 are probably worth some

attention after Last Call.

Thanks, and good luck with your document!

Spencer Dawkins

2.1 Scope of this document

   The technical specifications to provide L2VPN services are outside
   the scope of this document.  The framework document [L2VPN_FR] and
   several documents, which explain technical approaches providing L2VPN
   services, are available to cover this aspect.

Spencer: "and several documents" without citations seems hand-waveish...

[Yetik] The idea was to not cite solution documents as solutions should
come after the requirement. But, I propose to change it as follows:

   The technical specifications to provide L2VPN services are outside
   the scope of this document.  The framework document [L2VPN_FR] and
   several documents, which explain technical approaches providing L2VPN
   services such as [VPLS-BGP], [VPLS-LDP], and [IPLS], are available to
cover this aspect.

3.2 Taxonomy of L2VPN Types

   The following diagram shows a L2VPN reference model.

Spencer: citation for this "reference model" would be nice. It would
also be 
nice to say "L2VPN A in this diagram shows VPLS, L2VPN B shows VPWS" -
"In 
Figure 1, L2VPN B represents a VPWS case" does appear later in the
document, 
but it's buried at the end of a paragraph, and I can't find "L2VPN A 
represents a VPLS" anywhere in the document.

[Yetik] Thanks for the catch. We will replace "The CE sees a bridge" by
"In Figure 1, L2VPN A represents a VPLS".

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.

4.1 Scope of emulation

   Some possibly salient differences between VPLS and a real LAN are:
     - VPLS frames can get duplicated if the PW sequencing option isn't
     turned on.  The data frames on the PWs are sent in IP datagrams,
     and under certain failure scenarios, IP networks can duplicate
     packets.  If the PW data transmission protocol does not ensure
     sequence of data packets, frames can be duplicated or received out
     of sequence.  If the customer's Bridge Protocol Data Unit (BPDU)
     frames are sent as data packets, then BPDU frames can be duplicated
     or mis-sequenced.

Spencer: it may be worth mentioning that some of the prohibitions
against 
out-of-order delivery, etc. during spanning tree recalculation were
relaxed 
when IEEE defined RTSP, so VPLSes that duplicate or mis-sequence frames 
during spanning tree recalculation may not be all that different from
real 
LANs.

[Yetik] I will change the paragraph as follows (I am assuming you meant
RSTP):
     "- VPLS frames can get duplicated if the PW sequencing option isn't
     turned on.  The data frames on the PWs are sent in IP datagrams,
     and under certain failure scenarios, IP networks can duplicate
     packets.  If the PW data transmission protocol does not ensure
     sequence of data packets, frames can be duplicated or received out
     of sequence.  If the customer's Bridge Protocol Data Unit (BPDU)
     frames are sent as data packets, then BPDU frames can be duplicated
     or mis-sequenced, although this may not create any problems for
RTSP"

   - Since the IPLS solution aims at transporting encapsulated traffic
     (rather than Layer 2 frames themselves), the IPLS solution is NOT
     REQUIRED to preserve the Layer 2 Header transparently from CE to
     CE.  For example, Source MAC address may not be preserved by the
     IPLS solution.

Spencer: s/may not be/will probably not be/? "may not be" seems to say
that 
the lack of transparency is the exception in IPLS, but I would expect it
to 
be the rule.

[Yetik] I will make the change accordingly.

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.

4.9 Protection and Restoration
   The L2VPN service infrastructure SHOULD provide redundant paths to
   assure high availability.  The reaction to failures SHOULD result in
   an attempt to restore the service using alternative paths.

Spencer: well, at least this isn't a MUST... My impression is that
customers 
who care about redundant paths usually care about spreading the paths
across 
SPs as well - but I guess SPs in this situation don't have to provide 
redundant paths, if customers are prepared to switch SPs on failure 
detection anyway. Mumble. Forget I said anything...

   The intention is to keep the restoration time small.  The restoration
   time MUST be less than the time it takes the CE devices, or customer
   Layer 2 control protocols as well as Layer 3 routing protocols, to
   detect a failure in the L2VPN.

5.2 Layer 3 Support

   IPLS MUST allow transport of customer's IPv4 and IPv6 traffic
   encapsulated within Layer 2 frames.  IPLS SHOULD also allow CEs to
   run ISIS and MPLS protocols transparently among them when those are
   used in conjunction with IP.

Spencer: not sure I understood why ISIS and MPLS are called out, while
OSPF 
(and, I guess, BGP and even RIPv2) are not.

[Yetik] Because they are not IP. IPLS is IP-only solution. ISIS (MPLS
too) are used very common in IP networks, and IPLS solution should not
ignore them.

5.3 Quality of Service and Traffic Parameters

   A customer application SHOULD experience consistent QoS independent
   of the access network technology used at different sites connected to
   the same L2VPN.

Spencer: umm, given that 802.3 supports various access link speeds, is
QoS 
really technology-independent? 5.6.1 seems more realistic on this topic.

[Yetik] My take on this is as follows: One site can be Ethernet with
802.1p marking, another site can be ATM (bridged mode) with 8 QoS
classes. Still, the QoS performance should match, by doing right mapping
etc...

5.6.1  Physical/Link Layer Technology
   L2VPNs SHOULD support a broad range of physical and link layer access
   technologies, such as PSTN, ISDN, xDSL, cable modem, leased line,
   Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop,
   mobile radio access, etc.  The capacity and QoS achievable MAY be
   dependent on the specific access technology in use.

Spencer: s/L2VPNs SHOULD/L2VPN solutions SHOULD/?

[Yetik] Will do.

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.

5.7.1  Unicast, Unknown Unicast, Multicast, and Broadcast forwarding
   A VPLS MUST deliver every packet at least to its intended
   destination(s) within the scope of the VPLS, subject to the ingress
   policing and security policies.

Spencer: "intended" probably needs to be qualified - something like, "at

least to the same destinations within the scope of the VPLS that the
packet 
would have been delivered to, if the VPLS were replaced by a real LAN"?

[Yetik] There was a discussion about this in design team as well. Here
is what Norm said back then.

"To second some of Matt's comments (Matt Squire, that is), especially
MBS9, section 5.7.1 is too restrictive.  Bridges regularly violate every
one of the MUSTs in this section.  For example, they preclude installing
access lists on behalf of the customer.  Perhaps more to the point, they
preclude IGMP proxying.
A simple "MUST deliver every packet to at least those destinations which
need to receive it" might suffice.  That was the best that Link
Aggregation could come up with, when dealing with similar problems
regarding packet ordering."

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.

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.

5.7.4  End-point VLAN tag translation
   On the
   other hand, it SHOULD be noted that VLAN tag translation affects the
   support for multiple spanning trees (i.e., 802.1s [IEEE_802.1s]) and
   can break the proper operation.

Spencer: this is not a 2119 SHOULD, I think...
[Yetik] Agree. Will change.

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.

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. 

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.

6.10 Tunneling Requirements
   Connectivity between CE sites or PE devices in the backbone SHOULD be
   able to use a range of tunneling technologies, such as L2TP, GRE, IP-
   in-IP, MPLS, etc.

Spencer: is there a mandatory-to-implement technology? this seems
required 
for interworking...

[Yetik] This requirement states that a solution should be tunneling
technology agnostic. It is not an inter-working requirement.

6.11 Support for Access Technologies
   The connectivity between PE and CE devices is referred to as an AC.
   ACs MAY span networks of other providers or public networks.

Spencer: "AC" has been used previously without definition, and is not 
expanded in this definition. 
[Yetik] The definition is in the terminology RFC. Will refer to it and
also will change to "Attachment Circuit (AC)".

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 23 Dec 2005 11:45:32 -0600

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

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.

4.6 Addressing

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] 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? (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"

[Yetik] The former.

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

6.4 SLS Support

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

6.7 Security

Spencer+ - that would be clearer, I think - thanks!

---

From: "Serbest, Yetik" <[email-masked]>
Date: Fri, 23 Dec 2005 14:05:39 -0600

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,

Spencer

3.4 VPLS

[Yetik+] Exactly.

4.6 Addressing

[Yetik+] I will do it.

[Yetik] That is correct.

[Yetik+] Great suggestion.

5.7.2  Packet Re-ordering

[Yetik+] Again great suggestion.

5.7.3  Minimum MTU

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. 

[Yetik+] I like your suggestion.

[Yetik] The former.

[Yetik+] I will do it.

6.4 SLS Support

[Yetik+] I will.

6.7 Security

[yetik+] Will do it.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 23 Dec 2005 17:37:32 -0600

Re: Gen-ART Review of draft-ietf-l2vpn-requirements-05.txtDear 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 ; General Area Review Team 
  Cc: Shane Amante ; Vach Kompella ; Mark Townsley ; Russ Housley ; Alex Zinin ; Waldemar Augustyn 
  Sent: Friday, December 23, 2005 2:05 PM
  Subject: RE: Gen-ART Review of draft-ietf-l2vpn-requirements-05.txt 

  Hi Spencer,

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

  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.