[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New communication from the OIF
Hi Lyndon,
I checked here among MEF reps and there are several models: bandwidth
profile per ingress UNI, bandwidth profile per ingress EVC for a UNI,
bandwidth profile per ingress EVC+CE-VLAN CoS tuple. Both untagged and
tagged frames can be supported per EVC. As different bandwidth profiles
could apply for each of the UNIs in an EVC, the bandwidth profile is not
specified on an EVC basis, but as a UNI service attribute. Multiple EVCs
can be supported at a UNI. And a mix of UNIs with different
(physical/service) characteristics for a EVC is allowed. [MEF10] A new
egress profile was added [MEF 10.1].
MEF's EVC, if point-to-point, associates two UNI, or it may be
multi-point (multiple UNIs). And depending if CE-VLAN preservation is
used, the CE-VLAN ID values may only be significant at a given UNI.
The OIF liaison noted OIF was only considering point-to-point, though I
am wondering why? MEF is considering both pt-to-pt and multi-point EVCs.
As I mentioned at the last IETF meeting, it is difficult to understand
the requirement to (one-time) signal a list of VIDs without
understanding the requirements behind it. I can understand that an EVC
may support (possibly;-)) 500 VIDS when bundling. I am not sure this
infers one signaling message per EVC. Service multiplexing, multi-point,
all will have different needs. We may want to consider other
alternatives (l1vpn, call,..) to be able to support the wider MEF
service scope than optimizing for one specific service attribute.
Deborah
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Ong, Lyndon
Sent: Wednesday, March 07, 2007 11:36 AM
To: Adrian Farrel; MEURIC Julien RD-CORE-LAN;
Dimitri.Papadimitriou@alcatel-lucent.be
Cc: ccamp@ops.ietf.org
Subject: RE: New communication from the OIF
Hi Adrian,
I'm not the expert on this, but I think there may be two models at work
here:
- in one model, several originators request resource reservation for
their Ethernet flows
based on the associated Ethernet labels, each with some associated
bandwidth. The receiving
node creates a corresponding tunnel and aggregates these flows into the
tunnel.
- in the second model (which I believe to be the MEF EVC model, although
we're checking
with our MEF 'experts' on this), the originator requests an EVC service,
which has an
associated bandwidth from one edge of the network to another, and can
support within it
several Ethernet flows that share this bandwidth. If there are multiple
EVCs, the
originator uses signaling to identify which labels should be carried in
EVCx and which
should be carried in EVCy - if EVCx carries 200 Ethernet flows, then you
would need to
identify 200 labels as belonging to EVCx. However there is one
transport requirement
for the EVC, not one for each flow.
Cheers,
Lyndon
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; Dimitri.Papadimitriou@alcatel-lucent.be
Cc: ccamp@ops.ietf.org
Subject: Re: New communication from the OIF
Julien, Dimitry,
I, too, read these examples as a desire to perform aggregation of
multiple Ethernet flows into a single managed flow.
My question is, what is wrong with a tunnel construct? Such a
construction, like the label stack in MPLS, is easily available in
Ethernet. Is there a specific reason why the end-to-end labels must be
visible in the data plane in the core of the network?
In this sense, the request for a concatenation of labels is simply so
that multiple labels can be treated in the same way, not (unlike the TDM
case) in order to construct some for of virtual concatenation. If it
were the case that each Ethernet label had a limited amount of bandwidth
associated and it was necessary to clump labels to make a bigger unit of
bandwidth, the case would be different, but that does not apply to
Ethernet AFAIK.
So, still struggling to understand the underlying requirement.
Perhaps it is "simply" the desire to exchange only one Path message
between source and destination when multiple LSPs are formed between the
same pair of end-points. One might argue the same case in L3VPN
deployments.
Adrian
----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <julien.meuric@orange-ftgroup.com>
To: <Dimitri.Papadimitriou@alcatel-lucent.be>; <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF
Hi Dimitri.
If you consider the access network, I agree with you: provisioning would
probably be on a per customer basis. However, when we focus on the
aggregation or the core networks, service establishment could be needed
for a collection of VIDs already in place: as far as I understand, this
is what the MEF defines as a single service carrying several VLANs, and
I believe the OIF would prefer to establish this as a single service
instead of signalling a list of 500 VIDs, especially if end-to-end
recovery is needed some time.
Regards,
Julien
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Dimitri.Papadimitriou@alcatel-lucent.be
adrain, very interesting examples / applications of ethernet LSPs
but in the proposed cases i see more rationales to unbundle than
bundle the VLAN ID in the same Path message
for the VLAN per service i guess we're on the safe path, for the
VLAN per customer the question is simple, are all customers specs
identical and provisioned at the same time ?
thanks,
- d.
"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
28/02/2007 16:16
Please respond to "Adrian Farrel"
To: <ccamp@ops.ietf.org>
cc:
Subject: New communication from the OIF
Hi,
We have received the following communication from the OIF discussing
their
desire to build compound VLAN-ID labels. It would be good to look at the
scenarios they describe to examine what our recommendations are.
All input gratefully received.
As always, all communications can be found through the CCAMP alternate
Web
site at www.olddog.co.uk/ccamp.htm
Regards,
Adrian
====
February 27, 2007
To: Adrian Farrel, adrian@olddog.co.uk and Deborah Brungard,
dbrungard@att.com,
IETF CCAMP WG co-chairs
From: Jim Jones, OIF Technical Committee Chair
Subject: Further Information Regarding VLAN ID Requirements
Dear Adrian and Deborah,
It is our understanding that CCAMP members requested more information to
understand the requirements we have identified for carrying or
indicating
large numbers of VLAN IDs in the Label objects in control signaling
messages
for Ethernet connections with frame switching granularity. This issue is
more fully described in the attached excerpt from our liaison to CCAMP
on
October 2006.
Accordingly, our carrier WG has developed a small set of illustrative
scenarios as attached, for CCAMP's review and information.
We would be strongly interested in CCAMP's conclusions on how these
scenarios can be supported using existing GMPLS methods or if any
further
definition might be required.
Best regards,
Jim Jones
OIF Technical Committee Chair
Attachments:
1) Excerpt from OIF Liaison to IETF CCAMP of October 2006
2) oif2007.056 - Illustrative Scenarios of VLAN ID Use
cc: Bill Fenner and Ross Callon, IETF Routing Area Directors
Lyndon Ong, OIF TC Vice Chair
Evelyne Roch, OIF Interoperability Working Group Chair
Jonathan Sadler, OIF Architecture & Signaling Working Group Chair