Subject: RE: Layer 2 Switching Caps LSPs

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Thu, 3 Feb 2005 12:16:22 -0600

Dimitri,

Can the off-line discussion be summarized for the benefit of those on
the list who did not participate?  For me, the draft (and the current
discussion on the list) have not clearly articulated the problem being
addressed.  If a summary of the conclusions of the off-line discussion
will do this, it would be useful.

I am also interested to know what is lacking in the current GMPLS RFCs
with respect to ATM and Frame Relay support that necessitates including
them in this new draft (presumably this is a part of the problem to be
solved).

Regards,
Ben

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of dimitri papadimitriou
> Sent: Thursday, January 27, 2005 6:35 PM
> To: David Allan
> Cc: 'Adrian Farrel'; 'Shahram Davari'; [email-masked]
> Subject: Re: Layer 2 Switching Caps LSPs
> 
> dave - there was a lengthy off-line discussion suggested by the chairs
> intended to explain you the scope of the draft and its relatioship
with
> the ethernet data plane (after the question you raised during the f2f
> meeting) - this has been done and we have explained (via a lengthy
> exchange of e-mails) that this document and so the use of gmpls to
> control ethernet frame flows, is not targeting control of bridged
> ethernet environments - if this is not clear from the current document
> introduction we would have also to work on this part of the document -
> therefore, the below reference to MSTP is not in the current scope; on
> the other side, the use of the term "VLAN label" has created some
> confusion; therefore, in a next release i will simply refer to a
"label"
> of 32 bits (unstructured) because the intention was (and still is) to
> find an easy way to map the control of the ethernet frame flows on
each
> device they traverses without making any assumption on how this flow
is
> processed inside each node at the data plane level (note: on label
> values, RFC 3946 took an equivalent approach - for circuits - where
> sonet/sdh multiplexing structures have been used to create unique
> multiplex entry names i.e. labels - this concept is here applied for
> "virtual" circuits), so, if the working group is willing to enter into
a
> data plane oriented discussion to clarify the behaviour(s) onto which
> the present approach would be potentially applicable this is fine with
> me as long as we are within the scope of the initial motivations
> 
> thanks,
> - dimitri.
> 
> David Allan wrote:
> > Hi Adrian:
> >
> > Your suggestion is in a way reasonable but with the caveat that in
IEEE
> > terms, a bridging topology is currently all VLANs (802.1Q single
> spanning
> > tree) or partitioned into specific ranges (I believe 64 in 802.1s
> although I
> > do not claim to be an expert).
> >
> > If the PEs were to implement a bridge function and we were using
GMPLS
> to
> > interconnect them, then the control plane should be identifying
either
> all
> > VLANs (single spanning tree, which I beleive the draft covers by
> referring
> > simply to Ethernet port) or a VLAN range to be associated with the
LSP
> > consistent with 802.1s if it is to operate to interconnect bridges
> defined
> > by the IEEE...
> >
> > I suspect assuming any other behavior (e.g. LSP for single VLAN tag)
> would
> > go outside the boundary of what is currently defined...so alignment
with
> > 802.1s IMO would be a minimum requirement if we are to consider
carrying
> > VLAN information in GMPLS signalling....
> >
> > cheers
> > Dave
> >
> > You wrote....
> >
> >>Hi,
> >>
> >>The authors of the draft might like to clarify for the list
> >>exactly what data plane operations they are suggesting. To me
> >>it seems possible that the draft is proposing VLAN ID
> >>*swapping*. But an alternative is that the VLAN ID is used as
> >>a label, but that the same label is used for the full length
> >>of the LSP.
> >>
> >>Adrian
> >
> >
> >
> > .
> >
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

---

From: [email-masked]
Date: Thu, 3 Feb 2005 21:07:00 +0100

ben,

the discussion with dave has been reproduced in accelerated on the mailing list - for me it appears that the more "philosophical" conclusion can be positioned by answering to the following question "Was SONET/SDH or lambda switching initially intended to be controlled by GMPLS ?" if the response is "No, but nothing prevents to do so" the next question is what does prevent from applying GMPLS to other technologies knowing a substantial gain is obtained from its application - in certain conditions - (see motivations as part of this introduction for instance) ? key issue being which are these (technical) conditions and are there conditions that would preclude progressing this document - the response is simply the negative - there are no such conditions in the point-to-point - non-bridging - context where this document applies.

now, not sure there is a technical "firm" conclusion but the point on the ethernet label encoding appears as follows since so far there is potential interest to keep the label for ethernet generic enough and deduce its interpretation from type of link over which the label is used and intepreet its value according to the traffic_parameters and propose associations to cover cases such as case 2 of Appendix A of <draft-pwe3-ethernet-encap-08.txt> mechanisms that is also applicable to other tunneling technology since this mechanism is orthogonal to the use of PW's if required (example being Ethernet over SDH/OTH, for instance); however, if these are the only associations we see relevant as part of this document then we would fall back on the existing encoding with potential enhancement if so required -

to come to the point of the articulation the - generic - response holds in one line: it articulates GMPLS signaling for L2SC LSPs (note: the latter has been introduced in RFC 3945, RFC 3471, RFC 3473) - the motivations are detailed as part of the introduction of this document - i can not comment more from your initial statement since not detailed enough for me to be more specific

the response to the last question is relatively simple since the above mentioned do not include any specifics concerning ATM or FR - this document intends to close this gap by defining specific Traffic_Parameters for these technologies - is there an interest for doing so: response is yes otherwise the document would not have included the corr. details

voila, thanks,

- dimitri.

"Mack-Crane, T. Benjamin" <[email-masked]>
Sent by: [email-masked]
02/03/2005 12:16 CST

To: <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" <[email-masked]>
cc: "Adrian Farrel" <[email-masked]>, "Shahram Davari" <[email-masked]>, <[email-masked]>
bcc:
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri,

Regards,
Ben

Behalf
with
"label"
each
is
a
IEEE
GMPLS
either
LSP
with
carrying

---

From: Shahram Davari <[email-masked]>
Date: Thu, 3 Feb 2005 13:13:23 -0800

Dimitri,
 
Unfortunately I didn't grasp completely what you are trying to convey. But one thing I know for sure, and that is  "Ethernet is Connectionless (CLS)" (like IP) and assumes shared medium, while GMPLS is connection-oriented (CO) and doesn't work in shared medium. Off course you could always configure and build an Ethernet network that looks like it is CO (by configuring a max of 2 ports with the same VLAN ID in each bridge), and by not using any shared medium. But then who needs GMPLS, when you already have to configure your network by other means?
 
-Shahram

 From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 03, 2005 3:07 PM
To: Mack-Crane, T. Benjamin
Cc: [email-masked]; [email-masked]; David Allan; Adrian Farrel; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

ben, 

voila, thanks,

- dimitri.

Dimitri,

Regards,
Ben

Behalf
with
"label"
each
is
a
IEEE
GMPLS
either
LSP
with
carrying

---

From: [email-masked]
Date: Thu, 3 Feb 2005 23:30:56 +0100

