RE: New communication from the OIF

[Dimitri.Papadimitriou@alcatel-lucent.be]

lyndon

o) first you will observe that the doc. MEF traffic parameters does not 
speak about "label distribution" 

reason: you will observe (by section 3.4 of RFC 3209) that label per 
sender (shared reservation or not) and label per link reservation 
(de-facto shared) are possible

hence the usage of RSVP-TE traffic parameters result also in using these 
rules (i will add a statement to make this clearer in the next release) 
but remember the doc does not define any "label" format for MEF purposes

o) second you will observe that the document does not infer any "VID" to 
EVC relationship, noticing that single CoS and multiple CoS per EVC are 
covered in the draft, and this, independently of the number of VIDs per 
EVC 

o) third closing the loop, the draft is not inferring any "label" to "VID" 
relationship (that relationship when equating an EVC with single or 
multiple CoS to an RSVP session is straightforward) 

the questions are thus the following

1. to which entity the traffic parameters are applied in case of a single 
EVC with multiple VIDs ? if you are following the reasoning since so far 
it should be per EVC (for the set of VIDs) 

note: per EVC+VID taken individually requires separate signaling otherwise 
you need a list of tspecs and a list of label + correspondance and this is 
another protocol, in fact boiling down to a simple relationship 

2. what is the "label" value(s) in this case ? using the set of VIDs to 
represent a "reservation" at the control plane level is completely useless 
as the control plane doesn't need this info to create PSB/RSB and the 
entity to which the reservation is associated is the "EVC" ... so you will 
need to find a unique per-EVC characteristic when the 1:1 relationship 
between label and EVC is limitative e.g. a bundle index or so (something 
that boils you down to a 1:1 relationship because indepedently of the 
"protocol" being explicit in the enumeration IS cumbersome)

 thanks,
-d.




"Ong, Lyndon" <Lyong@Ciena.com>
Sent by: owner-ccamp@ops.ietf.org
08/03/2007 00:28
 
        To:     "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>, 
"Adrian Farrel" <adrian@olddog.co.uk>, "MEURIC Julien RD-CORE-LAN" 
<julien.meuric@orange-ftgroup.com>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <ccamp@ops.ietf.org>
        Subject:        RE: New communication from the OIF


Hi Deborah,

That's great that you talked to your MEF reps, I think it confirms my
previous email:

- there are, as you say, several models allowed in the MEF spec.  One
model does
allow bundling of many (possibly hundreds or thousands) of VIDs in one
EVC, which 
causes a problem if you are 
attempting to control the EVC with an RSVP session.  The original
liaison was not
intended, I think, to restrict the models supported, but to identify a
case 
where it was not clear how you would do the signaling, where the case
was of particular
interest to some of the carrier members of OIF.

- perhaps multiple messages could be a solution.  If so, it would be
helpful to 
understand how this would work - any solutions coming out of CCAMP would
be
very welcome. 

- not sure if there is an issue on point-to-multipoint, we were just
trying to 
address one issue at a time, I think.

Now that we hopefully have a better understanding of the underlying
motivations,
hopefully we can make some further progress on a solution :o)

Cheers,

Lyndon

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com] 
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; 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 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