sharam, the first issue is that you have to decouple the notion of ethernet with bridging, the second is that this configuration operation can be automated - however the interesting point you brought in the loop of discussion here is "applicability for shared medium" - isn't the PW solution in the same context as 1) it can not make an automated usage of a "medium" without configuring the tunnels (in our case the tunnels that will be used to carry the ethernet payload e.g. SDH, OTH, etc. if not using point-to-point PHY's) but in addition to the present solution PW also requires 2) the provisioning of the PW - something not needed in the present context as terminating points will be directly accessing the "ethernet medium", in brief if such argument is used here it should have also been used in the PW context (if not more intensively)

another fundamental point, i am also surprised seeing people supporting MPLS (which brings a connection-oriented behaviour to IP) wondering about the suitability of using one of the protocol suite of the IETF i.e. GMPLS to bring another (initially) connectionless technology to a "connection-oriented" behaviour (even if i do rather prefer the term flow, in the present context) at the end the resulting gain is the same for both technologies it terms of capabilities as application of constraint-based routing principles - is this not at the end what drives mostly all debates in the (G)MPLS galaxy beside VPNs and that was underlying incorporation of these L2 technologies as part of the GMPLS protocol architecture

thanks,

- dimitri.

Shahram Davari <[email-masked]>
Sent by: [email-masked]
02/03/2005 13:13 PST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T. Benjamin" <[email-masked]>
cc: [email-masked], David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
bcc:
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri,

-Shahram

ben,

voila, thanks,

- dimitri.

Dimitri,

Regards,
Ben

Behalf
with
"label"
each
is
a
IEEE
GMPLS
either
LSP
with
carrying

---

From: Shahram Davari <[email-masked]>
Date: Thu, 3 Feb 2005 15:37:19 -0800

Dimitri,
 
I have another question. As you know there are only 4094 VLANs (12 bit). This means only 4094 P2P connection could be setup using GMPLS. Since this is not scalable, presumably you need a multiplexing label (such as MPLS or another VLAN tag), and its associated signaling between two edges of the network. So why not use PW and be done with it.
 
-Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shahram Davari
Sent: Thursday, February 03, 2005 6:19 PM
To: [email-masked]'
Cc: Mack-Crane, T. Benjamin; [email-masked]; David Allan; Adrian Farrel; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

Hi Dimitri,
 
Thanks for your response. Please see my comments in-line.
 
-Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 03, 2005 5:31 PM
To: Shahram Davari
Cc: [email-masked]'; Mack-Crane, T. Benjamin; [email-masked]; David Allan; Adrian Farrel; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

sharam, the first issue is that you have to decouple the notion of ethernet with bridging, 

Ethernet networks have 3 main layers: 

1) PHY = 10/100/1G/10G as explained in 802.3, 

2) MAC = 802.3

3) Bridging = 802.1D

Without Bridging layer your device can only have a single port. Example is the Ethernet port of your desktop computer. Therefore if you want to build an Ethernet network, you need bridging layer.

  the second is that this configuration operation can be automated - 

But after you have configured your connections (aka VLAN ports), then there is nothing left for GMPS to do. Or are you saying that the GMPLS will do the configuration?

  however the interesting point you brought in the loop of discussion here is "applicability for shared medium" - isn't the PW solution in the same context 

No, because in PW, the payload (Ethernet) is encapsulated in another layer network (aka MPLS), and is invisible to the intermediate nodes. While in your case there is no encapsulation, and all the intermediate nodes can act on the MAC and VLAN tag.

  as 1) it can not make an automated usage of a "medium" without configuring the tunnels (in our case the tunnels that will be used to carry the ethernet payload e.g. SDH, OTH, etc. if not using point-to-point PHY's) but in addition to the present solution PW also requires 2) the provisioning of the PW - something not needed in the present context as terminating points will be directly accessing the "ethernet medium", in brief if such argument is used here it should have also been used in the PW context (if not more intensively)

another fundamental point, i am also surprised seeing people supporting MPLS (which brings a connection-oriented behaviour to IP) wondering about the suitability of using one of the protocol suite of the IETF i.e. GMPLS to bring another (initially) connectionless technology to a "connection-oriented" behaviour 

I don't argue against bringing connection-oriented behavior to Ethernet. My concern is the method used to do so. if you had done proper Network Interworking (aka, encapsulation or as ITU calls it client/server), then there would not be any problem. However, what you are trying to do is to modify Ethernet's control-plane in a way that requires modification to its data-plane behavior. As an analogy what you are doing is like trying to use the IP address as MPLS tag in order to make IP connection-oriented.

In contrast you could easily change ATM's control-plane to GMPLS without any modification to ATM data-plane behavior, because ATM by design is connection-oriented, and the VPI/VCI could easily be interpreted as GMPLS tags.

  (even if i do rather prefer the term flow, in the present context) at the end the resulting gain is the same for both technologies it terms of capabilities as application of constraint-based routing principles - is this not at the end what drives mostly all debates in the (G)MPLS galaxy beside VPNs and that was underlying incorporation of these L2 technologies as part of the GMPLS protocol architecture

thanks,

- dimitri.

Dimitri,

-Shahram

ben, 

voila, thanks,

- dimitri.

Dimitri,

Regards,
Ben

Behalf
with
"label"
each
is
a
IEEE
GMPLS
either
LSP
with
carrying

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Feb 2005 06:43:51 -0800

Dimitri,

> From: dimitri papadimitriou [mailto:[email-masked]]
> Sent: Thursday, February 03, 2005 10:38 PM
> To: Shahram Davari
> Cc: [email-masked]'; Mack-Crane, T. Benjamin; David
> Allan; Adrian Farrel; [email-masked]
> sharam, as said in my previous mail the "vlan mode" is 
> intended to be a 
> refinment of the "port mode", you have 4096 VLANs per port, taking a 
> 10Gbps interface this leads you to a granularity of about 2.5 
> Mbps (but 
> also keep in mind that there are two levels of VLANs defined today so 
> further refinment is still possible) and with 16 ports you would have 
> 64k LSPs not that bad for an unscalable solution ;-)

I think we have a disconnect here. Could you please explain how you could
reuse the VLAN IDs in a single switch for different LSPs? 

> 
> note: i have explained in a previous mail where use of PW makes more 
> sense and where it does less, and where it does simply not
> 
> Shahram Davari wrote:
> > Dimitri,
> > 
> > I have another question. As you know there are only 4094 VLANs (12
> > bit). This means only 4094 P2P connection could be setup 
> using GMPLS.
> > Since this is not scalable, presumably you need a multiplexing label
> > (such as MPLS or another VLAN tag), and its associated signaling
> > between two edges of the network. So why not use PW and be done with
> > it.
> > 
> > -Shahram
> > 
> > -----Original Message----- From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Shahram Davari Sent:
> > Thursday, February 03, 2005 6:19 PM To:
> > [email-masked]' Cc: Mack-Crane, T. Benjamin;
> > [email-masked]; David Allan; Adrian Farrel;
> > [email-masked] Subject: RE: Layer 2 Switching Caps LSPs
> > 
> > 
> > Hi Dimitri,
> > 
> > -----Original Message----- From: [email-masked]
> > [mailto:[email-masked]] Sent: Thursday, February
> > 03, 2005 5:31 PM To: Shahram Davari Cc:
> > [email-masked]'; Mack-Crane, T. Benjamin;
> > [email-masked]; David Allan; Adrian Farrel;
> > [email-masked] Subject: RE: Layer 2 Switching Caps LSPs
> > 
> > 
> > 
> > Without Bridging layer your device can only have a single port.
> > Example is the Ethernet port of your desktop computer. Therefore if
> > you want to build an Ethernet network, you need bridging layer.
> > 
> > 
> > 
> > But after you have configured your connections (aka VLAN 
> ports), then
> > there is nothing left for GMPS to do. Or are you saying that the
> > GMPLS will do the configuration?
> > 
> > however the interesting point you brought in the loop of discussion
> > here is "applicability for shared medium" - isn't the PW solution in
> > the same context
> > 
> > No, because in PW, the payload (Ethernet) is encapsulated in another
> > layer network (aka MPLS), and is invisible to the 
> intermediate nodes.
> > While in your case there is no encapsulation, and all the
> > intermediate nodes can act on the MAC and VLAN tag.
> > 
> > as 1) it can not make an automated usage of a "medium" without
> > configuring the tunnels (in our case the tunnels that will 
> be used to
> > carry the ethernet payload e.g. SDH, OTH, etc. if not using
> > point-to-point PHY's) but in addition to the present 
> solution PW also
> > requires 2) the provisioning of the PW - something not needed in the
> > present context as terminating points will be directly accessing the
> > "ethernet medium", in brief if such argument is used here it should
> > have also been used in the PW context (if not more intensively)
> > 
> > another fundamental point, i am also surprised seeing people
> > supporting MPLS (which brings a connection-oriented behaviour to IP)
> > wondering about the suitability of using one of the 
> protocol suite of
> > the IETF i.e. GMPLS to bring another (initially) connectionless
> > technology to a "connection-oriented" behaviour
> > 
> > I don't argue against bringing connection-oriented behavior to
> > Ethernet. My concern is the method used to do so. if you had done
> > proper Network Interworking (aka, encapsulation or as ITU calls it
> > client/server), then there would not be any problem. However, what
> > you are trying to do is to modify Ethernet's control-plane in a way
> > that requires modification to its data-plane behavior. As an analogy
> > what you are doing is like trying to use the IP address as MPLS tag
> > in order to make IP connection-oriented.
> > 
> > In contrast you could easily change ATM's control-plane to GMPLS
> > without any modification to ATM data-plane behavior, because ATM by
> > design is connection-oriented, and the VPI/VCI could easily be
> > interpreted as GMPLS tags.
> > 
> > (even if i do rather prefer the term flow, in the present 
> context) at
> > the end the resulting gain is the same for both 
> technologies it terms
> > of capabilities as application of constraint-based routing 
> principles
> > - is this not at the end what drives mostly all debates in the
> > (G)MPLS galaxy beside VPNs and that was underlying incorporation of
> > these L2 technologies as part of the GMPLS protocol architecture
> > 
> > thanks,
> > 
> > - dimitri.
> > 
> > 
> > Shahram Davari <[email-masked]> Sent by:
> > [email-masked] 02/03/2005 13:13 PST
> > 
> > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T.
> > Benjamin" <[email-masked]> cc: [email-masked],
> > David Allan <[email-masked]>, Adrian Farrel
> > <[email-masked]>, [email-masked] bcc: Subject: RE: Layer 2
> > Switching Caps LSPs
> > 
> > 
> > 
> > 
> > Dimitri,
> > 
> > Unfortunately I didn't grasp completely what you are trying to
> > convey. But one thing I know for sure, and that is  "Ethernet is
> > Connectionless (CLS)" (like IP) and assumes shared medium, while
> > GMPLS is connection-oriented (CO) and doesn't work in shared medium.
> > Off course you could always configure and build an Ethernet network
> > that looks like it is CO (by configuring a max of 2 ports with the
> > same VLAN ID in each bridge), and by not using any shared 
> medium. But
> > then who needs GMPLS, when you already have to configure 
> your network
> > by other means?
> > 
> > -Shahram
> > 
> > 
> > From: [email-masked]
> > [mailto:[email-masked]] Sent: Thursday, February
> > 03, 2005 3:07 PM To: Mack-Crane, T. Benjamin Cc:
> > [email-masked]; [email-masked]; David
> > Allan; Adrian Farrel; Shahram Davari; [email-masked] 
> Subject: RE:
> > the discussion with dave has been reproduced in accelerated on the
> > mailing list - for me it appears that the more "philosophical"
> > conclusion can be positioned by answering to the following question
> > "Was SONET/SDH or lambda switching initially intended to be
> > controlled by GMPLS ?" if the response is "No, but nothing prevents
> > to do so" the next question is what does prevent from applying GMPLS
> > to other technologies knowing a substantial gain is 
> obtained from its
> > application - in certain conditions - (see motivations as part of
> > this introduction for instance) ? key issue being which are these
> > (technical) conditions and are there conditions that would preclude
> > progressing this document - the response is simply the negative -
> > there are no such conditions in the point-to-point - non-bridging -
> > context where this document applies.
> > 
> > now, not sure there is a technical "firm" conclusion but 
> the point on
> > the ethernet label encoding appears as follows since so far there is
> > potential interest to keep the label for ethernet generic enough and
> > deduce its interpretation from type of link over which the label is
> > used and intepreet its value according to the traffic_parameters and
> > propose associations to cover cases such as case 2 of Appendix A of
> > <draft-pwe3-ethernet-encap-08.txt> mechanisms that is also 
> applicable
> > to other tunneling technology since this mechanism is orthogonal to
> > the use of PW's if required (example being Ethernet over 
> SDH/OTH, for
> > instance); however, if these are the only associations we see
> > relevant as part of this document then we would fall back on the
> > existing encoding with potential enhancement if so required -
> > 
> > to come to the point of the articulation the - generic - response
> > holds in one line: it articulates GMPLS signaling for L2SC LSPs
> > (note: the latter has been introduced in RFC 3945, RFC 3471, RFC
> > 3473) - the motivations are detailed as part of the introduction of
> > this document - i can not comment more from your initial statement
> > since not detailed enough for me to be more specific
> > 
> > the response to the last question is relatively simple since the
> > above mentioned do not include any specifics concerning ATM or FR -
> > this document intends to close this gap by defining specific
> > Traffic_Parameters for these technologies - is there an interest for
> > doing so: response is yes otherwise the document would not have
> > included the corr. details
> > 
> > voila, thanks,
> > 
> > - dimitri.
> > 
> > 
> > 
> > 
> > 
> > "Mack-Crane, T. Benjamin" <[email-masked]> Sent by:
> > [email-masked] 02/03/2005 12:16 CST
> > 
> > To: <[email-masked]>, Dimitri
> > PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan"
> > <[email-masked]> cc: "Adrian Farrel"
> > <[email-masked]>, "Shahram Davari"
> > <[email-masked]>, <[email-masked]> bcc: Subject:
> > RE: Layer 2 Switching Caps LSPs
> > 
> > 
> > Dimitri,
> > 
> >  the list who did not participate?  For me, the draft (and the
> > current discussion on the list) have not clearly articulated the
> > problem being addressed.  If a summary of the conclusions of the
> > off-line discussion will do this, it would be useful.
> > 
> > I am also interested to know what is lacking in the current GMPLS
> > RFCs with respect to ATM and Frame Relay support that necessitates
> > including them in this new draft (presumably this is a part of the
> > problem to be solved).
> > 
> > Regards, Ben
> > 
> > 
> >> -----Original Message----- From: [email-masked]
> >> [mailto:[email-masked]] On
> > 
> > Behalf
> > 
> >> Of dimitri papadimitriou Sent: Thursday, January 27, 2005 6:35 PM 
> >> To: David Allan Cc: 'Adrian Farrel'; 'Shahram Davari';
> >> [email-masked] Subject: Re: Layer 2 Switching Caps LSPs
> >> 
> >> dave - there was a lengthy off-line discussion suggested by the
> >> chairs intended to explain you the scope of the draft and its
> >> relatioship
> > 
> > with
> > 
> >> the ethernet data plane (after the question you raised during the
> >> f2f meeting) - this has been done and we have explained (via a
> >> lengthy exchange of e-mails) that this document and so the use of
> >> gmpls to control ethernet frame flows, is not targeting control of
> >> bridged ethernet environments - if this is not clear from the
> >> current document introduction we would have also to work on this
> >> part of the document - therefore, the below reference to MSTP is
> >> not in the current scope; on the other side, the use of the term
> >> "VLAN label" has created some confusion; therefore, in a next
> >> release i will simply refer to a
> > 
> > "label"
> > 
> >> of 32 bits (unstructured) because the intention was (and still is)
> >> to find an easy way to map the control of the ethernet frame flows
> >> on
> > 
> > each
> > 
> >> multiplex entry names i.e. labels - this concept is here applied
> >> for "virtual" circuits), so, if the working group is willing to
> >> enter into
> > 
> > a
> > 
> >> data plane oriented discussion to clarify the behaviour(s) onto
> >> which the present approach would be potentially applicable this is
> >> fine with me as long as we are within the scope of the initial
> >> motivations
> >> 
> >> thanks, - dimitri.
> >> 
> >> David Allan wrote:
> >> 
> >>> Hi Adrian:
> >>> 
> >>> cheers Dave
> >>>> *swapping*. But an alternative is that the VLAN ID is used as a
> >>>> label, but that the same label is used for the full length of
> >>>> the LSP.
> >>>> 
> >>>> Adrian
> >>> 
> >>> 
> >>> 
> >>> .
> >>> 
> > 
> > ============================================================ The
> > information contained in this message may be privileged and
> > confidential and protected from disclosure. If the reader of this
> > message is not the intended recipient, or an employee or agent
> > responsible for delivering this message to the intended recipient,
> > you are hereby notified that any reproduction, dissemination or
> > distribution of this communication is strictly prohibited. If you
> > have received this communication in error, please notify us
> > immediately by replying to the message and deleting it from your
> > computer. Thank you. Tellabs

---

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Fri, 4 Feb 2005 09:22:14 -0600

Dimitri,

See in-line below.

Regards,

Ben

________________________________

From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, February 03, 2005 2:07 PM
To: Mack-Crane, T. Benjamin
Cc: [email-masked]; [email-masked]; David
Allan; Adrian Farrel; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

ben, 

the discussion with dave has been reproduced in accelerated on the
mailing list - for me it appears that the more "philosophical"
conclusion can be positioned by answering to the following question "Was
SONET/SDH or lambda switching initially intended to be controlled by
GMPLS ?" if the response is "No, but nothing prevents to do so" the next
question is what does prevent from applying GMPLS to other technologies
knowing a substantial gain is obtained from its application - in certain
conditions - (see motivations as part of this introduction for instance)
? key issue being which are these (technical) conditions and are there
conditions that would preclude progressing this document - the response
is simply the negative - there are no such conditions in the
point-to-point - non-bridging - context where this document applies.

SONET/SDH is well-defined in terms of its information forwarding
behavior, both in normal state and under fault conditions.

I do not believe GMPLS has adequately addressed lambda (analog optical)
switching yet, probably because the technology is not mature.

Where can I find the definition of the forwarding behavior you refer to
as "point-to-point - non-bridging"?

 now, not sure there is a technical "firm" conclusion but the point on
the ethernet label encoding appears as follows since so far there is
potential interest to keep the label for ethernet generic enough and
deduce its interpretation from type of link over which the label is used
and intepreet its value according to the traffic_parameters and propose
associations to cover cases such as case 2 of Appendix A of
<draft-pwe3-ethernet-encap-08.txt> mechanisms that is also applicable to
other tunneling technology since this mechanism is orthogonal to the use
of PW's if required (example being Ethernet over SDH/OTH, for instance);
however, if these are the only associations we see relevant as part of
this document then we would fall back on the existing encoding with
potential enhancement if so required - 

to come to the point of the articulation the - generic - response holds
in one line: it articulates GMPLS signaling for L2SC LSPs (note: the
latter has been introduced in RFC 3945, RFC 3471, RFC 3473) - the
motivations are detailed as part of the introduction of this document -
i can not comment more from your initial statement since not detailed
enough for me to be more specific 

the response to the last question is relatively simple since the above
mentioned do not include any specifics concerning ATM or FR - this
document intends to close this gap by defining specific
Traffic_Parameters for these technologies - is there an interest for
doing so: response is yes otherwise the document would not have included
the corr. Details

ATM and FR already have standard traffic parameters.  GMPLS uses Intserv
in some cases, which could be applied to L2SC.  ATM and FR labels are
defined in RFC 3471.  This draft adds (without definition) "delay" and
"jitter," which are not specific to L2SC technology and are not traffic
parameters in the sense defined by the TSPEC (traffic characteristics of
the data flow that the sender will generate) but rather are constraints
on the route.  It also adds "switching granularity" which is perhaps
more closely aligned with Encoding Type than TSPEC.  Some discussion of
the rationale for the encodings proposed would be helpful.

voila, thanks,

- dimitri.

To: <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL,
"David Allan" <[email-masked]>
cc: "Adrian Farrel" <[email-masked]>, "Shahram Davari"
<[email-masked]>, <[email-masked]>
bcc: 
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri,

Regards,
Ben

Behalf
with
"label"
each
is
a
IEEE
GMPLS
either
LSP
with
carrying

---

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Fri, 4 Feb 2005 11:09:08 -0600

Dmitri,

Regarding your statement "you have to decouple the notion of ethernet
with bridging"

Forwarding of Ethernet frames IS bridging (as defined by the IEEE) and a
lot of work has gone into defining the forwarding behavior of bridges.
Are you proposing to define a new form of Ethernet forwarding outside of
the IEEE?  This seems like a bad idea.

Regards,

Ben

From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, February 03, 2005 4:31 PM
To: Shahram Davari
Cc: [email-masked]'; Mack-Crane, T. Benjamin;
[email-masked]; David Allan; Adrian Farrel; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

sharam, the first issue is that you have to decouple the notion of
ethernet with bridging, the second is that this configuration operation
can be automated - however the interesting point you brought in the loop
of discussion here is "applicability for shared medium" - isn't the PW
solution in the same context as 1) it can not make an automated usage of
a "medium" without configuring the tunnels (in our case the tunnels that
will be used to carry the ethernet payload e.g. SDH, OTH, etc. if not
using point-to-point PHY's) but in addition to the present solution PW
also requires 2) the provisioning of the PW - something not needed in
the present context as terminating points will be directly accessing the
"ethernet medium", in brief if such argument is used here it should have
also been used in the PW context (if not more intensively)

another fundamental point, i am also surprised seeing people supporting
MPLS (which brings a connection-oriented behaviour to IP) wondering
about the suitability of using one of the protocol suite of the IETF
i.e. GMPLS to bring another (initially) connectionless technology to a
"connection-oriented" behaviour (even if i do rather prefer the term
flow, in the present context) at the end the resulting gain is the same
for both technologies it terms of capabilities as application of
constraint-based routing principles - is this not at the end what drives
mostly all debates in the (G)MPLS galaxy beside VPNs and that was
underlying incorporation of these L2 technologies as part of the GMPLS
protocol architecture

thanks,

- dimitri.

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T. Benjamin"
<[email-masked]>
cc: [email-masked], David Allan <[email-masked]>,
Adrian Farrel <[email-masked]>, [email-masked]
bcc: 
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri,

Unfortunately I didn't grasp completely what you are trying to convey.
But one thing I know for sure, and that is  "Ethernet is Connectionless
(CLS)" (like IP) and assumes shared medium, while GMPLS is
connection-oriented (CO) and doesn't work in shared medium. Off course
you could always configure and build an Ethernet network that looks like
it is CO (by configuring a max of 2 ports with the same VLAN ID in each
bridge), and by not using any shared medium. But then who needs GMPLS,
when you already have to configure your network by other means?

-Shahram

ben, 

the corr. details

voila, thanks,

- dimitri.

Dimitri,

Regards,
Ben

Behalf
with
"label"
each
is
a
IEEE
GMPLS
either
LSP
with
carrying

---

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Fri, 4 Feb 2005 11:09:58 -0600

Dmitri,

Some questions in-line below.

Regards,
Ben

> Sent: Thursday, February 03, 2005 9:33 PM
> To: Shahram Davari
> Sharam, see in-line
> > ethernet with bridging,
> this is exactly where we did start from "port mode" in the first
version
> of the document and then "vlan mode" but in none of these modes
bridging
> is required as the path is known from its establishment (therefore
there
> is no MAC learning is needed here in the point-to-point case that we
are
> talking about) in brief, such interface would not make use of the
> canonical operations performed on ETH switches

Other bodies have defined Ethernet P-P services and have addressed the
bridging issues involved.  Is the IETF also defining an Ethernet P-P
service?  If so, it would be useful to address the same issues (with
some rationale).  Alternatively, we could simply use one of the already
completed service definitions (saving some work).

There are also definitions for ATM and FR services.  I am not familiar
with the "port mode" services in these cases or the "ATM VP Bundle"
service.  Do you have a reference for these?

> > But after you have configured your connections (aka VLAN ports),
then
> > layer network (aka MPLS), and is invisible to the intermediate
nodes.
> then if you ask me wether there can be an intermediate device
(bridging
> device) between two devices as discussed in this thread, the response
is
> yes - but does it change something fundamental here (as the scope of
the
> discussion is non-bridging environment), the response is: no - as such
> intermediate devices if they (unlikely) happen to be located as
> mentioned above would just behave as they do today when
interconnection
> two edge nodes (with point to point VLANs but this would require
manual
> provisioning as there is no GMPLS control on such bridging devices)

This is getting confusing.  It sounds as if there are some 2-port
bridges that can be controlled by GMPLS, and others that cannot.  How
does one distinguish which is which?

> 
> this said and as defined MPLS and used currently used for PW, MPLS is
> not a "layer" in the sense you are using this word
> 
> > configuring the tunnels (in our case the tunnels that will be used
to
> > point-to-point PHY's) but in addition to the present solution PW
also
> > wondering about the suitability of using one of the protocol suite
of
> > client/server), then there would not be any problem.
> 
> would you further explain what is/would be fundamentally different if
i
> had a client/server layer ? this knowing that inverse translation can
be
> performed when leaving the network to reach the ethernet terminating
> point ?
> 
> > However, what
> > that requires modification to its data-plane behavior.
> 
> i disagree on the last part of the sentence, this document does not
> modify behaviour for existing bridging devices as it is not its scope,
> as the port more already defined in several RFCs did not modify the
> behaviour consider this as being a way to sub-segment the flows
crossing
> an interface based on their VLAN ID, in case you consider each device
as
> a device allowing VLAN ID translation the latter becomes indeed
locally
> significant so we may say that this approach when applied on each
device
> scopes the VLAN ID - but again this is already the case for tagged
> frames crossing PE's today -
> 
> > As an analogy
> this is not a good analogy because IP addresses are end-to-end
> significant if NATing is not used - the same applies here consider
this
> translation as occurring on particular devices PE's for instance i.e.
> VLANs do not have in the present context an end-to-end semantic
anymore
> it is obvious that for ATM for instance situation is much more easy to
> tackle due its initial design
> 
> > (even if i do rather prefer the term flow, in the present context)
at
> > the end the resulting gain is the same for both technologies it
terms
principles
> > same VLAN ID in each bridge), and by not using any shared medium.
But
> > then who needs GMPLS, when you already have to configure your
network
> > Allan; Adrian Farrel; Shahram Davari; [email-masked] Subject:
RE:
> > Layer 2 Switching Caps LSPs
> >
> >
> >
> > ben,
> >
> > to other technologies knowing a substantial gain is obtained from
its
applicable
> > the use of PW's if required (example being Ethernet over SDH/OTH,
for

---

From: [email-masked]
Date: Fri, 4 Feb 2005 19:20:47 +0100

ben,

> Regarding your statement ?you have to decouple the notion of ethernet
with
> bridging?

-> i did mention this to clearly distinguish
   1. Ethernet 802.3
   2. Bridging
   3. MAC learning

   to lead to the example where the Ethernet term is mentioned (take for
inst.
   the ethernet port mode of some of this WG RFCs), this by referencing
only
   1) but not 2) and 3)

> Forwarding of Ethernet frames IS bridging (as defined by the IEEE) and a
lot > of work has gone into defining the forwarding behavior of bridges.
Are you > proposing to define a new form of Ethernet forwarding outside of
the IEEE?  > This seems like a bad idea.

-> for the ethernet port mode (nothing new here, the whole flow entering
the
   incoming port is inserted into the outgoing port) for the other mode, it
   additionally allows for distinguishing the flows (entering a port) based
   on the VLAN ID (in the point-to-point context that we are discussing
here)

---

From: [email-masked]
Date: Fri, 4 Feb 2005 19:33:32 +0100

dave - your response is "you don't think refinment would be possible" for a reason that escapes me since the document does not define control of provider bridges and as i do not think i have mentioned the "snooping" operation you are describing here below - you are more creative than i do ;-)

note: this said it does not change the numbers provided here below - and i can live with 64k LSPs (at least in a first phase)

"David Allan" <[email-masked]>
02/04/2005 09:44 EST

To: "[email-masked]'" <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari <[email-masked]>
cc: "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
bcc:
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri:
<snipped>
(but
> 64k LSPs not that bad for an unscalable solution ;-)

Suggesting snooping a 802.1ad VLAN stack to forward on the basis of more than one tag is more creative abuse of existing standards. You cannot preserve the value and simplicity of Ethernet if you insist on re-inventing it...A provider bridge forwards on the basis to S-tag and MAC address. The C-tag has no significance and we would be foolish to pursue a path whereby it does.

MPLS devices (all disucssion of ECMP aside) only forward on the basis of the top label.

rgds
Dave

> > [mailto:[email-masked]] Sent: Thursday,
> February 03,
> > 2005 5:31 PM To: Shahram Davari Cc:
> > there is nothing left for GMPS to do. Or are you saying
> that the GMPLS
> > will do the configuration?
> >
> However, what you
> > are trying to do is to modify Ethernet's control-plane in a
> way that
> > requires modification to its data-plane behavior. As an
> analogy what
> > you are doing is like trying to use the IP address as MPLS tag in
> > order to make IP connection-oriented.
> >
> > - is this not at the end what drives mostly all debates in
> the (G)MPLS
> > galaxy beside VPNs and that was underlying incorporation of
> these L2
> > technologies as part of the GMPLS protocol architecture
> >
> > thanks,
> >
> > - dimitri.
> >
> >
> > But one thing I know for sure, and that is  "Ethernet is
> > Connectionless (CLS)" (like IP) and assumes shared medium,
> while GMPLS
> > is connection-oriented (CO) and doesn't work in shared medium. Off
> > course you could always configure and build an Ethernet
> network that
> > looks like it is CO (by configuring a max of 2 ports with the same
> > VLAN ID in each bridge), and by not using any shared
> medium. But then
> > who needs GMPLS, when you already have to configure your network by
> > other means?
> >
> > -Shahram
> >
> >
> > [mailto:[email-masked]] Sent: Thursday,
> February 03,
> > 2005 3:07 PM To: Mack-Crane, T. Benjamin Cc:
> [email-masked];
> > [email-masked]; David Allan; Adrian
> Farrel; Shahram
> > Davari; [email-masked] Subject: RE: Layer 2 Switching Caps LSPs
> >
> >
> >
> > ben,
> >
> controlled
> > by GMPLS ?" if the response is "No, but nothing prevents to
> do so" the
> > next question is what does prevent from applying GMPLS to other
> > technologies knowing a substantial gain is obtained from its
> > application - in certain conditions - (see motivations as
> part of this
> > introduction for instance) ? key issue being which are these
> > instance); however, if these are the only associations we
> see relevant
> > as part of this document then we would fall back on the existing
> > encoding with potential enhancement if so required -
> >
> <[email-masked]>,
> > "Shahram Davari" <[email-masked]>,
> <[email-masked]>
> > bcc: Subject:
> > with respect to ATM and Frame Relay support that necessitates
> >> ethernet environments - if this is not clear from the current
> >> document introduction we would have also to work on this
> part of the
> >> document - therefore, the below reference to MSTP is not in the
> >> current scope; on the other side, the use of the term "VLAN label"
> >> has created some confusion; therefore, in a next release i will
> >> simply refer to a
> >
> > "label"
> >
> >> the present approach would be potentially applicable this is fine
> >> with me as long as we are within the scope of the initial
> motivations
> >>
> >> thanks, - dimitri.
> >>
> >> David Allan wrote:
> >>
> >>> Hi Adrian:
> >>>
> > responsible for delivering this message to the intended
> recipient, you
> > are hereby notified that any reproduction, dissemination or
> > distribution of this communication is strictly prohibited.
> If you have
> > received this communication in error, please notify us
> immediately by
> > replying to the message and deleting it from your computer.
> Thank you.
> > Tellabs ============================================================
> >
> >
>
>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Feb 2005 10:55:56 -0800

Dimitri,
 
Ho do you achieve the 64K? Are you planning to reuse the VLAN-ID in different ports for different LSPs?
If so your proposal is broken, because VLAN IDs don't have local significance, rather they have network-wide 
significance and meaning. So if  2 of these LSPs (having the same VLAN ID) pass through the same link, they would be merged.
 
-Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 04, 2005 1:34 PM
To: David Allan
Cc: [email-masked]'; [email-masked]'; Shahram Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri: 
<snipped> 
 (but 

rgds 
Dave 

> > [ mailto:[email-masked] <mailto:[email-masked]> ]On Behalf Of Shahram Davari Sent: 
> > [ mailto:[email-masked] <mailto:[email-masked]> ] Sent: Thursday, 
> February 03, 
> > [ mailto:[email-masked] <mailto:[email-masked]> ] Sent: Thursday, 
> February 03, 
> >> [ mailto:[email-masked] <mailto:[email-masked]> ] On 
> > 
> > Behalf 
> >

---

From: [email-masked]
Date: Fri, 4 Feb 2005 20:01:10 +0100

sharam

-> the port scopes their usage, incoming LSP_1 is associated to frames
flowing with VLAN_1 through port_8 is distinct from LSP_2 associated to
frames flowing with VLAN_1 through port_2 (on the same node)

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Feb 2005 11:04:53 -0800

Dimitri,

> frames flowing with VLAN_1 through port_2 (on the same node)

What happens if both both LSP_1 and LSP_2 want to be routed to prt_3?
Don't they get merged?

-Shahram

---

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Fri, 4 Feb 2005 13:04:44 -0600

Dimitri,

As I think Sharam has noted, 1) is a physical interface.  How packets
are transferred from one interface to another is the question.  2)
defines behavior for this (and 3) is just one feature of this behavior).
If you are not referring to 2), what defines the forwarding behavior?
Just saying all received packets are sent is not adequate (at least this
was not deemed adequate by earlier efforts to define Ethernet P-P
service).

Regards,
Ben

> Sent: Friday, February 04, 2005 12:21 PM
> Cc: [email-masked]; Shahram Davari;
>    incoming port is inserted into the outgoing port) for the other
mode,
> it

---

From: [email-masked]
Date: Fri, 4 Feb 2005 20:09:32 +0100

sharam, i have explained in a previous thread taking translation operation allowed on VLAN IDs (see PWE3 encaps document for inst.) and here assuming that the inverse translation is performed at the egress you are retrieving the value when leaving the network

concerning the second point, the issue of merging has also to be refined from what you say as you can maintain two different LSPs on a link that share a common label (in the frame mode) - as briefly explained in section  2.4.3 of RFC 3209 - this said the above operation is also not excluded if one desires maintaining separate labels

02/04/2005 10:55 PST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
bcc:
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri,

-Shahram
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 04, 2005 1:34 PM
To: David Allan
Cc: [email-masked]'; [email-masked]'; Shahram Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri:
<snipped>
(but

rgds
Dave

---

From: [email-masked]
Date: Fri, 4 Feb 2005 20:26:12 +0100

ben,

> As I think Sharam has noted, 1) is a physical interface.

i don't understand what you mean by 1) (= Ethernet 802.3) is a "physical
interface" please take a look at IEEE 802.3 to see that it defines the

1.4.167 Media Access Control (MAC): The data link sublayer that is
responsible for transferring data to and from the Physical Layer.

- as also depicted in Figure 2.1 and 2.2, where you will see that PHY is
just below the MAC sub-layer but the latter is not the "PHY" - Fig 2.1 is
rather explicit

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Feb 2005 11:51:33 -0800

Dimitri,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 04, 2005 2:10 PM
To: Shahram Davari
Cc: [email-masked]'; David Allan; [email-masked]'; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

Let me make it clear: IEEE does not permit translation of the VLAN ID in the Core-provider bridge (S-VLAN aware bridge) as well as Legacy bridges (C-VLAN aware bridge).

To answer your PWE3 question: 

A PE that supports ETH PW, has 2 disjoint and distinct components: An IEEE 802.1D Ethernet Bridging component followed by an PW IWF. The 802.1D performs the switching based on VLAN ID (and possibly MAC address), followed by a PW IWF that performs ETH PW processing. The first component (802.1D bridge) is not allowed to change the VLAN ID, because IEEE standards does not permit that. The VLAN ID May only be changed in the PW IWF, since it is outside the scope of IEEE.

What? SE is for Multicast application !!!!!!!! not what we are talking about.

-Shahram   

Dimitri,

-Shahram
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 04, 2005 1:34 PM
To: David Allan
Cc: [email-masked]'; [email-masked]'; Shahram Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

Dimitri: 
<snipped> 
 (but 

rgds 
Dave

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Feb 2005 12:22:02 -0800

Dimitri,

By Physical interface Ben means A single port (PHY +MAC). It is like a single TCP/IP port. You need another STANDARD function not defined in 802.3 to do the forwarding. AFAIK IEEE defines 802.1D for such function. Do you have any other Standard Forwarding function that this draft is targeting? 

-Shahram

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Friday, February 04, 2005 2:26 PM

---

From: [email-masked]
Date: Sat, 5 Feb 2005 00:22:17 +0100

sharam,

> sharam, i have explained in a previous thread taking translation
operation
> allowed on VLAN IDs (see PWE3 encaps document for inst.) and here
assuming
> that the inverse translation is performed at the egress you are
retrieving
> the value when leaving the network

>  Let me make it clear: IEEE does not permit translation of the VLAN ID in
> the Core-provider bridge (S-VLAN aware bridge) as well as Legacy bridges
> (C-VLAN aware bridge).

for your information as extracted from the last 802.1ad document
(15-12-2004): i do want to mention this because the notion of VLAN_ID
translation exist at the IEEE as well (note: in the above i did mention the
PWE3 doc)

"8.6.1 Ingress
Change subclause 8.6.1 as follows. After the existing note, add the
following note:
NOTE 2?A Service-VLAN aware Bridge considers a received frame to be
untagged if the initial octets of the MAC user data do not compose a
Service VLAN tag header.
Change the following paragraph as follows:
An S-VLAN aware Bridge Port may implement a manageable VID Translation
Table that specifies a value to be substituted for each of the possible
4094 VID values assigned or received as specified above. The translation
shall occur prior to application of the Enable Ingress Filtering parameter
and the other constituent functions of the Forwarding Process specified
below. The default configuration of the table shall retain the original VID
value. A C-VLAN aware Bridge shall not translate VIDs."

>    A PE that supports ETH PW, has 2 disjoint and distinct components: An
> IEEE 802.1D Ethernet Bridging component followed by an PW IWF. The 802.1D
> performs the switching based on VLAN ID (and possibly MAC address),

so now switching based on the VLAN ID becomes possible (while only possibly
on the MAC address) ? why not in the scope of the present document then ?

> followed by a PW IWF that performs ETH PW processing. The first component
> (802.1D bridge) is not allowed to change the VLAN ID, because IEEE
standards
> does not permit that. The VLAN ID May only be changed in the PW IWF,
since
> it is outside the scope of IEEE.

... so ETH processing within the context of the PW allows such operation as
i did pointed out (that was not defined by the IEEE - my whole point -),
and the question is why the same couldn't happen in the present context ?
knowing that "bridging" is not a pre-requisite

> concerning the second point, the issue of merging has also to be refined
> from what you say as you can maintain two different LSPs on a link that
> share a common label (in the frame mode) - as briefly explained in
section
> 2.4.3 of RFC 3209 - this said the above operation is also not excluded if
> one desires maintaining separate labels

> What? SE is for Multicast application !!!!!!!! not what we are talking

SE Style is used among other for make-before-break; sharing, MP2P, etc.
that are not related to multicast (see RFC 3209)

---

From: [email-masked]
Date: Sat, 5 Feb 2005 00:42:06 +0100

sharam,

-> we do still have the possibility to maintain two separate LSPs at the
control plane level even if sharing of resource reservation occurs;
concerning the label it may or not be identical depending on whether the
explicit route for these LSPs is identical or not i.e. when path msgs have
different explicit route, separate LSPs must be established - note that the
inverse applies as well even if the explicit route are identical separate
labels can still be assigned

---

From: [email-masked]
Date: Sat, 5 Feb 2005 17:42:38 +0100

see my response to sharam - as you come all over again with the same issues -

the question is how many flows can you discriminate based on the VLAN_ID and the response is 4k per port, drawing an analogy with a PE PW box the same happens if a NSP per port,

the second question is but *if* you discriminate the flows on a local basis you are assuming a behaviour that is not defined by the IEEE (your initial last CCAMP meeting question) and the response there are equivalent mechanisms defined outside the scope of the IEEE and definition i was pointing did include this behaviour (or more precisely does not preclude it);

the third question how is the forwarding occurring then and the response is not necessarily using bridging/MAC learning as the path of these frames is known from the LSP establishment (it is thus the establishment of the LSP that determines external behaviour of the forwarding function) - note: as in any standard there is no point in detailing the exact implementation of the switching/ forwarding/connection function -

and lastly (closing the loop) the fourth question is does it require VLAN swapping ? the response is no this mechanism is not assumed and (taking a minimalistic assumption of VLAN continuity) just mandate ensuring per-port (and not per node or other instances) VLAN interpretation and this would only be constraining the establishment of the LSP at the end since equivalent to a continuity principle (and this can also be tackled by GMPLS using the label set mechanisms) - however you could with the document as written assume that a VLAN_ID may be translated - note: i do not refer to VLAN swapping - when crossing a node and document(as part of an appendix) a similar table as the one written in Appendix A of <draft-ietf-pwe3-ethernet-encap-08.txt> - i think at the end this is what adrian was looking for as part of the documentation effort -

note: this said to respond to your claim upon what's mandatory or not as part of this document, the response did not change from the previous one and the discussion we are having now is just because you are assuming a unique and specific data plane behaviour as part of this document for which there is no specification and then challenge this document as it would be the only possible allowed behaviour while 1) this is not the case, and some of these behaviours do not require anything else than what i document in my response to sharam and 2) there is nothing that precludes proposing an interpretation of a specific data plane field, or mechanism, or entity within the control plane - ask yourself the question is it allowed to interpreet link locally a data plane wavelength or timeslot as a label in the control plane ? response: yes, as it is just a matter of convention (even if some are more "natural" than others) but these interpretation orthogonal to the implementation of the forwarding/switching/connection function

02/04/2005 14:32 EST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "[email-masked]'" <[email-masked]>, Shahram Davari <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
bcc:
Subject: RE: Layer 2 Switching Caps LSPs

OK let me decompose your last response and see if we can bottom this out....

> further refinment is still possible)

My interpretation of "refinement" implies modification to existing procedures. Judging from your last response, you are simply referring to hierarchy which is an existing solution and requires no "refinement".

> and with 16 ports you would have

How can I interpret this....

- I could have 4k VLANs all with a common topology (bridge for 16 spokes).

- Using VLAN swapping I could have 64k uni-directional LSPs only in a perfect world where I had an exactly flat distribution acorss the ports as to how they were routed. (BTW Any sort of aggregation scenario could drag that number down to a maximum of 4k LSPs).

However the second requires VLAN tag swapping which your and your co-authors comments in the past have suggested was not the purpose of this draft. Many of us violently object to VLAN awapping as it is data plane behavior that is not specified anywhere, and we see no utility in defining a control plane for things that do not exist....

Is there a third option that I have not understood implied by your latest comments?

cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 04, 2005 1:34 PM
To: Allan, David [CAR:NS00:EXCH]
Cc: [email-masked]'; [email-masked]'; Shahram Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel; [email-masked]

bcc:

Dimitri:
<snipped>
(but

rgds
Dave

---

From: "Don Fedyk" <[email-masked]>
Date: Thu, 10 Feb 2005 09:41:18 -0500

Hi Dimitri

> -----Original Message----- From: dimitri papadimitriou
> [mailto:[email-masked]] Sent: Wednesday, February
> 09, 2005 6:33 PM To: Fedyk, Don [BL60:1A00:EXCH] Cc:
> [email-masked] Subject: Re: FW: Layer 2 Switching Caps
> LSPs
> 
> 
> don,
> 
> Don Fedyk wrote:
> > Resending, ccamp list message never came through
> > ------------------------------------------------
> > 
> > Hi
> > 
> > I read through this draft and the thread and I don't see
> > that much detail. Dimitri your statements are more about
> > what this draft is not 
> > about. While they would be useful additions in the draft
> > for clarification, how does this draft differ from one
> > that just says:  "Lets define some code points for TLVs
> > for future signaling of packet 
> > technologies, ATM, FR and Ethernet"?
> 
> the document details RSVP-TE processing (beside
> introducing rationales) and does not limit to a list of
> codepoints, at the end and when looking at the additional
> code-points (beside new C-Types) this constitute a small
> part of this document (section 5.1) for the LSP encoding
> type
Yes but without a picture like: 

ATM UNI-[gmpls controlled ATM i/f]-ATM PNNI etc

I'm left guessing where this is really headed. The processing is in the
context of the new code points. 

> 
> > This is very similar to another SDO just asking for a
> > few  code points IMHO.
> 
> i don't see what differs in terms of approach from other
> technologies currently being more detailed as part of the
> GMPLS coverage

You have a point. GMPLS was/is defined to a level of abstraction such that
we need to describe it to people
beyond what is in the documents today.  GMPLS is so large we had to start
somewhere, but do we continue just refining
or do we drill down to bedrock with a few select technologies?  I would
prefer if we could drill down. I
think that is what the debate is really. 

> 
> for the technical rationale, it comes from the definition
> introduced in LSP-hierarchy document that introduces
> classes of resources (in terms of switching capability)
> and LSP regions, however at some point in time there is a
> need to distinguish between the common part and the
> technology specific part (in particular when the target is
> a unified TE model) that needs only to be supported by
> nodes capable to initiate LSPs across the corresponding
> region (L2SC in the present context)
> 
> > Would it not be better to detail one technology and
> > transport mode in detail, rather than slowly refining
> > the signaling for multiple technologies?
> 
> what do you mean by "detail one technology and transport
> mode" ?  clarification would be helpful in order for me to
> understand this comment

Really it was the point above if we continue to specify abstractly we raise
a lot of questions particularly where active standardization is going on
like Ethernet.  If we cannot drill down to a particular usage scenario is
the work really needed at this point in time?

Regards,
Don
> > Don
<snip>

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Thu, 10 Feb 2005 10:27:50 -0600

Hi Don,

Refer below for my responses (db)-
Thanks-
Deborah 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Don Fedyk
Sent: Thursday, February 10, 2005 9:41 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: FW: Layer 2 Switching Caps LSPs

Hi Dimitri

Db> The draft was intended as a discussion of RFC3945 with respect to
L2LSP. From the discussion, there does seem to be confusion on the
current descriptions in 3945/3473, including concerns on why L2 was
included under GMPLS, why GMPLS and not MPLS (or Ethernet), so the draft
has been successful. It's a first cut, and it's hoped there's group
interest in adding the details.

> technologies currently being more detailed as part of the

You have a point. GMPLS was/is defined to a level of abstraction such
that
we need to describe it to people
beyond what is in the documents today.  GMPLS is so large we had to
start
somewhere, but do we continue just refining
or do we drill down to bedrock with a few select technologies?  I would
prefer if we could drill down. I
think that is what the debate is really.

Db> Yes, some do prefer to limit it to one layer/technology at a time.
And it seems as each technology has been tackled, there has been great
resistance;-) Others of us are hoping it will do it's original premise
of providing a consistent control plane for multiple technologies:
ftp://ftp.isi.edu/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-
04.txt
ftp://ftp.isi.edu/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-reqs-00
.txt

> mode" ?  clarification would be helpful in order for me to

Really it was the point above if we continue to specify abstractly we
raise
a lot of questions particularly where active standardization is going on
like Ethernet.  If we cannot drill down to a particular usage scenario
is
the work really needed at this point in time?

Regards,
Don
<snip>