Subject: Re: LCAS and GMPLS

From: Wataru Imajuku <[email-masked]>
Date: Wed, 27 Jul 2005 13:28:20 +0900

Hi, Mr. Dueser and all

  Thank you for your comment.

  As you pointed out, the GFP/LCAS/VCAT functionality is temination capability.
  But, it can easily migrate with non-GFP/LCAS/VCAT TDM network,

  The one of ID's requirements includes the extension for the routing protocol
in order to advertise such termination capability in each node.
  I believe this routing extension helps smooth migration amongst GFP/LCAS/VCAT
capable and non capable networks.

  In the -00.txt version, the ID suggests the extension to
  Interface Switching Capability Descriptor (ISCD) as a temporal suggestion.
  Because, I understand that the meaning of interface switching capability 
descriptor
  includes both transit capability and termination capability of LSPs.

  However, the explicit addition of termination capability to the ISCD may 
be one of choice,
considering the more generic node architeture as discussed in Dimitri's 
MRN-extensions draft.

  I hope the discussion in Paris meeting also for above issue .

Best Regards,
Wataru

Hi,

>some comments re I-D draft-imajuku-ccamp-gmpls-vcat-lagr-req-00:
>
>- LCAS was not intended for grouping of VC-X-yvs, but for synchronization 
>of the VC-X which is added or dropped. And it's bi-directional.
>- Only the terminating nodes need to have the full GFP+LCAS+VCAT functionality.
>- You need to be careful when using the verbs may, shoul and must - are 
>they conform to IETF convention?
>
>I believe in general this is an important I-D also wrt to the ITU-T 
>liaison and for implementation! I believe we can also discuss details 
>during the IETF next week.
>
>Michael Dueser

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL +81-46-859-4315
FAX +81-46-859-5541

---

From: "Trevor Wilson" <[email-masked]>
Date: Wed, 27 Jul 2005 12:30:45 +0100

Hi,

VCAT (and LCAS) functionality is required ONLY at the terminating TDM
NEs of a Virtually Concatenated signal. As long as the 'intermediate
NEs', through which the individual VC-ns are transported, have the
capacity to carry those VC-ns then the SONET/SDH network will provide
the necessary connection. For any given VCAT connection, the
intermediate NEs do not need to be VCAT/LCAS capable. Therefore I do not
understand why, in the 'problem statement of
'draft-imajuku-ccamp-gmpls-vcat-lagr-req-00.txt', each TDM node should
advertise its VCAT/LCAS capabilities. When the connection is being
provisioned, it is up to the SDH/SONET NMS to determine whether or not
the network (and it's NEs) are capable of a VCAT/LCAS operation.
In the TDM network, label switching is not performed, except perhaps at
the edge of the network where the client signal is encapsulated into the
transport technology. Therefore I believe that the routes for the
individual VC-ns of a virtually concatenated group (VCG) are of no
consequence to the client signal, and the VCG can be looked upon as a
single LSP between the TDM ingress node and the TDM egress node.

Michael:

Below you state that LCAS is Bi-directional.
For LCAS to operate it needs at least one member in both directions; but
essentially the LCAS operation is uni-directional in nature. If
bandwidth adjustment is required in both directions it is necessary to
initiate these separately.

Regards,

Trevor

Trevor Wilson
Nortel Networks
Belfast Lab
Tel: +44 2890 363701
       ESN 751 3701
>This is the Way. This is Nortel. 
>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wataru Imajuku
Sent: 27 July 2005 05:28
To: [email-masked]; [email-masked]
Subject: Re: LCAS and GMPLS

Hi, Mr. Dueser and all

  As you pointed out, the GFP/LCAS/VCAT functionality is temination
capability.
  But, it can easily migrate with non-GFP/LCAS/VCAT TDM network,

  The one of ID's requirements includes the extension for the routing
protocol in order to advertise such termination capability in each node.
  I believe this routing extension helps smooth migration amongst
GFP/LCAS/VCAT capable and non capable networks.

  In the -00.txt version, the ID suggests the extension to
  Interface Switching Capability Descriptor (ISCD) as a temporal
suggestion.
  Because, I understand that the meaning of interface switching
capability 
descriptor
  includes both transit capability and termination capability of LSPs.

  However, the explicit addition of termination capability to the ISCD
may 
be one of choice,
considering the more generic node architeture as discussed in Dimitri's 
MRN-extensions draft.

Best Regards,
Wataru

Hi,

---

From: [email-masked]
Date: Wed, 27 Jul 2005 13:41:41 +0200

Hi Trevor,

you're right! Thanks for the clarification,

Michael

-----Ursprüngliche Nachricht-----
Von: Trevor Wilson [mailto:[email-masked]] 
Gesendet: Mittwoch, 27. Juli 2005 13:31
An: Wataru Imajuku; Dueser, Michael; [email-masked]
Betreff: RE: LCAS and GMPLS

Hi,

VCAT (and LCAS) functionality is required ONLY at the terminating TDM NEs of a Virtually Concatenated signal. As long as the 'intermediate NEs', through which the individual VC-ns are transported, have the capacity to carry those VC-ns then the SONET/SDH network will provide the necessary connection. For any given VCAT connection, the intermediate NEs do not need to be VCAT/LCAS capable. Therefore I do not understand why, in the 'problem statement of 'draft-imajuku-ccamp-gmpls-vcat-lagr-req-00.txt', each TDM node should advertise its VCAT/LCAS capabilities. When the connection is being provisioned, it is up to the SDH/SONET NMS to determine whether or not the network (and it's NEs) are capable of a VCAT/LCAS operation. In the TDM network, label switching is not performed, except perhaps at the edge of the network where the client signal is encapsulated into the transport technology. Therefore I believe that the routes for the individual VC-ns of a virtually concatenated group (VCG) are of no consequence to the client signal, and the VCG can be looked upon as a single LSP between the TDM ingress node and the TDM egress node.

Michael:

Below you state that LCAS is Bi-directional.
For LCAS to operate it needs at least one member in both directions; but essentially the LCAS operation is uni-directional in nature. If bandwidth adjustment is required in both directions it is necessary to initiate these separately.

Regards,

Trevor

Trevor Wilson
Nortel Networks
Belfast Lab
Tel: +44 2890 363701
       ESN 751 3701

-----Original Message-----

Hi, Mr. Dueser and all

Best Regards,
Wataru

Hi,

---

From: Wataru Imajuku <[email-masked]>
Date: Wed, 27 Jul 2005 23:01:13 +0900

Hi, all

  I forward a nice comment from Mr. Huub van Helvoort.

  His comments indicates we need liason from ITU-T SG-15 regarding to this issue.

Best Regards
Wataru

>Date: Wed, 27 Jul 2005 15:35:08 +0200
>From: Huub van Helvoort <[email-masked]>
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) 
>Gecko/20040804 Netscape/7.2 (ax)
>X-Accept-Language: en-us, en
>To: "Wataru Imajuku <imajuku.wataru" <[email-masked]>
>Subject: [Fwd: Re: LCAS and GMPLS]
>
>Hello Wataru,
>
>Thank you for your reply.
>Would you be so kind to send the attached response also to
>the ccamp list? In my name.
>
>Kindest regards, Huub.
>PS  My messages are not on the list:
>     https://psg.com/lists/ccamp/ccamp.2005/maillist.html
>
>-------- Original Message --------
>Date: Wed, 27 Jul 2005 13:49:19 +0200
>From: Huub van Helvoort <[email-masked]>
>To: [email-masked]
>CC: Trevor Wilson <[email-masked]>,  Wataru Imajuku 
><[email-masked]>,  [email-masked]
>References: <[email-masked]>
>
>Hello again,
>
>I agree with what Trevor wrote:
>
>>intermediate NEs do not need to be VCAT/LCAS capable.
>
>and:
>
>One point for the problem statement could be that in order to
>guarantee a hitless removal of one of the members in a VCG
>(decrease of bandwidth) there is a mandatory sequence:
>First remove member at ingress node, wait for confirm and
>only then remove path and member at egress node.
>
>However, a solution was presented at the last ITU-T SG15/q11
>meeting that removes this requirement.
>
>Cheers, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 31 Jul 2005 16:21:35 +0200

Hello Wataru,

> I forward a nice comment from Mr. Huub van Helvoort.

Thank you for forwarding.
(I hope I can send this message the list myself).

> His comments indicates we need liason from ITU-T SG-15 regarding to 

This is a good proposal, it will indicate to ITU-T SG15/Q11
that IETF/CCAMP supports this enhancement.

Kind regards, Huub.

--- from message 27-7-2005 ---

-- 
================================================================
              http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...

Delivery-date: Sun, 31 Jul 2005 14:22:51 +0000
Date: Sun, 31 Jul 2005 16:21:35 +0200
From: Huub van Helvoort <[email-masked]>
To: ccamp <[email-masked]>
Subject: Re: LCAS and GMPLS

Hello Wataru,

> I forward a nice comment from Mr. Huub van Helvoort.

Thank you for forwarding.
(I hope I can send this message the list myself).

> His comments indicates we need liason from ITU-T SG-15 regarding to 

This is a good proposal, it will indicate to ITU-T SG15/Q11
that IETF/CCAMP supports this enhancement.

Kind regards, Huub.

--- from message 27-7-2005 ---

-- 
================================================================
              http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...

Delivery-date: Sun, 31 Jul 2005 11:17:31 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Slides please
Date: Sun, 31 Jul 2005 12:19:41 +0100

Hi,

Thanks to those who have already sent me slides.

If the rest of you would like to send them, I will put them on line.

Absolute deadline is 5pm Tuesday, Paris time.

Thanks.
Adrian

Delivery-date: Sun, 31 Jul 2005 10:50:11 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>
Cc: "'Jean Philippe Vasseur'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Issue for CCAMP meeting [Was: Early chair review of draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt]
Date: Sun, 31 Jul 2005 11:49:58 +0100

Hi Arthi,

[SNIPPED]

> hop at least has IP reachability (via IGP or BGP). If the next-hop is
> not reachable, then the path computation stops and the LSR sends back a
> PathErr upstream. If the next-hop is reachable, then it finds an
> ABR/ASBR to get to the next-hop. In the absence of an auto-discovery
> mechanism, the ABR in the case of inter-area TE or the ASBR in the
> next-hop AS in the case of inter-AS TE should be the loose next-hop in
> the ERO and hence should be accessible via the TED, otherwise the path
> computation for the inter-domain TE LSP will fail.
> ## I would like you to make it VERY clear what you are doing here.
> ## You are using the Routing Database to make TE routing decisions.
> ## This may (or may not) be OK in people's minds
> ## I will send separate mail to the CCAMP list because this is a BIG
> ## DEAL in GMPLS networks.

AA---> I noticed the mail that you sent out. Thanks! However, there have
been no replies yet. But I think this ID does state that that if the next
hop is not in the TED and does not have IP reachability, then such a
computation would fail. Should we raise this point again either at the
WG meeting or when we post the next rev ?

This would be a good topic to close at the meeting.
What you say here is OK: that is, if the hop is not in the TED *and* does
not have IP reachability, then computation fails.
Clearly, we also know what to do when the hop is in the TED (regardless of
IP reachability).

The issue we have to cover is what to do when the hop is *not* in the TED,
but we do have IP reachability.
What does this mean when we have a separate data and control plane? What
does it mean when the data and control planes are shared (as in MPLS)?
I think there may be some subtle operational issues hiding here and I feel
a BCP coming on :-(

If you could mention this in your slot, that would be valuable. If folks
with opinions could rush to the mic (or the mailing list), that would also
be helpful.

Cheers,
Adrian

Delivery-date: Sat, 30 Jul 2005 09:32:29 +0000
From: "Adrian Farrel" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Date: Sat, 30 Jul 2005 10:29:57 +0100

Hi, 

Time for me to speak out about the omission of hitherto mandatory objects
from signaling messages. 

I would MUCH prefer that you keep the objects (Upstream Label or Path,
Label on Resv) and use a special label value (implicit null? some new
reserved label value?) to mean "stitch this". 

For me this is more natural and is less of a significant change to the
existing protocol and implementation. 

It also solves the bidirection problem. 

Opinions? 

Cheers,
Adrian 

 ----- Original Message -----
From: <[email-masked]>
To: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Cc: "Arthi Ayyangar" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Friday, July 29, 2005 9:39 PM
Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 

>
> hi j-l, arthi 
>
>
> > > -In section 4.1.2 you partially describe bidirectional LSP
> > stitching
> > > procedure. You mention that an Upstream Label MUST NOT be
> > allocated by
> > > the end-to-end LSP on the LSP segment, which is OK. But
> > then how the
> > > LSP-Segment Egress will now that the end-to-end LSP is
> > bidirectional?
> > AA--------> Excellent point.
> >
> > > What about defining a flag in the Attributes Flags TLV of the
> > > LSP_ATTRIBUTE object so as to indicate that the LSP is
> > bidirectional?
> > AA------> That would be a change to the processing that GMPLS
> > nodes use
> > AA------> to
> > detect bidirectionality, isn't it ? Normally nodes look for
> > the Upstream Label object to detect bidirectionality.
> >
> > So let us say that an LSP is bidirectional if a) an Upstream
> > Label is present or b) no Upstream Label, but bit set in
> > LSP_ATTRIBUTE or c) both However, reliance on an e2e
> > attributes bit set by head end, means existing head ends will
> > not be setting this bit, so that will be an issue (wrt compatibility). 
>
> JLLR: I agree this may raise some backward compatibility issues.
> This would require that head-ends be upgraded... 
>
>
> DP: the other issue is having two methods for indicating the same thing
is also not advisable
> 
>
> > Could be nice if this signaling was just between the node
> > doing the stitching and the end point of the LSP segment,
> > since this is the hop that the bidirectionality information
> > is lost. Let me think about this. 
>
> JLLR: Yes, and what about defining a new MPLS label value, let say label
4 = "No label assigned", with a semantic distinct from label 3 semantic
(=label pop). The UPSTREAM label object with this new label value  would
be included in the end-to-end Path message over the LSP-Segment...
> 
>
> DP: assuming an information has to be passed for the indicating this
capability i do also think a method like passing an implicit indication in
the upstream label value would be more appropriated (note that the initial
issue is due to the fact one would allow for unidirectional e2e LSP making
use of bidirectional LSP segments - see comment from J-L here below - and
not maintaining a 1:1 relationship for the directionality between the e2e
LSP and the LSP segment that can be retrieved with the procedure described
in section 4.2.4 - and so the first question is it worth allowing this?)
> 
>
> > > Also the selection of the LSP segment in case of bidirectional LSP
> > > should be detailed (e.g. If the end-to-end LSP is
> > bidirecitonal then
> > > the LSP-segment MUST be bidirectional. Also shall we allow that two
> > > unidrectional end-to-end LSP use the same bidirectional LSP segment
> > > (one in each direction)?
> > AA----> Yes, this should be okay. IMO.
> >
> > > -At the end of section 4.2.5 you mention that LSP-Segment
> > failure or
> > > maintenance SHOULD be treated as a failure event for the
> > end-to-end LSP.
> > > I agree for LSP-Segment failure but not for LSP-Segment maintenance.
> > > LSP-Segment maintenance should be treated as TE-link
> > maintenance for
> > > the end-to-end LSP, and procedures defined in GMPLS
> > graceful TE-link
> > > shutdown draft may be useful (Specific RSVP error code and TE-link
> > > attribute)...
> > AA---> Yes, I agree; we will mention this. Actually the graceful
> > AA---> teardown
> > sentence occurs few paragraphs before, but not in the right
> > context. So we will clarify the above. 
>
>
> DP: i am not sure to understand the comment, the sentence speaks about
deletion of the LSP segment due to failure/maintenance should be treated
as a failure event for the e2e LSP, so i don't think the initial sentence
was meant to translated the initial comment, anyway it would be of
interest that you detail the error code
>
> DP: note also that section 4.2.5 indicates that for stitched LSPs
Graceful deletion can be used - i perfectly agree - but the sequence
should be detailed as part of this section
> 
>
> > > Hope this helps,
> > AA--->  Sure does.
> >
> >
> > Thanks!
> >
> > -arthi
> >
> > >
> > >
> > > > -----Message d'origine-----
> > > > De : [email-masked]
> > > > [mailto:[email-masked]] De la part de
> > > > [email-masked] Envoyé : vendredi 15 juillet
> > 2005 21:50 À :
> > > > [email-masked] Cc : [email-masked] Objet : I-D
> > > > ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
> > > >
> > > > A New Internet-Draft is available from the on-line
> > Internet-Drafts
> > > > directories.
> > > > This draft is a work item of the Common Control and Measurement
> > > > Plane Working Group of the IETF.
> > > >
> > > > Title: Label Switched Path Stitching with
> > > > Generalized MPLS Traffic Engineering
> > > > Author(s): A. Ayyangar, J. Vasseur
> > > > Filename: draft-ietf-ccamp-lsp-stitching-01.txt
> > > > Pages: 19
> > > > Date: 2005-7-15
> > > >
> > > > In certain scenarios, there may be a need to combine together two
> > > >    different Generalized Multi-Protocol Label Switching
> > (GMPLS) Label
> > > >    Switched Paths (LSPs) such that in the data plane, a
> > single end-to-
> > > >    end (e2e) LSP is achieved and all traffic from one LSP
> > is switched
> > > >    onto the other LSP.  We will refer to this as "LSP
> > stitching".
> > > > This
> > > >    document covers cases where: a) the node performing
> > the stitching
> > > >    does not require configuration of every LSP pair to be stitched
> > > >    together b) the node performing the stitching is not
> > the egress of
> > > >    any of the LSPs c) LSP stitching not only results in
> > an end-to-end
> > > >    LSP in the data plane, but there is also a
> > corresponding end-to-end
> > > >    LSP (RSVP session) in the control plane.  It might be
> > possible to
> > > >    configure a GMPLS node to switch the traffic from an LSP for
> > > > which it
> > > >    is the egress, to another LSP for which it is the
> > ingress, without
> > > >    requiring any signaling or routing extensions whatsoever,
> > > > completely
> > > >    transparent to other nodes.  This will also result in
> > LSP stitching
> > > >    in the data plane.  However, this document does not cover this
> > > >    scenario of LSP stitching.
> > > >
> > > > A URL for this Internet-Draft is:
> > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitc
> > > hing-01.txt
> > > >
> > > > To remove yourself from the I-D Announcement list, send a
> > message to
> > > > [email-masked] with the word unsubscribe
> > in the body
> > > > of the message.
> > > > You can also visit
> > > > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > > to change your subscription settings.
> > > >
> > > >
> > > > Internet-Drafts are also available by anonymous FTP.
> > Login with the
> > > > username "anonymous" and a password of your e-mail address. After
> > > > logging in, type "cd internet-drafts" and then
> > > > "get draft-ietf-ccamp-lsp-stitching-01.txt".
> > > >
> > > > A list of Internet-Drafts directories can be found in
> > > > http://www.ietf.org/shadow.html or
> > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > >
> > > > Internet-Drafts can also be obtained by e-mail.
> > > >
> > > > Send a message to:
> > > > [email-masked].
> > > > In the body type:
> > > > "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
> > > >
> > > > NOTE:The mail server at ietf.org can return the document in
> > > > MIME-encoded form by using the "mpack" utility.  To use this
> > > > feature, insert the command "ENCODING mime" before the "FILE"
> > > > command.  To decode the response(s), you will need "munpack" or
> > > > a MIME-compliant mail reader.  Different MIME-compliant mail
> > > > readers
> > > > exhibit different behavior, especially when dealing with
> > > > "multipart" MIME messages (i.e. documents which have been split
> > > > up into multiple messages), so check your local documentation on
> > > > how to manipulate these messages.
> > > >
> > > >
> > > > Below is the data which will enable a MIME compliant mail reader
> > > > implementation to automatically retrieve the ASCII version of the
> > > > Internet-Draft.
> > > >
> > >
> > 
>

Delivery-date: Fri, 29 Jul 2005 20:43:10 +0000
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
From: [email-masked]
Subject: Re: Proposed liaison to SG15 on RFC 4139
Date: Fri, 29 Jul 2005 22:42:18 +0200

Delivery-date: Fri, 29 Jul 2005 20:41:41 +0000
To: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Cc: "Arthi Ayyangar" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Date: Fri, 29 Jul 2005 22:39:04 +0200

Delivery-date: Fri, 29 Jul 2005 15:27:29 +0000
Date: Sat, 30 Jul 2005 00:24:14 +0900
From: Kohei Shiomoto <[email-masked]>
To: LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>
CC: [email-masked], Richard Rabbat <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-01.txt

Hi Jean-Louis

Thank you for your comments. Your point sounds important when we=20
consider the case IPv4 and IPv6 coexist.

But I feel that the IPv4 and IPv6 interwork seems a little bit future=20
topic in a (G)MPLS context, in particular, from the control plane=20
perspective.

I would be happy if you could provide your experience with the actual=20
network operation and contribution.

Best regards,
--
Kohei

LE ROUX Jean-Louis RD-CORE-LAN wrote:
> Hi Kohei, Rajiv, Richard,
>=20
> I have on comment related to your GMPLS addressing ID:
> In section 5.2 you recommend, that in the session object, the IP tunnel=
 end-point be set to the destination TE router id and that the extended t=
unnel id be set to the source TE router id, which makes sense. But as per=
 3209, a session object can either encode IPv4 or IPv6 addresses but not =
both types, and there may be an issue if source TE router id is IPv6 and =
destination TE router id is IPv4 (or vice versa). This may happen for ins=
tance with inter-AS/SP LSPs. IMHO we should address this point.
>=20
> Best Regards,
>=20
> JL
>=20
>=20
>=20
>=20
>=20
>>-----Message d'origine-----
>>De : [email-masked]=20
>>[mailto:[email-masked]] De la part de=20
>>[email-masked]
>>Envoy=EF=BF=BD : mardi 21 juin 2005 21:50
>>=EF=BF=BD : [email-masked]
>>Cc : [email-masked]
>>Objet : I-D ACTION:draft-ietf-ccamp-gmpls-addressing-01.txt=20
>>
>>A New Internet-Draft is available from the on-line=20
>>Internet-Drafts directories.
>>This draft is a work item of the Common Control and=20
>>Measurement Plane Working Group of the IETF.
>>
>>	Title		: Use of Addresses in Generalized Multi-Protocol
>>                          Label Switching (GMPLS) Networks
>>	Author(s)	: K. Shiomoto, et al.
>>	Filename	: draft-ietf-ccamp-gmpls-addressing-01.txt
>>	Pages		: 23
>>	Date		: 2005-6-21
>>=09
>>This document explains and clarifies the use of addresses in=20
>>   Generalized Multi-Protocol Label Switching (GMPLS)=20
>>networks.  The aim=20
>>   of this document is to facilitate and ensure better=20
>>interworking of=20
>>   GMPLS-capable Label Switching Routers (LSRs) based on experience=20
>>   gained in deployments and interoperability testing and proper=20
>>   interpretation of published RFCs.=20
>>   =20
>>   The document recommends a proper approach for the=20
>>interpretation and=20
>>   choice of address and identifier fields within GMPLS protocols and=20
>>   references specific control plane usage models.  It also examines=20
>>   some common GMPLS Resource Reservation Protocol-Traffic=20
>>Engineering=20
>>   (RSVP-TE) signaling message processing issues and recommends=20
>>   solutions.  It finally discusses how to handle IPv6 sources and=20
>>   destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB=20
>>   (Management Information Base) modules.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-add
>=20
> ressing-01.txt
>=20
>>To remove yourself from the I-D Announcement list, send a=20
>>message to [email-masked] with the word=20
>>unsubscribe in the body of the message. =20
>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>>to change your subscription settings.
>>
>>
>>Internet-Drafts are also available by anonymous FTP. Login=20
>>with the username "anonymous" and a password of your e-mail=20
>>address. After logging in, type "cd internet-drafts" and then
>>	"get draft-ietf-ccamp-gmpls-addressing-01.txt".
>>
>>A list of Internet-Drafts directories can be found in=20
>>http://www.ietf.org/shadow.html or=20
>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>>	[email-masked].
>>In the body type:
>>	"FILE=20
>>/internet-drafts/draft-ietf-ccamp-gmpls-addressing-01.txt".
>>=09
>>NOTE:	The mail server at ietf.org can return the document in
>>	MIME-encoded form by using the "mpack" utility.  To use this
>>	feature, insert the command "ENCODING mime" before the "FILE"
>>	command.  To decode the response(s), you will need "munpack" or
>>	a MIME-compliant mail reader.  Different MIME-compliant=20
>>mail readers
>>	exhibit different behavior, especially when dealing with
>>	"multipart" MIME messages (i.e. documents which have been split
>>	up into multiple messages), so check your local documentation on
>>	how to manipulate these messages.
>>	=09
>>	=09
>>Below is the data which will enable a MIME compliant mail reader
>>implementation to automatically retrieve the ASCII version of the
>>Internet-Draft.
>>
>=20
>=20
>=20
>=20

--=20
Kohei Shiomoto, Ph.D
Senior Research Engineer, Supervisor
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone +81 422 59 4402    Fax +81 422 59 3787

Delivery-date: Fri, 29 Jul 2005 09:20:51 +0000
Content-class: urn:content-classes:message
Subject: RE: ARE: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Date: Fri, 29 Jul 2005 11:18:49 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>
Cc: "JP Vasseur" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Arthi

> AA---------> Actually the section on Assumptions where we introduce
> Auto-discovery does say that it would rely on IGP and/or BGP=20
> information.
> Would you just like us to expand that to include use of local=20
> policies in conjuction with the above information when there=20
> are sevaral downstream candidates ?

Yes that would be good, as actually, in an inter-SP context, such =
policies based on the so called "TE peering contracts" might be of huge =
importance...

Thanks,

JL

> -----Message d'origine-----
> De : Arthi Ayyangar [mailto:[email-masked]]=20
> Envoy=E9 : jeudi 28 juillet 2005 19:34
> =C0 : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : JP Vasseur; [email-masked]; [email-masked]
> Objet : Re: ARE: I-D=20
> ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
>=20
> Hi JL,
>=20
> (You seem to be on a roll...14 IDs down, 4 to go... :-))

:-)

>=20
> > A few comments related to your inter-domain pd draft
> AA---> Thanks for the comments.
>=20
> > -Section: 1) common assumptions, Why not adding and addressing the=20
> > case where a path is made of a set of abstract nodes? For=20
> instance, in=20
> > the inter-AS case, an ERO may list a set of ASes. This may require=20
> > specific procedures when computing the path and selecting=20
> the downstream ASBR...
> AA-------> True. This needs to be addressed. The procedures would=20
> AA-------> require
> interaction with BGP to find the ASBR exit point for the nexthop AS.
>=20
> > -Section 4: 1)  Even if this is not really in the scope I=20
> think that=20
> > the auto-discovery mechanism would require some more words. This is=20
> > partially addressed latter in the draft(4.2.1), but you=20
> should mention=20
> > here that such auto-discovery may rely on IGP information=20
> and/or BGP=20
> > information and also on local policies (particularly in inter-AS/SP=20
> > case). In the inter-AS/SP case there may be several candidate=20
> > downstream ASBRs, pertaining to distinct ASes/SPs, and the=20
> downstream=20
> > AS selection may require appying policies related to=20
> specific "TE peering contract"
> > negociated with neigbors Ases/SPs...
> AA---------> Actually the section on Assumptions where we introduce
> Auto-discovery does say that it would rely on IGP and/or BGP=20
> information.
> Would you just like us to expand that to include use of local=20
> policies in conjuction with the above information when there=20
> are sevaral downstream candidates ?

Yes that would be good, as actually in an inter-SP context these =
policies might be
of huge importance

>=20
>=20
> > -Section 4 2) b) ii) What do you exactly mean by "the=20
> boundary LSR is=20
> > not a FA-LSP/LSP segment candidate"? Does it mean in this=20
> case, that a=20
> > contigous LSP is created?, this would not be consistent with b)
> AA----> This is what happens when drafts are merged, split,=20
> re-named; etc.
> :-). One of the versions of the draft actually explained what=20
> "candidate"
> meant...Well...
>    This means that if the LSR has no local policy for nesting=20
> or stitching the inter-domain LSP, then it would simply set=20
> up a contiguous LSP.
>    Also, I think we need to fix the assumption that FA LSPs=20
> or LSP segments can exist only between domain boundary LSRs.=20
> It might be the case, but it is not necessary.
>=20
> > -Top of Section 4.1.1: You should remove the first sentence=20
> after the=20
> > three path examples, "At least the set", as this sounds an=20
> ambiguous=20
> > repetition of what is just stated above
> AA-----> Okay.
>=20
> > -Section 6.2: "If the Inter-AS TE related Information is flooded in=20
> > the IGP, each ASBR is capable of computing the path..."
> >
> > Actually there may be some topologies where an ASBR cannot=20
> compute a=20
> > link protection path.
> >
> > See the following example
> >
> > AS1-->   <---AS2----
> > ASBR1----ASBR2
> > |        |
> > |        |
> > ASBR3----ASBR4
> >
> > ASBR1 is aware of links ASBR1->ASBR2, ASBR1->ASBR3 and ASBR3->ASBR4=20
> > but not the link ASBR2->ASBR4 as there is no flooding=20
> between AS1 and AS2.
> > Hence ASBR1 cannot compute a path to protect link ASBR1-ASBR2.
> >
> > Actually this case is similar to node protection issue, the path=20
> > should be computed according to the pd computation methods=20
> defined in the doc.
> AA--------> I agree completely.
>=20
> >
> > Also it would be useful to mention that pd inter-domain backup path
> may requires XRO incusion in RSVP messages...
> AA-----> That's fine. This is useful for any computation=20
> where loose hop
> expansion occurs in different domains.
>=20
> > -Section 7.2
> >
> > "Note that stiching or nesting rely on local=20
> optimization...hence the=20
> > reoptimization is not global and... Procedures describes in=20
> loose hop=20
> > MUST be used... " It would be good to mention that global PCE-based=20
> > reoptimization (with potential change of border LSRs) also apply to=20
> > stiching/nesting.
> AA-------> I couldn't more.
>=20
> thanks,
> -arthi
>=20
> In both cases, contiguous or stiching/nesting, PCE or
> > any offline computation is required to achieve end-to-end=20
> > reoptimization.
>=20
>=20
> >
> >
> >
> >
> > > -----Message d'origine-----
> > > De : [email-masked]
> > > [mailto:[email-masked]] De la part de=20
> > > [email-masked] Envoy=E9 : vendredi 15 avril 2005=20
> 21:34 =C0 :=20
> > > [email-masked] Cc : [email-masked] Objet : I-D=20
> > > ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
> > >
> > > A New Internet-Draft is available from the on-line=20
> Internet-Drafts=20
> > > directories.
> > > This draft is a work item of the Common Control and Measurement=20
> > > Plane Working Group of the IETF.
> > >
> > > 	Title		: A Per-domain path computation method for
> > > 			  computing Inter-domain Traffic
> > > Engineering (TE)
> > > 			  Label Switched Path (LSP)
> > > 	Author(s)	: J. Vasseur, et al.
> > > 	Filename	:
> > > draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
> > > 	Pages		: 0
> > > 	Date		: 2005-4-15
> > >
> > > This document specifies a per-domain path computation method for=20
> > > computing inter-domain Traffic Engineering (TE)=20
> Multiprotocol Label=20
> > > Switching (MPLS) and Generalized MPLS
> > > (GMPLS) Label Switched (LSP) paths. In this document a domain is=20
> > > referred to as a collection of network elements within a common=20
> > > sphere of address management or path computational responsibility=20
> > > such as IGP areas and Autonomous Systems.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-dom
> > > ain-pd-path-comp-00.txt
> > >
> > > To remove yourself from the I-D Announcement list, send a=20
> message to=20
> > > [email-masked] with the word unsubscribe=20
> in the body=20
> > > of the message.
> > > You can also visit=20
> > > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > to change your subscription settings.
> > >
> > >
> > > Internet-Drafts are also available by anonymous FTP.=20
> Login with the=20
> > > username "anonymous" and a password of your e-mail address. After=20
> > > logging in, type "cd internet-drafts" and then
> > > 	"get draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt".
> > >
> > > A list of Internet-Drafts directories can be found in=20
> > > http://www.ietf.org/shadow.html or=20
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > > 	[email-masked].
> > > In the body type:
> > > 	"FILE
> > >=20
> /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt".
> > >
> > > NOTE:	The mail server at ietf.org can return the document in
> > > 	MIME-encoded form by using the "mpack" utility.  To use this
> > > 	feature, insert the command "ENCODING mime" before the "FILE"
> > > 	command.  To decode the response(s), you will need "munpack" or
> > > 	a MIME-compliant mail reader.  Different MIME-compliant mail=20
> > > readers
> > > 	exhibit different behavior, especially when dealing with
> > > 	"multipart" MIME messages (i.e. documents which have been split
> > > 	up into multiple messages), so check your local documentation on
> > > 	how to manipulate these messages.
> > >
> > >
> > > Below is the data which will enable a MIME compliant mail reader=20
> > > implementation to automatically retrieve the ASCII version of the=20
> > > Internet-Draft.
> > >
> >
>=20

Delivery-date: Fri, 29 Jul 2005 09:08:40 +0000
Cc: <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, <[email-masked]>
From: JP Vasseur <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Date: Fri, 29 Jul 2005 11:08:19 +0200
To: LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>

Hi Jean-Louis,

Thanks for the useful comments. We plan to submit a new revision =20
(including answer to Adrian's comments also) right after this IETF.

Cheers

JP.

On Jul 28, 2005, at 10:00 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote:

> Hi Arthi, JP
>
> Thanks for this new revision that sounds really good
>
> I have two commments:
>
> -In section 4.1.2 you partially describe bidirectional LSP =20
> stitching procedure.
> You mention that an Upstream Label MUST NOT be allocated by the end-=20=

> to-end LSP on the LSP segment, which is OK.
> But then how the LSP-Segment Egress will now that the end-to-end =20
> LSP is bidirectional? What about defining a flag in the Attributes =20
> Flags TLV of the LSP_ATTRIBUTE object so as to indicate that the =20
> LSP is bidirectional?
> Also the selection of the LSP segment in case of bidirectional LSP =20
> should be detailed (e.g. If the end-to-end LSP is bidirecitonal then
> the LSP-segment MUST be bidirectional. Also shall we allow that two =20=

> unidrectional end-to-end LSP use the same bidirectional LSP segment =20=

> (one in each direction)?
>
> -At the end of section 4.2.5 you mention that LSP-Segment failure =20
> or maintenance SHOULD be treated as a failure event for the end-to-=20
> end LSP. I agree for LSP-Segment failure but not for LSP-Segment =20
> maintenance. LSP-Segment maintenance should be treated as TE-link =20
> maintenance for the end-to-end LSP, and procedures defined in GMPLS =20=

> graceful TE-link shutdown draft may be useful (Specific RSVP error =20
> code and TE-link attribute)...
>
> Hope this helps,
>
> Best Regards
>
> JL
>
>
>
>> -----Message d'origine-----
>> De : [email-masked]
>> [mailto:[email-masked]] De la part de
>> [email-masked]
>> Envoy=E9 : vendredi 15 juillet 2005 21:50
>> =C0 : [email-masked]
>> Cc : [email-masked]
>> Objet : I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>> This draft is a work item of the Common Control and
>> Measurement Plane Working Group of the IETF.
>>
>>     Title        : Label Switched Path Stitching with
>> Generalized MPLS Traffic Engineering
>>     Author(s)    : A. Ayyangar, J. Vasseur
>>     Filename    : draft-ietf-ccamp-lsp-stitching-01.txt
>>     Pages        : 19
>>     Date        : 2005-7-15
>>
>> In certain scenarios, there may be a need to combine together two
>>    different Generalized Multi-Protocol Label Switching (GMPLS) Label
>>    Switched Paths (LSPs) such that in the data plane, a single end-=20=

>> to-
>>    end (e2e) LSP is achieved and all traffic from one LSP is switched
>>    onto the other LSP.  We will refer to this as "LSP
>> stitching".  This
>>    document covers cases where: a) the node performing the stitching
>>    does not require configuration of every LSP pair to be stitched
>>    together b) the node performing the stitching is not the egress of
>>    any of the LSPs c) LSP stitching not only results in an end-to-end
>>    LSP in the data plane, but there is also a corresponding end-to-=20=

>> end
>>    LSP (RSVP session) in the control plane.  It might be possible to
>>    configure a GMPLS node to switch the traffic from an LSP
>> for which it
>>    is the egress, to another LSP for which it is the ingress, without
>>    requiring any signaling or routing extensions whatsoever,
>> completely
>>    transparent to other nodes.  This will also result in LSP =20
>> stitching
>>    in the data plane.  However, this document does not cover this
>>    scenario of LSP stitching.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitc
>>
> hing-01.txt
>
>>
>> To remove yourself from the I-D Announcement list, send a
>> message to [email-masked] with the word
>> unsubscribe in the body of the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-=20
>> announce
>> to change your subscription settings.
>>
>>
>> Internet-Drafts are also available by anonymous FTP. Login
>> with the username "anonymous" and a password of your e-mail
>> address. After logging in, type "cd internet-drafts" and then
>>     "get draft-ietf-ccamp-lsp-stitching-01.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>     [email-masked].
>> In the body type:
>>     "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
>>
>> NOTE:    The mail server at ietf.org can return the document in
>>     MIME-encoded form by using the "mpack" utility.  To use this
>>     feature, insert the command "ENCODING mime" before the "FILE"
>>     command.  To decode the response(s), you will need "munpack" or
>>     a MIME-compliant mail reader.  Different MIME-compliant
>> mail readers
>>     exhibit different behavior, especially when dealing with
>>     "multipart" MIME messages (i.e. documents which have been split
>>     up into multiple messages), so check your local documentation on
>>     how to manipulate these messages.
>>
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>

Delivery-date: Fri, 29 Jul 2005 09:05:51 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Date: Fri, 29 Jul 2005 11:02:17 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi Arthi,

Please see inline=20

> -----Message d'origine-----
> De : Arthi Ayyangar [mailto:[email-masked]]=20
> Envoy=E9 : jeudi 28 juillet 2005 18:17
> =C0 : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [email-masked]; [email-masked]
> Objet : RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt=20
>=20
> Hi JL,
>=20
> Thanks for the comments.
>=20
> > -In section 4.1.2 you partially describe bidirectional LSP=20
> stitching=20
> > procedure. You mention that an Upstream Label MUST NOT be=20
> allocated by=20
> > the end-to-end LSP on the LSP segment, which is OK. But=20
> then how the=20
> > LSP-Segment Egress will now that the end-to-end LSP is=20
> bidirectional?
> AA--------> Excellent point.
>=20
> > What about defining a flag in the Attributes Flags TLV of the=20
> > LSP_ATTRIBUTE object so as to indicate that the LSP is=20
> bidirectional?
> AA------> That would be a change to the processing that GMPLS=20
> nodes use=20
> AA------> to
> detect bidirectionality, isn't it ? Normally nodes look for=20
> the Upstream Label object to detect bidirectionality.
>=20
> So let us say that an LSP is bidirectional if a) an Upstream=20
> Label is present or b) no Upstream Label, but bit set in=20
> LSP_ATTRIBUTE or c) both However, reliance on an e2e=20
> attributes bit set by head end, means existing head ends will=20
> not be setting this bit, so that will be an issue (wrt compatibility).

JLLR: I agree this may raise some backward compatibility issues.
This would require that head-ends be upgraded...

>=20
> Could be nice if this signaling was just between the node=20
> doing the stitching and the end point of the LSP segment,=20
> since this is the hop that the bidirectionality information=20
> is lost. Let me think about this.

JLLR: Yes, and what about defining a new MPLS label value, let say label =
4 =3D "No label assigned", with a semantic distinct from label 3 =
semantic (=3Dlabel pop). The UPSTREAM label object with this new label =
value  would be included in the end-to-end Path message over the =
LSP-Segment...

Let discuss this point during Paris meeting,

Regards,

JL

>=20
>=20
> > Also the selection of the LSP segment in case of bidirectional LSP=20
> > should be detailed (e.g. If the end-to-end LSP is=20
> bidirecitonal then=20
> > the LSP-segment MUST be bidirectional. Also shall we allow that two=20
> > unidrectional end-to-end LSP use the same bidirectional LSP segment=20
> > (one in each direction)?
> AA----> Yes, this should be okay. IMO.
>=20
> > -At the end of section 4.2.5 you mention that LSP-Segment=20
> failure or=20
> > maintenance SHOULD be treated as a failure event for the=20
> end-to-end LSP.
> > I agree for LSP-Segment failure but not for LSP-Segment maintenance.
> > LSP-Segment maintenance should be treated as TE-link=20
> maintenance for=20
> > the end-to-end LSP, and procedures defined in GMPLS=20
> graceful TE-link=20
> > shutdown draft may be useful (Specific RSVP error code and TE-link=20
> > attribute)...
> AA---> Yes, I agree; we will mention this. Actually the graceful=20
> AA---> teardown
> sentence occurs few paragraphs before, but not in the right=20
> context. So we will clarify the above.
>=20
> > Hope this helps,
> AA--->  Sure does.
>=20
>=20
> Thanks!
>=20
> -arthi
>=20
> >
> >
> > > -----Message d'origine-----
> > > De : [email-masked]
> > > [mailto:[email-masked]] De la part de=20
> > > [email-masked] Envoy=E9 : vendredi 15 juillet=20
> 2005 21:50 =C0 :=20
> > > [email-masked] Cc : [email-masked] Objet : I-D=20
> > > ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
> > >
> > > A New Internet-Draft is available from the on-line=20
> Internet-Drafts=20
> > > directories.
> > > This draft is a work item of the Common Control and Measurement=20
> > > Plane Working Group of the IETF.
> > >
> > > 	Title		: Label Switched Path Stitching with
> > > Generalized MPLS Traffic Engineering
> > > 	Author(s)	: A. Ayyangar, J. Vasseur
> > > 	Filename	: draft-ietf-ccamp-lsp-stitching-01.txt
> > > 	Pages		: 19
> > > 	Date		: 2005-7-15
> > >
> > > In certain scenarios, there may be a need to combine together two
> > >    different Generalized Multi-Protocol Label Switching=20
> (GMPLS) Label
> > >    Switched Paths (LSPs) such that in the data plane, a=20
> single end-to-
> > >    end (e2e) LSP is achieved and all traffic from one LSP=20
> is switched
> > >    onto the other LSP.  We will refer to this as "LSP=20
> stitching". =20
> > > This
> > >    document covers cases where: a) the node performing=20
> the stitching
> > >    does not require configuration of every LSP pair to be stitched
> > >    together b) the node performing the stitching is not=20
> the egress of
> > >    any of the LSPs c) LSP stitching not only results in=20
> an end-to-end
> > >    LSP in the data plane, but there is also a=20
> corresponding end-to-end
> > >    LSP (RSVP session) in the control plane.  It might be=20
> possible to
> > >    configure a GMPLS node to switch the traffic from an LSP for=20
> > > which it
> > >    is the egress, to another LSP for which it is the=20
> ingress, without
> > >    requiring any signaling or routing extensions whatsoever,=20
> > > completely
> > >    transparent to other nodes.  This will also result in=20
> LSP stitching
> > >    in the data plane.  However, this document does not cover this
> > >    scenario of LSP stitching.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitc
> > hing-01.txt
> > >
> > > To remove yourself from the I-D Announcement list, send a=20
> message to=20
> > > [email-masked] with the word unsubscribe=20
> in the body=20
> > > of the message.
> > > You can also visit=20
> > > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > to change your subscription settings.
> > >
> > >
> > > Internet-Drafts are also available by anonymous FTP.=20
> Login with the=20
> > > username "anonymous" and a password of your e-mail address. After=20
> > > logging in, type "cd internet-drafts" and then
> > > 	"get draft-ietf-ccamp-lsp-stitching-01.txt".
> > >
> > > A list of Internet-Drafts directories can be found in=20
> > > http://www.ietf.org/shadow.html or=20
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > > 	[email-masked].
> > > In the body type:
> > > 	"FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
> > >
> > > NOTE:	The mail server at ietf.org can return the document in
> > > 	MIME-encoded form by using the "mpack" utility.  To use this
> > > 	feature, insert the command "ENCODING mime" before the "FILE"
> > > 	command.  To decode the response(s), you will need "munpack" or
> > > 	a MIME-compliant mail reader.  Different MIME-compliant mail=20
> > > readers
> > > 	exhibit different behavior, especially when dealing with
> > > 	"multipart" MIME messages (i.e. documents which have been split
> > > 	up into multiple messages), so check your local documentation on
> > > 	how to manipulate these messages.
> > >
> > >
> > > Below is the data which will enable a MIME compliant mail reader=20
> > > implementation to automatically retrieve the ASCII version of the=20
> > > Internet-Draft.
> > >
> >
>=20

Delivery-date: Fri, 29 Jul 2005 07:33:39 +0000
From: "Adrian Farrel" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Proposed liaison to SG15 on RFC 4139
Date: Fri, 29 Jul 2005 08:32:54 +0100

Hi, 

I propose to send this liaison to Study Group 15 of the ITU-T. 

Comments please. 

Thanks,
Adrian 

======= 

To: ITU-T Study Group 15
From: IETF CCAMP Working Group
Subject: New Request for Comment Published
For: Information 

The CCAMP Working Group of the IETF wishes to inform Study Group 15 of the 
ITU-T of the publication of a new Request for Comment. 

RFC 4139 "Requirements for Generalized MPLS (GMPLS) Signaling Usage and 
Extensions for Automatically Switched Optical Network (ASON)" is available 
from the RFC Editor's repository at 
ftp://ftp.rfc-editor.org/in-notes/rfc4139.txt 

The Abstract of this RFC reads as follows. 

  The Generalized Multi-Protocol Label Switching (GMPLS) suite of
  protocols has been defined to control different switching
  technologies and different applications.  These include support
  for requesting Time Division Multiplexing (TDM) connections, including
  Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy
  (SDH) and Optical Transport Networks (OTNs).

  This document concentrates on the signaling aspects of the GMPLS
  suite of protocols.  It identifies the features to be covered by the
  GMPLS signaling protocol to support the capabilities of an
  Automatically Switched Optical Network (ASON).  This document provides
  a problem statement and additional requirements for the GMPLS
  signaling protocol to support the ASON functionality. 

The CCAMP Working Group would like to thank the members and Questions of 
Study Group 15 for the helpful input and review feedback that they provided 
while this document was being developed. 

Regards,
Adrian Farrel and Kireeti Kompella
CCAMP Working Group Co-chairs 

Delivery-date: Fri, 29 Jul 2005 07:33:27 +0000
From: "Adrian Farrel" <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Subject: New CCAMP RFC
Date: Fri, 29 Jul 2005 08:31:24 +0100

Thanks to everyone involved.
Not quite sure how this RFC jumped the queue, but good to have it
published. 

Adrian
 ----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 27, 2005 11:37 PM
Subject: RFC 4139 on Requirements for Generalized MPLS (GMPLS)
SignalingUsage and Extensions for Automatically Switched OpticalNetwork
(ASON) 

>
> A new Request for Comments is now available in online RFC libraries. 
>
>
>         RFC 4139 
>
>         Title:      Requirements for Generalized MPLS (GMPLS)
>                     Signaling Usage and Extensions for Automatically
>                     Switched Optical Network (ASON)
>         Author(s):  D. Papadimitriou, J. Drake, J. Ash, A. Farrel,
>                     L. Ong
>         Status:     Informational
>         Date:       July 2005
>         Mailbox:    [email-masked],
>                     [email-masked], [email-masked],
>                     [email-masked], [email-masked]
>         Pages:      16
>         Characters: 36660
>         Updates/Obsoletes/SeeAlso:    None 
>
>         I-D Tag:    draft-ietf-ccamp-gmpls-ason-reqts-07.txt 
>
>         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4139.txt 
>
>
> The Generalized Multi-Protocol Label Switching (GMPLS) suite of
> protocols has been defined to control different switching
> technologies and different applications.  These include support
> for requesting Time Division Multiplexing (TDM) connections, including
> Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy
> (SDH) and Optical Transport Networks (OTNs). 
>
> This document concentrates on the signaling aspects of the GMPLS
> suite of protocols.  It identifies the features to be covered by the
> GMPLS signaling protocol to support the capabilities of an
> Automatically Switched Optical Network (ASON).  This document provides
> a problem statement and additional requirements for the GMPLS
> signaling protocol to support the ASON functionality. 
>
> This document is a product of the Common Control and Measurement Plane
> Working Group of the IETF. 
>
> This memo provides information for the Internet community.  It does
> not specify an Internet standard of any kind.  Distribution of this
> memo is unlimited. 
>
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [email-masked].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [email-masked]. 
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [email-masked] with the message body
> help: ways_to_get_rfcs.  For example: 
>
>         To: [email-masked]
>         Subject: getting rfcs 
>
>         help: ways_to_get_rfcs 
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution. 
>
> Submissions for Requests for Comments should be sent to
> [email-masked].  Please consult RFC 2223, Instructions to RFC
> Authors, for further information. 
>
>
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute

Delivery-date: Fri, 29 Jul 2005 01:20:15 +0000
Date: Fri, 29 Jul 2005 10:17:44 +0900
From: "K. Miyazaki" <[email-masked]>
To: [email-masked]
Subject: Re: draft-otani-ccamp-interas-gmpls-te-03.txt

Hi everyone,

I think following draft is important requirement in GMPLS
inter-domain and it should be WG document asap.

Regards,

Keiji Miyazaki

Tomohiro Otani wrote:
> Hi everyone,
> 
> We updated the GMPLS inter-domain TE req. draft.  Since last meeting,
> we believe this document has been already stable and well-recognized, 
> however, per the last meeting discussion, we have to wait for the 
> charter being revised, in order to be a WG document (This must be 
> initiated by chairs).
> 
> Until then, we continue to update the contents and indeed welcome your 
> feedback and comments through this list or during the meeting in Paris.
> 
> Regards,
> 
> tomo
> 
> 
> 
> 
> -----------------------------------------------------------------------------
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: GMPLS Inter-domain Traffic Engineering Requirements
> 	Author(s)	: T. Otani, et al.
> 	Filename	: draft-otani-ccamp-interas-gmpls-te-03.txt
> 	Pages		: 15
> 	Date		: 2005-7-20
> 	
> This draft provides requirements for the support of generalized 
> multi-protocol label switching (GMPLS) inter-domain traffic 
> engineering (TE). Its main objective is to present the differences 
> between MPLS inter-domain TE and GMPLS inter-domain TE.  This draft 
> covers not only GMPLS Inter-domain architecture but also functional 
> requirements in terms of GMPLS signaling and routing in order to 
> specify these in a GMPLS Inter-domain environment.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-03.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> i-d-announce-request at ietf.org with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-otani-ccamp-interas-gmpls-te-03.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

Delivery-date: Thu, 28 Jul 2005 22:55:03 +0000
Cc: Adrian Farrel <[email-masked]>, [email-masked], [email-masked], Arthi Ayyangar <[email-masked]>
From: JP Vasseur <[email-masked]>
Subject: Re: Early chair review of draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Date: Fri, 29 Jul 2005 00:53:23 +0200
To: Adrian Farrel <[email-masked]>

Thanks for your comments Adrian. I hadn't missed it, just did not =20
find the time to reply yet ... More after this IETF.

Thanks.

JP.

On Jul 28, 2005, at 9:18 PM, Arthi Ayyangar wrote:

> Hi Adrian,
>
> Thanks for your exhaustive review and comments.
> Looks like I missed this mail. Sorry about that.
>
> Please see inline for my replies to some questions/issues raised. For
> formatting issues, I will turn to JP so that we can address them in =20=

> the
> next rev. Thanks!
>
>
>> I have not caught all of the typos, I am sure. Also worried that the
>> number of changes needed may have obscured some technical issues, =20
>> so we
>> will have to go around this at least once more.
>>
> AA-----> Fair enough.
>
>
>> ## The next paragraph is a bit unclear. Why not it with...
>> ## Per-domain computation applies where the full route to an
>> ## inter-domain LSP cannot be or is not determined at the ingress
>> ## point of the LSP, and is not signaled across domain boundaries.
>> ## This is most likely to arrise owing to TE visibilty limitations.
>> ## The signaling message indicates the destination and nodes up to
>> ## the next domain boundary. It may also indicate further domain
>> ## boundaries or domain identifiers. The route through each domain,
>> ## possibly including the choice of exit point from the domain,
>> ## must be determined within the domain.
>>
> AA-------> Sounds better to me.
>
>
>> The principle of per-domain path computation specified in this =20
>> document
>> comprises of a GMPLS or MPLS node along an inter-domain LSP path,
>> computing a path up to the last reachable hop within its domain. It
>> covers cases where this last hop (domain exit point) may already be
>> specified in the signaling message as well the case where this =20
>> last hop
>> may need to be determined by the GMPLS node.
>>
>>
>
>
>> ABR Routers: routers used to connect two IGP areas (areas in OSPF or
>> L1/L2 in IS-IS)
>> ##replace "L1/L2" with "levels"
>>
> AA----> Yep.
>
>
>> ## Missing ASBR. Just point to Interconnect routers
>>
> AA----> Okay.
>
>
>
>> Boundary LSR: a boundary LSR is either an ABR in the context of =20
>> inter-
>> area MPLS TE or an ASBR in the context of inter-AS MPLS TE.
>>
>> Bypass Tunnel: an LSP that is used to protect a set of LSPs passing
>> over a common facility.
>>
>> CSPF: Constraint-based Shortest Path First.
>> ## I searched for the uses of this acronym and I thought all of them
>> ## should be less specific (that is allowing any path computation
>> ## technique). In which case, you will not need this in the =20
>> terminology
>> ## section.
>>
> AA---> That is true.
>
> <snipped>
>
>>
>> ## The next paragpraph is true but irrelevant to this I-D.
>>
> AA---> Agree.
>
>> There are different ways in which inter-domain TE LSP path =20
>> computation
>> may be performed. For example, if the requirement is to get an end-=20=

>> to-
>> end constraint-based shortest path across multiple domains, then a
>> mechanism using one or more distributed PCEs could be used to compute
>> the shortest path across different domains. Alternatively, one could
>> also use some static or discovery mechanisms to determine the next
>> boundary LSR per domain as the inter-domain TE LSP is being signaled.
>> Other offline mechanisms for path computation are not precluded =20
>> either.
>> Depending on the Service Provider=C6s requirements, one may adopt =20
>> either
>> of these techniques for inter-domain path computation.
>>
>>
> <snipped>
>
>
>> ## Why do you mention CSPF? The path computation algorithm in use is
>> ## surely not relevant to this I-D.
>>
> AA----> Agree.
>
>
>> Note that PCE-based path computation may be mentioned in this =20
>> document
>> for the sake of reference but such techniques are outside the =20
>> scope of
>> this document.
>> ## Then don't mention them.
>>
> AA----> :-)
>
>
>> ## Do you need to say that you also support the case where area2 is
>> ## not a spearate area, but is part of area 1?
>> ##
>> ## Do you support routing across (i.e. into and out of) an area
>> ## that is not area zero?
>>
> AA----> Don't see why not.
>
>
>> - The various ASBRs are BGP peers, without any IGP running on the
>> single hop links interconnecting the ASBRs and also referred to as
>> inter-ASBR links,
>> ## Whoah! I hope you will explain why you *need* to run BGP, and
>> ## how you will manage non-TE distribution of reachability
>> ## information when the destination of a TE-LSP is a TE address.
>> ## Will you perhaps be mandating (stronger than recommending) that
>> ## the destination of an inter-AS TE LSP is the TE Router ID of
>> ## the egress in order to be sure that this address is one of the
>> ## reachable addresses advertised by BGP?
>>
> AA--------> See below.
>
>
>
>> hop at least has IP reachability (via IGP or BGP). If the next-hop is
>> not reachable, then the path computation stops and the LSR sends =20
>> back a
>> PathErr upstream. If the next-hop is reachable, then it finds an
>> ABR/ASBR to get to the next-hop. In the absence of an auto-discovery
>> mechanism, the ABR in the case of inter-area TE or the ASBR in the
>> next-hop AS in the case of inter-AS TE should be the loose next-=20
>> hop in
>> the ERO and hence should be accessible via the TED, otherwise the =20
>> path
>> computation for the inter-domain TE LSP will fail.
>> ## I would like you to make it VERY clear what you are doing here.
>> ## You are using the Routing Database to make TE routing decisions.
>> ## This may (or may not) be OK in people's minds
>> ## I will send separate mail to the CCAMP list because this is a BIG
>> ## DEAL in GMPLS networks.
>>
> AA---> I noticed the mail that you sent out. Thanks! However, there =20=

> have
> been no replies yet. But I think this ID does state that that if =20
> the next
> hop is not in the TED and does not have IP reachability, then such a
> computation would fail. Should we raise this point again either at the
> WG meeting or when we post the next rev ?
>
>
>> ## In any case, can you please clarify that this process MUST NOT be
>> ## used when the next-hop is within the same domain but does not
>> ## appear in the TED, or does not have TE connectivity available.
>>
> AA-------> Okay, this will be clarified.
>
> <snipped>
>
>>              or LSP segment(s) already exist, then it SHOULD try to
>>              select from among those intra-area/AS LSPs. Depending
>>              on local policy, it MAY signal a new FA-LSP/LSP segment
>>              if this selection fails. If the FA-LSP/LSP segment is
>>              successfully signaled or selected, it propagates the
>>              inter-domain Path message to the next-hop following the
>>              procedures described in [LSP-HIER]. If, for some reason
>>              the dynamic FA-LSP/LSP segment setup to the next-hop
>>              boundary LSR fails, the path computation stops and a
>> ## Is it the path computation that stops?
>> ## Is there no scope for retires or fall-back to ordinary routing?
>>
> AA-------> This is the case which JL mentioned as well in his email.
> There could be multiple exit points and if one fails, then another =20
> could
> be tried based on routing information and local policies. So I =20
> agree that
> a retry is possible and  if all attempts fail then an error is =20
> propagated.
>
>
> <snipped>
>
>> 4.1.   Example with an inter-area TE LSP
>>
>> 4.1.1.  Case 1: T1 is a contiguous TE LSP
>>
>> ## I think your example should start at the ingress! It seems you
>> ## cut back to that after the first paragraph.
>>
> AA---> Okay.
>
>
>
>> ## What does the user supply? What does the ingress compute?
>> ## How is ABR1 selected? (I like ABR2: it is a nicer color. Why
>> ## can't I have ABR2?)
>> ## There is also some repeated text in this section.
>> ## Also, why are you considering Example 1 since it is out of scope
>> ## for you?
>>
> AA--------> Not clear to me what is out of scope and why ?
>
>
>> ## Presumably, Example 3 only applies if areas 1 and 2 are actually
>> ## part of the same area, so you should say so.
>>
>> When the path message reaches ABR1, it first determines the egress =20=

>> LSR
>> from its area 0 along the LSP path (say ABR=C61), either directly =
from
>> the ERO (if for example the next hop ABR is specified as a loose =20
>> hop in
>> the ERO) or by using some constraint-aware auto-discovery =20
>> mechanism. In
>> ## Wow! "A constraint-aware auto-discovery mechanism." I borrowed
>> ## one of those from Batman once, but I could never get it to work.
>>
> AA---------> :-)
>
>
>> ## What are you talking about?
>> ## Yes, I see this in section 3, 1) and in section 4, 1) but it does
>> ## not explain what you are suggesting may exist. I must say it =20
>> sounds
>> ## suspisciously like TE aggregation advertisement using BGP.
>>
> AA-------> I don't think "constraint-aware" stuff is relevant to this
> document and I am okay with getting rid of it. We need discovery of =20=

> exit
> points...but that's about it.
>
>
> <snipped>
>
>>
>> ## Can you explain why the TE information pertaining to the inter-AS
>> ## links *needs* to be flooded within the ASs?
>>
> AA-----> Hmm...I don't think we say that TE information for =20
> inter_AS links
> *needs* to be flooded. See below for answer to why ?
>
> It is surely enough that
>
>> ## the ASBRs have access to the TE information about their own TE =20
>> links.
>>
> AA----> Yes they do, but the previous hop LSR in this AS that picked
> this ASBR as the exit point doesn't have that information. So, if =20
> the LSR
> selecting this ASBR had that information (and used it in path
> computation), then if the ASBR-ASBR link was a bottleneck, then it =20
> could
> have chosen another exit ASBR instead.
>
>
>> ## After all, you have defined that the ASBRs in the *next* AS can do
>> ## hop resolution and crankback. Why should the ASBRs in *this* AS =20=

>> also
>> ## not perform that operation if necessary?
>>
> AA---> Sure it can.
>
>
>> ## You are reducing the chance of call setup failure at the =20
>> expense of
>> ## increasing the scope of the TE information flooded. But we know
>> ## how that works!
>>
> AA-----> How many ASBR-ASBR links are we talking about ?
>
> <snipped>
>
>> 4.2.2.  Case 2: T1 is a stitched or nested TE LSP
>>
>> The signaling procedures are very similar to the inter-area LSP setup
>> case described earlier. In this case, the FA-LSPs or LSP segments =20
>> will
>> only be originated by the ASBRs at the entry to the AS.
>> ## This is a really important point that you should bring out a bit!
>> ## An FA cannot exist out of the IGP instance that contains its
>> ## component TE links.
>> ## What about non-FAs? Could I operate a stitched segment for just =20=

>> the
>> ## link between ASBRs? I think so. Indeed, I might want to.
>> ## Could I run a hierarchical LSP for just the link between ASBRs? =20=

>> Yes
>> ## although I am not convinced it adds value, but maybe there is some
>> ## administrative benefit when crossing a trust boundary (for =20
>> example,
>> ## all I have to do is count the packets with one label).
>>
> AA-------> Is your point that FA-LSPs and LSP segments can =20
> originate and
> terminate on any a) boundary node or b) any other node that has local
> configuration/policy to do so (for originating) ? If yes, then I =20
> agree. I
> think this ID needs to be fixed to explicitly state that.
>
> <snipped>
>
>>
>> 6.     MPLS Traffic Engineering Fast Reroute for inter-domain TE LSPs
>> ## The following section is valuable in the context of the popularity
>> ## of RFC 4090, but you cannot produce this I-D in CCAMP without also
>> ## discussing the use of Segment Protection to achieve the same
>> ## function in the data plane.
>>
> AA-------> Agree.
>
>
> <snipped>
>
>> 7.1.   Contiguous TE LSPs
>>
>> ## Need to generalize this section for areas, etc.
>>
>> After an inter-AS TE LSP has been set up, a more optimal route might
>> appear in the various traversed ASes. Then in this case, it is
>> desirable to get the ability to reroute an inter-AS TE LSP in a non-
>> disruptive fashion (making use of the so called Make Before Break
>> procedure) to follow this more optimal path. This is a known as a TE
>> LSP reoptimization procedure.
>>
>> ## Is there any requirement to redescribe the procedures of
>> ## [LOOSE-PATH-REOPT]? Why not simply state that...
>> ## [LOOSE-PATH-REOPT] describes a mechanism to control discovery
>> ## or more optimal paths, and to signal new paths using make before
>> ## break.
>>
> AA----> Nope, no need at all.
>
>
>> #### BEGIN DELETE
>> #
>> #
>>
>> [LOOSE-REOPT] proposes a mechanisms allowing:
>> ## s/[LOOSE-REOPT]/[LOOSE-PATH-REOPT]/ -- change throughout the doc
>> ## s/proposes/defines/
>>
>>
>>  Vasseur, Ayyangar and Zhang                                  14
>>
>>
>>
>> draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April =20=

>> 2005
>>
>>
>>       - The head-end LSR to trigger on every LSR whose next hop is a
>>       loose hop the re evaluation of the current path in order to
>> ## s/re evaluation/re-evaluation/
>>       detect a potentially more optimal path. This is done via
>>       explicit signaling request: the head-end LSR sets the =F4ERO
>>       Expansion request=F6 bit of the SESSION-ATTRIBUTE object =
carried
>>       in the RSVP Path message.
>>
>>       - An LSR whose next hop is a loose-hop to signal to the head-
>>       end LSR that a better path exists. This is performed by sending
>>       an RSVP Path Error Notify message (ERROR-CODE =3D 25), sub-code =
6
>>       (Better path exists).
>>
>>       This indication may be sent either:
>>
>>             - In response to a query sent by the head-end LSR,
>>              - Spontaneously by any LSR having detected a more
>>              optimal path
>>
>> Such a mechanism allows for the reoptimization of a TE LSP if and =20
>> only
>> if a better path is some downstream area/AS is detected.
>>
>> The reoptimization event can either be timer or event-driven based (a
>> link UP event for instance).
>>
>> Note that the reoptimization MUST always be performed in a non-
>> disruptive fashion.
>>
>> Once the head-end LSR is informed of the existence of a more optimal
>> path either in its head-end area/AS or in another AS, the inter-AS TE
>> Path computation is triggered using the same set of mechanisms as =20
>> when
>> the TE LSP is first set up. Then the inter-AS TE LSP is set up
>> following the more optimal path, making use of the make before break
>> procedure. In case of a contiguous LSP, the reoptimization process is
>> strictly controlled by the head-end LSR which triggers the make-=20
>> before-
>> break procedure, regardless of the location where the more optimal =20=

>> path
>> is.
>>
>> Note that in the case of loose hop reoptimization, the TE LSP may
>> follow a preferable path within one or more domain(s) whereas in the
>> case of PCE-based path computation techniques, the reoptimization
>> process may lead to following a completely different inter-domain =20
>> path
>> (including a different set of ABRs/ASBRs) since end-to-end shortest
>> path is computed.
>>
>> #
>> #
>> #### END DELETE
>>
>> 7.2.   Stitched or nested (non-contiguous) TE LSPs
>>
>> ## This section contains quite a lot of repetition.
>>
>> In the case of a stitched or nested inter-domain TE LSP, the re-
>> optimization process is treated as a local matter to any Area/AS. The
>> main reason is that the inter-domain TE LSP is a different LSP (and
>> therefore different RSVP session) from the intra-domain LSP =20
>> segment or
>>
>> ## Your causality is broken. Being a different LSP does not imply
>> ## being a different session. However, the key point *is* that this
>> ## is a different session (with different ingress and egress).
>>
> AA-----> We'll simply highlight that this is a different session.
>
> <snipped>
>
>
>> 8.     Security Considerations
>>
>> ## This section seems very lightweight given the importance of
>> ## inter-AS trust boundaries.
>>
> AA----> I agree. We should add details about policy control, trust
> relationship; etc . They may be an overlap with the signaling
> ID, but that's okay. Also, need to highlight how a boundary node =20
> (or any
> other node) would handle the case where it is being overwhelmed =20
> with path
> computation requests for an inter-domain LSP from some other domain.
>
> thanks,
> -arthi
>

Delivery-date: Thu, 28 Jul 2005 19:20:58 +0000
Date: Thu, 28 Jul 2005 12:18:49 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: Adrian Farrel <[email-masked]>
cc: "'Jean Philippe Vasseur'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Early chair review of draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt

Hi Adrian,

Thanks for your exhaustive review and comments.
Looks like I missed this mail. Sorry about that.

Please see inline for my replies to some questions/issues raised. For
formatting issues, I will turn to JP so that we can address them in the
next rev. Thanks!

> I have not caught all of the typos, I am sure. Also worried that the
> number of changes needed may have obscured some technical issues, so we
> will have to go around this at least once more.
AA-----> Fair enough.

> ## The next paragraph is a bit unclear. Why not it with...
> ## Per-domain computation applies where the full route to an
> ## inter-domain LSP cannot be or is not determined at the ingress
> ## point of the LSP, and is not signaled across domain boundaries.
> ## This is most likely to arrise owing to TE visibilty limitations.
> ## The signaling message indicates the destination and nodes up to
> ## the next domain boundary. It may also indicate further domain
> ## boundaries or domain identifiers. The route through each domain,
> ## possibly including the choice of exit point from the domain,
> ## must be determined within the domain.
AA-------> Sounds better to me.

> The principle of per-domain path computation specified in this document
> comprises of a GMPLS or MPLS node along an inter-domain LSP path,
> computing a path up to the last reachable hop within its domain. It
> covers cases where this last hop (domain exit point) may already be
> specified in the signaling message as well the case where this last hop
> may need to be determined by the GMPLS node.
>

> ABR Routers: routers used to connect two IGP areas (areas in OSPF or
> L1/L2 in IS-IS)
> ##replace "L1/L2" with "levels"
AA----> Yep.

> ## Missing ASBR. Just point to Interconnect routers
AA----> Okay.

> Boundary LSR: a boundary LSR is either an ABR in the context of inter-
> area MPLS TE or an ASBR in the context of inter-AS MPLS TE.
>
> Bypass Tunnel: an LSP that is used to protect a set of LSPs passing
> over a common facility.
>
> CSPF: Constraint-based Shortest Path First.
> ## I searched for the uses of this acronym and I thought all of them
> ## should be less specific (that is allowing any path computation
> ## technique). In which case, you will not need this in the terminology
> ## section.
AA---> That is true.

<snipped>
>
> ## The next paragpraph is true but irrelevant to this I-D.
AA---> Agree.
> There are different ways in which inter-domain TE LSP path computation
> may be performed. For example, if the requirement is to get an end-to-
> end constraint-based shortest path across multiple domains, then a
> mechanism using one or more distributed PCEs could be used to compute
> the shortest path across different domains. Alternatively, one could
> also use some static or discovery mechanisms to determine the next
> boundary LSR per domain as the inter-domain TE LSP is being signaled.
> Other offline mechanisms for path computation are not precluded either.
> Depending on the Service Provider=C6s requirements, one may adopt either
> of these techniques for inter-domain path computation.
>
<snipped>

> ## Why do you mention CSPF? The path computation algorithm in use is
> ## surely not relevant to this I-D.
AA----> Agree.

> Note that PCE-based path computation may be mentioned in this document
> for the sake of reference but such techniques are outside the scope of
> this document.
> ## Then don't mention them.
AA----> :-)

> ## Do you need to say that you also support the case where area2 is
> ## not a spearate area, but is part of area 1?
> ##
> ## Do you support routing across (i.e. into and out of) an area
> ## that is not area zero?
AA----> Don't see why not.

> - The various ASBRs are BGP peers, without any IGP running on the
> single hop links interconnecting the ASBRs and also referred to as
> inter-ASBR links,
> ## Whoah! I hope you will explain why you *need* to run BGP, and
> ## how you will manage non-TE distribution of reachability
> ## information when the destination of a TE-LSP is a TE address.
> ## Will you perhaps be mandating (stronger than recommending) that
> ## the destination of an inter-AS TE LSP is the TE Router ID of
> ## the egress in order to be sure that this address is one of the
> ## reachable addresses advertised by BGP?
AA--------> See below.

> hop at least has IP reachability (via IGP or BGP). If the next-hop is
> not reachable, then the path computation stops and the LSR sends back a
> PathErr upstream. If the next-hop is reachable, then it finds an
> ABR/ASBR to get to the next-hop. In the absence of an auto-discovery
> mechanism, the ABR in the case of inter-area TE or the ASBR in the
> next-hop AS in the case of inter-AS TE should be the loose next-hop in
> the ERO and hence should be accessible via the TED, otherwise the path
> computation for the inter-domain TE LSP will fail.
> ## I would like you to make it VERY clear what you are doing here.
> ## You are using the Routing Database to make TE routing decisions.
> ## This may (or may not) be OK in people's minds
> ## I will send separate mail to the CCAMP list because this is a BIG
> ## DEAL in GMPLS networks.
AA---> I noticed the mail that you sent out. Thanks! However, there have
been no replies yet. But I think this ID does state that that if the next
hop is not in the TED and does not have IP reachability, then such a
computation would fail. Should we raise this point again either at the
WG meeting or when we post the next rev ?

> ## In any case, can you please clarify that this process MUST NOT be
> ## used when the next-hop is within the same domain but does not
> ## appear in the TED, or does not have TE connectivity available.
AA-------> Okay, this will be clarified.

<snipped>
>              or LSP segment(s) already exist, then it SHOULD try to
>              select from among those intra-area/AS LSPs. Depending
>              on local policy, it MAY signal a new FA-LSP/LSP segment
>              if this selection fails. If the FA-LSP/LSP segment is
>              successfully signaled or selected, it propagates the
>              inter-domain Path message to the next-hop following the
>              procedures described in [LSP-HIER]. If, for some reason
>              the dynamic FA-LSP/LSP segment setup to the next-hop
>              boundary LSR fails, the path computation stops and a
> ## Is it the path computation that stops?
> ## Is there no scope for retires or fall-back to ordinary routing?
AA-------> This is the case which JL mentioned as well in his email.
There could be multiple exit points and if one fails, then another could
be tried based on routing information and local policies. So I agree that
a retry is possible and  if all attempts fail then an error is propagated.

<snipped>
> 4.1.   Example with an inter-area TE LSP
>
> 4.1.1.  Case 1: T1 is a contiguous TE LSP
>
> ## I think your example should start at the ingress! It seems you
> ## cut back to that after the first paragraph.
AA---> Okay.

> ## What does the user supply? What does the ingress compute?
> ## How is ABR1 selected? (I like ABR2: it is a nicer color. Why
> ## can't I have ABR2?)
> ## There is also some repeated text in this section.
> ## Also, why are you considering Example 1 since it is out of scope
> ## for you?
AA--------> Not clear to me what is out of scope and why ?

> ## Presumably, Example 3 only applies if areas 1 and 2 are actually
> ## part of the same area, so you should say so.
>
> When the path message reaches ABR1, it first determines the egress LSR
> from its area 0 along the LSP path (say ABR=C61), either directly from
> the ERO (if for example the next hop ABR is specified as a loose hop in
> the ERO) or by using some constraint-aware auto-discovery mechanism. In
> ## Wow! "A constraint-aware auto-discovery mechanism." I borrowed
> ## one of those from Batman once, but I could never get it to work.
AA---------> :-)

> ## What are you talking about?
> ## Yes, I see this in section 3, 1) and in section 4, 1) but it does
> ## not explain what you are suggesting may exist. I must say it sounds
> ## suspisciously like TE aggregation advertisement using BGP.
AA-------> I don't think "constraint-aware" stuff is relevant to this
document and I am okay with getting rid of it. We need discovery of exit
points...but that's about it.

<snipped>
>
> ## Can you explain why the TE information pertaining to the inter-AS
> ## links *needs* to be flooded within the ASs?
AA-----> Hmm...I don't think we say that TE information for inter_AS links
*needs* to be flooded. See below for answer to why ?

It is surely enough that
> ## the ASBRs have access to the TE information about their own TE links.
AA----> Yes they do, but the previous hop LSR in this AS that picked
this ASBR as the exit point doesn't have that information. So, if the LSR
selecting this ASBR had that information (and used it in path
computation), then if the ASBR-ASBR link was a bottleneck, then it could
have chosen another exit ASBR instead.

> ## After all, you have defined that the ASBRs in the *next* AS can do
> ## hop resolution and crankback. Why should the ASBRs in *this* AS also
> ## not perform that operation if necessary?
AA---> Sure it can.

> ## You are reducing the chance of call setup failure at the expense of
> ## increasing the scope of the TE information flooded. But we know
> ## how that works!
AA-----> How many ASBR-ASBR links are we talking about ?

<snipped>
> 4.2.2.  Case 2: T1 is a stitched or nested TE LSP
>
> The signaling procedures are very similar to the inter-area LSP setup
> case described earlier. In this case, the FA-LSPs or LSP segments will
> only be originated by the ASBRs at the entry to the AS.
> ## This is a really important point that you should bring out a bit!
> ## An FA cannot exist out of the IGP instance that contains its
> ## component TE links.
> ## What about non-FAs? Could I operate a stitched segment for just the
> ## link between ASBRs? I think so. Indeed, I might want to.
> ## Could I run a hierarchical LSP for just the link between ASBRs? Yes
> ## although I am not convinced it adds value, but maybe there is some
> ## administrative benefit when crossing a trust boundary (for example,
> ## all I have to do is count the packets with one label).
AA-------> Is your point that FA-LSPs and LSP segments can originate and
terminate on any a) boundary node or b) any other node that has local
configuration/policy to do so (for originating) ? If yes, then I agree. I
think this ID needs to be fixed to explicitly state that.

<snipped>
>
> 6.     MPLS Traffic Engineering Fast Reroute for inter-domain TE LSPs
> ## The following section is valuable in the context of the popularity
> ## of RFC 4090, but you cannot produce this I-D in CCAMP without also
> ## discussing the use of Segment Protection to achieve the same
> ## function in the data plane.
AA-------> Agree.

<snipped>
> 7.1.   Contiguous TE LSPs
>
> ## Need to generalize this section for areas, etc.
>
> After an inter-AS TE LSP has been set up, a more optimal route might
> appear in the various traversed ASes. Then in this case, it is
> desirable to get the ability to reroute an inter-AS TE LSP in a non-
> disruptive fashion (making use of the so called Make Before Break
> procedure) to follow this more optimal path. This is a known as a TE
> LSP reoptimization procedure.
>
> ## Is there any requirement to redescribe the procedures of
> ## [LOOSE-PATH-REOPT]? Why not simply state that...
> ## [LOOSE-PATH-REOPT] describes a mechanism to control discovery
> ## or more optimal paths, and to signal new paths using make before
> ## break.
AA----> Nope, no need at all.

> #### BEGIN DELETE
> #
> #
>
> [LOOSE-REOPT] proposes a mechanisms allowing:
> ## s/[LOOSE-REOPT]/[LOOSE-PATH-REOPT]/ -- change throughout the doc
> ## s/proposes/defines/
>
>
>  Vasseur, Ayyangar and Zhang                                  14
>
>
>
> draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt            April 2005
>
>
>       - The head-end LSR to trigger on every LSR whose next hop is a
>       loose hop the re evaluation of the current path in order to
> ## s/re evaluation/re-evaluation/
>       detect a potentially more optimal path. This is done via
>       explicit signaling request: the head-end LSR sets the =F4ERO
>       Expansion request=F6 bit of the SESSION-ATTRIBUTE object carried
>       in the RSVP Path message.
>
>       - An LSR whose next hop is a loose-hop to signal to the head-
>       end LSR that a better path exists. This is performed by sending
>       an RSVP Path Error Notify message (ERROR-CODE =3D 25), sub-code 6
>       (Better path exists).
>
>       This indication may be sent either:
>
>             - In response to a query sent by the head-end LSR,
>              - Spontaneously by any LSR having detected a more
>              optimal path
>
> Such a mechanism allows for the reoptimization of a TE LSP if and only
> if a better path is some downstream area/AS is detected.
>
> The reoptimization event can either be timer or event-driven based (a
> link UP event for instance).
>
> Note that the reoptimization MUST always be performed in a non-
> disruptive fashion.
>
> Once the head-end LSR is informed of the existence of a more optimal
> path either in its head-end area/AS or in another AS, the inter-AS TE
> Path computation is triggered using the same set of mechanisms as when
> the TE LSP is first set up. Then the inter-AS TE LSP is set up
> following the more optimal path, making use of the make before break
> procedure. In case of a contiguous LSP, the reoptimization process is
> strictly controlled by the head-end LSR which triggers the make-before-
> break procedure, regardless of the location where the more optimal path
> is.
>
> Note that in the case of loose hop reoptimization, the TE LSP may
> follow a preferable path within one or more domain(s) whereas in the
> case of PCE-based path computation techniques, the reoptimization
> process may lead to following a completely different inter-domain path
> (including a different set of ABRs/ASBRs) since end-to-end shortest
> path is computed.
>
> #
> #
> #### END DELETE
>
> 7.2.   Stitched or nested (non-contiguous) TE LSPs
>
> ## This section contains quite a lot of repetition.
>
> In the case of a stitched or nested inter-domain TE LSP, the re-
> optimization process is treated as a local matter to any Area/AS. The
> main reason is that the inter-domain TE LSP is a different LSP (and
> therefore different RSVP session) from the intra-domain LSP segment or
>
> ## Your causality is broken. Being a different LSP does not imply
> ## being a different session. However, the key point *is* that this
> ## is a different session (with different ingress and egress).
AA-----> We'll simply highlight that this is a different session.

<snipped>

> 8.     Security Considerations
>
> ## This section seems very lightweight given the importance of
> ## inter-AS trust boundaries.
AA----> I agree. We should add details about policy control, trust
relationship; etc . They may be an overlap with the signaling
ID, but that's okay. Also, need to highlight how a boundary node (or any
other node) would handle the case where it is being overwhelmed with path
computation requests for an inter-domain LSP from some other domain.

thanks,
-arthi

Delivery-date: Thu, 28 Jul 2005 17:40:16 +0000
Date: Thu, 28 Jul 2005 10:39:23 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>
cc: JP Vasseur <[email-masked]>, [email-masked], [email-masked]
Subject: Re: ARE: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt

> > "Note that stiching or nesting rely on local optimization...hence the
> > reoptimization is not global and... Procedures describes in loose hop
> > MUST be used... " It would be good to mention that global PCE-based
> > reoptimization (with potential change of border LSRs) also apply to
> > stiching/nesting.
                      agree
> AA-------> I couldn't ^ more.

-arthi

Delivery-date: Thu, 28 Jul 2005 17:34:49 +0000
Date: Thu, 28 Jul 2005 10:33:36 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>
cc: JP Vasseur <[email-masked]>, [email-masked], [email-masked]
Subject: Re: ARE: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt

Hi JL,

(You seem to be on a roll...14 IDs down, 4 to go... :-))

> A few comments related to your inter-domain pd draft
AA---> Thanks for the comments.

> -Section: 1) common assumptions, Why not adding and addressing the case
> where a path is made of a set of abstract nodes? For instance, in the
> inter-AS case, an ERO may list a set of ASes. This may require specific
> procedures when computing the path and selecting the downstream ASBR...
AA-------> True. This needs to be addressed. The procedures would require
interaction with BGP to find the ASBR exit point for the nexthop AS.

> -Section 4: 1)  Even if this is not really in the scope I think that the
> auto-discovery mechanism would require some more words. This is
> partially addressed latter in the draft(4.2.1), but you should mention
> here that such auto-discovery may rely on IGP information and/or BGP
> information and also on local policies (particularly in inter-AS/SP
> case). In the inter-AS/SP case there may be several candidate downstream
> ASBRs, pertaining to distinct ASes/SPs, and the downstream AS selection
> may require appying policies related to specific "TE peering contract"
> negociated with neigbors Ases/SPs...
AA---------> Actually the section on Assumptions where we introduce
Auto-discovery does say that it would rely on IGP and/or BGP information.
Would you just like us to expand that to include use of local policies
in conjuction with the above information when there are sevaral downstream
candidates ?

> -Section 4 2) b) ii) What do you exactly mean by "the boundary LSR is
> not a FA-LSP/LSP segment candidate"? Does it mean in this case, that a
> contigous LSP is created?, this would not be consistent with b)
AA----> This is what happens when drafts are merged, split, re-named; etc.
:-). One of the versions of the draft actually explained what "candidate"
meant...Well...
   This means that if the LSR has no local policy for nesting or stitching
the inter-domain LSP, then it would simply set up a contiguous LSP.
   Also, I think we need to fix the assumption that FA LSPs or LSP
segments can exist only between domain boundary LSRs. It might be the
case, but it is not necessary.

> -Top of Section 4.1.1: You should remove the first sentence after the
> three path examples, "At least the set", as this sounds an ambiguous
> repetition of what is just stated above
AA-----> Okay.

> -Section 6.2: "If the Inter-AS TE related Information is flooded in the
> IGP, each ASBR is capable of computing the path..."
>
> Actually there may be some topologies where an ASBR cannot compute a
> link protection path.
>
> See the following example
>
> AS1-->   <---AS2----
> ASBR1----ASBR2
> |        |
> |        |
> ASBR3----ASBR4
>
> ASBR1 is aware of links ASBR1->ASBR2, ASBR1->ASBR3 and ASBR3->ASBR4 but
> not the link ASBR2->ASBR4 as there is no flooding between AS1 and AS2.
> Hence ASBR1 cannot compute a path to protect link ASBR1-ASBR2.
>
> Actually this case is similar to node protection issue, the path should
> be computed according to the pd computation methods defined in the doc.
AA--------> I agree completely.

>
> Also it would be useful to mention that pd inter-domain backup path
may requires XRO incusion in RSVP messages...
AA-----> That's fine. This is useful for any computation where loose hop
expansion occurs in different domains.

> -Section 7.2
>
> "Note that stiching or nesting rely on local optimization...hence the
> reoptimization is not global and... Procedures describes in loose hop
> MUST be used... " It would be good to mention that global PCE-based
> reoptimization (with potential change of border LSRs) also apply to
> stiching/nesting.
AA-------> I couldn't more.

thanks,
-arthi

In both cases, contiguous or stiching/nesting, PCE or
> any offline computation is required to achieve end-to-end
> reoptimization.

>
>
>
>
> > -----Message d'origine-----
> > De : [email-masked]
> > [mailto:[email-masked]] De la part de
> > [email-masked]
> > Envoy=E9 : vendredi 15 avril 2005 21:34
> > =C0 : [email-masked]
> > Cc : [email-masked]
> > Objet : I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> > This draft is a work item of the Common Control and
> > Measurement Plane Working Group of the IETF.
> >
> > =09Title=09=09: A Per-domain path computation method for
> > =09=09=09  computing Inter-domain Traffic
> > Engineering (TE)
> > =09=09=09  Label Switched Path (LSP)
> > =09Author(s)=09: J. Vasseur, et al.
> > =09Filename=09:
> > draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
> > =09Pages=09=09: 0
> > =09Date=09=09: 2005-4-15
> >
> > This document specifies a per-domain path computation method
> > for computing inter-domain Traffic Engineering (TE)
> > Multiprotocol Label Switching (MPLS) and Generalized MPLS
> > (GMPLS) Label Switched (LSP) paths. In this document a domain
> > is referred to as a collection of network elements within a
> > common sphere of address management or path computational
> > responsibility such as IGP areas and Autonomous Systems.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-dom
> > ain-pd-path-comp-00.txt
> >
> > To remove yourself from the I-D Announcement list, send a
> > message to [email-masked] with the word
> > unsubscribe in the body of the message.
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> > with the username "anonymous" and a password of your e-mail
> > address. After logging in, type "cd internet-drafts" and then
> > =09"get draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > =[email-masked].
> > In the body type:
> > =09"FILE
> > /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt".
> >
> > NOTE:=09The mail server at ietf.org can return the document in
> > =09MIME-encoded form by using the "mpack" utility.  To use this
> > =09feature, insert the command "ENCODING mime" before the "FILE"
> > =09command.  To decode the response(s), you will need "munpack" or
> > =09a MIME-compliant mail reader.  Different MIME-compliant
> > mail readers
> > =09exhibit different behavior, especially when dealing with
> > =09"multipart" MIME messages (i.e. documents which have been split
> > =09up into multiple messages), so check your local documentation on
> > =09how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
>

Delivery-date: Thu, 28 Jul 2005 17:04:15 +0000
Date: Thu, 28 Jul 2005 10:03:18 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: Igor Bryskin <[email-masked]>
cc: [email-masked], Igor Bryskin <[email-masked]>, [email-masked]
Subject: Re: LSP stitching questions for discussion

Thanks Dimitri, Igor and Adrian for posting your answers.

There seems to be agreement that the procedures are applicable to both
PSC and non-PSC LSPs. Good.

As expected, the main disagreement is whether stitching should or should
not be allowed when region boundaries (SC based) are traversed. I
tend to agree with Dimitri and Igor on this. Just because it is possible,
doesn't mean it should be allowed, especially given that one can use
hierarchical LSPs for this purpose.

However, to Adrian's point about "declaring a specific hardware
deployment illegal in the control plane", it would be useful to understand
this scenario wrt what is done in data plane and in control plane and is
there any benefit of this behavior.

I will try to capture this discussion in the presentation at the WG
meeting.

thanks,
-arthi

> [dp] ok - last try for an end-to-end PSC-1 LSP of 2MB you could make use
> of a PSC-1 segment of 4MB
>
> Ah, Ok. I see your point and agree.
>
> Igor
>
>
> You are right: whether PSC1 and PSC2 are separate network layers or not
> is a topic of a separate (painful :=)) discussion. However, I just
> wanted to point out here that a PSC2 LSP is a provisioned as such for a
> reason: it is meant to *nest* PSC1 LSPs rather than to stitch them. From
> the VNT management point of view PSC2 and PSC1 are separate topological
> layers. that is PSC2 produces topology for PSC1, just like VC4 produces
> topology for VC12. The only difference is that in the latter case this
> relationship is forced by the hardware, and in the former case is not
> (just logical). Take for example C and C++ programming. Certain things
> you simply forced not to do in C++, whereas in C you could but
> shouldn't.
>
> See you in Paris.
> Igor
>
>
>
>
> "Igor Bryskin" <[email-masked]>
> Sent by: [email-masked]
> 07/20/2005 13:25 AST
>
> To: "Arthi Ayyangar" <[email-masked]>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: <[email-masked]> bcc:
> Subject: Re: LSP stitching questions for discussion
>
>
> Dimitri,
>
> It seems to me that I mostly agree(?!) with what you wrote in this mail.
> I'd still want to confirm your views on the following questions:
>
>
> a) Is it possible (should we allow) to stitch PSC1 e2e LSP by a LSC LSP
> segment ?
>
> b) Is it possible (should we allow) to stitch VC12 e2e LSP by a VC4 LSP
> segment ?  c) Is it possible (should we allow) to stitch PSC1 e2e LSP by
> a PSC2 LSP segment ?
>
> My answers are NO to all three questions. You can sticth PSC1 with PSC1,
> VC12 with VC12, etc. In all other cases you need, first, to setup a
> hierarchical LSP (H-LSP) (whether it is FA-LSP (single domain) or not
> (multi-domain)) in order to create a data link of the e2e LSP switching
> capability and only after that you can also use a stitching segment on
> top of this H-LSP).
>
> See also in-line.
>
> Igor
>
>
> ----- Original Message -----
> From: [email-masked]
> To: Arthi Ayyangar
> Cc: Igor Bryskin ; [email-masked]
> Sent: Wednesday, July 20, 2005 4:46 AM
> Subject: Re: LSP stitching questions for discussion
>
> arthi,
>
>
>
> first a recap: this item on stitching was initiated in order to allow
> per "domain" control of end-to-end (contiguous) LSP, as part of a
> separate document, and not to extend its scope (unduly, in this case,
> see below) but mainly in order to have the set of all related protocol
> mechanisms within a specific document -
>
>
>
> from this initial working assumption, it is clear that the segment must
> have the properties of the incoming end-to-end LSP which are determined
> among other by its switching type e.g. PSC-3 or TDM, the first
> requirement of LSP stitching is contiguity of the end-to-end LSP at the
> data plane level (after stitching operation) - and this by definition of
> the initial working assumption -
>
> IB>> Agree
>
> note: the only latitude which is left (for a given switching type e.g.
> PSC-2) is due to the properties of packet (PSC) networks that allows you
> stitch a segment having a larger Max Reservable Bandwidth and Unreserved
> Bandwidth (we would have equivalent latitude for other attributes but
> this is a local policy decision - which at the end is the sole purpose
> of this approach)
>
> IB>> Disagree. Conceptually PCS1 and PSC2 are different layers and the
> latter cannot stitch the former, just like in case VC12 and VC4. You
> should nest PSC1 within PSC2 instead.
>
>
>
> Here are some of the questions related to LSP stitching to start a
> discussion on the usage of LSP stitching.
>
> >1) Are the control plane signaling procedures for LSP stitching as
> >described in this ID, (explicit request for LSP stitching on
> >LSP segment, different label allocation rules; etc) REQUIRED to stitch
> >packet LSPs in data plane
>
>
> -> yes (beside manual config operation)
>
> IB>> Agree
>
>
> >2) Are the control plane signaling procedures for LSP stitching as
> >described in this ID, (explicit request for LSP stitching on
> >LSP segment, different label allocation rules; etc) REQUIRED to stitch
> >non-packet LSPs in data plane ?
>
>
> -> yes (beside manual config operation)
>
> IB>> Agree
>
>
> >3) If an e2e LSP crosses a region boundary (based on different TE
> >link switching capabilities), then can I use LSP stitching
> >a) control plane procedures for packet LSPs
> >b) data plane procedures for packet LSPs
> >c) control plane procedures for non-packet LSPs
> >d) data plane procedures for non-packet LSPs
>
>
> -> no, when crossing a region boundary, you simply use a document named
> "draft-mpls-lsp-hierarchy-08.txt" which is in the RFC Editor queue, but
> this does not prevent from creating an LSP segment on top of an FA-LSP
> (see below)
>
> IB>> Agree with the caviat that it should be H-LSP instead of FA-LSP to
> cover single and multi-domain scenarios
>
>
> >4) If the switching type of an e2e LSP is different from that of an LSP
> >segment, can I use LSP stitching
> >a) control plane procedures for packet LSPs
> >b) data plane procedures for packet LSPs
> >c) control plane procedures for non-packet LSPs
> >d) data plane procedures for non-packet LSPs
>
>
> -> no, in this case progression of the end-to-end LSP establishment,
> implies that the LSP segment must fulfil a set of constraints carried as
> part of the incoming end-to-end LSP request, in this case one has to
> create an LSP segment (with a switching type equal to the incoming
> end-to-end LSP switching type) over that FA (i.e. referred here above to
> the LSP segment with a different Switching Type)
>
>
> IB>> Agree with the caviat that it should be H-LSP instead of FA-LSP to
> cover single and multi-domain scenarios
>
> Cheers,
>
> Igor
>
> >Note that although 3) and 4) appear to be the same, the reason I have
> >them as different questions is that in one case the TE link switching
> >capability is examined and in the other case the Generalized Label Request
> >is examined.
>
>
>
> -> what it appears to me is that this discussion mixes the issue of the
> operation describing the stitching operations at the domain boundaries
> from the LSP segment creation itself i.e. an LSP segment can indeed be
> an FA link inherited from the creation of an (intra-domain) FA-LSP -
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com

Delivery-date: Thu, 28 Jul 2005 16:57:13 +0000
Date: Thu, 28 Jul 2005 09:55:48 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-01.txt 

Hi JL,

Thanks for the comments.

>
> -In section 5.2, I'm not sure that path p3 is a valid one:
> "RO-X1-ASBR1(loose)-ASBR4(strict)-ASBR7(strict)-ASBR9(loose)-R6. What
> does ERO sub-objects for ASBR4 and ASBR5 represent? Actually this cannot
> be an interface or router id, because the ERO would be invalid (cannot
> be strict as ASBR4 and ASBR7 ar not directly connected). The only way to
> proceed in this way is to include ERO-sub-objects corresponding to
> FA-LSP or LSP-Segment TE-links (numbered or unnumbered tunnel interface
> id).  One could assume that RO would obtain such ERO including FA-LSP or
> LSP-segment as a result of a PCE based compuation... On receip of a Path
> message the ERO subobject would allow to directly determine the
> underlying FA-LSP or LSP-Segment...
AA----------> The intention was actually to show a case where ERO contains
FA-LSP or LSP segment TE link address (as you have described above) in
which case, contiguous LSP would not be setup. Looks like the part
stating this got edited out somewhere along the line. :-(
            Also, I agree with you that in that case the ERO would either
contain numbered or unnumbered TE link address corresponding to FA-LSP or
LSP segment. So we will fix the ERO in the above case to explain this
scenario. Thanks for pointing this out.

> By the way it would also be good to ilusrate the case of abstract nodes,
> e.g. a path made of AS number ERO subobjects...
AA-----> You mean in the ERO processing discussion, right ? Will do.

> -It would be good to add some text related to failure detection, at the
> end of 6.1.3. In case of stitching or nesting, the PLR could rely on
> BFD-MPLS so as to rapidliy detect FA-LSP/LSP-Segment tail-end failure.
> This would help ensuring fast recovery...
AA--------> Makes sense.

> -In section 6.2 the FRR considerations described in 6.1.3 for stiching
> and nesting, actually also apply to GMPLS Segment Recovery.
AA-------> Okay...but mechanisms are different.

> -Section 7 would benefif from some words on global reoptimization (ie
> with change of border routers) Even if this is more a path computation
> issue this may have some impact on signaling...
AA------> Since, as you said it is a path computation issue and it doesn't
directly cover any signaling extension, it was deliberately left out of
this ID. It is mentioned in the pd-path-comp ID.

> -And two minor edits Section 5.1.1: issue with B3 path, in the figure
> ASBR6 and ASBR7 are not connnected.  Section 8: [INTER-AS-TE-REQ]
> instead of [INTER-AREA-TE-REQS]
AA----> Okay. Will fix.

thanks,
-arthi

> Hope this helps,
>
> Best Regards
>
> JL
>
>
> > -----Message d'origine-----
> > De : [email-masked]
> > [mailto:[email-masked]] De la part de
> > [email-masked]
> > Envoy=E9 : mardi 19 juillet 2005 21:50
> > =C0 : [email-masked]
> > Cc : [email-masked]
> > Objet : I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> > This draft is a work item of the Common Control and
> > Measurement Plane Working Group of the IETF.
> >
> > =09Title=09=09: Inter domain GMPLS Traffic
> > Engineering - RSVP-TE extensions
> > =09Author(s)=09: A. Ayyangar, J. Vasseur
> > =09Filename=09: draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
> > =09Pages=09=09: 17
> > =09Date=09=09: 2005-7-19
> >
> > This document describes extensions to Generalized
> > Multi-Protocol Label Switching (GMPLS) Resource ReserVation
> > Protocol - Traffic Engineering
> > (RSVP-TE) signaling required to support mechanisms for the
> > establishment and maintenance of GMPLS Traffic Engineering
> > (TE) Label Switched Paths (LSPs), both packet and non-packet,
> > that traverse multiple domains. For the purpose of this
> > document, a domain is considered to be any collection of
> > network elements within a common realm of address space or
> > path computation responsibility. Examples of such domains
> > include Autonomous Systems, IGP areas and GMPLS overlay networks.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-dom
> > ain-rsvp-te-01.txt
> >
> > To remove yourself from the I-D Announcement list, send a
> > message to [email-masked] with the word
> > unsubscribe in the body of the message.
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> > with the username "anonymous" and a password of your e-mail
> > address. After logging in, type "cd internet-drafts" and then
> > =09"get draft-ietf-ccamp-inter-domain-rsvp-te-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > =[email-masked].
> > In the body type:
> > =09"FILE
> > /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-01.txt".
> >
> > NOTE:=09The mail server at ietf.org can return the document in
> > =09MIME-encoded form by using the "mpack" utility.  To use this
> > =09feature, insert the command "ENCODING mime" before the "FILE"
> > =09command.  To decode the response(s), you will need "munpack" or
> > =09a MIME-compliant mail reader.  Different MIME-compliant
> > mail readers
> > =09exhibit different behavior, especially when dealing with
> > =09"multipart" MIME messages (i.e. documents which have been split
> > =09up into multiple messages), so check your local documentation on
> > =09how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
>

Delivery-date: Thu, 28 Jul 2005 16:18:10 +0000
Date: Thu, 28 Jul 2005 09:16:56 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 

Hi JL,

Thanks for the comments.

> -In section 4.1.2 you partially describe bidirectional LSP stitching
> procedure. You mention that an Upstream Label MUST NOT be allocated by
> the end-to-end LSP on the LSP segment, which is OK. But then how the
> LSP-Segment Egress will now that the end-to-end LSP is bidirectional?
AA--------> Excellent point.

> What about defining a flag in the Attributes Flags TLV of the
> LSP_ATTRIBUTE object so as to indicate that the LSP is bidirectional?
AA------> That would be a change to the processing that GMPLS nodes use to
detect bidirectionality, isn't it ? Normally nodes look for the Upstream
Label object to detect bidirectionality.

So let us say that an LSP is bidirectional if a) an Upstream Label is
present or b) no Upstream Label, but bit set in LSP_ATTRIBUTE or c) both
However, reliance on an e2e attributes bit set by head end, means existing
head ends will not be setting this bit, so that will be an issue (wrt
compatibility).

Could be nice if this signaling was just between the node doing the
stitching and the end point of the LSP segment, since this is the hop that
the bidirectionality information is lost. Let me think about this.

> Also the selection of the LSP segment in case of bidirectional LSP
> should be detailed (e.g. If the end-to-end LSP is bidirecitonal then the
> LSP-segment MUST be bidirectional. Also shall we allow that two
> unidrectional end-to-end LSP use the same bidirectional LSP segment (one
> in each direction)?
AA----> Yes, this should be okay. IMO.

> -At the end of section 4.2.5 you mention that LSP-Segment failure or
> maintenance SHOULD be treated as a failure event for the end-to-end LSP.
> I agree for LSP-Segment failure but not for LSP-Segment maintenance.
> LSP-Segment maintenance should be treated as TE-link maintenance for the
> end-to-end LSP, and procedures defined in GMPLS graceful TE-link
> shutdown draft may be useful (Specific RSVP error code and TE-link
> attribute)...
AA---> Yes, I agree; we will mention this. Actually the graceful teardown
sentence occurs few paragraphs before, but not in the right context. So we
will clarify the above.

> Hope this helps,
AA--->  Sure does.

Thanks!

-arthi

>
>
> > -----Message d'origine-----
> > De : [email-masked]
> > [mailto:[email-masked]] De la part de
> > [email-masked]
> > Envoy=E9 : vendredi 15 juillet 2005 21:50
> > =C0 : [email-masked]
> > Cc : [email-masked]
> > Objet : I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> > This draft is a work item of the Common Control and
> > Measurement Plane Working Group of the IETF.
> >
> > =09Title=09=09: Label Switched Path Stitching with
> > Generalized MPLS Traffic Engineering
> > =09Author(s)=09: A. Ayyangar, J. Vasseur
> > =09Filename=09: draft-ietf-ccamp-lsp-stitching-01.txt
> > =09Pages=09=09: 19
> > =09Date=09=09: 2005-7-15
> >
> > In certain scenarios, there may be a need to combine together two
> >    different Generalized Multi-Protocol Label Switching (GMPLS) Label
> >    Switched Paths (LSPs) such that in the data plane, a single end-to-
> >    end (e2e) LSP is achieved and all traffic from one LSP is switched
> >    onto the other LSP.  We will refer to this as "LSP
> > stitching".  This
> >    document covers cases where: a) the node performing the stitching
> >    does not require configuration of every LSP pair to be stitched
> >    together b) the node performing the stitching is not the egress of
> >    any of the LSPs c) LSP stitching not only results in an end-to-end
> >    LSP in the data plane, but there is also a corresponding end-to-end
> >    LSP (RSVP session) in the control plane.  It might be possible to
> >    configure a GMPLS node to switch the traffic from an LSP
> > for which it
> >    is the egress, to another LSP for which it is the ingress, without
> >    requiring any signaling or routing extensions whatsoever,
> > completely
> >    transparent to other nodes.  This will also result in LSP stitching
> >    in the data plane.  However, this document does not cover this
> >    scenario of LSP stitching.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitc
> hing-01.txt
> >
> > To remove yourself from the I-D Announcement list, send a
> > message to [email-masked] with the word
> > unsubscribe in the body of the message.
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> > with the username "anonymous" and a password of your e-mail
> > address. After logging in, type "cd internet-drafts" and then
> > =09"get draft-ietf-ccamp-lsp-stitching-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > =[email-masked].
> > In the body type:
> > =09"FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
> >
> > NOTE:=09The mail server at ietf.org can return the document in
> > =09MIME-encoded form by using the "mpack" utility.  To use this
> > =09feature, insert the command "ENCODING mime" before the "FILE"
> > =09command.  To decode the response(s), you will need "munpack" or
> > =09a MIME-compliant mail reader.  Different MIME-compliant
> > mail readers
> > =09exhibit different behavior, especially when dealing with
> > =09"multipart" MIME messages (i.e. documents which have been split
> > =09up into multiple messages), so check your local documentation on
> > =09how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
>

Delivery-date: Thu, 28 Jul 2005 15:50:27 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-01.txt 
Date: Thu, 28 Jul 2005 17:48:10 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Richard Rabbat" <[email-masked]>
Cc: <[email-masked]>

Hi Kohei, Rajiv, Richard,

I have on comment related to your GMPLS addressing ID:
In section 5.2 you recommend, that in the session object, the IP tunnel =
end-point be set to the destination TE router id and that the extended =
tunnel id be set to the source TE router id, which makes sense. But as =
per 3209, a session object can either encode IPv4 or IPv6 addresses but =
not both types, and there may be an issue if source TE router id is IPv6 =
and destination TE router id is IPv4 (or vice versa). This may happen =
for instance with inter-AS/SP LSPs. IMHO we should address this point.

Best Regards,

JL

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de=20
> [email-masked]
> Envoy=E9 : mardi 21 juin 2005 21:50
> =C0 : [email-masked]
> Cc : [email-masked]
> Objet : I-D ACTION:draft-ietf-ccamp-gmpls-addressing-01.txt=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Common Control and=20
> Measurement Plane Working Group of the IETF.
>=20
> 	Title		: Use of Addresses in Generalized Multi-Protocol
>                           Label Switching (GMPLS) Networks
> 	Author(s)	: K. Shiomoto, et al.
> 	Filename	: draft-ietf-ccamp-gmpls-addressing-01.txt
> 	Pages		: 23
> 	Date		: 2005-6-21
> =09
> This document explains and clarifies the use of addresses in=20
>    Generalized Multi-Protocol Label Switching (GMPLS)=20
> networks.  The aim=20
>    of this document is to facilitate and ensure better=20
> interworking of=20
>    GMPLS-capable Label Switching Routers (LSRs) based on experience=20
>    gained in deployments and interoperability testing and proper=20
>    interpretation of published RFCs.=20
>    =20
>    The document recommends a proper approach for the=20
> interpretation and=20
>    choice of address and identifier fields within GMPLS protocols and=20
>    references specific control plane usage models.  It also examines=20
>    some common GMPLS Resource Reservation Protocol-Traffic=20
> Engineering=20
>    (RSVP-TE) signaling message processing issues and recommends=20
>    solutions.  It finally discusses how to handle IPv6 sources and=20
>    destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB=20
>    (Management Information Base) modules.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-add
ressing-01.txt
>=20
> To remove yourself from the I-D Announcement list, send a=20
> message to [email-masked] with the word=20
> unsubscribe in the body of the message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login=20
> with the username "anonymous" and a password of your e-mail=20
> address. After logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-ccamp-gmpls-addressing-01.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE=20
> /internet-drafts/draft-ietf-ccamp-gmpls-addressing-01.txt".
> =09
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 	=09
> 	=09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20

Delivery-date: Thu, 28 Jul 2005 13:56:02 +0000
Content-class: urn:content-classes:message
Subject: ARE: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Date: Thu, 28 Jul 2005 15:53:03 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "JP Vasseur" <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi JP, Arthi Raymond

A few comments related to your inter-domain pd draft

-Section: 1) common assumptions,
Why not adding and addressing the case where a path is made of a set of =
abstract nodes?
For  instance, in the inter-AS case, an ERO may list a set of ASes. This =
may require specific procedures when computing the path and selecting =
the downstream ASBR...

-Section 4: 1)=20
Even if this is not really in the scope I think that the auto-discovery =
mechanism would require some more words. This is partially addressed =
latter in the draft(4.2.1), but you should mention here that such =
auto-discovery may rely on IGP information and/or BGP information and =
also on local policies (particularly in inter-AS/SP case).
In the inter-AS/SP case there may be several candidate downstream ASBRs, =
pertaining to distinct ASes/SPs, and the downstream AS selection may =
require appying policies related to specific "TE peering contract" =
negociated with neigbors Ases/SPs...

-Section 4  2) b) ii) What do you exactly mean by "the boundary LSR is =
not a FA-LSP/LSP segment candidate"?
Does it mean in this case, that a contigous LSP is created?, this would =
not be consistent with b)=20

-Top of Section 4.1.1: You should remove the first sentence after the =
three path examples,
"At least the set", as this sounds an ambiguous repetition of what is =
just stated above

-Section 6.2:
"If the Inter-AS TE related Information is flooded in the IGP, each ASBR =
is capable of computing the path..."

Actually there may be some topologies where an ASBR cannot compute a =
link protection path.

See the following example

AS1-->   <---AS2----
ASBR1----ASBR2
|        |
|        |
ASBR3----ASBR4

ASBR1 is aware of links ASBR1->ASBR2, ASBR1->ASBR3 and ASBR3->ASBR4 but =
not the link ASBR2->ASBR4 as there is no flooding between AS1 and AS2.
Hence ASBR1 cannot compute a path to protect link ASBR1-ASBR2.

Actually this case is similar to node protection issue, the path should =
be computed according to the pd computation methods defined in the doc.

Also it would be useful to mention that pd inter-domain backup path may =
requires XRO incusion in RSVP messages...

-Section 7.2

"Note that stiching or nesting rely on local optimization...hence the =
reoptimization is not global and...
Procedures describes in loose hop MUST be used...
"
It would be good to mention that global PCE-based reoptimization (with =
potential change of border LSRs) also apply to stiching/nesting.
In both cases, contiguous or stiching/nesting, PCE or any offline =
computation is required to achieve end-to-end reoptimization.

Hope it helps,

Best Regards,

JL

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de=20
> [email-masked]
> Envoy=E9 : vendredi 15 avril 2005 21:34
> =C0 : [email-masked]
> Cc : [email-masked]
> Objet : I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Common Control and=20
> Measurement Plane Working Group of the IETF.
>=20
> 	Title		: A Per-domain path computation method for=20
> 			  computing Inter-domain Traffic=20
> Engineering (TE)=20
> 			  Label Switched Path (LSP)
> 	Author(s)	: J. Vasseur, et al.
> 	Filename	:=20
> draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
> 	Pages		: 0
> 	Date		: 2005-4-15
> =09
> This document specifies a per-domain path computation method=20
> for computing inter-domain Traffic Engineering (TE)=20
> Multiprotocol Label Switching (MPLS) and Generalized MPLS=20
> (GMPLS) Label Switched (LSP) paths. In this document a domain=20
> is referred to as a collection of network elements within a=20
> common sphere of address management or path computational=20
> responsibility such as IGP areas and Autonomous Systems.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-dom
> ain-pd-path-comp-00.txt
>=20
> To remove yourself from the I-D Announcement list, send a=20
> message to [email-masked] with the word=20
> unsubscribe in the body of the message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login=20
> with the username "anonymous" and a password of your e-mail=20
> address. After logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE=20
> /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt".
> =09
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 	=09
> 	=09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20

Delivery-date: Thu, 28 Jul 2005 11:40:22 +0000
Date: Thu, 28 Jul 2005 13:38:52 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: "Ali Sajassi (sajassi)" <[email-masked]>
CC:  [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet

Ali Sajassi (sajassi) wrote:
> Loa,
Ali,

I don't parse the paragraph below. If you said "All the MPLS traffic
can be carried..." I would understand it. But, then we have done
that for the last 6 years.
We were talking about extending the GMPLS control plane to control
Ethernet traffic, and into a MRN (gosh I hate that name ;))
architecture.
My take here is that we need to cooperate with IEEE to do this, since
in my opinion, we need to discuss the forwarding plane.

/Loa

> I think you might have misinterpreted what I was saying. I was talking
> about using MPLS encap first and then have MPLS traffic over its
> designated VLAN(s). All the GMPLS traffic can be carried over a single
> VLAN or you can have more than one for load balancing purposes. And thus
> there shouldn't be any scalability issues.
>  
> 
>>i don't know if we are ready to start the discussion on 
>>solution, but we seems to do that anyway ;)
>>
> 
> Apparently :-)
> 
> 
>>there is a way for us to get a tpid from IEEE, we could 
>>specify the behavior of switches on that tpid
>>
>>my take that we shouldn't do that without involving ieee, but 
>>on the other it is normally quite easy to work with them
>>
> 
> 
> If interested one can come and discuss it during next 802.1 group (which
> is the architecture group for IEEE bridges) meeting.
> 
> 
>>but again we need to undestand requirements first
>>
> 
> 
> Completely agree. 
> 
> -Ali
> 
> 
>>/Loa
>>
>>Ali Sajassi (sajassi) wrote:
>>
>>>Dimitri,
>>> 
>>>By "existing Ethernet switches", I mean Ethernet switches based on 
>>>current approved IEEE 802 .1Q/.1D standards and not the 
>>
>>hypothetical 
>>
>>>switches with TBD forwarding characteristics. Anyway, if 
>>
>>the objective 
>>
>>>is to use RSVP-TE with "existing Ethernet switches", you 
>>
>>can do that 
>>
>>>easily by designating a VLAN or (set of VLANs) for RSVP-TE 
>>
>>traffic and 
>>
>>>support both EoMPLS and native bridged traffic on a single trunk. 
>>>There is some overhead with such encapsulation but the 
>>
>>benefit of it 
>>
>>>is that it works now. If we want to do it through some other means 
>>>(such as MAC address translation), then the benefit of such 
>>
>>approach 
>>
>>>is not clear to me; however, the disadvantages are very clear
>>>:-) Anyway, I'll look forward to more discussions during 
>>
>>and after the 
>>
>>>meeting next week.
>>> 
>>>Cheers,
>>>Ali
>>>
>>>    
>>
>>--------------------------------------------------------------
>>----------
>>
>>>    *From:* [email-masked]
>>>    [mailto:[email-masked]]
>>>    *Sent:* Tuesday, July 26, 2005 4:21 PM
>>>    *To:* Ali Sajassi (sajassi)
>>>    *Cc:* CHO, JAI HYUNG; Heiles Juergen; [email-masked]; 
>>
>>[email-masked]
>>
>>>    *Subject:* RE: Frameformat in a l2cs gmpls rnvironment 
>>
>>- Issues w/
>>
>>>    GMPLS Ethernet
>>>
>>>    ali
>>>
>>>    to be clear here you are hanging on using the term "existing
>>>    Ethernet switches" while the document that has been at 
>>
>>the source of
>>
>>>    the discussion does not state "GMPLS must be deployable 
>>
>>on existing
>>
>>>    Ethernet switches" this may be the case but there are 
>>
>>limitations
>>
>>>    (and there are perfectly well understood, don't worry) 
>>
>>beside this
>>
>>>    you should also tell us what do you exactly mean with the term
>>>    "existing" - but this is a side issue -
>>>
>>>    this said, this does NOT mean that a GMPLS Ethernet 
>>
>>switch (either
>>
>>>    existing or even "extended") would need to support a 
>>
>>new Ethernet
>>
>>>    802.3 frame forwarding paradigm, the difference is 
>>
>>subtle but has to
>>
>>>    be underlined
>>>
>>>    note: there is a slot of 20 minutes during the next 
>>
>>CCAMP WG meeting
>>
>>>    where this document and all related issues will be 
>>
>>heavily discussed
>>
>>>    ... so i welcome you to join the festivities ;-)
>>>
>>>    thanks,
>>>
>>>    - dimitri.
>>>
>>>     
>>>
>>>    *"Ali Sajassi \(sajassi\)" <[email-masked]>*
>>>    Sent by: [email-masked]
>>>    07/25/2005 16:13 MST
>>>
>>>    To: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen"
>>>    <[email-masked]>, <[email-masked]>
>>>    cc: <[email-masked]>
>>>    bcc:
>>>    Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/
>>>    GMPLS Ethernet
>>>
>>>
>>>    Jaihyung,
>>>
>>>    It seems to me that your primary objective is to use 
>>
>>the existing
>>
>>>    Ethernet switches with new control plane (GMPLS) to 
>>
>>setup TE paths for
>>
>>>    different applications. And you mentioned three 
>>
>>approaches for doing
>>
>>>    this in your email. However, all three of them have 
>>
>>issues and are not
>>
>>>    viable. Lets go over them ...
>>>
>>>     >
>>>     > In below mail, I discussed about three proposed approaches.
>>>     >
>>>     >
>>>     > 1. using VLAN tag as it is for L2 label encoding.
>>>
>>>    As you know this approach has scalability issue and you 
>>
>>are limited to
>>
>>>    4K services in the network and if you try to use the 
>>
>>upcoming IEEE
>>
>>>    802.1ad standard to make VLANs, interface specific, 
>>
>>then you will need
>>
>>>    new switches and not existing Ethernet switches. Even 
>>
>>if you use these
>>
>>>    newer switches, you will still be limited to 4K 
>>
>>services per interface
>>
>>>    and it would defeat the objective of using existing switches.
>>>
>>>     >
>>>     > 2. defining new protocol ID (TPID) and borrow VLAN 
>>
>>tag format,
>>
>>>     > ?or extended VLAN tag to implement label swapping.
>>>     >
>>>
>>>    This approach requires new data plane functionality to 
>>
>>be implemented
>>
>>>    (which defeats the objective of using existing switches).
>>>
>>>     > 3. use lower 3 bytes of MAC address for L2 label encoding.
>>>     >
>>>
>>>    This approach has several issues:
>>>    1) how does MAC addresses get distributed among the 
>>
>>bridges ? How does
>>
>>>    this distribution works during a link or node failure ? 
>>
>>How does it
>>
>>>    recover from a link or node failure ?
>>>
>>>    2) Will you assign a separate provider MAC for each 
>>
>>customer MAC. If so,
>>
>>>    then how do you address MAC scalability. If not, then 
>>
>>how do you take
>>
>>>    care of 1-to-N mapping between provider MAC address and 
>>
>>customer MAC
>>
>>>    addresses and how do you handle multipoint connections.
>>>
>>>    3) how do handle customer FCS retention when doing this 
>>
>>MAC translation
>>
>>>    stuff ??
>>>
>>>     >
>>>     > 802.1Q bridge forwards Ethernet frames using two 
>>
>>dataplane tables
>>
>>>     > - MAC forwarding table and VLAN forwarding table.
>>>     > Bridge control protocols, such as GARP, GVRP, GMRP,
>>>     > manipulate one of the two dataplane entities.
>>>
>>>    This is not correct. Bridges don't have different 
>>
>>databases for MAC
>>
>>>    forwarding and VLAN forwarding. They have filtering 
>>
>>datebase(s) with
>>
>>>    corresponding IDs (FIDs). VLAN IDs get mapped to FIDs 
>>
>>based on operation
>>
>>>    mode (IVL versus SVL). Then once a filtering database 
>>
>>is identified,
>>
>>>    then a MAC address lookup is performed for forwarding. 
>>
>>Bridge control
>>
>>>    protocols use a designated MAC addressed and based on these MAC
>>>    addressed, the bridge knows how to process the frame.
>>>
>>>     >
>>>     > Similarly, option 1 and 3 are about which one of two
>>>     > dataplane entities
>>>     > GMPLS protocol should control on behalf of bridge 
>>
>>control protocols.
>>
>>>     > The two proposals do not intend to modify bridge behavior
>>>     > seriously, such as MAC learning, aging, filtering.
>>>     > Therefore, the approaches 1 and 3 are in the scope of CCAMP.
>>>
>>>    If that's the intention, you may find out soon you get 
>>
>>more than what
>>
>>>    you asked for :-)
>>>
>>>     >
>>>     > (% note however, I would regard implementing label swapping
>>>     > function is acceptable change considering the 
>>
>>Internal Sublayer
>>
>>>     > design of 802.1D bridge.)
>>>     >
>>>
>>>    The only way of doing this is using VID translation 
>>
>>table specified in
>>
>>>    IEEE 802.1ad which requires new data-plane 
>>
>>functionality and thus
>>
>>>    existing bridges cannot be used !!
>>>
>>>    Also if going the route of tag swapping, you may 
>>
>>consider using IEEE
>>
>>>    802.1ah. As the editor of .1ah, I can go over the 
>>
>>details when I get a
>>
>>>    chance.
>>>
>>>     >
>>>     > However, option 2 is about what TPID code we will
>>>     > choose to implement new switching function.
>>>     > The switch of this implementation should have new hardware
>>>     > design in addition to normal bride hardware.
>>>     > I think such proposal as option 2 is out of CCAMP scope.
>>>
>>>    Yes.
>>>
>>>     >
>>>     > Overall objective is improving scalability, traffic 
>>
>>engineering (TE)
>>
>>>     > characteristics of 802.1 bridge that it can be 
>>
>>reliable, manageable
>>
>>>     > enough to replace some core routers.
>>>
>>>    Easier said than done :-)
>>>
>>>     > The switching technique you mentioned above, such as
>>>     > Ethernet over MPLS as defined by PWE3 and L2VPN,
>>>     > are all actually router based technology, however this
>>>     > work is based on simple bridge architecture.
>>>     > Cost-effectiveness is the key differentiator.
>>>     >
>>>
>>>    The devils are in the details and once you worked out 
>>
>>the details, you
>>
>>>    will see the issues.
>>>
>>>     >
>>>     > In access or enterprise network, capability of 
>>
>>providing end-to-end
>>
>>>     > L2-LSP will enable service providers policing, 
>>
>>measuring, charging
>>
>>>     > application flows using Ethernet based network. This 
>>
>>will eventually
>>
>>>     > improve income structure and introduce new session 
>>
>>based commercial
>>
>>>     > service. I have been discussing this aspect in mail thread of
>>>     > title 'End-to-end L2-LSP'.  Please read the mail 
>>
>>thread and comment
>>
>>>     > on the discussion.
>>>     >
>>>     >
>>>     > >You mentioned to use the MAC address or part of it 
>>
>>as a label.
>>
>>>     > >The TRILL working group is defining shortest path routing
>>>     > for Ethernet.
>>>     > >How would this fit together?
>>>     >
>>>     >
>>>     > TRILL employs new encapsulation layer outside of 
>>
>>Ethernet frames.
>>
>>>     > However in my proposal of option-3, I simply use the 
>>
>>Ethernet header
>>
>>>     > to encode GMPLS label.
>>>     >
>>>     > The overall format of rbridge is
>>>     > [Ethernet][r-tag][Ethernet][ data..]
>>>     > It is not LSP based technology but a connectionless 
>>
>>routing bridge.
>>
>>>     > TTL count is very important in rbridge because 
>>
>>frames are routed
>>
>>>     > hop-by-hop and it may loop.
>>>     >
>>>     > Whereas in option-3 above, Ethernet frames that have certain
>>>     > OUI prefix in MAC address are forwarded via a path that
>>>     > GMPLS protocol has configured on MAC forwarding table.
>>>     >
>>>
>>>    How does the redundancy work in here. Are you using 
>>
>>bridge protocol in
>>
>>>    conjunction with GMPLS protocol. If you do, then there 
>>
>>are bunch of
>>
>>>    issues. If you don't, then what is it used and how does 
>>
>>it interact with
>>
>>>    bridging protocols ??
>>>
>>>    -Ali
>>>
>>>
>>>     >
>>>     > Thanks
>>>     >
>>>     > Jaihyung
>>>     >
>>>     >
>>>     >
>>>     > -----?? ???-----
>>>     > ?? ??: "Heiles Juergen" <[email-masked]>
>>>     > ?? ??: 2005-07-25 ?? 6:44:34
>>>     > ?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles
>>>     > Juergen" <[email-masked]>, "[email-masked]"
>>>     > <[email-masked]>
>>>     > ??: "[email-masked]" <[email-masked]>
>>>     > ??: RE: Frameformat in a l2cs gmpls rnvironment.
>>>     >
>>>     >
>>>     >
>>>     >
>>>     >
>>>     >
>>>     > Dear Jaihyung,
>>>     >
>>>     > you mention several options that could be used as a label.
>>>     > Most of them have strong impacts on the data plane and
>>>     > introduce new layer networks. Is this in the scope of CCAMP?
>>>     > What is the goal, to introduce a control plane for a existing
>>>     > L2 technology or introduce a new L2 technology? What would be
>>>     > the benefit of such a new L2 co switching technology compared
>>>     > to Ethernet over MPLS as defined by PWE3 and L2VPN?
>>>     > You mentioned to use the MAC address or part of it as a
>>>     > label. The TRILL working group is defining shortest path
>>>     > routing for Ethernet. How would this fit together?
>>>     >
>>>     >
>>>     > Regards
>>>     >
>>>     > Juergen
>>>     >
>>>     >
>>>     >
>>>     >
>>>     >
>>>     > > From: CHO, JAI HYUNG [mailto:[email-masked]]
>>>     > > Sent: Saturday, July 23, 2005 6:19 AM
>>>     > > To: Heiles Juergen; [email-masked]
>>>     > > Cc: [email-masked]
>>>     > > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
>>>     > >
>>>     > >
>>>     > > Dear Juergen, Par and all,
>>>     > >
>>>     > > The proposed framework of L2SC was not intended to suggest
>>>     > > any specific solution. It is still an open question.
>>>     > > As Adrian noted, it only aims to present requirements
>>>     > > as in scenarios that may drive people toward next 
>>
>>step in many
>>
>>>     > > viable solutions.
>>>     > >
>>>     > > In fact, there are other options we may also 
>>
>>consider for L2
>>
>>>     > > label encoding.
>>>     > > IEEE 802.1 Ethernet bridges forward frames based 
>>
>>on 48bits of
>>
>>>     > > MAC address,
>>>     > > and additionally using VLAN tag.
>>>     > >
>>>     > > When the purpose of GMPLS control over Ethernet is not to
>>>     > > create new dataplane
>>>     > > but to utilize IEEE 802.1 bridge architecture, we may
>>>     > consider using
>>>     > > one of the two forwarding methods, MAC forwarding or VLAN
>>>     > forwarding.
>>>     > > (and perhaps any other combination of fields in 
>>
>>MAC, but I'll
>>
>>>     > > not discuss it)
>>>     > >
>>>     > > Use of VLAN ID for label encoding may automate 
>>
>>VLAN configuration
>>
>>>     > > using IP protocols. However, GMPLS protocol cannot use the
>>>     > > field exclusively
>>>     > > because public/private operators already use VLAN 
>>
>>for various
>>
>>>     > > purpose.
>>>     > > There is a potential conflict with existing use of VLAN and
>>>     > > GMPLS use of VLAN label.
>>>     > > Furthermore, scalability of VLAN ID has been 
>>
>>frequently noted
>>
>>>     > > as weakness
>>>     > > because the size of VLAN ID is at most 4096 (12bit).
>>>     > >
>>>     > > The scalability may be improved if the scope of 
>>
>>VLAN label is
>>
>>>     > > confined to
>>>     > > link-local, and some additional swapping function 
>>
>>of VLAN ID
>>
>>>     > > is introduced in
>>>     > > Internal Sublayer [802.1D] of GMPLS implemented switch.
>>>     > > However, this will only be effective when the configuration
>>>     > > of network
>>>     > > is mesh structure that multiple LSP paths exist. If the
>>>     > > configuration of network
>>>     > > is star or tree shape, as normal configuration of 
>>
>>access network,
>>
>>>     > > LSPs concentrate in root node and total number of
>>>     > > LSPs that the network can hold still be limited by 
>>
>>available
>>
>>>     > > label space
>>>     > > at a few root links.
>>>     > >
>>>     > > For these reasons, I do not think any form of VLAN 
>>
>>ID label is
>>
>>>     > > an appropriate choice for layer-2 label encoding.
>>>     > >
>>>     > > There are some other proposals assuming new 
>>
>>assignment of Ethernet
>>
>>>     > > Length/Type value (e.g. new TPID in VLAN tag) and 
>>
>>re-definition of
>>
>>>     > > information fields placed between 802.3 MAC header 
>>
>>and IP packet.
>>
>>>     > > In this case, only the format of VLAN tag or 
>>
>>extended VLAN tag
>>
>>>     > > is borrowed, however, inside the switching hardware, the
>>>     > > filter and relay,
>>>     > > etc. are totally different new dataplane switch.
>>>     > >
>>>     > > I do not see such approach is a GMPLS 
>>
>>implementation for Ethernet
>>
>>>     > > because the core switching technique is not 802.1 Ethernet
>>>     > > bridge at all.
>>>     > >
>>>     > > The other option we may consider is using MAC address filed
>>>     > as below.
>>>     > >
>>>     > >
>>>     > > +-------+-------+-------+-------+-------+-------+
>>>     > > | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte |
>>>     > > +-------+-------+-------+-------+-------+-------+
>>>     > > +-----------------------+-----------------------+
>>>     > > |  OUI Prefix (=GMPLS)  |   DA-label (24bit)    |
>>>     > > +-----------------------+-----------------------+
>>>     > > |  OUI Prefix (=GMPLS)  |   SA-label (24bit)    |
>>>     > > +---------------+-------+-----------------------+
>>>     > > | Length/Type   |
>>>     > > +---------------+
>>>     > >
>>>     > >
>>>     > > IEEE is designated by the ISO Council to act as the
>>>     > > registration authority
>>>     > > for the higher three-octet of OUI number in the MAC address
>>>     > > to be used by manufacturer. Ethernet manufacturer 
>>
>>may generate
>>
>>>     > > global unique MAC address using the OUI prefix and 
>>
>>address block of
>>
>>>     > > lower three-octet (24bit). Taking advantage of the
>>>     > addressing scheme,
>>>     > > GMPLS may use the lower three-octet exclusively if a unique
>>>     > > OUI number
>>>     > > is reserved for the protocol. With this labeling 
>>
>>scheme, GMPLS will
>>
>>>     > > control MAC forwarding entry, not VLAN table.
>>>     > >
>>>     > > All Ethernet frames controlled by GMPLS will have identical
>>>     > > OUI number
>>>     > > that they can easily be distinguished from other 
>>
>>Ethernet frames.
>>
>>>     > > In principle, the label lookup hardware is 
>>
>>identical to MAC lookup
>>
>>>     > > hardware in this labeling scheme. Therefore GMPLS 
>>
>>implemented
>>
>>>     > > switch may still function as normal Ethernet 
>>
>>bridge to the frames
>>
>>>     > > that OUI number is not GMPLS. This also facilitates GMPLS
>>>     > implemented
>>>     > > switches being deployed in operating Ethernet with minimum
>>>     > > service disruption.
>>>     > >
>>>     > > Note also that above proposed label encoding 
>>
>>method is transparent
>>
>>>     > > to the use of Ethernet Length/Type field. End-user 
>>
>>device may use
>>
>>>     > > the Length/Type field as defined in IEEE 802.3 protocol.
>>>     > > It also allows network operators configure VLAN 
>>
>>for their own
>>
>>>     > > purpose.
>>>     > > When IEEE 802.1p is used in conjunction with 
>>
>>L2-LSP, the priority
>>
>>>     > > field of VLAN tag can also be used for imposing 
>>
>>consistent TE
>>
>>>     > > policy in
>>>     > > legacy switches and GMPLS switches.
>>>     > >
>>>     > > Any way, my conclusion is, there are other options 
>>
>>we may consider,
>>
>>>     > > and this issue is still open to discuss.
>>>     > >
>>>     > > Thanks,
>>>     > >
>>>     > > Sincerely,
>>>     > >
>>>     > > Jaihyung
>>>     > >
>>>     > >
>>>     > >
>>>     > >
>>>     > >
>>>     > > -----?? ???-----
>>>     > > ?? ??: "Heiles Juergen" <[email-masked]>
>>>     > > ?? ??: 2005-07-22 ?? 10:23:43
>>>     > > ?? ??: "Loa Andersson" <[email-masked]>, 
>>
>>"[email-masked]"
>>
>>>     > > <[email-masked]>
>>>     > > ??: "[email-masked]" <[email-masked]>, "[email-masked]"
>>>     > > <[email-masked]>
>>>     > > ??: RE: Frameformat in a l2cs gmpls rnvironment.
>>>     > >
>>>     > >
>>>     > >
>>>     > >
>>>     > >
>>>     > >
>>>     > > Loa,
>>>     > >
>>>     > > I interpret the ID as a proposal to use GMPLS for 
>>
>>VLAN setup.
>>
>>>     > > So GMPLS and VLAN to not compete. The VLAN is at the data
>>>     > > plane and GMPLS at the control plane. The question 
>>
>>is how and
>>
>>>     > > should different control plane techniques like GMPLS and
>>>     > > (GVRP and STB) work together?
>>>     > >
>>>     > > Regards
>>>     > >
>>>     > > Juergen
>>>     > >
>>>     > >
>>>     > > > From: [email-masked]
>>>     > > > [mailto:[email-masked]] On Behalf Of 
>>
>>Loa Andersson
>>
>>>     > > > Sent: Friday, July 22, 2005 2:53 PM
>>>     > > > To: [email-masked]
>>>     > > > Cc: [email-masked]; [email-masked]
>>>     > > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
>>>     > > >
>>>     > > > Richard,
>>>     > > >
>>>     > > > I agree to most of this. Since we have doubts 
>>
>>about the viability
>>
>>>     > > > of taking GMPLS all the way to end-user or 
>>
>>enterprise I think it
>>
>>>     > > > would be good, from a wg perspective, if we 
>>
>>agreed to solve the
>>
>>>     > > > core network problems first.
>>>     > > >
>>>     > > > Do you have any comment on the requirement to 
>>
>>run both VLANs and
>>
>>>     > > > GMPLS on the same switch?
>>>     > > >
>>>     > > > /Loa
>>>     > > >
>>>     > > > [email-masked] wrote:
>>>     > > > > Regardless of whether or not a switch is 
>>
>>directly connected
>>
>>>     > > >  > to hosts, it must be able to forward packets using the
>>>     > > > connectionless
>>>     > > >  > Ethernet data plane. This is due to the fundamental
>>>     > > > requirement that
>>>     > > >  > for GMPLS switches to be able to exchange control
>>>     > > information with
>>>     > > >  > each other, a data plane for control traffic 
>>
>>must be present.
>>
>>>     > > >  > This is akin to using the IP data plane for MPLS
>>>     > > signalling in an
>>>     > > >  > IP/MPLS network. An alternative would be to 
>>
>>use a static
>>
>>>     > > reserved
>>>     > > >  > L2-LSP for control traffic in the same way 
>>
>>that reserved
>>
>>>     > > VPI/VCIs
>>>     > > >  > are used for PNNI signalling in ATM.
>>>     > > > >
>>>     > > > > Regarding connecting hosts to GMPLS switches, I
>>>     > personally don't
>>>     > > >  > think extending L2-LSPs into the 
>>
>>enterprise/home network is
>>
>>>     > > >  > commercially viable. However, if you do want to use
>>>     > > GMPLS switches
>>>     > > >  > in the home/enterprise network and for some reason
>>>     > don't want to
>>>     > > >  > extend L2-LSPs down to the host then you will not be
>>>     > performing
>>>     > > >  > normal Ethernet Mac address switching anyway. 
>>
>>Instead you will
>>
>>>     > > >  > need some kind of policy on the switch that maps
>>>     > connectionless
>>>     > > >  > Ethernet packets (e.g. based on MAC src/dest, 802.1p,
>>>     > VLAN) to a
>>>     > > >  > L2-LSP. This is because multiple L2-LSPs to the same
>>>     > destination
>>>     > > >  > (e.g. a gateway router) may exist for 
>>
>>different services/flows
>>
>>>     > > >  > (e.g. video download, VoIP call, etc.).
>>>     > > > >
>>>     > > > > Regards,
>>>     > > > > Richard
>>>     > > > >
>>>     > > > >
>>>     > > > >>From: [email-masked]
>>>     > > [mailto:[email-masked]]On
>>>     > > > >>Behalf Of Par Mattsson
>>>     > > > >>Sent: 22 July 2005 11:42
>>>     > > > >>To: Loa Andersson
>>>     > > > >>Cc: [email-masked]
>>>     > > > >>Subject: Re: Frameformat in a l2cs gmpls rnvironment.
>>>     > > > >>
>>>     > > > >>
>>>     > > > >>
>>>     > > > >>>Per and Dimitri,
>>>     > > > >>>
>>>     > > > >>>I would like to come down stronger than that, 
>>
>>for me it is
>>
>>>     > > > >>>a very strong requirement that the same 
>>
>>switch can handle
>>
>>>     > > > >>>both VLANs and GMPLs trafic correctly. I 
>>
>>can't dsee how that
>>
>>>     > > > >>>could be done if using the VLAN tpid to indicate GMPLS
>>>     > > > >>>traffic.
>>>     > > > >>
>>>     > > > >>If you ever want that same switch to handle 
>>
>>traffic for a
>>
>>>     > > directly
>>>     > > > >>connected  host (not to uncommen) you would 
>>
>>want that to
>>
>>>     > > use normal
>>>     > > > >>ethernet macaddress switching. So of course 
>>
>>you do not want
>>
>>>     > > > to have to
>>>     > > > >>choose between vlan and gmpls, you would want 
>>
>>both at the
>>
>>>     > > same time.
>>>     > > > >>
>>>     > > > >>/per
>>>     > > > >>
>>>     > > > >>
>>>     > > > >>
>>>     > > > >>>/Loa
>>>     > > > >>>
>>>     > > > >>>Par Mattsson wrote:
>>>     > > > >>>
>>>     > > > >>>>>hi par, one of the possibilities that has 
>>
>>been considered
>>
>>>     > > > >>
>>>     > > > >>to cope with
>>>     > > > >>
>>>     > > > >>>>>this requirement is to use a dedicated TPID for the
>>>     > > > >>
>>>     > > > >>Ethernet labeled
>>>     > > > >>
>>>     > > > >>>>>frames; this would allow differentiated 
>>
>>processing with
>>
>>>     > > > non-labeled
>>>     > > > >>>>>framesthanks.
>>>     > > > >>>>
>>>     > > > >>>>
>>>     > > > >>>>That seems to make more sence. If that frame is to be
>>>     > > sized like a
>>>     > > > >>>>802.1q
>>>     > > > >>>>frame. There is not that much space left to 
>>
>>a label. Or is
>>
>>>     > > > >>
>>>     > > > >>the demand to
>>>     > > > >>
>>>     > > > >>>>use jumboframes ?
>>>     > > > >>>>Has there been any discussion on labelstacking, and
>>>     > > > mainly where to
>>>     > > > >>>>place
>>>     > > > >>>>the information?
>>>     > > > >>>>
>>>     > > > >>>>Regards.
>>>     > > > >>>>Per
>>>     > > > >>>>
>>>     > > > >>>>
>>>     > > > >>>>
>>>     > > > >>>
>>>     > > > >>>
>>>     > > > >>>--
>>>     > > > >>>Loa Andersson
>>>     > > > >>>
>>>     > > > >>>Principal Networking Architect
>>>     > > > >>>Acreo AB                           phone:  
>>
>>+46 8 632 77 14
>>
>>>     > > > >>>Isafjordsgatan 22                  mobile: 
>>
>>+46 739 81 21 64
>>
>>>     > > > >>>Kista, Sweden                      email:
>>>     > > [email-masked]
>>>     > > > >>>                                            [email-masked]
>>>     > > > >>>
>>>     > > > >>
>>>     > > > >>
>>>     > > > >>
>>>     > > > >
>>>     > > >
>>>     > > >
>>>     > > > --
>>>     > > > Loa Andersson
>>>     > > >
>>>     > > > Principal Networking Architect
>>>     > > > Acreo AB                           phone:  +46 8 
>>
>>632 77 14
>>
>>>     > > > Isafjordsgatan 22                  mobile: +46 
>>
>>739 81 21 64
>>
>>>     > > > Kista, Sweden                      email:  
>>
>>[email-masked]
>>
>>>     > > >                                             [email-masked]
>>>     > > >
>>>     > >
>>>     > >
>>>     > >
>>>     > >
>>>     >
>>>     >
>>>     >
>>>
>>
>>--
>>Loa Andersson
>>
>>Principal Networking Architect
>>Acreo AB                           phone:  +46 8 632 77 14
>>Isafjordsgatan 22                  mobile: +46 739 81 21 64
>>Kista, Sweden                      email:  [email-masked]
>>                                            [email-masked]
>>
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Thu, 28 Jul 2005 10:42:06 +0000
Reply-To: <[email-masked]>
From: "Itaru Nishioka" <[email-masked]>
To: <[email-masked]>
Subject: RE: draft-otani-ccamp-interas-gmpls-te-03.txt
Date: Thu, 28 Jul 2005 19:48:48 +0900
Organization: nec

This draft gives a good start point  for "Distributing Reachability and TE Information" 
in inter-domain framework  (Section 4 of draft-ietf-ccamp-inter-domain-framework-04.txt).

I also hope re-charter as soon as possible.

Thanks,

itaru.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tomohiro Otani
> Sent: Thursday, July 21, 2005 7:09 PM
> To: [email-masked]
> Subject: draft-otani-ccamp-interas-gmpls-te-03.txt
> 
> Hi everyone,
> 
> We updated the GMPLS inter-domain TE req. draft.  Since last 
> meeting, we believe this document has been already stable and 
> well-recognized, however, per the last meeting discussion, we 
> have to wait for the charter being revised, in order to be a 
> WG document (This must be initiated by chairs).
> 
> Until then, we continue to update the contents and indeed 
> welcome your feedback and comments through this list or 
> during the meeting in Paris.
> 
> Regards,
> 
> tomo

Delivery-date: Thu, 28 Jul 2005 09:30:13 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-01.txt 
Date: Thu, 28 Jul 2005 11:29:25 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Arthi, JP

A few comments on this draft:

-In section 5.2, I'm not sure that path p3 is a valid one:
"RO-X1-ASBR1(loose)-ASBR4(strict)-ASBR7(strict)-ASBR9(loose)-R6.
What does ERO sub-objects for ASBR4 and ASBR5 represent?
Actually this cannot be an interface or router id, because the ERO would =
be invalid (cannot be strict as ASBR4 and ASBR7 ar not directly =
connected). The only way to proceed in this way is to include =
ERO-sub-objects corresponding to FA-LSP or LSP-Segment TE-links =
(numbered or unnumbered tunnel interface id).=20
One could assume that RO would obtain such ERO including FA-LSP or =
LSP-segment as a result of a PCE based compuation...
On receip of a Path message the ERO subobject would allow to directly =
determine the underlying FA-LSP or LSP-Segment...

By the way it would also be good to ilusrate the case of abstract nodes, =
e.g. a path made of AS number ERO subobjects...

-It would be good to add some text related to failure detection, at the =
end of 6.1.3. In case of stitching or nesting, the PLR could rely on =
BFD-MPLS so as to rapidliy detect FA-LSP/LSP-Segment tail-end failure. =
This would help ensuring fast recovery...

-In section 6.2 the FRR considerations described in 6.1.3 for stiching =
and nesting, actually also apply to GMPLS Segment Recovery.

-Section 7 would benefif from some words on global reoptimization (ie =
with change of border routers)
Even if this is more a path computation issue this may have some impact =
on signaling...

-And two minor edits
Section 5.1.1: issue with B3 path, in the figure ASBR6 and ASBR7 are not =
connnected.=20
Section 8: [INTER-AS-TE-REQ] instead of [INTER-AREA-TE-REQS]

Hope this helps,

Best Regards

JL

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de=20
> [email-masked]
> Envoy=E9 : mardi 19 juillet 2005 21:50
> =C0 : [email-masked]
> Cc : [email-masked]
> Objet : I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-01.txt=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Common Control and=20
> Measurement Plane Working Group of the IETF.
>=20
> 	Title		: Inter domain GMPLS Traffic=20
> Engineering - RSVP-TE extensions
> 	Author(s)	: A. Ayyangar, J. Vasseur
> 	Filename	: draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
> 	Pages		: 17
> 	Date		: 2005-7-19
> =09
> This document describes extensions to Generalized=20
> Multi-Protocol Label Switching (GMPLS) Resource ReserVation=20
> Protocol - Traffic Engineering
> (RSVP-TE) signaling required to support mechanisms for the=20
> establishment and maintenance of GMPLS Traffic Engineering=20
> (TE) Label Switched Paths (LSPs), both packet and non-packet,=20
> that traverse multiple domains. For the purpose of this=20
> document, a domain is considered to be any collection of=20
> network elements within a common realm of address space or=20
> path computation responsibility. Examples of such domains=20
> include Autonomous Systems, IGP areas and GMPLS overlay networks.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-dom
> ain-rsvp-te-01.txt
>=20
> To remove yourself from the I-D Announcement list, send a=20
> message to [email-masked] with the word=20
> unsubscribe in the body of the message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login=20
> with the username "anonymous" and a password of your e-mail=20
> address. After logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-ccamp-inter-domain-rsvp-te-01.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE=20
> /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-01.txt".
> =09
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 	=09
> 	=09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20

Delivery-date: Thu, 28 Jul 2005 09:00:49 +0000
Date: Thu, 28 Jul 2005 11:00:14 +0200
From: Huub van Helvoort <[email-masked]>
To: ccamp <[email-masked]>
Subject: Test - please ignore

Sorry for this.

Delivery-date: Thu, 28 Jul 2005 08:41:58 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: "Ali Sajassi \(sajassi\)" <[email-masked]>, "Heiles Juergen" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Bcc: 
Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Date: Thu, 28 Jul 2005 17:42:55 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message

Hi, Ali
 
sorry for late in this response. 
a bit busy at preparing trip to Paris. 
see in-line

[snip] 
>>> > 
>>> >> 3. use lower 3 bytes of MAC address for L2 label encoding. 
>>> > 
>>> >This approach has several issues: 
>>> >1) how does MAC addresses get distributed among the bridges ? 
>>> >How does this distribution works during a link or node failure ? 
>>> >How does it recover from a link or node failure ? 
>> 
>> Ali, 
>> The questions are really implementation dependent. 
>> Can we defer this discussion after Paris meeting? 
>> However, I see the solution will not be so different than 
>> what RSVP-TE has been done for other transport network. 
> 
>These questions are not implementation dependent. IEEE bridges have a 
>well established procedures for handling link and node failures based on 
>RSTP/MSTP and "independent" interaction between these procedures and 
>RSVP-TE is questionable at best. If you think this is not the case, then 
>I encourage you to specify how this interaction works. 

Honestly, it's not clear for me what is the point you trying to make. 
RSVP-TE works on well-established IP routing protocols, 
and MPLS/GMPLS define LSP restoration mechanism well. 
I believe you understand well how RSVP-TE distributes 
generic label between nodes in the event of failure. 
I'm a bit surprised a cisco guy saying such doubt on RSVP-TE. 
I still feel this is not necessary talk at this stage. 
Clear answer can be given after we settle down solution.

>> 
>> >2) Will you assign a separate provider MAC for each customer MAC. 
>> >If so, then how do you address MAC scalability. 
>> >If not, then how do you take care of 1-to-N mapping between provider 
>> >MAC address and customer MAC addresses and how do you handle 
>> multipoint 
>> >connections. 
>> 
>> 
>> I think you are asking the issue of L2 label stacking or LSP 
>> aggregation, or perhaps some VPN application similar to 802.1ad. 
>> There are some opinions on whether label stacking is 
>> necessary in L2SC domain. This is actually the question 
>> Adrian keep asking us. 
> 
>Since you are using provider MAC address as a label, then by label 
>stacking, I presume you mean encapsulating customers MAC addresses 
>inside the provider MAC. 

That'll depend on service function configured in ingress node.
 
1. If ingress is PSC, (i.e. L3/L4 switching or MPLS), provider MAC header 
?will encapsulate user IP packet or MPLS packet
 
2. If ingress provides L2 VPN service, provider MAC will encapsulate 
?user MAC, thus it'll be MAC-in-MAC as you said.
 
3. If ingress provides end-to-end L2-LSP connection, it'll simply change 
?user MAC address to GMPLS prefixed L2 label at ingress. 
 this case only be valid in enterprise/access network.

I told it before in reply to Juergen. 
please read past mails carefully. 
Scalability performance must be discussed respectively 
at the three cases.

>If you want to go to that extend, then why not 
>just simply use IEEE 802.1ah that provide both stacking of MAC addresses 
>as well as it provides you with a 20-bit tag for service instance 
>identification.

No, because of at least four reasons,
 
1. assuming new definition of dataplane is not in CCAMP scope, 
  as you also agreed.
 
2. such machine will only be compatible with the same kind. 
?backward compatibility to 802.1D/Q bridge is important goal to us, 
?so that the GMPLS implemented switch may inter-mix with 
?legacy bridges.
 
3. we are not intending to develop it just for metro-LAN service. 
  as I told in above, several different service application, 
  such as campus Internet service, MPLS-LSP backbone, etc. 
  can also be considered.
 
4. we can achieve far more flexible, compatible, scalable solution 
 than your proposal if we combine L2 label with MPLS shim labels. 
?besides, if the format you propose is something like 
?[MAC][20bit-tag][ IP ][ .. data ...] 
?than is it in fact a MPLS label switching? 
?if it is your proposal, why not just extend MPLS specs a bit, 
?rather than creating new one?

>> I personally think that we can achieve LSP aggregation with 
>> the aid of MPLS shim label, however I think this is too 
>> premature discussion. 
>> All I can say at the moment is, lower 3 octet of MAC address 
>> gives us 16M size of label space and this is enough to 
>> implement link-local, site-local or even some domain-local LSPs. 
>> Between the L2-LSP boundary, it needs further discussion. 
>> 
>It is one thing to have the address space, it is another thing to have 
>proper management and control protocols to manage that space. The big 
>question is what type of control and management protocols you intend to 
>use for that space and how it interacts with the existing IEEE control 
>and management protocols. Also, if it is one-to-one mapping, then we are 
>back to square one regarding MAC address scalability.

control ? ==> of course, GMPLS.  
management? ==> not in my interest.
 
it seems you are talking about address management mechanism. 
Precedence of such solution is far later.

>> > 
>> >3) how do handle customer FCS retention when doing this MAC 
>> translation 
>> >stuff ?? 
>> 
>>   I haven't seen any application that requires retention of 
>> original FCS image. 
>> 802.1D specification recommends recalculation of FCS when 
>> there is any change in MAC. I see no problem if FCS is 
>> recalculated at the label swapping switch. 
> 
>Please refer to all the discussions on the PWE3 mailing list regarding 
>FCS retention. There are certain applications that require it and that's 
>why there is a draft for it.

ok, thanks, I found there's some people worrying about this, 
however, such worry is not in the scope of my idea. 
It is even not clear if there's requirement exist for 
PWE service using L2-LSP.

[snip] 
>> 
>> If we define the scope of L2 label as site-local or 
>> domain-local, we don't need such label swapping operation. 
>> However, if we want link-local label, and find out that it is 
>> very useful 
>> (* actually I do think it'll be very useful *), I think we 
>> need to consult such modification with IEEE. 
>> Technically speaking, I don't think replacing the label value 
>> after normal MAC lookup will serious change hardware architecture. 
>> Also, it doesn't break conformance rule. 
>> Did any 802.1 spec. say that input MAC must be identical to 
>> output MAC? 
> 
>There is no MAC address swapping or translation in .1D, .1Q, or its 
>future standards. If there is MAC address translation, then you can run 
>into quite a few unwanted side affects.

so, which conformance rule does it break in 802.1D/Q spec. 
if we translate MAC address ? 
In fact, some bridge vender sells MAC translating switch 
for security purpose because it can hide internal MAC information. 
It doesn't cause any side-effect. 
You need to be specific what side-effect it may cause.

[snip] 
>> > 
>> >How does the redundancy work in here. Are you using bridge 
>> protocol in 
>> >conjunction with GMPLS protocol. If you do, then there are bunch of 
>> >issues. 
>> 
>> 
>> Yes I do. 
>> I intend GMPLS implemented switches being deployed in 
>> operating network 
>> as normal Ethernet switch that perform bridge protocols. 
>> When they detect (or snoop) RSVP-TE message, they establish L2-LSP 
>> and selectively forward those GMPLS prefixed frames via the L2-LSP. 
>> The message path that RSVP-TE is exchanged, thus L2-LSPs are 
>> established, does not necessarily be identical to spanning tree path 
>> because L2-LSPs can be established via shortest path. 
>> I welcome further discussion on this issue, but I hope to continue it 
>> after Paris meeting, if you may. 
> 
>If RSVP-TE traffic uses link-state based protocols and bridged traffic 
>uses distance-based protocols (e.g., RSTP) and these traffic operate 
>independently from each other and both types of traffic come through the 
>same port, then how does a standard IEEE bridge know how to discern 
>these packets and which packets to take action on ? - e.g., what IEEE 
>procedures do you recommend to be used ?? If you are talking about 
>different physical ports, then you are talking about different 
>independent networks with different set of links and topology for each 
>which is not the intent here.

Normal MAC lookup is sufficient. 
MAC entries for normal frames are learned as bridge relay function. 
The frames are forwarded via active ports as usual. 
MAC entries for GMPLS frames are configured by GMPLS protocols. 
GMPLS frames may be forwarded via active ports as well as 
some standby ports that are not used by spanning tree. 
Of course in this case, GMPLS control messages need to be 
forwarded via standby ports. 

Thanks 
 
Jaihyung

 

-----?? ???----- 
?? ??: "Ali Sajassi (sajassi)" <[email-masked]> 
?? ??: 2005-07-27 ?? 12:00:53 
?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: "[email-masked]" <[email-masked]> 
??: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet 

Jaihyung, 

Please refer to my comments inline ... 

[snip] 
> > 
> >> 3. use lower 3 bytes of MAC address for L2 label encoding. 
> > 
> >This approach has several issues: 
> >1) how does MAC addresses get distributed among the bridges ? 
> >How does this distribution works during a link or node failure ? 
> >How does it recover from a link or node failure ? 
> > 
>  
>  
> Ali, 
> The questions are really implementation dependent. 
> Can we defer this discussion after Paris meeting? 
> However, I see the solution will not be so different than 
> what RSVP-TE has been done for other transport network. 
> 

These questions are not implementation dependent. IEEE bridges have a 
well established procedures for handling link and node failures based on 
RSTP/MSTP and "independent" interaction between these procedures and 
RSVP-TE is questionable at best. If you think this is not the case, then 
I encourage you to specify how this interaction works.  

>  
> >2) Will you assign a separate provider MAC for each customer MAC. 
> >If so, then how do you address MAC scalability. 
> >If not, then how do you take care of 1-to-N mapping between provider 
> >MAC address and customer MAC addresses and how do you handle 
> multipoint 
> >connections. 
>  
>  
> I think you are asking the issue of L2 label stacking or LSP 
> aggregation, or perhaps some VPN application similar to 802.1ad. 
> There are some opinions on whether label stacking is 
> necessary in L2SC domain. This is actually the question 
> Adrian keep asking us. 

Since you are using provider MAC address as a label, then by label 
stacking, I presume you mean encapsulating customers MAC addresses 
inside the provider MAC. If you want to go to that extend, then why not 
just simply use IEEE 802.1ah that provide both stacking of MAC addresses 
as well as it provides you with a 20-bit tag for service instance 
identification. 

> I personally think that we can achieve LSP aggregation with 
> the aid of MPLS shim label, however I think this is too 
> premature discussion. 
> All I can say at the moment is, lower 3 octet of MAC address 
> gives us 16M size of label space and this is enough to 
> implement link-local, site-local or even some domain-local LSPs. 
> Between the L2-LSP boundary, it needs further discussion. 
> 
It is one thing to have the address space, it is another thing to have 
proper management and control protocols to manage that space. The big 
question is what type of control and management protocols you intend to 
use for that space and how it interacts with the existing IEEE control 
and management protocols. Also, if it is one-to-one mapping, then we are 
back to square one regarding MAC address scalability. 

>  
> > 
> >3) how do handle customer FCS retention when doing this MAC 
> translation 
> >stuff ?? 
> > 
>  
>  
>   I haven't seen any application that requires retention of 
> original FCS image. 
> 802.1D specification recommends recalculation of FCS when 
> there is any change in MAC. I see no problem if FCS is 
> recalculated at the label swapping switch. 

Please refer to all the discussions on the PWE3 mailing list regarding 
FCS retention. There are certain applications that require it and that's 
why there is a draft for it. 

>  
>  
> >> 802.1Q bridge forwards Ethernet frames using two dataplane tables 
> >> - MAC forwarding table and VLAN forwarding table. 
> >> Bridge control protocols, such as GARP, GVRP, GMRP, 
> manipulate one of 
> >> the two dataplane entities. 
> > 
> >This is not correct. Bridges don't have different databases for MAC 
> >forwarding and VLAN forwarding. They have filtering datebase(s) with 
> >corresponding IDs (FIDs). VLAN IDs get mapped to FIDs based on 
> >operation mode (IVL versus SVL). Then once a filtering database is 
> >identified, then a MAC address lookup is performed for forwarding. 
> >Bridge control protocols use a designated MAC addressed and based on 
> >these MAC addressed, the bridge knows how to process the frame. 
>  
>  
> oh, come on . 
> I explained it in conceptual level and you re-described it in 
> implementation level.  The contextual meaning is same. 
> I believe you don't deny the existence of two types of 
> filtering databases, for MAC and VID, and the control of GARP 
> over these databases. 
> This is unnecessary argument, I think. 
>  

No, I didn't describe the implementation but instead I described it as 
specified in .1D and .1Q. However, I see what you were trying to say and 
I think it was just a poor choice of words. 

[snip] 
>  
> If we define the scope of L2 label as site-local or 
> domain-local, we don't need such label swapping operation. 
> However, if we want link-local label, and find out that it is 
> very useful 
> (* actually I do think it'll be very useful *), I think we 
> need to consult such modification with IEEE. 
> Technically speaking, I don't think replacing the label value 
> after normal MAC lookup will serious change hardware architecture. 
> Also, it doesn't break conformance rule. 
> Did any 802.1 spec. say that input MAC must be identical to 
> output MAC? 

There is no MAC address swapping or translation in .1D, .1Q, or its 
future standards. If there is MAC address translation, then you can run 
into quite a few unwanted side affects. 

[snip] 
>  
>  
> [snip] 
> > 
> >How does the redundancy work in here. Are you using bridge 
> protocol in 
> >conjunction with GMPLS protocol. If you do, then there are bunch of 
> >issues. 
>  
>  
> Yes I do. 
> I intend GMPLS implemented switches being deployed in 
> operating network 
> as normal Ethernet switch that perform bridge protocols. 
> When they detect (or snoop) RSVP-TE message, they establish L2-LSP 
> and selectively forward those GMPLS prefixed frames via the L2-LSP. 
> The message path that RSVP-TE is exchanged, thus L2-LSPs are 
> established, does not necessarily be identical to spanning tree path 
> because L2-LSPs can be established via shortest path. 
> I welcome further discussion on this issue, but I hope to continue it 
> after Paris meeting, if you may. 

If RSVP-TE traffic uses link-state based protocols and bridged traffic 
uses distance-based protocols (e.g., RSTP) and these traffic operate 
independently from each other and both types of traffic come through the 
same port, then how does a standard IEEE bridge know how to discern 
these packets and which packets to take action on ? - e.g., what IEEE 
procedures do you recommend to be used ?? If you are talking about 
different physical ports, then you are talking about different 
independent networks with different set of links and topology for each 
which is not the intent here. 

Cheers, 
Ali  

>  
>  
> Thanks 
>  
> Jaihyung 
>  
> 
> -----?? ???----- 
> ?? ??: "Ali Sajassi (sajassi)" <[email-masked]> 
> ?? ??: 2005-07-26 ?? 8:13:56 
> ?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles 
> Juergen" <[email-masked]>, "[email-masked]" 
> <[email-masked]> 
> ??: "[email-masked]" <[email-masked]> 
> ??: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ 
> GMPLS Ethernet 
> 
> 
> 
> 
> 
> 
> 
> 
> Jaihyung, 
> 
> It seems to me that your primary objective is to use the existing 
> Ethernet switches with new control plane (GMPLS) to setup TE 
> paths for 
> different applications. And you mentioned three approaches for doing 
> this in your email. However, all three of them have issues 
> and are not 
> viable. Lets go over them ... 
> 
> > 
> > In below mail, I discussed about three proposed approaches. 
> >  
> >  
> > 1. using VLAN tag as it is for L2 label encoding. 
> 
> As you know this approach has scalability issue and you are 
> limited to 
> 4K services in the network and if you try to use the upcoming IEEE 
> 802.1ad standard to make VLANs, interface specific, then you 
> will need 
> new switches and not existing Ethernet switches. Even if you 
> use these 
> newer switches, you will still be limited to 4K services per 
> interface 
> and it would defeat the objective of using existing switches. 
> 
> > 
> > 2. defining new protocol ID (TPID) and borrow VLAN tag format, 
> > ?or extended VLAN tag to implement label swapping. 
> > 
> 
> This approach requires new data plane functionality to be implemented 
> (which defeats the objective of using existing switches). 
> 
> > 3. use lower 3 bytes of MAC address for L2 label encoding. 
> >  
> 
> This approach has several issues: 
> 1) how does MAC addresses get distributed among the bridges ? 
> How does 
> this distribution works during a link or node failure ? How does it 
> recover from a link or node failure ? 
> 
> 2) Will you assign a separate provider MAC for each customer 
> MAC. If so, 
> then how do you address MAC scalability. If not, then how do you take 
> care of 1-to-N mapping between provider MAC address and customer MAC 
> addresses and how do you handle multipoint connections. 
> 
> 3) how do handle customer FCS retention when doing this MAC 
> translation 
> stuff ?? 
> 
> > 
> > 802.1Q bridge forwards Ethernet frames using two dataplane tables 
> > - MAC forwarding table and VLAN forwarding table. 
> > Bridge control protocols, such as GARP, GVRP, GMRP, 
> > manipulate one of the two dataplane entities. 
> 
> This is not correct. Bridges don't have different databases for MAC 
> forwarding and VLAN forwarding. They have filtering datebase(s) with 
> corresponding IDs (FIDs). VLAN IDs get mapped to FIDs based 
> on operation 
> mode (IVL versus SVL). Then once a filtering database is identified, 
> then a MAC address lookup is performed for forwarding. Bridge control 
> protocols use a designated MAC addressed and based on these MAC 
> addressed, the bridge knows how to process the frame. 
> 
> > 
> > Similarly, option 1 and 3 are about which one of two 
> > dataplane entities 
> > GMPLS protocol should control on behalf of bridge control 
> protocols. 
> > The two proposals do not intend to modify bridge behavior 
> > seriously, such as MAC learning, aging, filtering. 
> > Therefore, the approaches 1 and 3 are in the scope of CCAMP. 
> 
> If that's the intention, you may find out soon you get more than what 
> you asked for :-) 
> 
> > 
> > (% note however, I would regard implementing label swapping 
> > function is acceptable change considering the Internal Sublayer 
> > design of 802.1D bridge.) 
> > 
> 
> The only way of doing this is using VID translation table 
> specified in 
> IEEE 802.1ad which requires new data-plane functionality and thus 
> existing bridges cannot be used !! 
> 
> Also if going the route of tag swapping, you may consider using IEEE 
> 802.1ah. As the editor of .1ah, I can go over the details 
> when I get a 
> chance. 
>  
> > 
> > However, option 2 is about what TPID code we will 
> > choose to implement new switching function. 
> > The switch of this implementation should have new hardware 
> > design in addition to normal bride hardware. 
> > I think such proposal as option 2 is out of CCAMP scope. 
> 
> Yes. 
> 
> > 
> > Overall objective is improving scalability, traffic 
> engineering (TE) 
> > characteristics of 802.1 bridge that it can be reliable, manageable 
> > enough to replace some core routers. 
> 
> Easier said than done :-) 
> 
> > The switching technique you mentioned above, such as 
> > Ethernet over MPLS as defined by PWE3 and L2VPN, 
> > are all actually router based technology, however this 
> > work is based on simple bridge architecture. 
> > Cost-effectiveness is the key differentiator. 
> > 
> 
> The devils are in the details and once you worked out the 
> details, you 
> will see the issues. 
>  
> > 
> > In access or enterprise network, capability of providing end-to-end 
> > L2-LSP will enable service providers policing, measuring, charging 
> > application flows using Ethernet based network. This will 
> eventually 
> > improve income structure and introduce new session based commercial 
> > service. I have been discussing this aspect in mail thread of 
> > title 'End-to-end L2-LSP'.  Please read the mail thread and comment 
> > on the discussion. 
> >  
> > 
> > >You mentioned to use the MAC address or part of it as a label. 
> > >The TRILL working group is defining shortest path routing 
> > for Ethernet. 
> > >How would this fit together? 
> >  
> > 
> > TRILL employs new encapsulation layer outside of Ethernet frames. 
> > However in my proposal of option-3, I simply use the 
> Ethernet header 
> > to encode GMPLS label. 
> > 
> > The overall format of rbridge is  
> > [Ethernet][r-tag][Ethernet][ data..] 
> > It is not LSP based technology but a connectionless routing bridge. 
> > TTL count is very important in rbridge because frames are routed 
> > hop-by-hop and it may loop. 
> > 
> > Whereas in option-3 above, Ethernet frames that have certain 
> > OUI prefix in MAC address are forwarded via a path that 
> > GMPLS protocol has configured on MAC forwarding table. 
> >  
> 
> How does the redundancy work in here. Are you using bridge 
> protocol in 
> conjunction with GMPLS protocol. If you do, then there are bunch of 
> issues. If you don't, then what is it used and how does it 
> interact with 
> bridging protocols ?? 
> 
> -Ali 
> 
> 
> > 
> > Thanks 
> >  
> > Jaihyung 
> >  
> >  
> > 
> > -----?? ???----- 
> > ?? ??: "Heiles Juergen" <[email-masked]> 
> > ?? ??: 2005-07-25 ?? 6:44:34 
> > ?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles 
> > Juergen" <[email-masked]>, "[email-masked]" 
> > <[email-masked]> 
> > ??: "[email-masked]" <[email-masked]> 
> > ??: RE: Frameformat in a l2cs gmpls rnvironment. 
> > 
> > 
> > 
> > 
> > 
> > 
> > Dear Jaihyung, 
> > 
> > you mention several options that could be used as a label. 
> > Most of them have strong impacts on the data plane and 
> > introduce new layer networks. Is this in the scope of CCAMP? 
> > What is the goal, to introduce a control plane for a existing 
> > L2 technology or introduce a new L2 technology? What would be 
> > the benefit of such a new L2 co switching technology compared 
> > to Ethernet over MPLS as defined by PWE3 and L2VPN? 
> > You mentioned to use the MAC address or part of it as a 
> > label. The TRILL working group is defining shortest path 
> > routing for Ethernet. How would this fit together? 
> > 
> > 
> > Regards 
> > 
> > Juergen 
> >  
> > 
> > 
> > 
> > 
> > > From: CHO, JAI HYUNG [mailto:[email-masked]] 
> > > Sent: Saturday, July 23, 2005 6:19 AM 
> > > To: Heiles Juergen; [email-masked] 
> > > Cc: [email-masked] 
> > > Subject: RE: Frameformat in a l2cs gmpls rnvironment. 
> > > 
> > > 
> > > Dear Juergen, Par and all, 
> > > 
> > > The proposed framework of L2SC was not intended to suggest 
> > > any specific solution. It is still an open question. 
> > > As Adrian noted, it only aims to present requirements 
> > > as in scenarios that may drive people toward next step in many 
> > > viable solutions. 
> > > 
> > > In fact, there are other options we may also consider for L2 
> > > label encoding. 
> > > IEEE 802.1 Ethernet bridges forward frames based on 48bits of 
> > > MAC address, 
> > > and additionally using VLAN tag. 
> > > 
> > > When the purpose of GMPLS control over Ethernet is not to 
> > > create new dataplane 
> > > but to utilize IEEE 802.1 bridge architecture, we may 
> > consider using 
> > > one of the two forwarding methods, MAC forwarding or VLAN 
> > forwarding. 
> > > (and perhaps any other combination of fields in MAC, but I'll 
> > > not discuss it) 
> > >  
> > > Use of VLAN ID for label encoding may automate VLAN configuration 
> > > using IP protocols. However, GMPLS protocol cannot use the 
> > > field exclusively 
> > > because public/private operators already use VLAN for various 
> > > purpose. 
> > > There is a potential conflict with existing use of VLAN and 
> > > GMPLS use of VLAN label.  
> > > Furthermore, scalability of VLAN ID has been frequently noted 
> > > as weakness 
> > > because the size of VLAN ID is at most 4096 (12bit). 
> > > 
> > > The scalability may be improved if the scope of VLAN label is 
> > > confined to 
> > > link-local, and some additional swapping function of VLAN ID 
> > > is introduced in 
> > > Internal Sublayer [802.1D] of GMPLS implemented switch. 
> > > However, this will only be effective when the configuration 
> > > of network 
> > > is mesh structure that multiple LSP paths exist. If the 
> > > configuration of network 
> > > is star or tree shape, as normal configuration of access network, 
> > > LSPs concentrate in root node and total number of 
> > > LSPs that the network can hold still be limited by available 
> > > label space 
> > > at a few root links. 
> > > 
> > > For these reasons, I do not think any form of VLAN ID label is 
> > > an appropriate choice for layer-2 label encoding. 
> > >  
> > > There are some other proposals assuming new assignment of 
> Ethernet 
> > > Length/Type value (e.g. new TPID in VLAN tag) and 
> re-definition of 
> > > information fields placed between 802.3 MAC header and IP packet. 
> > > In this case, only the format of VLAN tag or extended VLAN tag 
> > > is borrowed, however, inside the switching hardware, the 
> > > filter and relay, 
> > > etc. are totally different new dataplane switch. 
> > > 
> > > I do not see such approach is a GMPLS implementation for Ethernet 
> > > because the core switching technique is not 802.1 Ethernet 
> > > bridge at all. 
> > >  
> > > The other option we may consider is using MAC address filed 
> > as below. 
> > >  
> > > 
> > > +-------+-------+-------+-------+-------+-------+ 
> > > | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte | 
> > > +-------+-------+-------+-------+-------+-------+ 
> > > +-----------------------+-----------------------+ 
> > > |  OUI Prefix (=GMPLS)  |   DA-label (24bit)    | 
> > > +-----------------------+-----------------------+ 
> > > |  OUI Prefix (=GMPLS)  |   SA-label (24bit)    | 
> > > +---------------+-------+-----------------------+ 
> > > | Length/Type   | 
> > > +---------------+ 
> > >  
> > > 
> > > IEEE is designated by the ISO Council to act as the 
> > > registration authority 
> > > for the higher three-octet of OUI number in the MAC address 
> > > to be used by manufacturer. Ethernet manufacturer may generate 
> > > global unique MAC address using the OUI prefix and 
> address block of 
> > > lower three-octet (24bit). Taking advantage of the 
> > addressing scheme, 
> > > GMPLS may use the lower three-octet exclusively if a unique 
> > > OUI number 
> > > is reserved for the protocol. With this labeling scheme, 
> GMPLS will 
> > > control MAC forwarding entry, not VLAN table. 
> > >  
> > > All Ethernet frames controlled by GMPLS will have identical 
> > > OUI number 
> > > that they can easily be distinguished from other Ethernet frames. 
> > > In principle, the label lookup hardware is identical to 
> MAC lookup 
> > > hardware in this labeling scheme. Therefore GMPLS implemented 
> > > switch may still function as normal Ethernet bridge to the frames 
> > > that OUI number is not GMPLS. This also facilitates GMPLS 
> > implemented 
> > > switches being deployed in operating Ethernet with minimum 
> > > service disruption. 
> > >  
> > > Note also that above proposed label encoding method is 
> transparent 
> > > to the use of Ethernet Length/Type field. End-user device may use 
> > > the Length/Type field as defined in IEEE 802.3 protocol. 
> > > It also allows network operators configure VLAN for their own 
> > > purpose. 
> > > When IEEE 802.1p is used in conjunction with L2-LSP, the priority 
> > > field of VLAN tag can also be used for imposing consistent TE 
> > > policy in 
> > > legacy switches and GMPLS switches. 
> > >  
> > > Any way, my conclusion is, there are other options we may 
> consider, 
> > > and this issue is still open to discuss. 
> > >  
> > > Thanks, 
> > >  
> > > Sincerely, 
> > >  
> > > Jaihyung 
> > >  
> > >  
> > >  
> > >  
> > > 
> > > -----?? ???----- 
> > > ?? ??: "Heiles Juergen" <[email-masked]> 
> > > ?? ??: 2005-07-22 ?? 10:23:43 
> > > ?? ??: "Loa Andersson" <[email-masked]>, "[email-masked]" 
> > > <[email-masked]> 
> > > ??: "[email-masked]" <[email-masked]>, "[email-masked]" 
> > > <[email-masked]> 
> > > ??: RE: Frameformat in a l2cs gmpls rnvironment. 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Loa, 
> > > 
> > > I interpret the ID as a proposal to use GMPLS for VLAN setup. 
> > > So GMPLS and VLAN to not compete. The VLAN is at the data 
> > > plane and GMPLS at the control plane. The question is how and 
> > > should different control plane techniques like GMPLS and 
> > > (GVRP and STB) work together? 
> > > 
> > > Regards 
> > > 
> > > Juergen 
> > > 
> > > 
> > > > From: [email-masked] 
> > > > [mailto:[email-masked]] On Behalf Of Loa Andersson 
> > > > Sent: Friday, July 22, 2005 2:53 PM 
> > > > To: [email-masked] 
> > > > Cc: [email-masked]; [email-masked] 
> > > > Subject: Re: Frameformat in a l2cs gmpls rnvironment. 
> > > > 
> > > > Richard, 
> > > > 
> > > > I agree to most of this. Since we have doubts about the 
> viability 
> > > > of taking GMPLS all the way to end-user or enterprise I 
> think it 
> > > > would be good, from a wg perspective, if we agreed to solve the 
> > > > core network problems first. 
> > > > 
> > > > Do you have any comment on the requirement to run both 
> VLANs and 
> > > > GMPLS on the same switch? 
> > > > 
> > > > /Loa 
> > > > 
> > > > [email-masked] wrote: 
> > > > > Regardless of whether or not a switch is directly connected 
> > > >  > to hosts, it must be able to forward packets using the 
> > > > connectionless 
> > > >  > Ethernet data plane. This is due to the fundamental 
> > > > requirement that 
> > > >  > for GMPLS switches to be able to exchange control 
> > > information with 
> > > >  > each other, a data plane for control traffic must be 
> present. 
> > > >  > This is akin to using the IP data plane for MPLS 
> > > signalling in an 
> > > >  > IP/MPLS network. An alternative would be to use a static 
> > > reserved 
> > > >  > L2-LSP for control traffic in the same way that reserved 
> > > VPI/VCIs 
> > > >  > are used for PNNI signalling in ATM. 
> > > > > 
> > > > > Regarding connecting hosts to GMPLS switches, I 
> > personally don't 
> > > >  > think extending L2-LSPs into the enterprise/home network is 
> > > >  > commercially viable. However, if you do want to use 
> > > GMPLS switches 
> > > >  > in the home/enterprise network and for some reason 
> > don't want to 
> > > >  > extend L2-LSPs down to the host then you will not be 
> > performing 
> > > >  > normal Ethernet Mac address switching anyway. 
> Instead you will 
> > > >  > need some kind of policy on the switch that maps 
> > connectionless 
> > > >  > Ethernet packets (e.g. based on MAC src/dest, 802.1p, 
> > VLAN) to a 
> > > >  > L2-LSP. This is because multiple L2-LSPs to the same 
> > destination 
> > > >  > (e.g. a gateway router) may exist for different 
> services/flows 
> > > >  > (e.g. video download, VoIP call, etc.). 
> > > > > 
> > > > > Regards, 
> > > > > Richard 
> > > > > 
> > > > > 
> > > > >>From: [email-masked] 
> > > [mailto:[email-masked]]On 
> > > > >>Behalf Of Par Mattsson 
> > > > >>Sent: 22 July 2005 11:42 
> > > > >>To: Loa Andersson 
> > > > >>Cc: [email-masked] 
> > > > >>Subject: Re: Frameformat in a l2cs gmpls rnvironment. 
> > > > >> 
> > > > >> 
> > > > >> 
> > > > >>>Per and Dimitri, 
> > > > >>> 
> > > > >>>I would like to come down stronger than that, for me it is 
> > > > >>>a very strong requirement that the same switch can handle 
> > > > >>>both VLANs and GMPLs trafic correctly. I can't dsee how that 
> > > > >>>could be done if using the VLAN tpid to indicate GMPLS 
> > > > >>>traffic. 
> > > > >> 
> > > > >>If you ever want that same switch to handle traffic for a 
> > > directly 
> > > > >>connected  host (not to uncommen) you would want that to 
> > > use normal 
> > > > >>ethernet macaddress switching. So of course you do not want 
> > > > to have to 
> > > > >>choose between vlan and gmpls, you would want both at the 
> > > same time. 
> > > > >> 
> > > > >>/per 
> > > > >> 
> > > > >> 
> > > > >> 
> > > > >>>/Loa 
> > > > >>> 
> > > > >>>Par Mattsson wrote: 
> > > > >>> 
> > > > >>>>>hi par, one of the possibilities that has been considered 
> > > > >> 
> > > > >>to cope with 
> > > > >> 
> > > > >>>>>this requirement is to use a dedicated TPID for the 
> > > > >> 
> > > > >>Ethernet labeled 
> > > > >> 
> > > > >>>>>frames; this would allow differentiated processing with 
> > > > non-labeled 
> > > > >>>>>framesthanks. 
> > > > >>>> 
> > > > >>>> 
> > > > >>>>That seems to make more sence. If that frame is to be 
> > > sized like a 
> > > > >>>>802.1q 
> > > > >>>>frame. There is not that much space left to a label. Or is 
> > > > >> 
> > > > >>the demand to 
> > > > >> 
> > > > >>>>use jumboframes ? 
> > > > >>>>Has there been any discussion on labelstacking, and 
> > > > mainly where to 
> > > > >>>>place 
> > > > >>>>the information? 
> > > > >>>> 
> > > > >>>>Regards. 
> > > > >>>>Per 
> > > > >>>> 
> > > > >>>> 
> > > > >>>> 
> > > > >>> 
> > > > >>> 
> > > > >>>-- 
> > > > >>>Loa Andersson 
> > > > >>> 
> > > > >>>Principal Networking Architect 
> > > > >>>Acreo AB                           phone:  +46 8 632 77 14 
> > > > >>>Isafjordsgatan 22                  mobile: +46 739 81 21 64 
> > > > >>>Kista, Sweden                      email:  
> > > [email-masked] 
> > > > >>>                                            [email-masked] 
> > > > >>> 
> > > > >> 
> > > > >> 
> > > > >> 
> > > > > 
> > > > 
> > > > 
> > > > -- 
> > > > Loa Andersson 
> > > > 
> > > > Principal Networking Architect 
> > > > Acreo AB                           phone:  +46 8 632 77 14 
> > > > Isafjordsgatan 22                  mobile: +46 739 81 21 64 
> > > > Kista, Sweden                      email:  
> [email-masked] 
> > > >                                             [email-masked] 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> 
> 

Delivery-date: Thu, 28 Jul 2005 08:02:32 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Date: Thu, 28 Jul 2005 10:00:25 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, <[email-masked]>

Hi Arthi, JP

Thanks for this new revision that sounds really good

I have two commments:

-In section 4.1.2 you partially describe bidirectional LSP stitching =
procedure.
You mention that an Upstream Label MUST NOT be allocated by the =
end-to-end LSP on the LSP segment, which is OK.
But then how the LSP-Segment Egress will now that the end-to-end LSP is =
bidirectional? What about defining a flag in the Attributes Flags TLV of =
the LSP_ATTRIBUTE object so as to indicate that the LSP is =
bidirectional?
Also the selection of the LSP segment in case of bidirectional LSP =
should be detailed (e.g. If the end-to-end LSP is bidirecitonal then=20
the LSP-segment MUST be bidirectional. Also shall we allow that two =
unidrectional end-to-end LSP use the same bidirectional LSP segment (one =
in each direction)?

-At the end of section 4.2.5 you mention that LSP-Segment failure or =
maintenance SHOULD be treated as a failure event for the end-to-end LSP. =
I agree for LSP-Segment failure but not for LSP-Segment maintenance. =
LSP-Segment maintenance should be treated as TE-link maintenance for the =
end-to-end LSP, and procedures defined in GMPLS graceful TE-link =
shutdown draft may be useful (Specific RSVP error code and TE-link =
attribute)...

Hope this helps,

Best Regards

JL

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de=20
> [email-masked]
> Envoy=E9 : vendredi 15 juillet 2005 21:50
> =C0 : [email-masked]
> Cc : [email-masked]
> Objet : I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Common Control and=20
> Measurement Plane Working Group of the IETF.
>=20
> 	Title		: Label Switched Path Stitching with=20
> Generalized MPLS Traffic Engineering
> 	Author(s)	: A. Ayyangar, J. Vasseur
> 	Filename	: draft-ietf-ccamp-lsp-stitching-01.txt
> 	Pages		: 19
> 	Date		: 2005-7-15
> =09
> In certain scenarios, there may be a need to combine together two
>    different Generalized Multi-Protocol Label Switching (GMPLS) Label
>    Switched Paths (LSPs) such that in the data plane, a single end-to-
>    end (e2e) LSP is achieved and all traffic from one LSP is switched
>    onto the other LSP.  We will refer to this as "LSP=20
> stitching".  This
>    document covers cases where: a) the node performing the stitching
>    does not require configuration of every LSP pair to be stitched
>    together b) the node performing the stitching is not the egress of
>    any of the LSPs c) LSP stitching not only results in an end-to-end
>    LSP in the data plane, but there is also a corresponding end-to-end
>    LSP (RSVP session) in the control plane.  It might be possible to
>    configure a GMPLS node to switch the traffic from an LSP=20
> for which it
>    is the egress, to another LSP for which it is the ingress, without
>    requiring any signaling or routing extensions whatsoever,=20
> completely
>    transparent to other nodes.  This will also result in LSP stitching
>    in the data plane.  However, this document does not cover this
>    scenario of LSP stitching.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitc
hing-01.txt
>=20
> To remove yourself from the I-D Announcement list, send a=20
> message to [email-masked] with the word=20
> unsubscribe in the body of the message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login=20
> with the username "anonymous" and a password of your e-mail=20
> address. After logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-ccamp-lsp-stitching-01.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
> =09
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 	=09
> 	=09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20

Delivery-date: Wed, 27 Jul 2005 22:39:41 +0000
To: [email-masked]
Subject: RFC 4139 on Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Wed, 27 Jul 2005 15:37:22 -0700

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 4139

        Title:      Requirements for Generalized MPLS (GMPLS)
                    Signaling Usage and Extensions for Automatically
                    Switched Optical Network (ASON)
        Author(s):  D. Papadimitriou, J. Drake, J. Ash, A. Farrel,
                    L. Ong
        Status:     Informational
        Date:       July 2005
        Mailbox:    [email-masked],
                    [email-masked], [email-masked],
                    [email-masked], [email-masked]
        Pages:      16
        Characters: 36660
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ccamp-gmpls-ason-reqts-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4139.txt

The Generalized Multi-Protocol Label Switching (GMPLS) suite of
protocols has been defined to control different switching
technologies and different applications.  These include support
for requesting Time Division Multiplexing (TDM) connections, including
Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy
(SDH) and Optical Transport Networks (OTNs).

This document concentrates on the signaling aspects of the GMPLS
suite of protocols.  It identifies the features to be covered by the
GMPLS signaling protocol to support the capabilities of an
Automatically Switched Optical Network (ASON).  This document provides
a problem statement and additional requirements for the GMPLS
signaling protocol to support the ASON functionality.

This document is a product of the Common Control and Measurement Plane
Working Group of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc4139

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc4139.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

Delivery-date: Wed, 27 Jul 2005 20:56:43 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Incoming correspondence from the OIF
Date: Wed, 27 Jul 2005 21:57:45 +0100

Hi,

We have received the following email and attachment from the OIF.

I will put these on the web at http://www.olddog.co.uk/incoming.htm

Cheers,
Adrian

========

Dear Mr. Farrel and Mr. Kampella,

On behalf of Jim Jones, OIF Technical Committee Chair, attached please
find
a liaison letter regarding findings from the OIF Interoperability
Demonstration at SUPERCOMM.

Warm Regards,
Stephanie

Stephanie Lazicki / Association Coordinator Optical Internetworking Forum
39355 California Street / Suite 307 / Fremont, CA 94538 USA
Phone: +1.510.608.5928 main / +1.510.608.5916 direct
Fax: +1.510.608.5917
Email: [email-masked]
http://www.oiforum.com

Managed by Association Management Solutions (AMS); Forum management,
Meeting and Event Planning http://www.amsl.com

========
Text of attachment...

To: Mr. Adrian Farrel, WG Co-Chair for IETF CCAMP
Mr. Kireeti Kompella, WG Co-Chair for IETF CCAMP
Copy to Alex Zinin and Bill Fenner, IETF Routing Area Directors
From: Jim Jones, OIF Technical Committee Chair
July 25, 2005
Dear Adrian and Kireeti,

The OIF recently concluded a worldwide interoperability demonstration at
Supercomm in June 2005 that successfully focused on dynamic setup of
Ethernet Private Line service over an ASON enabled SONET/SDH network. A
number of issues were encountered during testing that were felt to be of
possible interest to the IETF CCAMP WG, and OIF invites the review and
comment of IETF CCAMP on these issues. They include the following:

1. Use of the NCC and RCC fields for STS-3c/VC-4 connections

During OIF testing it was noted that some ambiguity exists in the
specification of encoding of NCC, RCC and NVC for certain types of
connections: NCC and RCC for an STS-3c/VC-4 connection can be set to 0 or
to 1 depending on which example of RFC 3946 is followed.

Clarification is requested from IETF CCAMP as to which setting is
considered correct, or if both settings should be accepted (this procedure
was used during testing at Supercomm).

2. Setting of NVC for VCAT connections

It was also noted that the setting of NVC may be somewhat ambiguous for
the case where diverse connections are used within a single VCAT group.
Each individual RSVP session controls a single connection, but the
connection is part of a larger VCAT group and carries VCAT encoding of the
H4 byte. Clarification is requested from IETF CCAMP and ITU-T Q.14/15 as
to the correct setting of NVC for this case (0 or 1?). It should be noted
that this case may occur with a VCAT group with only a single initial
member, and that the NVC may provide an indication that VCAT encoding of
the H4 byte is in use for the connection.

3. Length of the Interface Switching Capability TLV

Although the Interface Switching Capability TLV defined by CCAMP for
SONET/SDH connections was not used for the testing, it was noted that the
text describing the length of the Interface Switching Capability TLV
defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly
ambiguous due to the use of padding bytes.

RFC 3630 states that "The TLV is padded to four-octet alignment; padding
is not included in the length field (so a three octet value would have a
length of three, but the total size of the TLV would be eight octets)."

Reading of the encoding in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
specifies that the length of the TLV for TDM is 41 bytes plus 3 bytes of
padding, and should be given in the length field as 41 bytes rather than
44. OIF requests verification of this interpretation from the experts in
IETF CCAMP group.

4. Use of ADMIN_STATUS in an initial PATH message

Some implementations sent an ADMIN_STATUS object with no flags set in the
initial PATH message, i.e., when no status change was being requested.
Although this did not serve any particular function, it was believed that
this could be accepted as RFC3473, sect. 7.2 (page 18) states:

"The absence of the object is equivalent to receiving an object containing
values all set to zero (0)."

It was our interpretation based on this text that a node should accept an
ADMIN_STATUS object with no flags set in the same way as if the object was
missing. Comment on this interpretation is welcome.

5. Handling of multiple received ResvConf Request objects

When a connection desires a confirmation that the service (i.e.
connection) requested is in place, a RESV_CONF_REQ object is included in
the RESV message. As this object is received by the remote end of the
reservation, it will send a RESV_CONF message back to the requester.

However, it is unclear whether it is necessary to send a RESV_CONF message
when the RSVP connection state is refreshed by subsequent RESV. This
becomes potentially burdensome, especially when the reservation is being
rapidly refreshed. Therefore we ask: should the remote end send a
RESV_CONF message for subsequent RESV messages that still include the
RESV_CONF_REQ object? Or is it required that the requestor of the
reservation remove the RESV_CONF_REQ object to prevent the generation of
further RESV_CONF messages? Comment on this issue from IETF CCAMP is
requested.

6. Symmetry of Refresh Reduction usage

During interop testing, we ran into a conflict caused by varying
interpretations of RFC2961, regarding the use of SRefresh messages and the
Refresh Reduction capabilities of the two ends of a given link. One
interpretation of RFC2961 indicates that setting the Refresh Reduction
Capability flag in the RSVP header indicates that that interface shall be
capable of receiving messages related to Refresh Reduction - including the
SRefresh message. This would be true even if the other end of the link for
that interface were NOT indicating Refresh Reduction Capability, since the
RFC makes no statement about symmetry in this matter.

Another interpretation is that both ends of an interface must indicate
Refresh Reduction Capability before either end can use such messages, i.e,
use of Refresh Reduction on a link is symmetric.

Comment from CCAMP WG on the correct interpretation is requested.

7. Sending of ACKs bundled with the RSVP HELLO

During interop testing, it was observed that Message Acks were piggybacked
onto RSVP Hello messages, when the receiving end was not using the Hello
protocol. In this situation, the incoming Hello's were discarded and the
Acks were lost.

We believe that Message Acks should only be piggybacked onto mandatory
messages, and not on Hello messages because of this problem. Comment on
this interpretation is requested.

8. TSPEC format to be used for Ethernet connections

For the interoperability demonstration, the INTSERV SENDER_TSPEC format
was used. However, it appears to us that the INTSERV SENDER_TSPEC defined
in RFC 2210 is not sufficient to support the Ethernet Private Line
described in MEF and ITU-T documents as the MEF and ITU-T specifications
provide a bandwidth profile description for Ethernet Private Line
connections that includes six parameters described below, and the INTSERV
format does not have fields that correspond with all six parameters.
MEF6 [2] specifies that the Ethernet Bandwidth Profile is specified in
terms of the following parameters: CIR, CBS, EIR, EBS, CM, CF. MEF10 [3]
and G.8011 Am1 [1] define the parameters, summarized below:

CIR (Committed Information Rate): Maximum rate required under normal
conditions, service level guaranteed.
CBS (Committed Burst Size): Limits the number of bytes for a burst while
conforming to CIR.
EIR (Excess Information Rate): Maximum rate required under burst
conditions, no guarantee of performance.
EBS (Excess Burst Size): Limits the number of bytes for a burst while
conforming to EIR.
CF (Coupling Flag) and CM (Colour Mode): Give a choice for different modes
of operation.

RFC2210 defines the following SENDER_TSPEC format for Ethernet Traffic
Parameters as follows:
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |0| reserved | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(a) - Message format version number (0)
(b) - Overall length (7 words not including header)
(c) - Service header, service number 1 (default/global information)
(d) - Length of service 1 data, 6 words not including header
(e) - Parameter ID, parameter 127 (Token_Bucket_TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including header

Advice of the IETF CCAMP WG or other experts within IETF is solicited
regarding what TSPEC format if any is
suitable to be used for setup of Ethernet connections.

OIF greatly appreciates the input of the IETF CCAMP WG and other IETF
experts in order to reach conclusion
on these issues.
Best regards,

Jim Jones, OIF Technical Committee Chair

cc: Trey Malpass, Lyndon Ong

References:

[1] ITU-T Recommendation G.8011/Y.1307 (2004), Am. 1 (2005), "Ethernet
Services Framework"

[2] Metro Ethernet Forum, MEF 6 - Ethernet Services Definition, Phase 1,
Jun3 2004

[3] Metro Ethernet Forum, MEF.10 - Ethernet Services Attributes Phase 1,
Nov. 2004

Delivery-date: Wed, 27 Jul 2005 20:37:45 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Lam, Hing-Kam \(Kam\)" <[email-masked]>, "Malcolm Betts" <[email-masked]>, "Stephen Trowbridge" <[email-masked]>, <[email-masked]>, "Scott Bradner" <[email-masked]>
Subject: CCAMP Response to your liaison on GMPLS/ASON Lexicography
Date: Wed, 27 Jul 2005 21:39:05 +0100

To: ITU-T SG15 Questions 12 and 14
From: IETF CCAMP Working Group
Subject: Response to your liaison on GMPLS/ASON Lexicography
For: Action
Deadline: September 30th 2005

The CCAMP Working Group would like to thank SG15 and especially Questions
12 and 14 for the time and effort they put into providing input and
feedback on the GMPLS/ASON lexicography Internet-Draft that is being
developed by CCAMP. Much of the material supplied as direct comments or as
mark-ups to the Internet-Draft has been incorporated into the latest
revision which is available at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-03.txt
and is available for open discussion on the CCAMP mailing list.

In your liaison you state some assumptions which we would like to comment
on as follows.

- The purpose of the document is to enable those familiar with ASON
  to understand GMPLS terminology in an ASON context

Correct.

- GMPLS terms are described informally in the document in a way that
  is generally consistent with GMPLS (existing RFCs and work in progress)

While the definition of GMPLS terms would be helpful for understanding
GMPLS terms in a GMPLS context, that is not the purpose of this document.

- Based on these descriptions, interpretations of these GMPLS terms
  in ASON terminology are provided

It is intended that the interpretation of the GMPLS terms is not based on
these descriptions, but based on the full meaning of the GMPLS terms. The
descriptions of the GMPLS terms are provided in this Internet-Draft for
context and a brief summary.

- CCAMP has primarily responsibility for the descriptions of GMPLS terms

CCAMP is primarily responsible for the specification of GMPLS protocols
and applicability, not just its terms. CCAMP is responsible for all of the
content of this Internet-Draft, but will depend heavily on SG15 for
assistance in providing suitable text for ASON interpretations as set out
below.

- Q12/15 has responsibility to provide input to the GMPLS-ASON
  interpretations (based on the descriptions in this draft)

We welcome this assumption of responsibility by Q12/15 to provide input to
the Internet-Draft. While the Internet-Draft remains under the overall
editorial control of the CCAMP working group, we hope to be able to use
the text supplied by Q12/15 with only editorial changes.

Additionally, we welcome the pledge to continue work on this
Internet-Draft through correspondence on the Q12/15 mailing list, and
thank Q12/15 for assigning Ben Mack-Crane as the SG15 representative on
this matter. Ben has proved very helpful in clarifying and developing
comments received from SG15.

We have had several email exchanges with Ben about a few of the specific
comments made in your review of the 02 revision of the Internet-Draft.
Although he has taken these comments to the Q12/15 mailing list no
response has been received, perhaps due to pressure of time. We are taking
the opportunity to restate several questions here for your convenience and
would appreciate your answers as part of the response to this liaison.

1. Definition of a Resource (section 3.2)
   You have supplied us with the simple text that says...
     "In ASON applications:
      A resource refers only to a link connection (e.g. VC-11,
      VC-4 etc.)."

   We would like to clarify this because we don't understand how
   the original text is wrong. It used to say...
     "ITU-T [should be ASON] terms for resource:
      - Connection point (cp) in the context of link discovery
        and resource management (allocation, binding into
        cross-connects, etc.);
      - Link connection or trail termination in the context of
        routing, path computation and signaling."

   Recall that we are talking about the ASON terms for what GMPLS
   calls a resource. We think the following...
   In ASON a link connection is an association of output cp on one
   side of the link and input cp on the other side of the link. In
   GMPLS by resource we mean in most of the cases the local end of
   the resource (which is cp in ASON terminology). This is true in
   the context of link discovery.

   More importantly, this is also true in the context of a
   signaling application. Specifically, when a GMPLS signaling
   sub-system requests allocation of a resource, the GMPLS
   Resource Manager allocates only the local end of the
   resource. This happens on both sides of the link, that is, we
   allocate input and output resources. This contrasts with ASON,
   where there is a much more versatile LRM, and the connection
   manager (signaling application) allocates link connections
   only on the output side, leaving LRM to coordinate the
   allocation with the neighbor.

   However, in GMPLS TE advertisements we account only for
   outgoing resources, that is, we don't advertise incoming
   resources on the assumption that they match the outgoing
   resources for the discovered TE links.

   Bottom line: we believe that we should retain the previous
   definitions, and have not made this change in the new
   revision. We would like to discuss this point further with
   Q12/15.

2. Link ends and Data links (Section 3.5 - was section 3.4)

2a.Although we understand that ASON does not require the concept
   of a link end, GMPLS does. Therefore we should provide some
   form of language to help people do the mapping.

   The proposed new text from Q12/15 removes all reference to
   link ends from the ASON section, and we feel this is a
   mistake and propose the following text:
     "In ASON, a GMPLS unidirectional data link end is a
      collection of connection points from the same client
      layer that are supported by a single trail termination
      (access point)."

   This text depends on the fact that a link end is described as
   a set of resources that transfer traffic to a neighbor.

2b.The new text from Q12/15 gives us...
     "A GMPLS data link is an ASON link supported by a single
      server trail."

   We are not sure that we understand this correctly. It
   appears to say that a unidirectional data link could be
   supported by multiple trail terminations (access points).
   This seems to suggest that a client would have to make a
   choice about where to send data, which seems to imply it
   really has to choose between data links! We are confused!

   We think some of this problem may come from the *need* in
   GMPLS to identify data link ends. There may be some value in
   stressing that a GMPLS link end is supported by exactly one
   trail termination. When several trail terminations are
   involved, we can still talk about single TE link (as a
   bundle), but each component link will be a distinct data
   link. We think that in ASON the SNPP (TE link in GMPLS
   language) could be supported by multiple terminations.

3. Link interfaces (section 3.6 - was 3.5)
   The new text from Q12/15 gives us...
     "A GMPLS interface is "all the stuff between a physical
      interface and a matrix in an ASON network element." More
      precisely, it is a trail termination function and adaptation
      function for which adapted client layer connection points
      are bound to a matrix."

   We think "physical interface" may be ambiguous in the multi-
   layer context. We think the "stuff" should be between a link
   and a matrix, since we are talking about links in distinct
   layers.

In addition to your feedback on the specific points above, we would
welcome your continued comments and review of the Internet-Draft.

Regards,
Adrian Farrel and Kireeti Kompella
IETF CCAMP Working Group Co-chairs

Delivery-date: Wed, 27 Jul 2005 20:02:48 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>
Cc: "ccamp" <[email-masked]>
Subject: Re: VCn-xV LSPs terminology
Date: Wed, 27 Jul 2005 20:51:14 +0100

Hi,

Yes, please check everything you can find in the lexicography draft, and
comment accordingly.

Thanks,
Adrian
----- Original Message ----- 
From: "Ong, Lyndon" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>; "Wataru Imajuku
<imajuku.wataru" <[email-masked]>
Cc: "Dieter Beller <D.Beller" <[email-masked]>; "ccamp"
<[email-masked]>
Sent: Wednesday, July 27, 2005 4:41 PM
Subject: RE: VCn-xV LSPs terminology

Hi Folks,

It would be worthwhile to check this against the lexicography draft.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Diego Caviglia
Sent: Wednesday, July 27, 2005 1:25 AM
To: Wataru Imajuku <imajuku.wataru
Cc: Dieter Beller <D.Beller; ccamp
Subject: Re: VCn-xV LSPs terminology

Hi Wataru, Dieter,
                    yes I agree with both of you.

Regards

Diego

Wataru Imajuku <[email-masked]> on 27/07/2005 10.00.02

To:    Dieter Beller <[email-masked]>, Diego Caviglia
       <[email-masked]>
cc:    [email-masked]

Subject:    Re: VCn-xV LSPs terminology

Hi, Diego

   I understand your question is whether we shoud call LSP on the basis
of signaling session or not.

  If so, IMHO is Yes.
  The VC4-7v with single RSVP session is single LSP.
  On the other hand, VC4-3v + VC4-4v with two RSVP session is two LSPs.
  However, both of them are single LSP in the client layer as Dieter
said, .

  That is my understanding.
  But is that right, all ?

Best Regards
Wataru

>Hi Diego,
>
>Diego Caviglia wrote:
>
>>Hi all,
>>        I'd like to have a terminology clarification about virtual
>>concatenated LSP.
>>
>>When, say a VC4-7v, VCAT circuit is set-up with a single signalling
session
>>RFC3946 (Path, Resv and may be Resv Confirm) is correct to say that
>>the VCAT group is made by a single LSP or that is made by 7 LSPs?
>>
>>IMHO in that case there is a single LSP.
>>
>
>in my understanding, you are describing a multi-layer scenario here
>because the VCAT client layer sits on top of the VC4 server layer (see
>ITU-T Rec. G.806).
>
>If you are in the VCAT client layer, there is IMHO a single LSP that is

>decomposed into 7 HO VC4 LSPs in the VC4 server layer in your example.
>
>Now, if multiple (not necessarily all) VC4 LSPs are routed along the
>same path you could set up a server layer call containing multiple
>VC4 connections using a single RSVP signaling session (as it was done
>in the OIF interop demo this year).
>
>I hope this clarifies the issue.
>
>
>Cheers,
>Dieter
>
>--
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>        V
>+---------------+      Dieter Beller
>| A L C A T E L |      Alcatel Optics Group
>+---------------+      Optical Networks Division
>                       Dept. US/BA3
>
>                       Alcatel SEL AG
>                       Lorenzstrasse 10
>                       D-70435 Stuttgart, Germany
>
>                       Phone:   +49 711 821-43125
>                       Fax:     +49 711 821-47045
>
>                       E-mail:  [email-masked]
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>

Delivery-date: Wed, 27 Jul 2005 17:52:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Date: Wed, 27 Jul 2005 10:51:38 -0700
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>, "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen" <[email-masked]>, <[email-masked]>, <[email-masked]>

Loa,

=20

> yes - we can make a solution based on designated vlans=20
> "work", but if we do that we will have serious scaling issues

I think you might have misinterpreted what I was saying. I was talking
about using MPLS encap first and then have MPLS traffic over its
designated VLAN(s). All the GMPLS traffic can be carried over a single
VLAN or you can have more than one for load balancing purposes. And thus
there shouldn't be any scalability issues.
=20
>=20
> i don't know if we are ready to start the discussion on=20
> solution, but we seems to do that anyway ;)
>=20
Apparently :-)

> there is a way for us to get a tpid from IEEE, we could=20
> specify the behavior of switches on that tpid
>=20
> my take that we shouldn't do that without involving ieee, but=20
> on the other it is normally quite easy to work with them
>=20

If interested one can come and discuss it during next 802.1 group (which
is the architecture group for IEEE bridges) meeting.

> but again we need to undestand requirements first
>=20

Completely agree.=20

-Ali

> /Loa
>=20
> Ali Sajassi (sajassi) wrote:
> > Dimitri,
> > =20
> > By "existing Ethernet switches", I mean Ethernet switches based on=20
> > current approved IEEE 802 .1Q/.1D standards and not the=20
> hypothetical=20
> > switches with TBD forwarding characteristics. Anyway, if=20
> the objective=20
> > is to use RSVP-TE with "existing Ethernet switches", you=20
> can do that=20
> > easily by designating a VLAN or (set of VLANs) for RSVP-TE=20
> traffic and=20
> > support both EoMPLS and native bridged traffic on a single trunk.=20
> > There is some overhead with such encapsulation but the=20
> benefit of it=20
> > is that it works now. If we want to do it through some other means=20
> > (such as MAC address translation), then the benefit of such=20
> approach=20
> > is not clear to me; however, the disadvantages are very clear
> > :-) Anyway, I'll look forward to more discussions during=20
> and after the=20
> > meeting next week.
> > =20
> > Cheers,
> > Ali
> >=20
> >    =20
> --------------------------------------------------------------
> ----------
> >     *From:* [email-masked]
> >     [mailto:[email-masked]]
> >     *Sent:* Tuesday, July 26, 2005 4:21 PM
> >     *To:* Ali Sajassi (sajassi)
> >     *Cc:* CHO, JAI HYUNG; Heiles Juergen; [email-masked];=20
> [email-masked]
> >     *Subject:* RE: Frameformat in a l2cs gmpls rnvironment=20
> - Issues w/
> >     GMPLS Ethernet
> >=20
> >     ali
> >=20
> >     to be clear here you are hanging on using the term "existing
> >     Ethernet switches" while the document that has been at=20
> the source of
> >     the discussion does not state "GMPLS must be deployable=20
> on existing
> >     Ethernet switches" this may be the case but there are=20
> limitations
> >     (and there are perfectly well understood, don't worry)=20
> beside this
> >     you should also tell us what do you exactly mean with the term
> >     "existing" - but this is a side issue -
> >=20
> >     this said, this does NOT mean that a GMPLS Ethernet=20
> switch (either
> >     existing or even "extended") would need to support a=20
> new Ethernet
> >     802.3 frame forwarding paradigm, the difference is=20
> subtle but has to
> >     be underlined
> >=20
> >     note: there is a slot of 20 minutes during the next=20
> CCAMP WG meeting
> >     where this document and all related issues will be=20
> heavily discussed
> >     ... so i welcome you to join the festivities ;-)
> >=20
> >     thanks,
> >=20
> >     - dimitri.
> >=20
> >     =20
> >=20
> >     *"Ali Sajassi \(sajassi\)" <[email-masked]>*
> >     Sent by: [email-masked]
> >     07/25/2005 16:13 MST
> >=20
> >     To: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen"
> >     <[email-masked]>, <[email-masked]>
> >     cc: <[email-masked]>
> >     bcc:
> >     Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/
> >     GMPLS Ethernet
> >=20
> >=20
> >     Jaihyung,
> >=20
> >     It seems to me that your primary objective is to use=20
> the existing
> >     Ethernet switches with new control plane (GMPLS) to=20
> setup TE paths for
> >     different applications. And you mentioned three=20
> approaches for doing
> >     this in your email. However, all three of them have=20
> issues and are not
> >     viable. Lets go over them ...
> >=20
> >      >
> >      > In below mail, I discussed about three proposed approaches.
> >      >
> >      >
> >      > 1. using VLAN tag as it is for L2 label encoding.
> >=20
> >     As you know this approach has scalability issue and you=20
> are limited to
> >     4K services in the network and if you try to use the=20
> upcoming IEEE
> >     802.1ad standard to make VLANs, interface specific,=20
> then you will need
> >     new switches and not existing Ethernet switches. Even=20
> if you use these
> >     newer switches, you will still be limited to 4K=20
> services per interface
> >     and it would defeat the objective of using existing switches.
> >=20
> >      >
> >      > 2. defining new protocol ID (TPID) and borrow VLAN=20
> tag format,
> >      > ?or extended VLAN tag to implement label swapping.
> >      >
> >=20
> >     This approach requires new data plane functionality to=20
> be implemented
> >     (which defeats the objective of using existing switches).
> >=20
> >      > 3. use lower 3 bytes of MAC address for L2 label encoding.
> >      >
> >=20
> >     This approach has several issues:
> >     1) how does MAC addresses get distributed among the=20
> bridges ? How does
> >     this distribution works during a link or node failure ?=20
> How does it
> >     recover from a link or node failure ?
> >=20
> >     2) Will you assign a separate provider MAC for each=20
> customer MAC. If so,
> >     then how do you address MAC scalability. If not, then=20
> how do you take
> >     care of 1-to-N mapping between provider MAC address and=20
> customer MAC
> >     addresses and how do you handle multipoint connections.
> >=20
> >     3) how do handle customer FCS retention when doing this=20
> MAC translation
> >     stuff ??
> >=20
> >      >
> >      > 802.1Q bridge forwards Ethernet frames using two=20
> dataplane tables
> >      > - MAC forwarding table and VLAN forwarding table.
> >      > Bridge control protocols, such as GARP, GVRP, GMRP,
> >      > manipulate one of the two dataplane entities.
> >=20
> >     This is not correct. Bridges don't have different=20
> databases for MAC
> >     forwarding and VLAN forwarding. They have filtering=20
> datebase(s) with
> >     corresponding IDs (FIDs). VLAN IDs get mapped to FIDs=20
> based on operation
> >     mode (IVL versus SVL). Then once a filtering database=20
> is identified,
> >     then a MAC address lookup is performed for forwarding.=20
> Bridge control
> >     protocols use a designated MAC addressed and based on these MAC
> >     addressed, the bridge knows how to process the frame.
> >=20
> >      >
> >      > Similarly, option 1 and 3 are about which one of two
> >      > dataplane entities
> >      > GMPLS protocol should control on behalf of bridge=20
> control protocols.
> >      > The two proposals do not intend to modify bridge behavior
> >      > seriously, such as MAC learning, aging, filtering.
> >      > Therefore, the approaches 1 and 3 are in the scope of CCAMP.
> >=20
> >     If that's the intention, you may find out soon you get=20
> more than what
> >     you asked for :-)
> >=20
> >      >
> >      > (% note however, I would regard implementing label swapping
> >      > function is acceptable change considering the=20
> Internal Sublayer
> >      > design of 802.1D bridge.)
> >      >
> >=20
> >     The only way of doing this is using VID translation=20
> table specified in
> >     IEEE 802.1ad which requires new data-plane=20
> functionality and thus
> >     existing bridges cannot be used !!
> >=20
> >     Also if going the route of tag swapping, you may=20
> consider using IEEE
> >     802.1ah. As the editor of .1ah, I can go over the=20
> details when I get a
> >     chance.
> >=20
> >      >
> >      > However, option 2 is about what TPID code we will
> >      > choose to implement new switching function.
> >      > The switch of this implementation should have new hardware
> >      > design in addition to normal bride hardware.
> >      > I think such proposal as option 2 is out of CCAMP scope.
> >=20
> >     Yes.
> >=20
> >      >
> >      > Overall objective is improving scalability, traffic=20
> engineering (TE)
> >      > characteristics of 802.1 bridge that it can be=20
> reliable, manageable
> >      > enough to replace some core routers.
> >=20
> >     Easier said than done :-)
> >=20
> >      > The switching technique you mentioned above, such as
> >      > Ethernet over MPLS as defined by PWE3 and L2VPN,
> >      > are all actually router based technology, however this
> >      > work is based on simple bridge architecture.
> >      > Cost-effectiveness is the key differentiator.
> >      >
> >=20
> >     The devils are in the details and once you worked out=20
> the details, you
> >     will see the issues.
> >=20
> >      >
> >      > In access or enterprise network, capability of=20
> providing end-to-end
> >      > L2-LSP will enable service providers policing,=20
> measuring, charging
> >      > application flows using Ethernet based network. This=20
> will eventually
> >      > improve income structure and introduce new session=20
> based commercial
> >      > service. I have been discussing this aspect in mail thread of
> >      > title 'End-to-end L2-LSP'.  Please read the mail=20
> thread and comment
> >      > on the discussion.
> >      >
> >      >
> >      > >You mentioned to use the MAC address or part of it=20
> as a label.
> >      > >The TRILL working group is defining shortest path routing
> >      > for Ethernet.
> >      > >How would this fit together?
> >      >
> >      >
> >      > TRILL employs new encapsulation layer outside of=20
> Ethernet frames.
> >      > However in my proposal of option-3, I simply use the=20
> Ethernet header
> >      > to encode GMPLS label.
> >      >
> >      > The overall format of rbridge is
> >      > [Ethernet][r-tag][Ethernet][ data..]
> >      > It is not LSP based technology but a connectionless=20
> routing bridge.
> >      > TTL count is very important in rbridge because=20
> frames are routed
> >      > hop-by-hop and it may loop.
> >      >
> >      > Whereas in option-3 above, Ethernet frames that have certain
> >      > OUI prefix in MAC address are forwarded via a path that
> >      > GMPLS protocol has configured on MAC forwarding table.
> >      >
> >=20
> >     How does the redundancy work in here. Are you using=20
> bridge protocol in
> >     conjunction with GMPLS protocol. If you do, then there=20
> are bunch of
> >     issues. If you don't, then what is it used and how does=20
> it interact with
> >     bridging protocols ??
> >=20
> >     -Ali
> >=20
> >=20
> >      >
> >      > Thanks
> >      >
> >      > Jaihyung
> >      >
> >      >
> >      >
> >      > -----?? ???-----
> >      > ?? ??: "Heiles Juergen" <[email-masked]>
> >      > ?? ??: 2005-07-25 ?? 6:44:34
> >      > ?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles
> >      > Juergen" <[email-masked]>, "[email-masked]"
> >      > <[email-masked]>
> >      > ??: "[email-masked]" <[email-masked]>
> >      > ??: RE: Frameformat in a l2cs gmpls rnvironment.
> >      >
> >      >
> >      >
> >      >
> >      >
> >      >
> >      > Dear Jaihyung,
> >      >
> >      > you mention several options that could be used as a label.
> >      > Most of them have strong impacts on the data plane and
> >      > introduce new layer networks. Is this in the scope of CCAMP?
> >      > What is the goal, to introduce a control plane for a existing
> >      > L2 technology or introduce a new L2 technology? What would be
> >      > the benefit of such a new L2 co switching technology compared
> >      > to Ethernet over MPLS as defined by PWE3 and L2VPN?
> >      > You mentioned to use the MAC address or part of it as a
> >      > label. The TRILL working group is defining shortest path
> >      > routing for Ethernet. How would this fit together?
> >      >
> >      >
> >      > Regards
> >      >
> >      > Juergen
> >      >
> >      >
> >      >
> >      >
> >      >
> >      > > From: CHO, JAI HYUNG [mailto:[email-masked]]
> >      > > Sent: Saturday, July 23, 2005 6:19 AM
> >      > > To: Heiles Juergen; [email-masked]
> >      > > Cc: [email-masked]
> >      > > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> >      > >
> >      > >
> >      > > Dear Juergen, Par and all,
> >      > >
> >      > > The proposed framework of L2SC was not intended to suggest
> >      > > any specific solution. It is still an open question.
> >      > > As Adrian noted, it only aims to present requirements
> >      > > as in scenarios that may drive people toward next=20
> step in many
> >      > > viable solutions.
> >      > >
> >      > > In fact, there are other options we may also=20
> consider for L2
> >      > > label encoding.
> >      > > IEEE 802.1 Ethernet bridges forward frames based=20
> on 48bits of
> >      > > MAC address,
> >      > > and additionally using VLAN tag.
> >      > >
> >      > > When the purpose of GMPLS control over Ethernet is not to
> >      > > create new dataplane
> >      > > but to utilize IEEE 802.1 bridge architecture, we may
> >      > consider using
> >      > > one of the two forwarding methods, MAC forwarding or VLAN
> >      > forwarding.
> >      > > (and perhaps any other combination of fields in=20
> MAC, but I'll
> >      > > not discuss it)
> >      > >
> >      > > Use of VLAN ID for label encoding may automate=20
> VLAN configuration
> >      > > using IP protocols. However, GMPLS protocol cannot use the
> >      > > field exclusively
> >      > > because public/private operators already use VLAN=20
> for various
> >      > > purpose.
> >      > > There is a potential conflict with existing use of VLAN and
> >      > > GMPLS use of VLAN label.
> >      > > Furthermore, scalability of VLAN ID has been=20
> frequently noted
> >      > > as weakness
> >      > > because the size of VLAN ID is at most 4096 (12bit).
> >      > >
> >      > > The scalability may be improved if the scope of=20
> VLAN label is
> >      > > confined to
> >      > > link-local, and some additional swapping function=20
> of VLAN ID
> >      > > is introduced in
> >      > > Internal Sublayer [802.1D] of GMPLS implemented switch.
> >      > > However, this will only be effective when the configuration
> >      > > of network
> >      > > is mesh structure that multiple LSP paths exist. If the
> >      > > configuration of network
> >      > > is star or tree shape, as normal configuration of=20
> access network,
> >      > > LSPs concentrate in root node and total number of
> >      > > LSPs that the network can hold still be limited by=20
> available
> >      > > label space
> >      > > at a few root links.
> >      > >
> >      > > For these reasons, I do not think any form of VLAN=20
> ID label is
> >      > > an appropriate choice for layer-2 label encoding.
> >      > >
> >      > > There are some other proposals assuming new=20
> assignment of Ethernet
> >      > > Length/Type value (e.g. new TPID in VLAN tag) and=20
> re-definition of
> >      > > information fields placed between 802.3 MAC header=20
> and IP packet.
> >      > > In this case, only the format of VLAN tag or=20
> extended VLAN tag
> >      > > is borrowed, however, inside the switching hardware, the
> >      > > filter and relay,
> >      > > etc. are totally different new dataplane switch.
> >      > >
> >      > > I do not see such approach is a GMPLS=20
> implementation for Ethernet
> >      > > because the core switching technique is not 802.1 Ethernet
> >      > > bridge at all.
> >      > >
> >      > > The other option we may consider is using MAC address filed
> >      > as below.
> >      > >
> >      > >
> >      > > +-------+-------+-------+-------+-------+-------+
> >      > > | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte |
> >      > > +-------+-------+-------+-------+-------+-------+
> >      > > +-----------------------+-----------------------+
> >      > > |  OUI Prefix (=3DGMPLS)  |   DA-label (24bit)    |
> >      > > +-----------------------+-----------------------+
> >      > > |  OUI Prefix (=3DGMPLS)  |   SA-label (24bit)    |
> >      > > +---------------+-------+-----------------------+
> >      > > | Length/Type   |
> >      > > +---------------+
> >      > >
> >      > >
> >      > > IEEE is designated by the ISO Council to act as the
> >      > > registration authority
> >      > > for the higher three-octet of OUI number in the MAC address
> >      > > to be used by manufacturer. Ethernet manufacturer=20
> may generate
> >      > > global unique MAC address using the OUI prefix and=20
> address block of
> >      > > lower three-octet (24bit). Taking advantage of the
> >      > addressing scheme,
> >      > > GMPLS may use the lower three-octet exclusively if a unique
> >      > > OUI number
> >      > > is reserved for the protocol. With this labeling=20
> scheme, GMPLS will
> >      > > control MAC forwarding entry, not VLAN table.
> >      > >
> >      > > All Ethernet frames controlled by GMPLS will have identical
> >      > > OUI number
> >      > > that they can easily be distinguished from other=20
> Ethernet frames.
> >      > > In principle, the label lookup hardware is=20
> identical to MAC lookup
> >      > > hardware in this labeling scheme. Therefore GMPLS=20
> implemented
> >      > > switch may still function as normal Ethernet=20
> bridge to the frames
> >      > > that OUI number is not GMPLS. This also facilitates GMPLS
> >      > implemented
> >      > > switches being deployed in operating Ethernet with minimum
> >      > > service disruption.
> >      > >
> >      > > Note also that above proposed label encoding=20
> method is transparent
> >      > > to the use of Ethernet Length/Type field. End-user=20
> device may use
> >      > > the Length/Type field as defined in IEEE 802.3 protocol.
> >      > > It also allows network operators configure VLAN=20
> for their own
> >      > > purpose.
> >      > > When IEEE 802.1p is used in conjunction with=20
> L2-LSP, the priority
> >      > > field of VLAN tag can also be used for imposing=20
> consistent TE
> >      > > policy in
> >      > > legacy switches and GMPLS switches.
> >      > >
> >      > > Any way, my conclusion is, there are other options=20
> we may consider,
> >      > > and this issue is still open to discuss.
> >      > >
> >      > > Thanks,
> >      > >
> >      > > Sincerely,
> >      > >
> >      > > Jaihyung
> >      > >
> >      > >
> >      > >
> >      > >
> >      > >
> >      > > -----?? ???-----
> >      > > ?? ??: "Heiles Juergen" <[email-masked]>
> >      > > ?? ??: 2005-07-22 ?? 10:23:43
> >      > > ?? ??: "Loa Andersson" <[email-masked]>,=20
> "[email-masked]"
> >      > > <[email-masked]>
> >      > > ??: "[email-masked]" <[email-masked]>, "[email-masked]"
> >      > > <[email-masked]>
> >      > > ??: RE: Frameformat in a l2cs gmpls rnvironment.
> >      > >
> >      > >
> >      > >
> >      > >
> >      > >
> >      > >
> >      > > Loa,
> >      > >
> >      > > I interpret the ID as a proposal to use GMPLS for=20
> VLAN setup.
> >      > > So GMPLS and VLAN to not compete. The VLAN is at the data
> >      > > plane and GMPLS at the control plane. The question=20
> is how and
> >      > > should different control plane techniques like GMPLS and
> >      > > (GVRP and STB) work together?
> >      > >
> >      > > Regards
> >      > >
> >      > > Juergen
> >      > >
> >      > >
> >      > > > From: [email-masked]
> >      > > > [mailto:[email-masked]] On Behalf Of=20
> Loa Andersson
> >      > > > Sent: Friday, July 22, 2005 2:53 PM
> >      > > > To: [email-masked]
> >      > > > Cc: [email-masked]; [email-masked]
> >      > > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> >      > > >
> >      > > > Richard,
> >      > > >
> >      > > > I agree to most of this. Since we have doubts=20
> about the viability
> >      > > > of taking GMPLS all the way to end-user or=20
> enterprise I think it
> >      > > > would be good, from a wg perspective, if we=20
> agreed to solve the
> >      > > > core network problems first.
> >      > > >
> >      > > > Do you have any comment on the requirement to=20
> run both VLANs and
> >      > > > GMPLS on the same switch?
> >      > > >
> >      > > > /Loa
> >      > > >
> >      > > > [email-masked] wrote:
> >      > > > > Regardless of whether or not a switch is=20
> directly connected
> >      > > >  > to hosts, it must be able to forward packets using the
> >      > > > connectionless
> >      > > >  > Ethernet data plane. This is due to the fundamental
> >      > > > requirement that
> >      > > >  > for GMPLS switches to be able to exchange control
> >      > > information with
> >      > > >  > each other, a data plane for control traffic=20
> must be present.
> >      > > >  > This is akin to using the IP data plane for MPLS
> >      > > signalling in an
> >      > > >  > IP/MPLS network. An alternative would be to=20
> use a static
> >      > > reserved
> >      > > >  > L2-LSP for control traffic in the same way=20
> that reserved
> >      > > VPI/VCIs
> >      > > >  > are used for PNNI signalling in ATM.
> >      > > > >
> >      > > > > Regarding connecting hosts to GMPLS switches, I
> >      > personally don't
> >      > > >  > think extending L2-LSPs into the=20
> enterprise/home network is
> >      > > >  > commercially viable. However, if you do want to use
> >      > > GMPLS switches
> >      > > >  > in the home/enterprise network and for some reason
> >      > don't want to
> >      > > >  > extend L2-LSPs down to the host then you will not be
> >      > performing
> >      > > >  > normal Ethernet Mac address switching anyway.=20
> Instead you will
> >      > > >  > need some kind of policy on the switch that maps
> >      > connectionless
> >      > > >  > Ethernet packets (e.g. based on MAC src/dest, 802.1p,
> >      > VLAN) to a
> >      > > >  > L2-LSP. This is because multiple L2-LSPs to the same
> >      > destination
> >      > > >  > (e.g. a gateway router) may exist for=20
> different services/flows
> >      > > >  > (e.g. video download, VoIP call, etc.).
> >      > > > >
> >      > > > > Regards,
> >      > > > > Richard
> >      > > > >
> >      > > > >
> >      > > > >>From: [email-masked]
> >      > > [mailto:[email-masked]]On
> >      > > > >>Behalf Of Par Mattsson
> >      > > > >>Sent: 22 July 2005 11:42
> >      > > > >>To: Loa Andersson
> >      > > > >>Cc: [email-masked]
> >      > > > >>Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> >      > > > >>
> >      > > > >>
> >      > > > >>
> >      > > > >>>Per and Dimitri,
> >      > > > >>>
> >      > > > >>>I would like to come down stronger than that,=20
> for me it is
> >      > > > >>>a very strong requirement that the same=20
> switch can handle
> >      > > > >>>both VLANs and GMPLs trafic correctly. I=20
> can't dsee how that
> >      > > > >>>could be done if using the VLAN tpid to indicate GMPLS
> >      > > > >>>traffic.
> >      > > > >>
> >      > > > >>If you ever want that same switch to handle=20
> traffic for a
> >      > > directly
> >      > > > >>connected  host (not to uncommen) you would=20
> want that to
> >      > > use normal
> >      > > > >>ethernet macaddress switching. So of course=20
> you do not want
> >      > > > to have to
> >      > > > >>choose between vlan and gmpls, you would want=20
> both at the
> >      > > same time.
> >      > > > >>
> >      > > > >>/per
> >      > > > >>
> >      > > > >>
> >      > > > >>
> >      > > > >>>/Loa
> >      > > > >>>
> >      > > > >>>Par Mattsson wrote:
> >      > > > >>>
> >      > > > >>>>>hi par, one of the possibilities that has=20
> been considered
> >      > > > >>
> >      > > > >>to cope with
> >      > > > >>
> >      > > > >>>>>this requirement is to use a dedicated TPID for the
> >      > > > >>
> >      > > > >>Ethernet labeled
> >      > > > >>
> >      > > > >>>>>frames; this would allow differentiated=20
> processing with
> >      > > > non-labeled
> >      > > > >>>>>framesthanks.
> >      > > > >>>>
> >      > > > >>>>
> >      > > > >>>>That seems to make more sence. If that frame is to be
> >      > > sized like a
> >      > > > >>>>802.1q
> >      > > > >>>>frame. There is not that much space left to=20
> a label. Or is
> >      > > > >>
> >      > > > >>the demand to
> >      > > > >>
> >      > > > >>>>use jumboframes ?
> >      > > > >>>>Has there been any discussion on labelstacking, and
> >      > > > mainly where to
> >      > > > >>>>place
> >      > > > >>>>the information?
> >      > > > >>>>
> >      > > > >>>>Regards.
> >      > > > >>>>Per
> >      > > > >>>>
> >      > > > >>>>
> >      > > > >>>>
> >      > > > >>>
> >      > > > >>>
> >      > > > >>>--
> >      > > > >>>Loa Andersson
> >      > > > >>>
> >      > > > >>>Principal Networking Architect
> >      > > > >>>Acreo AB                           phone: =20
> +46 8 632 77 14
> >      > > > >>>Isafjordsgatan 22                  mobile:=20
> +46 739 81 21 64
> >      > > > >>>Kista, Sweden                      email:
> >      > > [email-masked]
> >      > > > >>>                                            [email-masked]
> >      > > > >>>
> >      > > > >>
> >      > > > >>
> >      > > > >>
> >      > > > >
> >      > > >
> >      > > >
> >      > > > --
> >      > > > Loa Andersson
> >      > > >
> >      > > > Principal Networking Architect
> >      > > > Acreo AB                           phone:  +46 8=20
> 632 77 14
> >      > > > Isafjordsgatan 22                  mobile: +46=20
> 739 81 21 64
> >      > > > Kista, Sweden                      email: =20
> [email-masked]
> >      > > >                                             [email-masked]
> >      > > >
> >      > >
> >      > >
> >      > >
> >      > >
> >      >
> >      >
> >      >
> >=20
>=20
>=20
> --
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                             [email-masked]
>=20

Delivery-date: Wed, 27 Jul 2005 15:42:30 +0000
Content-class: urn:content-classes:message
Subject: RE: VCn-xV LSPs terminology
Date: Wed, 27 Jul 2005 11:41:14 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>, "Wataru Imajuku <imajuku.wataru" <[email-masked]>
Cc: "Dieter Beller <D.Beller" <[email-masked]>, "ccamp" <[email-masked]>

Hi Folks,

It would be worthwhile to check this against the lexicography draft.

Cheers,

Lyndon=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Diego Caviglia
Sent: Wednesday, July 27, 2005 1:25 AM
To: Wataru Imajuku <imajuku.wataru
Cc: Dieter Beller <D.Beller; ccamp
Subject: Re: VCn-xV LSPs terminology

Hi Wataru, Dieter,
                    yes I agree with both of you.

Regards

Diego

Wataru Imajuku <[email-masked]> on 27/07/2005 10.00.02

To:    Dieter Beller <[email-masked]>, Diego Caviglia
       <[email-masked]>
cc:    [email-masked]

Subject:    Re: VCn-xV LSPs terminology

Hi, Diego

   I understand your question is whether we shoud call LSP on the basis
of signaling session or not.

  If so, IMHO is Yes.
  The VC4-7v with single RSVP session is single LSP.
  On the other hand, VC4-3v + VC4-4v with two RSVP session is two LSPs.
  However, both of them are single LSP in the client layer as Dieter
said, .

  That is my understanding.
  But is that right, all ?

Best Regards
Wataru

>Hi Diego,
>
>Diego Caviglia wrote:
>
>>Hi all,
>>        I'd like to have a terminology clarification about virtual=20
>>concatenated LSP.
>>
>>When, say a VC4-7v, VCAT circuit is set-up with a single signalling
session
>>RFC3946 (Path, Resv and may be Resv Confirm) is correct to say that=20
>>the VCAT group is made by a single LSP or that is made by 7 LSPs?
>>
>>IMHO in that case there is a single LSP.
>>
>
>in my understanding, you are describing a multi-layer scenario here=20
>because the VCAT client layer sits on top of the VC4 server layer (see=20
>ITU-T Rec. G.806).
>
>If you are in the VCAT client layer, there is IMHO a single LSP that is

>decomposed into 7 HO VC4 LSPs in the VC4 server layer in your example.
>
>Now, if multiple (not necessarily all) VC4 LSPs are routed along the=20
>same path you could set up a server layer call containing multiple
>VC4 connections using a single RSVP signaling session (as it was done=20
>in the OIF interop demo this year).
>
>I hope this clarifies the issue.
>
>
>Cheers,
>Dieter
>
>--
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>        V
>+---------------+      Dieter Beller
>| A L C A T E L |      Alcatel Optics Group
>+---------------+      Optical Networks Division
>                       Dept. US/BA3
>
>                       Alcatel SEL AG
>                       Lorenzstrasse 10
>                       D-70435 Stuttgart, Germany
>
>                       Phone:   +49 711 821-43125
>                       Fax:     +49 711 821-47045
>
>                       E-mail:  [email-masked]
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>

Delivery-date: Wed, 27 Jul 2005 14:01:46 +0000
Date: Wed, 27 Jul 2005 23:01:13 +0900
To: [email-masked]
From: Wataru Imajuku <[email-masked]>
Subject: Re: LCAS and GMPLS

Hi, all

Best Regards
Wataru

Delivery-date: Wed, 27 Jul 2005 13:18:44 +0000
Date: Wed, 27 Jul 2005 22:17:21 +0900
To: Huub van Helvoort <[email-masked]>, Trevor Wilson <[email-masked]>
From: Wataru Imajuku <[email-masked]>
Subject: Re: VCn-xV LSPs terminology
Cc: ccamp <[email-masked]>

Hi, Huub

  Your comment is very valuable.

  I will try to reflect your comment on -01.txt version.

  Thank you

Best Regards,
Wataru

>Hello,
>
>In addition to what Trevor Wilson wrote:
>
>>Firtsly, lets get the nomenclature correct. A virtually concatenated
>>signal is denoted as VC-n-Xv (please note the use of hyphens and
>>upper/lower case letters).
>
>Note that "n" can have the value 4, 3, 2, 12, 11 and for SONET
>the nomenclature would be VTn-Xv (n=1.5,6)and STS-n-Xv (n=1,3c).
>
>Looking at draft-imajuku-ccamp-gmpls-vcat-lagr-req-00
>I find in the second paragraph of the introduction:
>    "The LCAS achieves hitless bandwidth modification via
>     signaling in the H4 byte of the SDH/SONET link"
>This restricts this document to VC-n-Xv (n=3,4) and STS-n-Xv.
>
>Changing the text to:
>    "The LCAS achieves hitless bandwidth modification via
>     signaling in the VCAT overhead byte of the SDH/SONET link"
>will make it more generic (even applicable to OTN).
>
>H4 bite is also mentioned at the top of page 5.
>
>Cheers, Huub (van Helvoort)
>
>--
>================================================================
>              http://members.chello.nl/hhelvoort/
>================================================================
>Always remember that you are unique...just like everyone else...

Delivery-date: Wed, 27 Jul 2005 11:42:28 +0000
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: AW: LCAS and GMPLS
Date: Wed, 27 Jul 2005 13:41:41 +0200

Hi Trevor,

Michael

-----Urspr=FCngliche Nachricht-----
Von: Trevor Wilson [mailto:[email-masked]]=20
Gesendet: Mittwoch, 27. Juli 2005 13:31
An: Wataru Imajuku; Dueser, Michael; [email-masked]
Betreff: RE: LCAS and GMPLS

Hi,

VCAT (and LCAS) functionality is required ONLY at the terminating TDM =
NEs of a Virtually Concatenated signal. As long as the 'intermediate =
NEs', through which the individual VC-ns are transported, have the =
capacity to carry those VC-ns then the SONET/SDH network will provide =
the necessary connection. For any given VCAT connection, the =
intermediate NEs do not need to be VCAT/LCAS capable. Therefore I do =
not understand why, in the 'problem statement of =
'draft-imajuku-ccamp-gmpls-vcat-lagr-req-00.txt', each TDM node should =
advertise its VCAT/LCAS capabilities. When the connection is being =
provisioned, it is up to the SDH/SONET NMS to determine whether or not =
the network (and it's NEs) are capable of a VCAT/LCAS operation. In the =
TDM network, label switching is not performed, except perhaps at the =
edge of the network where the client signal is encapsulated into the =
transport technology. Therefore I believe that the routes for the =
individual VC-ns of a virtually concatenated group (VCG) are of no =
consequence to the client signal, and the VCG can be looked upon as a =
single LSP between the TDM ingress node and the TDM egress node.

Michael:

Below you state that LCAS is Bi-directional.
For LCAS to operate it needs at least one member in both directions; =
but essentially the LCAS operation is uni-directional in nature. If =
bandwidth adjustment is required in both directions it is necessary to =
initiate these separately.

Regards,

Trevor

Trevor Wilson
Nortel Networks
Belfast Lab
Tel: +44 2890 363701
       ESN 751 3701

-----Original Message-----

Hi, Mr. Dueser and all

  The one of ID's requirements includes the extension for the routing
protocol in order to advertise such termination capability in each =
node.
  I believe this routing extension helps smooth migration amongst
GFP/LCAS/VCAT capable and non capable networks.

capability=20

  However, the explicit addition of termination capability to the ISCD
may=20
be one of choice,
considering the more generic node architeture as discussed in Dimitri's =

MRN-extensions draft.

Best Regards,
Wataru

Hi,

>- LCAS was not intended for grouping of VC-X-yvs, but for=20
>synchronization
>- You need to be careful when using the verbs may, shoul and must - =
are

>liaison and for implementation! I believe we can also discuss details=20

FAX +81-46-859-5541=20

Delivery-date: Wed, 27 Jul 2005 11:31:35 +0000
Content-class: urn:content-classes:message
Subject: RE: LCAS and GMPLS
Date: Wed, 27 Jul 2005 12:30:45 +0100
From: "Trevor Wilson" <[email-masked]>
To: "Wataru Imajuku" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi,

Michael:

Regards,

Trevor

Trevor Wilson
Nortel Networks
Belfast Lab
Tel: +44 2890 363701
       ESN 751 3701
>This is the Way. This is Nortel.=20
>

-----Original Message-----

Hi, Mr. Dueser and all

capability=20

  However, the explicit addition of termination capability to the ISCD
may=20
be one of choice,
considering the more generic node architeture as discussed in Dimitri's=20
MRN-extensions draft.

Best Regards,
Wataru

Hi,

>- LCAS was not intended for grouping of VC-X-yvs, but for=20
>synchronization

>liaison and for implementation! I believe we can also discuss details=20

FAX +81-46-859-5541=20

Delivery-date: Wed, 27 Jul 2005 10:50:56 +0000
Content-class: urn:content-classes:message
Subject: RE: VCn-xV LSPs terminology
Date: Wed, 27 Jul 2005 11:50:04 +0100
From: "Trevor Wilson" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>, "Wataru Imajuku <imajuku.wataru" <[email-masked]>, "Alan Bailey \(Alan Bailey\)" <IMCEAEX-_O=NORTEL_OU=EuropeM01_cn=Recipients_cn=Exchange_cn=[email-masked]>
Cc: "Dieter Beller <D.Beller" <[email-masked]>, "ccamp" <[email-masked]>, "Ludovico Prattico" <[email-masked]>, "Pete Anslow" <[email-masked]>, "Malcolm Betts" <[email-masked]>, "Graham Copley" <[email-masked]>, "Astrid Lozano" <[email-masked]>, "David Martin" <[email-masked]>, "Michael Mayer" <[email-masked]>

Hi,

Firtsly, lets get the nomenclature correct. A virtually concatenated
signal is denoted as VC-n-Xv (please note the use of hyphens and
upper/lower case letters). Also I will use VCG =3D Virtually =
Concatenated
Group in my reply below.

Wataru: You wrote

"The VC4-7v with single RSVP session is single LSP.
 On the other hand, VC4-3v + VC4-4v with two RSVP session is two LSPs "

I assume that when you say 'VC-4-3v + VC-4-4v' you mean that the VCG has
a total of seven members transported over two routes, one with three
members and one with four members. This is and always will be a VC-4-7v.
It is not a summation of two VCGs. You cannot think of each route as a
separate VCG. The VCAT function at the terminations of the connection
will regard all individual VC-4s as members of the VC-4-7v, regardless
of which route they were transported on.

I hope this helps.

Trevor Wilson
Nortel Networks
Belfast Lab
Tel: +44 2890 363701
       ESN 751 3701
>This is the Way. This is Nortel.=20
>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Diego Caviglia
Sent: 27 July 2005 09:25
To: Wataru Imajuku <imajuku.wataru
Cc: Dieter Beller <D.Beller; ccamp
Subject: Re: VCn-xV LSPs terminology

Hi Wataru, Dieter,
                    yes I agree with both of you.

Regards

Diego

Wataru Imajuku <[email-masked]> on 27/07/2005 10.00.02

To:    Dieter Beller <[email-masked]>, Diego Caviglia
       <[email-masked]>
cc:    [email-masked]

Subject:    Re: VCn-xV LSPs terminology

Hi, Diego

   I understand your question is whether we shoud call LSP on the basis
of signaling session or not.

  If so, IMHO is Yes.
  The VC4-7v with single RSVP session is single LSP.
  On the other hand, VC4-3v + VC4-4v with two RSVP session is two LSPs.
  However, both of them are single LSP in the client layer as Dieter
said, .

  That is my understanding.
  But is that right, all ?

Best Regards
Wataru

>Hi Diego,
>
>Diego Caviglia wrote:
>
>>Hi all,
>>        I'd like to have a terminology clarification about virtual=20
>>concatenated LSP.
>>
>>When, say a VC4-7v, VCAT circuit is set-up with a single signalling
session
>>RFC3946 (Path, Resv and may be Resv Confirm) is correct to say that=20
>>the VCAT group is made by a single LSP or that is made by 7 LSPs?
>>
>>IMHO in that case there is a single LSP.
>>
>
>in my understanding, you are describing a multi-layer scenario here=20
>because the VCAT client layer sits on top of the VC4 server layer (see=20
>ITU-T Rec. G.806).
>
>If you are in the VCAT client layer, there is IMHO a single LSP that is

>decomposed into 7 HO VC4 LSPs in the VC4 server layer in your example.
>
>Now, if multiple (not necessarily all) VC4 LSPs are routed along the=20
>same path you could set up a server layer call containing multiple VC4=20
>connections using a single RSVP signaling session (as it was done in=20
>the OIF interop demo this year).
>
>I hope this clarifies the issue.
>
>
>Cheers,
>Dieter
>
>--
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>        V
>+---------------+      Dieter Beller
>| A L C A T E L |      Alcatel Optics Group
>+---------------+      Optical Networks Division
>                       Dept. US/BA3
>
>                       Alcatel SEL AG
>                       Lorenzstrasse 10
>                       D-70435 Stuttgart, Germany
>
>                       Phone:   +49 711 821-43125
>                       Fax:     +49 711 821-47045
>
>                       E-mail:  [email-masked]
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>

Delivery-date: Wed, 27 Jul 2005 10:49:38 +0000
Date: Wed, 27 Jul 2005 12:44:51 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: "Ali Sajassi (sajassi)" <[email-masked]>
CC: [email-masked], "CHO, JAI HYUNG" <[email-masked]>, Heiles Juergen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet

Ali,

yes - we can make a solution based on designated vlans "work", but if
we do that we will have serious scaling issues

i don't know if we are ready to start the discussion on solution, but
we seems to do that anyway ;)

there is a way for us to get a tpid from IEEE, we could specify the
behavior of switches on that tpid

my take that we shouldn't do that without involving ieee, but on the
other it is normally quite easy to work with them

but again we need to undestand requirements first

/Loa

Ali Sajassi (sajassi) wrote:
> Dimitri,
>  
> By "existing Ethernet switches", I mean Ethernet switches based on 
> current approved IEEE 802 .1Q/.1D standards and not the hypothetical 
> switches with TBD forwarding characteristics. Anyway, if the objective 
> is to use RSVP-TE with "existing Ethernet switches", you can do that 
> easily by designating a VLAN or (set of VLANs) for RSVP-TE traffic 
> and support both EoMPLS and native bridged traffic on a 
> single trunk. There is some overhead with such encapsulation but the 
> benefit of it is that it works now. If we want to do it through some 
> other means (such as MAC address translation), then the benefit of such 
> approach is not clear to me; however, the disadvantages are very clear 
> :-) Anyway, I'll look forward to more discussions during and after the 
> meeting next week.
>  
> Cheers,
> Ali
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked]
>     [mailto:[email-masked]]
>     *Sent:* Tuesday, July 26, 2005 4:21 PM
>     *To:* Ali Sajassi (sajassi)
>     *Cc:* CHO, JAI HYUNG; Heiles Juergen; [email-masked]; [email-masked]
>     *Subject:* RE: Frameformat in a l2cs gmpls rnvironment - Issues w/
>     GMPLS Ethernet
> 
>     ali
> 
>     to be clear here you are hanging on using the term "existing
>     Ethernet switches" while the document that has been at the source of
>     the discussion does not state "GMPLS must be deployable on existing
>     Ethernet switches" this may be the case but there are limitations
>     (and there are perfectly well understood, don't worry) beside this
>     you should also tell us what do you exactly mean with the term
>     "existing" - but this is a side issue -
> 
>     this said, this does NOT mean that a GMPLS Ethernet switch (either
>     existing or even "extended") would need to support a new Ethernet
>     802.3 frame forwarding paradigm, the difference is subtle but has to
>     be underlined
> 
>     note: there is a slot of 20 minutes during the next CCAMP WG meeting
>     where this document and all related issues will be heavily discussed
>     ... so i welcome you to join the festivities ;-)
> 
>     thanks,
> 
>     - dimitri.
> 
>      
> 
>     *"Ali Sajassi \(sajassi\)" <[email-masked]>*
>     Sent by: [email-masked]
>     07/25/2005 16:13 MST
> 
>     To: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen"
>     <[email-masked]>, <[email-masked]>
>     cc: <[email-masked]>
>     bcc:
>     Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/
>     GMPLS Ethernet
> 
> 
>     Jaihyung,
> 
>     It seems to me that your primary objective is to use the existing
>     Ethernet switches with new control plane (GMPLS) to setup TE paths for
>     different applications. And you mentioned three approaches for doing
>     this in your email. However, all three of them have issues and are not
>     viable. Lets go over them ...
> 
>      >
>      > In below mail, I discussed about three proposed approaches.
>      >
>      >
>      > 1. using VLAN tag as it is for L2 label encoding.
> 
>     As you know this approach has scalability issue and you are limited to
>     4K services in the network and if you try to use the upcoming IEEE
>     802.1ad standard to make VLANs, interface specific, then you will need
>     new switches and not existing Ethernet switches. Even if you use these
>     newer switches, you will still be limited to 4K services per interface
>     and it would defeat the objective of using existing switches.
> 
>      >
>      > 2. defining new protocol ID (TPID) and borrow VLAN tag format,
>      > ?or extended VLAN tag to implement label swapping.
>      >
> 
>     This approach requires new data plane functionality to be implemented
>     (which defeats the objective of using existing switches).
> 
>      > 3. use lower 3 bytes of MAC address for L2 label encoding.
>      >
> 
>     This approach has several issues:
>     1) how does MAC addresses get distributed among the bridges ? How does
>     this distribution works during a link or node failure ? How does it
>     recover from a link or node failure ?
> 
>     2) Will you assign a separate provider MAC for each customer MAC. If so,
>     then how do you address MAC scalability. If not, then how do you take
>     care of 1-to-N mapping between provider MAC address and customer MAC
>     addresses and how do you handle multipoint connections.
> 
>     3) how do handle customer FCS retention when doing this MAC translation
>     stuff ??
> 
>      >
>      > 802.1Q bridge forwards Ethernet frames using two dataplane tables
>      > - MAC forwarding table and VLAN forwarding table.
>      > Bridge control protocols, such as GARP, GVRP, GMRP,
>      > manipulate one of the two dataplane entities.
> 
>     This is not correct. Bridges don't have different databases for MAC
>     forwarding and VLAN forwarding. They have filtering datebase(s) with
>     corresponding IDs (FIDs). VLAN IDs get mapped to FIDs based on operation
>     mode (IVL versus SVL). Then once a filtering database is identified,
>     then a MAC address lookup is performed for forwarding. Bridge control
>     protocols use a designated MAC addressed and based on these MAC
>     addressed, the bridge knows how to process the frame.
> 
>      >
>      > Similarly, option 1 and 3 are about which one of two
>      > dataplane entities
>      > GMPLS protocol should control on behalf of bridge control protocols.
>      > The two proposals do not intend to modify bridge behavior
>      > seriously, such as MAC learning, aging, filtering.
>      > Therefore, the approaches 1 and 3 are in the scope of CCAMP.
> 
>     If that's the intention, you may find out soon you get more than what
>     you asked for :-)
> 
>      >
>      > (% note however, I would regard implementing label swapping
>      > function is acceptable change considering the Internal Sublayer
>      > design of 802.1D bridge.)
>      >
> 
>     The only way of doing this is using VID translation table specified in
>     IEEE 802.1ad which requires new data-plane functionality and thus
>     existing bridges cannot be used !!
> 
>     Also if going the route of tag swapping, you may consider using IEEE
>     802.1ah. As the editor of .1ah, I can go over the details when I get a
>     chance.
> 
>      >
>      > However, option 2 is about what TPID code we will
>      > choose to implement new switching function.
>      > The switch of this implementation should have new hardware
>      > design in addition to normal bride hardware.
>      > I think such proposal as option 2 is out of CCAMP scope.
> 
>     Yes.
> 
>      >
>      > Overall objective is improving scalability, traffic engineering (TE)
>      > characteristics of 802.1 bridge that it can be reliable, manageable
>      > enough to replace some core routers.
> 
>     Easier said than done :-)
> 
>      > The switching technique you mentioned above, such as
>      > Ethernet over MPLS as defined by PWE3 and L2VPN,
>      > are all actually router based technology, however this
>      > work is based on simple bridge architecture.
>      > Cost-effectiveness is the key differentiator.
>      >
> 
>     The devils are in the details and once you worked out the details, you
>     will see the issues.
> 
>      >
>      > In access or enterprise network, capability of providing end-to-end
>      > L2-LSP will enable service providers policing, measuring, charging
>      > application flows using Ethernet based network. This will eventually
>      > improve income structure and introduce new session based commercial
>      > service. I have been discussing this aspect in mail thread of
>      > title 'End-to-end L2-LSP'.  Please read the mail thread and comment
>      > on the discussion.
>      >
>      >
>      > >You mentioned to use the MAC address or part of it as a label.
>      > >The TRILL working group is defining shortest path routing
>      > for Ethernet.
>      > >How would this fit together?
>      >
>      >
>      > TRILL employs new encapsulation layer outside of Ethernet frames.
>      > However in my proposal of option-3, I simply use the Ethernet header
>      > to encode GMPLS label.
>      >
>      > The overall format of rbridge is
>      > [Ethernet][r-tag][Ethernet][ data..]
>      > It is not LSP based technology but a connectionless routing bridge.
>      > TTL count is very important in rbridge because frames are routed
>      > hop-by-hop and it may loop.
>      >
>      > Whereas in option-3 above, Ethernet frames that have certain
>      > OUI prefix in MAC address are forwarded via a path that
>      > GMPLS protocol has configured on MAC forwarding table.
>      >
> 
>     How does the redundancy work in here. Are you using bridge protocol in
>     conjunction with GMPLS protocol. If you do, then there are bunch of
>     issues. If you don't, then what is it used and how does it interact with
>     bridging protocols ??
> 
>     -Ali
> 
> 
>      >
>      > Thanks
>      >
>      > Jaihyung
>      >
>      >
>      >
>      > -----?? ???-----
>      > ?? ??: "Heiles Juergen" <[email-masked]>
>      > ?? ??: 2005-07-25 ?? 6:44:34
>      > ?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles
>      > Juergen" <[email-masked]>, "[email-masked]"
>      > <[email-masked]>
>      > ??: "[email-masked]" <[email-masked]>
>      > ??: RE: Frameformat in a l2cs gmpls rnvironment.
>      >
>      >
>      >
>      >
>      >
>      >
>      > Dear Jaihyung,
>      >
>      > you mention several options that could be used as a label.
>      > Most of them have strong impacts on the data plane and
>      > introduce new layer networks. Is this in the scope of CCAMP?
>      > What is the goal, to introduce a control plane for a existing
>      > L2 technology or introduce a new L2 technology? What would be
>      > the benefit of such a new L2 co switching technology compared
>      > to Ethernet over MPLS as defined by PWE3 and L2VPN?
>      > You mentioned to use the MAC address or part of it as a
>      > label. The TRILL working group is defining shortest path
>      > routing for Ethernet. How would this fit together?
>      >
>      >
>      > Regards
>      >
>      > Juergen
>      >
>      >
>      >
>      >
>      >
>      > > From: CHO, JAI HYUNG [mailto:[email-masked]]
>      > > Sent: Saturday, July 23, 2005 6:19 AM
>      > > To: Heiles Juergen; [email-masked]
>      > > Cc: [email-masked]
>      > > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
>      > >
>      > >
>      > > Dear Juergen, Par and all,
>      > >
>      > > The proposed framework of L2SC was not intended to suggest
>      > > any specific solution. It is still an open question.
>      > > As Adrian noted, it only aims to present requirements
>      > > as in scenarios that may drive people toward next step in many
>      > > viable solutions.
>      > >
>      > > In fact, there are other options we may also consider for L2
>      > > label encoding.
>      > > IEEE 802.1 Ethernet bridges forward frames based on 48bits of
>      > > MAC address,
>      > > and additionally using VLAN tag.
>      > >
>      > > When the purpose of GMPLS control over Ethernet is not to
>      > > create new dataplane
>      > > but to utilize IEEE 802.1 bridge architecture, we may
>      > consider using
>      > > one of the two forwarding methods, MAC forwarding or VLAN
>      > forwarding.
>      > > (and perhaps any other combination of fields in MAC, but I'll
>      > > not discuss it)
>      > >
>      > > Use of VLAN ID for label encoding may automate VLAN configuration
>      > > using IP protocols. However, GMPLS protocol cannot use the
>      > > field exclusively
>      > > because public/private operators already use VLAN for various
>      > > purpose.
>      > > There is a potential conflict with existing use of VLAN and
>      > > GMPLS use of VLAN label.
>      > > Furthermore, scalability of VLAN ID has been frequently noted
>      > > as weakness
>      > > because the size of VLAN ID is at most 4096 (12bit).
>      > >
>      > > The scalability may be improved if the scope of VLAN label is
>      > > confined to
>      > > link-local, and some additional swapping function of VLAN ID
>      > > is introduced in
>      > > Internal Sublayer [802.1D] of GMPLS implemented switch.
>      > > However, this will only be effective when the configuration
>      > > of network
>      > > is mesh structure that multiple LSP paths exist. If the
>      > > configuration of network
>      > > is star or tree shape, as normal configuration of access network,
>      > > LSPs concentrate in root node and total number of
>      > > LSPs that the network can hold still be limited by available
>      > > label space
>      > > at a few root links.
>      > >
>      > > For these reasons, I do not think any form of VLAN ID label is
>      > > an appropriate choice for layer-2 label encoding.
>      > >
>      > > There are some other proposals assuming new assignment of Ethernet
>      > > Length/Type value (e.g. new TPID in VLAN tag) and re-definition of
>      > > information fields placed between 802.3 MAC header and IP packet.
>      > > In this case, only the format of VLAN tag or extended VLAN tag
>      > > is borrowed, however, inside the switching hardware, the
>      > > filter and relay,
>      > > etc. are totally different new dataplane switch.
>      > >
>      > > I do not see such approach is a GMPLS implementation for Ethernet
>      > > because the core switching technique is not 802.1 Ethernet
>      > > bridge at all.
>      > >
>      > > The other option we may consider is using MAC address filed
>      > as below.
>      > >
>      > >
>      > > +-------+-------+-------+-------+-------+-------+
>      > > | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte |
>      > > +-------+-------+-------+-------+-------+-------+
>      > > +-----------------------+-----------------------+
>      > > |  OUI Prefix (=GMPLS)  |   DA-label (24bit)    |
>      > > +-----------------------+-----------------------+
>      > > |  OUI Prefix (=GMPLS)  |   SA-label (24bit)    |
>      > > +---------------+-------+-----------------------+
>      > > | Length/Type   |
>      > > +---------------+
>      > >
>      > >
>      > > IEEE is designated by the ISO Council to act as the
>      > > registration authority
>      > > for the higher three-octet of OUI number in the MAC address
>      > > to be used by manufacturer. Ethernet manufacturer may generate
>      > > global unique MAC address using the OUI prefix and address block of
>      > > lower three-octet (24bit). Taking advantage of the
>      > addressing scheme,
>      > > GMPLS may use the lower three-octet exclusively if a unique
>      > > OUI number
>      > > is reserved for the protocol. With this labeling scheme, GMPLS will
>      > > control MAC forwarding entry, not VLAN table.
>      > >
>      > > All Ethernet frames controlled by GMPLS will have identical
>      > > OUI number
>      > > that they can easily be distinguished from other Ethernet frames.
>      > > In principle, the label lookup hardware is identical to MAC lookup
>      > > hardware in this labeling scheme. Therefore GMPLS implemented
>      > > switch may still function as normal Ethernet bridge to the frames
>      > > that OUI number is not GMPLS. This also facilitates GMPLS
>      > implemented
>      > > switches being deployed in operating Ethernet with minimum
>      > > service disruption.
>      > >
>      > > Note also that above proposed label encoding method is transparent
>      > > to the use of Ethernet Length/Type field. End-user device may use
>      > > the Length/Type field as defined in IEEE 802.3 protocol.
>      > > It also allows network operators configure VLAN for their own
>      > > purpose.
>      > > When IEEE 802.1p is used in conjunction with L2-LSP, the priority
>      > > field of VLAN tag can also be used for imposing consistent TE
>      > > policy in
>      > > legacy switches and GMPLS switches.
>      > >
>      > > Any way, my conclusion is, there are other options we may consider,
>      > > and this issue is still open to discuss.
>      > >
>      > > Thanks,
>      > >
>      > > Sincerely,
>      > >
>      > > Jaihyung
>      > >
>      > >
>      > >
>      > >
>      > >
>      > > -----?? ???-----
>      > > ?? ??: "Heiles Juergen" <[email-masked]>
>      > > ?? ??: 2005-07-22 ?? 10:23:43
>      > > ?? ??: "Loa Andersson" <[email-masked]>, "[email-masked]"
>      > > <[email-masked]>
>      > > ??: "[email-masked]" <[email-masked]>, "[email-masked]"
>      > > <[email-masked]>
>      > > ??: RE: Frameformat in a l2cs gmpls rnvironment.
>      > >
>      > >
>      > >
>      > >
>      > >
>      > >
>      > > Loa,
>      > >
>      > > I interpret the ID as a proposal to use GMPLS for VLAN setup.
>      > > So GMPLS and VLAN to not compete. The VLAN is at the data
>      > > plane and GMPLS at the control plane. The question is how and
>      > > should different control plane techniques like GMPLS and
>      > > (GVRP and STB) work together?
>      > >
>      > > Regards
>      > >
>      > > Juergen
>      > >
>      > >
>      > > > From: [email-masked]
>      > > > [mailto:[email-masked]] On Behalf Of Loa Andersson
>      > > > Sent: Friday, July 22, 2005 2:53 PM
>      > > > To: [email-masked]
>      > > > Cc: [email-masked]; [email-masked]
>      > > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
>      > > >
>      > > > Richard,
>      > > >
>      > > > I agree to most of this. Since we have doubts about the viability
>      > > > of taking GMPLS all the way to end-user or enterprise I think it
>      > > > would be good, from a wg perspective, if we agreed to solve the
>      > > > core network problems first.
>      > > >
>      > > > Do you have any comment on the requirement to run both VLANs and
>      > > > GMPLS on the same switch?
>      > > >
>      > > > /Loa
>      > > >
>      > > > [email-masked] wrote:
>      > > > > Regardless of whether or not a switch is directly connected
>      > > >  > to hosts, it must be able to forward packets using the
>      > > > connectionless
>      > > >  > Ethernet data plane. This is due to the fundamental
>      > > > requirement that
>      > > >  > for GMPLS switches to be able to exchange control
>      > > information with
>      > > >  > each other, a data plane for control traffic must be present.
>      > > >  > This is akin to using the IP data plane for MPLS
>      > > signalling in an
>      > > >  > IP/MPLS network. An alternative would be to use a static
>      > > reserved
>      > > >  > L2-LSP for control traffic in the same way that reserved
>      > > VPI/VCIs
>      > > >  > are used for PNNI signalling in ATM.
>      > > > >
>      > > > > Regarding connecting hosts to GMPLS switches, I
>      > personally don't
>      > > >  > think extending L2-LSPs into the enterprise/home network is
>      > > >  > commercially viable. However, if you do want to use
>      > > GMPLS switches
>      > > >  > in the home/enterprise network and for some reason
>      > don't want to
>      > > >  > extend L2-LSPs down to the host then you will not be
>      > performing
>      > > >  > normal Ethernet Mac address switching anyway. Instead you will
>      > > >  > need some kind of policy on the switch that maps
>      > connectionless
>      > > >  > Ethernet packets (e.g. based on MAC src/dest, 802.1p,
>      > VLAN) to a
>      > > >  > L2-LSP. This is because multiple L2-LSPs to the same
>      > destination
>      > > >  > (e.g. a gateway router) may exist for different services/flows
>      > > >  > (e.g. video download, VoIP call, etc.).
>      > > > >
>      > > > > Regards,
>      > > > > Richard
>      > > > >
>      > > > >
>      > > > >>From: [email-masked]
>      > > [mailto:[email-masked]]On
>      > > > >>Behalf Of Par Mattsson
>      > > > >>Sent: 22 July 2005 11:42
>      > > > >>To: Loa Andersson
>      > > > >>Cc: [email-masked]
>      > > > >>Subject: Re: Frameformat in a l2cs gmpls rnvironment.
>      > > > >>
>      > > > >>
>      > > > >>
>      > > > >>>Per and Dimitri,
>      > > > >>>
>      > > > >>>I would like to come down stronger than that, for me it is
>      > > > >>>a very strong requirement that the same switch can handle
>      > > > >>>both VLANs and GMPLs trafic correctly. I can't dsee how that
>      > > > >>>could be done if using the VLAN tpid to indicate GMPLS
>      > > > >>>traffic.
>      > > > >>
>      > > > >>If you ever want that same switch to handle traffic for a
>      > > directly
>      > > > >>connected  host (not to uncommen) you would want that to
>      > > use normal
>      > > > >>ethernet macaddress switching. So of course you do not want
>      > > > to have to
>      > > > >>choose between vlan and gmpls, you would want both at the
>      > > same time.
>      > > > >>
>      > > > >>/per
>      > > > >>
>      > > > >>
>      > > > >>
>      > > > >>>/Loa
>      > > > >>>
>      > > > >>>Par Mattsson wrote:
>      > > > >>>
>      > > > >>>>>hi par, one of the possibilities that has been considered
>      > > > >>
>      > > > >>to cope with
>      > > > >>
>      > > > >>>>>this requirement is to use a dedicated TPID for the
>      > > > >>
>      > > > >>Ethernet labeled
>      > > > >>
>      > > > >>>>>frames; this would allow differentiated processing with
>      > > > non-labeled
>      > > > >>>>>framesthanks.
>      > > > >>>>
>      > > > >>>>
>      > > > >>>>That seems to make more sence. If that frame is to be
>      > > sized like a
>      > > > >>>>802.1q
>      > > > >>>>frame. There is not that much space left to a label. Or is
>      > > > >>
>      > > > >>the demand to
>      > > > >>
>      > > > >>>>use jumboframes ?
>      > > > >>>>Has there been any discussion on labelstacking, and
>      > > > mainly where to
>      > > > >>>>place
>      > > > >>>>the information?
>      > > > >>>>
>      > > > >>>>Regards.
>      > > > >>>>Per
>      > > > >>>>
>      > > > >>>>
>      > > > >>>>
>      > > > >>>
>      > > > >>>
>      > > > >>>--
>      > > > >>>Loa Andersson
>      > > > >>>
>      > > > >>>Principal Networking Architect
>      > > > >>>Acreo AB                           phone:  +46 8 632 77 14
>      > > > >>>Isafjordsgatan 22                  mobile: +46 739 81 21 64
>      > > > >>>Kista, Sweden                      email:
>      > > [email-masked]
>      > > > >>>                                            [email-masked]
>      > > > >>>
>      > > > >>
>      > > > >>
>      > > > >>
>      > > > >
>      > > >
>      > > >
>      > > > --
>      > > > Loa Andersson
>      > > >
>      > > > Principal Networking Architect
>      > > > Acreo AB                           phone:  +46 8 632 77 14
>      > > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
>      > > > Kista, Sweden                      email:  [email-masked]
>      > > >                                             [email-masked]
>      > > >
>      > >
>      > >
>      > >
>      > >
>      >
>      >
>      >
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Wed, 27 Jul 2005 08:25:23 +0000
Sensitivity: 
Subject: Re: VCn-xV LSPs terminology
To: "Wataru Imajuku <imajuku.wataru" <[email-masked]>
Cc: "Dieter Beller <D.Beller" <[email-masked]>, "ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 27 Jul 2005 10:24:45 +0200

Hi Wataru, Dieter,
                    yes I agree with both of you.

Regards

Diego

Wataru Imajuku <[email-masked]> on 27/07/2005 10.00.02

To:    Dieter Beller <[email-masked]>, Diego Caviglia
       <[email-masked]>
cc:    [email-masked]

Subject:    Re: VCn-xV LSPs terminology

Hi, Diego

   I understand your question is whether we shoud call LSP on
the basis of signaling session or not.

  If so, IMHO is Yes.
  The VC4-7v with single RSVP session is single LSP.
  On the other hand, VC4-3v + VC4-4v with two RSVP session is two LSPs.
  However, both of them are single LSP in the client layer as Dieter said,
.

  That is my understanding.
  But is that right, all ?

Best Regards
Wataru

>Hi Diego,
>
>Diego Caviglia wrote:
>
>>Hi all,
>>        I'd like to have a terminology clarification about virtual
>>concatenated LSP.
>>
>>When, say a VC4-7v, VCAT circuit is set-up with a single signalling
session
>>RFC3946 (Path, Resv and may be Resv Confirm) is correct to say that the
>>VCAT group is made by a single LSP or that is made by 7 LSPs?
>>
>>IMHO in that case there is a single LSP.
>>
>
>in my understanding, you are describing a multi-layer scenario here
>because the VCAT client layer sits on top of the VC4 server layer (see
>ITU-T Rec. G.806).
>
>If you are in the VCAT client layer, there is IMHO a single LSP that
>is decomposed into 7 HO VC4 LSPs in the VC4 server layer in your
>example.
>
>Now, if multiple (not necessarily all) VC4 LSPs are routed along the
>same path you could set up a server layer call containing multiple
>VC4 connections using a single RSVP signaling session (as it was
>done in the OIF interop demo this year).
>
>I hope this clarifies the issue.
>
>
>Cheers,
>Dieter
>
>--
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>        V
>+---------------+      Dieter Beller
>| A L C A T E L |      Alcatel Optics Group
>+---------------+      Optical Networks Division
>                       Dept. US/BA3
>
>                       Alcatel SEL AG
>                       Lorenzstrasse 10
>                       D-70435 Stuttgart, Germany
>
>                       Phone:   +49 711 821-43125
>                       Fax:     +49 711 821-47045
>
>                       E-mail:  [email-masked]
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>

Delivery-date: Wed, 27 Jul 2005 08:00:30 +0000
Date: Wed, 27 Jul 2005 17:00:02 +0900
To: Dieter Beller <[email-masked]>, Diego Caviglia <[email-masked]>
From: Wataru Imajuku <[email-masked]>
Subject: Re: VCn-xV LSPs terminology
Cc: [email-masked]

Hi, Diego

   I understand your question is whether we shoud call LSP on
the basis of signaling session or not.

  If so, IMHO is Yes.
  The VC4-7v with single RSVP session is single LSP.
  On the other hand, VC4-3v + VC4-4v with two RSVP session is two LSPs.
  However, both of them are single LSP in the client layer as Dieter said, .

  That is my understanding.
  But is that right, all ?

Best Regards
Wataru

>Hi Diego,
>
>Diego Caviglia wrote:
>
>>Hi all,
>>        I'd like to have a terminology clarification about virtual
>>concatenated LSP.
>>
>>When, say a VC4-7v, VCAT circuit is set-up with a single signalling session
>>RFC3946 (Path, Resv and may be Resv Confirm) is correct to say that the
>>VCAT group is made by a single LSP or that is made by 7 LSPs?
>>
>>IMHO in that case there is a single LSP.
>>
>
>in my understanding, you are describing a multi-layer scenario here
>because the VCAT client layer sits on top of the VC4 server layer (see
>ITU-T Rec. G.806).
>
>If you are in the VCAT client layer, there is IMHO a single LSP that
>is decomposed into 7 HO VC4 LSPs in the VC4 server layer in your
>example.
>
>Now, if multiple (not necessarily all) VC4 LSPs are routed along the
>same path you could set up a server layer call containing multiple
>VC4 connections using a single RSVP signaling session (as it was
>done in the OIF interop demo this year).
>
>I hope this clarifies the issue.
>
>
>Cheers,
>Dieter
>
>--
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>        V
>+---------------+      Dieter Beller
>| A L C A T E L |      Alcatel Optics Group
>+---------------+      Optical Networks Division
>                       Dept. US/BA3
>
>                       Alcatel SEL AG
>                       Lorenzstrasse 10
>                       D-70435 Stuttgart, Germany
>
>                       Phone:   +49 711 821-43125
>                       Fax:     +49 711 821-47045
>
>                       E-mail:  [email-masked]
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>

Delivery-date: Wed, 27 Jul 2005 07:41:37 +0000
Date: Wed, 27 Jul 2005 09:40:24 +0200
From: Dieter Beller <[email-masked]>
Organization: Alcatel SEL AG, OND Germany
To: Diego Caviglia <[email-masked]>
CC: [email-masked]
Subject: Re: VCn-xV LSPs terminology

Hi Diego,

Diego Caviglia wrote:

>Hi all,
>        I'd like to have a terminology clarification about virtual
>concatenated LSP.
>
>When, say a VC4-7v, VCAT circuit is set-up with a single signalling session
>RFC3946 (Path, Resv and may be Resv Confirm) is correct to say that the
>VCAT group is made by a single LSP or that is made by 7 LSPs?
>
>IMHO in that case there is a single LSP.
>  
>

in my understanding, you are describing a multi-layer scenario here
because the VCAT client layer sits on top of the VC4 server layer (see
ITU-T Rec. G.806).

If you are in the VCAT client layer, there is IMHO a single LSP that
is decomposed into 7 HO VC4 LSPs in the VC4 server layer in your
example.

Now, if multiple (not necessarily all) VC4 LSPs are routed along the
same path you could set up a server layer call containing multiple
VC4 connections using a single RSVP signaling session (as it was
done in the OIF interop demo this year).

I hope this clarifies the issue.

Cheers,
Dieter

-- 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

        V
+---------------+      Dieter Beller
| A L C A T E L |      Alcatel Optics Group
+---------------+      Optical Networks Division
                       Dept. US/BA3

                       Alcatel SEL AG
                       Lorenzstrasse 10
                       D-70435 Stuttgart, Germany

                       Phone:   +49 711 821-43125
                       Fax:     +49 711 821-47045

                       E-mail:  [email-masked]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Delivery-date: Wed, 27 Jul 2005 06:57:50 +0000
Sensitivity: 
Subject: VCn-xV LSPs terminology
To: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 27 Jul 2005 08:57:02 +0200

Hi all,
        I'd like to have a terminology clarification about virtual
concatenated LSP.

When, say a VC4-7v, VCAT circuit is set-up with a single signalling session
RFC3946 (Path, Resv and may be Resv Confirm) is correct to say that the
VCAT group is made by a single LSP or that is made by 7 LSPs?

IMHO in that case there is a single LSP.

Regards

Diego

Delivery-date: Wed, 27 Jul 2005 06:26:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Date: Tue, 26 Jul 2005 23:24:47 -0700
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: <[email-masked]>
Cc: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen" <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C59273.E41176C9
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Dimitri,
=20
By "existing Ethernet switches", I mean Ethernet switches based on
current approved IEEE 802 .1Q/.1D standards and not the hypothetical
switches with TBD forwarding characteristics. Anyway, if the objective
is to use RSVP-TE with "existing Ethernet switches", you can do that
easily by designating a VLAN or (set of VLANs) for RSVP-TE traffic and
support both EoMPLS and native bridged traffic on a single trunk. There
is some overhead with such encapsulation but the benefit of it is that
it works now. If we want to do it through some other means (such as MAC
address translation), then the benefit of such approach is not clear to
me; however, the disadvantages are very clear :-) Anyway, I'll look
forward to more discussions during and after the meeting next week.
=20
Cheers,
Ali

________________________________

	From: [email-masked]
[mailto:[email-masked]]=20
	Sent: Tuesday, July 26, 2005 4:21 PM
	To: Ali Sajassi (sajassi)
	Cc: CHO, JAI HYUNG; Heiles Juergen; [email-masked];
[email-masked]
	Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/
GMPLS Ethernet
=09
=09

	ali

	to be clear here you are hanging on using the term "existing
Ethernet switches" while the document that has been at the source of the
discussion does not state "GMPLS must be deployable on existing Ethernet
switches" this may be the case but there are limitations (and there are
perfectly well understood, don't worry) beside this you should also tell
us what do you exactly mean with the term "existing" - but this is a
side issue -

	this said, this does NOT mean that a GMPLS Ethernet switch
(either existing or even "extended") would need to support a new
Ethernet 802.3 frame forwarding paradigm, the difference is subtle but
has to be underlined

	note: there is a slot of 20 minutes during the next CCAMP WG
meeting where this document and all related issues will be heavily
discussed ... so i welcome you to join the festivities ;-)

	thanks,

	- dimitri.

	 =20
=09
	"Ali Sajassi \(sajassi\)" <[email-masked]>
	Sent by: [email-masked]
	07/25/2005 16:13 MST
=09
	To: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen"
<[email-masked]>, <[email-masked]>
	cc: <[email-masked]>
	bcc:=20
	Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/
GMPLS Ethernet
=09
=09
=09

	Jaihyung,
=09
	It seems to me that your primary objective is to use the
existing
	Ethernet switches with new control plane (GMPLS) to setup TE
paths for
	different applications. And you mentioned three approaches for
doing
	this in your email. However, all three of them have issues and
are not
	viable. Lets go over them ...
=09
	>
	> In below mail, I discussed about three proposed approaches.
	>
	>
	> 1. using VLAN tag as it is for L2 label encoding.
=09
	As you know this approach has scalability issue and you are
limited to
	4K services in the network and if you try to use the upcoming
IEEE
	802.1ad standard to make VLANs, interface specific, then you
will need
	new switches and not existing Ethernet switches. Even if you use
these
	newer switches, you will still be limited to 4K services per
interface
	and it would defeat the objective of using existing switches.
=09
	>
	> 2. defining new protocol ID (TPID) and borrow VLAN tag format,
	> ?or extended VLAN tag to implement label swapping.
	>
=09
	This approach requires new data plane functionality to be
implemented
	(which defeats the objective of using existing switches).
=09
	> 3. use lower 3 bytes of MAC address for L2 label encoding.
	>
=09
	This approach has several issues:
	1) how does MAC addresses get distributed among the bridges ?
How does
	this distribution works during a link or node failure ? How does
it
	recover from a link or node failure ?
=09
	2) Will you assign a separate provider MAC for each customer
MAC. If so,
	then how do you address MAC scalability. If not, then how do you
take
	care of 1-to-N mapping between provider MAC address and customer
MAC
	addresses and how do you handle multipoint connections.
=09
	3) how do handle customer FCS retention when doing this MAC
translation
	stuff ??
=09
	>
	> 802.1Q bridge forwards Ethernet frames using two dataplane
tables
	> - MAC forwarding table and VLAN forwarding table.
	> Bridge control protocols, such as GARP, GVRP, GMRP,
	> manipulate one of the two dataplane entities.
=09
	This is not correct. Bridges don't have different databases for
MAC
	forwarding and VLAN forwarding. They have filtering datebase(s)
with
	corresponding IDs (FIDs). VLAN IDs get mapped to FIDs based on
operation
	mode (IVL versus SVL). Then once a filtering database is
identified,
	then a MAC address lookup is performed for forwarding. Bridge
control
	protocols use a designated MAC addressed and based on these MAC
	addressed, the bridge knows how to process the frame.
=09
	>
	> Similarly, option 1 and 3 are about which one of two
	> dataplane entities
	> GMPLS protocol should control on behalf of bridge control
protocols.
	> The two proposals do not intend to modify bridge behavior
	> seriously, such as MAC learning, aging, filtering.
	> Therefore, the approaches 1 and 3 are in the scope of CCAMP.
=09
	If that's the intention, you may find out soon you get more than
what
	you asked for :-)
=09
	>
	> (% note however, I would regard implementing label swapping
	> function is acceptable change considering the Internal
Sublayer
	> design of 802.1D bridge.)
	>
=09
	The only way of doing this is using VID translation table
specified in
	IEEE 802.1ad which requires new data-plane functionality and
thus
	existing bridges cannot be used !!
=09
	Also if going the route of tag swapping, you may consider using
IEEE
	802.1ah. As the editor of .1ah, I can go over the details when I
get a
	chance.
=09
	>
	> However, option 2 is about what TPID code we will
	> choose to implement new switching function.
	> The switch of this implementation should have new hardware
	> design in addition to normal bride hardware.
	> I think such proposal as option 2 is out of CCAMP scope.
=09
	Yes.
=09
	>
	> Overall objective is improving scalability, traffic
engineering (TE)
	> characteristics of 802.1 bridge that it can be reliable,
manageable
	> enough to replace some core routers.
=09
	Easier said than done :-)
=09
	> The switching technique you mentioned above, such as
	> Ethernet over MPLS as defined by PWE3 and L2VPN,
	> are all actually router based technology, however this
	> work is based on simple bridge architecture.
	> Cost-effectiveness is the key differentiator.
	>
=09
	The devils are in the details and once you worked out the
details, you
	will see the issues.
=09
	>
	> In access or enterprise network, capability of providing
end-to-end
	> L2-LSP will enable service providers policing, measuring,
charging
	> application flows using Ethernet based network. This will
eventually
	> improve income structure and introduce new session based
commercial
	> service. I have been discussing this aspect in mail thread of
	> title 'End-to-end L2-LSP'.  Please read the mail thread and
comment
	> on the discussion.
	>
	>
	> >You mentioned to use the MAC address or part of it as a
label.
	> >The TRILL working group is defining shortest path routing
	> for Ethernet.
	> >How would this fit together?
	>
	>
	> TRILL employs new encapsulation layer outside of Ethernet
frames.
	> However in my proposal of option-3, I simply use the Ethernet
header
	> to encode GMPLS label.
	>
	> The overall format of rbridge is
	> [Ethernet][r-tag][Ethernet][ data..]
	> It is not LSP based technology but a connectionless routing
bridge.
	> TTL count is very important in rbridge because frames are
routed
	> hop-by-hop and it may loop.
	>
	> Whereas in option-3 above, Ethernet frames that have certain
	> OUI prefix in MAC address are forwarded via a path that
	> GMPLS protocol has configured on MAC forwarding table.
	>
=09
	How does the redundancy work in here. Are you using bridge
protocol in
	conjunction with GMPLS protocol. If you do, then there are bunch
of
	issues. If you don't, then what is it used and how does it
interact with
	bridging protocols ??
=09
	-Ali
=09
=09
	>
	> Thanks
	>
	> Jaihyung
	>
	>
	>
	> -----?? ???-----
	> ?? ??: "Heiles Juergen" <[email-masked]>
	> ?? ??: 2005-07-25 ?? 6:44:34
	> ?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles
	> Juergen" <[email-masked]>, "[email-masked]"
	> <[email-masked]>
	> ??: "[email-masked]" <[email-masked]>
	> ??: RE: Frameformat in a l2cs gmpls rnvironment.
	>
	>
	>
	>
	>
	>
	> Dear Jaihyung,
	>
	> you mention several options that could be used as a label.
	> Most of them have strong impacts on the data plane and
	> introduce new layer networks. Is this in the scope of CCAMP?
	> What is the goal, to introduce a control plane for a existing
	> L2 technology or introduce a new L2 technology? What would be
	> the benefit of such a new L2 co switching technology compared
	> to Ethernet over MPLS as defined by PWE3 and L2VPN?
	> You mentioned to use the MAC address or part of it as a
	> label. The TRILL working group is defining shortest path
	> routing for Ethernet. How would this fit together?
	>
	>
	> Regards
	>
	> Juergen
	>
	>
	>
	>
	>
	> > From: CHO, JAI HYUNG [mailto:[email-masked]]
	> > Sent: Saturday, July 23, 2005 6:19 AM
	> > To: Heiles Juergen; [email-masked]
	> > Cc: [email-masked]
	> > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
	> >
	> >
	> > Dear Juergen, Par and all,
	> >
	> > The proposed framework of L2SC was not intended to suggest
	> > any specific solution. It is still an open question.
	> > As Adrian noted, it only aims to present requirements
	> > as in scenarios that may drive people toward next step in
many
	> > viable solutions.
	> >
	> > In fact, there are other options we may also consider for L2
	> > label encoding.
	> > IEEE 802.1 Ethernet bridges forward frames based on 48bits
of
	> > MAC address,
	> > and additionally using VLAN tag.
	> >
	> > When the purpose of GMPLS control over Ethernet is not to
	> > create new dataplane
	> > but to utilize IEEE 802.1 bridge architecture, we may
	> consider using
	> > one of the two forwarding methods, MAC forwarding or VLAN
	> forwarding.
	> > (and perhaps any other combination of fields in MAC, but
I'll
	> > not discuss it)
	> >
	> > Use of VLAN ID for label encoding may automate VLAN
configuration
	> > using IP protocols. However, GMPLS protocol cannot use the
	> > field exclusively
	> > because public/private operators already use VLAN for
various
	> > purpose.
	> > There is a potential conflict with existing use of VLAN and
	> > GMPLS use of VLAN label.
	> > Furthermore, scalability of VLAN ID has been frequently
noted
	> > as weakness
	> > because the size of VLAN ID is at most 4096 (12bit).
	> >
	> > The scalability may be improved if the scope of VLAN label
is
	> > confined to
	> > link-local, and some additional swapping function of VLAN ID
	> > is introduced in
	> > Internal Sublayer [802.1D] of GMPLS implemented switch.
	> > However, this will only be effective when the configuration
	> > of network
	> > is mesh structure that multiple LSP paths exist. If the
	> > configuration of network
	> > is star or tree shape, as normal configuration of access
network,
	> > LSPs concentrate in root node and total number of
	> > LSPs that the network can hold still be limited by available
	> > label space
	> > at a few root links.
	> >
	> > For these reasons, I do not think any form of VLAN ID label
is
	> > an appropriate choice for layer-2 label encoding.
	> >
	> > There are some other proposals assuming new assignment of
Ethernet
	> > Length/Type value (e.g. new TPID in VLAN tag) and
re-definition of
	> > information fields placed between 802.3 MAC header and IP
packet.
	> > In this case, only the format of VLAN tag or extended VLAN
tag
	> > is borrowed, however, inside the switching hardware, the
	> > filter and relay,
	> > etc. are totally different new dataplane switch.
	> >
	> > I do not see such approach is a GMPLS implementation for
Ethernet
	> > because the core switching technique is not 802.1 Ethernet
	> > bridge at all.
	> >
	> > The other option we may consider is using MAC address filed
	> as below.
	> >
	> >
	> > +-------+-------+-------+-------+-------+-------+
	> > | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte |
	> > +-------+-------+-------+-------+-------+-------+
	> > +-----------------------+-----------------------+
	> > |  OUI Prefix (=3DGMPLS)  |   DA-label (24bit)    |
	> > +-----------------------+-----------------------+
	> > |  OUI Prefix (=3DGMPLS)  |   SA-label (24bit)    |
	> > +---------------+-------+-----------------------+
	> > | Length/Type   |
	> > +---------------+
	> >
	> >
	> > IEEE is designated by the ISO Council to act as the
	> > registration authority
	> > for the higher three-octet of OUI number in the MAC address
	> > to be used by manufacturer. Ethernet manufacturer may
generate
	> > global unique MAC address using the OUI prefix and address
block of
	> > lower three-octet (24bit). Taking advantage of the
	> addressing scheme,
	> > GMPLS may use the lower three-octet exclusively if a unique
	> > OUI number
	> > is reserved for the protocol. With this labeling scheme,
GMPLS will
	> > control MAC forwarding entry, not VLAN table.
	> >
	> > All Ethernet frames controlled by GMPLS will have identical
	> > OUI number
	> > that they can easily be distinguished from other Ethernet
frames.
	> > In principle, the label lookup hardware is identical to MAC
lookup
	> > hardware in this labeling scheme. Therefore GMPLS
implemented
	> > switch may still function as normal Ethernet bridge to the
frames
	> > that OUI number is not GMPLS. This also facilitates GMPLS
	> implemented
	> > switches being deployed in operating Ethernet with minimum
	> > service disruption.
	> >
	> > Note also that above proposed label encoding method is
transparent
	> > to the use of Ethernet Length/Type field. End-user device
may use
	> > the Length/Type field as defined in IEEE 802.3 protocol.
	> > It also allows network operators configure VLAN for their
own
	> > purpose.
	> > When IEEE 802.1p is used in conjunction with L2-LSP, the
priority
	> > field of VLAN tag can also be used for imposing consistent
TE
	> > policy in
	> > legacy switches and GMPLS switches.
	> >
	> > Any way, my conclusion is, there are other options we may
consider,
	> > and this issue is still open to discuss.
	> >
	> > Thanks,
	> >
	> > Sincerely,
	> >
	> > Jaihyung
	> >
	> >
	> >
	> >
	> >
	> > -----?? ???-----
	> > ?? ??: "Heiles Juergen" <[email-masked]>
	> > ?? ??: 2005-07-22 ?? 10:23:43
	> > ?? ??: "Loa Andersson" <[email-masked]>, "[email-masked]"
	> > <[email-masked]>
	> > ??: "[email-masked]" <[email-masked]>, "[email-masked]"
	> > <[email-masked]>
	> > ??: RE: Frameformat in a l2cs gmpls rnvironment.
	> >
	> >
	> >
	> >
	> >
	> >
	> > Loa,
	> >
	> > I interpret the ID as a proposal to use GMPLS for VLAN
setup.
	> > So GMPLS and VLAN to not compete. The VLAN is at the data
	> > plane and GMPLS at the control plane. The question is how
and
	> > should different control plane techniques like GMPLS and
	> > (GVRP and STB) work together?
	> >
	> > Regards
	> >
	> > Juergen
	> >
	> >
	> > > From: [email-masked]
	> > > [mailto:[email-masked]] On Behalf Of Loa
Andersson
	> > > Sent: Friday, July 22, 2005 2:53 PM
	> > > To: [email-masked]
	> > > Cc: [email-masked]; [email-masked]
	> > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
	> > >
	> > > Richard,
	> > >
	> > > I agree to most of this. Since we have doubts about the
viability
	> > > of taking GMPLS all the way to end-user or enterprise I
think it
	> > > would be good, from a wg perspective, if we agreed to
solve the
	> > > core network problems first.
	> > >
	> > > Do you have any comment on the requirement to run both
VLANs and
	> > > GMPLS on the same switch?
	> > >
	> > > /Loa
	> > >
	> > > [email-masked] wrote:
	> > > > Regardless of whether or not a switch is directly
connected
	> > >  > to hosts, it must be able to forward packets using the
	> > > connectionless
	> > >  > Ethernet data plane. This is due to the fundamental
	> > > requirement that
	> > >  > for GMPLS switches to be able to exchange control
	> > information with
	> > >  > each other, a data plane for control traffic must be
present.
	> > >  > This is akin to using the IP data plane for MPLS
	> > signalling in an
	> > >  > IP/MPLS network. An alternative would be to use a
static
	> > reserved
	> > >  > L2-LSP for control traffic in the same way that
reserved
	> > VPI/VCIs
	> > >  > are used for PNNI signalling in ATM.
	> > > >
	> > > > Regarding connecting hosts to GMPLS switches, I
	> personally don't
	> > >  > think extending L2-LSPs into the enterprise/home
network is
	> > >  > commercially viable. However, if you do want to use
	> > GMPLS switches
	> > >  > in the home/enterprise network and for some reason
	> don't want to
	> > >  > extend L2-LSPs down to the host then you will not be
	> performing
	> > >  > normal Ethernet Mac address switching anyway. Instead
you will
	> > >  > need some kind of policy on the switch that maps
	> connectionless
	> > >  > Ethernet packets (e.g. based on MAC src/dest, 802.1p,=20
	> VLAN) to a
	> > >  > L2-LSP. This is because multiple L2-LSPs to the same
	> destination
	> > >  > (e.g. a gateway router) may exist for different
services/flows
	> > >  > (e.g. video download, VoIP call, etc.).
	> > > >
	> > > > Regards,
	> > > > Richard
	> > > >
	> > > >
	> > > >>From: [email-masked]
	> > [mailto:[email-masked]]On
	> > > >>Behalf Of Par Mattsson
	> > > >>Sent: 22 July 2005 11:42
	> > > >>To: Loa Andersson
	> > > >>Cc: [email-masked]
	> > > >>Subject: Re: Frameformat in a l2cs gmpls rnvironment.
	> > > >>
	> > > >>
	> > > >>
	> > > >>>Per and Dimitri,
	> > > >>>
	> > > >>>I would like to come down stronger than that, for me it
is
	> > > >>>a very strong requirement that the same switch can
handle
	> > > >>>both VLANs and GMPLs trafic correctly. I can't dsee how
that
	> > > >>>could be done if using the VLAN tpid to indicate GMPLS
	> > > >>>traffic.
	> > > >>
	> > > >>If you ever want that same switch to handle traffic for
a
	> > directly
	> > > >>connected  host (not to uncommen) you would want that to
	> > use normal
	> > > >>ethernet macaddress switching. So of course you do not
want
	> > > to have to
	> > > >>choose between vlan and gmpls, you would want both at
the
	> > same time.
	> > > >>
	> > > >>/per
	> > > >>
	> > > >>
	> > > >>
	> > > >>>/Loa
	> > > >>>
	> > > >>>Par Mattsson wrote:
	> > > >>>
	> > > >>>>>hi par, one of the possibilities that has been
considered
	> > > >>
	> > > >>to cope with
	> > > >>
	> > > >>>>>this requirement is to use a dedicated TPID for the
	> > > >>
	> > > >>Ethernet labeled
	> > > >>
	> > > >>>>>frames; this would allow differentiated processing
with
	> > > non-labeled
	> > > >>>>>framesthanks.
	> > > >>>>
	> > > >>>>
	> > > >>>>That seems to make more sence. If that frame is to be
	> > sized like a
	> > > >>>>802.1q
	> > > >>>>frame. There is not that much space left to a label.
Or is
	> > > >>
	> > > >>the demand to
	> > > >>
	> > > >>>>use jumboframes ?
	> > > >>>>Has there been any discussion on labelstacking, and
	> > > mainly where to
	> > > >>>>place
	> > > >>>>the information?
	> > > >>>>
	> > > >>>>Regards.
	> > > >>>>Per
	> > > >>>>
	> > > >>>>
	> > > >>>>
	> > > >>>
	> > > >>>
	> > > >>>--
	> > > >>>Loa Andersson
	> > > >>>
	> > > >>>Principal Networking Architect
	> > > >>>Acreo AB                           phone:  +46 8 632 77
14
	> > > >>>Isafjordsgatan 22                  mobile: +46 739 81
21 64
	> > > >>>Kista, Sweden                      email:
	> > [email-masked]
	> > > >>>                                            [email-masked]
	> > > >>>
	> > > >>
	> > > >>
	> > > >>
	> > > >
	> > >
	> > >
	> > > --
	> > > Loa Andersson
	> > >
	> > > Principal Networking Architect
	> > > Acreo AB                           phone:  +46 8 632 77 14
	> > > Isafjordsgatan 22                  mobile: +46 739 81 21
64
	> > > Kista, Sweden                      email:
[email-masked]
	> > >                                             [email-masked]

------_=_NextPart_001_01C59273.E41176C9
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1505" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D696540506-27072005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Dimitri,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D696540506-27072005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D696540506-27072005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>By "existing Ethernet switches", I mean =
Ethernet switches=20
based on current approved&nbsp;IEEE 802&nbsp;.1Q/.1D&nbsp;standards and =
not the=20
hypothetical switches with&nbsp;TBD forwarding characteristics. Anyway, =
if the=20
objective is to use RSVP-TE with&nbsp;"existing Ethernet switches", you =
can do=20
that easily by&nbsp;designating a VLAN or (set of VLANs)&nbsp;for =
RSVP-TE=20
traffic and&nbsp;support both EoMPLS and native bridged traffic on a=20
single&nbsp;trunk.&nbsp;There is&nbsp;some overhead with such =
encapsulation but=20
the benefit of it is that it works now.&nbsp;If we want to=20
do&nbsp;it&nbsp;through some other means (such as MAC address =
translation), then=20
the benefit of such approach is not clear to me; however, the =
disadvantages are=20
very clear :-) Anyway, I'll look forward to more discussions during and =
after=20
the meeting next week.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D696540506-27072005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D696540506-27072005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D696540506-27072005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Ali</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Tuesday, =
July 26,=20
  2005 4:21 PM<BR><B>To:</B> Ali Sajassi (sajassi)<BR><B>Cc:</B> CHO, =
JAI HYUNG;=20
  Heiles Juergen; [email-masked]; [email-masked]<BR><B>Subject:</B> =
RE:=20
  Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS=20
  Ethernet<BR></FONT><BR></DIV>
  <DIV></DIV>
  <P><FONT face=3DMonospace,Courier>ali</FONT></P>
  <P><FONT face=3DMonospace,Courier>to be clear here you are hanging on =
using the=20
  term "existing Ethernet switches" while the document that has been at =
the=20
  source of the discussion does not state "GMPLS must be deployable on =
existing=20
  Ethernet switches" this may be the case but there are limitations (and =
there=20
  are perfectly well understood, don't worry) beside this you should =
also tell=20
  us what do you exactly mean with the term "existing" - but this is a =
side=20
  issue -</FONT></P>
  <P><FONT face=3DMonospace,Courier>this said, this does NOT mean that a =
GMPLS=20
  Ethernet switch (either existing or even "extended") would need to =
support a=20
  new Ethernet 802.3 frame forwarding paradigm, the difference is subtle =
but has=20
  to be underlined</FONT></P>
  <P><FONT face=3DMonospace,Courier>note: there is a slot of 20 minutes =
during the=20
  next CCAMP WG meeting where this document and all related issues will =
be=20
  heavily discussed ... so i welcome you to join the festivities =
;-)</FONT></P>
  <P><FONT face=3DMonospace,Courier>thanks,</FONT></P>
  <P><FONT face=3DMonospace,Courier>- dimitri.</FONT></P>
  <P><FONT face=3DMonospace,Courier>&nbsp; </FONT><BR><BR><FONT =
size=3D2><B>"Ali=20
  Sajassi \(sajassi\)" &lt;[email-masked]&gt;</B></FONT><BR><FONT =
size=3D2>Sent=20
  by: [email-masked]</FONT><BR><FONT size=3D2>07/25/2005 16:13 =

  MST</FONT><BR><BR><FONT size=3D2>To:</FONT> <FONT size=3D2>"CHO, JAI =
HYUNG"=20
  &lt;[email-masked]&gt;, "Heiles Juergen"=20
  &lt;[email-masked]&gt;, =
&lt;[email-masked]&gt;</FONT><BR><FONT=20
  size=3D2>cc:</FONT> <FONT =
size=3D2>&lt;[email-masked]&gt;</FONT><BR><FONT=20
  size=3D2>bcc:</FONT> <BR><FONT size=3D2>Subject:</FONT> <FONT =
size=3D2>RE:=20
  Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS=20
  Ethernet</FONT><BR><BR><BR></P>
  <P><FONT face=3DMonospace,Courier>Jaihyung,<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>It seems to me that your primary objective is =
to use=20
  the existing<BR>Ethernet switches with new control plane (GMPLS) to =
setup TE=20
  paths for<BR>different applications. And you mentioned three =
approaches for=20
  doing<BR>this in your email. However, all three of them have issues =
and are=20
  not<BR>viable. Lets go over them ...<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>&gt;<BR>&gt; In below mail, I discussed about =
three=20
  proposed approaches.<BR>&gt;<BR>&gt;<BR>&gt; 1. using VLAN tag as it =
is for L2=20
  label encoding.<BR></FONT><BR><FONT face=3DMonospace,Courier>As you =
know this=20
  approach has scalability issue and you are limited to<BR>4K services =
in the=20
  network and if you try to use the upcoming IEEE<BR>802.1ad standard to =
make=20
  VLANs, interface specific, then you will need<BR>new switches and not =
existing=20
  Ethernet switches. Even if you use these<BR>newer switches, you will =
still be=20
  limited to 4K services per interface<BR>and it would defeat the =
objective of=20
  using existing switches.<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>&gt;<BR>&gt; 2. defining new protocol ID =
(TPID) and=20
  borrow VLAN tag format,<BR>&gt; ?or extended VLAN tag to implement =
label=20
  swapping.<BR>&gt;<BR></FONT><BR><FONT face=3DMonospace,Courier>This =
approach=20
  requires new data plane functionality to be implemented<BR>(which =
defeats the=20
  objective of using existing switches).<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>&gt; 3. use lower 3 bytes of MAC address for =
L2 label=20
  encoding.<BR>&gt;<BR></FONT><BR><FONT face=3DMonospace,Courier>This =
approach has=20
  several issues:<BR>1) how does MAC addresses get distributed among the =
bridges=20
  ? How does<BR>this distribution works during a link or node failure ? =
How does=20
  it<BR>recover from a link or node failure ?<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>2) Will you assign a separate provider MAC =
for each=20
  customer MAC. If so,<BR>then how do you address MAC scalability. If =
not, then=20
  how do you take<BR>care of 1-to-N mapping between provider MAC address =
and=20
  customer MAC<BR>addresses and how do you handle multipoint=20
  connections.<BR></FONT><BR><FONT face=3DMonospace,Courier>3) how do =
handle=20
  customer FCS retention when doing this MAC translation<BR>stuff=20
  ??<BR></FONT><BR><FONT face=3DMonospace,Courier>&gt;<BR>&gt; 802.1Q =
bridge=20
  forwards Ethernet frames using two dataplane tables<BR>&gt; - MAC =
forwarding=20
  table and VLAN forwarding table.<BR>&gt; Bridge control protocols, =
such as=20
  GARP, GVRP, GMRP,<BR>&gt; manipulate one of the two dataplane=20
  entities.<BR></FONT><BR><FONT face=3DMonospace,Courier>This is not =
correct.=20
  Bridges don't have different databases for MAC<BR>forwarding and VLAN=20
  forwarding. They have filtering datebase(s) with<BR>corresponding IDs =
(FIDs).=20
  VLAN IDs get mapped to FIDs based on operation<BR>mode (IVL versus =
SVL). Then=20
  once a filtering database is identified,<BR>then a MAC address lookup =
is=20
  performed for forwarding. Bridge control<BR>protocols use a designated =
MAC=20
  addressed and based on these MAC<BR>addressed, the bridge knows how to =
process=20
  the frame.<BR></FONT><BR><FONT face=3DMonospace,Courier>&gt;<BR>&gt; =
Similarly,=20
  option 1 and 3 are about which one of two<BR>&gt; dataplane =
entities<BR>&gt;=20
  GMPLS protocol should control on behalf of bridge control =
protocols.<BR>&gt;=20
  The two proposals do not intend to modify bridge behavior<BR>&gt; =
seriously,=20
  such as MAC learning, aging, filtering.<BR>&gt; Therefore, the =
approaches 1=20
  and 3 are in the scope of CCAMP.<BR></FONT><BR><FONT =
face=3DMonospace,Courier>If=20
  that's the intention, you may find out soon you get more than =
what<BR>you=20
  asked for :-)<BR></FONT><BR><FONT =
face=3DMonospace,Courier>&gt;<BR>&gt; (% note=20
  however, I would regard implementing label swapping<BR>&gt; function =
is=20
  acceptable change considering the Internal Sublayer<BR>&gt; design of =
802.1D=20
  bridge.)<BR>&gt;<BR></FONT><BR><FONT face=3DMonospace,Courier>The only =
way of=20
  doing this is using VID translation table specified in<BR>IEEE 802.1ad =
which=20
  requires new data-plane functionality and thus<BR>existing bridges =
cannot be=20
  used !!<BR></FONT><BR><FONT face=3DMonospace,Courier>Also if going the =
route of=20
  tag swapping, you may consider using IEEE<BR>802.1ah. As the editor of =
.1ah, I=20
  can go over the details when I get a<BR>chance.<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>&gt;<BR>&gt; However, option 2 is about what =
TPID code=20
  we will<BR>&gt; choose to implement new switching function.<BR>&gt; =
The switch=20
  of this implementation should have new hardware<BR>&gt; design in =
addition to=20
  normal bride hardware.<BR>&gt; I think such proposal as option 2 is =
out of=20
  CCAMP scope.<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>Yes.<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>&gt;<BR>&gt; Overall objective is improving=20
  scalability, traffic engineering (TE)<BR>&gt; characteristics of 802.1 =
bridge=20
  that it can be reliable, manageable<BR>&gt; enough to replace some =
core=20
  routers.<BR></FONT><BR><FONT face=3DMonospace,Courier>Easier said than =
done=20
  :-)<BR></FONT><BR><FONT face=3DMonospace,Courier>&gt; The switching =
technique=20
  you mentioned above, such as<BR>&gt; Ethernet over MPLS as defined by =
PWE3 and=20
  L2VPN,<BR>&gt; are all actually router based technology, however =
this<BR>&gt;=20
  work is based on simple bridge architecture.<BR>&gt; =
Cost-effectiveness is the=20
  key differentiator.<BR>&gt;<BR></FONT><BR><FONT =
face=3DMonospace,Courier>The=20
  devils are in the details and once you worked out the details, =
you<BR>will see=20
  the issues.<BR></FONT><BR><FONT face=3DMonospace,Courier>&gt;<BR>&gt; =
In access=20
  or enterprise network, capability of providing end-to-end<BR>&gt; =
L2-LSP will=20
  enable service providers policing, measuring, charging<BR>&gt; =
application=20
  flows using Ethernet based network. This will eventually<BR>&gt; =
improve=20
  income structure and introduce new session based commercial<BR>&gt; =
service. I=20
  have been discussing this aspect in mail thread of<BR>&gt; title =
'End-to-end=20
  L2-LSP'. &nbsp;Please read the mail thread and comment<BR>&gt; on the=20
  discussion.<BR>&gt;<BR>&gt;<BR>&gt; &gt;You mentioned to use the MAC =
address=20
  or part of it as a label.<BR>&gt; &gt;The TRILL working group is =
defining=20
  shortest path routing<BR>&gt; for Ethernet.<BR>&gt; &gt;How would this =
fit=20
  together?<BR>&gt;<BR>&gt;<BR>&gt; TRILL employs new encapsulation =
layer=20
  outside of Ethernet frames.<BR>&gt; However in my proposal of =
option-3, I=20
  simply use the Ethernet header<BR>&gt; to encode GMPLS =
label.<BR>&gt;<BR>&gt;=20
  The overall format of rbridge is<BR>&gt; [Ethernet][r-tag][Ethernet][=20
  data..]<BR>&gt; It is not LSP based technology but a connectionless =
routing=20
  bridge.<BR>&gt; TTL count is very important in rbridge because frames =
are=20
  routed<BR>&gt; hop-by-hop and it may loop.<BR>&gt;<BR>&gt; Whereas in =
option-3=20
  above, Ethernet frames that have certain<BR>&gt; OUI prefix in MAC =
address are=20
  forwarded via a path that<BR>&gt; GMPLS protocol has configured on MAC =

  forwarding table.<BR>&gt;<BR></FONT><BR><FONT =
face=3DMonospace,Courier>How does=20
  the redundancy work in here. Are you using bridge protocol =
in<BR>conjunction=20
  with GMPLS protocol. If you do, then there are bunch of<BR>issues. If =
you=20
  don't, then what is it used and how does it interact with<BR>bridging=20
  protocols ??<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>-Ali<BR></FONT><BR><BR><FONT=20
  face=3DMonospace,Courier>&gt;<BR>&gt; Thanks<BR>&gt;<BR>&gt;=20
  Jaihyung<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; -----?? ???-----<BR>&gt; ?? =
??:=20
  "Heiles Juergen" &lt;[email-masked]&gt;<BR>&gt; ?? ??: =
2005-07-25=20
  ?? 6:44:34<BR>&gt; ?? ??: "CHO, JAI HYUNG" =
&lt;[email-masked]&gt;,=20
  "Heiles<BR>&gt; Juergen" &lt;[email-masked]&gt;,=20
  "[email-masked]"<BR>&gt; &lt;[email-masked]&gt;<BR>&gt; ??: =
"[email-masked]"=20
  &lt;[email-masked]&gt;<BR>&gt; ??: RE: Frameformat in a l2cs gmpls =

  rnvironment.<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; =
Dear=20
  Jaihyung,<BR>&gt;<BR>&gt; you mention several options that could be =
used as a=20
  label.<BR>&gt; Most of them have strong impacts on the data plane =
and<BR>&gt;=20
  introduce new layer networks. Is this in the scope of CCAMP?<BR>&gt; =
What is=20
  the goal, to introduce a control plane for a existing<BR>&gt; L2 =
technology or=20
  introduce a new L2 technology? What would be<BR>&gt; the benefit of =
such a new=20
  L2 co switching technology compared<BR>&gt; to Ethernet over MPLS as =
defined=20
  by PWE3 and L2VPN?<BR>&gt; You mentioned to use the MAC address or =
part of it=20
  as a<BR>&gt; label. The TRILL working group is defining shortest =
path<BR>&gt;=20
  routing for Ethernet. How would this fit =
together?<BR>&gt;<BR>&gt;<BR>&gt;=20
  Regards<BR>&gt;<BR>&gt;=20
  Juergen<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; &gt; =
-----Original=20
  Message-----<BR>&gt; &gt; From: CHO, JAI HYUNG=20
  [mailto:[email-masked]]<BR>&gt; &gt; Sent: Saturday, July 23, =
2005 6:19=20
  AM<BR>&gt; &gt; To: Heiles Juergen; [email-masked]<BR>&gt; &gt; Cc:=20
  [email-masked]<BR>&gt; &gt; Subject: RE: Frameformat in a l2cs =
gmpls=20
  rnvironment.<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; Dear Juergen, Par =
and=20
  all,<BR>&gt; &gt;<BR>&gt; &gt; The proposed framework of L2SC was not =
intended=20
  to suggest<BR>&gt; &gt; any specific solution. It is still an open=20
  question.<BR>&gt; &gt; As Adrian noted, it only aims to present=20
  requirements<BR>&gt; &gt; as in scenarios that may drive people toward =
next=20
  step in many<BR>&gt; &gt; viable solutions.<BR>&gt; &gt;<BR>&gt; &gt; =
In fact,=20
  there are other options we may also consider for L2<BR>&gt; &gt; label =

  encoding.<BR>&gt; &gt; IEEE 802.1 Ethernet bridges forward frames =
based on=20
  48bits of<BR>&gt; &gt; MAC address,<BR>&gt; &gt; and additionally =
using VLAN=20
  tag.<BR>&gt; &gt;<BR>&gt; &gt; When the purpose of GMPLS control over =
Ethernet=20
  is not to<BR>&gt; &gt; create new dataplane<BR>&gt; &gt; but to =
utilize IEEE=20
  802.1 bridge architecture, we may<BR>&gt; consider using<BR>&gt; &gt; =
one of=20
  the two forwarding methods, MAC forwarding or VLAN<BR>&gt; =
forwarding.<BR>&gt;=20
  &gt; (and perhaps any other combination of fields in MAC, but =
I'll<BR>&gt;=20
  &gt; not discuss it)<BR>&gt; &gt;<BR>&gt; &gt; Use of VLAN ID for =
label=20
  encoding may automate VLAN configuration<BR>&gt; &gt; using IP =
protocols.=20
  However, GMPLS protocol cannot use the<BR>&gt; &gt; field =
exclusively<BR>&gt;=20
  &gt; because public/private operators already use VLAN for =
various<BR>&gt;=20
  &gt; purpose.<BR>&gt; &gt; There is a potential conflict with existing =
use of=20
  VLAN and<BR>&gt; &gt; GMPLS use of VLAN label.<BR>&gt; &gt; =
Furthermore,=20
  scalability of VLAN ID has been frequently noted<BR>&gt; &gt; as=20
  weakness<BR>&gt; &gt; because the size of VLAN ID is at most 4096=20
  (12bit).<BR>&gt; &gt;<BR>&gt; &gt; The scalability may be improved if =
the=20
  scope of VLAN label is<BR>&gt; &gt; confined to<BR>&gt; &gt; =
link-local, and=20
  some additional swapping function of VLAN ID<BR>&gt; &gt; is =
introduced=20
  in<BR>&gt; &gt; Internal Sublayer [802.1D] of GMPLS implemented=20
  switch.<BR>&gt; &gt; However, this will only be effective when the=20
  configuration<BR>&gt; &gt; of network<BR>&gt; &gt; is mesh structure =
that=20
  multiple LSP paths exist. If the<BR>&gt; &gt; configuration of =
network<BR>&gt;=20
  &gt; is star or tree shape, as normal configuration of access =
network,<BR>&gt;=20
  &gt; LSPs concentrate in root node and total number of<BR>&gt; &gt; =
LSPs that=20
  the network can hold still be limited by available<BR>&gt; &gt; label=20
  space<BR>&gt; &gt; at a few root links.<BR>&gt; &gt;<BR>&gt; &gt; For =
these=20
  reasons, I do not think any form of VLAN ID label is<BR>&gt; &gt; an=20
  appropriate choice for layer-2 label encoding.<BR>&gt; &gt;<BR>&gt; =
&gt; There=20
  are some other proposals assuming new assignment of Ethernet<BR>&gt; =
&gt;=20
  Length/Type value (e.g. new TPID in VLAN tag) and re-definition =
of<BR>&gt;=20
  &gt; information fields placed between 802.3 MAC header and IP =
packet.<BR>&gt;=20
  &gt; In this case, only the format of VLAN tag or extended VLAN =
tag<BR>&gt;=20
  &gt; is borrowed, however, inside the switching hardware, the<BR>&gt; =
&gt;=20
  filter and relay,<BR>&gt; &gt; etc. are totally different new =
dataplane=20
  switch.<BR>&gt; &gt;<BR>&gt; &gt; I do not see such approach is a =
GMPLS=20
  implementation for Ethernet<BR>&gt; &gt; because the core switching =
technique=20
  is not 802.1 Ethernet<BR>&gt; &gt; bridge at all.<BR>&gt; &gt;<BR>&gt; =
&gt;=20
  The other option we may consider is using MAC address filed<BR>&gt; as =

  below.<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;=20
  +-------+-------+-------+-------+-------+-------+<BR>&gt; &gt; | 1byte =
| 2byte=20
  | 3byte | 4byte | 5byte | 6byte |<BR>&gt; &gt;=20
  +-------+-------+-------+-------+-------+-------+<BR>&gt; &gt;=20
  +-----------------------+-----------------------+<BR>&gt; &gt; | =
&nbsp;OUI=20
  Prefix (=3DGMPLS) &nbsp;| &nbsp; DA-label (24bit) &nbsp; =
&nbsp;|<BR>&gt; &gt;=20
  +-----------------------+-----------------------+<BR>&gt; &gt; | =
&nbsp;OUI=20
  Prefix (=3DGMPLS) &nbsp;| &nbsp; SA-label (24bit) &nbsp; =
&nbsp;|<BR>&gt; &gt;=20
  +---------------+-------+-----------------------+<BR>&gt; &gt; | =
Length/Type=20
  &nbsp; |<BR>&gt; &gt; +---------------+<BR>&gt; &gt;<BR>&gt; =
&gt;<BR>&gt; &gt;=20
  IEEE is designated by the ISO Council to act as the<BR>&gt; &gt; =
registration=20
  authority<BR>&gt; &gt; for the higher three-octet of OUI number in the =
MAC=20
  address<BR>&gt; &gt; to be used by manufacturer. Ethernet manufacturer =
may=20
  generate<BR>&gt; &gt; global unique MAC address using the OUI prefix =
and=20
  address block of<BR>&gt; &gt; lower three-octet (24bit). Taking =
advantage of=20
  the<BR>&gt; addressing scheme,<BR>&gt; &gt; GMPLS may use the lower=20
  three-octet exclusively if a unique<BR>&gt; &gt; OUI number<BR>&gt; =
&gt; is=20
  reserved for the protocol. With this labeling scheme, GMPLS =
will<BR>&gt; &gt;=20
  control MAC forwarding entry, not VLAN table.<BR>&gt; &gt;<BR>&gt; =
&gt; All=20
  Ethernet frames controlled by GMPLS will have identical<BR>&gt; &gt; =
OUI=20
  number<BR>&gt; &gt; that they can easily be distinguished from other =
Ethernet=20
  frames.<BR>&gt; &gt; In principle, the label lookup hardware is =
identical to=20
  MAC lookup<BR>&gt; &gt; hardware in this labeling scheme. Therefore =
GMPLS=20
  implemented<BR>&gt; &gt; switch may still function as normal Ethernet =
bridge=20
  to the frames<BR>&gt; &gt; that OUI number is not GMPLS. This also =
facilitates=20
  GMPLS<BR>&gt; implemented<BR>&gt; &gt; switches being deployed in =
operating=20
  Ethernet with minimum<BR>&gt; &gt; service disruption.<BR>&gt; =
&gt;<BR>&gt;=20
  &gt; Note also that above proposed label encoding method is=20
  transparent<BR>&gt; &gt; to the use of Ethernet Length/Type field. =
End-user=20
  device may use<BR>&gt; &gt; the Length/Type field as defined in IEEE =
802.3=20
  protocol.<BR>&gt; &gt; It also allows network operators configure VLAN =
for=20
  their own<BR>&gt; &gt; purpose.<BR>&gt; &gt; When IEEE 802.1p is used =
in=20
  conjunction with L2-LSP, the priority<BR>&gt; &gt; field of VLAN tag =
can also=20
  be used for imposing consistent TE<BR>&gt; &gt; policy in<BR>&gt; &gt; =
legacy=20
  switches and GMPLS switches.<BR>&gt; &gt;<BR>&gt; &gt; Any way, my =
conclusion=20
  is, there are other options we may consider,<BR>&gt; &gt; and this =
issue is=20
  still open to discuss.<BR>&gt; &gt;<BR>&gt; &gt; Thanks,<BR>&gt; =
&gt;<BR>&gt;=20
  &gt; Sincerely,<BR>&gt; &gt;<BR>&gt; &gt; Jaihyung<BR>&gt; =
&gt;<BR>&gt;=20
  &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; -----??=20
  ???-----<BR>&gt; &gt; ?? ??: "Heiles Juergen"=20
  &lt;[email-masked]&gt;<BR>&gt; &gt; ?? ??: 2005-07-22 ??=20
  10:23:43<BR>&gt; &gt; ?? ??: "Loa Andersson" &lt;[email-masked]&gt;,=20
  "[email-masked]"<BR>&gt; &gt; =
&lt;[email-masked]&gt;<BR>&gt;=20
  &gt; ??: "[email-masked]" &lt;[email-masked]&gt;, =
"[email-masked]"<BR>&gt;=20
  &gt; &lt;[email-masked]&gt;<BR>&gt; &gt; ??: RE: Frameformat in a =
l2cs=20
  gmpls rnvironment.<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; =
&gt;<BR>&gt;=20
  &gt;<BR>&gt; &gt;<BR>&gt; &gt; Loa,<BR>&gt; &gt;<BR>&gt; &gt; I =
interpret the=20
  ID as a proposal to use GMPLS for VLAN setup.<BR>&gt; &gt; So GMPLS =
and VLAN=20
  to not compete. The VLAN is at the data<BR>&gt; &gt; plane and GMPLS =
at the=20
  control plane. The question is how and<BR>&gt; &gt; should different =
control=20
  plane techniques like GMPLS and<BR>&gt; &gt; (GVRP and STB) work=20
  together?<BR>&gt; &gt;<BR>&gt; &gt; Regards<BR>&gt; &gt;<BR>&gt; &gt;=20
  Juergen<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; &gt; -----Original=20
  Message-----<BR>&gt; &gt; &gt; From: [email-masked]<BR>&gt; =
&gt;=20
  &gt; [mailto:[email-masked]] On Behalf Of Loa =
Andersson<BR>&gt; &gt;=20
  &gt; Sent: Friday, July 22, 2005 2:53 PM<BR>&gt; &gt; &gt; To:=20
  [email-masked]<BR>&gt; &gt; &gt; Cc: [email-masked];=20
  [email-masked]<BR>&gt; &gt; &gt; Subject: Re: Frameformat in a =
l2cs gmpls=20
  rnvironment.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Richard,<BR>&gt; &gt; =

  &gt;<BR>&gt; &gt; &gt; I agree to most of this. Since we have doubts =
about the=20
  viability<BR>&gt; &gt; &gt; of taking GMPLS all the way to end-user or =

  enterprise I think it<BR>&gt; &gt; &gt; would be good, from a wg =
perspective,=20
  if we agreed to solve the<BR>&gt; &gt; &gt; core network problems=20
  first.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Do you have any comment on =
the=20
  requirement to run both VLANs and<BR>&gt; &gt; &gt; GMPLS on the same=20
  switch?<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; /Loa<BR>&gt; &gt; =
&gt;<BR>&gt;=20
  &gt; &gt; [email-masked] wrote:<BR>&gt; &gt; &gt; &gt; =
Regardless of=20
  whether or not a switch is directly connected<BR>&gt; &gt; &gt; =
&nbsp;&gt; to=20
  hosts, it must be able to forward packets using the<BR>&gt; &gt; &gt;=20
  connectionless<BR>&gt; &gt; &gt; &nbsp;&gt; Ethernet data plane. This =
is due=20
  to the fundamental<BR>&gt; &gt; &gt; requirement that<BR>&gt; &gt; =
&gt;=20
  &nbsp;&gt; for GMPLS switches to be able to exchange control<BR>&gt; =
&gt;=20
  information with<BR>&gt; &gt; &gt; &nbsp;&gt; each other, a data plane =
for=20
  control traffic must be present.<BR>&gt; &gt; &gt; &nbsp;&gt; This is =
akin to=20
  using the IP data plane for MPLS<BR>&gt; &gt; signalling in an<BR>&gt; =
&gt;=20
  &gt; &nbsp;&gt; IP/MPLS network. An alternative would be to use a=20
  static<BR>&gt; &gt; reserved<BR>&gt; &gt; &gt; &nbsp;&gt; L2-LSP for =
control=20
  traffic in the same way that reserved<BR>&gt; &gt; VPI/VCIs<BR>&gt; =
&gt; &gt;=20
  &nbsp;&gt; are used for PNNI signalling in ATM.<BR>&gt; &gt; &gt; =
&gt;<BR>&gt;=20
  &gt; &gt; &gt; Regarding connecting hosts to GMPLS switches, I<BR>&gt; =

  personally don't<BR>&gt; &gt; &gt; &nbsp;&gt; think extending L2-LSPs =
into the=20
  enterprise/home network is<BR>&gt; &gt; &gt; &nbsp;&gt; commercially =
viable.=20
  However, if you do want to use<BR>&gt; &gt; GMPLS switches<BR>&gt; =
&gt; &gt;=20
  &nbsp;&gt; in the home/enterprise network and for some reason<BR>&gt; =
don't=20
  want to<BR>&gt; &gt; &gt; &nbsp;&gt; extend L2-LSPs down to the host =
then you=20
  will not be<BR>&gt; performing<BR>&gt; &gt; &gt; &nbsp;&gt; normal =
Ethernet=20
  Mac address switching anyway. Instead you will<BR>&gt; &gt; &gt; =
&nbsp;&gt;=20
  need some kind of policy on the switch that maps<BR>&gt;=20
  connectionless</FONT><BR><FONT face=3DMonospace,Courier>&gt; &gt; &gt; =

  &nbsp;&gt; Ethernet packets (e.g. based on MAC src/dest, 802.1p,=20
  </FONT><BR><FONT face=3DMonospace,Courier>&gt; VLAN) to a<BR>&gt; &gt; =
&gt;=20
  &nbsp;&gt; L2-LSP. This is because multiple L2-LSPs to the =
same<BR>&gt;=20
  destination<BR>&gt; &gt; &gt; &nbsp;&gt; (e.g. a gateway router) may =
exist for=20
  different services/flows<BR>&gt; &gt; &gt; &nbsp;&gt; (e.g. video =
download,=20
  VoIP call, etc.).<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt;=20
  Regards,<BR>&gt; &gt; &gt; &gt; Richard<BR>&gt; &gt; &gt; &gt;<BR>&gt; =
&gt;=20
  &gt; &gt;<BR>&gt; &gt; &gt; &gt;&gt;-----Original Message-----<BR>&gt; =
&gt;=20
  &gt; &gt;&gt;From: [email-masked]<BR>&gt; &gt;=20
  [mailto:[email-masked]]On<BR>&gt; &gt; &gt; &gt;&gt;Behalf =
Of Par=20
  Mattsson<BR>&gt; &gt; &gt; &gt;&gt;Sent: 22 July 2005 11:42<BR>&gt; =
&gt; &gt;=20
  &gt;&gt;To: Loa Andersson<BR>&gt; &gt; &gt; &gt;&gt;Cc:=20
  [email-masked]<BR>&gt; &gt; &gt; &gt;&gt;Subject: Re: Frameformat =
in a=20
  l2cs gmpls rnvironment.<BR>&gt; &gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt;=20
  &gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;&gt;Per =
and=20
  Dimitri,<BR>&gt; &gt; &gt; &gt;&gt;&gt;<BR>&gt; &gt; &gt; =
&gt;&gt;&gt;I would=20
  like to come down stronger than that, for me it is<BR>&gt; &gt; &gt;=20
  &gt;&gt;&gt;a very strong requirement that the same switch can =
handle<BR>&gt;=20
  &gt; &gt; &gt;&gt;&gt;both VLANs and GMPLs trafic correctly. I can't =
dsee how=20
  that<BR>&gt; &gt; &gt; &gt;&gt;&gt;could be done if using the VLAN =
tpid to=20
  indicate GMPLS<BR>&gt; &gt; &gt; &gt;&gt;&gt;traffic.<BR>&gt; &gt; =
&gt;=20
  &gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;If you ever want that same switch =
to handle=20
  traffic for a<BR>&gt; &gt; directly<BR>&gt; &gt; &gt; =
&gt;&gt;connected=20
  &nbsp;host (not to uncommen) you would want that to<BR>&gt; &gt; use=20
  normal<BR>&gt; &gt; &gt; &gt;&gt;ethernet macaddress switching. So of =
course=20
  you do not want<BR>&gt; &gt; &gt; to have to<BR>&gt; &gt; &gt; =
&gt;&gt;choose=20
  between vlan and gmpls, you would want both at the<BR>&gt; &gt; same=20
  time.<BR>&gt; &gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt; =
&gt;&gt;/per<BR>&gt; &gt;=20
  &gt; &gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt; =
&gt;&gt;<BR>&gt;=20
  &gt; &gt; &gt;&gt;&gt;/Loa<BR>&gt; &gt; &gt; &gt;&gt;&gt;<BR>&gt; &gt; =
&gt;=20
  &gt;&gt;&gt;Par Mattsson wrote:<BR>&gt; &gt; &gt; &gt;&gt;&gt;<BR>&gt; =
&gt;=20
  &gt; &gt;&gt;&gt;&gt;&gt;hi par, one of the possibilities that has =
been=20
  considered<BR>&gt; &gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;to =
cope=20
  with<BR>&gt; &gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt; =
&gt;&gt;&gt;&gt;&gt;this=20
  requirement is to use a dedicated TPID for the<BR>&gt; &gt; &gt;=20
  &gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;Ethernet labeled<BR>&gt; &gt; &gt;=20
  &gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;&gt;&gt;&gt;frames; this would =
allow=20
  differentiated processing with<BR>&gt; &gt; &gt; non-labeled<BR>&gt; =
&gt; &gt;=20
  &gt;&gt;&gt;&gt;&gt;framesthanks.<BR>&gt; &gt; &gt; =
&gt;&gt;&gt;&gt;<BR>&gt;=20
  &gt; &gt; &gt;&gt;&gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;&gt;&gt;That =
seems to=20
  make more sence. If that frame is to be<BR>&gt; &gt; sized like =
a<BR>&gt; &gt;=20
  &gt; &gt;&gt;&gt;&gt;802.1q<BR>&gt; &gt; &gt; &gt;&gt;&gt;&gt;frame. =
There is=20
  not that much space left to a label. Or is<BR>&gt; &gt; &gt; =
&gt;&gt;<BR>&gt;=20
  &gt; &gt; &gt;&gt;the demand to<BR>&gt; &gt; &gt; &gt;&gt;<BR>&gt; =
&gt; &gt;=20
  &gt;&gt;&gt;&gt;use jumboframes ?<BR>&gt; &gt; &gt; =
&gt;&gt;&gt;&gt;Has there=20
  been any discussion on labelstacking, and<BR>&gt; &gt; &gt; mainly =
where=20
  to<BR>&gt; &gt; &gt; &gt;&gt;&gt;&gt;place<BR>&gt; &gt; &gt;=20
  &gt;&gt;&gt;&gt;the information?<BR>&gt; &gt; &gt; =
&gt;&gt;&gt;&gt;<BR>&gt;=20
  &gt; &gt; &gt;&gt;&gt;&gt;Regards.<BR>&gt; &gt; &gt;=20
  &gt;&gt;&gt;&gt;Per<BR>&gt; &gt; &gt; &gt;&gt;&gt;&gt;<BR>&gt; &gt; =
&gt;=20
  &gt;&gt;&gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;&gt;&gt;<BR>&gt; &gt; &gt;=20
  &gt;&gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;&gt;<BR>&gt; &gt; &gt;=20
  &gt;&gt;&gt;--<BR>&gt; &gt; &gt; &gt;&gt;&gt;Loa Andersson<BR>&gt; =
&gt; &gt;=20
  &gt;&gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;&gt;Principal Networking=20
  Architect<BR>&gt; &gt; &gt; &gt;&gt;&gt;Acreo AB &nbsp; &nbsp; &nbsp; =
&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; phone:=20
  &nbsp;+46 8 632 77 14<BR>&gt; &gt; &gt; &gt;&gt;&gt;Isafjordsgatan 22 =
&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;mobile: +46 739 =
81 21=20
  64<BR>&gt; &gt; &gt; &gt;&gt;&gt;Kista, Sweden &nbsp; &nbsp; &nbsp; =
&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;email:<BR>&gt; &gt;=20
  [email-masked]<BR>&gt; &gt; &gt; &gt;&gt;&gt; &nbsp; &nbsp; =
&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;[email-masked]<BR>&gt; &gt;=20
  &gt; &gt;&gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt;=20
  &gt;&gt;<BR>&gt; &gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; =
&gt;=20
  &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; --<BR>&gt; &gt; &gt; Loa=20
  Andersson<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Principal Networking=20
  Architect<BR>&gt; &gt; &gt; Acreo AB &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; phone: &nbsp;+46 8 =
632 77=20
  14<BR>&gt; &gt; &gt; Isafjordsgatan 22 &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp;mobile: +46 739 81 21 64<BR>&gt; &gt; &gt; =
Kista,=20
  Sweden &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
  &nbsp;email: &nbsp;[email-masked]<BR>&gt; &gt; &gt; &nbsp; =
&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=20
  [email-masked]<BR>&gt; &gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; =
&gt;<BR>&gt;=20
  &gt;<BR>&gt;<BR>&gt;<BR>&gt;</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C59273.E41176C9--

Delivery-date: Wed, 27 Jul 2005 04:29:23 +0000
Date: Wed, 27 Jul 2005 13:28:20 +0900
To: [email-masked], [email-masked]
From: Wataru Imajuku <[email-masked]>
Subject: Re: LCAS and GMPLS

Hi, Mr. Dueser and all

Best Regards,
Wataru

Hi,

Delivery-date: Wed, 27 Jul 2005 03:02:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Date: Tue, 26 Jul 2005 20:00:53 -0700
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

=20
Jaihyung,

Please refer to my comments inline ...

[snip]
> >=20
> >> 3. use lower 3 bytes of MAC address for L2 label encoding.
> >=20
> >This approach has several issues:
> >1) how does MAC addresses get distributed among the bridges ?=20
> >How does this distribution works during a link or node failure ?=20
> >How does it recover from a link or node failure ?
> >=20
> =20
> =20
> Ali,
> The questions are really implementation dependent.
> Can we defer this discussion after Paris meeting?
> However, I see the solution will not be so different than=20
> what RSVP-TE has been done for other transport network.
>=20

These questions are not implementation dependent. IEEE bridges have a
well established procedures for handling link and node failures based on
RSTP/MSTP and "independent" interaction between these procedures and
RSVP-TE is questionable at best. If you think this is not the case, then
I encourage you to specify how this interaction works. =20

=20
> =20
> >2) Will you assign a separate provider MAC for each customer MAC.=20
> >If so, then how do you address MAC scalability.=20
> >If not, then how do you take care of 1-to-N mapping between provider=20
> >MAC address and customer MAC addresses and how do you handle=20
> multipoint=20
> >connections.
> =20
> =20
> I think you are asking the issue of L2 label stacking or LSP=20
> aggregation, or perhaps some VPN application similar to 802.1ad.
> There are some opinions on whether label stacking is=20
> necessary in L2SC domain. This is actually the question=20
> Adrian keep asking us.

Since you are using provider MAC address as a label, then by label
stacking, I presume you mean encapsulating customers MAC addresses
inside the provider MAC. If you want to go to that extend, then why not
just simply use IEEE 802.1ah that provide both stacking of MAC addresses
as well as it provides you with a 20-bit tag for service instance
identification.

> I personally think that we can achieve LSP aggregation with=20
> the aid of MPLS shim label, however I think this is too=20
> premature discussion.
> All I can say at the moment is, lower 3 octet of MAC address=20
> gives us 16M size of label space and this is enough to=20
> implement link-local, site-local or even some domain-local LSPs.
> Between the L2-LSP boundary, it needs further discussion.
>=20
It is one thing to have the address space, it is another thing to have
proper management and control protocols to manage that space. The big
question is what type of control and management protocols you intend to
use for that space and how it interacts with the existing IEEE control
and management protocols. Also, if it is one-to-one mapping, then we are
back to square one regarding MAC address scalability.
=20
> =20
> >=20
> >3) how do handle customer FCS retention when doing this MAC=20
> translation=20
> >stuff ??
> >=20
> =20
> =20
>   I haven't seen any application that requires retention of=20
> original FCS image.
> 802.1D specification recommends recalculation of FCS when=20
> there is any change in MAC. I see no problem if FCS is=20
> recalculated at the label swapping switch.

Please refer to all the discussions on the PWE3 mailing list regarding
FCS retention. There are certain applications that require it and that's
why there is a draft for it.

> =20
> =20
> >> 802.1Q bridge forwards Ethernet frames using two dataplane tables
> >> - MAC forwarding table and VLAN forwarding table.
> >> Bridge control protocols, such as GARP, GVRP, GMRP,=20
> manipulate one of=20
> >> the two dataplane entities.
> >=20
> >This is not correct. Bridges don't have different databases for MAC=20
> >forwarding and VLAN forwarding. They have filtering datebase(s) with=20
> >corresponding IDs (FIDs). VLAN IDs get mapped to FIDs based on=20
> >operation mode (IVL versus SVL). Then once a filtering database is=20
> >identified, then a MAC address lookup is performed for forwarding.=20
> >Bridge control protocols use a designated MAC addressed and based on=20
> >these MAC addressed, the bridge knows how to process the frame.
> =20
> =20
> oh, come on .
> I explained it in conceptual level and you re-described it in=20
> implementation level.  The contextual meaning is same.
> I believe you don't deny the existence of two types of=20
> filtering databases, for MAC and VID, and the control of GARP=20
> over these databases.=20
> This is unnecessary argument, I think.
> =20

No, I didn't describe the implementation but instead I described it as
specified in .1D and .1Q. However, I see what you were trying to say and
I think it was just a poor choice of words.

=20
[snip]=20
> =20
> If we define the scope of L2 label as site-local or=20
> domain-local, we don't need such label swapping operation.
> However, if we want link-local label, and find out that it is=20
> very useful
> (* actually I do think it'll be very useful *), I think we=20
> need to consult such modification with IEEE.
> Technically speaking, I don't think replacing the label value=20
> after normal MAC lookup will serious change hardware architecture.
> Also, it doesn't break conformance rule.
> Did any 802.1 spec. say that input MAC must be identical to=20
> output MAC?

There is no MAC address swapping or translation in .1D, .1Q, or its
future standards. If there is MAC address translation, then you can run
into quite a few unwanted side affects.

[snip]
> =20
> =20
> [snip]
> >=20
> >How does the redundancy work in here. Are you using bridge=20
> protocol in
> >conjunction with GMPLS protocol. If you do, then there are bunch of
> >issues.=20
> =20
> =20
> Yes I do.=20
> I intend GMPLS implemented switches being deployed in=20
> operating network
> as normal Ethernet switch that perform bridge protocols.
> When they detect (or snoop) RSVP-TE message, they establish L2-LSP
> and selectively forward those GMPLS prefixed frames via the L2-LSP.
> The message path that RSVP-TE is exchanged, thus L2-LSPs are=20
> established, does not necessarily be identical to spanning tree path
> because L2-LSPs can be established via shortest path.
> I welcome further discussion on this issue, but I hope to continue it=20
> after Paris meeting, if you may.

If RSVP-TE traffic uses link-state based protocols and bridged traffic
uses distance-based protocols (e.g., RSTP) and these traffic operate
independently from each other and both types of traffic come through the
same port, then how does a standard IEEE bridge know how to discern
these packets and which packets to take action on ? - e.g., what IEEE
procedures do you recommend to be used ?? If you are talking about
different physical ports, then you are talking about different
independent networks with different set of links and topology for each
which is not the intent here.

Cheers,
Ali =20

> =20
> =20
> Thanks
> =20
> Jaihyung
> =20
>=20
> -----?? ???-----=20
> ?? ??: "Ali Sajassi (sajassi)" <[email-masked]>=20
> ?? ??: 2005-07-26 ?? 8:13:56=20
> ?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles=20
> Juergen" <[email-masked]>, "[email-masked]"=20
> <[email-masked]>=20
> ??: "[email-masked]" <[email-masked]>=20
> ??: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/=20
> GMPLS Ethernet=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> Jaihyung,=20
>=20
> It seems to me that your primary objective is to use the existing=20
> Ethernet switches with new control plane (GMPLS) to setup TE=20
> paths for=20
> different applications. And you mentioned three approaches for doing=20
> this in your email. However, all three of them have issues=20
> and are not=20
> viable. Lets go over them ...=20
>=20
> >=20
> > In below mail, I discussed about three proposed approaches.=20
> > =20
> > =20
> > 1. using VLAN tag as it is for L2 label encoding.=20
>=20
> As you know this approach has scalability issue and you are=20
> limited to=20
> 4K services in the network and if you try to use the upcoming IEEE=20
> 802.1ad standard to make VLANs, interface specific, then you=20
> will need=20
> new switches and not existing Ethernet switches. Even if you=20
> use these=20
> newer switches, you will still be limited to 4K services per=20
> interface=20
> and it would defeat the objective of using existing switches.=20
>=20
> >=20
> > 2. defining new protocol ID (TPID) and borrow VLAN tag format,=20
> > ?or extended VLAN tag to implement label swapping.=20
> >=20
>=20
> This approach requires new data plane functionality to be implemented=20
> (which defeats the objective of using existing switches).=20
>=20
> > 3. use lower 3 bytes of MAC address for L2 label encoding.=20
> > =20
>=20
> This approach has several issues:=20
> 1) how does MAC addresses get distributed among the bridges ?=20
> How does=20
> this distribution works during a link or node failure ? How does it=20
> recover from a link or node failure ?=20
>=20
> 2) Will you assign a separate provider MAC for each customer=20
> MAC. If so,=20
> then how do you address MAC scalability. If not, then how do you take=20
> care of 1-to-N mapping between provider MAC address and customer MAC=20
> addresses and how do you handle multipoint connections.=20
>=20
> 3) how do handle customer FCS retention when doing this MAC=20
> translation=20
> stuff ??=20
>=20
> >=20
> > 802.1Q bridge forwards Ethernet frames using two dataplane tables=20
> > - MAC forwarding table and VLAN forwarding table.=20
> > Bridge control protocols, such as GARP, GVRP, GMRP,=20
> > manipulate one of the two dataplane entities.=20
>=20
> This is not correct. Bridges don't have different databases for MAC=20
> forwarding and VLAN forwarding. They have filtering datebase(s) with=20
> corresponding IDs (FIDs). VLAN IDs get mapped to FIDs based=20
> on operation=20
> mode (IVL versus SVL). Then once a filtering database is identified,=20
> then a MAC address lookup is performed for forwarding. Bridge control=20
> protocols use a designated MAC addressed and based on these MAC=20
> addressed, the bridge knows how to process the frame.=20
>=20
> >=20
> > Similarly, option 1 and 3 are about which one of two=20
> > dataplane entities=20
> > GMPLS protocol should control on behalf of bridge control=20
> protocols.=20
> > The two proposals do not intend to modify bridge behavior=20
> > seriously, such as MAC learning, aging, filtering.=20
> > Therefore, the approaches 1 and 3 are in the scope of CCAMP.=20
>=20
> If that's the intention, you may find out soon you get more than what=20
> you asked for :-)=20
>=20
> >=20
> > (% note however, I would regard implementing label swapping=20
> > function is acceptable change considering the Internal Sublayer=20
> > design of 802.1D bridge.)=20
> >=20
>=20
> The only way of doing this is using VID translation table=20
> specified in=20
> IEEE 802.1ad which requires new data-plane functionality and thus=20
> existing bridges cannot be used !!=20
>=20
> Also if going the route of tag swapping, you may consider using IEEE=20
> 802.1ah. As the editor of .1ah, I can go over the details=20
> when I get a=20
> chance.=20
> =20
> >=20
> > However, option 2 is about what TPID code we will=20
> > choose to implement new switching function.=20
> > The switch of this implementation should have new hardware=20
> > design in addition to normal bride hardware.=20
> > I think such proposal as option 2 is out of CCAMP scope.=20
>=20
> Yes.=20
>=20
> >=20
> > Overall objective is improving scalability, traffic=20
> engineering (TE)=20
> > characteristics of 802.1 bridge that it can be reliable, manageable=20
> > enough to replace some core routers.=20
>=20
> Easier said than done :-)=20
>=20
> > The switching technique you mentioned above, such as=20
> > Ethernet over MPLS as defined by PWE3 and L2VPN,=20
> > are all actually router based technology, however this=20
> > work is based on simple bridge architecture.=20
> > Cost-effectiveness is the key differentiator.=20
> >=20
>=20
> The devils are in the details and once you worked out the=20
> details, you=20
> will see the issues.=20
> =20
> >=20
> > In access or enterprise network, capability of providing end-to-end=20
> > L2-LSP will enable service providers policing, measuring, charging=20
> > application flows using Ethernet based network. This will=20
> eventually=20
> > improve income structure and introduce new session based commercial=20
> > service. I have been discussing this aspect in mail thread of=20
> > title 'End-to-end L2-LSP'.  Please read the mail thread and comment=20
> > on the discussion.=20
> > =20
> >=20
> > >You mentioned to use the MAC address or part of it as a label.=20
> > >The TRILL working group is defining shortest path routing=20
> > for Ethernet.=20
> > >How would this fit together?=20
> > =20
> >=20
> > TRILL employs new encapsulation layer outside of Ethernet frames.=20
> > However in my proposal of option-3, I simply use the=20
> Ethernet header=20
> > to encode GMPLS label.=20
> >=20
> > The overall format of rbridge is =20
> > [Ethernet][r-tag][Ethernet][ data..]=20
> > It is not LSP based technology but a connectionless routing bridge.=20
> > TTL count is very important in rbridge because frames are routed=20
> > hop-by-hop and it may loop.=20
> >=20
> > Whereas in option-3 above, Ethernet frames that have certain=20
> > OUI prefix in MAC address are forwarded via a path that=20
> > GMPLS protocol has configured on MAC forwarding table.=20
> > =20
>=20
> How does the redundancy work in here. Are you using bridge=20
> protocol in=20
> conjunction with GMPLS protocol. If you do, then there are bunch of=20
> issues. If you don't, then what is it used and how does it=20
> interact with=20
> bridging protocols ??=20
>=20
> -Ali=20
>=20
>=20
> >=20
> > Thanks=20
> > =20
> > Jaihyung=20
> > =20
> > =20
> >=20
> > -----?? ???-----=20
> > ?? ??: "Heiles Juergen" <[email-masked]>=20
> > ?? ??: 2005-07-25 ?? 6:44:34=20
> > ?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles=20
> > Juergen" <[email-masked]>, "[email-masked]"=20
> > <[email-masked]>=20
> > ??: "[email-masked]" <[email-masked]>=20
> > ??: RE: Frameformat in a l2cs gmpls rnvironment.=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > Dear Jaihyung,=20
> >=20
> > you mention several options that could be used as a label.=20
> > Most of them have strong impacts on the data plane and=20
> > introduce new layer networks. Is this in the scope of CCAMP?=20
> > What is the goal, to introduce a control plane for a existing=20
> > L2 technology or introduce a new L2 technology? What would be=20
> > the benefit of such a new L2 co switching technology compared=20
> > to Ethernet over MPLS as defined by PWE3 and L2VPN?=20
> > You mentioned to use the MAC address or part of it as a=20
> > label. The TRILL working group is defining shortest path=20
> > routing for Ethernet. How would this fit together?=20
> >=20
> >=20
> > Regards=20
> >=20
> > Juergen=20
> > =20
> >=20
> >=20
> >=20
> >=20
> > > -----Original Message-----=20
> > > From: CHO, JAI HYUNG [mailto:[email-masked]]=20
> > > Sent: Saturday, July 23, 2005 6:19 AM=20
> > > To: Heiles Juergen; [email-masked]=20
> > > Cc: [email-masked]=20
> > > Subject: RE: Frameformat in a l2cs gmpls rnvironment.=20
> > >=20
> > >=20
> > > Dear Juergen, Par and all,=20
> > >=20
> > > The proposed framework of L2SC was not intended to suggest=20
> > > any specific solution. It is still an open question.=20
> > > As Adrian noted, it only aims to present requirements=20
> > > as in scenarios that may drive people toward next step in many=20
> > > viable solutions.=20
> > >=20
> > > In fact, there are other options we may also consider for L2=20
> > > label encoding.=20
> > > IEEE 802.1 Ethernet bridges forward frames based on 48bits of=20
> > > MAC address,=20
> > > and additionally using VLAN tag.=20
> > >=20
> > > When the purpose of GMPLS control over Ethernet is not to=20
> > > create new dataplane=20
> > > but to utilize IEEE 802.1 bridge architecture, we may=20
> > consider using=20
> > > one of the two forwarding methods, MAC forwarding or VLAN=20
> > forwarding.=20
> > > (and perhaps any other combination of fields in MAC, but I'll=20
> > > not discuss it)=20
> > > =20
> > > Use of VLAN ID for label encoding may automate VLAN configuration=20
> > > using IP protocols. However, GMPLS protocol cannot use the=20
> > > field exclusively=20
> > > because public/private operators already use VLAN for various=20
> > > purpose.=20
> > > There is a potential conflict with existing use of VLAN and=20
> > > GMPLS use of VLAN label. =20
> > > Furthermore, scalability of VLAN ID has been frequently noted=20
> > > as weakness=20
> > > because the size of VLAN ID is at most 4096 (12bit).=20
> > >=20
> > > The scalability may be improved if the scope of VLAN label is=20
> > > confined to=20
> > > link-local, and some additional swapping function of VLAN ID=20
> > > is introduced in=20
> > > Internal Sublayer [802.1D] of GMPLS implemented switch.=20
> > > However, this will only be effective when the configuration=20
> > > of network=20
> > > is mesh structure that multiple LSP paths exist. If the=20
> > > configuration of network=20
> > > is star or tree shape, as normal configuration of access network,=20
> > > LSPs concentrate in root node and total number of=20
> > > LSPs that the network can hold still be limited by available=20
> > > label space=20
> > > at a few root links.=20
> > >=20
> > > For these reasons, I do not think any form of VLAN ID label is=20
> > > an appropriate choice for layer-2 label encoding.=20
> > > =20
> > > There are some other proposals assuming new assignment of=20
> Ethernet=20
> > > Length/Type value (e.g. new TPID in VLAN tag) and=20
> re-definition of=20
> > > information fields placed between 802.3 MAC header and IP packet.=20
> > > In this case, only the format of VLAN tag or extended VLAN tag=20
> > > is borrowed, however, inside the switching hardware, the=20
> > > filter and relay,=20
> > > etc. are totally different new dataplane switch.=20
> > >=20
> > > I do not see such approach is a GMPLS implementation for Ethernet=20
> > > because the core switching technique is not 802.1 Ethernet=20
> > > bridge at all.=20
> > > =20
> > > The other option we may consider is using MAC address filed=20
> > as below.=20
> > > =20
> > >=20
> > > +-------+-------+-------+-------+-------+-------+=20
> > > | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte |=20
> > > +-------+-------+-------+-------+-------+-------+=20
> > > +-----------------------+-----------------------+=20
> > > |  OUI Prefix (=3DGMPLS)  |   DA-label (24bit)    |=20
> > > +-----------------------+-----------------------+=20
> > > |  OUI Prefix (=3DGMPLS)  |   SA-label (24bit)    |=20
> > > +---------------+-------+-----------------------+=20
> > > | Length/Type   |=20
> > > +---------------+=20
> > > =20
> > >=20
> > > IEEE is designated by the ISO Council to act as the=20
> > > registration authority=20
> > > for the higher three-octet of OUI number in the MAC address=20
> > > to be used by manufacturer. Ethernet manufacturer may generate=20
> > > global unique MAC address using the OUI prefix and=20
> address block of=20
> > > lower three-octet (24bit). Taking advantage of the=20
> > addressing scheme,=20
> > > GMPLS may use the lower three-octet exclusively if a unique=20
> > > OUI number=20
> > > is reserved for the protocol. With this labeling scheme,=20
> GMPLS will=20
> > > control MAC forwarding entry, not VLAN table.=20
> > > =20
> > > All Ethernet frames controlled by GMPLS will have identical=20
> > > OUI number=20
> > > that they can easily be distinguished from other Ethernet frames.=20
> > > In principle, the label lookup hardware is identical to=20
> MAC lookup=20
> > > hardware in this labeling scheme. Therefore GMPLS implemented=20
> > > switch may still function as normal Ethernet bridge to the frames=20
> > > that OUI number is not GMPLS. This also facilitates GMPLS=20
> > implemented=20
> > > switches being deployed in operating Ethernet with minimum=20
> > > service disruption.=20
> > > =20
> > > Note also that above proposed label encoding method is=20
> transparent=20
> > > to the use of Ethernet Length/Type field. End-user device may use=20
> > > the Length/Type field as defined in IEEE 802.3 protocol.=20
> > > It also allows network operators configure VLAN for their own=20
> > > purpose.=20
> > > When IEEE 802.1p is used in conjunction with L2-LSP, the priority=20
> > > field of VLAN tag can also be used for imposing consistent TE=20
> > > policy in=20
> > > legacy switches and GMPLS switches.=20
> > > =20
> > > Any way, my conclusion is, there are other options we may=20
> consider,=20
> > > and this issue is still open to discuss.=20
> > > =20
> > > Thanks,=20
> > > =20
> > > Sincerely,=20
> > > =20
> > > Jaihyung=20
> > > =20
> > > =20
> > > =20
> > > =20
> > >=20
> > > -----?? ???-----=20
> > > ?? ??: "Heiles Juergen" <[email-masked]>=20
> > > ?? ??: 2005-07-22 ?? 10:23:43=20
> > > ?? ??: "Loa Andersson" <[email-masked]>, "[email-masked]"=20
> > > <[email-masked]>=20
> > > ??: "[email-masked]" <[email-masked]>, "[email-masked]"=20
> > > <[email-masked]>=20
> > > ??: RE: Frameformat in a l2cs gmpls rnvironment.=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > > Loa,=20
> > >=20
> > > I interpret the ID as a proposal to use GMPLS for VLAN setup.=20
> > > So GMPLS and VLAN to not compete. The VLAN is at the data=20
> > > plane and GMPLS at the control plane. The question is how and=20
> > > should different control plane techniques like GMPLS and=20
> > > (GVRP and STB) work together?=20
> > >=20
> > > Regards=20
> > >=20
> > > Juergen=20
> > >=20
> > >=20
> > > > -----Original Message-----=20
> > > > From: [email-masked]=20
> > > > [mailto:[email-masked]] On Behalf Of Loa Andersson=20
> > > > Sent: Friday, July 22, 2005 2:53 PM=20
> > > > To: [email-masked]=20
> > > > Cc: [email-masked]; [email-masked]=20
> > > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.=20
> > > >=20
> > > > Richard,=20
> > > >=20
> > > > I agree to most of this. Since we have doubts about the=20
> viability=20
> > > > of taking GMPLS all the way to end-user or enterprise I=20
> think it=20
> > > > would be good, from a wg perspective, if we agreed to solve the=20
> > > > core network problems first.=20
> > > >=20
> > > > Do you have any comment on the requirement to run both=20
> VLANs and=20
> > > > GMPLS on the same switch?=20
> > > >=20
> > > > /Loa=20
> > > >=20
> > > > [email-masked] wrote:=20
> > > > > Regardless of whether or not a switch is directly connected=20
> > > >  > to hosts, it must be able to forward packets using the=20
> > > > connectionless=20
> > > >  > Ethernet data plane. This is due to the fundamental=20
> > > > requirement that=20
> > > >  > for GMPLS switches to be able to exchange control=20
> > > information with=20
> > > >  > each other, a data plane for control traffic must be=20
> present.=20
> > > >  > This is akin to using the IP data plane for MPLS=20
> > > signalling in an=20
> > > >  > IP/MPLS network. An alternative would be to use a static=20
> > > reserved=20
> > > >  > L2-LSP for control traffic in the same way that reserved=20
> > > VPI/VCIs=20
> > > >  > are used for PNNI signalling in ATM.=20
> > > > >=20
> > > > > Regarding connecting hosts to GMPLS switches, I=20
> > personally don't=20
> > > >  > think extending L2-LSPs into the enterprise/home network is=20
> > > >  > commercially viable. However, if you do want to use=20
> > > GMPLS switches=20
> > > >  > in the home/enterprise network and for some reason=20
> > don't want to=20
> > > >  > extend L2-LSPs down to the host then you will not be=20
> > performing=20
> > > >  > normal Ethernet Mac address switching anyway.=20
> Instead you will=20
> > > >  > need some kind of policy on the switch that maps=20
> > connectionless=20
> > > >  > Ethernet packets (e.g. based on MAC src/dest, 802.1p,=20
> > VLAN) to a=20
> > > >  > L2-LSP. This is because multiple L2-LSPs to the same=20
> > destination=20
> > > >  > (e.g. a gateway router) may exist for different=20
> services/flows=20
> > > >  > (e.g. video download, VoIP call, etc.).=20
> > > > >=20
> > > > > Regards,=20
> > > > > Richard=20
> > > > >=20
> > > > >=20
> > > > >>-----Original Message-----=20
> > > > >>From: [email-masked]=20
> > > [mailto:[email-masked]]On=20
> > > > >>Behalf Of Par Mattsson=20
> > > > >>Sent: 22 July 2005 11:42=20
> > > > >>To: Loa Andersson=20
> > > > >>Cc: [email-masked]=20
> > > > >>Subject: Re: Frameformat in a l2cs gmpls rnvironment.=20
> > > > >>=20
> > > > >>=20
> > > > >>=20
> > > > >>>Per and Dimitri,=20
> > > > >>>=20
> > > > >>>I would like to come down stronger than that, for me it is=20
> > > > >>>a very strong requirement that the same switch can handle=20
> > > > >>>both VLANs and GMPLs trafic correctly. I can't dsee how that=20
> > > > >>>could be done if using the VLAN tpid to indicate GMPLS=20
> > > > >>>traffic.=20
> > > > >>=20
> > > > >>If you ever want that same switch to handle traffic for a=20
> > > directly=20
> > > > >>connected  host (not to uncommen) you would want that to=20
> > > use normal=20
> > > > >>ethernet macaddress switching. So of course you do not want=20
> > > > to have to=20
> > > > >>choose between vlan and gmpls, you would want both at the=20
> > > same time.=20
> > > > >>=20
> > > > >>/per=20
> > > > >>=20
> > > > >>=20
> > > > >>=20
> > > > >>>/Loa=20
> > > > >>>=20
> > > > >>>Par Mattsson wrote:=20
> > > > >>>=20
> > > > >>>>>hi par, one of the possibilities that has been considered=20
> > > > >>=20
> > > > >>to cope with=20
> > > > >>=20
> > > > >>>>>this requirement is to use a dedicated TPID for the=20
> > > > >>=20
> > > > >>Ethernet labeled=20
> > > > >>=20
> > > > >>>>>frames; this would allow differentiated processing with=20
> > > > non-labeled=20
> > > > >>>>>framesthanks.=20
> > > > >>>>=20
> > > > >>>>=20
> > > > >>>>That seems to make more sence. If that frame is to be=20
> > > sized like a=20
> > > > >>>>802.1q=20
> > > > >>>>frame. There is not that much space left to a label. Or is=20
> > > > >>=20
> > > > >>the demand to=20
> > > > >>=20
> > > > >>>>use jumboframes ?=20
> > > > >>>>Has there been any discussion on labelstacking, and=20
> > > > mainly where to=20
> > > > >>>>place=20
> > > > >>>>the information?=20
> > > > >>>>=20
> > > > >>>>Regards.=20
> > > > >>>>Per=20
> > > > >>>>=20
> > > > >>>>=20
> > > > >>>>=20
> > > > >>>=20
> > > > >>>=20
> > > > >>>--=20
> > > > >>>Loa Andersson=20
> > > > >>>=20
> > > > >>>Principal Networking Architect=20
> > > > >>>Acreo AB                           phone:  +46 8 632 77 14=20
> > > > >>>Isafjordsgatan 22                  mobile: +46 739 81 21 64=20
> > > > >>>Kista, Sweden                      email: =20
> > > [email-masked]=20
> > > > >>>                                            [email-masked]=20
> > > > >>>=20
> > > > >>=20
> > > > >>=20
> > > > >>=20
> > > > >=20
> > > >=20
> > > >=20
> > > > --=20
> > > > Loa Andersson=20
> > > >=20
> > > > Principal Networking Architect=20
> > > > Acreo AB                           phone:  +46 8 632 77 14=20
> > > > Isafjordsgatan 22                  mobile: +46 739 81 21 64=20
> > > > Kista, Sweden                      email: =20
> [email-masked]=20
> > > >                                             [email-masked]=20
> > > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> >=20
>=20
>=20

Delivery-date: Tue, 26 Jul 2005 23:22:05 +0000
To: "Ali Sajassi \(sajassi\)" <[email-masked]>
Cc: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Date: Wed, 27 Jul 2005 01:20:45 +0200

Delivery-date: Tue, 26 Jul 2005 17:03:45 +0000
From: [email-masked]
To: [email-masked]
Subject: GMPLS VCAT and LAGR
Date: Tue, 26 Jul 2005 19:02:22 +0200

Hi, 

- LCAS was not intended for grouping of VC-X-yvs, but for synchronization of the VC-X which is added or dropped. And it's bi-directional.
- Only the terminating nodes need to have the full GFP+LCAS+VCAT functionality.
- You need to be careful when using the verbs may, shoul and must - are they conform to IETF convention?

I believe in general this is an important I-D also wrt to the ITU-T liaison and for implementation! I believe we can also discuss details during the IETF next week.  

Michael Dueser

Delivery-date: Tue, 26 Jul 2005 14:45:08 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Online agenda
Date: Tue, 26 Jul 2005 15:25:05 +0100

Available at http://www.olddog.co.uk/63/ccamp.htm

Will be updated as slides reach me.

Cheers,
Adrian

Delivery-date: Tue, 26 Jul 2005 08:44:42 +0000
Sensitivity: 
Subject: RE: Moving LSP ownership between control plane and management plane
To: [email-masked]
Cc: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Tue, 26 Jul 2005 10:43:01 +0200

Hi Julien,
           I'll be in Paris next week and will be a pleasure to discuss
this with you.

Regards

Diego

"MEURIC Julien RD-CORE-LAN" <[email-masked]> on 25/07/2005
18.18.11

To:    "Diego Caviglia" <[email-masked]>
cc:    "ccamp" <[email-masked]>

Subject:    RE: Moving LSP ownership between control plane and management
       plane

Hello Diego, Adrian and all.

In my view, I feel that moving LSP ownership between MP and CP are very
useful functions for a carrier operational network, whether it be for
migration to GMPLS or for network maintenance.
As far as I understand, the I-D is a proposal for the signalling part
and does not pretend solving every associated issues. Some work will
probably be needed to implement the whole process, but this part looks
interesting to me.

I would be glad to discuss further this matter next week in Paris.

Regards

Julien

Julien Meuric
France Telecom
Research & Development
Core Network
2, avenue Pierre Marzin
22307 Lannion Cedex - France
Tel : + 33 (0)2 96 05 28 28
Fax : + 33 (0)2 96 05 12 52
http://www.francetelecom.com/rd/

-----Original Message-----
Behalf Of Diego Caviglia

Hi Geroge,
           sorry but I don't see how the management effort is something
related to this ID and more in general with CCAMP.

There are already RFC ID that provide tools to signal LSP with ERO
filled
up to the Label level and of course this can be done only via
management, I
don't remeber any objections on that due to NMS impact.

I'd like to discuss here (I mean in the CCAMP ML) about the ID, that is,
if
it useful and if could work and not about the difficulties it implies
for
the NMS.

I'm open to discuss, and actually I did, NMS related issues on the ITU-T
ML.

Regards

Diego

George Newsome <[email-masked]>@ops.ietf.org on 20/07/2005 11.03.00

Sent by:    [email-masked]

To:    Adrian Farrel <[email-masked]>
cc:    [email-masked], Neil Harrison <[email-masked]>, Dino
       Bramanti <[email-masked]>

Subject:    Re: Moving LSP ownership between control plane and
management
       plane

Adrian, Dino, etc.,

This thread has rapidly got too long, and I don't have the time at the
moment to argue the toss, so I'll reply as a note rather than
intersperse remarks.

On Adrian's question of which operators were at Holmdel - AT&T and
T-Systems. On do operators think they want this - some do some don't.
BT clearly don't see much value in fiddling with signaling.

You ask whether this might be done in service, and there are certainly
those who would like to see just that. Related questions are how many
times in the life of the system might this be done for the same
connection? Is it cost effective to develop a highly reliable solution
that is used just once in the life of the system?

However this is not so much a discussion of whether this could be
useful, but a technical discussion of whether changing a bit (and a slew
of procedures) in a signaling protocol actually provides the claimed
facility.

Because of the effort the management system needs to provide before
signaling might be involved, changing the signaling protocol gives the
illusion of success, yet does not provide the claimed service at all.

Once the management systems have got as far as assigning control plane
names, we can ask what happens to the cross connect object when it is
deleted as part of the hand off procedure? The behavior of this object
is that its deletion results in dropping the matrix connection, which is
exactly not required during the change over.

It is my considered opinion that fiddling with signaling merely
obfuscates the significant difficulties, which are glossed over by
stating that those difficulties occur at a different time.

Regards

             George

Adrian Farrel wrote:

> Thanks George,
>
> Useful input.
>
>
>>You asked for comments on this proposal, which was presented to ITU-T
>>Q14 experts in January of this year.
>
>
> Can you confirm that there were plenty of providers represented at the
> meeting.
>
>
>>There are so many issues involved in moving a connection from the
>>management plane to the control plane that involve intensive
management
>>action, that it is not evident that signaling need be involved at all.
>
>
> Interesting. It is certainly valuable to have a list of these issues
out
> in the open. I have made some comments in the appended meeting report.
>
> If the control plane is to take over the connection then we assume
that
> signaling state must be built so that the control plane could then
modify
> or tear down the connection. how would you propose that this be done
> without involving signaling?
>
>
>>As a personal opinion, it makes little sense to consider moving the
>>connection. It makes more sense to replace the connection with one set
>>up via the control plane, and to then delete the original management
set
>>up connection.
>
>
> The question arrises of how this would be done in a network with
limited
> resources. That is, if it is possible to set up a parallel conneciton
then
> the method you describe would be fine, but if there are not enough
> parallel resources then would you propose that a lambda (for example)
> could be used for the management-established connection and for the
> control-plane-owned connection at the same time? This might present
some
> difficulties as well.
>
> Do you have an opinion on my main question which is whether this tyoe
of
> change-over would ever be done in service?
>
> Thanks,
> Adrian
>
>
>>Excerpt of the meeting report of Q14 Experts, January 2005
>>
>>WD06 (Marconi) "G.7713 Modification in order to support Circuit
>>Migration" contains a modified version of draft G.7713 Revision as was
>>presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This
>>contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to
extend
>>the concept of Call/Connection setup to setup/adopt and release to
>>release/de-adopt. In Connection Adoption both the SNC are not actually
>>created and the LC are not actually established due to the fact that
the
>>underlying physical resources are already in place. In the
>>Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated,
>>only the Control Plane information associated with then is removed and
>>the ownership is moved to Management Plane. Attributes for indicating
>>Adoption/Dis-adoption are proposed for the INNI Connection messages.
>>
>>The discussion was mainly on the Management plane and Control plane
>>actions required before signalling is involved. The group noted that
the
>>following issues need to be addressed:
>>
>>- Naming of transport resources to the control plane.  Before a call
can
>>be placed under signalling control, links that are involved in the
>>connection need to be given control plane names.  Without these, no
>>explicit route can be formed to match the resources of the connection.
>
>
> This is pretty obvious. But actually, this is an issue with moving the
> resources from one plane to another (or having them present in both
> planes). It is certainly a prerequisite for moving the connection, but
it
> is not functionally an element of moving the connection.
>
> The draft, as I read it, assumes that these operations have been
completed
> and then asks "how do I move the connection from one plane to the
other?"
>
>
>>- Resource state while under dual CP and MP views.  After resources
are
>>given control plane names, the resources are still viewed by the
>>management plane.  It may be necessary to create a new state for the
>>resource to indicate that the management plane cannot perform some
>>actions on the connection points as the control plane is about to take
>
> over.
>
> Yes. There is certainly scope for a race condition here. I believe
that
> the I-D proposes to (try to) make the transfer an atomic action from
the
> point of view of the change-over.
>
> Note, however, that it is wrong to assume that a resource belongs only
to
> the control or to the management plane at any moment in time. This may
be
> true with respect to the ability to provision/control connections, but
> resources that are available for use by the control plane can still be
> managed through the management plane. Thus, you take a laser out of
> service through the management plane, not through the control plane.
>
>
>>- Role of discovery functions (esp. CELA).  After control plane names
>>are allocated, distributed control plane functions need to be
associated
>>and communication adjacencies formed.  This too is a precursor to any
>>signalling procedures in migrating from the MP to CP.
>
>
> Note to CCAMP: CELA is Control Entity Logical Adjacency.
> This too is "obvious".
> But this discussion seems to be wide of the mark. Before deploying a
> control plane, it is clear that this type of operation needs to take
> place. Since (within the context of CCAMP) a control plane *is* going
to
> be deployed, we can assume this operation and move on to the
discussion
in
> the draft.
>
>
>>- Similarity of migration to synchronization after CP failure and
>>subsequent recovery.  Connection control procedures might be the same
in
>>migrating a call from the MP to the CP as the situation when the CP
has
>>failed and is recovering.  Here, the network connections are already
in
>>place, but connection and call state need to be created to match it.
>>Knowledge of the call and what the connection should be is obtained
from
>>the MP for migration, and from some reliable database in the recovery
>
> case.
>
> This is a valid point.
> Control plane failure, however, is unlikely to be total. That is, it
would
> be unusual for more than one control plane link or node to fail. Thus,
in
> the control plane, the "reliable database" is distributed and recovery
can
> follow the procedures outlined in
draft-ietf-ccamp-rsvp-restart-ext-03.txt
>
> It would certainly be worth considering whether the procedures used
for
> control plane recovery could be applied to transfer of ownership from
the
> management to control plane. at the moment, I suspect that they could
not
> because the restart extensions assume a specific period during which
> signaling is associated with recovery.
>
> We would also need to look at the reverse process (transfer from CP to
MP)
> that is not possible to cover by CP restart procedures.
>
>
>>- Call awareness of migration vs. connection being unaware of
migration.
>>  When connection state is being created to match an existing
>>connection, the connection controllers (CCs) do not require awareness
of
>>why this is happening as the context could be migration or recovery.
A
>>mechanism to create control state without affecting transport plane
>>state is needed in the CCs.  Call controllers though do need migration
>>awareness as they need to obtain/derive call identification from the
MP.
>
>
> I disagree.
> Connection controllers must be able to distinguish between resources
that
> are already in use and cannot be assigned to a new connection, and
those
> that are already in use and can be assigned to a new connection
because
> the connection is replacing an existing connection. If this were
happening
> entirely within the control plane we would use resource sharing, but
when
> the operation spans the control and management planes resource
> ownership/sharing is more complex and the conneciotn controller needs
to
> be able to issue the approriate instrucitons for the assignment of the
> resources.
> On the other hand, call controllers do not need awareness of the
details
> of the realisation of the connections.
>
>
>>In summary, the group decided that it is premature to consider
>>signalling procedure before the above issues, amongst other, have been
>>studied. However the contribution does enable the group to expose in a
>>larger context the interaction between CP and MP for connection
>>migration. The above issues were included in SP24 of the G.7713 Living
>>List (see WD22).
>
>
>

Delivery-date: Tue, 26 Jul 2005 06:02:23 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: "Ali Sajassi \(sajassi\)" <[email-masked]>, "Heiles Juergen" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Bcc: 
Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Date: Tue, 26 Jul 2005 15:01:51 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message

Dear Ali,
 
Thank you your comments.
please see below,

>> 1. using VLAN tag as it is for L2 label encoding.
> 
>As you know this approach has scalability issue and you are limited to
>4K services in the network and if you try to use the upcoming IEEE
>802.1ad standard to make VLANs, interface specific, then you will need
>new switches and not existing Ethernet switches. Even if you use these
>newer switches, you will still be limited to 4K services per interface
>and it would defeat the objective of using existing switches.
> 

I agree. 
That's the point I also want to make to those proponents of this approach.

>> 
>> 2. defining new protocol ID (TPID) and borrow VLAN tag format,
>> ?or extended VLAN tag to implement label swapping.
>> 
> 
>This approach requires new data plane functionality to be implemented
>(which defeats the objective of using existing switches).
> 
>> 3. use lower 3 bytes of MAC address for L2 label encoding.
> 
>This approach has several issues:
>1) how does MAC addresses get distributed among the bridges ? 
>How does this distribution works during a link or node failure ? 
>How does it recover from a link or node failure ?
> 

Ali,
The questions are really implementation dependent.
Can we defer this discussion after Paris meeting?
However, I see the solution will not be so different than 
what RSVP-TE has been done for other transport network.

>2) Will you assign a separate provider MAC for each customer MAC. 
>If so, then how do you address MAC scalability. 
>If not, then how do you take care of 1-to-N mapping between provider 
>MAC address and customer MAC addresses 
>and how do you handle multipoint connections.

I think you are asking the issue of L2 label stacking or LSP 
aggregation, or perhaps some VPN application similar to 802.1ad.
There are some opinions on whether label stacking is necessary
in L2SC domain. This is actually the question Adrian keep asking us.
I personally think that we can achieve LSP aggregation 
with the aid of MPLS shim label, however I think this is too 
premature discussion.
All I can say at the moment is, lower 3 octet of MAC address
gives us 16M size of label space and this is enough to implement
link-local, site-local or even some domain-local LSPs.
Between the L2-LSP boundary, it needs further discussion.

> 
>3) how do handle customer FCS retention when doing this MAC translation
>stuff ??
> 

  I haven't seen any application that requires retention of original FCS image.
802.1D specification recommends recalculation of FCS when there is
any change in MAC. I see no problem if FCS is recalculated at the
label swapping switch.

>> 802.1Q bridge forwards Ethernet frames using two dataplane tables
>> - MAC forwarding table and VLAN forwarding table.
>> Bridge control protocols, such as GARP, GVRP, GMRP,
>> manipulate one of the two dataplane entities.
> 
>This is not correct. Bridges don't have different databases for MAC
>forwarding and VLAN forwarding. They have filtering datebase(s) with
>corresponding IDs (FIDs). VLAN IDs get mapped to FIDs based on operation
>mode (IVL versus SVL). Then once a filtering database is identified,
>then a MAC address lookup is performed for forwarding. Bridge control
>protocols use a designated MAC addressed and based on these MAC
>addressed, the bridge knows how to process the frame.

oh, come on .
I explained it in conceptual level and you re-described it in 
implementation level.  The contextual meaning is same.
I believe you don't deny the existence of two types of filtering 
databases, for MAC and VID, and the control of GARP over 
these databases. 
This is unnecessary argument, I think.

>> 
>> (% note however, I would regard implementing label swapping
>> function is acceptable change considering the Internal Sublayer
>> design of 802.1D bridge.)
> 
>The only way of doing this is using VID translation table specified in
>IEEE 802.1ad which requires new data-plane functionality and thus
>existing bridges cannot be used !!
> 

If we define the scope of L2 label as site-local or domain-local, 
we don't need such label swapping operation.
However, if we want link-local label, and find out that it is very useful
(* actually I do think it'll be very useful *),
I think we need to consult such modification with IEEE.
Technically speaking, I don't think replacing the label value after 
normal MAC lookup will serious change hardware architecture.
Also, it doesn't break conformance rule.
Did any 802.1 spec. say that input MAC must be identical to output MAC?

>Also if going the route of tag swapping, you may consider using IEEE
>802.1ah. As the editor of .1ah, I can go over the details when I get a
>chance.

thanks, 
hopefully, this will be far different approach than 802.1ah.

>> 
>> However, option 2 is about what TPID code we will
>> choose to implement new switching function.
>> The switch of this implementation should have new hardware
>> design in addition to normal bride hardware.
>> I think such proposal as option 2 is out of CCAMP scope.
 
>Yes. 
 
===> I agree.

[snip]
> 
>How does the redundancy work in here. Are you using bridge protocol in
>conjunction with GMPLS protocol. If you do, then there are bunch of
>issues. 

Yes I do. 
I intend GMPLS implemented switches being deployed in operating network
as normal Ethernet switch that perform bridge protocols.
When they detect (or snoop) RSVP-TE message, they establish L2-LSP
and selectively forward those GMPLS prefixed frames via the L2-LSP.
The message path that RSVP-TE is exchanged, thus L2-LSPs are 
established, does not necessarily be identical to spanning tree path
because L2-LSPs can be established via shortest path.
I welcome further discussion on this issue, but I hope to continue it 
after Paris meeting, if you may.

Thanks
 
Jaihyung

-----?? ???----- 
?? ??: "Ali Sajassi (sajassi)" <[email-masked]> 
?? ??: 2005-07-26 ?? 8:13:56 
?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: "[email-masked]" <[email-masked]> 
??: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet 

Jaihyung, 

It seems to me that your primary objective is to use the existing 
Ethernet switches with new control plane (GMPLS) to setup TE paths for 
different applications. And you mentioned three approaches for doing 
this in your email. However, all three of them have issues and are not 
viable. Lets go over them ... 

> 
> In below mail, I discussed about three proposed approaches. 
>  
>  
> 1. using VLAN tag as it is for L2 label encoding. 

As you know this approach has scalability issue and you are limited to 
4K services in the network and if you try to use the upcoming IEEE 
802.1ad standard to make VLANs, interface specific, then you will need 
new switches and not existing Ethernet switches. Even if you use these 
newer switches, you will still be limited to 4K services per interface 
and it would defeat the objective of using existing switches. 

> 
> 2. defining new protocol ID (TPID) and borrow VLAN tag format, 
> ?or extended VLAN tag to implement label swapping. 
> 

This approach requires new data plane functionality to be implemented 
(which defeats the objective of using existing switches). 

> 3. use lower 3 bytes of MAC address for L2 label encoding. 
>  

This approach has several issues: 
1) how does MAC addresses get distributed among the bridges ? How does 
this distribution works during a link or node failure ? How does it 
recover from a link or node failure ? 

2) Will you assign a separate provider MAC for each customer MAC. If so, 
then how do you address MAC scalability. If not, then how do you take 
care of 1-to-N mapping between provider MAC address and customer MAC 
addresses and how do you handle multipoint connections. 

3) how do handle customer FCS retention when doing this MAC translation 
stuff ?? 

> 
> 802.1Q bridge forwards Ethernet frames using two dataplane tables 
> - MAC forwarding table and VLAN forwarding table. 
> Bridge control protocols, such as GARP, GVRP, GMRP, 
> manipulate one of the two dataplane entities. 

This is not correct. Bridges don't have different databases for MAC 
forwarding and VLAN forwarding. They have filtering datebase(s) with 
corresponding IDs (FIDs). VLAN IDs get mapped to FIDs based on operation 
mode (IVL versus SVL). Then once a filtering database is identified, 
then a MAC address lookup is performed for forwarding. Bridge control 
protocols use a designated MAC addressed and based on these MAC 
addressed, the bridge knows how to process the frame. 

> 
> Similarly, option 1 and 3 are about which one of two 
> dataplane entities 
> GMPLS protocol should control on behalf of bridge control protocols. 
> The two proposals do not intend to modify bridge behavior 
> seriously, such as MAC learning, aging, filtering. 
> Therefore, the approaches 1 and 3 are in the scope of CCAMP. 

If that's the intention, you may find out soon you get more than what 
you asked for :-) 

> 
> (% note however, I would regard implementing label swapping 
> function is acceptable change considering the Internal Sublayer 
> design of 802.1D bridge.) 
> 

The only way of doing this is using VID translation table specified in 
IEEE 802.1ad which requires new data-plane functionality and thus 
existing bridges cannot be used !! 

Also if going the route of tag swapping, you may consider using IEEE 
802.1ah. As the editor of .1ah, I can go over the details when I get a 
chance. 
 
> 
> However, option 2 is about what TPID code we will 
> choose to implement new switching function. 
> The switch of this implementation should have new hardware 
> design in addition to normal bride hardware. 
> I think such proposal as option 2 is out of CCAMP scope. 

Yes. 

> 
> Overall objective is improving scalability, traffic engineering (TE) 
> characteristics of 802.1 bridge that it can be reliable, manageable 
> enough to replace some core routers. 

Easier said than done :-) 

> The switching technique you mentioned above, such as 
> Ethernet over MPLS as defined by PWE3 and L2VPN, 
> are all actually router based technology, however this 
> work is based on simple bridge architecture. 
> Cost-effectiveness is the key differentiator. 
> 

The devils are in the details and once you worked out the details, you 
will see the issues. 
 
> 
> In access or enterprise network, capability of providing end-to-end 
> L2-LSP will enable service providers policing, measuring, charging 
> application flows using Ethernet based network. This will eventually 
> improve income structure and introduce new session based commercial 
> service. I have been discussing this aspect in mail thread of 
> title 'End-to-end L2-LSP'.  Please read the mail thread and comment 
> on the discussion. 
>  
> 
> >You mentioned to use the MAC address or part of it as a label. 
> >The TRILL working group is defining shortest path routing 
> for Ethernet. 
> >How would this fit together? 
>  
> 
> TRILL employs new encapsulation layer outside of Ethernet frames. 
> However in my proposal of option-3, I simply use the Ethernet header 
> to encode GMPLS label. 
> 
> The overall format of rbridge is  
> [Ethernet][r-tag][Ethernet][ data..] 
> It is not LSP based technology but a connectionless routing bridge. 
> TTL count is very important in rbridge because frames are routed 
> hop-by-hop and it may loop. 
> 
> Whereas in option-3 above, Ethernet frames that have certain 
> OUI prefix in MAC address are forwarded via a path that 
> GMPLS protocol has configured on MAC forwarding table. 
>  

How does the redundancy work in here. Are you using bridge protocol in 
conjunction with GMPLS protocol. If you do, then there are bunch of 
issues. If you don't, then what is it used and how does it interact with 
bridging protocols ?? 

-Ali 

> 
> Thanks 
>  
> Jaihyung 
>  
>  
> 
> -----?? ???----- 
> ?? ??: "Heiles Juergen" <[email-masked]> 
> ?? ??: 2005-07-25 ?? 6:44:34 
> ?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles 
> Juergen" <[email-masked]>, "[email-masked]" 
> <[email-masked]> 
> ??: "[email-masked]" <[email-masked]> 
> ??: RE: Frameformat in a l2cs gmpls rnvironment. 
> 
> 
> 
> 
> 
> 
> Dear Jaihyung, 
> 
> you mention several options that could be used as a label. 
> Most of them have strong impacts on the data plane and 
> introduce new layer networks. Is this in the scope of CCAMP? 
> What is the goal, to introduce a control plane for a existing 
> L2 technology or introduce a new L2 technology? What would be 
> the benefit of such a new L2 co switching technology compared 
> to Ethernet over MPLS as defined by PWE3 and L2VPN? 
> You mentioned to use the MAC address or part of it as a 
> label. The TRILL working group is defining shortest path 
> routing for Ethernet. How would this fit together? 
> 
> 
> Regards 
> 
> Juergen 
>  
> 
> 
> 
> 
> > From: CHO, JAI HYUNG [mailto:[email-masked]] 
> > Sent: Saturday, July 23, 2005 6:19 AM 
> > To: Heiles Juergen; [email-masked] 
> > Cc: [email-masked] 
> > Subject: RE: Frameformat in a l2cs gmpls rnvironment. 
> > 
> > 
> > Dear Juergen, Par and all, 
> > 
> > The proposed framework of L2SC was not intended to suggest 
> > any specific solution. It is still an open question. 
> > As Adrian noted, it only aims to present requirements 
> > as in scenarios that may drive people toward next step in many 
> > viable solutions. 
> > 
> > In fact, there are other options we may also consider for L2 
> > label encoding. 
> > IEEE 802.1 Ethernet bridges forward frames based on 48bits of 
> > MAC address, 
> > and additionally using VLAN tag. 
> > 
> > When the purpose of GMPLS control over Ethernet is not to 
> > create new dataplane 
> > but to utilize IEEE 802.1 bridge architecture, we may 
> consider using 
> > one of the two forwarding methods, MAC forwarding or VLAN 
> forwarding. 
> > (and perhaps any other combination of fields in MAC, but I'll 
> > not discuss it) 
> >  
> > Use of VLAN ID for label encoding may automate VLAN configuration 
> > using IP protocols. However, GMPLS protocol cannot use the 
> > field exclusively 
> > because public/private operators already use VLAN for various 
> > purpose. 
> > There is a potential conflict with existing use of VLAN and 
> > GMPLS use of VLAN label.  
> > Furthermore, scalability of VLAN ID has been frequently noted 
> > as weakness 
> > because the size of VLAN ID is at most 4096 (12bit). 
> > 
> > The scalability may be improved if the scope of VLAN label is 
> > confined to 
> > link-local, and some additional swapping function of VLAN ID 
> > is introduced in 
> > Internal Sublayer [802.1D] of GMPLS implemented switch. 
> > However, this will only be effective when the configuration 
> > of network 
> > is mesh structure that multiple LSP paths exist. If the 
> > configuration of network 
> > is star or tree shape, as normal configuration of access network, 
> > LSPs concentrate in root node and total number of 
> > LSPs that the network can hold still be limited by available 
> > label space 
> > at a few root links. 
> > 
> > For these reasons, I do not think any form of VLAN ID label is 
> > an appropriate choice for layer-2 label encoding. 
> >  
> > There are some other proposals assuming new assignment of Ethernet 
> > Length/Type value (e.g. new TPID in VLAN tag) and re-definition of 
> > information fields placed between 802.3 MAC header and IP packet. 
> > In this case, only the format of VLAN tag or extended VLAN tag 
> > is borrowed, however, inside the switching hardware, the 
> > filter and relay, 
> > etc. are totally different new dataplane switch. 
> > 
> > I do not see such approach is a GMPLS implementation for Ethernet 
> > because the core switching technique is not 802.1 Ethernet 
> > bridge at all. 
> >  
> > The other option we may consider is using MAC address filed 
> as below. 
> >  
> > 
> > +-------+-------+-------+-------+-------+-------+ 
> > | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte | 
> > +-------+-------+-------+-------+-------+-------+ 
> > +-----------------------+-----------------------+ 
> > |  OUI Prefix (=GMPLS)  |   DA-label (24bit)    | 
> > +-----------------------+-----------------------+ 
> > |  OUI Prefix (=GMPLS)  |   SA-label (24bit)    | 
> > +---------------+-------+-----------------------+ 
> > | Length/Type   | 
> > +---------------+ 
> >  
> > 
> > IEEE is designated by the ISO Council to act as the 
> > registration authority 
> > for the higher three-octet of OUI number in the MAC address 
> > to be used by manufacturer. Ethernet manufacturer may generate 
> > global unique MAC address using the OUI prefix and address block of 
> > lower three-octet (24bit). Taking advantage of the 
> addressing scheme, 
> > GMPLS may use the lower three-octet exclusively if a unique 
> > OUI number 
> > is reserved for the protocol. With this labeling scheme, GMPLS will 
> > control MAC forwarding entry, not VLAN table. 
> >  
> > All Ethernet frames controlled by GMPLS will have identical 
> > OUI number 
> > that they can easily be distinguished from other Ethernet frames. 
> > In principle, the label lookup hardware is identical to MAC lookup 
> > hardware in this labeling scheme. Therefore GMPLS implemented 
> > switch may still function as normal Ethernet bridge to the frames 
> > that OUI number is not GMPLS. This also facilitates GMPLS 
> implemented 
> > switches being deployed in operating Ethernet with minimum 
> > service disruption. 
> >  
> > Note also that above proposed label encoding method is transparent 
> > to the use of Ethernet Length/Type field. End-user device may use 
> > the Length/Type field as defined in IEEE 802.3 protocol. 
> > It also allows network operators configure VLAN for their own 
> > purpose. 
> > When IEEE 802.1p is used in conjunction with L2-LSP, the priority 
> > field of VLAN tag can also be used for imposing consistent TE 
> > policy in 
> > legacy switches and GMPLS switches. 
> >  
> > Any way, my conclusion is, there are other options we may consider, 
> > and this issue is still open to discuss. 
> >  
> > Thanks, 
> >  
> > Sincerely, 
> >  
> > Jaihyung 
> >  
> >  
> >  
> >  
> > 
> > -----?? ???----- 
> > ?? ??: "Heiles Juergen" <[email-masked]> 
> > ?? ??: 2005-07-22 ?? 10:23:43 
> > ?? ??: "Loa Andersson" <[email-masked]>, "[email-masked]" 
> > <[email-masked]> 
> > ??: "[email-masked]" <[email-masked]>, "[email-masked]" 
> > <[email-masked]> 
> > ??: RE: Frameformat in a l2cs gmpls rnvironment. 
> > 
> > 
> > 
> > 
> > 
> > 
> > Loa, 
> > 
> > I interpret the ID as a proposal to use GMPLS for VLAN setup. 
> > So GMPLS and VLAN to not compete. The VLAN is at the data 
> > plane and GMPLS at the control plane. The question is how and 
> > should different control plane techniques like GMPLS and 
> > (GVRP and STB) work together? 
> > 
> > Regards 
> > 
> > Juergen 
> > 
> > 
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of Loa Andersson 
> > > Sent: Friday, July 22, 2005 2:53 PM 
> > > To: [email-masked] 
> > > Cc: [email-masked]; [email-masked] 
> > > Subject: Re: Frameformat in a l2cs gmpls rnvironment. 
> > > 
> > > Richard, 
> > > 
> > > I agree to most of this. Since we have doubts about the viability 
> > > of taking GMPLS all the way to end-user or enterprise I think it 
> > > would be good, from a wg perspective, if we agreed to solve the 
> > > core network problems first. 
> > > 
> > > Do you have any comment on the requirement to run both VLANs and 
> > > GMPLS on the same switch? 
> > > 
> > > /Loa 
> > > 
> > > [email-masked] wrote: 
> > > > Regardless of whether or not a switch is directly connected 
> > >  > to hosts, it must be able to forward packets using the 
> > > connectionless 
> > >  > Ethernet data plane. This is due to the fundamental 
> > > requirement that 
> > >  > for GMPLS switches to be able to exchange control 
> > information with 
> > >  > each other, a data plane for control traffic must be present. 
> > >  > This is akin to using the IP data plane for MPLS 
> > signalling in an 
> > >  > IP/MPLS network. An alternative would be to use a static 
> > reserved 
> > >  > L2-LSP for control traffic in the same way that reserved 
> > VPI/VCIs 
> > >  > are used for PNNI signalling in ATM. 
> > > > 
> > > > Regarding connecting hosts to GMPLS switches, I 
> personally don't 
> > >  > think extending L2-LSPs into the enterprise/home network is 
> > >  > commercially viable. However, if you do want to use 
> > GMPLS switches 
> > >  > in the home/enterprise network and for some reason 
> don't want to 
> > >  > extend L2-LSPs down to the host then you will not be 
> performing 
> > >  > normal Ethernet Mac address switching anyway. Instead you will 
> > >  > need some kind of policy on the switch that maps 
> connectionless 
> > >  > Ethernet packets (e.g. based on MAC src/dest, 802.1p, 
> VLAN) to a 
> > >  > L2-LSP. This is because multiple L2-LSPs to the same 
> destination 
> > >  > (e.g. a gateway router) may exist for different services/flows 
> > >  > (e.g. video download, VoIP call, etc.). 
> > > > 
> > > > Regards, 
> > > > Richard 
> > > > 
> > > > 
> > > >>From: [email-masked] 
> > [mailto:[email-masked]]On 
> > > >>Behalf Of Par Mattsson 
> > > >>Sent: 22 July 2005 11:42 
> > > >>To: Loa Andersson 
> > > >>Cc: [email-masked] 
> > > >>Subject: Re: Frameformat in a l2cs gmpls rnvironment. 
> > > >> 
> > > >> 
> > > >> 
> > > >>>Per and Dimitri, 
> > > >>> 
> > > >>>I would like to come down stronger than that, for me it is 
> > > >>>a very strong requirement that the same switch can handle 
> > > >>>both VLANs and GMPLs trafic correctly. I can't dsee how that 
> > > >>>could be done if using the VLAN tpid to indicate GMPLS 
> > > >>>traffic. 
> > > >> 
> > > >>If you ever want that same switch to handle traffic for a 
> > directly 
> > > >>connected  host (not to uncommen) you would want that to 
> > use normal 
> > > >>ethernet macaddress switching. So of course you do not want 
> > > to have to 
> > > >>choose between vlan and gmpls, you would want both at the 
> > same time. 
> > > >> 
> > > >>/per 
> > > >> 
> > > >> 
> > > >> 
> > > >>>/Loa 
> > > >>> 
> > > >>>Par Mattsson wrote: 
> > > >>> 
> > > >>>>>hi par, one of the possibilities that has been considered 
> > > >> 
> > > >>to cope with 
> > > >> 
> > > >>>>>this requirement is to use a dedicated TPID for the 
> > > >> 
> > > >>Ethernet labeled 
> > > >> 
> > > >>>>>frames; this would allow differentiated processing with 
> > > non-labeled 
> > > >>>>>framesthanks. 
> > > >>>> 
> > > >>>> 
> > > >>>>That seems to make more sence. If that frame is to be 
> > sized like a 
> > > >>>>802.1q 
> > > >>>>frame. There is not that much space left to a label. Or is 
> > > >> 
> > > >>the demand to 
> > > >> 
> > > >>>>use jumboframes ? 
> > > >>>>Has there been any discussion on labelstacking, and 
> > > mainly where to 
> > > >>>>place 
> > > >>>>the information? 
> > > >>>> 
> > > >>>>Regards. 
> > > >>>>Per 
> > > >>>> 
> > > >>>> 
> > > >>>> 
> > > >>> 
> > > >>> 
> > > >>>-- 
> > > >>>Loa Andersson 
> > > >>> 
> > > >>>Principal Networking Architect 
> > > >>>Acreo AB                           phone:  +46 8 632 77 14 
> > > >>>Isafjordsgatan 22                  mobile: +46 739 81 21 64 
> > > >>>Kista, Sweden                      email:  
> > [email-masked] 
> > > >>>                                            [email-masked] 
> > > >>> 
> > > >> 
> > > >> 
> > > >> 
> > > > 
> > > 
> > > 
> > > -- 
> > > Loa Andersson 
> > > 
> > > Principal Networking Architect 
> > > Acreo AB                           phone:  +46 8 632 77 14 
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64 
> > > Kista, Sweden                      email:  [email-masked] 
> > >                                             [email-masked] 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 

Delivery-date: Mon, 25 Jul 2005 23:15:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Date: Mon, 25 Jul 2005 16:13:56 -0700
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Jaihyung,

It seems to me that your primary objective is to use the existing
Ethernet switches with new control plane (GMPLS) to setup TE paths for
different applications. And you mentioned three approaches for doing
this in your email. However, all three of them have issues and are not
viable. Lets go over them ...
=20
>=20
> In below mail, I discussed about three proposed approaches.
> =20
> =20
> 1. using VLAN tag as it is for L2 label encoding.

As you know this approach has scalability issue and you are limited to
4K services in the network and if you try to use the upcoming IEEE
802.1ad standard to make VLANs, interface specific, then you will need
new switches and not existing Ethernet switches. Even if you use these
newer switches, you will still be limited to 4K services per interface
and it would defeat the objective of using existing switches.

>=20
> 2. defining new protocol ID (TPID) and borrow VLAN tag format,=20
> ?or extended VLAN tag to implement label swapping.
>=20

This approach requires new data plane functionality to be implemented
(which defeats the objective of using existing switches).

> 3. use lower 3 bytes of MAC address for L2 label encoding.
> =20

This approach has several issues:
1) how does MAC addresses get distributed among the bridges ? How does
this distribution works during a link or node failure ? How does it
recover from a link or node failure ?

2) Will you assign a separate provider MAC for each customer MAC. If so,
then how do you address MAC scalability. If not, then how do you take
care of 1-to-N mapping between provider MAC address and customer MAC
addresses and how do you handle multipoint connections.

3) how do handle customer FCS retention when doing this MAC translation
stuff ??

>=20
> 802.1Q bridge forwards Ethernet frames using two dataplane tables=20
> - MAC forwarding table and VLAN forwarding table.=20
> Bridge control protocols, such as GARP, GVRP, GMRP,=20
> manipulate one of the two dataplane entities.

This is not correct. Bridges don't have different databases for MAC
forwarding and VLAN forwarding. They have filtering datebase(s) with
corresponding IDs (FIDs). VLAN IDs get mapped to FIDs based on operation
mode (IVL versus SVL). Then once a filtering database is identified,
then a MAC address lookup is performed for forwarding. Bridge control
protocols use a designated MAC addressed and based on these MAC
addressed, the bridge knows how to process the frame.=20

>=20
> Similarly, option 1 and 3 are about which one of two=20
> dataplane entities=20
> GMPLS protocol should control on behalf of bridge control protocols.=20
> The two proposals do not intend to modify bridge behavior=20
> seriously, such as MAC learning, aging, filtering.=20
> Therefore, the approaches 1 and 3 are in the scope of CCAMP.

If that's the intention, you may find out soon you get more than what
you asked for :-)

>=20
> (% note however, I would regard implementing label swapping=20
> function is acceptable change considering the Internal Sublayer=20
> design of 802.1D bridge.)
>

The only way of doing this is using VID translation table specified in
IEEE 802.1ad which requires new data-plane functionality and thus
existing bridges cannot be used !!

Also if going the route of tag swapping, you may consider using IEEE
802.1ah. As the editor of .1ah, I can go over the details when I get a
chance.=20
 =20
>=20
> However, option 2 is about what TPID code we will=20
> choose to implement new switching function.=20
> The switch of this implementation should have new hardware=20
> design in addition to normal bride hardware.=20
> I think such proposal as option 2 is out of CCAMP scope.=20

Yes.

>=20
> Overall objective is improving scalability, traffic engineering (TE)=20
> characteristics of 802.1 bridge that it can be reliable, manageable=20
> enough to replace some core routers.

Easier said than done :-)

> The switching technique you mentioned above, such as=20
> Ethernet over MPLS as defined by PWE3 and L2VPN,
> are all actually router based technology, however this
> work is based on simple bridge architecture.
> Cost-effectiveness is the key differentiator.
>

The devils are in the details and once you worked out the details, you
will see the issues.
 =20
>=20
> In access or enterprise network, capability of providing end-to-end=20
> L2-LSP will enable service providers policing, measuring, charging=20
> application flows using Ethernet based network. This will eventually=20
> improve income structure and introduce new session based commercial=20
> service. I have been discussing this aspect in mail thread of=20
> title 'End-to-end L2-LSP'.  Please read the mail thread and comment
> on the discussion.
> =20
>=20
> >You mentioned to use the MAC address or part of it as a label.=20
> >The TRILL working group is defining shortest path routing=20
> for Ethernet.=20
> >How would this fit together?
> =20
>=20
> TRILL employs new encapsulation layer outside of Ethernet frames.=20
> However in my proposal of option-3, I simply use the Ethernet header=20
> to encode GMPLS label.=20
>=20
> The overall format of rbridge is =20
> [Ethernet][r-tag][Ethernet][ data..]=20
> It is not LSP based technology but a connectionless routing bridge.=20
> TTL count is very important in rbridge because frames are routed=20
> hop-by-hop and it may loop.
>=20
> Whereas in option-3 above, Ethernet frames that have certain=20
> OUI prefix in MAC address are forwarded via a path that=20
> GMPLS protocol has configured on MAC forwarding table.
> =20

How does the redundancy work in here. Are you using bridge protocol in
conjunction with GMPLS protocol. If you do, then there are bunch of
issues. If you don't, then what is it used and how does it interact with
bridging protocols ??

-Ali

>=20
> Thanks
> =20
> Jaihyung
> =20
> =20
>=20
> -----?? ???-----=20
> ?? ??: "Heiles Juergen" <[email-masked]>=20
> ?? ??: 2005-07-25 ?? 6:44:34=20
> ?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles=20
> Juergen" <[email-masked]>, "[email-masked]"=20
> <[email-masked]>=20
> ??: "[email-masked]" <[email-masked]>=20
> ??: RE: Frameformat in a l2cs gmpls rnvironment.=20
>=20
>=20
>=20
>=20
>=20
>=20
> Dear Jaihyung,=20
>=20
> you mention several options that could be used as a label.=20
> Most of them have strong impacts on the data plane and=20
> introduce new layer networks. Is this in the scope of CCAMP?=20
> What is the goal, to introduce a control plane for a existing=20
> L2 technology or introduce a new L2 technology? What would be=20
> the benefit of such a new L2 co switching technology compared=20
> to Ethernet over MPLS as defined by PWE3 and L2VPN?=20
> You mentioned to use the MAC address or part of it as a=20
> label. The TRILL working group is defining shortest path=20
> routing for Ethernet. How would this fit together?=20
>=20
>=20
> Regards=20
>=20
> Juergen=20
> =20
>=20
>=20
>=20
>=20
> > -----Original Message-----=20
> > From: CHO, JAI HYUNG [mailto:[email-masked]]=20
> > Sent: Saturday, July 23, 2005 6:19 AM=20
> > To: Heiles Juergen; [email-masked]=20
> > Cc: [email-masked]=20
> > Subject: RE: Frameformat in a l2cs gmpls rnvironment.=20
> >=20
> >=20
> > Dear Juergen, Par and all,=20
> >=20
> > The proposed framework of L2SC was not intended to suggest=20
> > any specific solution. It is still an open question.=20
> > As Adrian noted, it only aims to present requirements=20
> > as in scenarios that may drive people toward next step in many=20
> > viable solutions.=20
> >=20
> > In fact, there are other options we may also consider for L2=20
> > label encoding.=20
> > IEEE 802.1 Ethernet bridges forward frames based on 48bits of=20
> > MAC address,=20
> > and additionally using VLAN tag.=20
> >=20
> > When the purpose of GMPLS control over Ethernet is not to=20
> > create new dataplane=20
> > but to utilize IEEE 802.1 bridge architecture, we may=20
> consider using=20
> > one of the two forwarding methods, MAC forwarding or VLAN=20
> forwarding.=20
> > (and perhaps any other combination of fields in MAC, but I'll=20
> > not discuss it)=20
> > =20
> > Use of VLAN ID for label encoding may automate VLAN configuration=20
> > using IP protocols. However, GMPLS protocol cannot use the=20
> > field exclusively=20
> > because public/private operators already use VLAN for various=20
> > purpose.=20
> > There is a potential conflict with existing use of VLAN and=20
> > GMPLS use of VLAN label. =20
> > Furthermore, scalability of VLAN ID has been frequently noted=20
> > as weakness=20
> > because the size of VLAN ID is at most 4096 (12bit).=20
> >=20
> > The scalability may be improved if the scope of VLAN label is=20
> > confined to=20
> > link-local, and some additional swapping function of VLAN ID=20
> > is introduced in=20
> > Internal Sublayer [802.1D] of GMPLS implemented switch.=20
> > However, this will only be effective when the configuration=20
> > of network=20
> > is mesh structure that multiple LSP paths exist. If the=20
> > configuration of network=20
> > is star or tree shape, as normal configuration of access network,=20
> > LSPs concentrate in root node and total number of=20
> > LSPs that the network can hold still be limited by available=20
> > label space=20
> > at a few root links.=20
> >=20
> > For these reasons, I do not think any form of VLAN ID label is=20
> > an appropriate choice for layer-2 label encoding.=20
> > =20
> > There are some other proposals assuming new assignment of Ethernet=20
> > Length/Type value (e.g. new TPID in VLAN tag) and re-definition of=20
> > information fields placed between 802.3 MAC header and IP packet.=20
> > In this case, only the format of VLAN tag or extended VLAN tag=20
> > is borrowed, however, inside the switching hardware, the=20
> > filter and relay,=20
> > etc. are totally different new dataplane switch.=20
> >=20
> > I do not see such approach is a GMPLS implementation for Ethernet=20
> > because the core switching technique is not 802.1 Ethernet=20
> > bridge at all.=20
> > =20
> > The other option we may consider is using MAC address filed=20
> as below.=20
> > =20
> >=20
> > +-------+-------+-------+-------+-------+-------+=20
> > | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte |=20
> > +-------+-------+-------+-------+-------+-------+=20
> > +-----------------------+-----------------------+=20
> > |  OUI Prefix (=3DGMPLS)  |   DA-label (24bit)    |=20
> > +-----------------------+-----------------------+=20
> > |  OUI Prefix (=3DGMPLS)  |   SA-label (24bit)    |=20
> > +---------------+-------+-----------------------+=20
> > | Length/Type   |=20
> > +---------------+=20
> > =20
> >=20
> > IEEE is designated by the ISO Council to act as the=20
> > registration authority=20
> > for the higher three-octet of OUI number in the MAC address=20
> > to be used by manufacturer. Ethernet manufacturer may generate=20
> > global unique MAC address using the OUI prefix and address block of=20
> > lower three-octet (24bit). Taking advantage of the=20
> addressing scheme,=20
> > GMPLS may use the lower three-octet exclusively if a unique=20
> > OUI number=20
> > is reserved for the protocol. With this labeling scheme, GMPLS will=20
> > control MAC forwarding entry, not VLAN table.=20
> > =20
> > All Ethernet frames controlled by GMPLS will have identical=20
> > OUI number=20
> > that they can easily be distinguished from other Ethernet frames.=20
> > In principle, the label lookup hardware is identical to MAC lookup=20
> > hardware in this labeling scheme. Therefore GMPLS implemented=20
> > switch may still function as normal Ethernet bridge to the frames=20
> > that OUI number is not GMPLS. This also facilitates GMPLS=20
> implemented=20
> > switches being deployed in operating Ethernet with minimum=20
> > service disruption.=20
> > =20
> > Note also that above proposed label encoding method is transparent=20
> > to the use of Ethernet Length/Type field. End-user device may use=20
> > the Length/Type field as defined in IEEE 802.3 protocol.=20
> > It also allows network operators configure VLAN for their own=20
> > purpose.=20
> > When IEEE 802.1p is used in conjunction with L2-LSP, the priority=20
> > field of VLAN tag can also be used for imposing consistent TE=20
> > policy in=20
> > legacy switches and GMPLS switches.=20
> > =20
> > Any way, my conclusion is, there are other options we may consider,=20
> > and this issue is still open to discuss.=20
> > =20
> > Thanks,=20
> > =20
> > Sincerely,=20
> > =20
> > Jaihyung=20
> > =20
> > =20
> > =20
> > =20
> >=20
> > -----?? ???-----=20
> > ?? ??: "Heiles Juergen" <[email-masked]>=20
> > ?? ??: 2005-07-22 ?? 10:23:43=20
> > ?? ??: "Loa Andersson" <[email-masked]>, "[email-masked]"=20
> > <[email-masked]>=20
> > ??: "[email-masked]" <[email-masked]>, "[email-masked]"=20
> > <[email-masked]>=20
> > ??: RE: Frameformat in a l2cs gmpls rnvironment.=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > Loa,=20
> >=20
> > I interpret the ID as a proposal to use GMPLS for VLAN setup.=20
> > So GMPLS and VLAN to not compete. The VLAN is at the data=20
> > plane and GMPLS at the control plane. The question is how and=20
> > should different control plane techniques like GMPLS and=20
> > (GVRP and STB) work together?=20
> >=20
> > Regards=20
> >=20
> > Juergen=20
> >=20
> >=20
> > > -----Original Message-----=20
> > > From: [email-masked]=20
> > > [mailto:[email-masked]] On Behalf Of Loa Andersson=20
> > > Sent: Friday, July 22, 2005 2:53 PM=20
> > > To: [email-masked]=20
> > > Cc: [email-masked]; [email-masked]=20
> > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.=20
> > >=20
> > > Richard,=20
> > >=20
> > > I agree to most of this. Since we have doubts about the viability=20
> > > of taking GMPLS all the way to end-user or enterprise I think it=20
> > > would be good, from a wg perspective, if we agreed to solve the=20
> > > core network problems first.=20
> > >=20
> > > Do you have any comment on the requirement to run both VLANs and=20
> > > GMPLS on the same switch?=20
> > >=20
> > > /Loa=20
> > >=20
> > > [email-masked] wrote:=20
> > > > Regardless of whether or not a switch is directly connected=20
> > >  > to hosts, it must be able to forward packets using the=20
> > > connectionless=20
> > >  > Ethernet data plane. This is due to the fundamental=20
> > > requirement that=20
> > >  > for GMPLS switches to be able to exchange control=20
> > information with=20
> > >  > each other, a data plane for control traffic must be present.=20
> > >  > This is akin to using the IP data plane for MPLS=20
> > signalling in an=20
> > >  > IP/MPLS network. An alternative would be to use a static=20
> > reserved=20
> > >  > L2-LSP for control traffic in the same way that reserved=20
> > VPI/VCIs=20
> > >  > are used for PNNI signalling in ATM.=20
> > > >=20
> > > > Regarding connecting hosts to GMPLS switches, I=20
> personally don't=20
> > >  > think extending L2-LSPs into the enterprise/home network is=20
> > >  > commercially viable. However, if you do want to use=20
> > GMPLS switches=20
> > >  > in the home/enterprise network and for some reason=20
> don't want to=20
> > >  > extend L2-LSPs down to the host then you will not be=20
> performing=20
> > >  > normal Ethernet Mac address switching anyway. Instead you will=20
> > >  > need some kind of policy on the switch that maps=20
> connectionless=20
> > >  > Ethernet packets (e.g. based on MAC src/dest, 802.1p,=20
> VLAN) to a=20
> > >  > L2-LSP. This is because multiple L2-LSPs to the same=20
> destination=20
> > >  > (e.g. a gateway router) may exist for different services/flows=20
> > >  > (e.g. video download, VoIP call, etc.).=20
> > > >=20
> > > > Regards,=20
> > > > Richard=20
> > > >=20
> > > >=20
> > > >>-----Original Message-----=20
> > > >>From: [email-masked]=20
> > [mailto:[email-masked]]On=20
> > > >>Behalf Of Par Mattsson=20
> > > >>Sent: 22 July 2005 11:42=20
> > > >>To: Loa Andersson=20
> > > >>Cc: [email-masked]=20
> > > >>Subject: Re: Frameformat in a l2cs gmpls rnvironment.=20
> > > >>=20
> > > >>=20
> > > >>=20
> > > >>>Per and Dimitri,=20
> > > >>>=20
> > > >>>I would like to come down stronger than that, for me it is=20
> > > >>>a very strong requirement that the same switch can handle=20
> > > >>>both VLANs and GMPLs trafic correctly. I can't dsee how that=20
> > > >>>could be done if using the VLAN tpid to indicate GMPLS=20
> > > >>>traffic.=20
> > > >>=20
> > > >>If you ever want that same switch to handle traffic for a=20
> > directly=20
> > > >>connected  host (not to uncommen) you would want that to=20
> > use normal=20
> > > >>ethernet macaddress switching. So of course you do not want=20
> > > to have to=20
> > > >>choose between vlan and gmpls, you would want both at the=20
> > same time.=20
> > > >>=20
> > > >>/per=20
> > > >>=20
> > > >>=20
> > > >>=20
> > > >>>/Loa=20
> > > >>>=20
> > > >>>Par Mattsson wrote:=20
> > > >>>=20
> > > >>>>>hi par, one of the possibilities that has been considered=20
> > > >>=20
> > > >>to cope with=20
> > > >>=20
> > > >>>>>this requirement is to use a dedicated TPID for the=20
> > > >>=20
> > > >>Ethernet labeled=20
> > > >>=20
> > > >>>>>frames; this would allow differentiated processing with=20
> > > non-labeled=20
> > > >>>>>framesthanks.=20
> > > >>>>=20
> > > >>>>=20
> > > >>>>That seems to make more sence. If that frame is to be=20
> > sized like a=20
> > > >>>>802.1q=20
> > > >>>>frame. There is not that much space left to a label. Or is=20
> > > >>=20
> > > >>the demand to=20
> > > >>=20
> > > >>>>use jumboframes ?=20
> > > >>>>Has there been any discussion on labelstacking, and=20
> > > mainly where to=20
> > > >>>>place=20
> > > >>>>the information?=20
> > > >>>>=20
> > > >>>>Regards.=20
> > > >>>>Per=20
> > > >>>>=20
> > > >>>>=20
> > > >>>>=20
> > > >>>=20
> > > >>>=20
> > > >>>--=20
> > > >>>Loa Andersson=20
> > > >>>=20
> > > >>>Principal Networking Architect=20
> > > >>>Acreo AB                           phone:  +46 8 632 77 14=20
> > > >>>Isafjordsgatan 22                  mobile: +46 739 81 21 64=20
> > > >>>Kista, Sweden                      email: =20
> > [email-masked]=20
> > > >>>                                            [email-masked]=20
> > > >>>=20
> > > >>=20
> > > >>=20
> > > >>=20
> > > >=20
> > >=20
> > >=20
> > > --=20
> > > Loa Andersson=20
> > >=20
> > > Principal Networking Architect=20
> > > Acreo AB                           phone:  +46 8 632 77 14=20
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64=20
> > > Kista, Sweden                      email:  [email-masked]=20
> > >                                             [email-masked]=20
> > >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20

Delivery-date: Mon, 25 Jul 2005 21:38:37 +0000
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 23:37:01 +0200

hi richard

> I fully agree with Juergen's comments. The key question that's still not
> clear in my mind here is, what is the real motivation for this work?

motivations are detailed in section 4 - this said, i need some
clarification from your side to provide a more detailed answer to your
initial question

> Is it to simply support dynamic VLAN provisioning for Ethernet based on
> shortest/TE paths using GMPLS instead of using OSS?

among other - yes

> Or is it to develop an alternative CO-PS solution (to say ATM or MPLS)
> using the Ethernet frame structure, regardless of whether or not the
> Ethernet forwarding behaviour (and hardware) needs to be modified?

this is not an objective

however, and this is where the whole difficulty of the exercise stands, as
the DT was not chartered to specifically detail the data plane
behaviour/fowarding behaviour there is indeed a whole spectrum of such
behaviour that can sustain these requirements - reason why this work item
(even if we get a consensus as part of this WG) requires consultation of
the IEEE as stated in section 7.1

> If the scope of the proposal does not prevent the Ethernet forwarding
> behaviour being modified resulting in "the switching hardware, the filter
> and relay, etc. are totally different new dataplane switch", then this
seems
> to be contradictory to an earlier comment from Dimitri that said "the
> definition of any data plane behaviour is outside of the scope of the DT
> charter and the document it produced".

and this statement still holds as the DT work is concerned - note: some
individuals have expressed opinions in terms of data plane support but this
is not part of the scope of the present DT charter but these is a logical
consequence of initiating such a work item within a community of engineers

> This also raises questions regarding the role of the IEEE and what the
> applications/goals/benefits of the new Ethernet forwarding behaviour will
> be.

indeed - this is the reason why the document has explicitly stated that
consultation with the IEEE must be ensured to progress with this item

> If on the other hand the goal is to use the Ethernet data plane as it
stands
> today based on MAC address learning/switching, but to replace manual/OSS
> VLAN provisioning with a GMPLS CP, it seems to me that there is a
> fundamental difference between this proposal and all other GMPLS
solutions.
> In all the GMPLS solutions I'm aware of, the label signalled via GMPLS
(e.g.
> ATM VPI/VCI, WDM wavelength, etc.) is also used for forwarding in the
data
> plane. However in this case, data plane forwarding is not based on a
label
> (VLAN ID) but on an address, i.e. the destination MAC address. Instead,
the
> label is used to restrict the broadcast domain (e.g. to a P2P path),
which
> (following MAC flooding/learning) results in the packets belonging to a
> particular VLAN following the same path. Although the result is
effectively
> the same, the fact that forwarding is not based on the label signalled
using
> GMPLS may cause complications. For example, when a failure occurs, in
> addition to re-routing or switching over to backup paths, the MAC
> databases/tables of all effected nodes must be purged on a per VLAN
basis.

indeed, flushing and re-learning aspects must be addressed - and this is
the kind of feedback we expect to receive from the IEEE

> Looking at section 4, I agree that one obvious benefit (as mentioned in
> section 4) would be the ability to dynamically calculate loop-free
> shortest/TE paths, which would allow operators to switch off spanning
tree.
> However as Juergen points out, this is one of the goals for the TRILL WG
> (although the solution proposed is different), so I would like to
understand
> what the common/opposing goals are. Another example from section 4 is the
> point about improving scalability by introducing IP addressing with GMPLS
> rather relying on MAC addresses, which are not hierarchical. This point
is
> only valid if the control plane is being used to carry Ethernet
addresses.

i do not understand this last statement - would you clarify ? -

> So, this might be a valid point when comparing the TRILL solution to the
> GMPLS solution for example, but is not valid when comparing a standard
802.1
> Ethernet network to a GMPLS L2-LSP network. The reason being that both
> solutions are still based on data plane learning using MAC addresses and
are
> therefore both subject to the same data plane scaling issues, i.e. for
the
> solution to scale to large numbers of Ethernet customers, MAC-in-MAC
> encapsulation will be required.

indeed MAC-in-MAC is currently under definition to solve such kind of
problems, however the present approach does not intend to be used for
establishing an LSP per pair of MAC SA-DA when the #Ethernet terminating
hosts >> #network nodes;

also to clarify a specific point in the context of the present discussion,
this work item is not intended to solve ALL the specific issues and
problems related to the use of an Ethernet data plane in any operational
conditions; this document has simply identified several scenario where the
use of GMPLS protocol suite may be considered in order to facilitate (some
of the) Ethernet network operations

> Therefore, what will the benefits of using L2-LSPs with MAC-in-MAC be
> compared to encapsulating Ethernet in MPLS PWs?

some of the TRILL WG objectives are indeed overlapping with the present
effort however the respective approaches are not identical; TRILL does not
intend to make use of any signaling mechanism/source-routing protocol;
TRILL is intended to specifically cover "CAMPUS" networks (even if its
scope could be larger) by defining an "intermediate" technology between IP
and Ethernet to circumvent the drawbacks of the latter (in particular wrt
to 802.1d and related)

concerning the differences between the present work item and Ethernet over
PW/MPLS, i refer you to the introduction of the document under discussion

i hope this clarifies (at least some of your doubts)

thanks,
- dimitri.

Delivery-date: Mon, 25 Jul 2005 19:13:14 +0000
To: Loa Andersson <[email-masked]>
Cc: [email-masked], =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>, [email-masked]
From: [email-masked]
Subject: Re: dimitris question on VLAN vs label (L2SC)
Date: Mon, 25 Jul 2005 21:11:53 +0200

Delivery-date: Mon, 25 Jul 2005 16:18:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Moving LSP ownership between control plane and management plane
Date: Mon, 25 Jul 2005 18:18:11 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>
Cc: "ccamp" <[email-masked]>

Hello Diego, Adrian and all.

In my view, I feel that moving LSP ownership between MP and CP are very
useful functions for a carrier operational network, whether it be for
migration to GMPLS or for network maintenance.
As far as I understand, the I-D is a proposal for the signalling part
and does not pretend solving every associated issues. Some work will
probably be needed to implement the whole process, but this part looks
interesting to me.

I would be glad to discuss further this matter next week in Paris.

Regards

Julien=20

Julien Meuric
France Telecom
Research & Development
Core Network
2, avenue Pierre Marzin
22307 Lannion Cedex - France
Tel : + 33 (0)2 96 05 28 28
Fax : + 33 (0)2 96 05 12 52
http://www.francetelecom.com/rd/

-----Original Message-----
Behalf Of Diego Caviglia

Hi Geroge,
           sorry but I don't see how the management effort is something
related to this ID and more in general with CCAMP.

There are already RFC ID that provide tools to signal LSP with ERO
filled
up to the Label level and of course this can be done only via
management, I
don't remeber any objections on that due to NMS impact.

I'd like to discuss here (I mean in the CCAMP ML) about the ID, that is,
if
it useful and if could work and not about the difficulties it implies
for
the NMS.

I'm open to discuss, and actually I did, NMS related issues on the ITU-T
ML.

Regards

Diego

George Newsome <[email-masked]>@ops.ietf.org on 20/07/2005 11.03.00

Sent by:    [email-masked]

To:    Adrian Farrel <[email-masked]>
cc:    [email-masked], Neil Harrison <[email-masked]>, Dino
       Bramanti <[email-masked]>

Subject:    Re: Moving LSP ownership between control plane and
management
       plane

Adrian, Dino, etc.,

This thread has rapidly got too long, and I don't have the time at the
moment to argue the toss, so I'll reply as a note rather than
intersperse remarks.

On Adrian's question of which operators were at Holmdel - AT&T and
T-Systems. On do operators think they want this - some do some don't.
BT clearly don't see much value in fiddling with signaling.

You ask whether this might be done in service, and there are certainly
those who would like to see just that. Related questions are how many
times in the life of the system might this be done for the same
connection? Is it cost effective to develop a highly reliable solution
that is used just once in the life of the system?

However this is not so much a discussion of whether this could be
useful, but a technical discussion of whether changing a bit (and a slew
of procedures) in a signaling protocol actually provides the claimed
facility.

Because of the effort the management system needs to provide before
signaling might be involved, changing the signaling protocol gives the
illusion of success, yet does not provide the claimed service at all.

Once the management systems have got as far as assigning control plane
names, we can ask what happens to the cross connect object when it is
deleted as part of the hand off procedure? The behavior of this object
is that its deletion results in dropping the matrix connection, which is
exactly not required during the change over.

It is my considered opinion that fiddling with signaling merely
obfuscates the significant difficulties, which are glossed over by
stating that those difficulties occur at a different time.

Regards

             George

Adrian Farrel wrote:

> Thanks George,
>
> Useful input.
>
>
>>You asked for comments on this proposal, which was presented to ITU-T
>>Q14 experts in January of this year.
>
>
> Can you confirm that there were plenty of providers represented at the
> meeting.
>
>
>>There are so many issues involved in moving a connection from the
>>management plane to the control plane that involve intensive
management
>>action, that it is not evident that signaling need be involved at all.
>
>
> Interesting. It is certainly valuable to have a list of these issues
out
> in the open. I have made some comments in the appended meeting report.
>
> If the control plane is to take over the connection then we assume
that
> signaling state must be built so that the control plane could then
modify
> or tear down the connection. how would you propose that this be done
> without involving signaling?
>
>
>>As a personal opinion, it makes little sense to consider moving the
>>connection. It makes more sense to replace the connection with one set
>>up via the control plane, and to then delete the original management
set
>>up connection.
>
>
> The question arrises of how this would be done in a network with
limited
> resources. That is, if it is possible to set up a parallel conneciton
then
> the method you describe would be fine, but if there are not enough
> parallel resources then would you propose that a lambda (for example)
> could be used for the management-established connection and for the
> control-plane-owned connection at the same time? This might present
some
> difficulties as well.
>
> Do you have an opinion on my main question which is whether this tyoe
of
> change-over would ever be done in service?
>
> Thanks,
> Adrian
>
>
>>Excerpt of the meeting report of Q14 Experts, January 2005
>>
>>WD06 (Marconi) "G.7713 Modification in order to support Circuit
>>Migration" contains a modified version of draft G.7713 Revision as was
>>presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This
>>contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to
extend
>>the concept of Call/Connection setup to setup/adopt and release to
>>release/de-adopt. In Connection Adoption both the SNC are not actually
>>created and the LC are not actually established due to the fact that
the
>>underlying physical resources are already in place. In the
>>Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated,
>>only the Control Plane information associated with then is removed and
>>the ownership is moved to Management Plane. Attributes for indicating
>>Adoption/Dis-adoption are proposed for the INNI Connection messages.
>>
>>The discussion was mainly on the Management plane and Control plane
>>actions required before signalling is involved. The group noted that
the
>>following issues need to be addressed:
>>
>>- Naming of transport resources to the control plane.  Before a call
can
>>be placed under signalling control, links that are involved in the
>>connection need to be given control plane names.  Without these, no
>>explicit route can be formed to match the resources of the connection.
>
>
> This is pretty obvious. But actually, this is an issue with moving the
> resources from one plane to another (or having them present in both
> planes). It is certainly a prerequisite for moving the connection, but
it
> is not functionally an element of moving the connection.
>
> The draft, as I read it, assumes that these operations have been
completed
> and then asks "how do I move the connection from one plane to the
other?"
>
>
>>- Resource state while under dual CP and MP views.  After resources
are
>>given control plane names, the resources are still viewed by the
>>management plane.  It may be necessary to create a new state for the
>>resource to indicate that the management plane cannot perform some
>>actions on the connection points as the control plane is about to take
>
> over.
>
> Yes. There is certainly scope for a race condition here. I believe
that
> the I-D proposes to (try to) make the transfer an atomic action from
the
> point of view of the change-over.
>
> Note, however, that it is wrong to assume that a resource belongs only
to
> the control or to the management plane at any moment in time. This may
be
> true with respect to the ability to provision/control connections, but
> resources that are available for use by the control plane can still be
> managed through the management plane. Thus, you take a laser out of
> service through the management plane, not through the control plane.
>
>
>>- Role of discovery functions (esp. CELA).  After control plane names
>>are allocated, distributed control plane functions need to be
associated
>>and communication adjacencies formed.  This too is a precursor to any
>>signalling procedures in migrating from the MP to CP.
>
>
> Note to CCAMP: CELA is Control Entity Logical Adjacency.
> This too is "obvious".
> But this discussion seems to be wide of the mark. Before deploying a
> control plane, it is clear that this type of operation needs to take
> place. Since (within the context of CCAMP) a control plane *is* going
to
> be deployed, we can assume this operation and move on to the
discussion
in
> the draft.
>
>
>>- Similarity of migration to synchronization after CP failure and
>>subsequent recovery.  Connection control procedures might be the same
in
>>migrating a call from the MP to the CP as the situation when the CP
has
>>failed and is recovering.  Here, the network connections are already
in
>>place, but connection and call state need to be created to match it.
>>Knowledge of the call and what the connection should be is obtained
from
>>the MP for migration, and from some reliable database in the recovery
>
> case.
>
> This is a valid point.
> Control plane failure, however, is unlikely to be total. That is, it
would
> be unusual for more than one control plane link or node to fail. Thus,
in
> the control plane, the "reliable database" is distributed and recovery
can
> follow the procedures outlined in
draft-ietf-ccamp-rsvp-restart-ext-03.txt
>
> It would certainly be worth considering whether the procedures used
for
> control plane recovery could be applied to transfer of ownership from
the
> management to control plane. at the moment, I suspect that they could
not
> because the restart extensions assume a specific period during which
> signaling is associated with recovery.
>
> We would also need to look at the reverse process (transfer from CP to
MP)
> that is not possible to cover by CP restart procedures.
>
>
>>- Call awareness of migration vs. connection being unaware of
migration.
>>  When connection state is being created to match an existing
>>connection, the connection controllers (CCs) do not require awareness
of
>>why this is happening as the context could be migration or recovery.
A
>>mechanism to create control state without affecting transport plane
>>state is needed in the CCs.  Call controllers though do need migration
>>awareness as they need to obtain/derive call identification from the
MP.
>
>
> I disagree.
> Connection controllers must be able to distinguish between resources
that
> are already in use and cannot be assigned to a new connection, and
those
> that are already in use and can be assigned to a new connection
because
> the connection is replacing an existing connection. If this were
happening
> entirely within the control plane we would use resource sharing, but
when
> the operation spans the control and management planes resource
> ownership/sharing is more complex and the conneciotn controller needs
to
> be able to issue the approriate instrucitons for the assignment of the
> resources.
> On the other hand, call controllers do not need awareness of the
details
> of the realisation of the connections.
>
>
>>In summary, the group decided that it is premature to consider
>>signalling procedure before the above issues, amongst other, have been
>>studied. However the contribution does enable the group to expose in a
>>larger context the interaction between CP and MP for connection
>>migration. The above issues were included in SP24 of the G.7713 Living
>>List (see WD22).
>
>
>

Delivery-date: Mon, 25 Jul 2005 15:46:21 +0000
Content-Class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 16:44:55 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

I fully agree with Juergen's comments. The key question that's still not =
clear in my mind here is, what is the real motivation for this work? Is =
it to simply support dynamic VLAN provisioning for Ethernet based on =
shortest/TE paths using GMPLS instead of using OSS? Or is it to develop =
an alternative CO-PS solution (to say ATM or MPLS) using the Ethernet =
frame structure, regardless of whether or not the Ethernet forwarding =
behaviour (and hardware) needs to be modified?

If the scope of the proposal does not prevent the Ethernet forwarding =
behaviour being modified resulting in "the switching hardware, the =
filter and relay, etc. are totally different new dataplane switch", then =
this seems to be contradictory to an earlier comment from Dimitri that =
said "the definition of any data plane behaviour is outside of the scope =
of the DT charter and the document it produced". This also raises =
questions regarding the role of the IEEE and what the =
applications/goals/benefits of the new Ethernet forwarding behaviour =
will be.=20

If on the other hand the goal is to use the Ethernet data plane as it =
stands today based on MAC address learning/switching, but to replace =
manual/OSS VLAN provisioning with a GMPLS CP, it seems to me that there =
is a fundamental difference between this proposal and all other GMPLS =
solutions. In all the GMPLS solutions I'm aware of, the label signalled =
via GMPLS (e.g. ATM VPI/VCI, WDM wavelength, etc.) is also used for =
forwarding in the data plane. However in this case, data plane =
forwarding is not based on a label (VLAN ID) but on an address, i.e. the =
destination MAC address. Instead, the label is used to restrict the =
broadcast domain (e.g. to a P2P path), which (following MAC =
flooding/learning) results in the packets belonging to a particular VLAN =
following the same path. Although the result is effectively the same, =
the fact that forwarding is not based on the label signalled using GMPLS =
may cause complications. For example, when a failure occurs, in addition =
to re-routing or switching over to backup paths, the MAC =
databases/tables of all effected nodes must be purged on a per VLAN =
basis.

Looking at section 4, I agree that one obvious benefit (as mentioned in =
section 4) would be the ability to dynamically calculate loop-free =
shortest/TE paths, which would allow operators to switch off spanning =
tree. However as Juergen points out, this is one of the goals for the =
TRILL WG (although the solution proposed is different), so I would like =
to understand what the common/opposing goals are. Another example from =
section 4 is the point about improving scalability by introducing IP =
addressing with GMPLS rather relying on MAC addresses, which are not =
hierarchical. This point is only valid if the control plane is being =
used to carry Ethernet addresses. So, this might be a valid point when =
comparing the TRILL solution to the GMPLS solution for example, but is =
not valid when comparing a standard 802.1 Ethernet network to a GMPLS =
L2-LSP network. The reason being that both solutions are still based on =
data plane learning using MAC addresses and are therefore both subject =
to the same data plane scaling issues, i.e. for the solution to scale to =
large numbers of Ethernet customers, MAC-in-MAC encapsulation will be =
required. Therefore, what will the benefits of using L2-LSPs with =
MAC-in-MAC be compared to encapsulating Ethernet in MPLS PWs?

Regards,
Richard

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Heiles Juergen
> Sent: 25 July 2005 10:45
> To: CHO, JAI HYUNG; Heiles Juergen; [email-masked]
> Cc: [email-masked]
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
>=20
>=20
> Dear Jaihyung,
>=20
> you mention several options that could be used as a label.=20
> Most of them have strong impacts on the data plane and=20
> introduce new layer networks. Is this in the scope of CCAMP?=20
> What is the goal, to introduce a control plane for a existing=20
> L2 technology or introduce a new L2 technology? What would be=20
> the benefit of such a new L2 co switching technology compared=20
> to Ethernet over MPLS as defined by PWE3 and L2VPN?
> You mentioned to use the MAC address or part of it as a=20
> label. The TRILL working group is defining shortest path=20
> routing for Ethernet. How would this fit together?
>=20
>=20
> Regards
>=20
> Juergen
>  =20
>=20
>=20
>=20
>=20
> > From: CHO, JAI HYUNG [mailto:[email-masked]]=20
> > Sent: Saturday, July 23, 2005 6:19 AM
> > To: Heiles Juergen; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> >=20
> >=20
> > Dear Juergen, Par and all,
> >=20
> > The proposed framework of L2SC was not intended to suggest=20
> > any specific solution. It is still an open question.=20
> > As Adrian noted, it only aims to present requirements=20
> > as in scenarios that may drive people toward next step in many=20
> > viable solutions.
> >=20
> > In fact, there are other options we may also consider for L2=20
> > label encoding.=20
> > IEEE 802.1 Ethernet bridges forward frames based on 48bits of=20
> > MAC address,=20
> > and additionally using VLAN tag.=20
> >=20
> > When the purpose of GMPLS control over Ethernet is not to=20
> > create new dataplane=20
> > but to utilize IEEE 802.1 bridge architecture, we may=20
> consider using=20
> > one of the two forwarding methods, MAC forwarding or VLAN=20
> forwarding.=20
> > (and perhaps any other combination of fields in MAC, but I'll=20
> > not discuss it)
> > =20
> > Use of VLAN ID for label encoding may automate VLAN configuration=20
> > using IP protocols. However, GMPLS protocol cannot use the=20
> > field exclusively=20
> > because public/private operators already use VLAN for various=20
> > purpose.=20
> > There is a potential conflict with existing use of VLAN and=20
> > GMPLS use of VLAN label. =20
> > Furthermore, scalability of VLAN ID has been frequently noted=20
> > as weakness=20
> > because the size of VLAN ID is at most 4096 (12bit).=20
> >=20
> > The scalability may be improved if the scope of VLAN label is=20
> > confined to=20
> > link-local, and some additional swapping function of VLAN ID=20
> > is introduced in=20
> > Internal Sublayer [802.1D] of GMPLS implemented switch.=20
> > However, this will only be effective when the configuration=20
> > of network=20
> > is mesh structure that multiple LSP paths exist. If the=20
> > configuration of network=20
> > is star or tree shape, as normal configuration of access network,=20
> > LSPs concentrate in root node and total number of=20
> > LSPs that the network can hold still be limited by available=20
> > label space=20
> > at a few root links.=20
> >=20
> > For these reasons, I do not think any form of VLAN ID label is=20
> > an appropriate choice for layer-2 label encoding.
> > =20
> > There are some other proposals assuming new assignment of Ethernet=20
> > Length/Type value (e.g. new TPID in VLAN tag) and re-definition of=20
> > information fields placed between 802.3 MAC header and IP packet.=20
> > In this case, only the format of VLAN tag or extended VLAN tag=20
> > is borrowed, however, inside the switching hardware, the=20
> > filter and relay,=20
> > etc. are totally different new dataplane switch.
> >=20
> > I do not see such approach is a GMPLS implementation for Ethernet=20
> > because the core switching technique is not 802.1 Ethernet=20
> > bridge at all.
> > =20
> > The other option we may consider is using MAC address filed=20
> as below.
> > =20
> >=20
> > +-------+-------+-------+-------+-------+-------+=20
> > | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte |=20
> > +-------+-------+-------+-------+-------+-------+
> > +-----------------------+-----------------------+=20
> > |  OUI Prefix (=3DGMPLS)  |   DA-label (24bit)    |=20
> > +-----------------------+-----------------------+=20
> > |  OUI Prefix (=3DGMPLS)  |   SA-label (24bit)    |=20
> > +---------------+-------+-----------------------+=20
> > | Length/Type   |=20
> > +---------------+
> > =20
> >=20
> > IEEE is designated by the ISO Council to act as the=20
> > registration authority=20
> > for the higher three-octet of OUI number in the MAC address=20
> > to be used by manufacturer. Ethernet manufacturer may generate=20
> > global unique MAC address using the OUI prefix and address block of=20
> > lower three-octet (24bit). Taking advantage of the=20
> addressing scheme,=20
> > GMPLS may use the lower three-octet exclusively if a unique=20
> > OUI number=20
> > is reserved for the protocol. With this labeling scheme, GMPLS will=20
> > control MAC forwarding entry, not VLAN table.
> > =20
> > All Ethernet frames controlled by GMPLS will have identical=20
> > OUI number=20
> > that they can easily be distinguished from other Ethernet frames.=20
> > In principle, the label lookup hardware is identical to MAC lookup=20
> > hardware in this labeling scheme. Therefore GMPLS implemented=20
> > switch may still function as normal Ethernet bridge to the frames=20
> > that OUI number is not GMPLS. This also facilitates GMPLS=20
> implemented=20
> > switches being deployed in operating Ethernet with minimum=20
> > service disruption.
> > =20
> > Note also that above proposed label encoding method is transparent=20
> > to the use of Ethernet Length/Type field. End-user device may use=20
> > the Length/Type field as defined in IEEE 802.3 protocol.=20
> > It also allows network operators configure VLAN for their own=20
> > purpose.=20
> > When IEEE 802.1p is used in conjunction with L2-LSP, the priority=20
> > field of VLAN tag can also be used for imposing consistent TE=20
> > policy in=20
> > legacy switches and GMPLS switches.
> > =20
> > Any way, my conclusion is, there are other options we may consider,=20
> > and this issue is still open to discuss.
> > =20
> > Thanks,
> > =20
> > Sincerely,
> > =20
> > Jaihyung
> > =20
> > =20
> > =20
> > =20
> >=20
> > -----?? ???-----=20
> > ?? ??: "Heiles Juergen" <[email-masked]>=20
> > ?? ??: 2005-07-22 ?? 10:23:43=20
> > ?? ??: "Loa Andersson" <[email-masked]>, "[email-masked]"=20
> > <[email-masked]>=20
> > ??: "[email-masked]" <[email-masked]>, "[email-masked]"=20
> > <[email-masked]>=20
> > ??: RE: Frameformat in a l2cs gmpls rnvironment.=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > Loa,=20
> >=20
> > I interpret the ID as a proposal to use GMPLS for VLAN setup.=20
> > So GMPLS and VLAN to not compete. The VLAN is at the data=20
> > plane and GMPLS at the control plane. The question is how and=20
> > should different control plane techniques like GMPLS and=20
> > (GVRP and STB) work together?=20
> >=20
> > Regards=20
> >=20
> > Juergen=20
> >=20
> >=20
> > > -----Original Message-----=20
> > > From: [email-masked]=20
> > > [mailto:[email-masked]] On Behalf Of Loa Andersson=20
> > > Sent: Friday, July 22, 2005 2:53 PM=20
> > > To: [email-masked]=20
> > > Cc: [email-masked]; [email-masked]=20
> > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.=20
> > >=20
> > > Richard,=20
> > >=20
> > > I agree to most of this. Since we have doubts about the viability=20
> > > of taking GMPLS all the way to end-user or enterprise I think it=20
> > > would be good, from a wg perspective, if we agreed to solve the=20
> > > core network problems first.=20
> > >=20
> > > Do you have any comment on the requirement to run both VLANs and=20
> > > GMPLS on the same switch?=20
> > >=20
> > > /Loa=20
> > >=20
> > > [email-masked] wrote:=20
> > > > Regardless of whether or not a switch is directly connected=20
> > >  > to hosts, it must be able to forward packets using the=20
> > > connectionless=20
> > >  > Ethernet data plane. This is due to the fundamental=20
> > > requirement that=20
> > >  > for GMPLS switches to be able to exchange control=20
> > information with=20
> > >  > each other, a data plane for control traffic must be present.=20
> > >  > This is akin to using the IP data plane for MPLS=20
> > signalling in an=20
> > >  > IP/MPLS network. An alternative would be to use a static=20
> > reserved=20
> > >  > L2-LSP for control traffic in the same way that reserved=20
> > VPI/VCIs=20
> > >  > are used for PNNI signalling in ATM.=20
> > > >=20
> > > > Regarding connecting hosts to GMPLS switches, I=20
> personally don't=20
> > >  > think extending L2-LSPs into the enterprise/home network is=20
> > >  > commercially viable. However, if you do want to use=20
> > GMPLS switches=20
> > >  > in the home/enterprise network and for some reason=20
> don't want to=20
> > >  > extend L2-LSPs down to the host then you will not be=20
> performing=20
> > >  > normal Ethernet Mac address switching anyway. Instead you will=20
> > >  > need some kind of policy on the switch that maps=20
> connectionless=20
> > >  > Ethernet packets (e.g. based on MAC src/dest, 802.1p,=20
> VLAN) to a=20
> > >  > L2-LSP. This is because multiple L2-LSPs to the same=20
> destination=20
> > >  > (e.g. a gateway router) may exist for different services/flows=20
> > >  > (e.g. video download, VoIP call, etc.).=20
> > > >=20
> > > > Regards,=20
> > > > Richard=20
> > > >=20
> > > >=20
> > > >>-----Original Message-----=20
> > > >>From: [email-masked]=20
> > [mailto:[email-masked]]On=20
> > > >>Behalf Of Par Mattsson=20
> > > >>Sent: 22 July 2005 11:42=20
> > > >>To: Loa Andersson=20
> > > >>Cc: [email-masked]=20
> > > >>Subject: Re: Frameformat in a l2cs gmpls rnvironment.=20
> > > >>=20
> > > >>=20
> > > >>=20
> > > >>>Per and Dimitri,=20
> > > >>>=20
> > > >>>I would like to come down stronger than that, for me it is=20
> > > >>>a very strong requirement that the same switch can handle=20
> > > >>>both VLANs and GMPLs trafic correctly. I can't dsee how that=20
> > > >>>could be done if using the VLAN tpid to indicate GMPLS=20
> > > >>>traffic.=20
> > > >>=20
> > > >>If you ever want that same switch to handle traffic for a=20
> > directly=20
> > > >>connected  host (not to uncommen) you would want that to=20
> > use normal=20
> > > >>ethernet macaddress switching. So of course you do not want=20
> > > to have to=20
> > > >>choose between vlan and gmpls, you would want both at the=20
> > same time.=20
> > > >>=20
> > > >>/per=20
> > > >>=20
> > > >>=20
> > > >>=20
> > > >>>/Loa=20
> > > >>>=20
> > > >>>Par Mattsson wrote:=20
> > > >>>=20
> > > >>>>>hi par, one of the possibilities that has been considered=20
> > > >>=20
> > > >>to cope with=20
> > > >>=20
> > > >>>>>this requirement is to use a dedicated TPID for the=20
> > > >>=20
> > > >>Ethernet labeled=20
> > > >>=20
> > > >>>>>frames; this would allow differentiated processing with=20
> > > non-labeled=20
> > > >>>>>framesthanks.=20
> > > >>>>=20
> > > >>>>=20
> > > >>>>That seems to make more sence. If that frame is to be=20
> > sized like a=20
> > > >>>>802.1q=20
> > > >>>>frame. There is not that much space left to a label. Or is=20
> > > >>=20
> > > >>the demand to=20
> > > >>=20
> > > >>>>use jumboframes ?=20
> > > >>>>Has there been any discussion on labelstacking, and=20
> > > mainly where to=20
> > > >>>>place=20
> > > >>>>the information?=20
> > > >>>>=20
> > > >>>>Regards.=20
> > > >>>>Per=20
> > > >>>>=20
> > > >>>>=20
> > > >>>>=20
> > > >>>=20
> > > >>>=20
> > > >>>--=20
> > > >>>Loa Andersson=20
> > > >>>=20
> > > >>>Principal Networking Architect=20
> > > >>>Acreo AB                           phone:  +46 8 632 77 14=20
> > > >>>Isafjordsgatan 22                  mobile: +46 739 81 21 64=20
> > > >>>Kista, Sweden                      email: =20
> > [email-masked]=20
> > > >>>                                            [email-masked]=20
> > > >>>=20
> > > >>=20
> > > >>=20
> > > >>=20
> > > >=20
> > >=20
> > >=20
> > > --=20
> > > Loa Andersson=20
> > >=20
> > > Principal Networking Architect=20
> > > Acreo AB                           phone:  +46 8 632 77 14=20
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64=20
> > > Kista, Sweden                      email:  [email-masked]=20
> > >                                             [email-masked]=20
> > >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20

Delivery-date: Mon, 25 Jul 2005 14:37:03 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: "Heiles Juergen" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Bcc: 
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 23:37:15 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message

hi, Juergen
 
see some in-line below,

>> 3. use lower 3 bytes of MAC address for L2 label encoding. 
>> 
>> 802.1Q bridge forwards Ethernet frames using two dataplane tables 
>> - MAC forwarding table and VLAN forwarding table. 
>> Bridge control protocols, such as GARP, GVRP, GMRP, 
>> manipulate one of the two dataplane entities. 
>> 
>> Similarly, option 1 and 3 are about which one of two 
>> dataplane entities 
>> GMPLS protocol should control on behalf of bridge control protocols. 
>> The two proposals do not intend to modify bridge behavior 
>> seriously, such as MAC learning, aging, filtering. 
>> Therefore, the approaches 1 and 3 are in the scope of CCAMP. 
> 
>Even so your option 3 may not change the hardware it totaly changes 
>the forwarding behaviour as it redefines the meaning of a MAC address. 
>The MAC address is a end station address that identfies the source 
>and sink of the MAC frame. In your proposal it will be used as link 
>local label. 

There's no (in principle) physical change in the MAC forwarding behavior. 
GMPLS will configure MAC forwarding entry as if static entry 
is configured in MAC table by operator.

Suppose a network that Ethernet bridges interconnect routers. 
Normally single L2 data path is established between routers by MAC learning. 
If an operator manually configure another MAC forwarding path in the 
bridges, two L2 paths are established between routers.

Of course such configuration is not possible in 802.1 bridged network. 
However, GMPLS implementation may automate such configuration 
of semi-static MAC forwarding entry that otherwise be configured 
manually by operator.

>It would be the same as if MPLS would use a dedicated 
>IP address range as lable instead of its own label.

You may think it different perspective. 
MPLS forwards data using shim header, and the shim label is, 
again, encapsulated by Ethernet header. From the view of 
input and output link, Ethernet header (i.e. MAC addresses) is 
replaced at every hop together with shim label.

What if the router knows which Ethernet header is to be replaced 
to which Ethernet header in next link? Does it still need to lookup 
MPLS shim header at L3 level? In this case, it is sufficient for 
the switch performing swap operation in L2SC level. 
 
The whole idea of GMPLS is employing common control over 
underlying transport method, and in the case of Ethernet, 
the major transport method of Ethernet frame is MAC forwarding 
using Ethernet address, and so is GMPLS implementation for Ethernet.

>What will happen with the original MAC address when you enter 
>such a GMPLS Ethernet domain? Will you add a new "MAC header"?

You are actually referring three cases,

1. in local network that host forwards Ethernet frame via L2-LSP 
2. in core edge that provides L2VPN service 
3. in network that legacy switch and GMPLS switches are 
   interconnected.
 
In 1, Ethernet address is swapped to GMPLS prefixed address 
and forwarded via established L2-LSP.

In 2, user frames are encapsulated as you said.

In 3, normal Ethernet frames are forwarded via normal STP path, 
however GMPLS frames may be forwarded via different path 
established using RSVP-TE.

...... 
>> 
>> The benefit of L2SC switch is explained in section 4 of 
>> <draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt> 
>> 
>> Overall objective is improving scalability, traffic engineering (TE) 
>> characteristics of 802.1 bridge that it can be reliable, manageable 
>> enough to replace some core routers. 
> 
>This is also provided by Ethernet over MPLS even with label stacking.

but not by Ethernet bridges. 
When the price of Ethernet bridge is compared to MPLS router just by 
port and switching capacity, it is nearly ten times cheaper. 
What we are trying to do is delivering the capability of MPLS switch 
at the price of Ethernet switch.

>> The switching technique you mentioned above, such as 
>> Ethernet over MPLS as defined by PWE3 and L2VPN, 
>> are all actually router based technology, however this 
>> work is based on simple bridge architecture. 
>> Cost-effectiveness is the key differentiator. 
>> 
>This is what I hear often and what I mean with "we still call 
>it Ethernet as it will be cahep and simple as todays Ehternet". 
>In the end the same functionality is needed: lable lookup, 
>label swapping, signaling protocol, routing protocol, discovery protocol, ... 
>So from the functionality and architecture point of view no difference exists.

I understand well how today's routers become a machine of millions of gates. 
This is the solution I struggled for some years to simplify it best. 
That's why I am trying to preserve the original simplicity of hardware 
architecture of 802.1 Ethernet bridge. 

>One advantage compared to Ethernet over MPLS I see, is that 
>MPLS has to be again mapped into Ethernet for transport. 
>This addtional Ethernet layer is not needed.
>In your response to Richard you mention to use a simpler routing 
>for Ethernet in this enviroment using dynamic learning like in Ethernet. 
>How about a unified GMPLS control plane and restoration. 
>Will you introduce another spanning tree?

No, I'll just propose another way to achieve TE-LSP 
without relying on pre-established routing table. 
Please take a time to see 
<draft-jaihyung-ccamp-arpsignal-00.txt> 
and read the section about flood-routing.

thanks
 
Jaihyung 

-----?? ???----- 
?? ??: "Heiles Juergen" <[email-masked]> 
?? ??: 2005-07-25 ?? 9:32:40 
?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: "[email-masked]" <[email-masked]> 
??: RE: Frameformat in a l2cs gmpls rnvironment. 

Dear Jaihyung, 

the discussion now goes too much into implementations, however I would like to add my comments/questions. 

Regards 

Juergen 

> From: CHO, JAI HYUNG [mailto:[email-masked]] 
> Sent: Monday, July 25, 2005 1:40 PM 
> To: Heiles Juergen; [email-masked] 
> Cc: [email-masked] 
> Subject: RE: Frameformat in a l2cs gmpls rnvironment. 
> 
> 
.... 
> 3. use lower 3 bytes of MAC address for L2 label encoding. 
>  
> 
> 802.1Q bridge forwards Ethernet frames using two dataplane tables 
> - MAC forwarding table and VLAN forwarding table. 
> Bridge control protocols, such as GARP, GVRP, GMRP, 
> manipulate one of the two dataplane entities. 
> 
> Similarly, option 1 and 3 are about which one of two 
> dataplane entities 
> GMPLS protocol should control on behalf of bridge control protocols. 
> The two proposals do not intend to modify bridge behavior 
> seriously, such as MAC learning, aging, filtering. 
> Therefore, the approaches 1 and 3 are in the scope of CCAMP. 

Even so your option 3 may not change the hardware it totaly changes the forwarding behaviour as it redefines the meaning of a MAC address. The MAC address is a end station address that identfies the source and sink of the MAC frame. In your proposal it will be used as link local label. It would be the same as if MPLS would use a dedicated IP address range as lable instead of its own label. 
What will happen with the original MAC address when you enter such a GMPLS Ethernet domain? Will you add a new "MAC header"? 

...... 
> 
> The benefit of L2SC switch is explained in section 4 of 
> <draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt> 
> 
> Overall objective is improving scalability, traffic engineering (TE) 
> characteristics of 802.1 bridge that it can be reliable, manageable 
> enough to replace some core routers. 

This is also provided by Ethernet over MPLS even with label stacking. 

> The switching technique you mentioned above, such as 
> Ethernet over MPLS as defined by PWE3 and L2VPN, 
> are all actually router based technology, however this 
> work is based on simple bridge architecture. 
> Cost-effectiveness is the key differentiator. 
>  
This is what I hear often and what I mean with "we still call it Ethernet as it will be cahep and simple as todays Ehternet". 
In the end the same functionality is needed: lable lookup, label swapping, signaling protocol, routing protocol, discovery protocol, ... 
So from the functionality and architecture point of view no difference exists. 
One advantage compared to Ethernet over MPLS I see, is that MPLS has to be again mapped into Ethernet for transport. This addtional Ethernet layer is not needed. 
In your response to Richard you mention to use a simpler routing for Ethernet in this enviroment using dynamic learning like in Ethernet. How about a unified GMPLS control plane and restoration. Will you introduce another spanning tree? 

.. 

Delivery-date: Mon, 25 Jul 2005 13:10:44 +0000
Date: Mon, 25 Jul 2005 15:06:54 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To:  [email-masked]
CC: =?ISO-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>,  [email-masked]
Subject: dimitris question on VLAN vs label (L2SC)

Dimitri,

the simple answer is that I need my VLANs, they give me a
good, understood and reliable service, even when I can set up
LSP through an Ethernet network.

As I see it VLANsd and LSPs is not the same, if we use the
VLAN to encapsulate LSPs we get into a problem of distinguishing
between a VLAN and an LSP.

VLAN is a scarce resource, 2048 per network (yeah - know I can
increase it by managing the VLAN budget carefully, but it is
kind of awkward). I think we should aim for something like 2000
labels per link (I wouldn't object if we can do better).

I'd also say that the the Ethernet network needs to be able
to handle all types of traffic, gmpls, tagged and untagged
over the same swtich. Don't see that a interface separation would
help since VLAN are per platform.

Did I answer your questions?

/Loa

[email-masked] wrote:
> loa,
> 
> during the discussion loop one of the possibilities that came out 
> consisted in using a dedicated TPID value (different from the value 
> 0x8100 used in .1q), that would precede the encoded value as part of the 
> TCI
> 
> would you please clarify your specific concern ? i would like also to 
> point out that there are several cases here
> 
> 1. both type of traffic on the same switch but not necessarily on the 
> same interface
> 
> 2. both type of traffic on the same interface
> 
> with the following variant
> 
> 2a. interface must accommodate any type of traffic (un-/tagged and labeled)
> 
> 2b. interface must accommodate tagged and labeled type of traffic only
> 
> thanks,
> 
> - dimitri.
> 
> *Loa Andersson <[email-masked]>*
> Sent by: [email-masked]
> 07/22/2005 12:04 ZE2
> 
> To: Pär Mattsson <[email-masked]>
> cc: [email-masked]
> bcc:
> Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> 
> 
> Per and Dimitri,
> 
> I would like to come down stronger than that, for me it is
> a very strong requirement that the same switch can handle
> both VLANs and GMPLs trafic correctly. I can't dsee how that
> could be done if using the VLAN tpid to indicate GMPLS
> traffic.
> 
> /Loa
> 
> Pär Mattsson wrote:
>  >>hi par, one of the possibilities that has been considered to cope with
>  >>this requirement is to use a dedicated TPID for the Ethernet labeled
>  >>frames; this would allow differentiated processing with non-labeled
>  >>framesthanks.
>  >
>  >
>  > That seems to make more sence. If that frame is to be sized like a 802.1q
>  > frame. There is not that much space left to a label. Or is the demand to
>  > use jumboframes ?
>  > Has there been any discussion on labelstacking, and mainly where to place
>  > the information?
>  >
>  > Regards.
>  > Per
>  >
>  >
>  >
> 
> 
> --
> Loa Andersson
> 
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
> 
>                                                                                           [email-masked]

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Mon, 25 Jul 2005 12:33:22 +0000
From: Heiles Juergen <[email-masked]>
To: "CHO, JAI HYUNG" <[email-masked]>, Heiles Juergen <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 14:32:40 +0200

Dear Jaihyung,

the discussion now goes too much into implementations, however I would like to add my comments/questions. 

Regards

Juergen

> From: CHO, JAI HYUNG [mailto:[email-masked]] 
> Sent: Monday, July 25, 2005 1:40 PM
> To: Heiles Juergen; [email-masked]
> Cc: [email-masked]
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> 
> 
.....
> 3. use lower 3 bytes of MAC address for L2 label encoding.
>  
> 
> 802.1Q bridge forwards Ethernet frames using two dataplane tables 
> - MAC forwarding table and VLAN forwarding table. 
> Bridge control protocols, such as GARP, GVRP, GMRP, 
> manipulate one of the two dataplane entities.
> 
> Similarly, option 1 and 3 are about which one of two 
> dataplane entities 
> GMPLS protocol should control on behalf of bridge control protocols. 
> The two proposals do not intend to modify bridge behavior 
> seriously, such as MAC learning, aging, filtering. 
> Therefore, the approaches 1 and 3 are in the scope of CCAMP.

Even so your option 3 may not change the hardware it totaly changes the forwarding behaviour as it redefines the meaning of a MAC address. The MAC address is a end station address that identfies the source and sink of the MAC frame. In your proposal it will be used as link local label. It would be the same as if MPLS would use a dedicated IP address range as lable instead of its own label.
What will happen with the original MAC address when you enter such a GMPLS Ethernet domain? Will you add a new "MAC header"?

.......
> 
> The benefit of L2SC switch is explained in section 4 of 
> <draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt>
> 
> Overall objective is improving scalability, traffic engineering (TE) 
> characteristics of 802.1 bridge that it can be reliable, manageable 
> enough to replace some core routers.

This is also provided by Ethernet over MPLS even with label stacking.

> The switching technique you mentioned above, such as 
> Ethernet over MPLS as defined by PWE3 and L2VPN,
> are all actually router based technology, however this
> work is based on simple bridge architecture.
> Cost-effectiveness is the key differentiator.
>  
This is what I hear often and what I mean with "we still call it Ethernet as it will be cahep and simple as todays Ehternet".
In the end the same functionality is needed: lable lookup, label swapping, signaling protocol, routing protocol, discovery protocol, ...
So from the functionality and architecture point of view no difference exists.
One advantage compared to Ethernet over MPLS I see, is that MPLS has to be again mapped into Ethernet for transport. This addtional Ethernet layer is not needed.
In your response to Richard you mention to use a simpler routing for Ethernet in this enviroment using dynamic learning like in Ethernet. How about a unified GMPLS control plane and restoration. Will you introduce another spanning tree?

...

Delivery-date: Mon, 25 Jul 2005 11:58:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Mon, 25 Jul 2005 12:56:27 +0100
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Tom,

G.805 (co) and G.809 (cl) discuss general functional architectural
properties of the data-plane network.  Specific technology ones are then
generated from these.  We've found this stuff invaluable for many
reasons....but its esp crucial if you want sound management information
models.....and for large operators esp this is a very important topic
IMO.   I find it most useful however in a day-day sense (at least in
terms of the principles its based on) to be able to quickly analyse a
technology and spot its strengths/weaknesses. =20

Of course a data-plane network can carry traffic or control/management
protocols.  When you are dealing with co mode networks its quite
sensible (and forced in case of the co-cs mode) to have different
data-plane networks working in the same network system.  But see my post
to Igor a while back wrt to what this means when adapting these to be
carried by a lower layer network.  There are rather important network
owenship issues here.

Note also the design (eg for survivability) of the traffic and
control/management data-plane networks can be very different.  And it is
particularly important that the control/management-plane networks only
take their design cues from the duct-graph (you must know about real
physical separacy here if you want to do a good job)

The stuff in SG15 on ASON (various Recs here) discuss control-plane
arch.  And there is a stuff in the M series Recs on management
arch......but I'd look to TMF for this.

If you want to know a good text book, I've still to find anything better
than Reid/Sexton 'Broadband networking'.  Chapters 3 and 4 therein give
an excellent introduction to func arch and what this means for the 3
planes.....but there is lots of other good stuff in here on many topics.
Bit old-hat wrt technologies discussed, but this is not so importnat as
the general networking principles are invariant of technology (provided
one understands the basic modal differences).

regards, neil

> From: Tom Petch [mailto:[email-masked]]=20
> Sent: 23 July 2005 16:58
> To: Harrison,N,Neil,IKM1 R
> Cc: [email-masked]
> Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in=20
> a l2cs gmpls rnvironment.]
>=20
>=20
> Neil
>=20
> Is there an ITU-T Recommendation that gives an architectural=20
> definition of what it means by control plane, data plane,=20
> management plane, user plane, traffic dataplane, control data=20
> plane etc etc?
>=20
> I know what I mean when I use the terms but am not sure I=20
> always know what others mean.
>=20
> Tom Petch
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>;=20
> <[email-masked]>; <[email-masked]>;=20
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, July 23, 2005 2:15 PM
> Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in=20
> a l2cs gmpls rnvironment.]
>=20
>=20
> > > > IP is cl-ps networking techology period....and its
> > > > jolly important, but PLEASE don't try and feed me any=20
> of this 'IP=20
> > > > control plane' nonsense.
> >
> > JD:  Over the years I have enjoyed Neil's rants immensely,=20
> but I have=20
> > to say that this one is a classic.
>=20
> NH=3D> Thanks John for the kind words....its good to know=20
> you've had at least something to smile about ;-)
>=20
> Seriously though, see my updated response to Adrian.  But if=20
> you are still struggling to grasp what I mean by the above=20
> (out of context
> quote) try this:
>=20
> A single cl-ps IP network carrying traffic and everything=20
> else (eg public Internet) is very different animal to a co-cs=20
> network system where the traffic data-plane network and=20
> control/management data-planes network are logically=20
> disjoint, ie the role of IP in the latter is importantly=20
> different to the role of IP in the former...and let's hope=20
> never the 2 shall meet.
>=20
> regards, neil
>=20
>=20
>=20

Delivery-date: Mon, 25 Jul 2005 11:39:32 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: "Heiles Juergen" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Bcc: 
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 20:39:47 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message

hi, Juergen

>Dear Jaihyung, 
> 
>you mention several options that could be used as a label. 
>Most of them have strong impacts on the data plane and introduce 
>new layer networks. Is this in the scope of CCAMP? What is the goal, 

In below mail, I discussed about three proposed approaches.

1. using VLAN tag as it is for L2 label encoding.

2. defining new protocol ID (TPID) and borrow VLAN tag format, 
?or extended VLAN tag to implement label swapping.

3. use lower 3 bytes of MAC address for L2 label encoding.

802.1Q bridge forwards Ethernet frames using two dataplane tables 
- MAC forwarding table and VLAN forwarding table. 
Bridge control protocols, such as GARP, GVRP, GMRP, 
manipulate one of the two dataplane entities.

Similarly, option 1 and 3 are about which one of two dataplane entities 
GMPLS protocol should control on behalf of bridge control protocols. 
The two proposals do not intend to modify bridge behavior 
seriously, such as MAC learning, aging, filtering. 
Therefore, the approaches 1 and 3 are in the scope of CCAMP.

(% note however, I would regard implementing label swapping 
function is acceptable change considering the Internal Sublayer 
design of 802.1D bridge.)

However, option 2 is about what TPID code we will 
choose to implement new switching function. 
The switch of this implementation should have new hardware 
design in addition to normal bride hardware. 
I think such proposal as option 2 is out of CCAMP scope. 

>to introduce a control plane for a existing L2 technology or 
>introduce a new L2 technology? What would be the benefit 
>of such a new L2 co switching technology compared to Ethernet 
>over MPLS as defined by PWE3 and L2VPN?

The benefit of L2SC switch is explained in section 4 of 
<draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt>

Overall objective is improving scalability, traffic engineering (TE) 
characteristics of 802.1 bridge that it can be reliable, manageable 
enough to replace some core routers.
The switching technique you mentioned above, such as 
Ethernet over MPLS as defined by PWE3 and L2VPN,
are all actually router based technology, however this
work is based on simple bridge architecture.
Cost-effectiveness is the key differentiator.

In access or enterprise network, capability of providing end-to-end 
L2-LSP will enable service providers policing, measuring, charging 
application flows using Ethernet based network. This will eventually 
improve income structure and introduce new session based commercial 
service. I have been discussing this aspect in mail thread of 
title 'End-to-end L2-LSP'.  Please read the mail thread and comment
on the discussion.

>You mentioned to use the MAC address or part of it as a label. 
>The TRILL working group is defining shortest path routing for Ethernet. 
>How would this fit together?

TRILL employs new encapsulation layer outside of Ethernet frames. 
However in my proposal of option-3, I simply use the Ethernet header 
to encode GMPLS label. 

The overall format of rbridge is  [Ethernet][r-tag][Ethernet][ data..] 
It is not LSP based technology but a connectionless routing bridge. 
TTL count is very important in rbridge because frames are routed 
hop-by-hop and it may loop.

Whereas in option-3 above, Ethernet frames that have certain 
OUI prefix in MAC address are forwarded via a path that 
GMPLS protocol has configured on MAC forwarding table.

Thanks
 
Jaihyung

-----?? ???----- 
?? ??: "Heiles Juergen" <[email-masked]> 
?? ??: 2005-07-25 ?? 6:44:34 
?? ??: "CHO, JAI HYUNG" <[email-masked]>, "Heiles Juergen" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: "[email-masked]" <[email-masked]> 
??: RE: Frameformat in a l2cs gmpls rnvironment. 

Dear Jaihyung, 

you mention several options that could be used as a label. Most of them have strong impacts on the data plane and introduce new layer networks. Is this in the scope of CCAMP? What is the goal, to introduce a control plane for a existing L2 technology or introduce a new L2 technology? What would be the benefit of such a new L2 co switching technology compared to Ethernet over MPLS as defined by PWE3 and L2VPN? 
You mentioned to use the MAC address or part of it as a label. The TRILL working group is defining shortest path routing for Ethernet. How would this fit together? 

Regards 

Juergen 

> From: CHO, JAI HYUNG [mailto:[email-masked]] 
> Sent: Saturday, July 23, 2005 6:19 AM 
> To: Heiles Juergen; [email-masked] 
> Cc: [email-masked] 
> Subject: RE: Frameformat in a l2cs gmpls rnvironment. 
> 
> 
> Dear Juergen, Par and all, 
> 
> The proposed framework of L2SC was not intended to suggest 
> any specific solution. It is still an open question. 
> As Adrian noted, it only aims to present requirements 
> as in scenarios that may drive people toward next step in many 
> viable solutions. 
> 
> In fact, there are other options we may also consider for L2 
> label encoding. 
> IEEE 802.1 Ethernet bridges forward frames based on 48bits of 
> MAC address, 
> and additionally using VLAN tag. 
> 
> When the purpose of GMPLS control over Ethernet is not to 
> create new dataplane 
> but to utilize IEEE 802.1 bridge architecture, we may consider using 
> one of the two forwarding methods, MAC forwarding or VLAN forwarding. 
> (and perhaps any other combination of fields in MAC, but I'll 
> not discuss it) 
>  
> Use of VLAN ID for label encoding may automate VLAN configuration 
> using IP protocols. However, GMPLS protocol cannot use the 
> field exclusively 
> because public/private operators already use VLAN for various 
> purpose. 
> There is a potential conflict with existing use of VLAN and 
> GMPLS use of VLAN label.  
> Furthermore, scalability of VLAN ID has been frequently noted 
> as weakness 
> because the size of VLAN ID is at most 4096 (12bit). 
> 
> The scalability may be improved if the scope of VLAN label is 
> confined to 
> link-local, and some additional swapping function of VLAN ID 
> is introduced in 
> Internal Sublayer [802.1D] of GMPLS implemented switch. 
> However, this will only be effective when the configuration 
> of network 
> is mesh structure that multiple LSP paths exist. If the 
> configuration of network 
> is star or tree shape, as normal configuration of access network, 
> LSPs concentrate in root node and total number of 
> LSPs that the network can hold still be limited by available 
> label space 
> at a few root links. 
> 
> For these reasons, I do not think any form of VLAN ID label is 
> an appropriate choice for layer-2 label encoding. 
>  
> There are some other proposals assuming new assignment of Ethernet 
> Length/Type value (e.g. new TPID in VLAN tag) and re-definition of 
> information fields placed between 802.3 MAC header and IP packet. 
> In this case, only the format of VLAN tag or extended VLAN tag 
> is borrowed, however, inside the switching hardware, the 
> filter and relay, 
> etc. are totally different new dataplane switch. 
> 
> I do not see such approach is a GMPLS implementation for Ethernet 
> because the core switching technique is not 802.1 Ethernet 
> bridge at all. 
>  
> The other option we may consider is using MAC address filed as below. 
>  
> 
> +-------+-------+-------+-------+-------+-------+ 
> | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte | 
> +-------+-------+-------+-------+-------+-------+ 
> +-----------------------+-----------------------+ 
> |  OUI Prefix (=GMPLS)  |   DA-label (24bit)    | 
> +-----------------------+-----------------------+ 
> |  OUI Prefix (=GMPLS)  |   SA-label (24bit)    | 
> +---------------+-------+-----------------------+ 
> | Length/Type   | 
> +---------------+ 
>  
> 
> IEEE is designated by the ISO Council to act as the 
> registration authority 
> for the higher three-octet of OUI number in the MAC address 
> to be used by manufacturer. Ethernet manufacturer may generate 
> global unique MAC address using the OUI prefix and address block of 
> lower three-octet (24bit). Taking advantage of the addressing scheme, 
> GMPLS may use the lower three-octet exclusively if a unique 
> OUI number 
> is reserved for the protocol. With this labeling scheme, GMPLS will 
> control MAC forwarding entry, not VLAN table. 
>  
> All Ethernet frames controlled by GMPLS will have identical 
> OUI number 
> that they can easily be distinguished from other Ethernet frames. 
> In principle, the label lookup hardware is identical to MAC lookup 
> hardware in this labeling scheme. Therefore GMPLS implemented 
> switch may still function as normal Ethernet bridge to the frames 
> that OUI number is not GMPLS. This also facilitates GMPLS implemented 
> switches being deployed in operating Ethernet with minimum 
> service disruption. 
>  
> Note also that above proposed label encoding method is transparent 
> to the use of Ethernet Length/Type field. End-user device may use 
> the Length/Type field as defined in IEEE 802.3 protocol. 
> It also allows network operators configure VLAN for their own 
> purpose. 
> When IEEE 802.1p is used in conjunction with L2-LSP, the priority 
> field of VLAN tag can also be used for imposing consistent TE 
> policy in 
> legacy switches and GMPLS switches. 
>  
> Any way, my conclusion is, there are other options we may consider, 
> and this issue is still open to discuss. 
>  
> Thanks, 
>  
> Sincerely, 
>  
> Jaihyung 
>  
>  
>  
>  
> 
> -----?? ???----- 
> ?? ??: "Heiles Juergen" <[email-masked]> 
> ?? ??: 2005-07-22 ?? 10:23:43 
> ?? ??: "Loa Andersson" <[email-masked]>, "[email-masked]" 
> <[email-masked]> 
> ??: "[email-masked]" <[email-masked]>, "[email-masked]" 
> <[email-masked]> 
> ??: RE: Frameformat in a l2cs gmpls rnvironment. 
> 
> 
> 
> 
> 
> 
> Loa, 
> 
> I interpret the ID as a proposal to use GMPLS for VLAN setup. 
> So GMPLS and VLAN to not compete. The VLAN is at the data 
> plane and GMPLS at the control plane. The question is how and 
> should different control plane techniques like GMPLS and 
> (GVRP and STB) work together? 
> 
> Regards 
> 
> Juergen 
> 
> 
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Loa Andersson 
> > Sent: Friday, July 22, 2005 2:53 PM 
> > To: [email-masked] 
> > Cc: [email-masked]; [email-masked] 
> > Subject: Re: Frameformat in a l2cs gmpls rnvironment. 
> > 
> > Richard, 
> > 
> > I agree to most of this. Since we have doubts about the viability 
> > of taking GMPLS all the way to end-user or enterprise I think it 
> > would be good, from a wg perspective, if we agreed to solve the 
> > core network problems first. 
> > 
> > Do you have any comment on the requirement to run both VLANs and 
> > GMPLS on the same switch? 
> > 
> > /Loa 
> > 
> > [email-masked] wrote: 
> > > Regardless of whether or not a switch is directly connected 
> >  > to hosts, it must be able to forward packets using the 
> > connectionless 
> >  > Ethernet data plane. This is due to the fundamental 
> > requirement that 
> >  > for GMPLS switches to be able to exchange control 
> information with 
> >  > each other, a data plane for control traffic must be present. 
> >  > This is akin to using the IP data plane for MPLS 
> signalling in an 
> >  > IP/MPLS network. An alternative would be to use a static 
> reserved 
> >  > L2-LSP for control traffic in the same way that reserved 
> VPI/VCIs 
> >  > are used for PNNI signalling in ATM. 
> > > 
> > > Regarding connecting hosts to GMPLS switches, I personally don't 
> >  > think extending L2-LSPs into the enterprise/home network is 
> >  > commercially viable. However, if you do want to use 
> GMPLS switches 
> >  > in the home/enterprise network and for some reason don't want to 
> >  > extend L2-LSPs down to the host then you will not be performing 
> >  > normal Ethernet Mac address switching anyway. Instead you will 
> >  > need some kind of policy on the switch that maps connectionless 
> >  > Ethernet packets (e.g. based on MAC src/dest, 802.1p, VLAN) to a 
> >  > L2-LSP. This is because multiple L2-LSPs to the same destination 
> >  > (e.g. a gateway router) may exist for different services/flows 
> >  > (e.g. video download, VoIP call, etc.). 
> > > 
> > > Regards, 
> > > Richard 
> > > 
> > > 
> > >>From: [email-masked] 
> [mailto:[email-masked]]On 
> > >>Behalf Of Par Mattsson 
> > >>Sent: 22 July 2005 11:42 
> > >>To: Loa Andersson 
> > >>Cc: [email-masked] 
> > >>Subject: Re: Frameformat in a l2cs gmpls rnvironment. 
> > >> 
> > >> 
> > >> 
> > >>>Per and Dimitri, 
> > >>> 
> > >>>I would like to come down stronger than that, for me it is 
> > >>>a very strong requirement that the same switch can handle 
> > >>>both VLANs and GMPLs trafic correctly. I can't dsee how that 
> > >>>could be done if using the VLAN tpid to indicate GMPLS 
> > >>>traffic. 
> > >> 
> > >>If you ever want that same switch to handle traffic for a 
> directly 
> > >>connected  host (not to uncommen) you would want that to 
> use normal 
> > >>ethernet macaddress switching. So of course you do not want 
> > to have to 
> > >>choose between vlan and gmpls, you would want both at the 
> same time. 
> > >> 
> > >>/per 
> > >> 
> > >> 
> > >> 
> > >>>/Loa 
> > >>> 
> > >>>Par Mattsson wrote: 
> > >>> 
> > >>>>>hi par, one of the possibilities that has been considered 
> > >> 
> > >>to cope with 
> > >> 
> > >>>>>this requirement is to use a dedicated TPID for the 
> > >> 
> > >>Ethernet labeled 
> > >> 
> > >>>>>frames; this would allow differentiated processing with 
> > non-labeled 
> > >>>>>framesthanks. 
> > >>>> 
> > >>>> 
> > >>>>That seems to make more sence. If that frame is to be 
> sized like a 
> > >>>>802.1q 
> > >>>>frame. There is not that much space left to a label. Or is 
> > >> 
> > >>the demand to 
> > >> 
> > >>>>use jumboframes ? 
> > >>>>Has there been any discussion on labelstacking, and 
> > mainly where to 
> > >>>>place 
> > >>>>the information? 
> > >>>> 
> > >>>>Regards. 
> > >>>>Per 
> > >>>> 
> > >>>> 
> > >>>> 
> > >>> 
> > >>> 
> > >>>-- 
> > >>>Loa Andersson 
> > >>> 
> > >>>Principal Networking Architect 
> > >>>Acreo AB                           phone:  +46 8 632 77 14 
> > >>>Isafjordsgatan 22                  mobile: +46 739 81 21 64 
> > >>>Kista, Sweden                      email:  
> [email-masked] 
> > >>>                                            [email-masked] 
> > >>> 
> > >> 
> > >> 
> > >> 
> > > 
> > 
> > 
> > -- 
> > Loa Andersson 
> > 
> > Principal Networking Architect 
> > Acreo AB                           phone:  +46 8 632 77 14 
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64 
> > Kista, Sweden                      email:  [email-masked] 
> >                                             [email-masked] 
> > 
> 
> 
> 
> 

Delivery-date: Mon, 25 Jul 2005 10:13:32 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 
Bcc: 
Subject: RE: End-to-end L2-LSP
Date: Mon, 25 Jul 2005 19:14:28 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message

Hi, Richard

Here's continued part of reply to your original question. 
reply to the questions 1~5 are also enclosed below.

>6. Enterprise networks are built using not just switches 
>but routers as well. Firstly, for L2-LSPs to be set up 
>between switches and routers, they must belong to 
>the same address space to communicate with each other. 
>However, this address space must be separate from the 
>IPv4 forwarding address space. To use an example 
>of why this is true, routers connected via Ethernet 
>segments are considered to be directly connected, however, 
>if the IPv4 and L2-LSP address spaces were the same, 
>then IP routers separated by GMPLS switches would be 
>multiple hops away from each other. In addition to address 
>space separation, routing protocol instances must also be separated. 
>This need for this separation is obvious when considering 
>using a link state routing protocol which relies on a topological 
>view of the network, i.e. the IPv4 and L2-LSP topologies are different.

Allow me a bit lengthy writing at this time, because there's 
some message I want to tell you and people who might read this.

I think routing of GMPLS signal should be different 
in the access/enterprise network. 
If GMPLS implemented Ethernet switch aims to replace some core routers, 
it has to offer the same routing property as core routers do. 
However, if a vendor targets Ethernet market using the GMPLS 
implemented switch, the switch must be able to offer similar 
characteristics as Ethernet switches. 
In Ethernet, such notion of addressing and routing configuration 
as in IGP doesn't exist. The only routing feature Ethernet has is 
'broadcast, MAC learning, and filtering'. 
(%note: STP, MSTP, etc. must be seen in different perspective in this context)

This simplistic mind of routing results in successful acceptance 
of Ethernet. 
Now ordinary users may purchase and install Ethernet switch 
without burden of complex network configuration. Access network 
engineers are able to install Ethernet switches quickly in many 
outdoor sites because manual work is relatively simple. 
This helps reducing labor cost and OPEX a lot. 
In summary, what made Ethernet proliferating is the lightweightness, 
i.e. no manual numbering on ports, near-zero configuration, 
dynamic learning, broadcast & filtering, etc.

Such lightweightness can also be achieved in GMPLS 
when GMPLS signal doesn't rely on IP routing protocols, 
such as link-status or distance vector algorithm, but itself has 
controlled broadcast and learning capability as seen in Ethernet.

Ethernet learns destination MAC address from ARP broadcast. 
The switch optimizes data path from dynamic learning of backward path. 
Similarly, GMPLS signal may also be broadcast in a controlled way. 
Destination host group or access point to core network can be 
found from broadcast. L2-LSP can be establishment via the path 
learned from broadcast if the broadcast path is systematically recorded.

You may reference <draft-jaihyung-ccamp-arpsignal-00.txt> 
for detail of such routing method. Although the draft was written 
for ARP signaling, it can also be applied to RSVP-TE. 
I'll soon submit updated flood-routing method for RSVP-TE. 

The key message I want to tell is, 
the GMPLS control stack can be simplified if routing and signaling 
are merged in unified protocol. 
I'm sure this approach doesn't have the problem of routing hop 
or address space separation as you raised above.

>Secondly, routers break up Ethernet segments and must therefore 
>must always be the headend or tailend for a L2-LSPs, i.e. they 
>cannot be midpoints. This means that from a control plane perspective, 
>on receiving a L2-LSP path message a router must terminate the LSP 
>and send back a resv message whether it is the intended destination/sink 
>or not. It must then originate a path message for a new L2-LSP 
>and send it onto the next hop GMPLS switch. This is not how 
>RSVP-TE works today and therefore will require modifications. 
>In addition, traffic will be blackholed if transmitted by the source 
>before all the separate L2-LSPs have been setup end-to-end to 
>the sink/destination. This means that some kind of end-to-end 
>signalling message will need to be sent by the sink/destination 
>once the final L2-LSP has been established to inform the source 
>that the end-to-end connectivity has been provided. This functionality 
>is not supported by RSVP-TE today and will therefore require protocol modifications.

I agree in the point that routers break up L2-LSP connectivity. 
There's no way to provide end-to-end L2-LSP connectivity 
across L3 routers unless the routers are capable of supporting 
L2SC GMPLS. Perhaps local routers, gateways and edge routers are the 
first target to deploy L2SC GMPLS rather than Ethernet switches.

It is also no doubt some extension to RSVP-TE for L2SC will be 
necessary for end-to-end exchange of RSVP-TE. 
Clearly things that you pointed out need to be done.

>Thirdly, routers forward packets based on information in the IP header. 
>So, when a router receives a packet via a L2-LSP it will strip of the 
>L2 header and perform an IP lookup. Now, for the packet to be 
>forwarded using the correct L2-LSP the router must have a policy 
>that tells it which L2-LSP to use as there may be multiple 
>L2-LSPs to the same destination, e.g. for different voice calls or 
>video downloads. However, before a policy can even be configured, 
>the router needs to know what traffic (e.g. based on src/dest address, 
>port number, DSCP, etc.) to map to which L2-LSP, and this information 
>needs to come from the traffic source using signalling, i.e. RSVP-TE. 
>I do not believe this is supported today and will therefore require modifications.

Before you reach this conclusion, I want you look again where the 
source of problem is originated. 
If routers simply dispose MAC information, the router is losing 
important information to determine forwarding policy. 
The policy should have been known priori during LSP 
establishment time using RSVP-TE. This information is encoded 
in L2 label by ingress, thus the egress router should be able to 
keep the label information and use it for determining 
next L2-LSP to map. 
If a router doesn't have such capability of L2SC GMPLS, 
of course the policy decision will be that complex.

Sincerely,

Jaihyung 

 
-----?? ???----- 
?? ??: "CHO, JAI HYUNG" <[email-masked]> 
?? ??: 2005-07-21 ?? 11:59:07 
?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: 
??: RE: End-to-end L2-LSP 

Hi, Richard, 

Thank you for your tons of questions. 
It is a bit hard to answer in single mail. 
So, I divided it in two pieces. 
Here I send you the first part of answers to questions 1~5. 

>I agree that extending signalling down to the end-user is one 
>possible solution to address charging/billing issues, another possible 
>solution would be to use session based billing. I also agree that using 
>L2-LSPs could be a viable solution for providing traffic separation 
>and bandwidth guarantees in a service providers network, another 

Indeed, that's one important message I wanted to cast in this WG. 
Not only this is technically interesting, but the behind goal is about 
improving income structure of Internet service providers. 
I hope this can be an answer to the issue of QoS&Pricing 
that Neil Harrison once noted in last mail of this thread. 

Customers may basically use cl-ps service in fixed rate base, and 
when they need real-time service such as IP-TV or video phone, 
they may request simple CBR-like co-ps SVC-based service 
(i.e. L2-LSP) over cl-ps network using GMPLS signal. 
This way, operators may improve their service structure and invest 
to upgrade their access network. 

[snip] 
>1. If you want to eliminate the possibility of congestion in the 
>enterprise/home network using L2-LSPs for the reasons you 
>give below, then on every node in the network you will need: 
> 
>- A CPU: for control plane protocol processing 
>- Routing: At least static, an IGP for large networks and 
>OSPF-TE if TE is required 
>- Signalling: RSVP-TE 
>- Policing: Per connection policing, e.g. per VLAN 
> 
>I do not know how much it would cost to upgrade the $20 five 
>port 10/100 switch sitting on my desk to support all this, 
>but I do not believe this would be a trivial amount, particularly 
>at the volumes demanded by enterprises. 

I guess your five port $20 switch will be connected to machines 
owned only by you. If you can control resource usage of your 
machines, you don't need GMPLS implemented switch. 
However, if you need to share a switch with some of your colleague, 
I will recommend spending more that $20 on switch in order to enjoy 
nice video communication while your colleague abusing your 
network with P2P file transfer. I think this is worth while to spend 
money considering importance of your personal communication. 
As I noted in previous mail, GMPLS implemented switch will be 
necessary in nodes where automated resource control is crucial. 

>In addition, a hierarchical 
>architecture would be required for the solution to scale and 
>therefore aggregation switches within the enterprise network 
>would also need to support hierarchical CAC and policing. 

This is beyond issue we can discuss at the moment. 
I'd like further technical discussion, however, 
I think we need to wait until this idea of L2-LSP is 
officially chartered in CCAMP. 
I hope enough number of people support the idea that 
we can continue work on this issue. 

>2. Unless you want to reinvent LANE, then you will need to 
>continue to support CL Ethernet broadcasts and multicasts on 
>GMPLS enabled switches. To protect the L2-LSP traffic from 
>CL broadcast traffic you could rate limit it to say 1% of 
>the bandwidth available. However, how would you capacity 
>plan for and rate limit (dynamic, receiver driven) multicast 
>traffic for which usage patterns are difficult to predict? 
>In my opinion you will need to use over provisioning along with CoS, 
>which would raise the question, why is over provisioning 
>and CoS OK for multicast traffic 
>(which could be critical, e.g. trading floor information), 
>but not OK for unicast traffic? 

There will be a technical solution for multicast and broadcast. 
A member of DT once showed his interest on multicast solution 
for Ethernet using RSVP instead of IGMP. 
I also have an idea of extending point-to-point L2-LSP to 
multipoint L2-LSP as similar way that learning bridges 
learn backward path from source address. 

However, I have some doubt on necessity of multicast service. 
Do we really need multicast for streaming service in local/access ? 
I think even IP-TV will be better serviced using point-to-point 
connection in access network. 
There's very low chance of two subscribers receiving same channel 
at the same time if the receiver group is not that great. 
Multicasting is necessary in core network, however I doubt the 
same needs in local/access network, except some rare case. 

>3. Routers are relatively stable systems that are switched on 
>permanently and therefore RSVP-TE sessions are stable 
>and only go down when there is a failure. End user systems 
>however such as PCs, set top boxes, games consoles, etc. 
>are not always switched on and are not as stable. 
>What will the effect on the network be when large number 
>of RSVP-TE sessions are going up/down, e.g. as a result 
>of game console resets or PC crashes/freezes? 
>These effects will ripple through the enterprise/home 
>network into the operators network, and therefore mechanisms 
>must be put in place to protect against them. 

Control overhead of RSVP was discussed a lot in conjunction with IntServ. 
There have been proposals to reduce the overhead in core network 
such as RFC3175 or [HIER]. In particular, proposed architecture for 
LSP aggregation [HIER] will greatly help to solve the issue. 

% [HIER] draft-ieft-mpls-lsp-hierarchy-08.txt 

>4. When an IP device wants to forward a packet it uses ARP 
>to discover the MAC address of the IP next hop 
>(unless its already in the MAC table) and adds the Ethernet 
>header before forwarding the packet on. Now, if you want to 
>extend connections down to the end user device, then the 
>device will need to map IP traffic to different L2-LSPs. 
>A simple 1-to-1 mapping between an IP next hop address 
>and a MAC address will not be sufficient as there may 
>be multiple connections (e.g. using different VLAN IDs) 
>associated with an IP next hop. So, policies will need 
>to be configured on end user devices to map IP traffic 
>(e.g. based on src/dest IP address, port numbers, etc.) 
>to a specific L2-LSP (e.g. based on src/dest MAC address and/or VLAN ID). 

You pointed out important issue. 
Currently, Ethernet layer only maps IP and MAC in 1-to-1. 
Unless Ethernet-IP interface is extended as you suggested, 
users must be satisfied with at most single L2-LSP established 
between machine to machine. If they want another connection, 
they have to disconnect previous connection. 
This scenario will be OK in most real-life applications. 
However in future, extension to layer interface will be necessary 
and the solution should be consulted with IEEE. 

>5. End user devices such as PCs and VoIP phones are 
>likely to only need to support a relatively low number 
>of L2-LSPs. However, devices such as content servers 
>and call servers/gateways will need to support 
>hundreds/thousands of L2-LSPs. Connection setup and 
>state maintenance for large numbers of L2-LSPs will 
>consume a significant amount of processing resources, 
>as will policies to map IP traffic to the different L2-LSPs. 
>Therefore, I would expect that the system software 
>(and possibly hardware) will need to be designed from 
>the ground up to be able to support large numbers of L2-LSPs. 

Some high-performance servers are capable of handling 
millions of TCP connections. 
I believe the added complexity for LSP connection 
will not be far greater that the work-load normally assumed 
in contemporary servers. 

It may be a problem to local gateways if the signaling load 
is not bypassed. However, even in this case, there can be 
some solutions we can devise. 
ok, for rest of questions, 
I'll reply it in next mail. 

thanks 

Jaihyung 

-----?? ???----- 
?? ??: "[email-masked]" <[email-masked]> 
?? ??: 2005-07-21 ?? 12:09:56 
?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: 
??: RE: End-to-end L2-LSP 

Jaihyung, 

I agree that extending signalling down to the end-user is one possible solution to address charging/billing issues, another possible solution would be to use session based billing. I also agree that using L2-LSPs could be a viable solution for providing traffic separation and bandwidth guarantees in a service providers network, another possible solution would be to extended MPLS into the access network. 

However, if you want to extend L2-LSPs (not just signalling) down to the end user, then there are a number of complicated technical and commercial issues that must be overcome. Please see below for some of the key issues: 

1. If you want to eliminate the possibility of congestion in the enterprise/home network using L2-LSPs for the reasons you give below, then on every node in the network you will need: 

- A CPU: for control plane protocol processing 
- Routing: At least static, an IGP for large networks and OSPF-TE if TE is required 
- Signalling: RSVP-TE 
- Policing: Per connection policing, e.g. per VLAN 

I do not know how much it would cost to upgrade the $20 five port 10/100 switch sitting on my desk to support all this, but I do not believe this would be a trivial amount, particularly at the volumes demanded by enterprises. In addition, a hierarchical architecture would be required for the solution to scale and therefore aggregation switches within the enterprise network would also need to support hierarchical CAC and policing. 

2. Unless you want to reinvent LANE, then you will need to continue to support CL Ethernet broadcasts and multicasts on GMPLS enabled switches. To protect the L2-LSP traffic from CL broadcast traffic you could rate limit it to say 1% of the bandwidth available. However, how would you capacity plan for and rate limit (dynamic, receiver driven) multicast traffic for which usage patterns are difficult to predict? In my opinion you will need to use over provisioning along with CoS, which would raise the question, why is over provisioning and CoS OK for multicast traffic (which could be critical, e.g. trading floor information), but not OK for unicast traffic? 

3. Routers are relatively stable systems that are switched on permanently and therefore RSVP-TE sessions are stable and only go down when there is a failure. End user systems however such as PCs, set top boxes, games consoles, etc. are not always switched on and are not as stable. What will the effect on the network be when large number of RSVP-TE sessions are going up/down, e.g. as a result of game console resets or PC crashes/freezes? These effects will ripple through the enterprise/home network into the operators network, and therefore mechanisms must be put in place to protect against them. 

4. When an IP device wants to forward a packet it uses ARP to discover the MAC address of the IP next hop (unless its already in the MAC table) and adds the Ethernet header before forwarding the packet on. Now, if you want to extend connections down to the end user device, then the device will need to map IP traffic to different L2-LSPs. A simple 1-to-1 mapping between an IP next hop address and a MAC address will not be sufficient as there may be multiple connections (e.g. using different VLAN IDs) associated with an IP next hop. So, policies will need to be configured on end user devices to map IP traffic (e.g. based on src/dest IP address, port numbers, etc.) to a specific L2-LSP (e.g. based on src/dest MAC address and/or VLAN ID).  

5. End user devices such as PCs and VoIP phones are likely to only need to support a relatively low number of L2-LSPs. However, devices such as content servers and call servers/gateways will need to support hundreds/thousands of L2-LSPs. Connection setup and state maintenance for large numbers of L2-LSPs will consume a significant amount of processing resources, as will policies to map IP traffic to the different L2-LSPs. Therefore, I would expect that the system software (and possibly hardware) will need to be designed from the ground up to be able to support large numbers of L2-LSPs. 

6. Enterprise networks are built using not just switches but routers as well. Firstly, for L2-LSPs to be set up between switches and routers, they must belong to the same address space to communicate with each other. However, this address space must be separate from the IPv4 forwarding address space. To use an example of why this is true, routers connected via Ethernet segments are considered to be directly connected, however, if the IPv4 and L2-LSP address spaces were the same, then IP routers separated by GMPLS switches would be multiple hops away from each other. In addition to address space separation, routing protocol instances must also be separated. This need for this separation is obvious when considering using a link state routing protocol which relies on a topological view of the network, i.e. the IPv4 and L2-LSP topologies are different. 

Secondly, routers break up Ethernet segments and must therefore must always be the headend or tailend for a L2-LSPs, i.e. they cannot be midpoints. This means that from a control plane perspective, on receiving a L2-LSP path message a router must terminate the LSP and send back a resv message whether it is the intended destination/sink or not. It must then originate a path message for a new L2-LSP and send it onto the next hop GMPLS switch. This is not how RSVP-TE works today and therefore will require modifications. In addition, traffic will be blackholed if transmitted by the source before all the separate L2-LSPs have been setup end-to-end to the sink/destination. This means that some kind of end-to-end signalling message will need to be sent by the sink/destination once the final L2-LSP has been established to inform the source that the end-to-end connectivity has been provided. This functionality is not supported by RSVP-TE today and will therefore require protocol modifications. 

Thirdly, routers forward packets based on information in the IP header. So, when a router receives a packet via a L2-LSP it will strip of the L2 header and perform an IP lookup. Now, for the packet to be forwarded using the correct L2-LSP the router must have a policy that tells it which L2-LSP to use as there may be multiple L2-LSPs to the same destination, e.g. for different voice calls or video downloads. However, before a policy can even be configured, the router needs to know what traffic (e.g. based on src/dest address, port number, DSCP, etc.) to map to which L2-LSP, and this information needs to come from the traffic source using signalling, i.e. RSVP-TE. I do not believe this is supported today and will therefore require modifications. 

Regards, 
Richard 

> From: CHO, JAI HYUNG [mailto:[email-masked]] 
> Sent: 14 July 2005 04:24 
> To: Spencer,R,Richard,XDE73 R; [email-masked] 
> Subject: RE: End-to-end L2-LSP 
> 
> Dear Richard, 
> 
> See in-line please, 
> 
> >Thank you for taking the time to respond to my questions. I 
> anticipated 
> >that your response would include "over-provisioning is the 
> best answer" 
> >to decrease the chance of congestion on non-GMPLS switches. 
> >This is what is done in the LAN environment today in 
> conjunction with CoS, 
> >and this is why I believe there will be two opposing views on how 
> >far L2-LSP connections should be extended down to the user. One view 
> >is that over provisioning and CoS work fine in the 
> enterprise network today, 
> >and therefore the L2-LSP should only be extended down to the point 
> >at which the enterprise network connects to the SP network, 
> >e.g. Ethernet DSLAM. I think the other view will be that 
> over provisioning 
> >and CoS in the enterprise network don't work and therefore L2-LSPs 
> >should be provided end-to-end using only GMPLS capable switches. 
> >I wouldn't have thought there would be much call for mixed 
> >GMPLS/non-GMPLS enterprise networks (except for during migration) 
> >due to the opposing views, e.g. if over provisioning is good 
> enough for 
> >one switch, why isn't it good enough for the other? 
> 
> Over-provisioned network is non-guaranteed network. It can't prevent 
> occasional congestion at any rate. Further, network condition 
> in private 
> network is very diverse. You can't predict minimum service level 
> inside every private network. 
> 
> Suppose that an ISP want to provide high-quality, video-phone service 
> for enterprise users. Nothing can be guaranteed inside the 
> over-provisioned 
> customer network. If the service level is not satisfactory, 
> customers will complain 
> to service provider even if the main cause is in his network 
> or destination network. 
> We need some structure that coordinate service quality in 
> both private sector, 
> as well as in public sector consistently. 
> An end-to-end signal is an effective means to communicate between 
> user terminal, private switches and provider switches, and 
> concert service 
> quality at each different operations network. This is a goal 
> that RSVP (RFC2205) 
> pursued, however ineffective in local network because 
> Ethernet industry 
> didn't support RSVP over Ethernet (RFC2814, 2815, 2816). 
> Now we have another opportunity to realize the goal using L2-LSP. 
> Therefore, I believe end-to-end LSP is necessary even in 
> enterprise network 
> for the purpose of providing guaranteed commercial service. 
> 
> >I think where most people will agree is that using connections 
> >in the SPs access network does make sense in order to 
> provide efficient 
> >link utilisation and per connection policing to ensure one customers 
> >traffic can not affect another's. Regarding the ability to 
> set up new 
> >connections based on a request from the user (rather than 
> constraining 
> >RSVP signalling to inside the SP network), I think this will come 
> >down to enterprise customer demand for improved service performance. 
> >If a customer wasn't getting the performance they needed from their 
> >SP and was offered a new service that allowed them to setup 
> new L2-LSP 
> >connections on demand that would offer better performance 
> (e.g. for voice 
> >calls or video conferences), then upgrading the user devices 
> to support 
> >the new service could well be an attractive proposition. If 
> on the other 
> 
> Yes, this will be one of prospective service newly enabled 
> using L2-LSP. 
> 
> >hand a customer buys a best effort service and considers the 
> performance 
> >to be 'good enough', then there would be no reason to go to 
> the expense 
> >of upgrading the user devices to support the set up of L2-LSPs. 
> 
> Ever increasing besteffort bandwidth will eventually not satisfy 
> both providers and customers for many reasons. Service providers 
> will have difficulty in collecting expenses enough to invest 
> on increased 
> bandwidth. This will in turn gradually downgrade overall 
> communication quality, 
> and applications requiring real-time service will never 
> satisfy customers. 
> We already see such symptom in some low-price service providers. 
> I believe new service structure that can provide difference 
> of service 
> quality will offer benefit to customers, providers as well as 
> vendors in the end. 
> 
> I also look forward to see you at Paris and continue helpful 
> discussion. 
> 
> Sincerely 
> 
> Jaihyung 
> 
> 
>  
> 
> Dr. Jaihyung Cho 
> ETRI, Korea 
> phone :       042) 860-5514 
> oversea: +82-42-860-5514 
> fax:         +82-42-861-5550 
> 
> 
> 
> 
> -----?? ???----- 
> ?? ??: "[email-masked]" <[email-masked]> 
> ?? ??: 2005-07-14 ?? 1:10:30 
> ?? ??: "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]> 
> ??: 
> ??: RE: End-to-end L2-LSP 
> 
> 
> 
> Jaihyung, 
> 
> Thank you for taking the time to respond to my questions. I 
> anticipated that your response would include 
> "over-provisioning is the best answer" to decrease the chance 
> of congestion on non-GMPLS switches. This is what is done in 
> the LAN environment today in conjunction with CoS, and this 
> is why I believe there will be two opposing views on how far 
> L2-LSP connections should be extended down to the user. One 
> view is that over provisioning and CoS work fine in the 
> enterprise network today, and therefore the L2-LSP should 
> only be extended down to the point at which the enterprise 
> network connects to the SP network, e.g. Ethernet DSLAM. I 
> think the other view will be that over provisioning and CoS 
> in the enterprise network don't work and therefore L2-LSPs 
> should be provided end-to-end using only GMPLS capable 
> switches. I wouldn't have thought there would be much call 
> for mixed GMPLS/non-GMPLS enterprise networks (except for 
> during migration) due to the opposing views, e.g. if over 
> provisioning is good enough for one switch, why isn't it good 
> enough for the other? 
> 
> I think where most people will agree is that using 
> connections in the SPs access network does make sense in 
> order to provide efficient link utilisation and per 
> connection policing to ensure one customers traffic can not 
> affect another's. Regarding the ability to set up new 
> connections based on a request from the user (rather than 
> constraining RSVP signalling to inside the SP network), I 
> think this will come down to enterprise customer demand for 
> improved service performance. If a customer wasn't getting 
> the performance they needed from their SP and was offered a 
> new service that allowed them to setup new L2-LSP connections 
> on demand that would offer better performance (e.g. for voice 
> calls or video conferences), then upgrading the user devices 
> to support the new service could well be an attractive 
> proposition. If on the other hand a customer buys a best 
> effort service and considers the performance to be 'good 
> enough', then there would be no reason to go to the expense 
> of upgrading the user devices to support the set up of L2-LSPs. 
> 
> I look forward to the discussions in Paris. 
> 
> Regards, 
> Richard 
> 
> > From: CHO, JAI HYUNG [mailto:[email-masked]] 
> > Sent: 13 July 2005 15:14 
> > To: Spencer,R,Richard,XDE73 R; [email-masked] 
> > Subject: RE: End-to-end L2-LSP 
> > 
> > 
> >  
> >  
> > Dear Richard Spencer 
> >  
> > see in-line 
> >  
> > >Jaihyung, 
> > > 
> > >Perhaps I'm becoming too much of a pessimist;-) 
> >  
> > oh, not at all, 
> > you are reasonable enough to dig up unclear knowledge 
> > please go ahead until you finally get satisfactory answer. 
> >  
> > 
> > >Ignoring the commercial aspects, please can you help clarify 
> > a few technical 
> > >questions I have in order to help me gain a better 
> > understanding of the proposal? 
> > > 
> > >1. You say that one of the key reasons for using GMPLS in 
> > the enterprise 
> > >network is to provide end-to-end QoS control. However, you 
> > also say that not 
> > >all the switches will need to support GMPLS, only those at 
> > bottle necks. 
> > >Please can you expand on this to explain how you can have 
> end-to-end 
> > >QoS control when the L2-LSP is not end-to-end? 
> >  
> > 
> > The contextual meaning of 'End-to-end LSP' is that GMPLS label is 
> > assigned from source terminal and removed at destination terminal, 
> > because RSVP-TE message is exchanged from host to host. 
> > It may not perfectly guarantee QoS when the GMPLS deployment 
> > is not complete, however it will at least be good enough 
> > for end-user applications to tell those GMPLS implemented 
> L2 switches 
> > what frame must be given priority service when congestion occur. 
> >  
> > 
> > >As being discussed 
> > >on the PWE3 mailing list, the performance a service receives 
> > is only as 
> > >good as the worst performing server layer. Therefore, if 
> there is a 
> > >standard 802.1 workgroup switch between the user and the 
> > L2-LSP that is 
> > >experiencing congestion (e.g. due to a large amount of 
> > peer-to-peer traffic), 
> > >then the QoS that the user receives will only be as good as 
> > that provided 
> > >by the congested workgroup switch. 
> >  
> > 
> > of course, ETH-GMPLS does not prevent congestion inevitably 
> occurring 
> > in those non-GMPLS deployed part. 
> >  
> > 
> > >The only way I can see a network using a mixture of GMPLS 
> > and non-GMPLS 
> > >switches guaranteeing end-to-end QoS would be to design the 
> > network in 
> > >such a way that the non-GMPLS switches could never become 
> congested. 
> >  
> > 
> > Yes, that will be the way wise network designer improve 
> their network. 
> >  
> > 
> > >To do this would require that RSVP requests be used for ALL 
> > traffic flows 
> > >to ensure that there was enough bandwidth available, along 
> > with strict 
> > >per L2-LSP policing on the user devices (e.g. PC). 
> > >However, the obvious flaw in this approach is that someone could 
> > >just come along and connect 
> > >an end device to a non-GMPLS switch and start transmitting traffic 
> > >(without performing CAC/policing) causing the switch to 
> > become congested. 
> > >Therefore, please can you explain how end-to-end QoS can be 
> > guaranteed 
> > >in a mixed non-GMPLS and GMPLS switching environment? 
> >  
> > 
> > Of course traffic came from non controlled ingress can not be 
> > prevented 
> > in non-GMPLS node. There's no magic. Only the 
> > over-provisioning is the 
> > best answer. However, once the aggregated traffic pass 'ANY' one of 
> > GMPLS enabled node, those uncontrolled traffic will suffer 
> > queuing discipline. 
> >  
> > 
> > >2. Section 5.1 currently states "When the customer initiates 
> > data transmission, 
> > >the access switch maps the user flow into the L2 LSP. 
> > Mapping procedure is 
> > >subject to implementation choices, and is out of the scope of this 
> > >document." In order to be able to map any traffic, first of 
> > all the switch needs 
> > >to know what type of traffic (e.g. based on source/dest MAC, 
> > VLAN ID, 802.1p 
> > >bits, etc) should be mapped to the L2-LSP. In Figure 1, if 
> > an L2-LSP is set up 
> > >from the DSLAM to the edge router based on a request from 
> > the user (e.g. via 
> > >a PC or VoIP phone), then won't the user also need to signal 
> > what type of 
> > >traffic should to be mapped to the L2-LSP? 
> >  
> > 
> > Thank you for pointing out important thing. 
> > That's the most unfortunate part I reluctantly agreed because the 
> > work condition in the framework DT was not to span L2-LSP 
> > beyond provider network. 
> > As you noticed, mapping user traffic at provider access is awkward. 
> > A smooth method will be for user terminal aware of the L2 label 
> > to use by receiving RSVP-TE message. 
> > However, there was strong argument that RSVP-TE must not 
> > go beyond provider network because the DT is not chartered 
> > to work in customer network. 
> > That's why I requested amendment of CCAMP charter 
> > to include user terminal explicitly in CCAMP work scope, so that 
> > avoid such silly argument in future. 
> >  
> > 
> > >3. In section 5.1, the text states that the aggregation 
> > switch between the 
> > >DSLAM and edge router may be a 802.1 switch, i.e. it doesn't 
> > have to support 
> > >GMPLS. To set up a connection, first of all there needs to 
> > be a data plane 
> > >capable of carrying control plane traffic between GMPLS 
> > peers. Secondly, 
> > >the GMPLS peers need reachability information in order to 
> > forward control 
> > >messages onto the next peer (i.e. a static or IGP route). If 
> > the GMPLS peers 
> > >(e.g. the DSLAM and edge router in Figure 1) are not 
> > directly connected, 
> > >then the GMPLS control packets will need to be forwarded by 
> > the 802.1 switch. 
> > >Would the idea be to have say a "control traffic VLAN" 
> > configured between the 
> > >DSLAM and edge router via the transit 802.1 switch so that 
> > control packets 
> > >could be forwarded transparently by the 802.1 switch? 
> >  
> > 
> > Although it doesn't preclude use of VLAN, I think such 
> > special configuration 
> > for RSVP-TE control message is not necessary in legacy switches. 
> > Legacy switches only need to pass RSVP-TE messages as they 
> > pass normal data frames. Only the GMPLS implemented switches 
> > need to distinguish frames containing RSVP-TE messages and 
> > snoop them. 
> > Detail of implementation is, of course, for future discussion. 
> >  
> > 
> > >4. If we assume that control messages can be transparently 
> forwarded 
> > >by the intermediate 802.1 aggregation switch then how are 
> > user frames 
> > >forwarded in the data plane by the 802.1 switch? 
> >  
> > 
> > Legacy switches do not distinguish control/data frames. 
> >  
> > 
> > >If the DSLAM sets up a L2-LSP 
> > >to the edge router using say VLAN ID 99, how does the switch 
> > know that any 
> > >packets coming in with a VLAN ID of 99 should be forwarded 
> > out of the port 
> > >connecting to the edge router? 
> >  
> > 
> > oh, you misunderstood the L2-LSP. 
> > The question you are asking depends on how L2 label is encoded. 
> > there was hot debate in the DT about the issue how L2 label 
> > is encoded. 
> > My proposal is to use part of MAC address for label and the 
> > other people 
> > argued to use VLAN ID for label. The debate was not concluded 
> > because the goal of the L2SC framework document is not to select 
> > implementation method but to draw necessary work scope. 
> > I believe this issue will be dealt in depth after Paris meeting. 
> > So, please reserve your question until then and ask to those 
> > VLAN proponents. 
> >  
> > 
> > >5. During connection setup, I take it that the GMPLS peers 
> > assume that 
> > >resources are available within the intermediate 802.1 switch 
> > to support 
> > >the connection (as its transparent). However, as there is no 
> > >CAC/policing being performed by the 802.1 switch 
> > >(the L2-LSPs are transparent), and due to the any-to-any and 
> > broadcast 
> > >based nature of Ethernet (i.e. its CL properties), then 
> how can this 
> > >assumption be made? This comes back to my original question, how 
> > >can end-to-end QoS be guaranteed in an environment where there is 
> > >a mixture of 802.1 and GMPLS enabled switches? 
> >  
> > 
> > yes, you came back to the question I answered in above ;-) 
> > so, please see above. 
> > GMPLS enabled nodes must be positioned at points congestion 
> > is likely to be expected. 
> >  
> > Thanks 
> >  
> > Jaihyung 
> >  
> > 
> > ============================================ 
> > 
> >  
> > 
> > -----?? ???----- 
> > ?? ??: "[email-masked]" <[email-masked]> 
> > ?? ??: 2005-07-13 ?? 8:53:13 
> > ?? ??: "[email-masked]" <[email-masked]>, 
> > "[email-masked]" <[email-masked]> 
> > ??: 
> > ??: RE: End-to-end L2-LSP 
> > 
> > 
> > 
> > 
> > Jaihyung, 
> > 
> > Perhaps I'm becoming too much of a pessimist;-) Ignoring the 
> > commercial aspects, please can you help clarify a few 
> > technical questions I have in order to help me gain a better 
> > understanding of the proposal? 
> > 
> > 1. You say that one of the key reasons for using GMPLS in the 
> > enterprise network is to provide end-to-end QoS control. 
> > However, you also say that not all the switches will need to 
> > support GMPLS, only those at bottle necks. Please can you 
> > expand on this to explain how you can have end-to-end QoS 
> > control when the L2-LSP is not end-to-end? As being discussed 
> > on the PWE3 mailing list, the performance a service receives 
> > is only as good as the worst performing server layer. 
> > Therefore, if there is a standard 802.1 workgroup switch 
> > between the user and the L2-LSP that is experiencing 
> > congestion (e.g. due to a large amount of peer-to-peer 
> > traffic), then the QoS that the user receives will only be as 
> > good as that provided by the congested workgroup switch. 
> > 
> > The only way I can see a network using a mixture of GMPLS and 
> > non-GMPLS switches guaranteeing end-to-end QoS would be to 
> > design the network in such a way that the non-GMPLS switches 
> > could never become congested. To do this would require that 
> > RSVP requests be used for ALL traffic flows to ensure that 
> > there was enough bandwidth available, along with strict per 
> > L2-LSP policing on the user devices (e.g. PC). However, the 
> > obvious flaw in this approach is that someone could just come 
> > along and connect an end device to a non-GMPLS switch and 
> > start transmitting traffic (without performing CAC/policing) 
> > causing the switch to become congested. Therefore, please can 
> > you explain how end-to-end QoS can be guaranteed in a mixed 
> > non-GMPLS and GMPLS switching environment? 
> > 
> > 2. Section 5.1 currently states "When the customer initiates 
> > data transmission, the access switch maps the user flow into 
> > the L2 LSP. Mapping procedure is subject to implementation 
> > choices, and is out of the scope of this document." In order 
> > to be able to map any traffic, first of all the switch needs 
> > to know what type of traffic (e.g. based on source/dest MAC, 
> > VLAN ID, 802.1p bits, etc) should be mapped to the L2-LSP. In 
> > Figure 1, if an L2-LSP is set up from the DSLAM to the edge 
> > router based on a request from the user (e.g. via a PC or 
> > VoIP phone), then won't the user also need to signal what 
> > type of traffic should to be mapped to the L2-LSP? 
> > 
> > 3. In section 5.1, the text states that the aggregation 
> > switch between the DSLAM and edge router may be a 802.1 
> > switch, i.e. it doesn't have to support GMPLS. To set up a 
> > connection, first of all there needs to be a data plane 
> > capable of carrying control plane traffic between GMPLS 
> > peers. Secondly, the GMPLS peers need reachability 
> > information in order to forward control messages onto the 
> > next peer (i.e. a static or IGP route). If the GMPLS peers 
> > (e.g. the DSLAM and edge router in Figure 1) are not directly 
> > connected, then the GMPLS control packets will need to be 
> > forwarded by the 802.1 switch. Would the idea be to have say 
> > a "control traffic VLAN" configured between the DSLAM and 
> > edge router via the transit 802.1 switch so that control 
> > packets could be forwarded transparently by the 802.1 switch? 
> > 
> > 4. If we assume that control messages can be transparently 
> > forwarded by the intermediate 802.1 aggregation switch then 
> > how are user frames forwarded in the data plane by the 802.1 
> > switch? If the DSLAM sets up a L2-LSP to the edge router 
> > using say VLAN ID 99, how does the switch know that any 
> > packets coming in with a VLAN ID of 99 should be forwarded 
> > out of the port connecting to the edge router? 
> > 
> > 5. During connection setup, I take it that the GMPLS peers 
> > assume that resources are available within the intermediate 
> > 802.1 switch to support the connection (as its transparent). 
> > However, as there is no CAC/policing being performed by the 
> > 802.1 switch (the L2-LSPs are transparent), and due to the 
> > any-to-any and broadcast based nature of Ethernet (i.e. its 
> > CL properties), then how can this assumption be made? This 
> > comes back to my original question, how can end-to-end QoS be 
> > guaranteed in an environment where there is a mixture of 
> > 802.1 and GMPLS enabled switches? 
> > 
> > Thanks, 
> > Richard 
> > 
> > > From: CHO, JAI HYUNG [mailto:[email-masked]] 
> > > Sent: 12 July 2005 09:21 
> > > To: Spencer,R,Richard,XDE73 R; [email-masked] 
> > > Subject: RE: End-to-end L2-LSP 
> > > 
> > > 
> > > 
> > > 
> > > Dear Richard, 
> > > 
> > > Yes, I believe it is not only commercially profitable but it 
> > > may also grow total 
> > > revenue of service operators by introducing new services. 
> > > 
> > > For example, think the example of IP phone you referred. 
> > > How do you think you can provide reliable VoIP service and 
> > > safely authenticate phone users and charge fees as counted by 
> > > packet usage 
> > > using simple Ethernet based xDSL network ? 
> > > 
> > > There's hardly new service that providers may offer using 
> > > Ethernet based 
> > > architecture, and collect sufficient profit to investment. 
> > > 
> > > A sophisticated ATM switch might do the work if it is not 
> > expensive. 
> > > However, my intension is modifiying existing design of 
> > > Ethernet hardware 
> > > with a little bit additional cost,  and provide the level of 
> > > service that 
> > > ATM switches might offer. 
> > > 
> > > We have initial design of the Ethernet-MPLS hardware. I 
> don't think 
> > > GMPLS enabled Ethernet switch will be so complex. The 
> market price 
> > > of GMPLS enabled switch will not be so expensive than normal 
> > > Ethernet switches. 
> > > 
> > > Further, it only requires upgrade of switches in some 
> > > bottleneck points of network. 
> > > Read the framework documents of L2SC. It doesn't require 
> > > entire replacement 
> > > of switches to introduce new service. 
> > > 
> > > Every year, ISPs purchase new access switches and replaces 
> > > old machines. 
> > > With a bit additional cost, ISPs may use the GMPLS enabled 
> > switch for 
> > > normal Ethernet switching in initial deployment. 
> > > 
> > > When the GMPLS function is enabled in some upgraded part of 
> > network, 
> > > ISPs may provide high quality, reliable VoIP service to 
> > xDSL customers 
> > > using RSVP-TE enabled VoIP phone. 
> > > The high quality video-phone service enabled by GMPLS will be 
> > > competable to legacy voice only phone service. 
> > > 
> > > 
> > > There are lots of things I can argue about commercial aspects 
> > > of this technique. 
> > > However I don't think it is not appropriate to discuss this 
> > > issue in this mailing list. 
> > > All I can say is, 
> > > yes, I believe that it may be commercially viable. 
> > > 
> > > 
> > > Thanks 
> > > 
> > > Jaihyung 
> > > 
> > > ================================================ 
> > > 
> > > Do you really think the benefits of extended GMPLS down to 
> > > the end user could ever justify the costs involved in 
> > > upgrading LAN switches and things like IP phones (simple low 
> > > cost commodity items) to support GMPLS signalling/routing? 
> > > 
> > > Your proposal may be technically possible (though it would 
> > > require new hardware and significant software upgrades), but 
> > > commercially I would consider this to be a non-starter. 
> > > 
> > > Regards, 
> > > Richard 
> > > 
> > > > From: [email-masked] 
> > [mailto:[email-masked]]On 
> > > > Behalf Of CHO, JAI HYUNG 
> > > > Sent: 12 July 2005 01:10 
> > > > To: [email-masked] 
> > > > Subject: End-to-end L2-LSP 
> > > > 
> > > > 
> > > >  
> > > > Dear all, 
> > > > 
> > > > Greetings. 
> > > > 
> > > > I am a co-editor of the Ethernet-GMPLS framework document. 
> > > > (draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt) 
> > > > 
> > > > I am writing this to explain the motivation behind the 
> > > > proposal of scenario-1, and to raise the issue of 
> > > > end-to-end LSP to be included in CCAMP charter. 
> > > > 
> > > > An important goal intended in scenario-1 is 
> > > > QoS control over end-to-end packet delivery using LSP. 
> > > > In other words, the purpose of scenario-1 is extending coverage 
> > > > of GMPLS control including customer network and 
> end-user device, 
> > > > such as PC, VoIP phone, IP-TV, or even future 4G mobile phone. 
> > > > End-user applications will have a means to request resources 
> > > > to network using GMPLS signal. 
> > > > 
> > > > Unfortunately, this view is not included in the 
> > > > framework because there was strong opinion that 
> > > > L2-LSP must not span beyond provider network because 
> > > > CCAMP is not chartered to work on customer 
> > > > network. I am wondering if this is right argument. 
> > > > Perhaps the charter can be amended to include this work. 
> > > > 
> > > > I believe there is little technical reason to preclude 
> > > > LSP being used in customer network. It is a reasonable 
> > > > assumption that private company may also use GMPLS 
> > > > implemented Ethernet switch, once the L2SC work is successful. 
> > > > Currently, CCAMP is the only place discussing the matter of 
> > > > Ethernet and LSP. There is no other WG dealing similar issue. 
> > > > If CCAMP wants to work on Ethernet, 
> > > > I think the coverage of common GMPLS control must be 
> > > > extended to include all area where Ethernet is deployed. 
> > > > Currently, Ethernet is dominantly deployed in first-mile 
> > > > network where access network as well as customer network 
> > > > and user hosts are usually included. Therefore, user host must 
> > > > be considered as initiation and termination point of L2-LSP. 
> > > > 
> > > > Another important reason to include user host in CCAMP 
> > > > work scope is to achieve consistent end-to-end control of QoS. 
> > > > End-to-end QoS has long been desired goal since RSVP was 
> > > > first designed. This goal can be best achieved using 
> > > > end-to-end GMPLS signal and L2-LSP. 
> > > > Currently, RSVP (RFC2205) is available in many user hosts. 
> > > > There is only a little difference between RSVP and RSVP-TE. 
> > > > If the RSVP-TE signal of provider network can reach user host 
> > > > across Ethernet based private network, an LSP can be 
> established 
> > > > from application to application via the provider backbone. 
> > > > Service providers will be able to control application flows 
> > > > in L2-LSP level as well as in aggregated LSP pipe of similar 
> > > > application type. A variety of new services will be 
> enabled using 
> > > > the enhanced capability of distinguishing and controlling each 
> > > > individual application flow. 
> > > > 
> > > > I personally believe that end-to-end L2-LSP may offer 
> > > > innovative solutions for servicing IP-TV as well as fast 
> > mobility. 
> > > > There have been some experimental approaches combining 
> > > > MPLS and IP mobility. However such potential of the new 
> > > > application can only be explored when end-user host is 
> > > > included in the scope of CCAMP work area. 
> > > > 
> > > > Therefore, I hereby sincerely request people's attention 
> > > > and support on this perspective of end-to-end LSP. 
> > > > If there is enough number of people agree on this view, 
> > > > the WG can request the necessary update of the charter. 
> > > > 
> > > > Thank you. 
> > > >  
> > > > Jaihyung Cho 
> > > >  
> > > >  
> > > >  
> > > > ETRI, Korea 
> > > > phone :       042) 860-5514 
> > > > oversea: +82-42-860-5514 
> > > > fax:         +82-42-861-5550 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 

Delivery-date: Mon, 25 Jul 2005 10:06:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Mon, 25 Jul 2005 11:06:07 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Igor,

>=20
> > I am also a little concerned that some folks might
> > naively assume that a
> > control-plane is going to solve all their
> > management-plane
> > issues......when we move down the network stack to
> > the duct there are a
> > whole raft of factors that mean the management-plane
> > still dominates
> > here.  If you talk to the right folks in the
> > operators who run these
> > types of network you will indeed understand what I
> > mean by this.
>=20
> This kind of statements you've been making in about
> every email. I am curious to know as we move towards
> the duct which *exactly* features, provisioning
> functions or operations that are implemented via NMS
> could not be conceptually realized via control plane?=20
> Or you are not the "right folk to ask" ? :=3D)

NH=3D> To properly answer your question will take me a couple of pages.  =
I
can help/answer to a fair degree, but if you are really serious about
understanding this stuff better I do think you should seek out the right
folks in operators (not sure you will get all the feedback you need if
you are solely reliant on IETF lists).  Anyway, I'll send you a detailed
reponse off list...and I also note Alan McGuire here has sent you some
stuff off-list on a similar theme wrt to our experiences in BT (quite
compelling IMO).

regads, Neil

Delivery-date: Mon, 25 Jul 2005 10:00:02 +0000
Sensitivity: 
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
To: "<richard.spencer" <[email-masked]>
Cc: "<jaihyung" <[email-masked]>, "<ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Mon, 25 Jul 2005 11:59:27 +0200

Hi Richard,
            actually the usage of a specific VLAN tag for the control plane
seems to me a good idea.

It is a fast and simple way to distinguish data plane traffic from control
plane traffic.

Regards

Diego

<[email-masked]>@ops.ietf.org on 25/07/2005 11.54.36

Sent by:    [email-masked]

To:    <[email-masked]>
cc:    <[email-masked]>

Subject:    RE: Frameformat in a l2cs gmpls rnvironment.

Jaihyung,

As both you and Adrian thought that I was talking about an Ethernet Control
plane, I mustn't have adequately articulated my point. When I mentioned a
"data plane for control traffic" below, I was not talking about an Ethernet
control plane. I was referring to the transport of GMPLS IP control
protocol traffic over a standard 802.1 data plane, using either untagged
frames or a common VLAN ID.

Regards,
Richard

> From: CHO, JAI HYUNG [mailto:[email-masked]]
> Sent: 23 July 2005 05:39
> To: Spencer,R,Richard,XDE73 R
> Cc: [email-masked]
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
>
>
>
> Richard,
>
> IEEE recommends to use Ethernet Length/Type code for
> distinguishing control frames.
> All GARP, GVRP, GMPR and other proposed OAM frame follow this rule.
> IEEE particulary discourages using some number in data
> forwarding address
> being used for exchange of control data. An example is using
> some multicast address
> for exchange of hello frames. This rule is also applied to
> the case of VLAN forwarding.
> I think this policy is to prevent control chaos with other L2
> protocols.
> We need to be careful in taking approach to use some L2-LSP
> exclusively
> for control plane because it may result in unwanted conflict
> with both people and machine.
>
> Regards,
>
> Jaihyung
>
>
> -----?? ???-----
> ?? ??: "[email-masked]" <[email-masked]>
> ?? ??: 2005-07-22 ?? 8:44:08
> ?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> ??: "[email-masked]" <[email-masked]>
> ??: RE: Frameformat in a l2cs gmpls rnvironment.
>
>
>
> Regardless of whether or not a switch is directly connected
> to hosts, it must be able to forward packets using the
> connectionless Ethernet data plane. This is due to the
> fundamental requirement that for GMPLS switches to be able to
> exchange control information with each other, a data plane
> for control traffic must be present. This is akin to using
> the IP data plane for MPLS signalling in an IP/MPLS network.
> An alternative would be to use a static reserved L2-LSP for
> control traffic in the same way that reserved VPI/VCIs are
> used for PNNI signalling in ATM.
>
> Regarding connecting hosts to GMPLS switches, I personally
> don't think extending L2-LSPs into the enterprise/home
> network is commercially viable. However, if you do want to
> use GMPLS switches in the home/enterprise network and for
> some reason don't want to extend L2-LSPs down to the host
> then you will not be performing normal Ethernet Mac address
> switching anyway. Instead you will need some kind of policy
> on the switch that maps connectionless Ethernet packets (e.g.
> based on MAC src/dest, 802.1p, VLAN) to a L2-LSP. This is
> because multiple L2-LSPs to the same destination (e.g. a
> gateway router) may exist for different services/flows (e.g.
> video download, VoIP call, etc.).
>
> Regards,
> Richard
>
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Par Mattsson
> > Sent: 22 July 2005 11:42
> > To: Loa Andersson
> > Cc: [email-masked]
> > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> >
> >
> > > Per and Dimitri,
> > >
> > > I would like to come down stronger than that, for me it is
> > > a very strong requirement that the same switch can handle
> > > both VLANs and GMPLs trafic correctly. I can't dsee how that
> > > could be done if using the VLAN tpid to indicate GMPLS
> > > traffic.
> >
> > If you ever want that same switch to handle traffic for a directly
> > connected  host (not to uncommen) you would want that to use normal
> > ethernet macaddress switching. So of course you do not want
> to have to
> > choose between vlan and gmpls, you would want both at the
> same time.
> >
> > /per
> >
> >
> > >
> > > /Loa
> > >
> > > Par Mattsson wrote:
> > >>>hi par, one of the possibilities that has been considered
> > to cope with
> > >>>this requirement is to use a dedicated TPID for the
> > Ethernet labeled
> > >>>frames; this would allow differentiated processing with
> non-labeled
> > >>>framesthanks.
> > >>
> > >>
> > >> That seems to make more sence. If that frame is to be
> sized like a
> > >> 802.1q
> > >> frame. There is not that much space left to a label. Or is
> > the demand to
> > >> use jumboframes ?
> > >> Has there been any discussion on labelstacking, and
> mainly where to
> > >> place
> > >> the information?
> > >>
> > >> Regards.
> > >> Per
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > Loa Andersson
> > >
> > > Principal Networking Architect
> > > Acreo AB                           phone:  +46 8 632 77 14
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > Kista, Sweden                      email:  [email-masked]
> > >                                             [email-masked]
> > >
> >
> >
> >
>
>
>
>
>

Delivery-date: Mon, 25 Jul 2005 09:55:06 +0000
Content-Class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 10:54:36 +0100
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Jaihyung,=20

As both you and Adrian thought that I was talking about an Ethernet =
Control plane, I mustn't have adequately articulated my point. When I =
mentioned a "data plane for control traffic" below, I was not talking =
about an Ethernet control plane. I was referring to the transport of =
GMPLS IP control protocol traffic over a standard 802.1 data plane, =
using either untagged frames or a common VLAN ID.

Regards,
Richard

> From: CHO, JAI HYUNG [mailto:[email-masked]]
> Sent: 23 July 2005 05:39
> To: Spencer,R,Richard,XDE73 R
> Cc: [email-masked]
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
>=20
>=20
> =20
> Richard,=20
> =20
> IEEE recommends to use Ethernet Length/Type code for=20
> distinguishing control frames.
> All GARP, GVRP, GMPR and other proposed OAM frame follow this rule.
> IEEE particulary discourages using some number in data=20
> forwarding address=20
> being used for exchange of control data. An example is using=20
> some multicast address=20
> for exchange of hello frames. This rule is also applied to=20
> the case of VLAN forwarding.
> I think this policy is to prevent control chaos with other L2=20
> protocols.
> We need to be careful in taking approach to use some L2-LSP=20
> exclusively=20
> for control plane because it may result in unwanted conflict=20
> with both people and machine.
> =20
> Regards,
> =20
> Jaihyung
> =20
>=20
> -----?? ???-----=20
> ?? ??: "[email-masked]" <[email-masked]>=20
> ?? ??: 2005-07-22 ?? 8:44:08=20
> ?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>=20
> ??: "[email-masked]" <[email-masked]>=20
> ??: RE: Frameformat in a l2cs gmpls rnvironment.=20
>=20
>=20
>=20
> Regardless of whether or not a switch is directly connected=20
> to hosts, it must be able to forward packets using the=20
> connectionless Ethernet data plane. This is due to the=20
> fundamental requirement that for GMPLS switches to be able to=20
> exchange control information with each other, a data plane=20
> for control traffic must be present. This is akin to using=20
> the IP data plane for MPLS signalling in an IP/MPLS network.=20
> An alternative would be to use a static reserved L2-LSP for=20
> control traffic in the same way that reserved VPI/VCIs are=20
> used for PNNI signalling in ATM.=20
>=20
> Regarding connecting hosts to GMPLS switches, I personally=20
> don't think extending L2-LSPs into the enterprise/home=20
> network is commercially viable. However, if you do want to=20
> use GMPLS switches in the home/enterprise network and for=20
> some reason don't want to extend L2-LSPs down to the host=20
> then you will not be performing normal Ethernet Mac address=20
> switching anyway. Instead you will need some kind of policy=20
> on the switch that maps connectionless Ethernet packets (e.g.=20
> based on MAC src/dest, 802.1p, VLAN) to a L2-LSP. This is=20
> because multiple L2-LSPs to the same destination (e.g. a=20
> gateway router) may exist for different services/flows (e.g.=20
> video download, VoIP call, etc.).=20
>=20
> Regards,=20
> Richard=20
>=20
> > -----Original Message-----=20
> > From: [email-masked] [mailto:[email-masked]]On=20
> > Behalf Of Par Mattsson=20
> > Sent: 22 July 2005 11:42=20
> > To: Loa Andersson=20
> > Cc: [email-masked]=20
> > Subject: Re: Frameformat in a l2cs gmpls rnvironment.=20
> >=20
> >=20
> > > Per and Dimitri,=20
> > >=20
> > > I would like to come down stronger than that, for me it is=20
> > > a very strong requirement that the same switch can handle=20
> > > both VLANs and GMPLs trafic correctly. I can't dsee how that=20
> > > could be done if using the VLAN tpid to indicate GMPLS=20
> > > traffic.=20
> >=20
> > If you ever want that same switch to handle traffic for a directly=20
> > connected  host (not to uncommen) you would want that to use normal=20
> > ethernet macaddress switching. So of course you do not want=20
> to have to=20
> > choose between vlan and gmpls, you would want both at the=20
> same time.=20
> >=20
> > /per=20
> >=20
> >=20
> > >=20
> > > /Loa=20
> > >=20
> > > Par Mattsson wrote:=20
> > >>>hi par, one of the possibilities that has been considered=20
> > to cope with=20
> > >>>this requirement is to use a dedicated TPID for the=20
> > Ethernet labeled=20
> > >>>frames; this would allow differentiated processing with=20
> non-labeled=20
> > >>>framesthanks.=20
> > >>=20
> > >>=20
> > >> That seems to make more sence. If that frame is to be=20
> sized like a=20
> > >> 802.1q=20
> > >> frame. There is not that much space left to a label. Or is=20
> > the demand to=20
> > >> use jumboframes ?=20
> > >> Has there been any discussion on labelstacking, and=20
> mainly where to=20
> > >> place=20
> > >> the information?=20
> > >>=20
> > >> Regards.=20
> > >> Per=20
> > >>=20
> > >>=20
> > >>=20
> > >=20
> > >=20
> > > --=20
> > > Loa Andersson=20
> > >=20
> > > Principal Networking Architect=20
> > > Acreo AB                           phone:  +46 8 632 77 14=20
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64=20
> > > Kista, Sweden                      email:  [email-masked]=20
> > >                                             [email-masked]=20
> > >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20
>=20

Delivery-date: Mon, 25 Jul 2005 09:45:36 +0000
From: Heiles Juergen <[email-masked]>
To: "CHO, JAI HYUNG" <[email-masked]>, Heiles Juergen <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 11:44:34 +0200

Dear Jaihyung,

you mention several options that could be used as a label. Most of them have strong impacts on the data plane and introduce new layer networks. Is this in the scope of CCAMP? What is the goal, to introduce a control plane for a existing L2 technology or introduce a new L2 technology? What would be the benefit of such a new L2 co switching technology compared to Ethernet over MPLS as defined by PWE3 and L2VPN?
You mentioned to use the MAC address or part of it as a label. The TRILL working group is defining shortest path routing for Ethernet. How would this fit together?

Regards

Juergen

> From: CHO, JAI HYUNG [mailto:[email-masked]] 
> Sent: Saturday, July 23, 2005 6:19 AM
> To: Heiles Juergen; [email-masked]
> Cc: [email-masked]
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> 
> 
> Dear Juergen, Par and all,
> 
> The proposed framework of L2SC was not intended to suggest 
> any specific solution. It is still an open question. 
> As Adrian noted, it only aims to present requirements 
> as in scenarios that may drive people toward next step in many 
> viable solutions.
> 
> In fact, there are other options we may also consider for L2 
> label encoding. 
> IEEE 802.1 Ethernet bridges forward frames based on 48bits of 
> MAC address, 
> and additionally using VLAN tag. 
> 
> When the purpose of GMPLS control over Ethernet is not to 
> create new dataplane 
> but to utilize IEEE 802.1 bridge architecture, we may consider using 
> one of the two forwarding methods, MAC forwarding or VLAN forwarding. 
> (and perhaps any other combination of fields in MAC, but I'll 
> not discuss it)
>  
> Use of VLAN ID for label encoding may automate VLAN configuration 
> using IP protocols. However, GMPLS protocol cannot use the 
> field exclusively 
> because public/private operators already use VLAN for various 
> purpose. 
> There is a potential conflict with existing use of VLAN and 
> GMPLS use of VLAN label.  
> Furthermore, scalability of VLAN ID has been frequently noted 
> as weakness 
> because the size of VLAN ID is at most 4096 (12bit). 
> 
> The scalability may be improved if the scope of VLAN label is 
> confined to 
> link-local, and some additional swapping function of VLAN ID 
> is introduced in 
> Internal Sublayer [802.1D] of GMPLS implemented switch. 
> However, this will only be effective when the configuration 
> of network 
> is mesh structure that multiple LSP paths exist. If the 
> configuration of network 
> is star or tree shape, as normal configuration of access network, 
> LSPs concentrate in root node and total number of 
> LSPs that the network can hold still be limited by available 
> label space 
> at a few root links. 
> 
> For these reasons, I do not think any form of VLAN ID label is 
> an appropriate choice for layer-2 label encoding.
>  
> There are some other proposals assuming new assignment of Ethernet 
> Length/Type value (e.g. new TPID in VLAN tag) and re-definition of 
> information fields placed between 802.3 MAC header and IP packet. 
> In this case, only the format of VLAN tag or extended VLAN tag 
> is borrowed, however, inside the switching hardware, the 
> filter and relay, 
> etc. are totally different new dataplane switch.
> 
> I do not see such approach is a GMPLS implementation for Ethernet 
> because the core switching technique is not 802.1 Ethernet 
> bridge at all.
>  
> The other option we may consider is using MAC address filed as below.
>  
> 
> +-------+-------+-------+-------+-------+-------+ 
> | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte | 
> +-------+-------+-------+-------+-------+-------+
> +-----------------------+-----------------------+ 
> |  OUI Prefix (=GMPLS)  |   DA-label (24bit)    | 
> +-----------------------+-----------------------+ 
> |  OUI Prefix (=GMPLS)  |   SA-label (24bit)    | 
> +---------------+-------+-----------------------+ 
> | Length/Type   | 
> +---------------+
>  
> 
> IEEE is designated by the ISO Council to act as the 
> registration authority 
> for the higher three-octet of OUI number in the MAC address 
> to be used by manufacturer. Ethernet manufacturer may generate 
> global unique MAC address using the OUI prefix and address block of 
> lower three-octet (24bit). Taking advantage of the addressing scheme, 
> GMPLS may use the lower three-octet exclusively if a unique 
> OUI number 
> is reserved for the protocol. With this labeling scheme, GMPLS will 
> control MAC forwarding entry, not VLAN table.
>  
> All Ethernet frames controlled by GMPLS will have identical 
> OUI number 
> that they can easily be distinguished from other Ethernet frames. 
> In principle, the label lookup hardware is identical to MAC lookup 
> hardware in this labeling scheme. Therefore GMPLS implemented 
> switch may still function as normal Ethernet bridge to the frames 
> that OUI number is not GMPLS. This also facilitates GMPLS implemented 
> switches being deployed in operating Ethernet with minimum 
> service disruption.
>  
> Note also that above proposed label encoding method is transparent 
> to the use of Ethernet Length/Type field. End-user device may use 
> the Length/Type field as defined in IEEE 802.3 protocol. 
> It also allows network operators configure VLAN for their own 
> purpose. 
> When IEEE 802.1p is used in conjunction with L2-LSP, the priority 
> field of VLAN tag can also be used for imposing consistent TE 
> policy in 
> legacy switches and GMPLS switches.
>  
> Any way, my conclusion is, there are other options we may consider, 
> and this issue is still open to discuss.
>  
> Thanks,
>  
> Sincerely,
>  
> Jaihyung
>  
>  
>  
>  
> 
> -----?? ???----- 
> ?? ??: "Heiles Juergen" <[email-masked]> 
> ?? ??: 2005-07-22 ?? 10:23:43 
> ?? ??: "Loa Andersson" <[email-masked]>, "[email-masked]" 
> <[email-masked]> 
> ??: "[email-masked]" <[email-masked]>, "[email-masked]" 
> <[email-masked]> 
> ??: RE: Frameformat in a l2cs gmpls rnvironment. 
> 
> 
> 
> 
> 
> 
> Loa, 
> 
> I interpret the ID as a proposal to use GMPLS for VLAN setup. 
> So GMPLS and VLAN to not compete. The VLAN is at the data 
> plane and GMPLS at the control plane. The question is how and 
> should different control plane techniques like GMPLS and 
> (GVRP and STB) work together? 
> 
> Regards 
> 
> Juergen 
> 
> 
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Loa Andersson 
> > Sent: Friday, July 22, 2005 2:53 PM 
> > To: [email-masked] 
> > Cc: [email-masked]; [email-masked] 
> > Subject: Re: Frameformat in a l2cs gmpls rnvironment. 
> > 
> > Richard, 
> > 
> > I agree to most of this. Since we have doubts about the viability 
> > of taking GMPLS all the way to end-user or enterprise I think it 
> > would be good, from a wg perspective, if we agreed to solve the 
> > core network problems first. 
> > 
> > Do you have any comment on the requirement to run both VLANs and 
> > GMPLS on the same switch? 
> > 
> > /Loa 
> > 
> > [email-masked] wrote: 
> > > Regardless of whether or not a switch is directly connected 
> >  > to hosts, it must be able to forward packets using the 
> > connectionless 
> >  > Ethernet data plane. This is due to the fundamental 
> > requirement that 
> >  > for GMPLS switches to be able to exchange control 
> information with 
> >  > each other, a data plane for control traffic must be present. 
> >  > This is akin to using the IP data plane for MPLS 
> signalling in an 
> >  > IP/MPLS network. An alternative would be to use a static 
> reserved 
> >  > L2-LSP for control traffic in the same way that reserved 
> VPI/VCIs 
> >  > are used for PNNI signalling in ATM. 
> > > 
> > > Regarding connecting hosts to GMPLS switches, I personally don't 
> >  > think extending L2-LSPs into the enterprise/home network is 
> >  > commercially viable. However, if you do want to use 
> GMPLS switches 
> >  > in the home/enterprise network and for some reason don't want to 
> >  > extend L2-LSPs down to the host then you will not be performing 
> >  > normal Ethernet Mac address switching anyway. Instead you will 
> >  > need some kind of policy on the switch that maps connectionless 
> >  > Ethernet packets (e.g. based on MAC src/dest, 802.1p, VLAN) to a 
> >  > L2-LSP. This is because multiple L2-LSPs to the same destination 
> >  > (e.g. a gateway router) may exist for different services/flows 
> >  > (e.g. video download, VoIP call, etc.). 
> > > 
> > > Regards, 
> > > Richard 
> > > 
> > > 
> > >>From: [email-masked] 
> [mailto:[email-masked]]On 
> > >>Behalf Of Par Mattsson 
> > >>Sent: 22 July 2005 11:42 
> > >>To: Loa Andersson 
> > >>Cc: [email-masked] 
> > >>Subject: Re: Frameformat in a l2cs gmpls rnvironment. 
> > >> 
> > >> 
> > >> 
> > >>>Per and Dimitri, 
> > >>> 
> > >>>I would like to come down stronger than that, for me it is 
> > >>>a very strong requirement that the same switch can handle 
> > >>>both VLANs and GMPLs trafic correctly. I can't dsee how that 
> > >>>could be done if using the VLAN tpid to indicate GMPLS 
> > >>>traffic. 
> > >> 
> > >>If you ever want that same switch to handle traffic for a 
> directly 
> > >>connected  host (not to uncommen) you would want that to 
> use normal 
> > >>ethernet macaddress switching. So of course you do not want 
> > to have to 
> > >>choose between vlan and gmpls, you would want both at the 
> same time. 
> > >> 
> > >>/per 
> > >> 
> > >> 
> > >> 
> > >>>/Loa 
> > >>> 
> > >>>Par Mattsson wrote: 
> > >>> 
> > >>>>>hi par, one of the possibilities that has been considered 
> > >> 
> > >>to cope with 
> > >> 
> > >>>>>this requirement is to use a dedicated TPID for the 
> > >> 
> > >>Ethernet labeled 
> > >> 
> > >>>>>frames; this would allow differentiated processing with 
> > non-labeled 
> > >>>>>framesthanks. 
> > >>>> 
> > >>>> 
> > >>>>That seems to make more sence. If that frame is to be 
> sized like a 
> > >>>>802.1q 
> > >>>>frame. There is not that much space left to a label. Or is 
> > >> 
> > >>the demand to 
> > >> 
> > >>>>use jumboframes ? 
> > >>>>Has there been any discussion on labelstacking, and 
> > mainly where to 
> > >>>>place 
> > >>>>the information? 
> > >>>> 
> > >>>>Regards. 
> > >>>>Per 
> > >>>> 
> > >>>> 
> > >>>> 
> > >>> 
> > >>> 
> > >>>-- 
> > >>>Loa Andersson 
> > >>> 
> > >>>Principal Networking Architect 
> > >>>Acreo AB                           phone:  +46 8 632 77 14 
> > >>>Isafjordsgatan 22                  mobile: +46 739 81 21 64 
> > >>>Kista, Sweden                      email:  
> [email-masked] 
> > >>>                                            [email-masked] 
> > >>> 
> > >> 
> > >> 
> > >> 
> > > 
> > 
> > 
> > -- 
> > Loa Andersson 
> > 
> > Principal Networking Architect 
> > Acreo AB                           phone:  +46 8 632 77 14 
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64 
> > Kista, Sweden                      email:  [email-masked] 
> >                                             [email-masked] 
> > 
> 
> 
> 
> 

Delivery-date: Mon, 25 Jul 2005 09:14:53 +0000
Sensitivity: 
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
To: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Mon, 25 Jul 2005 11:14:45 +0200

Hi all,
        this is a very long and very interesting thread but IMHO we're
losing the focus.

W.r.t. the draft-papadimitriou-ccamp-gmpls-ethernet-framework-00 I think
that the ID is useful and I hope that this work progress in the CCAMP.
Moreover I'd like to have some words in the ID on the fact that a GMPLS
enabled Eth TNE can work and interwork also with Eth TNEs that are without
GMPLS control plane.  In the LMP section (section 6.4) there is no mention
about control channel, I'd like to have some words on this.

In general I agree that CP is just a way to automatise and speed-up
operation that can be done via NMS and thus seems to me that the VLAN usage
as GMPLS label is good.  Of course we need to go in deep on this matter but
the idea seems good.

Best regards

Diego

Delivery-date: Mon, 25 Jul 2005 08:56:38 +0000
Date: Mon, 25 Jul 2005 04:55:31 -0400
From: Bijan Jabbari <[email-masked]>
To: [email-masked], [email-masked]
Cc: Igor Bryskin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]

  While we are on the subject of control vs. management plane and the need for
GMPLS-based control of Ethernet TE, I thought it might be worthwhile to
indicate some prior work done in this area and within the context of an
experimental optical and IP network (although a few of you might be familiar
with this activity, as my colleagues or myself might have shared with you the
goal of the project which also involves establishing Ethernet/L2 LSPs).

  As part of this project (referred to as DRAGON, initiated in the early 2003
and supported by the NSF), we have implemented the GMPLS capabilities (OSPF-TE
& RSVP-TE) within an element (referred to as the Virtual LSR, or VLSR) 
and have
used it within experimental and demo networks to control Ethernet, TDM and
Fiber-switched capable switches. The implementation is open source software,
available free to public and it runs on FreeBSD or Linux.

  While VLSR participates in a GMPLS-based control network from one end, it
enables the devices (Ethernet switches, cross-connects, etc. without GMPLS
capability) to participate within the network, by translating specific 
protocol
events into an appropriate sets of commands for the device to effect an
associated state change.

  In our use of VLSR to control Ethernet switches, the LSP set up requests are
processed by issuing the appropriate SNMP commands to the said device to place
two ports into a single VLAN effecting a port-to-port cross-connect. For
control of Ethernet switches, we have used RFC 2674 to dynamically modify VLAN
configurations.

  Efforts are underway to add multi-region capability to VLSR, where we 
can have
the ability to route light-paths across different networks 
transparently. A case
of interest there is to cater to the PSC LSP when no existing path to the
destination might exist, however a lower layer path, say an Ethernet 
L2SC path,
could be established to provide the missing link for the PSC request.

  Regards,
  - Bijan

Quoting dimitri papadimitriou <[email-masked]>:

> igor
>
>> What I was trying to say here is that for the User how
>> TE Ethernet connection is established - via control or
>> management planes is of a little importance.
>
> -> in the CCAMP context where the second C means "Control" it is of 
> importance because the purpose of this working group is to define IP 
> control plane mechanism(s)
>
>> Before
>> explaining how cool/elegant it could be provisioned
>> via GMPLS you need to answer IMO the following
>> questions:
>
> -> i suggest you also take a look to section 3 and 4 and if you think 
> there are additional arguments you would consider as part of these 
> sections i would suggest that you share them with us
>
>> 1) What does it mean Traffic Engineered Ethernet
>> connection in the data plane and what is it good for?
>> For instance, we perfectly understand what does ATM
>> connection or TDM connection mean in the data plane
>> and can provide references to corresponding data plane
>> standards.
>
> -> i suggest you take a look at scenario 2 for inst. that should in 
> principle provide an answer to your question
>
>> 2) How does the label-aware Ethernet forwarder
>> co-exist with other Ethernet forwarders on the same
>> switch
>
> -> it is an explicit non-objective of THIS document to detail 
> (existing) Ethernet forwarding behaviour and their co-existence, in 
> part. due to point 3) here below
>
>> 3) What information is necessary to provision the
>> forwarding tables?
>
> -> the current document refers to "label" entries without delving 
> into details but this has been done purposely as the choice which 
> will ultimately be made (e.g. VLAN Tags, or new TPIDs or something 
> else) is orthogonal to be capabilities this working group wants to 
> achieve with GMPLS control of Ethernet networks
>
>> And so on.
>
> -> in practice ?
>
>> Cheers,
>> Igor
>>
>>   --- dimitri papadimitriou <[email-masked]>
>> wrote:
>>
>>
>>> hi igor,
>>>
>>> [snip - hint: igor i suggest you create a thread on
>>> control vs management plane]
>>>
>>>
>>>> My view wrt Ethertnet GMPLS is this. I have no
>>>
>>> doubts
>>>
>>>> that we can come up with mechanisms to dynamically
>>>> provision L2SC LSPs.
>>>
>>> ouf ;-)
>>>
>>>
>>>> My problem is the order of events. It does not seem to me wise to 
>>>> come up with
>>>> some control plane framework and solution(s) and
>>>
>>> after
>>>
>>>> that think what we need to do in the data plane.
>>>
>>> actually, if this is the only problem you have, i
>>> should underline we do not have to initiate the definition of a specific
>>> forwarding paradigm so i am not necessarily sure about what you mean by the
>>> last part of the above sentence
>>>
>>>
>>>> It seems to  me wiser to learn how to statically
>>>> provision such LSPs, see how useful they are, and
>>>
>>> only
>>>
>>>> after that design and develop ways to provision
>>>
>>> them
>>>
>>>> dynamically.
>>>
>>> i am not sure to follow how are you going to
>>> determine the benefit from dynamic provisioning by statically 
>>> configure these
>>> LSPs ?
>>>
>>>
>>>> In other words, it is wiser to repeat what has
>>>
>>> been
>>>
>>>> done with TDM LSPs.
>>>
>>> wiser ? ... would you clarify ? don't you think it
>>> is more appropriate to receive feedback on the appropriateness of the
>>> use of GMPLS for the scenarios depicted in the problem statement document
>>> rather than digress on non-rational argument such as "wiser", "careful"
>>> or so... ?
>>>
>>>
>>>> Cheers,
>>>> Igor
>>>>
>>>>
>>>>
>>>>
>>>>> A control-plane is useful in the major co-cs
>>>>> transport networks (mainly
>>>>> for S-PVCs and resilience) but its a minor player
>>>>> compared to role of
>>>>> the management-plane.   The converse of course
>>>
>>> holds
>>>
>>>>> in a *traffic*
>>>>> carrying cl-ps  IP network, esp when this is in
>>>
>>> the
>>>
>>>>> context of the
>>>>> public Internet.....but of course this isn't the
>>>>> case here and IP is
>>>>> only being used as the transport protocol in the
>>>
>>> OOB
>>>
>>>>> data-plane network
>>>>> that carries the control/management-plane
>>>
>>> protocols.
>>>
>>>>>
>>>>> These were points I wanted to make.....hopefully
>>>>> I've done a better job
>>>>> this time.
>>>>>
>>>>> regards, Neil
>>>>>
>>>>>
>>>>>
>>>>> From: Adrian Farrel [mailto:[email-masked]] Sent: 23 July 2005 00:08
>>>>> To: Harrison,N,Neil,IKM1 R
>>>>> Cc: [email-masked]
>>>>> Subject: Re: Ethernet Control Plane [Was: Re:
>>>>> Frameformat in a l2cs
>>>>> gmpls rnvironment.]
>>>>>
>>>>>
>>>>> Hi Neil,
>>>>>
>>>>> I think John beat me off the blocks here, but...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> GMPLS assumes an IP control plane.
>>>>>>
>>>>>> An IP control-plane?  There is actually no such
>>>>>
>>>>> animal.  Just what
>>>>>> the heck does that REALLY mean in GMPLS say?
>>>>>
>>>>>
>>>>> Let me explain.
>>>>> Perhaps I should have said "IP-based control
>>>
>>> plane".
>>>
>>>>> I mean a control plane which:
>>>>> - uses IP as its network protocol
>>>>> - uses IP addresses to identify control plane
>>>>> resources
>>>>> - uses IP addresses to identify data plane
>>>
>>> resources
>>>
>>>>> within the control plane
>>>>> - uses protocols developed for use in the
>>>
>>> Internet.
>>>
>>>>>
>>>>>> I am not questioning IP as a cl-ps networking
>>>>>
>>>>> protocol *carrying*
>>>>>> a signalling protocol (RSVP-TE, or dare I mention
>>>>>
>>>>> PNNI, or any
>>>>>> signalling protocol yet to be invented) or a
>>>>>
>>>>> routing protocol
>>>>>> (OSPF or ISO or whatever)
>>>>>
>>>>>
>>>>> I am glad to hear it.
>>>>>
>>>>>
>>>>>
>>>>>> or even management protocols
>>>>>
>>>>>
>>>>> Fine, but not in the remit of CCAMP.
>>>>>
>>>>>
>>>>>
>>>>>> but an 'IP Control Plane' per se means absolutely
>>>>>
>>>>> nothing to me....
>>>>>
>>>>> Well, I think it should. I think the list of
>>>>> attributes that I have
>>>>> given above define a control plane based on IP. It is undoubtable 
>>>>> that attempts have been made to
>>>>> use control planes
>>>>> based on other protocols. Some have been highly
>>>>> successful. Some have
>>>>> been less fortunate.
>>>>>
>>>>>
>>>>>
>>>>>> ...nor should it to anyone else.
>>>>>
>>>>>
>>>>> I think folks who were around at the beginning of
>>>>> CCAMP and who were
>>>>> part of the debate with the IESG will be very
>>>>> familiar with where the
>>>>> IETF draws the line here.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I think some folks might need a reality check
>>>>>
>>>>> here....and also
>>>>>
>>>>>
>>>>>> on the self-assumed importance of a
>>>
>>> control-plane.
>>>
>>>>> Hint: It ain't
>>>>>> that important.....the management-plane (which
>>>
>>> may
>>>
>>>>> be using IP!)
>>>>>> however is.
>>>>>
>>>>>
>>>>> I am not sure how to interpret this.
>>>>> It may be that you think that control plane is bad
>>>>> per se, but you have
>>>>> said elsewhere that you think it has value - but
>>>>> much less than the
>>>>> management plane.
>>>>> It may be that you believe that CCAMP is willfully
>>>>> neglecting the
>>>>> management plane. This would, in fact, be true. It
>>>>> is not in CCAMP's
>>>
>> === message truncated ===
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam protection around 
>> http://mail.yahoo.com .
>>
>
>

Delivery-date: Mon, 25 Jul 2005 07:23:06 +0000
From: Heiles Juergen <[email-masked]>
To: [email-masked], Heiles Juergen <[email-masked]>
Cc: Loa Andersson <[email-masked]>, Par Mattsson <[email-masked]>, [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 09:20:19 +0200

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C590E9.501C479C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Dimitri,
=20
what I described is the straight forward approach like it is used for =
SONET/SDH or OTN. A pure control plane approach for setup of =
connectivity. You could even keep the restriction of a domain local =
VLAN ID as defined by IEEE. It is "just" a restriction of matrix =
connectivity like some older SONET/SDH equipment also has (e.g. no time =
slot interchange in a ring). So it would have no major impact on 802.1d =
except for the definition of a control plane communications channel as =
mentioned by Richard.
In case we make any changes to the data plane behavior like disabling =
of MAC address learning and MAC address based forwarding and =
introduction of a dedicated label we introduce a new layer network like =
MPLS did for IP. This has much wider impact and should be carefully =
considered.
=20
Regards
=20
Juergen
=20

  _____ =20

From: [email-masked] =
[mailto:[email-masked]]=20
Sent: Friday, July 22, 2005 4:03 PM
To: Heiles Juergen
Cc: Loa Andersson; Par Mattsson; [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

hi juergen,

if well understand your point of view, you would be in favor of setting =
up path without introducing any specific indication in the data plane =
Ethernet frame flow

more precisely, once the "logical path" is setup using the control =
plane, the forwarding behaviour would remain unchanged from legacy =
Ethernet behaviour (i.e MAC address learning and forwarding based on =
MAC DA) in this case, the control plane function replaces the VLAN id =
configuration performed today manually on a per interface basis ? - =
please confirm

now, i would interested to know what in your view would be the role of =
802.1d and related in this context (also there are several levels of =
interaction possible here)

Heiles Juergen <[email-masked]>
Sent by: [email-masked]
07/22/2005 15:17 ZE2

To: Loa Andersson <[email-masked]>, P=E4r Mattsson <[email-masked]>
cc: [email-masked]
bcc:=20
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

GMPLS for SONET/SDH has no impact on the SONET/SDH data plane. It =
introduces a control plane for connection setup instead of a network =
management based connection setup. GMPLS for Ethernet can work in the =
same way. Ethernet as such is cl, but VLANs are setup and GMPLS can =
provide a control plane for VLAN setup. The Ethernet data plane is not =
changed and MAC address learning and forwarding is still be done within =
a VLAN. So no change to the Ethernet data plane. No GMPLS traffic is =
introduced, it is still VLAN traffic.
Introducing a dedicated GMPLS label for Ethernet (GMPLS traffic) goes =
beyond GMPLS as a control plane technique.

Regards

Juergen

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Friday, July 22, 2005 12:05 PM
> To: P=E4r Mattsson
> Cc: [email-masked]
> Subject: Re: Frameformat in a l2cs gmpls rnvironment.
>
> Per and Dimitri,
>
> I would like to come down stronger than that, for me it is
> a very strong requirement that the same switch can handle
> both VLANs and GMPLs trafic correctly. I can't dsee how that
> could be done if using the VLAN tpid to indicate GMPLS
> traffic.
>
> /Loa
>
> P=E4r Mattsson wrote:
> >>hi par, one of the possibilities that has been considered
> to cope with
> >>this requirement is to use a dedicated TPID for the Ethernet =
labeled
> >>frames; this would allow differentiated processing with non-labeled
> >>framesthanks.
> >
> >
> > That seems to make more sence. If that frame is to be sized
> like a 802.1q
> > frame. There is not that much space left to a label. Or is
> the demand to
> > use jumboframes ?
> > Has there been any discussion on labelstacking, and mainly
> where to place
> > the information?
> >
> > Regards.
> > Per
> >
> >
> >
>
>
> --
> Loa Andersson
>
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                             [email-masked]
>

------_=_NextPart_001_01C590E9.501C479C
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 6.00.2800.1505" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=690085706-25072005><FONT face=Arial 
color=#0000ff size=2>Hi Dimitri,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=690085706-25072005><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=690085706-25072005><FONT face=Arial 
color=#0000ff size=2>what I described is the straight forward approach like it 
is used for SONET/SDH or OTN.&nbsp;A pure control plane approach for setup of 
connectivity. You could even keep the restriction of a domain local VLAN ID as 
defined by IEEE. It is "just" a restriction of matrix connectivity like some 
older SONET/SDH equipment also has (e.g. no time slot interchange in a ring). So 
it would have no major impact on 802.1d except for the definition&nbsp;of a 
control plane communications channel as mentioned by 
Richard.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=690085706-25072005><FONT face=Arial 
color=#0000ff size=2>In case we make any changes to the data plane behavior like 
disabling of MAC address learning and MAC address based forwarding and 
introduction of a dedicated label we introduce a new layer network like MPLS did 
for IP.</FONT>&nbsp;</SPAN><FONT face=Arial><FONT color=#0000ff><FONT 
size=2>T<SPAN class=690085706-25072005>his has much wider impact and should be 
carefully considered.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=690085706-25072005></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><SPAN class=690085706-25072005></SPAN><FONT face=Arial><FONT 
color=#0000ff><FONT size=2>Regards</FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT 
size=2></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT><FONT><FONT face=Arial><FONT color=#0000ff><FONT size=2>J<SPAN 
class=690085706-25072005>uergen</SPAN></FONT></FONT></FONT></FONT></FONT></DIV>
<DIV><FONT><FONT><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
class=690085706-25072005></SPAN></FONT></FONT></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><BR></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=de dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> [email-masked] 
  [mailto:[email-masked]] <BR><B>Sent:</B> Friday, July 22, 
  2005 4:03 PM<BR><B>To:</B> Heiles Juergen<BR><B>Cc:</B> Loa Andersson; Par 
  Mattsson; [email-masked]<BR><B>Subject:</B> RE: Frameformat in a l2cs 
  gmpls rnvironment.<BR></FONT><BR></DIV>
  <DIV></DIV>
  <P><FONT face=Monospace,Courier>hi juergen,</FONT></P>
  <P><FONT face=Monospace,Courier>if well understand your point of view, you 
  would be in favor of setting up path without introducing any specific 
  indication in the data plane Ethernet frame flow</FONT></P>
  <P><FONT face=Monospace,Courier>more precisely, once the "logical path" is 
  setup using the control plane, the forwarding behaviour would remain unchanged 
  from legacy Ethernet behaviour (i.e MAC address learning and forwarding based 
  on MAC DA) in this case, the control plane function replaces the VLAN id 
  configuration performed today manually on a per interface basis ? - please 
  confirm</FONT></P>
  <P><FONT face=Monospace,Courier>now, i would interested to know what in your 
  view would be the role of 802.1d and related in this context (also there are 
  several levels of interaction possible here)</FONT></P>
  <P><BR><FONT size=2><B>Heiles Juergen 
  &lt;[email-masked]&gt;</B></FONT><BR><FONT size=2>Sent by: 
  [email-masked]</FONT><BR><FONT size=2>07/22/2005 15:17 
  ZE2</FONT><BR><BR><FONT size=2>To:</FONT> <FONT size=2>Loa Andersson 
  &lt;[email-masked]&gt;, Pär Mattsson &lt;[email-masked]&gt;</FONT><BR><FONT 
  size=2>cc:</FONT> <FONT size=2>[email-masked]</FONT><BR><FONT 
  size=2>bcc:</FONT> <BR><FONT size=2>Subject:</FONT> <FONT size=2>RE: 
  Frameformat in a l2cs gmpls rnvironment.</FONT><BR><BR><BR></P>
  <P><FONT face=Monospace,Courier>GMPLS for SONET/SDH has no impact on the 
  SONET/SDH data plane. It introduces a control plane for connection setup 
  instead of a network management based connection setup. GMPLS for Ethernet can 
  work in the same way. Ethernet as such is cl, but VLANs are setup and GMPLS 
  can provide a control plane for VLAN setup. The Ethernet data plane is not 
  changed and MAC address learning and forwarding is still be done within a 
  VLAN. So no change to the Ethernet data plane. No GMPLS traffic is introduced, 
  it is still VLAN traffic.<BR>Introducing a dedicated GMPLS label for Ethernet 
  (GMPLS traffic) goes beyond GMPLS as a control plane 
  technique.<BR></FONT><BR><FONT 
  face=Monospace,Courier>Regards<BR></FONT><BR><FONT 
  face=Monospace,Courier>Juergen<BR></FONT><BR><BR><BR><BR><FONT 
  face=Monospace,Courier>&gt; -----Original Message-----<BR>&gt; From: 
  [email-masked]<BR>&gt; [mailto:[email-masked]] On Behalf 
  Of Loa Andersson<BR>&gt; Sent: Friday, July 22, 2005 12:05 PM<BR>&gt; To: Pär 
  Mattsson<BR>&gt; Cc: [email-masked]<BR>&gt; Subject: Re: Frameformat in a 
  l2cs gmpls rnvironment.<BR>&gt;<BR>&gt; Per and Dimitri,<BR>&gt;<BR>&gt; I 
  would like to come down stronger than that, for me it is<BR>&gt; a very strong 
  requirement that the same switch can handle<BR>&gt; both VLANs and GMPLs 
  trafic correctly. I can't dsee how that<BR>&gt; could be done if using the 
  VLAN tpid to indicate GMPLS<BR>&gt; traffic.<BR>&gt;<BR>&gt; 
  /Loa<BR>&gt;<BR>&gt; Pär Mattsson wrote:<BR>&gt; &gt;&gt;hi par, one of the 
  possibilities that has been considered<BR>&gt; to cope with<BR>&gt; 
  &gt;&gt;this requirement is to use a dedicated TPID for the Ethernet 
  labeled<BR>&gt; &gt;&gt;frames; this would allow differentiated processing 
  with non-labeled<BR>&gt; &gt;&gt;framesthanks.<BR>&gt; &gt;<BR>&gt; 
  &gt;<BR>&gt; &gt; That seems to make more sence. If that frame is to be 
  sized<BR>&gt; like a 802.1q<BR>&gt; &gt; frame. There is not that much space 
  left to a label. Or is<BR>&gt; the demand to<BR>&gt; &gt; use jumboframes 
  ?<BR>&gt; &gt; Has there been any discussion on labelstacking, and 
  mainly<BR>&gt; where to place<BR>&gt; &gt; the information?<BR>&gt; 
  &gt;<BR>&gt; &gt; Regards.<BR>&gt; &gt; Per<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; 
  &gt;<BR>&gt;<BR>&gt;<BR>&gt; --<BR>&gt; Loa Andersson<BR>&gt;<BR>&gt; 
  Principal Networking Architect<BR>&gt; Acreo AB &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; phone: 
  &nbsp;+46 8 632 77 14<BR>&gt; Isafjordsgatan 22 &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;mobile: +46 739 81 21 64<BR>&gt; Kista, 
  Sweden &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp;email: &nbsp;[email-masked]<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
[email-masked]<BR>&gt;</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C590E9.501C479C--

Delivery-date: Sun, 24 Jul 2005 23:30:30 +0000
Date: Mon, 25 Jul 2005 08:28:35 +0900
From: Tomohiro Otani <[email-masked]>
To: Kenichi Nagami <[email-masked]>
Cc: [email-masked]
Subject: Re: GMPLS OSPF-TE MIB

Hi Nagami-san,

Thank you for your interest and comments to our draft.

Our mib is intended to mainly support GMPLS OSPF-TE, but
we need, in the future, to support OSPF-TE as well, whether
it is in this draft or another.

Arian, can we focus on GMPLS OSPF-TE first ? And then should we
start to investigate OSPF-TE ?

Other corrections will be fixed in the future version of the draft
and are highly appreciated.

With best regards,

tomo

Kenichi Nagami wrote:

>Hi tomo,
>
>
>This work is interesting and important from management point of view.
>I have questions and comments.
>
>
>- Does this MIB support for only GMPLS OSPF-TE or both GMPLS OSPF-TE and OSPF-TE (RFC3630) ?
>
>
>- I think INDEX of the ospfTeLsdbEntry need to add Area ID. Because OSPF opaque LSA type 10 is
>  "area local scope".
>
>
>- There are a log of error for MIB definition. Could you fix them?
>  For example,
>  1) "--" is needed "in xxx"
>     current
>    DESCRIPTION
>          "Initial version. Published as RFC xxxx." -- RFC-editor pls fill
>          in xxx"
>
>
>     changed
>    DESCRIPTION
>          "Initial version. Published as RFC xxxx." -- RFC-editor pls fill
>         --  in xxx"
>
>
>  2) need to "," in ospfTeMainGroup OBJECT-GROUP
>             ospfTeSwitchingType
>             ospfTeEncoding
>     are changed to
>             ospfTeSwitchingType,
>             ospfTeEncoding,
>
>
>Regards,
>
>
>Ken Nagami
>Intec Netcore
>
>
>
>>
>>At 08:52 05/07/15, Tomohiro Otani wrote:
>>Hi everyone,
>
>
>>We posted a new draft about GMPLS OSPF-TE MIB as follows.
>>http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-ospf-mib-00.txt
>
>
>>We welcome your comments and feedbacks, pls.
>>And please make a comment whether this is within ccamp WG or not (OSPF-WG?).
>
>
>>We believe that this is a very significant definition of OSPF-TE MIB,
>>being complementary to other GMPLS related MIBs (TE/LSR/LMP mibs) in order
>>to deploy GMPLS control plane in the actual environment with simple but
>>reliable network management.
>
>
>>With best regards,
>
>
>>tomo
>
>
>
>  
>

Delivery-date: Sun, 24 Jul 2005 16:31:59 +0000
Date: Sun, 24 Jul 2005 18:30:48 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Igor Bryskin <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked],  [email-masked]
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]

igor

> What I was trying to say here is that for the User how
> TE Ethernet connection is established - via control or
> management planes is of a little importance. 

-> in the CCAMP context where the second C means "Control" it is of 
importance because the purpose of this working group is to define IP 
control plane mechanism(s)

> Before
> explaining how cool/elegant it could be provisioned
> via GMPLS you need to answer IMO the following
> questions:

-> i suggest you also take a look to section 3 and 4 and if you think 
there are additional arguments you would consider as part of these 
sections i would suggest that you share them with us

> 1) What does it mean Traffic Engineered Ethernet
> connection in the data plane and what is it good for?
> For instance, we perfectly understand what does ATM
> connection or TDM connection mean in the data plane
> and can provide references to corresponding data plane
> standards.

-> i suggest you take a look at scenario 2 for inst. that should in 
principle provide an answer to your question

> 2) How does the label-aware Ethernet forwarder
> co-exist with other Ethernet forwarders on the same
> switch

-> it is an explicit non-objective of THIS document to detail (existing) 
Ethernet forwarding behaviour and their co-existence, in part. due to 
point 3) here below

> 3) What information is necessary to provision the
> forwarding tables?

-> the current document refers to "label" entries without delving into 
details but this has been done purposely as the choice which will 
ultimately be made (e.g. VLAN Tags, or new TPIDs or something else) is 
orthogonal to be capabilities this working group wants to achieve with 
GMPLS control of Ethernet networks

> And so on.

-> in practice ?

> Cheers,
> Igor
> 
>   
> 
> 
> --- dimitri papadimitriou <[email-masked]>
> wrote:
> 
> 
>>hi igor,
>>
>>[snip - hint: igor i suggest you create a thread on
>>control vs 
>>management plane]
>>
>>
>>>My view wrt Ethertnet GMPLS is this. I have no
>>
>>doubts
>>
>>>that we can come up with mechanisms to dynamically
>>>provision L2SC LSPs. 
>>
>>ouf ;-)
>>
>>
>>>My problem is the order of events. 
>>>It does not seem to me wise to come up with
>>>some control plane framework and solution(s) and
>>
>>after
>>
>>>that think what we need to do in the data plane. 
>>
>>actually, if this is the only problem you have, i
>>should underline we do 
>>not have to initiate the definition of a specific
>>forwarding paradigm so 
>>i am not necessarily sure about what you mean by the
>>last part of the 
>>above sentence
>>
>>
>>>It seems to  me wiser to learn how to statically
>>>provision such LSPs, see how useful they are, and
>>
>>only
>>
>>>after that design and develop ways to provision
>>
>>them
>>
>>>dynamically.
>>
>>i am not sure to follow how are you going to
>>determine the benefit from 
>>dynamic provisioning by statically configure these
>>LSPs ?
>>
>>
>>>In other words, it is wiser to repeat what has
>>
>>been
>>
>>>done with TDM LSPs.
>>
>>wiser ? ... would you clarify ? don't you think it
>>is more appropriate 
>>to receive feedback on the appropriateness of the
>>use of GMPLS for the 
>>scenarios depicted in the problem statement document
>>rather than digress 
>>on non-rational argument such as "wiser", "careful"
>>or so... ?
>>
>>
>>>Cheers,
>>>Igor
>>>
>>> 
>>>
>>>
>>>>A control-plane is useful in the major co-cs
>>>>transport networks (mainly
>>>>for S-PVCs and resilience) but its a minor player
>>>>compared to role of
>>>>the management-plane.   The converse of course
>>
>>holds
>>
>>>>in a *traffic*
>>>>carrying cl-ps  IP network, esp when this is in
>>
>>the
>>
>>>>context of the
>>>>public Internet.....but of course this isn't the
>>>>case here and IP is
>>>>only being used as the transport protocol in the
>>
>>OOB
>>
>>>>data-plane network
>>>>that carries the control/management-plane
>>
>>protocols.
>>
>>>>
>>>>These were points I wanted to make.....hopefully
>>>>I've done a better job
>>>>this time.
>>>>
>>>>regards, Neil
>>>>
>>>>
>>>>
>>>>From: Adrian Farrel [mailto:[email-masked]] 
>>>>Sent: 23 July 2005 00:08
>>>>To: Harrison,N,Neil,IKM1 R
>>>>Cc: [email-masked]
>>>>Subject: Re: Ethernet Control Plane [Was: Re:
>>>>Frameformat in a l2cs
>>>>gmpls rnvironment.]
>>>>
>>>>
>>>>Hi Neil,
>>>>
>>>>I think John beat me off the blocks here, but...
>>>>
>>>>
>>>>
>>>>
>>>>>>GMPLS assumes an IP control plane.
>>>>>
>>>>>An IP control-plane?  There is actually no such
>>>>
>>>>animal.  Just what 
>>>>
>>>>
>>>>>the heck does that REALLY mean in GMPLS say?
>>>>
>>>>
>>>>Let me explain.
>>>>Perhaps I should have said "IP-based control
>>
>>plane".
>>
>>>>I mean a control plane which:
>>>>- uses IP as its network protocol
>>>>- uses IP addresses to identify control plane
>>>>resources
>>>>- uses IP addresses to identify data plane
>>
>>resources
>>
>>>>within 
>>>> the control plane
>>>>- uses protocols developed for use in the
>>
>>Internet.
>>
>>>>
>>>>>I am not questioning IP as a cl-ps networking
>>>>
>>>>protocol *carrying* 
>>>>
>>>>
>>>>>a signalling protocol (RSVP-TE, or dare I mention
>>>>
>>>>PNNI, or any 
>>>>
>>>>
>>>>>signalling protocol yet to be invented) or a
>>>>
>>>>routing protocol 
>>>>
>>>>
>>>>>(OSPF or ISO or whatever)
>>>>
>>>>
>>>>I am glad to hear it.
>>>>
>>>>
>>>>
>>>>>or even management protocols
>>>>
>>>>
>>>>Fine, but not in the remit of CCAMP.
>>>>
>>>>
>>>>
>>>>>but an 'IP Control Plane' per se means absolutely
>>>>
>>>>nothing to me....
>>>>
>>>>Well, I think it should. I think the list of
>>>>attributes that I have
>>>>given above define a control plane based on IP. 
>>>>
>>>>It is undoubtable that attempts have been made to
>>>>use control planes
>>>>based on other protocols. Some have been highly
>>>>successful. Some have
>>>>been less fortunate.
>>>>
>>>>
>>>>
>>>>>...nor should it to anyone else. 
>>>>
>>>>
>>>>I think folks who were around at the beginning of
>>>>CCAMP and who were
>>>>part of the debate with the IESG will be very
>>>>familiar with where the
>>>>IETF draws the line here.
>>>>
>>>>
>>>>
>>>>
>>>>>I think some folks might need a reality check
>>>>
>>>>here....and also
>>>>
>>>>
>>>>>on the self-assumed importance of a
>>
>>control-plane.
>>
>>>>Hint: It ain't 
>>>>
>>>>
>>>>>that important.....the management-plane (which
>>
>>may
>>
>>>>be using IP!) 
>>>>
>>>>
>>>>>however is.
>>>>
>>>>
>>>>I am not sure how to interpret this.
>>>>It may be that you think that control plane is bad
>>>>per se, but you have
>>>>said elsewhere that you think it has value - but
>>>>much less than the
>>>>management plane.
>>>>It may be that you believe that CCAMP is willfully
>>>>neglecting the
>>>>management plane. This would, in fact, be true. It
>>>>is not in CCAMP's
>>
> === message truncated ===
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
> .
> 

Delivery-date: Sun, 24 Jul 2005 15:07:35 +0000
Date: Sun, 24 Jul 2005 08:05:32 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]

Dimitri,

What I was trying to say here is that for the User how
TE Ethernet connection is established - via control or
management planes is of a little importance. Before
explaining how cool/elegant it could be provisioned
via GMPLS you need to answer IMO the following
questions:

1) What does it mean Traffic Engineered Ethernet
connection in the data plane and what is it good for?
For instance, we perfectly understand what does ATM
connection or TDM connection mean in the data plane
and can provide references to corresponding data plane
standards.

2) How does the label-aware Ethernet forwarder
co-exist with other Ethernet forwarders on the same
switch

3) What information is necessary to provision the
forwarding tables?

And so on.

Cheers,
Igor

--- dimitri papadimitriou <[email-masked]>
wrote:

> hi igor,
> 
> [snip - hint: igor i suggest you create a thread on
> control vs 
> management plane]
> 
> > My view wrt Ethertnet GMPLS is this. I have no
> doubts
> > that we can come up with mechanisms to dynamically
> > provision L2SC LSPs. 
> 
> ouf ;-)
> 
> > My problem is the order of events. 
> > It does not seem to me wise to come up with
> > some control plane framework and solution(s) and
> after
> > that think what we need to do in the data plane. 
> 
> actually, if this is the only problem you have, i
> should underline we do 
> not have to initiate the definition of a specific
> forwarding paradigm so 
> i am not necessarily sure about what you mean by the
> last part of the 
> above sentence
> 
> > It seems to  me wiser to learn how to statically
> > provision such LSPs, see how useful they are, and
> only
> > after that design and develop ways to provision
> them
> > dynamically.
> 
> i am not sure to follow how are you going to
> determine the benefit from 
> dynamic provisioning by statically configure these
> LSPs ?
> 
> > In other words, it is wiser to repeat what has
> been
> > done with TDM LSPs.
> 
> wiser ? ... would you clarify ? don't you think it
> is more appropriate 
> to receive feedback on the appropriateness of the
> use of GMPLS for the 
> scenarios depicted in the problem statement document
> rather than digress 
> on non-rational argument such as "wiser", "careful"
> or so... ?
> 
> > Cheers,
> > Igor
> > 
> >  
> > 
> >>A control-plane is useful in the major co-cs
> >>transport networks (mainly
> >>for S-PVCs and resilience) but its a minor player
> >>compared to role of
> >>the management-plane.   The converse of course
> holds
> >>in a *traffic*
> >>carrying cl-ps  IP network, esp when this is in
> the
> >>context of the
> >>public Internet.....but of course this isn't the
> >>case here and IP is
> >>only being used as the transport protocol in the
> OOB
> >>data-plane network
> >>that carries the control/management-plane
> protocols.
> >> 
> >> 
> >>These were points I wanted to make.....hopefully
> >>I've done a better job
> >>this time.
> >> 
> >>regards, Neil
> >> 
> >> 
> >>
> >>From: Adrian Farrel [mailto:[email-masked]] 
> >>Sent: 23 July 2005 00:08
> >>To: Harrison,N,Neil,IKM1 R
> >>Cc: [email-masked]
> >>Subject: Re: Ethernet Control Plane [Was: Re:
> >>Frameformat in a l2cs
> >>gmpls rnvironment.]
> >>
> >>
> >>Hi Neil,
> >> 
> >>I think John beat me off the blocks here, but...
> >>
> >>
> >>
> >>>>GMPLS assumes an IP control plane.
> >>>
> >>>An IP control-plane?  There is actually no such
> >>
> >>animal.  Just what 
> >>
> >>>the heck does that REALLY mean in GMPLS say?
> >>
> >> 
> >>Let me explain.
> >>Perhaps I should have said "IP-based control
> plane".
> >>I mean a control plane which:
> >>- uses IP as its network protocol
> >>- uses IP addresses to identify control plane
> >>resources
> >>- uses IP addresses to identify data plane
> resources
> >>within 
> >>  the control plane
> >>- uses protocols developed for use in the
> Internet.
> >> 
> >>
> >>>I am not questioning IP as a cl-ps networking
> >>
> >>protocol *carrying* 
> >>
> >>>a signalling protocol (RSVP-TE, or dare I mention
> >>
> >>PNNI, or any 
> >>
> >>>signalling protocol yet to be invented) or a
> >>
> >>routing protocol 
> >>
> >>>(OSPF or ISO or whatever)
> >>
> >> 
> >>I am glad to hear it.
> >> 
> >>
> >>>or even management protocols
> >>
> >> 
> >>Fine, but not in the remit of CCAMP.
> >> 
> >>
> >>>but an 'IP Control Plane' per se means absolutely
> >>
> >>nothing to me....
> >> 
> >>Well, I think it should. I think the list of
> >>attributes that I have
> >>given above define a control plane based on IP. 
> >> 
> >>It is undoubtable that attempts have been made to
> >>use control planes
> >>based on other protocols. Some have been highly
> >>successful. Some have
> >>been less fortunate.
> >> 
> >>
> >>>...nor should it to anyone else. 
> >>
> >> 
> >>I think folks who were around at the beginning of
> >>CCAMP and who were
> >>part of the debate with the IESG will be very
> >>familiar with where the
> >>IETF draws the line here.
> >> 
> >> 
> >>
> >>>I think some folks might need a reality check
> >>
> >>here....and also
> >>
> >>>on the self-assumed importance of a
> control-plane.
> >>
> >>Hint: It ain't 
> >>
> >>>that important.....the management-plane (which
> may
> >>
> >>be using IP!) 
> >>
> >>>however is.
> >>
> >> 
> >>I am not sure how to interpret this.
> >>It may be that you think that control plane is bad
> >>per se, but you have
> >>said elsewhere that you think it has value - but
> >>much less than the
> >>management plane.
> >>It may be that you believe that CCAMP is willfully
> >>neglecting the
> >>management plane. This would, in fact, be true. It
> >>is not in CCAMP's
> 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Delivery-date: Sun, 24 Jul 2005 03:36:30 +0000
Date: Sat, 23 Jul 2005 20:33:45 -0700
From: Arun Satyanarayana <[email-masked]>
Organization: Cisco Systems
To: [email-masked], Adrian Farrel <[email-masked]>, Kireeti Kompella <[email-masked]>
CC: Lou Berger <[email-masked]>, Dimitri Papadimitriou <[email-masked]>, Reshad Rahman <[email-masked]>, Anca Zamfir <[email-masked]>, Junaid Israr <[email-masked]>, "Arun Satyanarayana (asatyana)" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-03.txt

Hi all,

Version -03 is the updated version resulting from last-call comments.

A scalability concern was raised, where, the restarting node does not
support the mechanism in this I-D, but, one or more RSVP neighbors do.
This would result in unnecessary generation (and possible
retransmission) of RecoveryPath msgs by the neighbors, and, receive
processing of the RecoveryPath msg until the restarting node has to
decide to drop it. This may be a scalability issue when a large number
of LSPs are active on the restarting node.

The solution is to indicate the capability to transmit and receive
RecoveryPath msgs with 2 new bits in the Capability object.

Note: The above solution also addresses a similar concern raised
earlier, where, the restarting node support the extensions but one or
more of its neighbors do not. The restarting node would have to wait
until the end of the Recovery Period to revert to restart processing per
RFC3473. With an explicit advertisement of RecoveryPath capability, this
requirement no longer exists.

We (the co-authors) hope that a short last-call to review the above
change only is sufficient to progress the I-D. Please review and
comment.

Thanks,
Arun
==============================================================
[email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
> 
> 	Title		: Extensions to GMPLS RSVP Graceful Restart
> 	Author(s)	: A. Satyanarayana
> 	Filename	: draft-ietf-ccamp-rsvp-restart-ext-03.txt
> 	Pages		: 24
> 	Date		: 2005-7-19
> 	
> This document describes extensions to the RSVP Graceful Restart
>    mechanisms defined in RFC 3473.  The extensions enable the recovery
>    of RSVP signaling state based on the Path message last sent by the
>    node being restarted.  Previously defined Graceful Restart
>    mechanisms, also called recovery from nodal faults, permit recovery
>    of signaling state from adjacent nodes when the data plane has
>    retained the associated forwarding state across a restart.  These
>    mechanisms do not fully support signaling state recovery on ingress
>    nodes or recovery of all RSVP objects.  The presented extensions use
>    the RSVP Hello extensions defined in RFC 3209, and extensions for
>    state recovery on nodal faults defined in RFC 3473.  With the
>    presented extensions the restarting node can recover all previously
>    transmitted Path state including the Explicit Route Object and the
>    downstream (outgoing) interface identifiers.  The extensions can also
>    be used to recover signaling state after the restart of an ingress
>    node.  The extensions optionally support the use of Summary Refresh,
>    defined in RFC 2961, to reduce the number of messages exchanged
>    during the Recovery Phase when the restarting node has recovered
>    signaling state locally for one or more LSPs.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-03.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-ccamp-rsvp-restart-ext-03.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-03.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

Delivery-date: Sat, 23 Jul 2005 17:22:33 +0000
Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Sat, 23 Jul 2005 17:58:27 +0200

Neil

Is there an ITU-T Recommendation that gives an architectural definition of what
it means by control plane, data plane, management plane, user plane, traffic
dataplane, control data plane etc etc?

I know what I mean when I use the terms but am not sure I always know what
others mean.

Tom Petch
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, July 23, 2005 2:15 PM
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls
rnvironment.]

> > > IP is cl-ps networking techology period....and its
> > > jolly important, but PLEASE don't try and feed me any of this 'IP
> > > control plane' nonsense.
>
> JD:  Over the years I have enjoyed Neil's rants immensely,
> but I have to say that this one is a classic.

NH=> Thanks John for the kind words....its good to know you've had at
least something to smile about ;-)

Seriously though, see my updated response to Adrian.  But if you are
still struggling to grasp what I mean by the above (out of context
quote) try this:

A single cl-ps IP network carrying traffic and everything else (eg
public Internet) is very different animal to a co-cs network system
where the traffic data-plane network and control/management data-planes
network are logically disjoint, ie the role of IP in the latter is
importantly different to the role of IP in the former...and let's hope
never the 2 shall meet.

regards, neil

Delivery-date: Sat, 23 Jul 2005 16:44:59 +0000
Date: Sat, 23 Jul 2005 18:43:18 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Igor Bryskin <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked]
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]

hi igor,

[snip - hint: igor i suggest you create a thread on control vs 
management plane]

> My view wrt Ethertnet GMPLS is this. I have no doubts
> that we can come up with mechanisms to dynamically
> provision L2SC LSPs. 

ouf ;-)

> My problem is the order of events. 
> It does not seem to me wise to come up with
> some control plane framework and solution(s) and after
> that think what we need to do in the data plane. 

actually, if this is the only problem you have, i should underline we do 
not have to initiate the definition of a specific forwarding paradigm so 
i am not necessarily sure about what you mean by the last part of the 
above sentence

> It seems to  me wiser to learn how to statically
> provision such LSPs, see how useful they are, and only
> after that design and develop ways to provision them
> dynamically.

i am not sure to follow how are you going to determine the benefit from 
dynamic provisioning by statically configure these LSPs ?

> In other words, it is wiser to repeat what has been
> done with TDM LSPs.

wiser ? ... would you clarify ? don't you think it is more appropriate 
to receive feedback on the appropriateness of the use of GMPLS for the 
scenarios depicted in the problem statement document rather than digress 
on non-rational argument such as "wiser", "careful" or so... ?

> Cheers,
> Igor
> 
>  
> 
>>A control-plane is useful in the major co-cs
>>transport networks (mainly
>>for S-PVCs and resilience) but its a minor player
>>compared to role of
>>the management-plane.   The converse of course holds
>>in a *traffic*
>>carrying cl-ps  IP network, esp when this is in the
>>context of the
>>public Internet.....but of course this isn't the
>>case here and IP is
>>only being used as the transport protocol in the OOB
>>data-plane network
>>that carries the control/management-plane protocols.
>> 
>> 
>>These were points I wanted to make.....hopefully
>>I've done a better job
>>this time.
>> 
>>regards, Neil
>> 
>> 
>>
>>From: Adrian Farrel [mailto:[email-masked]] 
>>Sent: 23 July 2005 00:08
>>To: Harrison,N,Neil,IKM1 R
>>Cc: [email-masked]
>>Subject: Re: Ethernet Control Plane [Was: Re:
>>Frameformat in a l2cs
>>gmpls rnvironment.]
>>
>>
>>Hi Neil,
>> 
>>I think John beat me off the blocks here, but...
>>
>>
>>
>>>>GMPLS assumes an IP control plane.
>>>
>>>An IP control-plane?  There is actually no such
>>
>>animal.  Just what 
>>
>>>the heck does that REALLY mean in GMPLS say?
>>
>> 
>>Let me explain.
>>Perhaps I should have said "IP-based control plane".
>>I mean a control plane which:
>>- uses IP as its network protocol
>>- uses IP addresses to identify control plane
>>resources
>>- uses IP addresses to identify data plane resources
>>within 
>>  the control plane
>>- uses protocols developed for use in the Internet.
>> 
>>
>>>I am not questioning IP as a cl-ps networking
>>
>>protocol *carrying* 
>>
>>>a signalling protocol (RSVP-TE, or dare I mention
>>
>>PNNI, or any 
>>
>>>signalling protocol yet to be invented) or a
>>
>>routing protocol 
>>
>>>(OSPF or ISO or whatever)
>>
>> 
>>I am glad to hear it.
>> 
>>
>>>or even management protocols
>>
>> 
>>Fine, but not in the remit of CCAMP.
>> 
>>
>>>but an 'IP Control Plane' per se means absolutely
>>
>>nothing to me....
>> 
>>Well, I think it should. I think the list of
>>attributes that I have
>>given above define a control plane based on IP. 
>> 
>>It is undoubtable that attempts have been made to
>>use control planes
>>based on other protocols. Some have been highly
>>successful. Some have
>>been less fortunate.
>> 
>>
>>>...nor should it to anyone else. 
>>
>> 
>>I think folks who were around at the beginning of
>>CCAMP and who were
>>part of the debate with the IESG will be very
>>familiar with where the
>>IETF draws the line here.
>> 
>> 
>>
>>>I think some folks might need a reality check
>>
>>here....and also
>>
>>>on the self-assumed importance of a control-plane.
>>
>>Hint: It ain't 
>>
>>>that important.....the management-plane (which may
>>
>>be using IP!) 
>>
>>>however is.
>>
>> 
>>I am not sure how to interpret this.
>>It may be that you think that control plane is bad
>>per se, but you have
>>said elsewhere that you think it has value - but
>>much less than the
>>management plane.
>>It may be that you believe that CCAMP is willfully
>>neglecting the
>>management plane. This would, in fact, be true. It
>>is not in CCAMP's
>>remit to look at the management plane. Other SDOs
>>are working to
>>establish common standards for management of network
>>devices across
>>multiple vendors - we can wish them luck.
>>Clearly some people (vendors and providers) see
>>sufficient value in a
>>control plane to invest time and energy.
>>
>>
>>>The (hype) party is over for the OTN start-ups. 
>>
>>IP per se does NOT
>>
>>>define a *control-plane*...IP is cl-ps networking
>>
>>techology period
>>
>>>....and its jolly important, but PLEASE don't try
>>
>>and feed me any of
>>
>>>this 'IP control plane' nonsense.
>>
> === message truncated ===
> 
> 
> 
> 		
> ____________________________________________________
> Start your day with Yahoo! - make it your home page 
> http://www.yahoo.com/r/hs 
>  
> 
> 
> .
> 

Delivery-date: Sat, 23 Jul 2005 13:50:45 +0000
Date: Sat, 23 Jul 2005 06:49:31 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
To: [email-masked], [email-masked]
Cc: [email-masked]

Neil,

[SNIP]

> I am also a little concerned that some folks might
> naively assume that a
> control-plane is going to solve all their
> management-plane
> issues......when we move down the network stack to
> the duct there are a
> whole raft of factors that mean the management-plane
> still dominates
> here.  If you talk to the right folks in the
> operators who run these
> types of network you will indeed understand what I
> mean by this.

This kind of statements you've been making in about
every email. I am curious to know as we move towards
the duct which *exactly* features, provisioning
functions or operations that are implemented via NMS
could not be conceptually realized via control plane? 
Or you are not the "right folk to ask" ? :=)

My view wrt Ethertnet GMPLS is this. I have no doubts
that we can come up with mechanisms to dynamically
provision L2SC LSPs. My problem is the order of
events. It does not seem to me wise to come up with
some control plane framework and solution(s) and after
that think what we need to do in the data plane. It
seems to  me wiser to learn how to statically
provision such LSPs, see how useful they are, and only
after that design and develop ways to provision them
dynamically.
In other words, it is wiser to repeat what has been
done with TDM LSPs.

Cheers,
Igor

> A control-plane is useful in the major co-cs
> transport networks (mainly
> for S-PVCs and resilience) but its a minor player
> compared to role of
> the management-plane.   The converse of course holds
> in a *traffic*
> carrying cl-ps  IP network, esp when this is in the
> context of the
> public Internet.....but of course this isn't the
> case here and IP is
> only being used as the transport protocol in the OOB
> data-plane network
> that carries the control/management-plane protocols.
>  
>  
> These were points I wanted to make.....hopefully
> I've done a better job
> this time.
>  
> regards, Neil
>  
>  
> 
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: 23 July 2005 00:08
> To: Harrison,N,Neil,IKM1 R
> Cc: [email-masked]
> Subject: Re: Ethernet Control Plane [Was: Re:
> Frameformat in a l2cs
> gmpls rnvironment.]
> 
> 
> Hi Neil,
>  
> I think John beat me off the blocks here, but...
> 
> 
> > > GMPLS assumes an IP control plane.
> >
> > An IP control-plane?  There is actually no such
> animal.  Just what 
> > the heck does that REALLY mean in GMPLS say?
>  
> Let me explain.
> Perhaps I should have said "IP-based control plane".
> I mean a control plane which:
> - uses IP as its network protocol
> - uses IP addresses to identify control plane
> resources
> - uses IP addresses to identify data plane resources
> within 
>   the control plane
> - uses protocols developed for use in the Internet.
>  
> > I am not questioning IP as a cl-ps networking
> protocol *carrying* 
> > a signalling protocol (RSVP-TE, or dare I mention
> PNNI, or any 
> > signalling protocol yet to be invented) or a
> routing protocol 
> > (OSPF or ISO or whatever)
>  
> I am glad to hear it.
>  
> > or even management protocols
>  
> Fine, but not in the remit of CCAMP.
>  
> > but an 'IP Control Plane' per se means absolutely
> nothing to me....
>  
> Well, I think it should. I think the list of
> attributes that I have
> given above define a control plane based on IP. 
>  
> It is undoubtable that attempts have been made to
> use control planes
> based on other protocols. Some have been highly
> successful. Some have
> been less fortunate.
>  
> > ...nor should it to anyone else. 
>  
> I think folks who were around at the beginning of
> CCAMP and who were
> part of the debate with the IESG will be very
> familiar with where the
> IETF draws the line here.
>  
>  
> > I think some folks might need a reality check
> here....and also
> > on the self-assumed importance of a control-plane.
> Hint: It ain't 
> > that important.....the management-plane (which may
> be using IP!) 
> > however is.
>  
> I am not sure how to interpret this.
> It may be that you think that control plane is bad
> per se, but you have
> said elsewhere that you think it has value - but
> much less than the
> management plane.
> It may be that you believe that CCAMP is willfully
> neglecting the
> management plane. This would, in fact, be true. It
> is not in CCAMP's
> remit to look at the management plane. Other SDOs
> are working to
> establish common standards for management of network
> devices across
> multiple vendors - we can wish them luck.
> Clearly some people (vendors and providers) see
> sufficient value in a
> control plane to invest time and energy.
> 
> > The (hype) party is over for the OTN start-ups. 
> IP per se does NOT
> > define a *control-plane*...IP is cl-ps networking
> techology period
> > ....and its jolly important, but PLEASE don't try
> and feed me any of
> > this 'IP control plane' nonsense.
> 
=== message truncated ===

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 

Delivery-date: Sat, 23 Jul 2005 12:16:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Sat, 23 Jul 2005 13:15:19 +0100
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58F80.310DD9EA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ok thanks Adrian,
=20
Re-reading what I wrote and your response (and John's) I can see I did
an awful job of trying to explain what I really meant...and I'm not
surprised you responded as you did.  So my apologies for letting
frustration get the better of me.  Trying to express it better:
=20
Its simply not true that one can have a 'common' control-plane approach
from IP to Optics.......for many reasons such as: the modal differences
demand different approaches, who owns what layer network, the notion
that one can create topology on the fly, the commercial factors that
govern GoS network build-out, the relative importance of the
control-plane vs the management plane (which also varies with network
mode and where you are in the stack), etc.
=20
However, if you go back some time the impression that was originally
'sold' to folks was that there IS this common control-plane from IP to
Optics.  This view may have mellowed now, but I still see evidence of it
of every now and then....and its when I see things that IMO are being
somewhat 'economical with the truth' that I tend to react.
=20
I also don't like it when folks go break architectural rules and
'pretend its OK/good'.  This is not generally an issue in CCAMPs as its
jolly hard to do much damage to the co-cs mode....but you can for sure
create havoc in the co-ps mode.   And at the end of the day arch
violations and functional omissions/deficiencies end up as operational
problems and opex costs in our networks.  If more folks understood
functional architecture stuff I suspect this would help control this
particular issue better.
=20
We therefore have the real situation that there is no forced technical
reason to be prescriptive in the choice of control-plane functional
components when we are dealing with our major SDH/OTN co-cs transport
networks.....which, of course, also have nothing to do with the public
Internet   That is, they can be chosen on a best-of-breed basis.  =20
=20
I am also a little concerned that some folks might naively assume that a
control-plane is going to solve all their management-plane
issues......when we move down the network stack to the duct there are a
whole raft of factors that mean the management-plane still dominates
here.  If you talk to the right folks in the operators who run these
types of network you will indeed understand what I mean by this.
=20
A control-plane is useful in the major co-cs transport networks (mainly
for S-PVCs and resilience) but its a minor player compared to role of
the management-plane.   The converse of course holds in a *traffic*
carrying cl-ps  IP network, esp when this is in the context of the
public Internet.....but of course this isn't the case here and IP is
only being used as the transport protocol in the OOB data-plane network
that carries the control/management-plane protocols. =20
=20
These were points I wanted to make.....hopefully I've done a better job
this time.
=20
regards, Neil
=20
=20

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]=20
Sent: 23 July 2005 00:08
To: Harrison,N,Neil,IKM1 R
Cc: [email-masked]
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs
gmpls rnvironment.]

Hi Neil,
=20
I think John beat me off the blocks here, but...

> > GMPLS assumes an IP control plane.
>
> An IP control-plane?  There is actually no such animal.  Just what=20
> the heck does that REALLY mean in GMPLS say?
=20
Let me explain.
Perhaps I should have said "IP-based control plane".
I mean a control plane which:
- uses IP as its network protocol
- uses IP addresses to identify control plane resources
- uses IP addresses to identify data plane resources within=20
  the control plane
- uses protocols developed for use in the Internet.
=20
> I am not questioning IP as a cl-ps networking protocol *carrying*=20
> a signalling protocol (RSVP-TE, or dare I mention PNNI, or any=20
> signalling protocol yet to be invented) or a routing protocol=20
> (OSPF or ISO or whatever)
=20
I am glad to hear it.
=20
> or even management protocols
=20
Fine, but not in the remit of CCAMP.
=20
> but an 'IP Control Plane' per se means absolutely nothing to me....
=20
Well, I think it should. I think the list of attributes that I have
given above define a control plane based on IP.=20
=20
It is undoubtable that attempts have been made to use control planes
based on other protocols. Some have been highly successful. Some have
been less fortunate.
=20
> ...nor should it to anyone else.=20
=20
I think folks who were around at the beginning of CCAMP and who were
part of the debate with the IESG will be very familiar with where the
IETF draws the line here.
=20
=20
> I think some folks might need a reality check here....and also
> on the self-assumed importance of a control-plane. Hint: It ain't=20
> that important.....the management-plane (which may be using IP!)=20
> however is.
=20
I am not sure how to interpret this.
It may be that you think that control plane is bad per se, but you have
said elsewhere that you think it has value - but much less than the
management plane.
It may be that you believe that CCAMP is willfully neglecting the
management plane. This would, in fact, be true. It is not in CCAMP's
remit to look at the management plane. Other SDOs are working to
establish common standards for management of network devices across
multiple vendors - we can wish them luck.
Clearly some people (vendors and providers) see sufficient value in a
control plane to invest time and energy.

> The (hype) party is over for the OTN start-ups.  IP per se does NOT
> define a *control-plane*...IP is cl-ps networking techology period
> ....and its jolly important, but PLEASE don't try and feed me any of
> this 'IP control plane' nonsense.
=20
Tush.
=20
> Adrian....you are far smarter than this IMO and should know better.
=20
Thanks for the endorsement. May I quote you?
=20
Adrian

------_=_NextPart_001_01C58F80.310DD9EA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Ok thanks Adrian,</FONT></SPAN></DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Re-reading what I wrote and your response (and John's) I can =
see I did an=20
awful job of trying to explain what I really meant...and I'm not =
surprised you=20
responded as you did.&nbsp; So my apologies for letting frustration get =
the=20
better of me.&nbsp; Trying to express it better:</FONT></SPAN></DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Its simply not true that one can have a 'common' control-plane =
approach=20
from IP to Optics.......for many reasons such as: the modal differences =
demand=20
different approaches, who owns what layer network, the notion that one =
can=20
create topology on the fly, the commercial factors that govern GoS =
network=20
build-out, the relative importance of the control-plane vs the =
management plane=20
(which also varies with network mode and where you are in the stack),=20
etc.</FONT></SPAN></DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D924593210-23072005><SPAN =
class=3D924593210-23072005><FONT=20
face=3D"Comic Sans MS" color=3D#800000 size=3D2><SPAN =
class=3D924593210-23072005><FONT=20
face=3D"Comic Sans MS" color=3D#800000 size=3D2>However, if you go back =
some time the=20
impression that was originally 'sold' to folks was that there IS this =
common=20
control-plane from IP to Optics.&nbsp; This view may have mellowed now, =
but I=20
still see evidence of it of every now and then....and its when I see =
things that=20
IMO are being somewhat 'economical with the truth' that I tend to=20
react.</FONT></SPAN></FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D924593210-23072005><SPAN =
class=3D924593210-23072005><FONT=20
face=3D"Comic Sans MS" color=3D#800000 size=3D2><SPAN=20
class=3D924593210-23072005></SPAN></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D924593210-23072005><SPAN =
class=3D924593210-23072005><FONT=20
face=3D"Comic Sans MS" color=3D#800000 size=3D2><SPAN =
class=3D924593210-23072005>I also=20
don't like it when folks go break architectural rules and 'pretend its=20
OK/good'.&nbsp; This is not generally an issue in CCAMPs as its jolly =
hard to do=20
much damage to the co-cs mode....but you can for sure create havoc in =
the co-ps=20
mode.&nbsp;&nbsp; And at the end of the day arch violations and =
functional=20
omissions/deficiencies end up as operational problems and opex costs in =
our=20
networks.&nbsp; If more folks understood functional architecture stuff I =
suspect=20
this would help control this particular issue=20
better.</SPAN></FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D924593210-23072005><SPAN =
class=3D924593210-23072005><FONT=20
face=3D"Comic Sans MS" color=3D#800000 size=3D2><SPAN=20
class=3D924593210-23072005></SPAN></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>We therefore have the real situation that there is no forced =
technical=20
reason to be prescriptive in the choice of control-plane functional =
components=20
when we are dealing with our major SDH/OTN co-cs transport =
networks.....which,=20
of course, also&nbsp;have nothing to do with the public=20
Internet&nbsp;&nbsp;</FONT></SPAN><SPAN class=3D924593210-23072005><FONT =

face=3D"Comic Sans MS" color=3D#800000 size=3D2><SPAN =
class=3D924593210-23072005><FONT=20
face=3D"Comic Sans MS" color=3D#800000 size=3D2>&nbsp;</FONT></SPAN>That =
is, they can=20
be chosen on a best-of-breed basis.&nbsp;&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D924593210-23072005></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D924593210-23072005></SPAN><SPAN =
class=3D924593210-23072005><FONT=20
face=3D"Comic Sans MS" color=3D#800000 size=3D2>I am also a little =
concerned that some=20
folks might naively assume that a control-plane is going to solve all =
their=20
management-plane issues......when we move down the network stack to the =
duct=20
there are a whole raft of factors that mean the management-plane still =
dominates=20
here.&nbsp; If you talk to the right folks in the operators who run =
these types=20
of network you will indeed understand what I mean by =
this.</FONT></SPAN></DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>A control-plane is useful in the major co-cs transport networks =
(mainly=20
for S-PVCs and resilience) but its a minor player compared to role of =
the=20
management-plane.&nbsp;&nbsp; The converse of course holds in&nbsp;a =
*traffic*=20
carrying cl-ps&nbsp;&nbsp;IP network, esp when this is in the context of =
the=20
public Internet.....but of course this isn't the case here and IP is =
only being=20
used as the transport protocol in the OOB data-plane network that =
carries the=20
control/management-plane protocols.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN><SPAN class=3D924593210-23072005><FONT =
face=3D"Comic Sans MS"=20
color=3D#800000 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>These were points I wanted to make.....hopefully I've done a =
better job=20
this time.</FONT></SPAN></DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D924593210-23072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>&nbsp;</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Adrian Farrel=20
  [mailto:[email-masked]] <BR><B>Sent:</B> 23 July 2005 =
00:08<BR><B>To:</B>=20
  Harrison,N,Neil,IKM1 R<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B> Re:=20
  Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls=20
  rnvironment.]<BR><BR></FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>Hi Neil,</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>I think John beat me off the blocks =
here,=20
  but...</FONT></DIV>
  <DIV><FONT face=3DCourier><BR><FONT size=3D2></FONT></FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; &gt; GMPLS assumes an IP =
control=20
  plane.<BR>&gt;<BR>&gt; An IP control-plane?&nbsp; There is actually no =
such=20
  animal.&nbsp; Just what </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; the&nbsp;</FONT><FONT =
face=3DCourier=20
  size=3D2>heck does that REALLY mean in GMPLS say?</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Let me explain.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>Perhaps I should have said =
"IP-based control=20
  plane".</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>I mean a control plane =
which:</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>- uses IP as its network =
protocol</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>- uses IP addresses to identify =
control plane=20
  resources</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>- uses IP addresses to identify =
data plane=20
  resources within </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp; the control =
plane</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>- uses protocols developed for use =
in the=20
  Internet.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; I am not =
questioning&nbsp;</FONT><FONT=20
  face=3DCourier size=3D2>IP</FONT><FONT face=3DCourier =
size=3D2>&nbsp;as a cl-ps=20
  networking protocol *carrying* </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; a signalling =
protocol&nbsp;</FONT><FONT=20
  face=3DCourier size=3D2>(</FONT><FONT face=3DCourier size=3D2>RSVP-TE, =
or dare I=20
  mention PNNI, or any </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; signalling protocol =
yet&nbsp;</FONT><FONT=20
  face=3DCourier><FONT size=3D2><FONT =
size=3D+0>to</FONT></FONT></FONT><FONT=20
  face=3DCourier size=3D2>&nbsp;be invented) or a routing protocol =
</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; (OSPF or ISO or =
whatever)</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>I am glad to hear it.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;or&nbsp;</FONT><FONT =
face=3DCourier=20
  size=3D2>even management protocols</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Fine, but not in the remit of=20
  CCAMP.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;but an 'IP Control Plane' =
per se=20
  means&nbsp;</FONT><FONT face=3DCourier size=3D2>absolutely nothing to=20
  me....</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Well, I think it should. I think =
the list of=20
  attributes that I have given above define a control plane based on IP. =

  </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>It is undoubtable that attempts =
have been made=20
  to use control planes based on other protocols. Some have been highly=20
  successful. Some have been less fortunate.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; ...nor should it to anyone=20
  else.&nbsp;</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>I think folks who were around at =
the beginning=20
  of CCAMP and who were part of the debate with the IESG will be very =
familiar=20
  with where the IETF draws the line here.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; I think&nbsp;</FONT><FONT =
face=3DCourier=20
  size=3D2>some folks might need a reality check here....and =
also</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;on the self-</FONT><FONT =
face=3DCourier=20
  size=3D2>assumed importance of a control-plane.&nbsp;H</FONT><FONT =
face=3DCourier=20
  size=3D2>int: It ain't </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; that&nbsp;</FONT><FONT =
face=3DCourier=20
  size=3D2>important.....the management-plane (which may be using IP!)=20
  </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; however</FONT><FONT =
face=3DCourier=20
  size=3D2>&nbsp;is.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>I am not sure how to interpret=20
  this.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>It may be that you think that =
control plane is=20
  bad per se, but you have said elsewhere that you think it has value - =
but much=20
  less than the management plane.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>It may be that you believe that =
CCAMP is=20
  willfully neglecting the management plane. This would, in fact, be =
true. It is=20
  not in CCAMP's remit to look at the management plane. Other SDOs are =
working=20
  to establish common standards for management of network devices across =

  multiple vendors - we can wish them luck.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>Clearly some people (vendors and =
providers) see=20
  sufficient value in a control plane to invest time and energy.</DIV>
  <DIV><BR>&gt; The (hype) party is over for the OTN start-ups.&nbsp; IP =
per se=20
  does NOT</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;define a =
*control-plane*...IP is=20
  cl-ps networking techology period</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; ....and its jolly important, =
but PLEASE=20
  don't try and feed me any of</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;this 'IP control plane'=20
  nonsense.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Tush.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV>
  <DIV>&gt; Adrian....you are far smarter than this IMO and should know=20
  better.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Thanks for the endorsement. May I quote you?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Adrian<BR></DIV></BLOCKQUOTE></FONT><FONT face=3DCourier=20
size=3D2></FONT></BODY></HTML>

------_=_NextPart_001_01C58F80.310DD9EA--

Delivery-date: Sat, 23 Jul 2005 12:16:51 +0000
Content-class: urn:content-classes:message
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Sat, 23 Jul 2005 13:15:18 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

> > > IP is cl-ps networking techology period....and its
> > > jolly important, but PLEASE don't try and feed me any of this 'IP
> > > control plane' nonsense.
>=20
> JD:  Over the years I have enjoyed Neil's rants immensely,
> but I have to say that this one is a classic.

NH=3D> Thanks John for the kind words....its good to know you've had at
least something to smile about ;-)

Seriously though, see my updated response to Adrian.  But if you are
still struggling to grasp what I mean by the above (out of context
quote) try this:

A single cl-ps IP network carrying traffic and everything else (eg
public Internet) is very different animal to a co-cs network system
where the traffic data-plane network and control/management data-planes
network are logically disjoint, ie the role of IP in the latter is
importantly different to the role of IP in the former...and let's hope
never the 2 shall meet.

regards, neil
=20

Delivery-date: Sat, 23 Jul 2005 10:34:23 +0000
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Sat, 23 Jul 2005 12:32:19 +0200

Delivery-date: Sat, 23 Jul 2005 04:37:47 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Bcc: 
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Sat, 23 Jul 2005 13:38:50 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message

Richard, 
 
IEEE recommends to use Ethernet Length/Type code for distinguishing control frames.
All GARP, GVRP, GMPR and other proposed OAM frame follow this rule.
IEEE particulary discourages using some number in data forwarding address 
being used for exchange of control data. An example is using some multicast address 
for exchange of hello frames. This rule is also applied to the case of VLAN forwarding.
I think this policy is to prevent control chaos with other L2 protocols.
We need to be careful in taking approach to use some L2-LSP exclusively 
for control plane because it may result in unwanted conflict with both people and machine.
 
Regards,
 
Jaihyung

-----?? ???----- 
?? ??: "[email-masked]" <[email-masked]> 
?? ??: 2005-07-22 ?? 8:44:08 
?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: "[email-masked]" <[email-masked]> 
??: RE: Frameformat in a l2cs gmpls rnvironment. 

Regardless of whether or not a switch is directly connected to hosts, it must be able to forward packets using the connectionless Ethernet data plane. This is due to the fundamental requirement that for GMPLS switches to be able to exchange control information with each other, a data plane for control traffic must be present. This is akin to using the IP data plane for MPLS signalling in an IP/MPLS network. An alternative would be to use a static reserved L2-LSP for control traffic in the same way that reserved VPI/VCIs are used for PNNI signalling in ATM. 

Regarding connecting hosts to GMPLS switches, I personally don't think extending L2-LSPs into the enterprise/home network is commercially viable. However, if you do want to use GMPLS switches in the home/enterprise network and for some reason don't want to extend L2-LSPs down to the host then you will not be performing normal Ethernet Mac address switching anyway. Instead you will need some kind of policy on the switch that maps connectionless Ethernet packets (e.g. based on MAC src/dest, 802.1p, VLAN) to a L2-LSP. This is because multiple L2-LSPs to the same destination (e.g. a gateway router) may exist for different services/flows (e.g. video download, VoIP call, etc.). 

Regards, 
Richard 

> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Par Mattsson 
> Sent: 22 July 2005 11:42 
> To: Loa Andersson 
> Cc: [email-masked] 
> Subject: Re: Frameformat in a l2cs gmpls rnvironment. 
> 
> 
> > Per and Dimitri, 
> > 
> > I would like to come down stronger than that, for me it is 
> > a very strong requirement that the same switch can handle 
> > both VLANs and GMPLs trafic correctly. I can't dsee how that 
> > could be done if using the VLAN tpid to indicate GMPLS 
> > traffic. 
> 
> If you ever want that same switch to handle traffic for a directly 
> connected  host (not to uncommen) you would want that to use normal 
> ethernet macaddress switching. So of course you do not want to have to 
> choose between vlan and gmpls, you would want both at the same time. 
> 
> /per 
> 
> 
> > 
> > /Loa 
> > 
> > Par Mattsson wrote: 
> >>>hi par, one of the possibilities that has been considered 
> to cope with 
> >>>this requirement is to use a dedicated TPID for the 
> Ethernet labeled 
> >>>frames; this would allow differentiated processing with non-labeled 
> >>>framesthanks. 
> >> 
> >> 
> >> That seems to make more sence. If that frame is to be sized like a 
> >> 802.1q 
> >> frame. There is not that much space left to a label. Or is 
> the demand to 
> >> use jumboframes ? 
> >> Has there been any discussion on labelstacking, and mainly where to 
> >> place 
> >> the information? 
> >> 
> >> Regards. 
> >> Per 
> >> 
> >> 
> >> 
> > 
> > 
> > -- 
> > Loa Andersson 
> > 
> > Principal Networking Architect 
> > Acreo AB                           phone:  +46 8 632 77 14 
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64 
> > Kista, Sweden                      email:  [email-masked] 
> >                                             [email-masked] 
> > 
> 
> 
> 

Delivery-date: Sat, 23 Jul 2005 04:20:01 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: "Heiles Juergen" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Bcc: 
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Sat, 23 Jul 2005 13:19:24 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message

Dear Juergen, Par and all,

The proposed framework of L2SC was not intended to suggest 
any specific solution. It is still an open question. 
As Adrian noted, it only aims to present requirements 
as in scenarios that may drive people toward next step in many 
viable solutions.

In fact, there are other options we may also consider for L2 label encoding. 
IEEE 802.1 Ethernet bridges forward frames based on 48bits of MAC address, 
and additionally using VLAN tag. 

When the purpose of GMPLS control over Ethernet is not to create new dataplane 
but to utilize IEEE 802.1 bridge architecture, we may consider using 
one of the two forwarding methods, MAC forwarding or VLAN forwarding. 
(and perhaps any other combination of fields in MAC, but I'll not discuss it)
 
Use of VLAN ID for label encoding may automate VLAN configuration 
using IP protocols. However, GMPLS protocol cannot use the field exclusively 
because public/private operators already use VLAN for various purpose. 
There is a potential conflict with existing use of VLAN and GMPLS use of VLAN label.  
Furthermore, scalability of VLAN ID has been frequently noted as weakness 
because the size of VLAN ID is at most 4096 (12bit). 

The scalability may be improved if the scope of VLAN label is confined to 
link-local, and some additional swapping function of VLAN ID is introduced in 
Internal Sublayer [802.1D] of GMPLS implemented switch. 
However, this will only be effective when the configuration of network 
is mesh structure that multiple LSP paths exist. If the configuration of network 
is star or tree shape, as normal configuration of access network, 
LSPs concentrate in root node and total number of 
LSPs that the network can hold still be limited by available label space 
at a few root links. 

For these reasons, I do not think any form of VLAN ID label is 
an appropriate choice for layer-2 label encoding.
 
There are some other proposals assuming new assignment of Ethernet 
Length/Type value (e.g. new TPID in VLAN tag) and re-definition of 
information fields placed between 802.3 MAC header and IP packet. 
In this case, only the format of VLAN tag or extended VLAN tag 
is borrowed, however, inside the switching hardware, the filter and relay, 
etc. are totally different new dataplane switch.

I do not see such approach is a GMPLS implementation for Ethernet 
because the core switching technique is not 802.1 Ethernet bridge at all.
 
The other option we may consider is using MAC address filed as below.

+-------+-------+-------+-------+-------+-------+ 
| 1byte | 2byte | 3byte | 4byte | 5byte | 6byte | 
+-------+-------+-------+-------+-------+-------+
+-----------------------+-----------------------+ 
|  OUI Prefix (=GMPLS)  |   DA-label (24bit)    | 
+-----------------------+-----------------------+ 
|  OUI Prefix (=GMPLS)  |   SA-label (24bit)    | 
+---------------+-------+-----------------------+ 
| Length/Type   | 
+---------------+

IEEE is designated by the ISO Council to act as the registration authority 
for the higher three-octet of OUI number in the MAC address 
to be used by manufacturer. Ethernet manufacturer may generate 
global unique MAC address using the OUI prefix and address block of 
lower three-octet (24bit). Taking advantage of the addressing scheme, 
GMPLS may use the lower three-octet exclusively if a unique OUI number 
is reserved for the protocol. With this labeling scheme, GMPLS will 
control MAC forwarding entry, not VLAN table.
 
All Ethernet frames controlled by GMPLS will have identical OUI number 
that they can easily be distinguished from other Ethernet frames. 
In principle, the label lookup hardware is identical to MAC lookup 
hardware in this labeling scheme. Therefore GMPLS implemented 
switch may still function as normal Ethernet bridge to the frames 
that OUI number is not GMPLS. This also facilitates GMPLS implemented 
switches being deployed in operating Ethernet with minimum service disruption.
 
Note also that above proposed label encoding method is transparent 
to the use of Ethernet Length/Type field. End-user device may use 
the Length/Type field as defined in IEEE 802.3 protocol. 
It also allows network operators configure VLAN for their own purpose. 
When IEEE 802.1p is used in conjunction with L2-LSP, the priority 
field of VLAN tag can also be used for imposing consistent TE policy in 
legacy switches and GMPLS switches.
 
Any way, my conclusion is, there are other options we may consider, 
and this issue is still open to discuss.
 
Thanks,
 
Sincerely,
 
Jaihyung

-----?? ???----- 
?? ??: "Heiles Juergen" <[email-masked]> 
?? ??: 2005-07-22 ?? 10:23:43 
?? ??: "Loa Andersson" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: RE: Frameformat in a l2cs gmpls rnvironment. 

Loa, 

I interpret the ID as a proposal to use GMPLS for VLAN setup. So GMPLS and VLAN to not compete. The VLAN is at the data plane and GMPLS at the control plane. The question is how and should different control plane techniques like GMPLS and (GVRP and STB) work together? 

Regards 

Juergen 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Loa Andersson 
> Sent: Friday, July 22, 2005 2:53 PM 
> To: [email-masked] 
> Cc: [email-masked]; [email-masked] 
> Subject: Re: Frameformat in a l2cs gmpls rnvironment. 
> 
> Richard, 
> 
> I agree to most of this. Since we have doubts about the viability 
> of taking GMPLS all the way to end-user or enterprise I think it 
> would be good, from a wg perspective, if we agreed to solve the 
> core network problems first. 
> 
> Do you have any comment on the requirement to run both VLANs and 
> GMPLS on the same switch? 
> 
> /Loa 
> 
> [email-masked] wrote: 
> > Regardless of whether or not a switch is directly connected 
>  > to hosts, it must be able to forward packets using the 
> connectionless 
>  > Ethernet data plane. This is due to the fundamental 
> requirement that 
>  > for GMPLS switches to be able to exchange control information with 
>  > each other, a data plane for control traffic must be present. 
>  > This is akin to using the IP data plane for MPLS signalling in an 
>  > IP/MPLS network. An alternative would be to use a static reserved 
>  > L2-LSP for control traffic in the same way that reserved VPI/VCIs 
>  > are used for PNNI signalling in ATM. 
> > 
> > Regarding connecting hosts to GMPLS switches, I personally don't 
>  > think extending L2-LSPs into the enterprise/home network is 
>  > commercially viable. However, if you do want to use GMPLS switches 
>  > in the home/enterprise network and for some reason don't want to 
>  > extend L2-LSPs down to the host then you will not be performing 
>  > normal Ethernet Mac address switching anyway. Instead you will 
>  > need some kind of policy on the switch that maps connectionless 
>  > Ethernet packets (e.g. based on MAC src/dest, 802.1p, VLAN) to a 
>  > L2-LSP. This is because multiple L2-LSPs to the same destination 
>  > (e.g. a gateway router) may exist for different services/flows 
>  > (e.g. video download, VoIP call, etc.). 
> > 
> > Regards, 
> > Richard 
> > 
> > 
> >>From: [email-masked] [mailto:[email-masked]]On 
> >>Behalf Of Par Mattsson 
> >>Sent: 22 July 2005 11:42 
> >>To: Loa Andersson 
> >>Cc: [email-masked] 
> >>Subject: Re: Frameformat in a l2cs gmpls rnvironment. 
> >> 
> >> 
> >> 
> >>>Per and Dimitri, 
> >>> 
> >>>I would like to come down stronger than that, for me it is 
> >>>a very strong requirement that the same switch can handle 
> >>>both VLANs and GMPLs trafic correctly. I can't dsee how that 
> >>>could be done if using the VLAN tpid to indicate GMPLS 
> >>>traffic. 
> >> 
> >>If you ever want that same switch to handle traffic for a directly 
> >>connected  host (not to uncommen) you would want that to use normal 
> >>ethernet macaddress switching. So of course you do not want 
> to have to 
> >>choose between vlan and gmpls, you would want both at the same time. 
> >> 
> >>/per 
> >> 
> >> 
> >> 
> >>>/Loa 
> >>> 
> >>>Par Mattsson wrote: 
> >>> 
> >>>>>hi par, one of the possibilities that has been considered 
> >> 
> >>to cope with 
> >> 
> >>>>>this requirement is to use a dedicated TPID for the 
> >> 
> >>Ethernet labeled 
> >> 
> >>>>>frames; this would allow differentiated processing with 
> non-labeled 
> >>>>>framesthanks. 
> >>>> 
> >>>> 
> >>>>That seems to make more sence. If that frame is to be sized like a 
> >>>>802.1q 
> >>>>frame. There is not that much space left to a label. Or is 
> >> 
> >>the demand to 
> >> 
> >>>>use jumboframes ? 
> >>>>Has there been any discussion on labelstacking, and 
> mainly where to 
> >>>>place 
> >>>>the information? 
> >>>> 
> >>>>Regards. 
> >>>>Per 
> >>>> 
> >>>> 
> >>>> 
> >>> 
> >>> 
> >>>-- 
> >>>Loa Andersson 
> >>> 
> >>>Principal Networking Architect 
> >>>Acreo AB                           phone:  +46 8 632 77 14 
> >>>Isafjordsgatan 22                  mobile: +46 739 81 21 64 
> >>>Kista, Sweden                      email:  [email-masked] 
> >>>                                            [email-masked] 
> >>> 
> >> 
> >> 
> >> 
> > 
> 
> 
> -- 
> Loa Andersson 
> 
> Principal Networking Architect 
> Acreo AB                           phone:  +46 8 632 77 14 
> Isafjordsgatan 22                  mobile: +46 739 81 21 64 
> Kista, Sweden                      email:  [email-masked] 
>                                             [email-masked] 
> 

Delivery-date: Sat, 23 Jul 2005 01:58:17 +0000
Content-class: urn:content-classes:message
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Fri, 22 Jul 2005 18:55:51 -0700
From: "Drake, John E" <[email-masked]>
To: "Drake, John E" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Snipped ...

> > IP is cl-ps networking techology period....and its
> > jolly important, but PLEASE don't try and feed me any of this 'IP
> > control plane' nonsense.

JD:  Over the years I have enjoyed Neil's rants immensely, but I have to
say that this one is a classic.

Delivery-date: Sat, 23 Jul 2005 00:35:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Fri, 22 Jul 2005 20:32:18 -0400
From: "Don Fedyk" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Neil

I concur with Adrian's definition of "IP Control Plane" or "IP-based
Control Plane". 

I think your point is more to the question of where the intelligence to
select the network paths lives. I believe that 
in GMPLS, Path selection and path control is not solely the
responsibility  of "IP-based control plane"  but is enabled by IP
mechanisms to be where it makes sense.   

Regards,
Don 

>-----Original Message----- From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Adrian Farrel
>Sent: Friday, July 22, 2005 7:08 PM
>
>
>Hi Neil,
>
>I think John beat me off the blocks here, but...
>
>
>> > GMPLS assumes an IP control plane.
>>
>> An IP control-plane?  There is actually no such animal.
>> Just what the heck does that REALLY mean in GMPLS say?
>
>Let me explain.  Perhaps I should have said "IP-based
>control plane".  I mean a control plane which:
>- uses IP as its network protocol
>- uses IP addresses to identify control plane resources
>- uses IP addresses to identify data plane resources within
>  the control plane
>- uses protocols developed for use in the Internet.
>
>> I am not questioning IP as a cl-ps networking protocol
>> *carrying* a signalling protocol (RSVP-TE, or dare I
>> mention PNNI, or any signalling protocol yet to be
>> invented) or a routing protocol (OSPF or ISO or whatever)
>
>I am glad to hear it.
>
<snip>

Delivery-date: Sat, 23 Jul 2005 00:03:56 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Sat, 23 Jul 2005 01:04:18 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_01F1_01C58F22.73B35600
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Richard,

I see you're in the same timezone as me :-)

> I don't understand why you have renamed the thread "Ethernet Control =
Plane"
> in response to my email. I haven't even mentioned an Ethernet Control =
Plane.

Hmmm. I seem to be having some problems with adjectival constructs =
today.

How about "Control Plane for Ethernet"?

I must say, what you wrote sounded like a discussion of establishing a =
mechanism to carry control plane traffic over Ethernet for the purpose =
of controlling Ethernet. I don't think "Ethernet Control Plane" is such =
a bad term for this.

But there is a lesson here. If the subject line needs changing (to help =
separate the several threads that are running with the same subject =
line) and if you don't change it yourself, someone else will. If you =
don't like that subject line, change it to something better.

Cheers,
Adrian

> I'm quite aware that GMPLS uses IP labelled control protocol packets =
and
> I haven't suggested removing IP and just using Ethernet. In fact, I =
would
> have thought my analogy with how a management VLAN is used today (e.g. =

> for ICMP ping and telnet) would have demonstrated that.
>
> I am simply saying that for two GMPLS peers to send (IP labelled) =
control
> protocol packets to each other, they must agree to encapsulate the =
packets
> using either untagged Ethernet frames or using tagged Ethernet frames =
with
> a common VLAN ID. Again, I'm not saying this is an issue, just =
something=20
> that needs to be considered. Switches are not routers and normally =
only=20
> send/receive locally addressed IP packets via the management VLAN, =
e.g.=20
> to ping between two directly connected switches the interfaces they =
are=20
> connected via must both be configured to be in the same management =
VLAN.

Regards,
Richard

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 22 July 2005 19:13
> To: Spencer,R,Richard,XDE73 R; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls
> rnvironment.]
>=20
>=20
> Whoa there!
>=20
> GMPLS assumes an IP control plane.
> I am aware that there is work afoot in other SDOs to assign a=20
> dedicated
> VLAN tag to specify the control plane traffic. This is not what we are
> doing.
>=20
> As far as I am aware, everyone in the IETF is comfortable=20
> with the idea of
> using IP packets to carry control plane data through an=20
> IP-enabled DCN. In
> Ethernet the issue will be whether the control plane is in=20
> band (use IP
> address and MAC address) or out of band (use distinct DCN).
>=20
> The use of a separate VLAN ID to signify the control plane is=20
> out of scope
> for CCAMP.
>=20
> Thanks,
> Adrian
>=20
> ----- Original Message -----=20
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, July 22, 2005 4:33 PM
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
>=20
>=20
> Juergen,
>=20
> Before you can use GMPLS to set up VLANs a data plane must=20
> first exist to
> carry the GMPLS control plane traffic. Yes you can use the standard
> Ethernet data plane for this purpose (and in fact must do so for the
> solution to be viable), but its not as simple as that. You=20
> cannot assume
> that just because two GMPLS peers are directly connected that they can
> communicate with each other.
>=20
> To exchange GMPLS control plane packets between a pair of=20
> GMPLS peers, the
> peers will need to agree to use either untagged control=20
> packets or to tag
> them with a common VLAN ID. The use of a separate VLAN for=20
> GMPLS control
> traffic is analogous to using a separate VLAN for management traffic
> today. If two switches belong to the same management VLAN=20
> then you can use
> ICMP ping to verify connectivity between them. However, if=20
> one switch has
> been put into the wrong management VLAN then the ping will=20
> obviously fail.
>=20
> If you want to use a separate VLAN for GMPLS control plane=20
> traffic, then
> you either need to (i) define a reserved GMPLS signalling=20
> VLAN ID, or (ii)
> leave it up to the operator to choose a VLAN ID. If you leave=20
> it up to the
> operator to decide what VLAN ID to use, then you need to=20
> consider what the
> implications in the inter-operator case will be, i.e. what=20
> VLAN ID range
> should be used for control plane traffic and what VLAN ID=20
> range should be
> used for user plane traffic.
>=20
> I'm not saying that defining how GMPLS control plane packets=20
> are forwarded
> in the Ethernet data plane will be an issue, simply that this=20
> is something
> that must be addressed to develop interoperable solutions.
>=20
> Regards,
> Richard
>=20
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Heiles Juergen
> > Sent: 22 July 2005 14:17
> > To: Loa Andersson; P=E4r Mattsson
> > Cc: [email-masked]
> > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> >
> >
> > GMPLS for SONET/SDH has no impact on the SONET/SDH data
> > plane. It introduces a control plane for connection setup
> > instead of a network management based connection setup. GMPLS
> > for Ethernet can work in the same way. Ethernet as such is
> > cl, but VLANs are setup and GMPLS can provide a control plane
> > for VLAN setup. The Ethernet data plane is not changed and
> > MAC address learning and forwarding is still be done within a
> > VLAN. So no change to the Ethernet data plane. No GMPLS
> > traffic is introduced, it is still VLAN traffic.
> > Introducing a dedicated GMPLS label for Ethernet (GMPLS
> > traffic) goes beyond GMPLS as a control plane technique.
> >
> > Regards
> >
> > Juergen
> >
> >
> >
> >
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Loa Andersson
> > > Sent: Friday, July 22, 2005 12:05 PM
> > > To: P=E4r Mattsson
> > > Cc: [email-masked]
> > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> > >
> > > Per and Dimitri,
> > >
> > > I would like to come down stronger than that, for me it is
> > > a very strong requirement that the same switch can handle
> > > both VLANs and GMPLs trafic correctly. I can't dsee how that
> > > could be done if using the VLAN tpid to indicate GMPLS
> > > traffic.
> > >
> > > /Loa
> > >
> > > P=E4r Mattsson wrote:
> > > >>hi par, one of the possibilities that has been considered
> > > to cope with
> > > >>this requirement is to use a dedicated TPID for the
> > Ethernet labeled
> > > >>frames; this would allow differentiated processing with
> > non-labeled
> > > >>framesthanks.
> > > >
> > > >
> > > > That seems to make more sence. If that frame is to be sized
> > > like a 802.1q
> > > > frame. There is not that much space left to a label. Or is
> > > the demand to
> > > > use jumboframes ?
> > > > Has there been any discussion on labelstacking, and mainly
> > > where to place
> > > > the information?
> > > >
> > > > Regards.
> > > > Per
> > > >
> > > >
> > > >
> > >
> > >
> > > --=20
> > > Loa Andersson
> > >
> > > Principal Networking Architect
> > > Acreo AB                           phone:  +46 8 632 77 14
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > Kista, Sweden                      email:  [email-masked]
> > >                                             [email-masked]
> > >
> >
> >
>=20
>=20
>=20
>=20

------=_NextPart_000_01F1_01C58F22.73B35600
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Hi Richard,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I see you're in the same timezone as =
me=20
:-)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; I don't understand why you have =
renamed the=20
thread "Ethernet Control Plane"</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;in response to my email. I =
haven't even=20
mentioned an Ethernet Control Plane.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Hmmm. I seem to be having some =
problems with=20
adjectival constructs today.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>How about "Control Plane for=20
Ethernet"?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I must say, what you wrote sounded =
like a=20
discussion of establishing a mechanism to carry control plane traffic =
over=20
Ethernet for the purpose of controlling Ethernet. I don't think =
"Ethernet=20
Control Plane" is such a bad term for this.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>But there is a lesson here. If the =
subject line=20
needs changing (to help separate the several threads that are running =
with the=20
same subject line) and if you don't change it yourself, someone else =
will. If=20
you don't like that subject line, change it to something =
better.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Cheers,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; I'm quite aware that GMPLS uses =
IP labelled=20
control protocol packets and</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;I haven't suggested =
removing IP and=20
just using Ethernet. In fact, I would</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;have thought my analogy =
with how a=20
management VLAN is used today (e.g. </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; for ICMP ping and telnet) would =
have=20
demonstrated that.<BR>&gt;<BR>&gt; I am simply saying that for two GMPLS =
peers=20
to send (IP labelled) control</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;protocol packets to each =
other, they=20
must agree to encapsulate the packets</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;using either untagged =
Ethernet frames=20
or using tagged Ethernet frames with</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;a common VLAN ID. Again, =
I'm not saying=20
this is an issue, just something </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; that needs to be considered. =
Switches are=20
not routers and normally only </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; send/receive locally addressed =
IP packets=20
via the management VLAN, e.g. </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; to ping between two directly =
connected=20
switches the interfaces they are </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; connected via must both be =
configured to be=20
in the same management VLAN.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV>
<DIV><BR><BR>Regards,<BR>Richard<BR><BR>&gt; -----Original =
Message-----<BR>&gt;=20
From: Adrian Farrel [mailto:[email-masked]]<BR>&gt; Sent: 22 July =
2005=20
19:13<BR>&gt; To: Spencer,R,Richard,XDE73 R; </FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>;=20
</FONT><A href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier size=3D2>;<BR>&gt; =
</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier size=3D2>&gt; =
Cc: </FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt; Subject:=20
Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls<BR>&gt;=20
rnvironment.]<BR>&gt; <BR>&gt; <BR>&gt; Whoa there!<BR>&gt; <BR>&gt; =
GMPLS=20
assumes an IP control plane.<BR>&gt; I am aware that there is work afoot =
in=20
other SDOs to assign a <BR>&gt; dedicated<BR>&gt; VLAN tag to specify =
the=20
control plane traffic. This is not what we are<BR>&gt; doing.<BR>&gt; =
<BR>&gt;=20
As far as I am aware, everyone in the IETF is comfortable <BR>&gt; with =
the idea=20
of<BR>&gt; using IP packets to carry control plane data through an =
<BR>&gt;=20
IP-enabled DCN. In<BR>&gt; Ethernet the issue will be whether the =
control plane=20
is in <BR>&gt; band (use IP<BR>&gt; address and MAC address) or out of =
band (use=20
distinct DCN).<BR>&gt; <BR>&gt; The use of a separate VLAN ID to signify =
the=20
control plane is <BR>&gt; out of scope<BR>&gt; for CCAMP.<BR>&gt; =
<BR>&gt;=20
Thanks,<BR>&gt; Adrian<BR>&gt; <BR>&gt; ----- Original Message ----- =
<BR>&gt;=20
From: &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT =
face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;<BR>&gt;=20
To: &lt;</FONT><A href=3D"mailto:[email-masked]"><FONT =
face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;;=20
&lt;</FONT><A href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;<BR>&gt; Cc:=20
&lt;</FONT><A href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;<BR>&gt; Sent:=20
Friday, July 22, 2005 4:33 PM<BR>&gt; Subject: RE: Frameformat in a l2cs =
gmpls=20
rnvironment.<BR>&gt; <BR>&gt; <BR>&gt; Juergen,<BR>&gt; <BR>&gt; Before =
you can=20
use GMPLS to set up VLANs a data plane must <BR>&gt; first exist =
to<BR>&gt;=20
carry the GMPLS control plane traffic. Yes you can use the =
standard<BR>&gt;=20
Ethernet data plane for this purpose (and in fact must do so for =
the<BR>&gt;=20
solution to be viable), but its not as simple as that. You <BR>&gt; =
cannot=20
assume<BR>&gt; that just because two GMPLS peers are directly connected =
that=20
they can<BR>&gt; communicate with each other.<BR>&gt; <BR>&gt; To =
exchange GMPLS=20
control plane packets between a pair of <BR>&gt; GMPLS peers, =
the<BR>&gt; peers=20
will need to agree to use either untagged control <BR>&gt; packets or to =

tag<BR>&gt; them with a common VLAN ID. The use of a separate VLAN for =
<BR>&gt;=20
GMPLS control<BR>&gt; traffic is analogous to using a separate VLAN for=20
management traffic<BR>&gt; today. If two switches belong to the same =
management=20
VLAN <BR>&gt; then you can use<BR>&gt; ICMP ping to verify connectivity =
between=20
them. However, if <BR>&gt; one switch has<BR>&gt; been put into the =
wrong=20
management VLAN then the ping will <BR>&gt; obviously fail.<BR>&gt; =
<BR>&gt; If=20
you want to use a separate VLAN for GMPLS control plane <BR>&gt; =
traffic,=20
then<BR>&gt; you either need to (i) define a reserved GMPLS signalling =
<BR>&gt;=20
VLAN ID, or (ii)<BR>&gt; leave it up to the operator to choose a VLAN =
ID. If you=20
leave <BR>&gt; it up to the<BR>&gt; operator to decide what VLAN ID to =
use, then=20
you need to <BR>&gt; consider what the<BR>&gt; implications in the=20
inter-operator case will be, i.e. what <BR>&gt; VLAN ID range<BR>&gt; =
should be=20
used for control plane traffic and what VLAN ID <BR>&gt; range should =
be<BR>&gt;=20
used for user plane traffic.<BR>&gt; <BR>&gt; I'm not saying that =
defining how=20
GMPLS control plane packets <BR>&gt; are forwarded<BR>&gt; in the =
Ethernet data=20
plane will be an issue, simply that this <BR>&gt; is something<BR>&gt; =
that must=20
be addressed to develop interoperable solutions.<BR>&gt; <BR>&gt;=20
Regards,<BR>&gt; Richard<BR>&gt; <BR>&gt; &gt; -----Original=20
Message-----<BR>&gt; &gt; From: </FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>=20
[mailto:[email-masked]]On<BR>&gt; &gt; Behalf Of Heiles=20
Juergen<BR>&gt; &gt; Sent: 22 July 2005 14:17<BR>&gt; &gt; To: Loa =
Andersson;=20
P=E4r Mattsson<BR>&gt; &gt; Cc: </FONT><A =
href=3D"mailto:[email-masked]"><FONT=20
face=3DCourier size=3D2>[email-masked]</FONT></A><BR><FONT =
face=3DCourier=20
size=3D2>&gt; &gt; Subject: RE: Frameformat in a l2cs gmpls =
rnvironment.<BR>&gt;=20
&gt;<BR>&gt; &gt;<BR>&gt; &gt; GMPLS for SONET/SDH has no impact on the=20
SONET/SDH data<BR>&gt; &gt; plane. It introduces a control plane for =
connection=20
setup<BR>&gt; &gt; instead of a network management based connection =
setup.=20
GMPLS<BR>&gt; &gt; for Ethernet can work in the same way. Ethernet as =
such=20
is<BR>&gt; &gt; cl, but VLANs are setup and GMPLS can provide a control=20
plane<BR>&gt; &gt; for VLAN setup. The Ethernet data plane is not =
changed=20
and<BR>&gt; &gt; MAC address learning and forwarding is still be done =
within=20
a<BR>&gt; &gt; VLAN. So no change to the Ethernet data plane. No =
GMPLS<BR>&gt;=20
&gt; traffic is introduced, it is still VLAN traffic.<BR>&gt; &gt; =
Introducing a=20
dedicated GMPLS label for Ethernet (GMPLS<BR>&gt; &gt; traffic) goes =
beyond=20
GMPLS as a control plane technique.<BR>&gt; &gt;<BR>&gt; &gt; =
Regards<BR>&gt;=20
&gt;<BR>&gt; &gt; Juergen<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; =

&gt;<BR>&gt; &gt; &gt; -----Original Message-----<BR>&gt; &gt; &gt; =
From:=20
</FONT><A href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt;=20
&gt; &gt; [mailto:[email-masked]] On Behalf Of Loa =
Andersson<BR>&gt;=20
&gt; &gt; Sent: Friday, July 22, 2005 12:05 PM<BR>&gt; &gt; &gt; To: =
P=E4r=20
Mattsson<BR>&gt; &gt; &gt; Cc: </FONT><A =
href=3D"mailto:[email-masked]"><FONT=20
face=3DCourier size=3D2>[email-masked]</FONT></A><BR><FONT =
face=3DCourier=20
size=3D2>&gt; &gt; &gt; Subject: Re: Frameformat in a l2cs gmpls=20
rnvironment.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Per and =
Dimitri,<BR>&gt; &gt;=20
&gt;<BR>&gt; &gt; &gt; I would like to come down stronger than that, for =
me it=20
is<BR>&gt; &gt; &gt; a very strong requirement that the same switch can=20
handle<BR>&gt; &gt; &gt; both VLANs and GMPLs trafic correctly. I can't =
dsee how=20
that<BR>&gt; &gt; &gt; could be done if using the VLAN tpid to indicate=20
GMPLS<BR>&gt; &gt; &gt; traffic.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;=20
/Loa<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; P=E4r Mattsson wrote:<BR>&gt; =
&gt; &gt;=20
&gt;&gt;hi par, one of the possibilities that has been =
considered<BR>&gt; &gt;=20
&gt; to cope with<BR>&gt; &gt; &gt; &gt;&gt;this requirement is to use a =

dedicated TPID for the<BR>&gt; &gt; Ethernet labeled<BR>&gt; &gt; &gt;=20
&gt;&gt;frames; this would allow differentiated processing with<BR>&gt; =
&gt;=20
non-labeled<BR>&gt; &gt; &gt; &gt;&gt;framesthanks.<BR>&gt; &gt; &gt;=20
&gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; That seems to make =
more=20
sence. If that frame is to be sized<BR>&gt; &gt; &gt; like a =
802.1q<BR>&gt; &gt;=20
&gt; &gt; frame. There is not that much space left to a label. Or =
is<BR>&gt;=20
&gt; &gt; the demand to<BR>&gt; &gt; &gt; &gt; use jumboframes ?<BR>&gt; =
&gt;=20
&gt; &gt; Has there been any discussion on labelstacking, and =
mainly<BR>&gt;=20
&gt; &gt; where to place<BR>&gt; &gt; &gt; &gt; the information?<BR>&gt; =
&gt;=20
&gt; &gt;<BR>&gt; &gt; &gt; &gt; Regards.<BR>&gt; &gt; &gt; &gt; =
Per<BR>&gt;=20
&gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; =
&gt;=20
&gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; -- <BR>&gt; &gt; &gt; Loa=20
Andersson<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Principal Networking=20
Architect<BR>&gt; &gt; &gt; Acreo=20
AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
phone:&nbsp; +46 8 632 77 14<BR>&gt; &gt; &gt; Isafjordsgatan=20
22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
mobile: +46 739 81 21 64<BR>&gt; &gt; &gt; Kista,=20
Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
email:&nbsp; </FONT><A href=3D"mailto:[email-masked]"><FONT =
face=3DCourier=20
size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt; &gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</FONT><A href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier size=3D2>&gt; &gt; =
&gt;<BR>&gt;=20
&gt;<BR>&gt; &gt;<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt;=20
<BR><BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_01F1_01C58F22.73B35600--

Delivery-date: Fri, 22 Jul 2005 23:43:46 +0000
Content-Class: urn:content-classes:message
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Sat, 23 Jul 2005 00:42:33 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Adrian,

I don't understand why you have renamed the thread "Ethernet Control =
Plane" in response to my email. I haven't even mentioned an Ethernet =
Control Plane.

I'm quite aware that GMPLS uses IP labelled control protocol packets and =
I haven't suggested removing IP and just using Ethernet. In fact, I =
would have thought my analogy with how a management VLAN is used today =
(e.g. for ICMP ping and telnet) would have demonstrated that.

I am simply saying that for two GMPLS peers to send (IP labelled) =
control protocol packets to each other, they must agree to encapsulate =
the packets using either untagged Ethernet frames or using tagged =
Ethernet frames with a common VLAN ID. Again, I'm not saying this is an =
issue, just something that needs to be considered. Switches are not =
routers and normally only send/receive locally addressed IP packets via =
the management VLAN, e.g. to ping between two directly connected =
switches the interfaces they are connected via must both be configured =
to be in the same management VLAN.

Regards,
Richard

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 22 July 2005 19:13
> To: Spencer,R,Richard,XDE73 R; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls
> rnvironment.]
>=20
>=20
> Whoa there!
>=20
> GMPLS assumes an IP control plane.
> I am aware that there is work afoot in other SDOs to assign a=20
> dedicated
> VLAN tag to specify the control plane traffic. This is not what we are
> doing.
>=20
> As far as I am aware, everyone in the IETF is comfortable=20
> with the idea of
> using IP packets to carry control plane data through an=20
> IP-enabled DCN. In
> Ethernet the issue will be whether the control plane is in=20
> band (use IP
> address and MAC address) or out of band (use distinct DCN).
>=20
> The use of a separate VLAN ID to signify the control plane is=20
> out of scope
> for CCAMP.
>=20
> Thanks,
> Adrian
>=20
> ----- Original Message -----=20
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, July 22, 2005 4:33 PM
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
>=20
>=20
> Juergen,
>=20
> Before you can use GMPLS to set up VLANs a data plane must=20
> first exist to
> carry the GMPLS control plane traffic. Yes you can use the standard
> Ethernet data plane for this purpose (and in fact must do so for the
> solution to be viable), but its not as simple as that. You=20
> cannot assume
> that just because two GMPLS peers are directly connected that they can
> communicate with each other.
>=20
> To exchange GMPLS control plane packets between a pair of=20
> GMPLS peers, the
> peers will need to agree to use either untagged control=20
> packets or to tag
> them with a common VLAN ID. The use of a separate VLAN for=20
> GMPLS control
> traffic is analogous to using a separate VLAN for management traffic
> today. If two switches belong to the same management VLAN=20
> then you can use
> ICMP ping to verify connectivity between them. However, if=20
> one switch has
> been put into the wrong management VLAN then the ping will=20
> obviously fail.
>=20
> If you want to use a separate VLAN for GMPLS control plane=20
> traffic, then
> you either need to (i) define a reserved GMPLS signalling=20
> VLAN ID, or (ii)
> leave it up to the operator to choose a VLAN ID. If you leave=20
> it up to the
> operator to decide what VLAN ID to use, then you need to=20
> consider what the
> implications in the inter-operator case will be, i.e. what=20
> VLAN ID range
> should be used for control plane traffic and what VLAN ID=20
> range should be
> used for user plane traffic.
>=20
> I'm not saying that defining how GMPLS control plane packets=20
> are forwarded
> in the Ethernet data plane will be an issue, simply that this=20
> is something
> that must be addressed to develop interoperable solutions.
>=20
> Regards,
> Richard
>=20
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Heiles Juergen
> > Sent: 22 July 2005 14:17
> > To: Loa Andersson; P=E4r Mattsson
> > Cc: [email-masked]
> > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> >
> >
> > GMPLS for SONET/SDH has no impact on the SONET/SDH data
> > plane. It introduces a control plane for connection setup
> > instead of a network management based connection setup. GMPLS
> > for Ethernet can work in the same way. Ethernet as such is
> > cl, but VLANs are setup and GMPLS can provide a control plane
> > for VLAN setup. The Ethernet data plane is not changed and
> > MAC address learning and forwarding is still be done within a
> > VLAN. So no change to the Ethernet data plane. No GMPLS
> > traffic is introduced, it is still VLAN traffic.
> > Introducing a dedicated GMPLS label for Ethernet (GMPLS
> > traffic) goes beyond GMPLS as a control plane technique.
> >
> > Regards
> >
> > Juergen
> >
> >
> >
> >
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Loa Andersson
> > > Sent: Friday, July 22, 2005 12:05 PM
> > > To: P=E4r Mattsson
> > > Cc: [email-masked]
> > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> > >
> > > Per and Dimitri,
> > >
> > > I would like to come down stronger than that, for me it is
> > > a very strong requirement that the same switch can handle
> > > both VLANs and GMPLs trafic correctly. I can't dsee how that
> > > could be done if using the VLAN tpid to indicate GMPLS
> > > traffic.
> > >
> > > /Loa
> > >
> > > P=E4r Mattsson wrote:
> > > >>hi par, one of the possibilities that has been considered
> > > to cope with
> > > >>this requirement is to use a dedicated TPID for the
> > Ethernet labeled
> > > >>frames; this would allow differentiated processing with
> > non-labeled
> > > >>framesthanks.
> > > >
> > > >
> > > > That seems to make more sence. If that frame is to be sized
> > > like a 802.1q
> > > > frame. There is not that much space left to a label. Or is
> > > the demand to
> > > > use jumboframes ?
> > > > Has there been any discussion on labelstacking, and mainly
> > > where to place
> > > > the information?
> > > >
> > > > Regards.
> > > > Per
> > > >
> > > >
> > > >
> > >
> > >
> > > --=20
> > > Loa Andersson
> > >
> > > Principal Networking Architect
> > > Acreo AB                           phone:  +46 8 632 77 14
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > Kista, Sweden                      email:  [email-masked]
> > >                                             [email-masked]
> > >
> >
> >
>=20
>=20
>=20
>=20

Delivery-date: Fri, 22 Jul 2005 23:23:08 +0000
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Sat, 23 Jul 2005 01:21:55 +0200

[snip]

> Can I make a plea NOT to screw-up ethernet by attempting to replicate
MPLS

by definition of "Ethernet", this is an explicit non-goal, also the
document does not intend to replicate RFC 3031

> ...in any case the ethernet data-plane belongs to IEEE.

i don't think the document under discussion states the opposite - all the
contrary section 7.1 states

IEEE "should be consulted on the scenarios and framework proposed in this
document and any solutions developed in the IETF context should be reviewed
by the appropriate IEEE working groups to ensure the solution is not
harmful
to 802.1 networks."

Delivery-date: Fri, 22 Jul 2005 23:08:50 +0000
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Sat, 23 Jul 2005 01:03:11 +0200

Delivery-date: Fri, 22 Jul 2005 23:07:53 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Sat, 23 Jul 2005 00:07:39 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_01BD_01C58F1A.8A0CE630
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Neil,

I think John beat me off the blocks here, but...

> > GMPLS assumes an IP control plane.
>
> An IP control-plane?  There is actually no such animal.  Just what=20
> the heck does that REALLY mean in GMPLS say?

Let me explain.
Perhaps I should have said "IP-based control plane".
I mean a control plane which:
- uses IP as its network protocol
- uses IP addresses to identify control plane resources
- uses IP addresses to identify data plane resources within=20
  the control plane
- uses protocols developed for use in the Internet.

> I am not questioning IP as a cl-ps networking protocol *carrying*=20
> a signalling protocol (RSVP-TE, or dare I mention PNNI, or any=20
> signalling protocol yet to be invented) or a routing protocol=20
> (OSPF or ISO or whatever)

I am glad to hear it.

> or even management protocols

Fine, but not in the remit of CCAMP.

> but an 'IP Control Plane' per se means absolutely nothing to me....

Well, I think it should. I think the list of attributes that I have =
given above define a control plane based on IP.=20

It is undoubtable that attempts have been made to use control planes =
based on other protocols. Some have been highly successful. Some have =
been less fortunate.

> ...nor should it to anyone else.=20

I think folks who were around at the beginning of CCAMP and who were =
part of the debate with the IESG will be very familiar with where the =
IETF draws the line here.

> I think some folks might need a reality check here....and also
> on the self-assumed importance of a control-plane. Hint: It ain't=20
> that important.....the management-plane (which may be using IP!)=20
> however is.

I am not sure how to interpret this.
It may be that you think that control plane is bad per se, but you have =
said elsewhere that you think it has value - but much less than the =
management plane.
It may be that you believe that CCAMP is willfully neglecting the =
management plane. This would, in fact, be true. It is not in CCAMP's =
remit to look at the management plane. Other SDOs are working to =
establish common standards for management of network devices across =
multiple vendors - we can wish them luck.
Clearly some people (vendors and providers) see sufficient value in a =
control plane to invest time and energy.

> The (hype) party is over for the OTN start-ups.  IP per se does NOT
> define a *control-plane*...IP is cl-ps networking techology period
> ....and its jolly important, but PLEASE don't try and feed me any of
> this 'IP control plane' nonsense.

Tush.

> Adrian....you are far smarter than this IMO and should know better.

Thanks for the endorsement. May I quote you?

Adrian

------=_NextPart_000_01BD_01C58F1A.8A0CE630
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Hi Neil,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I think John beat me off the blocks =
here,=20
but...</FONT></DIV>
<DIV><FONT face=3DCourier><BR><FONT size=3D2></FONT></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; &gt; GMPLS assumes an IP control =

plane.<BR>&gt;<BR>&gt; An IP control-plane?&nbsp; There is actually no =
such=20
animal.&nbsp; Just what </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; the&nbsp;</FONT><FONT =
face=3DCourier=20
size=3D2>heck does that REALLY mean in GMPLS say?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Let me explain.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Perhaps I should have said "IP-based =
control=20
plane".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I mean a control plane =
which:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- uses IP as its network =
protocol</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- uses IP addresses to identify =
control plane=20
resources</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- uses IP addresses to identify data =
plane=20
resources within </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; the control plane</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- uses protocols developed for use in =
the=20
Internet.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; I am not =
questioning&nbsp;</FONT><FONT=20
face=3DCourier size=3D2>IP</FONT><FONT face=3DCourier size=3D2>&nbsp;as =
a cl-ps=20
networking protocol *carrying* </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; a signalling =
protocol&nbsp;</FONT><FONT=20
face=3DCourier size=3D2>(</FONT><FONT face=3DCourier size=3D2>RSVP-TE, =
or dare I mention=20
PNNI, or any </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; signalling protocol =
yet&nbsp;</FONT><FONT=20
face=3DCourier><FONT size=3D2><FONT>to</FONT></FONT></FONT><FONT =
face=3DCourier=20
size=3D2>&nbsp;be invented) or a routing protocol </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; (OSPF or ISO or =
whatever)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I am glad to hear it.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;or&nbsp;</FONT><FONT =
face=3DCourier=20
size=3D2>even management protocols</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Fine, but not in the remit of =
CCAMP.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;but an 'IP Control Plane' =
per se=20
means&nbsp;</FONT><FONT face=3DCourier size=3D2>absolutely nothing to=20
me....</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Well, I think it should. I think the =
list of=20
attributes that I have given above define a control plane based on IP.=20
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>It is undoubtable that attempts have =
been made to=20
use control planes based on other protocols. Some have been highly =
successful.=20
Some have been less fortunate.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; ...nor should it to anyone=20
else.&nbsp;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I think folks who were around at the =
beginning of=20
CCAMP and who were part of the debate with the IESG will be very =
familiar with=20
where the IETF draws the line here.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; I think&nbsp;</FONT><FONT =
face=3DCourier=20
size=3D2>some folks might need a reality check here....and =
also</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;on the self-</FONT><FONT =
face=3DCourier=20
size=3D2>assumed importance of a control-plane.&nbsp;H</FONT><FONT =
face=3DCourier=20
size=3D2>int: It ain't </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; that&nbsp;</FONT><FONT =
face=3DCourier=20
size=3D2>important.....the management-plane (which may be using IP!) =
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; however</FONT><FONT =
face=3DCourier=20
size=3D2>&nbsp;is.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I am not sure how to interpret =
this.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>It may be that you think that control =
plane is=20
bad per se, but you have said elsewhere that you think it has value - =
but much=20
less than the management plane.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>It may be that you believe that CCAMP =
is=20
willfully neglecting the management plane. This would, in fact, be true. =
It is=20
not in CCAMP's remit to look at the management plane. Other SDOs are =
working to=20
establish common standards for management of network devices across =
multiple=20
vendors - we can wish them luck.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Clearly some people (vendors and =
providers) see=20
sufficient value in a control plane to invest time and energy.</DIV>
<DIV><BR>&gt; The (hype) party is over for the OTN start-ups.&nbsp; IP =
per se=20
does NOT</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;define a =
*control-plane*...IP is cl-ps=20
networking techology period</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; ....and its jolly important, but =
PLEASE=20
don't try and feed me any of</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;this 'IP control plane'=20
nonsense.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Tush.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV>
<DIV>&gt; Adrian....you are far smarter than this IMO and should know=20
better.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks for the endorsement. May I quote you?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Adrian<BR></DIV></FONT><FONT face=3DCourier =
size=3D2></FONT></BODY></HTML>

------=_NextPart_000_01BD_01C58F1A.8A0CE630--

Delivery-date: Fri, 22 Jul 2005 22:20:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Fri, 22 Jul 2005 15:18:35 -0700
From: "Drake, John E" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Neil,

Adrian is correct.  RSVP, OSPF/IS-IS, and BGP are the control plane =
protocols that are used to control an IP network.  GMPLS assumes the =
same set of control plane protocols.

Thanks,

John

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, July 22, 2005 2:22 PM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs =
gmpls
> rnvironment.]
>=20
> > GMPLS assumes an IP control plane.
>=20
> An IP control-plane?  There is actually no such animal.  Just what the
> heck does that REALLY mean in GMPLS say?  I am not questioning IP as a =
cl-
> ps networking protocol *carrying* a signalling protocol (RSVP-TE, or =
dare
> I mention PNNI, or any signalling protocol yet to be invented) or a
> routing protocol (OSPF or ISO or whatever) or even management =
protocols
> but an 'IP Control Plane' per se means absolutely nothing to me....nor
> should it to anyone else.   I think some folks might need a reality =
check
> here....and also on the self-assumed importance of a control-plane.  =
Hint:
> It ain't that important.....the management-plane (which may be using =
IP!)
> however is.
>=20
> The (hype) party is over for the OTN start-ups.  IP per se does NOT =
define
> a *control-plane*...IP is cl-ps networking techology period....and its
> jolly important, but PLEASE don't try and feed me any of this 'IP =
control
> plane' nonsense.
>=20
> Adrian....you are far smarter than this IMO and should know better.
>=20
> regards, Neil
>=20
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Adrian Farrel
> > Sent: 22 July 2005 19:13
> > To: Spencer,R,Richard,XDE73 R; [email-masked];
> > [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: Ethernet Control Plane [Was: Re: Frameformat in a
> > l2cs gmpls rnvironment.]
> >
> >
> > Whoa there!
> >
> > GMPLS assumes an IP control plane.
> > I am aware that there is work afoot in other SDOs to assign a
> > dedicated VLAN tag to specify the control plane traffic. This
> > is not what we are doing.
> >
> > As far as I am aware, everyone in the IETF is comfortable
> > with the idea of using IP packets to carry control plane data
> > through an IP-enabled DCN. In Ethernet the issue will be
> > whether the control plane is in band (use IP address and MAC
> > address) or out of band (use distinct DCN).
> >
> > The use of a separate VLAN ID to signify the control plane is
> > out of scope for CCAMP.
> >
> > Thanks,
> > Adrian
> >
> > ----- Original Message -----
> > From: <[email-masked]>
> > To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Friday, July 22, 2005 4:33 PM
> > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> >
> >
> > Juergen,
> >
> > Before you can use GMPLS to set up VLANs a data plane must
> > first exist to carry the GMPLS control plane traffic. Yes you
> > can use the standard Ethernet data plane for this purpose
> > (and in fact must do so for the solution to be viable), but
> > its not as simple as that. You cannot assume that just
> > because two GMPLS peers are directly connected that they can
> > communicate with each other.
> >
> > To exchange GMPLS control plane packets between a pair of
> > GMPLS peers, the peers will need to agree to use either
> > untagged control packets or to tag them with a common VLAN
> > ID. The use of a separate VLAN for GMPLS control traffic is
> > analogous to using a separate VLAN for management traffic
> > today. If two switches belong to the same management VLAN
> > then you can use ICMP ping to verify connectivity between
> > them. However, if one switch has been put into the wrong
> > management VLAN then the ping will obviously fail.
> >
> > If you want to use a separate VLAN for GMPLS control plane
> > traffic, then you either need to (i) define a reserved GMPLS
> > signalling VLAN ID, or (ii) leave it up to the operator to
> > choose a VLAN ID. If you leave it up to the operator to
> > decide what VLAN ID to use, then you need to consider what
> > the implications in the inter-operator case will be, i.e.
> > what VLAN ID range should be used for control plane traffic
> > and what VLAN ID range should be used for user plane traffic.
> >
> > I'm not saying that defining how GMPLS control plane packets
> > are forwarded in the Ethernet data plane will be an issue,
> > simply that this is something that must be addressed to
> > develop interoperable solutions.
> >
> > Regards,
> > Richard
> >
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Heiles Juergen
> > > Sent: 22 July 2005 14:17
> > > To: Loa Andersson; P=E4r Mattsson
> > > Cc: [email-masked]
> > > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> > >
> > >
> > > GMPLS for SONET/SDH has no impact on the SONET/SDH data plane. It
> > > introduces a control plane for connection setup instead of
> > a network
> > > management based connection setup. GMPLS for Ethernet can
> > work in the
> > > same way. Ethernet as such is cl, but VLANs are setup and GMPLS =
can
> > > provide a control plane for VLAN setup. The Ethernet data
> > plane is not
> > > changed and MAC address learning and forwarding is still be done
> > > within a VLAN. So no change to the Ethernet data plane. No GMPLS
> > > traffic is introduced, it is still VLAN traffic.
> > > Introducing a dedicated GMPLS label for Ethernet (GMPLS
> > > traffic) goes beyond GMPLS as a control plane technique.
> > >
> > > Regards
> > >
> > > Juergen
> > >
> > >
> > >
> > >
> > > > Behalf Of Loa Andersson
> > > > Sent: Friday, July 22, 2005 12:05 PM
> > > > To: P=E4r Mattsson
> > > > Cc: [email-masked]
> > > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> > > >
> > > > Per and Dimitri,
> > > >
> > > > I would like to come down stronger than that, for me it is a =
very
> > > > strong requirement that the same switch can handle both VLANs =
and
> > > > GMPLs trafic correctly. I can't dsee how that could be
> > done if using
> > > > the VLAN tpid to indicate GMPLS traffic.
> > > >
> > > > /Loa
> > > >
> > > > P=E4r Mattsson wrote:
> > > > >>hi par, one of the possibilities that has been considered
> > > > to cope with
> > > > >>this requirement is to use a dedicated TPID for the
> > > Ethernet labeled
> > > > >>frames; this would allow differentiated processing with
> > > non-labeled
> > > > >>framesthanks.
> > > > >
> > > > >
> > > > > That seems to make more sence. If that frame is to be sized
> > > > like a 802.1q
> > > > > frame. There is not that much space left to a label. Or is
> > > > the demand to
> > > > > use jumboframes ?
> > > > > Has there been any discussion on labelstacking, and mainly
> > > > where to place
> > > > > the information?
> > > > >
> > > > > Regards.
> > > > > Per
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Loa Andersson
> > > >
> > > > Principal Networking Architect
> > > > Acreo AB                           phone:  +46 8 632 77 14
> > > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > > Kista, Sweden                      email:  =
[email-masked]
> > > >                                             [email-masked]

Delivery-date: Fri, 22 Jul 2005 21:23:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Fri, 22 Jul 2005 22:22:13 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

> GMPLS assumes an IP control plane.

An IP control-plane?  There is actually no such animal.  Just what the =
heck does that REALLY mean in GMPLS say?  I am not questioning IP as a =
cl-ps networking protocol *carrying* a signalling protocol (RSVP-TE, or =
dare I mention PNNI, or any signalling protocol yet to be invented) or a =
routing protocol (OSPF or ISO or whatever) or even management protocols =
but an 'IP Control Plane' per se means absolutely nothing to me....nor =
should it to anyone else.   I think some folks might need a reality =
check here....and also on the self-assumed importance of a =
control-plane.  Hint: It ain't that important.....the management-plane =
(which may be using IP!) however is.

The (hype) party is over for the OTN start-ups.  IP per se does NOT =
define a *control-plane*...IP is cl-ps networking techology =
period....and its jolly important, but PLEASE don't try and feed me any =
of this 'IP control plane' nonsense.

Adrian....you are far smarter than this IMO and should know better.

regards, Neil

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 22 July 2005 19:13
> To: Spencer,R,Richard,XDE73 R; [email-masked];=20
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Ethernet Control Plane [Was: Re: Frameformat in a=20
> l2cs gmpls rnvironment.]
>=20
>=20
> Whoa there!
>=20
> GMPLS assumes an IP control plane.
> I am aware that there is work afoot in other SDOs to assign a
> dedicated VLAN tag to specify the control plane traffic. This=20
> is not what we are doing.
>=20
> As far as I am aware, everyone in the IETF is comfortable
> with the idea of using IP packets to carry control plane data=20
> through an IP-enabled DCN. In Ethernet the issue will be=20
> whether the control plane is in band (use IP address and MAC=20
> address) or out of band (use distinct DCN).
>=20
> The use of a separate VLAN ID to signify the control plane is
> out of scope for CCAMP.
>=20
> Thanks,
> Adrian
>=20
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, July 22, 2005 4:33 PM
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
>=20
>=20
> Juergen,
>=20
> Before you can use GMPLS to set up VLANs a data plane must
> first exist to carry the GMPLS control plane traffic. Yes you=20
> can use the standard Ethernet data plane for this purpose=20
> (and in fact must do so for the solution to be viable), but=20
> its not as simple as that. You cannot assume that just=20
> because two GMPLS peers are directly connected that they can=20
> communicate with each other.
>=20
> To exchange GMPLS control plane packets between a pair of
> GMPLS peers, the peers will need to agree to use either=20
> untagged control packets or to tag them with a common VLAN=20
> ID. The use of a separate VLAN for GMPLS control traffic is=20
> analogous to using a separate VLAN for management traffic=20
> today. If two switches belong to the same management VLAN=20
> then you can use ICMP ping to verify connectivity between=20
> them. However, if one switch has been put into the wrong=20
> management VLAN then the ping will obviously fail.
>=20
> If you want to use a separate VLAN for GMPLS control plane
> traffic, then you either need to (i) define a reserved GMPLS=20
> signalling VLAN ID, or (ii) leave it up to the operator to=20
> choose a VLAN ID. If you leave it up to the operator to=20
> decide what VLAN ID to use, then you need to consider what=20
> the implications in the inter-operator case will be, i.e.=20
> what VLAN ID range should be used for control plane traffic=20
> and what VLAN ID range should be used for user plane traffic.
>=20
> I'm not saying that defining how GMPLS control plane packets
> are forwarded in the Ethernet data plane will be an issue,=20
> simply that this is something that must be addressed to=20
> develop interoperable solutions.
>=20
> Regards,
> Richard
>=20
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Heiles Juergen
> > Sent: 22 July 2005 14:17
> > To: Loa Andersson; P=E4r Mattsson
> > Cc: [email-masked]
> > Subject: RE: Frameformat in a l2cs gmpls rnvironment.
> >
> >
> > GMPLS for SONET/SDH has no impact on the SONET/SDH data plane. It
> > introduces a control plane for connection setup instead of=20
> a network
> > management based connection setup. GMPLS for Ethernet can
> work in the
> > same way. Ethernet as such is cl, but VLANs are setup and GMPLS can
> > provide a control plane for VLAN setup. The Ethernet data=20
> plane is not
> > changed and MAC address learning and forwarding is still be done
> > within a VLAN. So no change to the Ethernet data plane. No GMPLS
> > traffic is introduced, it is still VLAN traffic.
> > Introducing a dedicated GMPLS label for Ethernet (GMPLS
> > traffic) goes beyond GMPLS as a control plane technique.
> >
> > Regards
> >
> > Juergen
> >
> >
> >
> >
> > > Behalf Of Loa Andersson
> > > Sent: Friday, July 22, 2005 12:05 PM
> > > To: P=E4r Mattsson
> > > Cc: [email-masked]
> > > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> > >
> > > Per and Dimitri,
> > >
> > > I would like to come down stronger than that, for me it is a very
> > > strong requirement that the same switch can handle both VLANs and=20
> > > GMPLs trafic correctly. I can't dsee how that could be=20
> done if using
> > > the VLAN tpid to indicate GMPLS traffic.
> > >
> > > /Loa
> > >
> > > P=E4r Mattsson wrote:
> > > >>hi par, one of the possibilities that has been considered
> > > to cope with
> > > >>this requirement is to use a dedicated TPID for the
> > Ethernet labeled
> > > >>frames; this would allow differentiated processing with
> > non-labeled
> > > >>framesthanks.
> > > >
> > > >
> > > > That seems to make more sence. If that frame is to be sized
> > > like a 802.1q
> > > > frame. There is not that much space left to a label. Or is
> > > the demand to
> > > > use jumboframes ?
> > > > Has there been any discussion on labelstacking, and mainly
> > > where to place
> > > > the information?
> > > >
> > > > Regards.
> > > > Per
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Loa Andersson
> > >
> > > Principal Networking Architect
> > > Acreo AB                           phone:  +46 8 632 77 14
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > Kista, Sweden                      email:  [email-masked]
> > >                                             [email-masked]
> > >
> >
> >
>=20
>=20
>=20
>=20
>=20

Delivery-date: Fri, 22 Jul 2005 21:23:52 +0000
Content-class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 22:22:12 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58F03.6D2AEF23
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

And me too Ben/Igor.  But go look at MPLS when folks DID define a =
data-plane here....don't anyone dare tell me 'this is good' (or the PW =
stuff it spawned) because I know otherwise.
=20
reqards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Mack-Crane, T. Benjamin
Sent: 22 July 2005 19:25
To: Igor Bryskin; [email-masked]
Cc: Adrian Farrel; P=E4r Mattsson; Loa Andersson; [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

Igor,
=20
I, too, am baffled by the notion of requirements for control of an =
unspecified data plane.
=20
Regards,
Ben

  _____ =20

From: Igor Bryskin [mailto:[email-masked]]=20
Sent: Friday, July 22, 2005 12:20 PM
To: [email-masked]
Cc: Mack-Crane, T. Benjamin; Adrian Farrel; P=E4r Mattsson; Loa =
Andersson; [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

Dimitri,
=20
The question is simple: is it possible today to statically provision =
L2LSPs that could, say, support e2e QoS? If not, may be it is to early =
to discuss aspects of dynamic provisioning of such LSPs? Is it =
possible/reasonable, in your opinion, to "detail how forwarding =
information can be exchanged via the control plane (and then installed)" =
without having in mind "a specific forwarding behavior"?
How do you know which forwarding information is needed for the =
forwarding nobody has defined yet?
The other question is do we need at all e2e QoS, route control, fast =
recovery? Sounds like exciting idea, but does all that commercially make =
sense? So, I guess, we need two things before we can move forward:
a) validation of the idea by the providers;
b) definition of the data plane behavior;
=20
Igor

----- Original Message -----=20
From: [email-masked]=20
To: Igor Bryskin <mailto:[email-masked]> =20
Cc: Mack-Crane, T. Benjamin <mailto:[email-masked]>  ; =
Adrian  <mailto:[email-masked]> Farrel ; P=E4r  =
<mailto:[email-masked]> Mattsson ; Loa  <mailto:[email-masked]> Andersson ; =
[email-masked]=20
Sent: Friday, July 22, 2005 12:21 PM
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

igor - i am not sure which point they exactly have - the purpose of this =
document is to detail how forwarding information can be exchanged via =
the control plane (and then installed) not to define a specific =
forwarding behaviour

thanks,

- dimitri.

"Igor Bryskin" <[email-masked]>
Sent by: [email-masked]
07/22/2005 11:10 AST

To: "Mack-Crane, T. Benjamin" <[email-masked]>, "Adrian =
Farrel" <[email-masked]>, P=E4r Mattsson <[email-masked]>, "Loa =
Andersson" <[email-masked]>
cc: <[email-masked]>
bcc:=20
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

Hi,

I think Ben and Juergen have a point here. There is nothing that could =
be dynamically provisioned that could not be also provisioned by =
management. In other words data plane is the King here. We need data =
plane standard(s) on how we encode a label, whether we need a label =
stack or not, how the labeled traffic is supposed to be treated, how =
labeled traffic co-exist with non-label traffic, etc. This is something =
that not for CCAMP to define. Take for example TDM networks. GMPLS only =
provides a way to dynamically provision G.707 networks. Hence there is a =
need in parallel standardization activities in ITU. Only after that we =
can discuss how all that could be dynamically provisioned, that is the =
aspects of control plane.=20

Igor
----- Original Message -----=20
From: Mack-Crane, T.  <mailto:[email-masked]> Benjamin=20
To: Adrian Farrel <mailto:[email-masked]>  ; P=E4r Mattsson =
<mailto:[email-masked]>  ; Loa  <mailto:[email-masked]> Andersson=20
Cc: [email-masked]=20
Sent: Friday, July 22, 2005 10:23 AM
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

Hi,

I think Juergen has raised an important question.  How frames are =
labeled (and the related data plane forwarding behavior) is not defined =
by the control plane.  The control plane serves to provision the data =
plane, not define it.  In the framework draft it is not clear what data =
plane standards are covered by the stated control plane requirements.  =
Some references should be supplied.  In any case, the labeling and =
forwarding behavior should be defined by these referenced standards, not =
by GMPLS.

(I am assuming definition of new data plane standards is out of scope =
for CCAMP.)

Regards,
Ben

  _____ =20

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Adrian Farrel
Sent: Friday, July 22, 2005 8:37 AM
To: P=E4r Mattsson; Loa Andersson
Cc: [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

Hi,

It is always refreshing how engineers jump straight to a discussion of =
the solution :-)

Perhaps we can assume that the framework draft is a good representation =
of the problem space, and that we are ready to start discussing the =
solutions.

One (perhaps the only?) significant question to answer is how the frames =
will be labelled. This question is one we must come to as soon as we are =
confident that the requirements need to be addressed at all.

As has been pointed out, there are several possibilities and to pick =
from these we need to understand:
1. Do we need to support explicit label stacking?
   Note that this is not supported in TDM, LSC or FSC.
2. Do we need to be able to control (perhaps through an
   external signaling controller) existing hardware and=20
   install LSPs through existing networks?
3. Do we need to support existing function simultaneous to
   the support of GMPLS L2 LSPs?

I think that from a chair's perspective I can give some limited =
guidance.

A. These questions must be raised and answered in the framework I-D
B. The answer to question 3 is "yes". This means that the use of labels
   must not significantly deplete any namespace used to support other
   function.
C. CCAMP is chartered to look at the control of transport networks. This
   includes Metro, but I am unsure about Campus. It does not cover=20
   signaling to the desktop.

Thanks,
Adrian

----- Original Message -----=20
From: "P=E4r Mattsson" <[email-masked]>
To: "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 22, 2005 11:41 AM
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

> > Per and Dimitri,
> >
> > I would like to come down stronger than that, for me it is
> > a very strong requirement that the same switch can handle
> > both VLANs and GMPLs trafic correctly. I can't dsee how that
> > could be done if using the VLAN tpid to indicate GMPLS
> > traffic.
>=20
> If you ever want that same switch to handle traffic for a directly
> connected  host (not to uncommen) you would want that to use normal
> ethernet macaddress switching. So of course you do not want to have to
> choose between vlan and gmpls, you would want both at the same time.
>=20
> /per
>=20
>=20
> >
> > /Loa
> >
> > P=E4r Mattsson wrote:
> >>>hi par, one of the possibilities that has been considered to cope =
with
> >>>this requirement is to use a dedicated TPID for the Ethernet =
labeled
> >>>frames; this would allow differentiated processing with non-labeled
> >>>framesthanks.
> >>
> >>
> >> That seems to make more sence. If that frame is to be sized like a
> >> 802.1q
> >> frame. There is not that much space left to a label. Or is the =
demand to
> >> use jumboframes ?
> >> Has there been any discussion on labelstacking, and mainly where to
> >> place
> >> the information?
> >>
> >> Regards.
> >> Per
> >>
> >>
> >>
> >
> >
> > --
> > Loa Andersson
> >
> > Principal Networking Architect
> > Acreo AB                           phone:  +46 8 632 77 14
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > Kista, Sweden                      email:  [email-masked]
> >                                             [email-masked]
> >
>=20
>=20
>=20
>=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C58F03.6D2AEF23
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D689555920-22072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>And me too Ben/Igor.&nbsp; But go look at MPLS when folks DID =
define a=20
data-plane here....don't anyone dare tell me 'this is good' (or the PW =
stuff it=20
spawned) because I know otherwise.</FONT></SPAN></DIV>
<DIV><SPAN class=3D689555920-22072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D689555920-22072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>reqards, Neil</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
  </B>Mack-Crane, T. Benjamin<BR><B>Sent:</B> 22 July 2005 =
19:25<BR><B>To:</B>=20
  Igor Bryskin; [email-masked]<BR><B>Cc:</B> Adrian =
Farrel;=20
  P=E4r Mattsson; Loa Andersson; [email-masked]<BR><B>Subject:</B> =
RE:=20
  Frameformat in a l2cs gmpls rnvironment.<BR><BR></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D935282018-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Igor,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D935282018-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D935282018-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>I, too, am baffled by the notion of =
requirements for=20
  control of an unspecified data plane.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D935282018-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D935282018-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D935282018-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Ben</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> Igor Bryskin=20
    [mailto:[email-masked]] <BR><B>Sent:</B> Friday, July 22, 2005 =
12:20=20
    PM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> =
Mack-Crane,=20
    T. Benjamin; Adrian Farrel; P=E4r Mattsson; Loa Andersson;=20
    [email-masked]<BR><B>Subject:</B> Re: Frameformat in a l2cs =
gmpls=20
    rnvironment.<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT face=3DArial size=3D2>Dimitri,</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>The question is simple: is it =
possible today to=20
    statically provision L2LSPs that could, say,&nbsp;support e2e QoS? =
If not,=20
    may be it is to early to discuss aspects of dynamic provisioning of =
such=20
    LSPs? Is it possible/reasonable, in your opinion, to "<FONT=20
    face=3D"Courier New" size=3D3>detail how forwarding information can =
be exchanged=20
    via the control plane (and then installed)" without&nbsp;having in =
mind "a=20
    specific forwarding behavior"?</FONT></FONT></DIV>
    <DIV><FONT face=3D"Courier New">How do you know which forwarding =
information=20
    is needed for the forwarding nobody has defined yet?</FONT></DIV>
    <DIV><FONT face=3D"Courier New">The other question is&nbsp;do we =
need at all=20
    e2e QoS, route control, fast recovery? Sounds like exciting idea, =
but does=20
    all that commercially make sense? So, I guess, we need two=20
    things&nbsp;before we can&nbsp;move forward:</FONT></DIV>
    <DIV><FONT face=3D"Courier New">a) validation of the idea by the=20
    providers;</FONT></DIV>
    <DIV><FONT face=3D"Courier New">b) definition of the data plane=20
    behavior;</FONT></DIV>
    <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New">Igor</FONT></DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
      <DIV style=3D"FONT: 10pt arial">----- Original Message ----- =
</DIV>
      <DIV=20
      style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
      <A title=[email-masked]=20
      =
href=3D"mailto:[email-masked]">Dimitri.Papadimitriou@al=
catel.be</A>=20
      </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
      href=3D"mailto:[email-masked]">Igor Bryskin</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A=20
      title=[email-masked]=20
      href=3D"mailto:[email-masked]">Mack-Crane, T. =
Benjamin</A> ; <A=20
      title=[email-masked] =
href=3D"mailto:[email-masked]">Adrian=20
      Farrel</A> ; <A title=[email-masked] =
href=3D"mailto:[email-masked]">P=E4r=20
      Mattsson</A> ; <A title=[email-masked] href=3D"mailto:[email-masked]">Loa=20
      Andersson</A> ; <A title=[email-masked]=20
      href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, July 22, 2005 =
12:21=20
      PM</DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Frameformat in =
a l2cs=20
      gmpls rnvironment.</DIV>
      <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>
      <P><FONT face=3DMonospace,Courier>igor - i am not sure which point =
they=20
      exactly have - the purpose of this document is to detail how =
forwarding=20
      information can be exchanged via the control plane (and then =
installed)=20
      not to define a specific forwarding behaviour</FONT></P>
      <P><FONT face=3DMonospace,Courier>thanks,</FONT></P>
      <P><FONT face=3DMonospace,Courier>- dimitri.</FONT><BR><BR><FONT=20
      size=3D2><B>"Igor Bryskin" &lt;<A=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</B></FONT><=
BR><FONT=20
      size=3D2>Sent by: <A=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A></FO=
NT><BR><FONT=20
      size=3D2>07/22/2005 11:10 AST</FONT><BR><BR><FONT =
size=3D2>To:</FONT> <FONT=20
      size=3D2>"Mack-Crane, T. Benjamin" &lt;<A=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A>=
&gt;,=20
      "Adrian Farrel" &lt;<A=20
      href=3D"mailto:[email-masked]">[email-masked]</A>&gt;, =
P=E4r=20
      Mattsson &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;, "Loa=20
      Andersson" &lt;<A=20
      href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FONT><BR><FONT=20
      size=3D2>cc:</FONT> <FONT size=3D2>&lt;<A=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FONT><BR><=
FONT=20
      size=3D2>bcc:</FONT> <BR><FONT size=3D2>Subject:</FONT> <FONT =
size=3D2>Re:=20
      Frameformat in a l2cs gmpls rnvironment.</FONT><BR><BR><BR></P>
      <P>Hi,<BR><BR>I think Ben and Juergen have a point here. There is =
nothing=20
      that could be dynamically provisioned that could not be also =
provisioned=20
      by management. In other words data plane is the King here. We need =
data=20
      plane standard(s) on how we encode a label, whether we need a =
label stack=20
      or not, how the labeled traffic is supposed to be&nbsp;treated, =
how=20
      labeled traffic co-exist with non-label traffic, etc. This is =
something=20
      that not for CCAMP to define. Take for example TDM networks. GMPLS =
only=20
      provides a way to dynamically provision G.707 networks. Hence =
there is a=20
      need in parallel standardization activities in ITU. Only after =
that we can=20
      discuss how all that could be dynamically provisioned, that is the =
aspects=20
      of control plane. <BR><BR>Igor<BR><FONT size=3D4>----- Original =
Message=20
      ----- </FONT><BR><FONT size=3D4><B>From:</B> </FONT><FONT =
color=3Dblue=20
      size=3D4><U><A =
href=3D"mailto:[email-masked]">Mack-Crane, T.=20
      Benjamin</A></U></FONT><FONT color=3Dblack size=3D4> =
</FONT><BR><FONT=20
      size=3D4><B>To:</B> </FONT><FONT color=3Dblue size=3D4><U><A=20
      href=3D"mailto:[email-masked]">Adrian =
Farrel</A></U></FONT><FONT=20
      color=3Dblack size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A =

      href=3D"mailto:[email-masked]">P=E4r Mattsson</A></U></FONT><FONT =
color=3Dblack=20
      size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A =
href=3D"mailto:[email-masked]">Loa=20
      Andersson</A></U></FONT><FONT color=3Dblack size=3D4> =
</FONT><BR><FONT=20
      size=3D4><B>Cc:</B> </FONT><FONT color=3Dblue size=3D4><U><A=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT=
=20
      color=3Dblack size=3D4> </FONT><BR><FONT size=3D4><B>Sent:</B> =
Friday, July 22,=20
      2005 10:23 AM</FONT><BR><FONT size=3D4><B>Subject:</B> RE: =
Frameformat in a=20
      l2cs gmpls rnvironment.</FONT><BR><BR>Hi,<BR><BR>I think Juergen =
has=20
      raised an important question.&nbsp; How frames are labeled (and =
the=20
      related data plane forwarding behavior) is not defined by the =
control=20
      plane.&nbsp; The control plane serves to provision the data plane, =
not=20
      define it.&nbsp; In the framework draft it is not clear what data =
plane=20
      standards are covered by the stated control plane =
requirements.&nbsp; Some=20
      references should be supplied.&nbsp; In any case, the labeling and =

      forwarding behavior should be defined&nbsp;by these referenced =
standards,=20
      not&nbsp;by GMPLS.<BR><BR>(I am assuming definition of new data =
plane=20
      standards is out of scope for CCAMP.)<BR><BR>Regards,<BR>Ben<BR>
      <HR align=3Dleft width=3D"99%" SIZE=3D4>
      <FONT color=3Dblack><BR><B>From:</B> [email-masked]=20
      [mailto:[email-masked]] <B>On Behalf Of </B>Adrian=20
      Farrel<BR><B>Sent:</B> Friday, July 22, 2005 8:37 AM<BR><B>To:</B> =
P=E4r=20
      Mattsson; Loa Andersson<BR><B>Cc:</B>=20
      [email-masked]<BR><B>Subject:</B> Re: Frameformat in a l2cs =
gmpls=20
      rnvironment.<BR><BR>Hi,<BR><BR>It is always refreshing how =
engineers jump=20
      straight to a discussion of the solution :-)<BR><BR>Perhaps we can =
assume=20
      that the framework draft is a good representation of the problem =
space,=20
      and that we are ready to start discussing the =
solutions.<BR><BR>One=20
      (perhaps the only?) significant question to answer is how the =
frames will=20
      be labelled. This question is one we must come to as soon as we =
are=20
      confident that the requirements need to be addressed at =
all.<BR><BR>As has=20
      been pointed out, there are several possibilities and to pick from =
these=20
      we need to understand:<BR>1. Do we need to support explicit label=20
      stacking?<BR>&nbsp;&nbsp; Note that this is not supported in TDM, =
LSC or=20
      FSC.<BR>2. Do we need to be able to control (perhaps through=20
      an<BR>&nbsp;&nbsp;&nbsp;external signaling controller) existing =
hardware=20
      and <BR>&nbsp;&nbsp; install LSPs through existing networks?<BR>3. =
Do we=20
      need to support existing function simultaneous to<BR>&nbsp;&nbsp; =
the=20
      support of GMPLS L2 LSPs?<BR><BR>I think that from a chair's =
perspective I=20
      can give some limited guidance.<BR><BR>A. These questions must be =
raised=20
      and answered in the framework I-D<BR>B. The answer to question 3 =
is "yes".=20
      This means that the use of labels<BR>&nbsp;&nbsp; must not =
significantly=20
      deplete any namespace used to support other<BR>&nbsp;&nbsp;=20
      function.<BR>C. CCAMP is chartered to look at the control of =
transport=20
      networks. This<BR>&nbsp;&nbsp;&nbsp;includes Metro, but I am =
unsure about=20
      Campus. It does not&nbsp;cover <BR>&nbsp;&nbsp; signaling to the=20
      desktop.<BR><BR>Thanks,<BR>Adrian<BR><BR>----- Original Message =
-----=20
      <BR>From: "P=E4r Mattsson" &lt;</FONT><FONT color=3Dblue><U><A=20
      href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT=20
      color=3Dblack>&gt;<BR>To: "Loa Andersson" &lt;</FONT><FONT =
color=3Dblue><U><A=20
      href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT=20
      color=3Dblack>&gt;<BR>Cc: &lt;</FONT><FONT color=3Dblue><U><A=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT=
=20
      color=3Dblack>&gt;<BR>Sent: Friday, July 22, 2005 11:41 =
AM<BR>Subject: Re:=20
      Frameformat in a l2cs gmpls rnvironment.<BR><BR><BR>&gt; &gt; Per =
and=20
      Dimitri,<BR>&gt; &gt;<BR>&gt; &gt; I would like to come down =
stronger than=20
      that, for me it is<BR>&gt; &gt; a very strong requirement that the =
same=20
      switch can handle<BR>&gt; &gt; both VLANs and GMPLs trafic =
correctly. I=20
      can't dsee how that<BR>&gt; &gt; could be done if using the VLAN =
tpid to=20
      indicate GMPLS<BR>&gt; &gt; traffic.<BR>&gt; <BR>&gt; If you ever =
want=20
      that same switch to handle traffic for a directly<BR>&gt; =
connected&nbsp;=20
      host (not to uncommen) you would want that to use normal<BR>&gt; =
ethernet=20
      macaddress switching. So of course you do not want to have =
to<BR>&gt;=20
      choose between vlan and gmpls, you would want both at the same=20
      time.<BR>&gt; <BR>&gt; /per<BR>&gt; <BR>&gt; <BR>&gt; &gt;<BR>&gt; =
&gt;=20
      /Loa<BR>&gt; &gt;<BR>&gt; &gt; P=E4r Mattsson wrote:<BR>&gt; =
&gt;&gt;&gt;hi=20
      par, one of the possibilities that has been considered to cope=20
      with<BR>&gt; &gt;&gt;&gt;this requirement is to use a dedicated =
TPID for=20
      the Ethernet labeled<BR>&gt; &gt;&gt;&gt;frames; this would allow=20
      differentiated processing with non-labeled<BR>&gt;=20
      &gt;&gt;&gt;framesthanks.<BR>&gt; &gt;&gt;<BR>&gt; =
&gt;&gt;<BR>&gt;=20
      &gt;&gt; That seems to make more sence. If that frame is to be =
sized like=20
      a<BR>&gt; &gt;&gt; 802.1q<BR>&gt; &gt;&gt; frame. There is not =
that much=20
      space left to a label. Or is the demand to<BR>&gt; &gt;&gt; use=20
      jumboframes ?<BR>&gt; &gt;&gt; Has there been any discussion on=20
      labelstacking, and mainly where to<BR>&gt; &gt;&gt; place<BR>&gt; =
&gt;&gt;=20
      the information?<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; =
Regards.<BR>&gt;=20
      &gt;&gt; Per<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; =
&gt;&gt;<BR>&gt;=20
      &gt;<BR>&gt; &gt;<BR>&gt; &gt; --<BR>&gt; &gt; Loa =
Andersson<BR>&gt;=20
      &gt;<BR>&gt; &gt; Principal Networking Architect<BR>&gt; &gt; =
Acreo=20
      =
AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
      phone:&nbsp; +46 8 632 77 14<BR>&gt; &gt; Isafjordsgatan=20
      =
22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      mobile: +46 739 81 21 64<BR>&gt; &gt; Kista,=20
      =
Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      email:&nbsp; </FONT><FONT color=3Dblue><U><A=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A></U></FO=
NT><FONT=20
      color=3Dblack><BR>&gt;=20
      =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      </FONT><FONT color=3Dblue><U><A=20
      href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT =
color=3Dblack><BR>&gt;=20
      &gt;<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR><BR></FONT><FONT=20
      face=3DMonospace,Courier=20
      =
size=3D4>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT><BR><FONT=20
      face=3DMonospace,Courier size=3D4>The information contained in =
this message=20
      may be privileged</FONT><BR><FONT face=3DMonospace,Courier =
size=3D4>and=20
      confidential and protected from disclosure. If the =
reader</FONT><BR><FONT=20
      face=3DMonospace,Courier size=3D4>of this message is not the =
intended=20
      recipient, or an employee</FONT><BR><FONT face=3DMonospace,Courier =
size=3D4>or=20
      agent responsible for delivering this message to =
the</FONT><BR><FONT=20
      face=3DMonospace,Courier size=3D4>intended recipient, you are =
hereby notified=20
      that any reproduction,</FONT><BR><FONT face=3DMonospace,Courier=20
      size=3D4>dissemination or distribution of this communication is=20
      strictly</FONT><BR><FONT face=3DMonospace,Courier =
size=3D4>prohibited. If you=20
      have received this communication in error,</FONT><BR><FONT=20
      face=3DMonospace,Courier size=3D4>please notify us immediately by =
replying to=20
      the message and</FONT><BR><FONT face=3DMonospace,Courier =
size=3D4>deleting it=20
      from your computer. Thank you. Tellabs</FONT><BR><FONT=20
      face=3DMonospace,Courier=20
      =
size=3D4>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT><BR>
      =
<P></P></BLOCKQUOTE></BLOCKQUOTE><PRE>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
</PRE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C58F03.6D2AEF23--

Delivery-date: Fri, 22 Jul 2005 20:13:51 +0000
Content-class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 21:11:43 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58EF9.93F9EBAA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dimitri, =20
=20
What do you mean by 'interferring elements'.....this sounds like some
'behind closed doors sect' at work.  I thought Adrian's post was (as
usual) plain/clear as to intent.
=20
regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: 22 July 2005 16:51
To: Adrian Farrel
Cc: [email-masked]; [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

adrian - ok much thanks for the clarification -=20

i wanted to be sure that the working group consensus is going to be the
element of decision for putting this item in the working list - and we
won't have other interfering elements in the decision process -=20

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
07/22/2005 16:08
Please respond to "Adrian Farrel"

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: <[email-masked]>
bcc:=20
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

Dimitri,

> what do you EXACTLY mean with the following sentence
>
> "This question is one we must come to as soon as we are confident that
the
> requirements need to be addressed at all."
>
> please clarify - btw who is "we" in this context ?

"We" means "the CCAMP working group"

> this sentence reads to me as "CCAMP has not yet committed to work on
this
> topic" is my reading correct ? or do you mean something else with this
?

Your reading is exactly correct as stated.
I refer you to your email to the list on 19th July. You asked...
> - if yes, is the interest in GMPLS for Ethernet in-/out-side the
>   CCAMP WG community strong enough to consider the corr. GMPLS
>   signaling and routing requirements (second part of the document)
>   as part of the CCAMP WG effort ?

Thus, the purpose of the I-D was to crystalize the authors' thoughts on
GMPLS control of Ethernet switching and to initiate discussion on
whether
the proposed deployment models are realistic and desirable. Following a
positive answer and assuming support (by CCAMP) for the doing the work
(in
CCAMP) all that remains is to add the work to the charter (see previous
charter discussions) and get on with it.

Thanks,
Adrian

------_=_NextPart_001_01C58EF9.93F9EBAA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D149210919-22072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Dimitri,&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D149210919-22072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D149210919-22072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>What do you mean by 'interferring elements'.....this sounds =
like some=20
'behind closed doors sect' at work.&nbsp; I thought Adrian's post was =
(as usual)=20
plain/clear as to intent.</FONT></SPAN></DIV>
<DIV><SPAN class=3D149210919-22072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D149210919-22072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
  </B>[email-masked]<BR><B>Sent:</B> 22 July 2005=20
  16:51<BR><B>To:</B> Adrian Farrel<BR><B>Cc:</B>=20
  [email-masked]; =
[email-masked]<BR><B>Subject:</B> Re:=20
  Frameformat in a l2cs gmpls rnvironment.<BR><BR></FONT></DIV>
  <P><FONT face=3DMonospace,Courier>adrian - ok much thanks for the =
clarification=20
  - </FONT></P>
  <P><FONT face=3DMonospace,Courier>i wanted to be sure that the working =
group=20
  consensus is going to be the element of decision for putting this item =
in the=20
  working list - and we won't have other interfering elements in the =
decision=20
  process - </FONT><BR><BR><FONT size=3D2><B>"Adrian Farrel"=20
  &lt;[email-masked]&gt;</B></FONT><BR><FONT size=3D2>Sent by:=20
  [email-masked]</FONT><BR><FONT size=3D2>07/22/2005=20
  16:08</FONT><BR><FONT size=3D2>Please respond to "Adrian=20
  Farrel"</FONT><BR><BR><FONT size=3D2>To:</FONT> <FONT size=3D2>Dimitri =

  PAPADIMITRIOU/BE/ALCATEL@ALCATEL</FONT><BR><FONT size=3D2>cc:</FONT> =
<FONT=20
  size=3D2>&lt;[email-masked]&gt;</FONT><BR><FONT =
size=3D2>bcc:</FONT> <BR><FONT=20
  size=3D2>Subject:</FONT> <FONT size=3D2>Re: Frameformat in a l2cs =
gmpls=20
  rnvironment.</FONT><BR><BR><BR></P>
  <P><FONT face=3DMonospace,Courier>Dimitri,<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>&gt; what do you EXACTLY mean with the =
following=20
  sentence<BR>&gt;<BR>&gt; "This question is one we must come to as soon =
as we=20
  are confident that<BR>the<BR>&gt; requirements need to be addressed at =

  all."<BR>&gt;<BR>&gt; please clarify - btw who is "we" in this context =

  ?<BR></FONT><BR><FONT face=3DMonospace,Courier>"We" means "the CCAMP =
working=20
  group"<BR></FONT><BR><FONT face=3DMonospace,Courier>&gt; this sentence =
reads to=20
  me as "CCAMP has not yet committed to work on<BR>this<BR>&gt; topic" =
is my=20
  reading correct ? or do you mean something else with this=20
  ?<BR></FONT><BR><FONT face=3DMonospace,Courier>Your reading is exactly =
correct=20
  as stated.<BR>I refer you to your email to the list on 19th July. You=20
  asked...<BR>&gt; - if yes, is the interest in GMPLS for Ethernet =
in-/out-side=20
  the<BR>&gt; &nbsp; CCAMP WG community strong enough to consider the =
corr.=20
  GMPLS<BR>&gt; &nbsp; signaling and routing requirements (second part =
of the=20
  document)<BR>&gt; &nbsp; as part of the CCAMP WG effort =
?<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>Thus, the purpose of the I-D was to =
crystalize the=20
  authors' thoughts on<BR>GMPLS control of Ethernet switching and to =
initiate=20
  discussion on whether<BR>the proposed deployment models are realistic =
and=20
  desirable. Following a<BR>positive answer and assuming support (by =
CCAMP) for=20
  the doing the work (in<BR>CCAMP) all that remains is to add the work =
to the=20
  charter (see previous<BR>charter discussions) and get on with=20
  it.<BR></FONT><BR><FONT=20
face=3DMonospace,Courier>Thanks,<BR>Adrian<BR></FONT></P></BLOCKQUOTE></B=
ODY></HTML>

------_=_NextPart_001_01C58EF9.93F9EBAA--

Delivery-date: Fri, 22 Jul 2005 20:13:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 21:11:44 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58EF9.9504EFFA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

And you are so right on this Igor.  The nice thing about the co-cs mode =
is that the data-plane has not been defined here and works great.  =
Adding a (forced) OOB control-plane is not a big deal.....in fact as we =
move to the duct the control-plane is of much lesser interest/importance =
(this is not to belittle it, its just a fact)   Where the data-plane has =
been defined however, for the co-ps mode in MPLS and the PW stuff its =
unfortunately spawned, it's (how shall I put this politely) 'not so =
great'.  Can I make a plea NOT to screw-up ethernet by attempting to =
replicate MPLS....in any case the ethernet data-plane belongs to IEEE.  =
I would advise folks here to leave this well alone.
=20
regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Igor Bryskin
Sent: 22 July 2005 16:11
To: Mack-Crane, T. Benjamin; Adrian Farrel; P=E4r Mattsson; Loa =
Andersson
Cc: [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

Hi,
=20
I think Ben and Juergen have a point here. There is nothing that could =
be dynamically provisioned that could not be also provisioned by =
management. In other words data plane is the King here. We need data =
plane standard(s) on how we encode a label, whether we need a label =
stack or not, how the labeled traffic is supposed to be treated, how =
labeled traffic co-exist with non-label traffic, etc. This is something =
that not for CCAMP to define. Take for example TDM networks. GMPLS only =
provides a way to dynamically provision G.707 networks. Hence there is a =
need in parallel standardization activities in ITU. Only after that we =
can discuss how all that could be dynamically provisioned, that is the =
aspects of control plane.=20
=20
Igor

----- Original Message -----=20
From: Mack-Crane, T. Benjamin <mailto:[email-masked]> =20
To: Adrian Farrel <mailto:[email-masked]>  ; P=E4r Mattsson =
<mailto:[email-masked]>  ; Loa Andersson <mailto:[email-masked]> =20
Cc: [email-masked]=20
Sent: Friday, July 22, 2005 10:23 AM
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

Hi,
=20
I think Juergen has raised an important question.  How frames are =
labeled (and the related data plane forwarding behavior) is not defined =
by the control plane.  The control plane serves to provision the data =
plane, not define it.  In the framework draft it is not clear what data =
plane standards are covered by the stated control plane requirements.  =
Some references should be supplied.  In any case, the labeling and =
forwarding behavior should be defined by these referenced standards, not =
by GMPLS.
=20
(I am assuming definition of new data plane standards is out of scope =
for CCAMP.)
=20
Regards,
Ben

  _____ =20

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Adrian Farrel
Sent: Friday, July 22, 2005 8:37 AM
To: P=E4r Mattsson; Loa Andersson
Cc: [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

Hi,
=20
It is always refreshing how engineers jump straight to a discussion of =
the solution :-)
=20
Perhaps we can assume that the framework draft is a good representation =
of the problem space, and that we are ready to start discussing the =
solutions.
=20
One (perhaps the only?) significant question to answer is how the frames =
will be labelled. This question is one we must come to as soon as we are =
confident that the requirements need to be addressed at all.
=20
As has been pointed out, there are several possibilities and to pick =
from these we need to understand:
1. Do we need to support explicit label stacking?
   Note that this is not supported in TDM, LSC or FSC.
2. Do we need to be able to control (perhaps through an
   external signaling controller) existing hardware and=20
   install LSPs through existing networks?
3. Do we need to support existing function simultaneous to
   the support of GMPLS L2 LSPs?
=20
I think that from a chair's perspective I can give some limited =
guidance.
=20
A. These questions must be raised and answered in the framework I-D
B. The answer to question 3 is "yes". This means that the use of labels
   must not significantly deplete any namespace used to support other
   function.
C. CCAMP is chartered to look at the control of transport networks. This
   includes Metro, but I am unsure about Campus. It does not cover=20
   signaling to the desktop.
=20
Thanks,
Adrian
=20
----- Original Message -----=20
From: "P=E4r Mattsson" < <mailto:[email-masked]> [email-masked]>
To: "Loa Andersson" < <mailto:[email-masked]> [email-masked]>
Cc: < <mailto:[email-masked]> [email-masked]>
Sent: Friday, July 22, 2005 11:41 AM
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

> > Per and Dimitri,
> >
> > I would like to come down stronger than that, for me it is
> > a very strong requirement that the same switch can handle
> > both VLANs and GMPLs trafic correctly. I can't dsee how that
> > could be done if using the VLAN tpid to indicate GMPLS
> > traffic.
>=20
> If you ever want that same switch to handle traffic for a directly
> connected  host (not to uncommen) you would want that to use normal
> ethernet macaddress switching. So of course you do not want to have to
> choose between vlan and gmpls, you would want both at the same time.
>=20
> /per
>=20
>=20
> >
> > /Loa
> >
> > P=E4r Mattsson wrote:
> >>>hi par, one of the possibilities that has been considered to cope =
with
> >>>this requirement is to use a dedicated TPID for the Ethernet =
labeled
> >>>frames; this would allow differentiated processing with non-labeled
> >>>framesthanks.
> >>
> >>
> >> That seems to make more sence. If that frame is to be sized like a
> >> 802.1q
> >> frame. There is not that much space left to a label. Or is the =
demand to
> >> use jumboframes ?
> >> Has there been any discussion on labelstacking, and mainly where to
> >> place
> >> the information?
> >>
> >> Regards.
> >> Per
> >>
> >>
> >>
> >
> >
> > --
> > Loa Andersson
> >
> > Principal Networking Architect
> > Acreo AB                           phone:  +46 8 632 77 14
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > Kista, Sweden                      email:   =
<mailto:[email-masked]> [email-masked]
> >                                              <mailto:[email-masked]> =
[email-masked]
>=20
>=20
>=20
>=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C58EF9.9504EFFA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D100240018-22072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>And you are so right on this Igor.&nbsp; The nice thing about =
the co-cs=20
mode is that the data-plane has not been defined here and works =
great.&nbsp;=20
Adding a (forced) OOB control-plane is not a big deal.....in fact as we =
move to=20
the duct the control-plane is of much lesser interest/importance (this =
is not to=20
belittle it, its just a fact)&nbsp;&nbsp; Where the data-plane has been =
defined=20
however, for the co-ps mode in MPLS and the PW stuff its unfortunately =
spawned,=20
it's (how shall I put this politely) 'not so great'.&nbsp; Can I make a =
plea NOT=20
to screw-up ethernet by attempting to replicate MPLS....in any case the =
ethernet=20
data-plane belongs to IEEE.&nbsp; I would advise folks here to leave =
this well=20
alone.</FONT></SPAN></DIV>
<DIV><SPAN class=3D100240018-22072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D100240018-22072005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
  </B>Igor Bryskin<BR><B>Sent:</B> 22 July 2005 16:11<BR><B>To:</B> =
Mack-Crane,=20
  T. Benjamin; Adrian Farrel; P=E4r Mattsson; Loa =
Andersson<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> Re: Frameformat in a l2cs gmpls=20
  rnvironment.<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I think Ben and Juergen have a point =
here. There=20
  is nothing that could be dynamically provisioned that could not be =
also=20
  provisioned by management. In other words data plane is the King here. =
We need=20
  data plane standard(s) on how we encode a label, whether we need a =
label stack=20
  or not, how the labeled traffic is supposed to be&nbsp;treated, how =
labeled=20
  traffic co-exist with non-label traffic, etc. This is something that =
not for=20
  CCAMP to define. Take for example TDM networks. GMPLS only provides a =
way to=20
  dynamically provision G.707 networks. Hence there is a need in =
parallel=20
  standardization activities in ITU. Only after that we can discuss how =
all that=20
  could be dynamically provisioned, that is the aspects of control =
plane.=20
  </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Igor</FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=[email-masked]=20
    href=3D"mailto:[email-masked]">Mack-Crane, T. =
Benjamin</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
    href=3D"mailto:[email-masked]">Adrian Farrel</A> ; <A =
title=[email-masked]=20
    href=3D"mailto:[email-masked]">P=E4r Mattsson</A> ; <A =
title=[email-masked]=20
    href=3D"mailto:[email-masked]">Loa Andersson</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
    href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, July 22, 2005 =
10:23=20
    AM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Frameformat in a =
l2cs=20
    gmpls rnvironment.</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>I think Juergen has raised an important =
question.&nbsp;=20
    How frames are labeled (and the related data plane forwarding =
behavior) is=20
    not defined by the control plane.&nbsp; The control plane serves to=20
    provision the data plane, not define it.&nbsp; In the framework =
draft it is=20
    not clear what data plane standards are covered by the stated =
control plane=20
    requirements.&nbsp; Some references should be supplied.&nbsp; In any =
case,=20
    the labeling and forwarding behavior should be defined&nbsp;by these =

    referenced standards, not&nbsp;by GMPLS.</FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>(I am assuming definition of new data plane =
standards=20
    is out of scope for CCAMP.)</FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>Ben</FONT></SPAN></DIV><BR>
    <BLOCKQUOTE=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
      <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
      <HR tabIndex=3D-1>
      <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =

      [mailto:[email-masked]] <B>On Behalf Of </B>Adrian=20
      Farrel<BR><B>Sent:</B> Friday, July 22, 2005 8:37 AM<BR><B>To:</B> =
P=E4r=20
      Mattsson; Loa Andersson<BR><B>Cc:</B>=20
      [email-masked]<BR><B>Subject:</B> Re: Frameformat in a l2cs =
gmpls=20
      rnvironment.<BR></FONT><BR></DIV>
      <DIV></DIV>
      <DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DCourier size=3D2>It is always refreshing how =
engineers jump=20
      straight to a discussion of the solution :-)</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DCourier size=3D2>Perhaps we can assume that the =
framework=20
      draft is a good representation of the problem space, and that we =
are ready=20
      to start discussing the solutions.</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DCourier size=3D2>One (perhaps the only?) =
significant=20
      question to answer is how the frames will be labelled. This =
question is=20
      one we must come to as soon as we are confident that the =
requirements need=20
      to be addressed at all.</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DCourier size=3D2>As has been pointed out, there =
are several=20
      possibilities and to pick from these we need to =
understand:</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>1. Do we need to support =
explicit label=20
      stacking?</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Note that this is =
not=20
      supported in TDM, LSC or FSC.</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>2. Do we need to be able to =
control=20
      (perhaps through an</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;external =
signaling=20
      controller) existing hardware and </FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; install LSPs =
through existing=20
      networks?</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>3. Do we need to support =
existing function=20
      simultaneous to</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; the support of =
GMPLS L2=20
      LSPs?</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DCourier size=3D2>I think that from a chair's =
perspective I=20
      can give some limited guidance.</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DCourier size=3D2>A. These questions must be =
raised and=20
      answered in the framework I-D</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>B. The answer to question 3 is =
"yes". This=20
      means that the use of labels</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; must not =
significantly deplete=20
      any namespace used to support other</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; =
function.</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>C. CCAMP is chartered to look =
at the=20
      control of transport networks. This</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;includes =
Metro, but I am=20
      unsure about Campus. It does not&nbsp;cover </FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; signaling to the=20
      desktop.</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
      <DIV><FONT face=3DCourier size=3D2>----- Original Message ----- =
</FONT>
      <DIV><FONT face=3DCourier size=3D2>From: "P=E4r Mattsson" =
&lt;</FONT><A=20
      href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
      size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>To: "Loa Andersson" =
&lt;</FONT><A=20
      href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
      size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>Cc: &lt;</FONT><A=20
      href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
      size=3D2>[email-masked]</FONT></A><FONT face=3DCourier=20
      size=3D2>&gt;</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>Sent: Friday, July 22, 2005 =
11:41=20
      AM</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>Subject: Re: Frameformat in a =
l2cs gmpls=20
      rnvironment.</FONT></DIV></DIV>
      <DIV><FONT face=3DCourier><BR><FONT =
size=3D2></FONT></FONT></DIV><FONT=20
      face=3DCourier size=3D2>&gt; &gt; Per and Dimitri,<BR>&gt; =
&gt;<BR>&gt; &gt; I=20
      would like to come down stronger than that, for me it is<BR>&gt; =
&gt; a=20
      very strong requirement that the same switch can handle<BR>&gt; =
&gt; both=20
      VLANs and GMPLs trafic correctly. I can't dsee how that<BR>&gt; =
&gt; could=20
      be done if using the VLAN tpid to indicate GMPLS<BR>&gt; &gt;=20
      traffic.<BR>&gt; <BR>&gt; If you ever want that same switch to =
handle=20
      traffic for a directly<BR>&gt; connected&nbsp; host (not to =
uncommen) you=20
      would want that to use normal<BR>&gt; ethernet macaddress =
switching. So of=20
      course you do not want to have to<BR>&gt; choose between vlan and =
gmpls,=20
      you would want both at the same time.<BR>&gt; <BR>&gt; =
/per<BR>&gt;=20
      <BR>&gt; <BR>&gt; &gt;<BR>&gt; &gt; /Loa<BR>&gt; &gt;<BR>&gt; &gt; =
P=E4r=20
      Mattsson wrote:<BR>&gt; &gt;&gt;&gt;hi par, one of the =
possibilities that=20
      has been considered to cope with<BR>&gt; &gt;&gt;&gt;this =
requirement is=20
      to use a dedicated TPID for the Ethernet labeled<BR>&gt;=20
      &gt;&gt;&gt;frames; this would allow differentiated processing =
with=20
      non-labeled<BR>&gt; &gt;&gt;&gt;framesthanks.<BR>&gt; =
&gt;&gt;<BR>&gt;=20
      &gt;&gt;<BR>&gt; &gt;&gt; That seems to make more sence. If that =
frame is=20
      to be sized like a<BR>&gt; &gt;&gt; 802.1q<BR>&gt; &gt;&gt; frame. =
There=20
      is not that much space left to a label. Or is the demand =
to<BR>&gt;=20
      &gt;&gt; use jumboframes ?<BR>&gt; &gt;&gt; Has there been any =
discussion=20
      on labelstacking, and mainly where to<BR>&gt; &gt;&gt; =
place<BR>&gt;=20
      &gt;&gt; the information?<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;=20
      Regards.<BR>&gt; &gt;&gt; Per<BR>&gt; &gt;&gt;<BR>&gt; =
&gt;&gt;<BR>&gt;=20
      &gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; --<BR>&gt; &gt; =
Loa=20
      Andersson<BR>&gt; &gt;<BR>&gt; &gt; Principal Networking =
Architect<BR>&gt;=20
      &gt; Acreo=20
      =
AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
      phone:&nbsp; +46 8 632 77 14<BR>&gt; &gt; Isafjordsgatan=20
      =
22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      mobile: +46 739 81 21 64<BR>&gt; &gt; Kista,=20
      =
Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      email:&nbsp; </FONT><A =
href=3D"mailto:[email-masked]"><FONT=20
      face=3DCourier size=3D2>[email-masked]</FONT></A><BR><FONT =

      face=3DCourier size=3D2>&gt;=20
      =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      </FONT><A href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
      size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt; &gt;<BR>&gt;=20
      <BR>&gt; <BR>&gt; <BR>&gt; =
</FONT></BLOCKQUOTE><PRE>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C58EF9.9504EFFA--

Delivery-date: Fri, 22 Jul 2005 20:13:42 +0000
Content-class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 21:11:45 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Adrian....with an operators hat on ;-)

Yes, you are right on most points here....few remarks in-(snipped)line:

> > BMC=3D> How frames are labeled (and the related data plane =
forwarding
> > behavior)
> is
> > not defined by the control plane.
>=20
> AF=3D> It is true to say that this is not defined by the control =
plane.=20
> Nevertheless, the control plane passes labels around and it is=20
> important to define how those labels will be interpreted. I refer you=20
> to all of the non-packet labeling mechanisms already defined: you will

> see that they do not define how the data is labeled, but they do=20
> define how the signaled label maps to the labeled data.
NH=3D> Largely right Adrian....but on a wider note, I wish (and goodness
knows how I wish, esp in MPLS/PWE3) we had a stronger understanding of
func arch and the 3 networking modes.  It is the very nature of the
co-cs mode's 'label' that is key here, ie folks can't abuse this mode as
the nature of label means it's self-protecting to a large degree (I'll
ignore the 'topology on the fly' folks who quite clearly live in their
own world).  And remember a label is something that affects the
client->server layer adaptation, BUT it is essentially owned/defined by
the server layer and not the client.  But all this labelling stuff is
traffic data-plane oriented and has nothing to do with the
control-plane.  As Igor put it recently, the data-plane is King....and
indeed its is, the control-plane is merely there to serve it.

The role/significance of the control plane itself also changes in the 3
modes.  In the cl-ps mode it is 'almost everything' (well distributed
routing is THE issue here) but when we get down to SDH/OTNs and the
co-cs mode its not so important.  Here it's the management-plane that
dominates everything, even IF there is a control-plane...and then its
really mainly signalling.

It's the co-ps mode that is the odd-man out.  Let me point out that MPLS
DOES define a new data-plane (so its not like GMPLS at all)....and its
from an examination of THAT data-plane structure/behaviour that one
uncovers a host of problems.  I'll spare you a lengthy discourse on the
topic but I think/hope most folks should grasp what I mean by this.
>=20
> > BMC=3D>The control plane serves to provision the data plane, not=20
> > define it.
>=20
> AF=3D>Yes.
NH=3D> Exactly.
>=20
> > BMC=3D>In the framework draft it is not clear what data plane
> standards are
> > covered by the stated control plane requirements. Some references
> > should be supplied.
>=20
> AF=3D>Such text would not be welcomed by the chairs who
> specifically instructed it to be left out.
NH=3D> They are wise IMO....don't screw-up the data-plane.  Take a leaf
from where this has been defined for the co-ps mode (ie MPLS/PWs)......I
don't think the results are that good (understatement).

> > BMC=3D>(I am assuming definition of new data plane standards is=20
> out of scope
> for
> > CCAMP.)
>=20
> AF=3D>Are you?
>=20
> I would be surprised if this work introduced new data plane standards.
NH=3D> I would be horrified based on past experience....leave the
data-plane which has been defined elsewhere alone please.

regards, Neil
>=20
> Thanks,
> Adrian
>=20
>=20
>=20

Delivery-date: Fri, 22 Jul 2005 19:02:18 +0000
To: "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: "Igor Bryskin" <[email-masked]>, <[email-masked]>, "Adrian Farrel" <[email-masked]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>, "Loa Andersson" <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 21:01:02 +0200

Delivery-date: Fri, 22 Jul 2005 18:28:24 +0000
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, "Adrian Farrel" <[email-masked]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>, "Loa Andersson" <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 20:27:34 +0200

Delivery-date: Fri, 22 Jul 2005 18:27:45 +0000
Content-class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 13:25:06 -0500
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>, "Loa Andersson" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58EEA.DBC1A8EF
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Igor,
=20
I, too, am baffled by the notion of requirements for control of an unspecif=
ied data plane.
=20
Regards,
Ben

________________________________

	From: Igor Bryskin [mailto:[email-masked]]=20
	Sent: Friday, July 22, 2005 12:20 PM
	To: [email-masked]
	Cc: Mack-Crane, T. Benjamin; Adrian Farrel; P=E4r Mattsson; Loa Andersson;=
 [email-masked]
	Subject: Re: Frameformat in a l2cs gmpls rnvironment.
=09
=09
	Dimitri,
	=20
	The question is simple: is it possible today to statically provision L2LSP=
s that could, say, support e2e QoS? If not, may be it is to early to discus=
s aspects of dynamic provisioning of such LSPs? Is it possible/reasonable, =
in your opinion, to "detail how forwarding information can be exchanged via=
 the control plane (and then installed)" without having in mind "a specific=
 forwarding behavior"?
	How do you know which forwarding information is needed for the forwarding =
nobody has defined yet?
	The other question is do we need at all e2e QoS, route control, fast recov=
ery? Sounds like exciting idea, but does all that commercially make sense? =
So, I guess, we need two things before we can move forward:
	a) validation of the idea by the providers;
	b) definition of the data plane behavior;
	=20
	Igor

		----- Original Message -----=20
		From: [email-masked]=20
		To: Igor Bryskin <mailto:[email-masked]> =20
		Cc: Mack-Crane, T. Benjamin <mailto:[email-masked]>  ; Adrian=
 Farrel <mailto:[email-masked]>  ; P=E4r Mattsson <mailto:[email-masked]=
e>  ; Loa Andersson <mailto:[email-masked]>  ; [email-masked]=20
		Sent: Friday, July 22, 2005 12:21 PM
		Subject: Re: Frameformat in a l2cs gmpls rnvironment.
	=09
	=09

		igor - i am not sure which point they exactly have - the purpose of this =
document is to detail how forwarding information can be exchanged via the c=
ontrol plane (and then installed) not to define a specific forwarding behav=
iour

		thanks,

		- dimitri.
	=09
		"Igor Bryskin" <[email-masked]>
		Sent by: [email-masked]
		07/22/2005 11:10 AST
	=09
		To: "Mack-Crane, T. Benjamin" <[email-masked]>, "Adrian Farre=
l" <[email-masked]>, P=E4r Mattsson <[email-masked]>, "Loa Andersson" <=
[email-masked]>
		cc: <[email-masked]>
		bcc:=20
		Subject: Re: Frameformat in a l2cs gmpls rnvironment.
	=09
	=09
	=09

		Hi,
	=09
		I think Ben and Juergen have a point here. There is nothing that could be=
 dynamically provisioned that could not be also provisioned by management. =
In other words data plane is the King here. We need data plane standard(s) =
on how we encode a label, whether we need a label stack or not, how the lab=
eled traffic is supposed to be treated, how labeled traffic co-exist with n=
on-label traffic, etc. This is something that not for CCAMP to define. Take=
 for example TDM networks. GMPLS only provides a way to dynamically provisi=
on G.707 networks. Hence there is a need in parallel standardization activi=
ties in ITU. Only after that we can discuss how all that could be dynamical=
ly provisioned, that is the aspects of control plane.=20
	=09
		Igor
		----- Original Message -----=20
		From: Mack-Crane, T. Benjamin <mailto:[email-masked]> =20
		To: Adrian Farrel <mailto:[email-masked]>  ; P=E4r Mattsson <mailto:=
[email-masked]>  ; Loa Andersson <mailto:[email-masked]> =20
		Cc: [email-masked]=20
		Sent: Friday, July 22, 2005 10:23 AM
		Subject: RE: Frameformat in a l2cs gmpls rnvironment.
	=09
		Hi,
	=09
		I think Juergen has raised an important question.  How frames are labeled=
 (and the related data plane forwarding behavior) is not defined by the con=
trol plane.  The control plane serves to provision the data plane, not defi=
ne it.  In the framework draft it is not clear what data plane standards ar=
e covered by the stated control plane requirements.  Some references should=
 be supplied.  In any case, the labeling and forwarding behavior should be =
defined by these referenced standards, not by GMPLS.
	=09
		(I am assuming definition of new data plane standards is out of scope for=
 CCAMP.)
	=09
		Regards,
		Ben
	=09
________________________________

	=09
		From: [email-masked] [mailto:[email-masked]] On Behal=
f Of Adrian Farrel
		Sent: Friday, July 22, 2005 8:37 AM
		To: P=E4r Mattsson; Loa Andersson
		Cc: [email-masked]
		Subject: Re: Frameformat in a l2cs gmpls rnvironment.
	=09
		Hi,
	=09
		It is always refreshing how engineers jump straight to a discussion of th=
e solution :-)
	=09
		Perhaps we can assume that the framework draft is a good representation o=
f the problem space, and that we are ready to start discussing the solution=
s=2E
	=09
		One (perhaps the only?) significant question to answer is how the frames =
will be labelled. This question is one we must come to as soon as we are co=
nfident that the requirements need to be addressed at all.
	=09
		As has been pointed out, there are several possibilities and to pick from=
 these we need to understand:
		1. Do we need to support explicit label stacking?
		   Note that this is not supported in TDM, LSC or FSC.
		2. Do we need to be able to control (perhaps through an
		   external signaling controller) existing hardware and=20
		   install LSPs through existing networks?
		3. Do we need to support existing function simultaneous to
		   the support of GMPLS L2 LSPs?
	=09
		I think that from a chair's perspective I can give some limited guidance.
	=09
		A. These questions must be raised and answered in the framework I-D
		B. The answer to question 3 is "yes". This means that the use of labels
		   must not significantly deplete any namespace used to support other
		   function.
		C. CCAMP is chartered to look at the control of transport networks. This
		   includes Metro, but I am unsure about Campus. It does not cover=20
		   signaling to the desktop.
	=09
		Thanks,
		Adrian
	=09
		----- Original Message -----=20
		From: "P=E4r Mattsson" <[email-masked]>
		To: "Loa Andersson" <[email-masked]>
		Cc: <[email-masked]>
		Sent: Friday, July 22, 2005 11:41 AM
		Subject: Re: Frameformat in a l2cs gmpls rnvironment.
	=09
	=09
		> > Per and Dimitri,
		> >
		> > I would like to come down stronger than that, for me it is
		> > a very strong requirement that the same switch can handle
		> > both VLANs and GMPLs trafic correctly. I can't dsee how that
		> > could be done if using the VLAN tpid to indicate GMPLS
		> > traffic.
		>=20
		> If you ever want that same switch to handle traffic for a directly
		> connected  host (not to uncommen) you would want that to use normal
		> ethernet macaddress switching. So of course you do not want to have to
		> choose between vlan and gmpls, you would want both at the same time.
		>=20
		> /per
		>=20
		>=20
		> >
		> > /Loa
		> >
		> > P=E4r Mattsson wrote:
		> >>>hi par, one of the possibilities that has been considered to cope wi=
th
		> >>>this requirement is to use a dedicated TPID for the Ethernet labeled
		> >>>frames; this would allow differentiated processing with non-labeled
		> >>>framesthanks.
		> >>
		> >>
		> >> That seems to make more sence. If that frame is to be sized like a
		> >> 802.1q
		> >> frame. There is not that much space left to a label. Or is the deman=
d to
		> >> use jumboframes ?
		> >> Has there been any discussion on labelstacking, and mainly where to
		> >> place
		> >> the information?
		> >>
		> >> Regards.
		> >> Per
		> >>
		> >>
		> >>
		> >
		> >
		> > --
		> > Loa Andersson
		> >
		> > Principal Networking Architect
		> > Acreo AB                           phone:  +46 8 632 77 14
		> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
		> > Kista, Sweden                      email:  [email-masked]
		> >                                             [email-masked]
		> >
		>=20
		>=20
		>=20
		>=20
	=09
		=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
		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
		=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
	=09

	=09

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C58EEA.DBC1A8EF
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D935282018-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Igor,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D935282018-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D935282018-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>I, too, am baffled by the notion of requirements f=
or=20
control of an unspecified data plane.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D935282018-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D935282018-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D935282018-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Ben</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli=
d; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Igor Bryskin [mailto:ibryskin@m=
ovaz.com]=20
  <BR><B>Sent:</B> Friday, July 22, 2005 12:20 PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Cc:</B> Mack-Crane, T. Benjamin; A=
drian=20
  Farrel; P=E4r Mattsson; Loa Andersson; [email-masked]<BR><B>Subject:<=
/B> Re:=20
  Frameformat in a l2cs gmpls rnvironment.<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial size=3D2>Dimitri,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>The question is simple: is it possible t=
oday to=20
  statically provision L2LSPs that could, say,&nbsp;support e2e QoS? If not=
, may=20
  be it is to early to discuss aspects of dynamic provisioning of such LSPs=
? Is=20
  it possible/reasonable, in your opinion, to "<FONT face=3D"Courier New"=20
  size=3D3>detail how forwarding information can be exchanged via the contr=
ol=20
  plane (and then installed)" without&nbsp;having in mind "a specific forwa=
rding=20
  behavior"?</FONT></FONT></DIV>
  <DIV><FONT face=3D"Courier New">How do you know which forwarding informat=
ion is=20
  needed for the forwarding nobody has defined yet?</FONT></DIV>
  <DIV><FONT face=3D"Courier New">The other question is&nbsp;do we need at =
all e2e=20
  QoS, route control, fast recovery? Sounds like exciting idea, but does al=
l=20
  that commercially make sense? So, I guess, we need two things&nbsp;before=
 we=20
  can&nbsp;move forward:</FONT></DIV>
  <DIV><FONT face=3D"Courier New">a) validation of the idea by the=20
  providers;</FONT></DIV>
  <DIV><FONT face=3D"Courier New">b) definition of the data plane=20
  behavior;</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New">Igor</FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-=
LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>F=
rom:</B>=20
    <A title=[email-masked]=20
    href=3D"mailto:[email-masked]">Dimitri.Papadimitriou@=
alcatel.be</A>=20
    </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=[email-masked]=
m=20
    href=3D"mailto:[email-masked]">Igor Bryskin</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A title=3DBen.Mack-Crane@te=
llabs.com=20
    href=3D"mailto:[email-masked]">Mack-Crane, T. Benjamin</A> =
; <A=20
    title=[email-masked] href=3D"mailto:[email-masked]">Adrian=20
    Farrel</A> ; <A title=[email-masked] href=3D"mailto:[email-masked]">P=
=E4r=20
    Mattsson</A> ; <A title=[email-masked] href=3D"mailto:[email-masked]">Loa Ander=
sson</A>=20
    ; <A title=[email-masked]=20
    href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, July 22, 2005 12:2=
1=20
    PM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Frameformat in a l2=
cs=20
    gmpls rnvironment.</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>
    <P><FONT face=3DMonospace,Courier>igor - i am not sure which point they=20
    exactly have - the purpose of this document is to detail how forwarding=20

    information can be exchanged via the control plane (and then installed)=
 not=20
    to define a specific forwarding behaviour</FONT></P>
    <P><FONT face=3DMonospace,Courier>thanks,</FONT></P>
    <P><FONT face=3DMonospace,Courier>- dimitri.</FONT><BR><BR><FONT=20
    size=3D2><B>"Igor Bryskin" &lt;<A=20
    href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</B></FONT=
><BR><FONT=20
    size=3D2>Sent by: <A=20
    href=3D"mailto:[email-masked]">[email-masked]</A></=
FONT><BR><FONT=20
    size=3D2>07/22/2005 11:10 AST</FONT><BR><BR><FONT size=3D2>To:</FONT> <=
FONT=20
    size=3D2>"Mack-Crane, T. Benjamin" &lt;<A=20
    href=3D"mailto:[email-masked]">[email-masked]</=
A>&gt;,=20
    "Adrian Farrel" &lt;<A=20
    href=3D"mailto:[email-masked]">[email-masked]</A>&gt;, P=E4r =
Mattsson=20
    &lt;<A href=3D"mailto:[email-masked]">[email-masked]</A>&gt;, "Loa Anders=
son"=20
    &lt;<A href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FONT><BR><FONT=20
    size=3D2>cc:</FONT> <FONT size=3D2>&lt;<A=20
    href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FONT><BR=
><FONT=20
    size=3D2>bcc:</FONT> <BR><FONT size=3D2>Subject:</FONT> <FONT size=3D2>=
Re:=20
    Frameformat in a l2cs gmpls rnvironment.</FONT><BR><BR><BR></P>
    <P>Hi,<BR><BR>I think Ben and Juergen have a point here. There is nothi=
ng=20
    that could be dynamically provisioned that could not be also provisione=
d by=20
    management. In other words data plane is the King here. We need data pl=
ane=20
    standard(s) on how we encode a label, whether we need a label stack or =
not,=20
    how the labeled traffic is supposed to be&nbsp;treated, how labeled tra=
ffic=20
    co-exist with non-label traffic, etc. This is something that not for CC=
AMP=20
    to define. Take for example TDM networks. GMPLS only provides a way to=20
    dynamically provision G.707 networks. Hence there is a need in parallel=20
    standardization activities in ITU. Only after that we can discuss how a=
ll=20
    that could be dynamically provisioned, that is the aspects of control p=
lane.=20
    <BR><BR>Igor<BR><FONT size=3D4>----- Original Message ----- </FONT><BR>=
<FONT=20
    size=3D4><B>From:</B> </FONT><FONT color=3Dblue size=3D4><U><A=20
    href=3D"mailto:[email-masked]">Mack-Crane, T.=20
    Benjamin</A></U></FONT><FONT color=3Dblack size=3D4> </FONT><BR><FONT=20
    size=3D4><B>To:</B> </FONT><FONT color=3Dblue size=3D4><U><A=20
    href=3D"mailto:[email-masked]">Adrian Farrel</A></U></FONT><FONT=20
    color=3Dblack size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A=20
    href=3D"mailto:[email-masked]">P=E4r Mattsson</A></U></FONT><FONT color=
=3Dblack=20
    size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A href=3D"mailto:loa=
@pi.se">Loa=20
    Andersson</A></U></FONT><FONT color=3Dblack size=3D4> </FONT><BR><FONT=20
    size=3D4><B>Cc:</B> </FONT><FONT color=3Dblue size=3D4><U><A=20
    href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FO=
NT=20
    color=3Dblack size=3D4> </FONT><BR><FONT size=3D4><B>Sent:</B> Friday, =
July 22,=20
    2005 10:23 AM</FONT><BR><FONT size=3D4><B>Subject:</B> RE: Frameformat =
in a=20
    l2cs gmpls rnvironment.</FONT><BR><BR>Hi,<BR><BR>I think Juergen has ra=
ised=20
    an important question.&nbsp; How frames are labeled (and the related da=
ta=20
    plane forwarding behavior) is not defined by the control plane.&nbsp; T=
he=20
    control plane serves to provision the data plane, not define it.&nbsp; =
In=20
    the framework draft it is not clear what data plane standards are cover=
ed by=20
    the stated control plane requirements.&nbsp; Some references should be=20
    supplied.&nbsp; In any case, the labeling and forwarding behavior shoul=
d be=20
    defined&nbsp;by these referenced standards, not&nbsp;by GMPLS.<BR><BR>(=
I am=20
    assuming definition of new data plane standards is out of scope for=20
    CCAMP.)<BR><BR>Regards,<BR>Ben<BR>
    <HR align=3Dleft width=3D"99%" SIZE=3D4>
    <FONT color=3Dblack><BR><B>From:</B> [email-masked]=20
    [mailto:[email-masked]] <B>On Behalf Of </B>Adrian=20
    Farrel<BR><B>Sent:</B> Friday, July 22, 2005 8:37 AM<BR><B>To:</B> P=E4=
r=20
    Mattsson; Loa Andersson<BR><B>Cc:</B> [email-masked]<BR><B>Subject:=
</B>=20
    Re: Frameformat in a l2cs gmpls rnvironment.<BR><BR>Hi,<BR><BR>It is al=
ways=20
    refreshing how engineers jump straight to a discussion of the solution=20
    :-)<BR><BR>Perhaps we can assume that the framework draft is a good=20
    representation of the problem space, and that we are ready to start=20
    discussing the solutions.<BR><BR>One (perhaps the only?) significant=20
    question to answer is how the frames will be labelled. This question is=
 one=20
    we must come to as soon as we are confident that the requirements need =
to be=20
    addressed at all.<BR><BR>As has been pointed out, there are several=20
    possibilities and to pick from these we need to understand:<BR>1. Do we=
 need=20
    to support explicit label stacking?<BR>&nbsp;&nbsp; Note that this is n=
ot=20
    supported in TDM, LSC or FSC.<BR>2. Do we need to be able to control=20
    (perhaps through an<BR>&nbsp;&nbsp;&nbsp;external signaling controller)=20
    existing hardware and <BR>&nbsp;&nbsp; install LSPs through existing=20
    networks?<BR>3. Do we need to support existing function simultaneous=20
    to<BR>&nbsp;&nbsp; the support of GMPLS L2 LSPs?<BR><BR>I think that fr=
om a=20
    chair's perspective I can give some limited guidance.<BR><BR>A. These=20
    questions must be raised and answered in the framework I-D<BR>B. The an=
swer=20
    to question 3 is "yes". This means that the use of labels<BR>&nbsp;&nbs=
p;=20
    must not significantly deplete any namespace used to support=20
    other<BR>&nbsp;&nbsp; function.<BR>C. CCAMP is chartered to look at the=20
    control of transport networks. This<BR>&nbsp;&nbsp;&nbsp;includes Metro=
, but=20
    I am unsure about Campus. It does not&nbsp;cover <BR>&nbsp;&nbsp; signa=
ling=20
    to the desktop.<BR><BR>Thanks,<BR>Adrian<BR><BR>----- Original Message =
-----=20
    <BR>From: "P=E4r Mattsson" &lt;</FONT><FONT color=3Dblue><U><A=20
    href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT=20
    color=3Dblack>&gt;<BR>To: "Loa Andersson" &lt;</FONT><FONT color=3Dblue=
><U><A=20
    href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT=20
    color=3Dblack>&gt;<BR>Cc: &lt;</FONT><FONT color=3Dblue><U><A=20
    href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FO=
NT=20
    color=3Dblack>&gt;<BR>Sent: Friday, July 22, 2005 11:41 AM<BR>Subject: =
Re:=20
    Frameformat in a l2cs gmpls rnvironment.<BR><BR><BR>&gt; &gt; Per and=20
    Dimitri,<BR>&gt; &gt;<BR>&gt; &gt; I would like to come down stronger t=
han=20
    that, for me it is<BR>&gt; &gt; a very strong requirement that the same=20
    switch can handle<BR>&gt; &gt; both VLANs and GMPLs trafic correctly. I=20
    can't dsee how that<BR>&gt; &gt; could be done if using the VLAN tpid t=
o=20
    indicate GMPLS<BR>&gt; &gt; traffic.<BR>&gt; <BR>&gt; If you ever want =
that=20
    same switch to handle traffic for a directly<BR>&gt; connected&nbsp; ho=
st=20
    (not to uncommen) you would want that to use normal<BR>&gt; ethernet=20
    macaddress switching. So of course you do not want to have to<BR>&gt; c=
hoose=20
    between vlan and gmpls, you would want both at the same time.<BR>&gt;=20
    <BR>&gt; /per<BR>&gt; <BR>&gt; <BR>&gt; &gt;<BR>&gt; &gt; /Loa<BR>&gt;=20
    &gt;<BR>&gt; &gt; P=E4r Mattsson wrote:<BR>&gt; &gt;&gt;&gt;hi par, one=
 of the=20
    possibilities that has been considered to cope with<BR>&gt; &gt;&gt;&gt=
;this=20
    requirement is to use a dedicated TPID for the Ethernet labeled<BR>&gt;=20
    &gt;&gt;&gt;frames; this would allow differentiated processing with=20
    non-labeled<BR>&gt; &gt;&gt;&gt;framesthanks.<BR>&gt; &gt;&gt;<BR>&gt;=20
    &gt;&gt;<BR>&gt; &gt;&gt; That seems to make more sence. If that frame =
is to=20
    be sized like a<BR>&gt; &gt;&gt; 802.1q<BR>&gt; &gt;&gt; frame. There i=
s not=20
    that much space left to a label. Or is the demand to<BR>&gt; &gt;&gt; u=
se=20
    jumboframes ?<BR>&gt; &gt;&gt; Has there been any discussion on=20
    labelstacking, and mainly where to<BR>&gt; &gt;&gt; place<BR>&gt; &gt;&=
gt;=20
    the information?<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; Regards.<BR>&gt; &gt=
;&gt;=20
    Per<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;<BR>=
&gt;=20
    &gt;<BR>&gt; &gt; --<BR>&gt; &gt; Loa Andersson<BR>&gt; &gt;<BR>&gt; &g=
t;=20
    Principal Networking Architect<BR>&gt; &gt; Acreo=20
    AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
    phone:&nbsp; +46 8 632 77 14<BR>&gt; &gt; Isafjordsgatan=20
    22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    mobile: +46 739 81 21 64<BR>&gt; &gt; Kista,=20
    Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    email:&nbsp; </FONT><FONT color=3Dblue><U><A=20
    href=3D"mailto:[email-masked]">[email-masked]</A></U></=
FONT><FONT=20
    color=3Dblack><BR>&gt;=20
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    </FONT><FONT color=3Dblue><U><A=20
    href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT color=3Dblack><=
BR>&gt;=20
    &gt;<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR><BR></FONT><FONT=20
    face=3DMonospace,Courier=20
    size=3D4>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT><BR><FONT=20
    face=3DMonospace,Courier size=3D4>The information contained in this mes=
sage may=20
    be privileged</FONT><BR><FONT face=3DMonospace,Courier size=3D4>and con=
fidential=20
    and protected from disclosure. If the reader</FONT><BR><FONT=20
    face=3DMonospace,Courier size=3D4>of this message is not the intended r=
ecipient,=20
    or an employee</FONT><BR><FONT face=3DMonospace,Courier size=3D4>or age=
nt=20
    responsible for delivering this message to the</FONT><BR><FONT=20
    face=3DMonospace,Courier size=3D4>intended recipient, you are hereby no=
tified=20
    that any reproduction,</FONT><BR><FONT face=3DMonospace,Courier=20
    size=3D4>dissemination or distribution of this communication is=20
    strictly</FONT><BR><FONT face=3DMonospace,Courier size=3D4>prohibited. =
If you=20
    have received this communication in error,</FONT><BR><FONT=20
    face=3DMonospace,Courier size=3D4>please notify us immediately by reply=
ing to=20
    the message and</FONT><BR><FONT face=3DMonospace,Courier size=3D4>delet=
ing it=20
    from your computer. Thank you. Tellabs</FONT><BR><FONT=20
    face=3DMonospace,Courier=20
    size=3D4>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT><BR>
    <P></P></BLOCKQUOTE></BLOCKQUOTE><pre>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
</pre></BODY></HTML>

------_=_NextPart_001_01C58EEA.DBC1A8EF--

Delivery-date: Fri, 22 Jul 2005 18:12:35 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Fri, 22 Jul 2005 19:13:11 +0100

Whoa there!

GMPLS assumes an IP control plane.
I am aware that there is work afoot in other SDOs to assign a dedicated
VLAN tag to specify the control plane traffic. This is not what we are
doing.

As far as I am aware, everyone in the IETF is comfortable with the idea of
using IP packets to carry control plane data through an IP-enabled DCN. In
Ethernet the issue will be whether the control plane is in band (use IP
address and MAC address) or out of band (use distinct DCN).

The use of a separate VLAN ID to signify the control plane is out of scope
for CCAMP.

Thanks,
Adrian

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 22, 2005 4:33 PM
Subject: RE: Frameformat in a l2cs gmpls rnvironment.

Juergen,

Before you can use GMPLS to set up VLANs a data plane must first exist to
carry the GMPLS control plane traffic. Yes you can use the standard
Ethernet data plane for this purpose (and in fact must do so for the
solution to be viable), but its not as simple as that. You cannot assume
that just because two GMPLS peers are directly connected that they can
communicate with each other.

To exchange GMPLS control plane packets between a pair of GMPLS peers, the
peers will need to agree to use either untagged control packets or to tag
them with a common VLAN ID. The use of a separate VLAN for GMPLS control
traffic is analogous to using a separate VLAN for management traffic
today. If two switches belong to the same management VLAN then you can use
ICMP ping to verify connectivity between them. However, if one switch has
been put into the wrong management VLAN then the ping will obviously fail.

If you want to use a separate VLAN for GMPLS control plane traffic, then
you either need to (i) define a reserved GMPLS signalling VLAN ID, or (ii)
leave it up to the operator to choose a VLAN ID. If you leave it up to the
operator to decide what VLAN ID to use, then you need to consider what the
implications in the inter-operator case will be, i.e. what VLAN ID range
should be used for control plane traffic and what VLAN ID range should be
used for user plane traffic.

I'm not saying that defining how GMPLS control plane packets are forwarded
in the Ethernet data plane will be an issue, simply that this is something
that must be addressed to develop interoperable solutions.

Regards,
Richard

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Heiles Juergen
> Sent: 22 July 2005 14:17
> To: Loa Andersson; Pär Mattsson
> Cc: [email-masked]
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
>
>
> GMPLS for SONET/SDH has no impact on the SONET/SDH data
> plane. It introduces a control plane for connection setup
> instead of a network management based connection setup. GMPLS
> for Ethernet can work in the same way. Ethernet as such is
> cl, but VLANs are setup and GMPLS can provide a control plane
> for VLAN setup. The Ethernet data plane is not changed and
> MAC address learning and forwarding is still be done within a
> VLAN. So no change to the Ethernet data plane. No GMPLS
> traffic is introduced, it is still VLAN traffic.
> Introducing a dedicated GMPLS label for Ethernet (GMPLS
> traffic) goes beyond GMPLS as a control plane technique.
>
> Regards
>
> Juergen
>
>
>
>
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Loa Andersson
> > Sent: Friday, July 22, 2005 12:05 PM
> > To: Pär Mattsson
> > Cc: [email-masked]
> > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> >
> > Per and Dimitri,
> >
> > I would like to come down stronger than that, for me it is
> > a very strong requirement that the same switch can handle
> > both VLANs and GMPLs trafic correctly. I can't dsee how that
> > could be done if using the VLAN tpid to indicate GMPLS
> > traffic.
> >
> > /Loa
> >
> > Pär Mattsson wrote:
> > >>hi par, one of the possibilities that has been considered
> > to cope with
> > >>this requirement is to use a dedicated TPID for the
> Ethernet labeled
> > >>frames; this would allow differentiated processing with
> non-labeled
> > >>framesthanks.
> > >
> > >
> > > That seems to make more sence. If that frame is to be sized
> > like a 802.1q
> > > frame. There is not that much space left to a label. Or is
> > the demand to
> > > use jumboframes ?
> > > Has there been any discussion on labelstacking, and mainly
> > where to place
> > > the information?
> > >
> > > Regards.
> > > Per
> > >
> > >
> > >
> >
> >
> > -- 
> > Loa Andersson
> >
> > Principal Networking Architect
> > Acreo AB                           phone:  +46 8 632 77 14
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > Kista, Sweden                      email:  [email-masked]
> >                                             [email-masked]
> >
>
>

Delivery-date: Fri, 22 Jul 2005 17:21:21 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: "Mack-Crane, T. Benjamin" <[email-masked]>, "Adrian Farrel" <[email-masked]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>, "Loa Andersson" <[email-masked]>, <[email-masked]>
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 13:19:53 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_017C_01C58EC0.0C02EAF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dimitri,

The question is simple: is it possible today to statically provision =
L2LSPs that could, say, support e2e QoS? If not, may be it is to early =
to discuss aspects of dynamic provisioning of such LSPs? Is it =
possible/reasonable, in your opinion, to "detail how forwarding =
information can be exchanged via the control plane (and then installed)" =
without having in mind "a specific forwarding behavior"?
How do you know which forwarding information is needed for the =
forwarding nobody has defined yet?
The other question is do we need at all e2e QoS, route control, fast =
recovery? Sounds like exciting idea, but does all that commercially make =
sense? So, I guess, we need two things before we can move forward:
a) validation of the idea by the providers;
b) definition of the data plane behavior;

Igor
  ----- Original Message -----=20
  From: [email-masked]=20
  To: Igor Bryskin=20
  Cc: Mack-Crane, T. Benjamin ; Adrian Farrel ; P=E4r Mattsson ; Loa =
Andersson ; [email-masked]=20
  Sent: Friday, July 22, 2005 12:21 PM
  Subject: Re: Frameformat in a l2cs gmpls rnvironment.

  igor - i am not sure which point they exactly have - the purpose of =
this document is to detail how forwarding information can be exchanged =
via the control plane (and then installed) not to define a specific =
forwarding behaviour

  thanks,

  - dimitri.

  "Igor Bryskin" <[email-masked]>
  Sent by: [email-masked]
  07/22/2005 11:10 AST

  To: "Mack-Crane, T. Benjamin" <[email-masked]>, "Adrian =
Farrel" <[email-masked]>, P=E4r Mattsson <[email-masked]>, "Loa =
Andersson" <[email-masked]>
  cc: <[email-masked]>
  bcc:=20
  Subject: Re: Frameformat in a l2cs gmpls rnvironment.

  Hi,

  I think Ben and Juergen have a point here. There is nothing that could =
be dynamically provisioned that could not be also provisioned by =
management. In other words data plane is the King here. We need data =
plane standard(s) on how we encode a label, whether we need a label =
stack or not, how the labeled traffic is supposed to be treated, how =
labeled traffic co-exist with non-label traffic, etc. This is something =
that not for CCAMP to define. Take for example TDM networks. GMPLS only =
provides a way to dynamically provision G.707 networks. Hence there is a =
need in parallel standardization activities in ITU. Only after that we =
can discuss how all that could be dynamically provisioned, that is the =
aspects of control plane.=20

  Igor
  ----- Original Message -----=20
  From: Mack-Crane, T. Benjamin=20
  To: Adrian Farrel ; P=E4r Mattsson ; Loa Andersson=20
  Cc: [email-masked]=20
  Sent: Friday, July 22, 2005 10:23 AM
  Subject: RE: Frameformat in a l2cs gmpls rnvironment.

  Hi,

  I think Juergen has raised an important question.  How frames are =
labeled (and the related data plane forwarding behavior) is not defined =
by the control plane.  The control plane serves to provision the data =
plane, not define it.  In the framework draft it is not clear what data =
plane standards are covered by the stated control plane requirements.  =
Some references should be supplied.  In any case, the labeling and =
forwarding behavior should be defined by these referenced standards, not =
by GMPLS.

  (I am assuming definition of new data plane standards is out of scope =
for CCAMP.)

  Regards,
  Ben

-------------------------------------------------------------------------=
-----

  From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Adrian Farrel
  Sent: Friday, July 22, 2005 8:37 AM
  To: P=E4r Mattsson; Loa Andersson
  Cc: [email-masked]
  Subject: Re: Frameformat in a l2cs gmpls rnvironment.

  Hi,

  It is always refreshing how engineers jump straight to a discussion of =
the solution :-)

  Perhaps we can assume that the framework draft is a good =
representation of the problem space, and that we are ready to start =
discussing the solutions.

  One (perhaps the only?) significant question to answer is how the =
frames will be labelled. This question is one we must come to as soon as =
we are confident that the requirements need to be addressed at all.

  As has been pointed out, there are several possibilities and to pick =
from these we need to understand:
  1. Do we need to support explicit label stacking?
     Note that this is not supported in TDM, LSC or FSC.
  2. Do we need to be able to control (perhaps through an
     external signaling controller) existing hardware and=20
     install LSPs through existing networks?
  3. Do we need to support existing function simultaneous to
     the support of GMPLS L2 LSPs?

  I think that from a chair's perspective I can give some limited =
guidance.

  A. These questions must be raised and answered in the framework I-D
  B. The answer to question 3 is "yes". This means that the use of =
labels
     must not significantly deplete any namespace used to support other
     function.
  C. CCAMP is chartered to look at the control of transport networks. =
This
     includes Metro, but I am unsure about Campus. It does not cover=20
     signaling to the desktop.

  Thanks,
  Adrian

  ----- Original Message -----=20
  From: "P=E4r Mattsson" <[email-masked]>
  To: "Loa Andersson" <[email-masked]>
  Cc: <[email-masked]>
  Sent: Friday, July 22, 2005 11:41 AM
  Subject: Re: Frameformat in a l2cs gmpls rnvironment.

  > > Per and Dimitri,
  > >
  > > I would like to come down stronger than that, for me it is
  > > a very strong requirement that the same switch can handle
  > > both VLANs and GMPLs trafic correctly. I can't dsee how that
  > > could be done if using the VLAN tpid to indicate GMPLS
  > > traffic.
  >=20
  > If you ever want that same switch to handle traffic for a directly
  > connected  host (not to uncommen) you would want that to use normal
  > ethernet macaddress switching. So of course you do not want to have =
to
  > choose between vlan and gmpls, you would want both at the same time.
  >=20
  > /per
  >=20
  >=20
  > >
  > > /Loa
  > >
  > > P=E4r Mattsson wrote:
  > >>>hi par, one of the possibilities that has been considered to cope =
with
  > >>>this requirement is to use a dedicated TPID for the Ethernet =
labeled
  > >>>frames; this would allow differentiated processing with =
non-labeled
  > >>>framesthanks.
  > >>
  > >>
  > >> That seems to make more sence. If that frame is to be sized like =
a
  > >> 802.1q
  > >> frame. There is not that much space left to a label. Or is the =
demand to
  > >> use jumboframes ?
  > >> Has there been any discussion on labelstacking, and mainly where =
to
  > >> place
  > >> the information?
  > >>
  > >> Regards.
  > >> Per
  > >>
  > >>
  > >>
  > >
  > >
  > > --
  > > Loa Andersson
  > >
  > > Principal Networking Architect
  > > Acreo AB                           phone:  +46 8 632 77 14
  > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
  > > Kista, Sweden                      email:  [email-masked]
  > >                                             [email-masked]
  > >
  >=20
  >=20
  >=20
  >=20

  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  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
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------=_NextPart_000_017C_01C58EC0.0C02EAF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dimitri,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The question is simple: is it possible =
today to=20
statically provision L2LSPs that could, say,&nbsp;support e2e QoS? If =
not, may=20
be it is to early to discuss aspects of dynamic provisioning of such =
LSPs? Is it=20
possible/reasonable, in your opinion, to "<FONT face=3D"Courier New" =
size=3D3>detail=20
how forwarding information can be exchanged via the control plane (and =
then=20
installed)" without&nbsp;having in mind "a specific forwarding=20
behavior"?</FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New">How do you know which forwarding =
information is=20
needed for the forwarding nobody has defined yet?</FONT></DIV>
<DIV><FONT face=3D"Courier New">The other question is&nbsp;do we need at =
all e2e=20
QoS, route control, fast recovery? Sounds like exciting idea, but does =
all that=20
commercially make sense? So, I guess, we need two things&nbsp;before we=20
can&nbsp;move forward:</FONT></DIV>
<DIV><FONT face=3D"Courier New">a) validation of the idea by the=20
providers;</FONT></DIV>
<DIV><FONT face=3D"Courier New">b) definition of the data plane=20
behavior;</FONT></DIV>
<DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New">Igor</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  =
href=3D"mailto:[email-masked]">Dimitri.Papadimitriou@al=
catel.be</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Igor Bryskin</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Mack-Crane, T. Benjamin</A> =
; <A=20
  title=[email-masked] href=3D"mailto:[email-masked]">Adrian =
Farrel</A>=20
  ; <A title=[email-masked] href=3D"mailto:[email-masked]">P=E4r =
Mattsson</A> ; <A=20
  title=[email-masked] href=3D"mailto:[email-masked]">Loa Andersson</A> ; <A=20
  title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, July 22, 2005 =
12:21=20
PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Frameformat in a =
l2cs gmpls=20
  rnvironment.</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>
  <P><FONT face=3DMonospace,Courier>igor - i am not sure which point =
they exactly=20
  have - the purpose of this document is to detail how forwarding =
information=20
  can be exchanged via the control plane (and then installed) not to =
define a=20
  specific forwarding behaviour</FONT></P>
  <P><FONT face=3DMonospace,Courier>thanks,</FONT></P>
  <P><FONT face=3DMonospace,Courier>- dimitri.</FONT><BR><BR><FONT =
size=3D2><B>"Igor=20
  Bryskin" &lt;<A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</B></FONT><=
BR><FONT=20
  size=3D2>Sent by: <A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A></FO=
NT><BR><FONT=20
  size=3D2>07/22/2005 11:10 AST</FONT><BR><BR><FONT size=3D2>To:</FONT> =
<FONT=20
  size=3D2>"Mack-Crane, T. Benjamin" &lt;<A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A>=
&gt;,=20
  "Adrian Farrel" &lt;<A=20
  href=3D"mailto:[email-masked]">[email-masked]</A>&gt;, P=E4r =
Mattsson=20
  &lt;<A href=3D"mailto:[email-masked]">[email-masked]</A>&gt;, "Loa =
Andersson"=20
  &lt;<A href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FONT><BR><FONT=20
  size=3D2>cc:</FONT> <FONT size=3D2>&lt;<A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FONT><BR><=
FONT=20
  size=3D2>bcc:</FONT> <BR><FONT size=3D2>Subject:</FONT> <FONT =
size=3D2>Re:=20
  Frameformat in a l2cs gmpls rnvironment.</FONT><BR><BR><BR></P>
  <P>Hi,<BR><BR>I think Ben and Juergen have a point here. There is =
nothing that=20
  could be dynamically provisioned that could not be also provisioned by =

  management. In other words data plane is the King here. We need data =
plane=20
  standard(s) on how we encode a label, whether we need a label stack or =
not,=20
  how the labeled traffic is supposed to be&nbsp;treated, how labeled =
traffic=20
  co-exist with non-label traffic, etc. This is something that not for =
CCAMP to=20
  define. Take for example TDM networks. GMPLS only provides a way to=20
  dynamically provision G.707 networks. Hence there is a need in =
parallel=20
  standardization activities in ITU. Only after that we can discuss how =
all that=20
  could be dynamically provisioned, that is the aspects of control =
plane.=20
  <BR><BR>Igor<BR><FONT size=3D4>----- Original Message ----- =
</FONT><BR><FONT=20
  size=3D4><B>From:</B> </FONT><FONT color=3Dblue size=3D4><U><A=20
  href=3D"mailto:[email-masked]">Mack-Crane, T.=20
  Benjamin</A></U></FONT><FONT color=3Dblack size=3D4> </FONT><BR><FONT=20
  size=3D4><B>To:</B> </FONT><FONT color=3Dblue size=3D4><U><A=20
  href=3D"mailto:[email-masked]">Adrian Farrel</A></U></FONT><FONT=20
  color=3Dblack size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A=20
  href=3D"mailto:[email-masked]">P=E4r Mattsson</A></U></FONT><FONT =
color=3Dblack=20
  size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A =
href=3D"mailto:[email-masked]">Loa=20
  Andersson</A></U></FONT><FONT color=3Dblack size=3D4> </FONT><BR><FONT =

  size=3D4><B>Cc:</B> </FONT><FONT color=3Dblue size=3D4><U><A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT=
=20
  color=3Dblack size=3D4> </FONT><BR><FONT size=3D4><B>Sent:</B> Friday, =
July 22, 2005=20
  10:23 AM</FONT><BR><FONT size=3D4><B>Subject:</B> RE: Frameformat in a =
l2cs=20
  gmpls rnvironment.</FONT><BR><BR>Hi,<BR><BR>I think Juergen has raised =
an=20
  important question.&nbsp; How frames are labeled (and the related data =
plane=20
  forwarding behavior) is not defined by the control plane.&nbsp; The =
control=20
  plane serves to provision the data plane, not define it.&nbsp; In the=20
  framework draft it is not clear what data plane standards are covered =
by the=20
  stated control plane requirements.&nbsp; Some references should be=20
  supplied.&nbsp; In any case, the labeling and forwarding behavior =
should be=20
  defined&nbsp;by these referenced standards, not&nbsp;by =
GMPLS.<BR><BR>(I am=20
  assuming definition of new data plane standards is out of scope for=20
  CCAMP.)<BR><BR>Regards,<BR>Ben<BR>
  <HR align=3Dleft width=3D"99%" SIZE=3D4>
  <FONT color=3Dblack><BR><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Adrian=20
  Farrel<BR><B>Sent:</B> Friday, July 22, 2005 8:37 AM<BR><B>To:</B> =
P=E4r=20
  Mattsson; Loa Andersson<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B>=20
  Re: Frameformat in a l2cs gmpls rnvironment.<BR><BR>Hi,<BR><BR>It is =
always=20
  refreshing how engineers jump straight to a discussion of the solution =

  :-)<BR><BR>Perhaps we can assume that the framework draft is a good=20
  representation of the problem space, and that we are ready to start =
discussing=20
  the solutions.<BR><BR>One (perhaps the only?) significant question to =
answer=20
  is how the frames will be labelled. This question is one we must come =
to as=20
  soon as we are confident that the requirements need to be addressed at =

  all.<BR><BR>As has been pointed out, there are several possibilities =
and to=20
  pick from these we need to understand:<BR>1. Do we need to support =
explicit=20
  label stacking?<BR>&nbsp;&nbsp; Note that this is not supported in =
TDM, LSC or=20
  FSC.<BR>2. Do we need to be able to control (perhaps through=20
  an<BR>&nbsp;&nbsp;&nbsp;external signaling controller) existing =
hardware and=20
  <BR>&nbsp;&nbsp; install LSPs through existing networks?<BR>3. Do we =
need to=20
  support existing function simultaneous to<BR>&nbsp;&nbsp; the support =
of GMPLS=20
  L2 LSPs?<BR><BR>I think that from a chair's perspective I can give =
some=20
  limited guidance.<BR><BR>A. These questions must be raised and =
answered in the=20
  framework I-D<BR>B. The answer to question 3 is "yes". This means that =
the use=20
  of labels<BR>&nbsp;&nbsp; must not significantly deplete any namespace =
used to=20
  support other<BR>&nbsp;&nbsp; function.<BR>C. CCAMP is chartered to =
look at=20
  the control of transport networks. This<BR>&nbsp;&nbsp;&nbsp;includes =
Metro,=20
  but I am unsure about Campus. It does not&nbsp;cover <BR>&nbsp;&nbsp;=20
  signaling to the desktop.<BR><BR>Thanks,<BR>Adrian<BR><BR>----- =
Original=20
  Message ----- <BR>From: "P=E4r Mattsson" &lt;</FONT><FONT =
color=3Dblue><U><A=20
  href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT=20
  color=3Dblack>&gt;<BR>To: "Loa Andersson" &lt;</FONT><FONT =
color=3Dblue><U><A=20
  href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT =
color=3Dblack>&gt;<BR>Cc:=20
  &lt;</FONT><FONT color=3Dblue><U><A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT=
=20
  color=3Dblack>&gt;<BR>Sent: Friday, July 22, 2005 11:41 AM<BR>Subject: =
Re:=20
  Frameformat in a l2cs gmpls rnvironment.<BR><BR><BR>&gt; &gt; Per and=20
  Dimitri,<BR>&gt; &gt;<BR>&gt; &gt; I would like to come down stronger =
than=20
  that, for me it is<BR>&gt; &gt; a very strong requirement that the =
same switch=20
  can handle<BR>&gt; &gt; both VLANs and GMPLs trafic correctly. I can't =
dsee=20
  how that<BR>&gt; &gt; could be done if using the VLAN tpid to indicate =

  GMPLS<BR>&gt; &gt; traffic.<BR>&gt; <BR>&gt; If you ever want that =
same switch=20
  to handle traffic for a directly<BR>&gt; connected&nbsp; host (not to=20
  uncommen) you would want that to use normal<BR>&gt; ethernet =
macaddress=20
  switching. So of course you do not want to have to<BR>&gt; choose =
between vlan=20
  and gmpls, you would want both at the same time.<BR>&gt; <BR>&gt; =
/per<BR>&gt;=20
  <BR>&gt; <BR>&gt; &gt;<BR>&gt; &gt; /Loa<BR>&gt; &gt;<BR>&gt; &gt; =
P=E4r=20
  Mattsson wrote:<BR>&gt; &gt;&gt;&gt;hi par, one of the possibilities =
that has=20
  been considered to cope with<BR>&gt; &gt;&gt;&gt;this requirement is =
to use a=20
  dedicated TPID for the Ethernet labeled<BR>&gt; &gt;&gt;&gt;frames; =
this would=20
  allow differentiated processing with non-labeled<BR>&gt;=20
  &gt;&gt;&gt;framesthanks.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; =
&gt;&gt;=20
  That seems to make more sence. If that frame is to be sized like =
a<BR>&gt;=20
  &gt;&gt; 802.1q<BR>&gt; &gt;&gt; frame. There is not that much space =
left to a=20
  label. Or is the demand to<BR>&gt; &gt;&gt; use jumboframes ?<BR>&gt; =
&gt;&gt;=20
  Has there been any discussion on labelstacking, and mainly where =
to<BR>&gt;=20
  &gt;&gt; place<BR>&gt; &gt;&gt; the information?<BR>&gt; =
&gt;&gt;<BR>&gt;=20
  &gt;&gt; Regards.<BR>&gt; &gt;&gt; Per<BR>&gt; &gt;&gt;<BR>&gt;=20
  &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; =
--<BR>&gt;=20
  &gt; Loa Andersson<BR>&gt; &gt;<BR>&gt; &gt; Principal Networking=20
  Architect<BR>&gt; &gt; Acreo=20
  =
AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
  phone:&nbsp; +46 8 632 77 14<BR>&gt; &gt; Isafjordsgatan=20
  =
22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mobile: +46 739 81 21 64<BR>&gt; &gt; Kista,=20
  =
Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  email:&nbsp; </FONT><FONT color=3Dblue><U><A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A></U></FO=
NT><FONT=20
  color=3Dblack><BR>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><FONT color=3Dblue><U><A=20
  href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT =
color=3Dblack><BR>&gt;=20
  &gt;<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR><BR></FONT><FONT=20
  face=3DMonospace,Courier=20
  =
size=3D4>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT><BR><FONT=20
  face=3DMonospace,Courier size=3D4>The information contained in this =
message may be=20
  privileged</FONT><BR><FONT face=3DMonospace,Courier size=3D4>and =
confidential and=20
  protected from disclosure. If the reader</FONT><BR><FONT=20
  face=3DMonospace,Courier size=3D4>of this message is not the intended =
recipient,=20
  or an employee</FONT><BR><FONT face=3DMonospace,Courier size=3D4>or =
agent=20
  responsible for delivering this message to the</FONT><BR><FONT=20
  face=3DMonospace,Courier size=3D4>intended recipient, you are hereby =
notified that=20
  any reproduction,</FONT><BR><FONT face=3DMonospace,Courier =
size=3D4>dissemination=20
  or distribution of this communication is strictly</FONT><BR><FONT=20
  face=3DMonospace,Courier size=3D4>prohibited. If you have received =
this=20
  communication in error,</FONT><BR><FONT face=3DMonospace,Courier =
size=3D4>please=20
  notify us immediately by replying to the message and</FONT><BR><FONT=20
  face=3DMonospace,Courier size=3D4>deleting it from your computer. =
Thank you.=20
  Tellabs</FONT><BR><FONT face=3DMonospace,Courier=20
  =
size=3D4>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT><BR>
  <P></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_017C_01C58EC0.0C02EAF0--

Delivery-date: Fri, 22 Jul 2005 16:23:38 +0000
To: "Igor Bryskin" <[email-masked]>
Cc: "Mack-Crane, T. Benjamin" <[email-masked]>, "Adrian Farrel" <[email-masked]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>, "Loa Andersson" <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 18:21:14 +0200

Delivery-date: Fri, 22 Jul 2005 15:52:16 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 17:51:08 +0200

Delivery-date: Fri, 22 Jul 2005 15:35:37 +0000
Content-Class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 16:33:59 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Juergen,

Before you can use GMPLS to set up VLANs a data plane must first exist =
to carry the GMPLS control plane traffic. Yes you can use the standard =
Ethernet data plane for this purpose (and in fact must do so for the =
solution to be viable), but its not as simple as that. You cannot assume =
that just because two GMPLS peers are directly connected that they can =
communicate with each other.

To exchange GMPLS control plane packets between a pair of GMPLS peers, =
the peers will need to agree to use either untagged control packets or =
to tag them with a common VLAN ID. The use of a separate VLAN for GMPLS =
control traffic is analogous to using a separate VLAN for management =
traffic today. If two switches belong to the same management VLAN then =
you can use ICMP ping to verify connectivity between them. However, if =
one switch has been put into the wrong management VLAN then the ping =
will obviously fail.

If you want to use a separate VLAN for GMPLS control plane traffic, then =
you either need to (i) define a reserved GMPLS signalling VLAN ID, or =
(ii) leave it up to the operator to choose a VLAN ID. If you leave it up =
to the operator to decide what VLAN ID to use, then you need to consider =
what the implications in the inter-operator case will be, i.e. what VLAN =
ID range should be used for control plane traffic and what VLAN ID range =
should be used for user plane traffic.

I'm not saying that defining how GMPLS control plane packets are =
forwarded in the Ethernet data plane will be an issue, simply that this =
is something that must be addressed to develop interoperable solutions.

Regards,
Richard

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Heiles Juergen
> Sent: 22 July 2005 14:17
> To: Loa Andersson; P=E4r Mattsson
> Cc: [email-masked]
> Subject: RE: Frameformat in a l2cs gmpls rnvironment.
>=20
>=20
> GMPLS for SONET/SDH has no impact on the SONET/SDH data=20
> plane. It introduces a control plane for connection setup=20
> instead of a network management based connection setup. GMPLS=20
> for Ethernet can work in the same way. Ethernet as such is=20
> cl, but VLANs are setup and GMPLS can provide a control plane=20
> for VLAN setup. The Ethernet data plane is not changed and=20
> MAC address learning and forwarding is still be done within a=20
> VLAN. So no change to the Ethernet data plane. No GMPLS=20
> traffic is introduced, it is still VLAN traffic.
> Introducing a dedicated GMPLS label for Ethernet (GMPLS=20
> traffic) goes beyond GMPLS as a control plane technique.
>=20
> Regards
>=20
> Juergen
>=20
>=20
> =20
>=20
> > From: [email-masked]=20
> > [mailto:[email-masked]] On Behalf Of Loa Andersson
> > Sent: Friday, July 22, 2005 12:05 PM
> > To: P=E4r Mattsson
> > Cc: [email-masked]
> > Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> >=20
> > Per and Dimitri,
> >=20
> > I would like to come down stronger than that, for me it is
> > a very strong requirement that the same switch can handle
> > both VLANs and GMPLs trafic correctly. I can't dsee how that
> > could be done if using the VLAN tpid to indicate GMPLS
> > traffic.
> >=20
> > /Loa
> >=20
> > P=E4r Mattsson wrote:
> > >>hi par, one of the possibilities that has been considered=20
> > to cope with
> > >>this requirement is to use a dedicated TPID for the=20
> Ethernet labeled
> > >>frames; this would allow differentiated processing with=20
> non-labeled
> > >>framesthanks.
> > >=20
> > >=20
> > > That seems to make more sence. If that frame is to be sized=20
> > like a 802.1q
> > > frame. There is not that much space left to a label. Or is=20
> > the demand to
> > > use jumboframes ?
> > > Has there been any discussion on labelstacking, and mainly=20
> > where to place
> > > the information?
> > >=20
> > > Regards.
> > > Per
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> > --=20
> > Loa Andersson
> >=20
> > Principal Networking Architect
> > Acreo AB                           phone:  +46 8 632 77 14
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > Kista, Sweden                      email:  [email-masked]
> >                                             [email-masked]
> >=20
>=20
>=20

Delivery-date: Fri, 22 Jul 2005 15:18:06 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 16:08:34 +0100

Dimitri,

> what do you EXACTLY mean with the following sentence
>
> "This question is one we must come to as soon as we are confident that
the
> requirements need to be addressed at all."
>
> please clarify - btw who is "we" in this context ?

"We" means "the CCAMP working group"

> this sentence reads to me as "CCAMP has not yet committed to work on
this
> topic" is my reading correct ? or do you mean something else with this ?

Your reading is exactly correct as stated.
I refer you to your email to the list on 19th July. You asked...
> - if yes, is the interest in GMPLS for Ethernet in-/out-side the
>   CCAMP WG community strong enough to consider the corr. GMPLS
>   signaling and routing requirements (second part of the document)
>   as part of the CCAMP WG effort ?

Thus, the purpose of the I-D was to crystalize the authors' thoughts on
GMPLS control of Ethernet switching and to initiate discussion on whether
the proposed deployment models are realistic and desirable. Following a
positive answer and assuming support (by CCAMP) for the doing the work (in
CCAMP) all that remains is to add the work to the charter (see previous
charter discussions) and get on with it.

Thanks,
Adrian

Delivery-date: Fri, 22 Jul 2005 15:17:58 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 16:18:30 +0100

Ben,

You raised some questions that I can answer with my chair hat comfortably
on.

> I think Juergen has raised an important question.

Yes, it is an important question, even if we are getting ahead of
ourselves. I take the question and the excitement as good evidence that we
are rapidly moving beyond the issue of whether requirements exist and are
now discussing how to implement.

> How frames are labeled (and the related data plane forwarding behavior)
is
> not defined by the control plane.

It is true to say that this is not defined by the control plane.
Nevertheless, the control plane passes labels around and it is important
to define how those labels will be interpreted. I refer you to all of the
non-packet labeling mechanisms already defined: you will see that they do
not define how the data is labeled, but they do define how the signaled
label maps to the labeled data.

> The control plane serves to provision the data plane, not define it.

Yes.

> In the framework draft it is not clear what data plane standards are
> covered by the stated control plane requirements. Some references
> should be supplied.

Such text would not be welcomed by the chairs who specifically instructed
it to be left out.
You may want to see a complete solution presented in one go, but the
chairs want to see the deployment scenarios separated from the solutions
work.
The debate about how to label packets is distinctly unhelpful in
determining what we want to be able to achieve with GMPLS control of
Ethernet networks. Further, the requirements may drive us towards one
solution rather than another, so placing the solution within the
requirements/framework I-D would be dangerous.

> In any case, the labeling and forwarding behavior should be defined by
these
> referenced standards, not by GMPLS.

I think you will find that there are adequate standards for forwarding
data in Ethernet, without any new standards being defined. The choice
which will ultimately be made (FOR EXAMPLE between MAC addresses, VLAN
TAGs, or new TPIDs) does not touch existing forwarding paradigms, but
might change how those forwarding paradigms are installed.

> (I am assuming definition of new data plane standards is out of scope
for
> CCAMP.)

Are you?

I would be surprised if this work introduced new data plane standards.

Thanks,
Adrian

Delivery-date: Fri, 22 Jul 2005 15:11:55 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Mack-Crane, T. Benjamin" <[email-masked]>, "Adrian Farrel" <[email-masked]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>, "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 11:10:31 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_013F_01C58EAD.F99BA260
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I think Ben and Juergen have a point here. There is nothing that could =
be dynamically provisioned that could not be also provisioned by =
management. In other words data plane is the King here. We need data =
plane standard(s) on how we encode a label, whether we need a label =
stack or not, how the labeled traffic is supposed to be treated, how =
labeled traffic co-exist with non-label traffic, etc. This is something =
that not for CCAMP to define. Take for example TDM networks. GMPLS only =
provides a way to dynamically provision G.707 networks. Hence there is a =
need in parallel standardization activities in ITU. Only after that we =
can discuss how all that could be dynamically provisioned, that is the =
aspects of control plane.=20

Igor
  ----- Original Message -----=20
  From: Mack-Crane, T. Benjamin=20
  To: Adrian Farrel ; P=E4r Mattsson ; Loa Andersson=20
  Cc: [email-masked]=20
  Sent: Friday, July 22, 2005 10:23 AM
  Subject: RE: Frameformat in a l2cs gmpls rnvironment.

  Hi,

  I think Juergen has raised an important question.  How frames are =
labeled (and the related data plane forwarding behavior) is not defined =
by the control plane.  The control plane serves to provision the data =
plane, not define it.  In the framework draft it is not clear what data =
plane standards are covered by the stated control plane requirements.  =
Some references should be supplied.  In any case, the labeling and =
forwarding behavior should be defined by these referenced standards, not =
by GMPLS.

  (I am assuming definition of new data plane standards is out of scope =
for CCAMP.)

  Regards,
  Ben

-------------------------------------------------------------------------=
---
    From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Adrian Farrel
    Sent: Friday, July 22, 2005 8:37 AM
    To: P=E4r Mattsson; Loa Andersson
    Cc: [email-masked]
    Subject: Re: Frameformat in a l2cs gmpls rnvironment.

    Hi,

    It is always refreshing how engineers jump straight to a discussion =
of the solution :-)

    Perhaps we can assume that the framework draft is a good =
representation of the problem space, and that we are ready to start =
discussing the solutions.

    One (perhaps the only?) significant question to answer is how the =
frames will be labelled. This question is one we must come to as soon as =
we are confident that the requirements need to be addressed at all.

    As has been pointed out, there are several possibilities and to pick =
from these we need to understand:
    1. Do we need to support explicit label stacking?
       Note that this is not supported in TDM, LSC or FSC.
    2. Do we need to be able to control (perhaps through an
       external signaling controller) existing hardware and=20
       install LSPs through existing networks?
    3. Do we need to support existing function simultaneous to
       the support of GMPLS L2 LSPs?

    I think that from a chair's perspective I can give some limited =
guidance.

    A. These questions must be raised and answered in the framework I-D
    B. The answer to question 3 is "yes". This means that the use of =
labels
       must not significantly deplete any namespace used to support =
other
       function.
    C. CCAMP is chartered to look at the control of transport networks. =
This
       includes Metro, but I am unsure about Campus. It does not cover=20
       signaling to the desktop.

    Thanks,
    Adrian

    ----- Original Message -----=20
    From: "P=E4r Mattsson" <[email-masked]>
    To: "Loa Andersson" <[email-masked]>
    Cc: <[email-masked]>
    Sent: Friday, July 22, 2005 11:41 AM
    Subject: Re: Frameformat in a l2cs gmpls rnvironment.

    > > Per and Dimitri,
    > >
    > > I would like to come down stronger than that, for me it is
    > > a very strong requirement that the same switch can handle
    > > both VLANs and GMPLs trafic correctly. I can't dsee how that
    > > could be done if using the VLAN tpid to indicate GMPLS
    > > traffic.
    >=20
    > If you ever want that same switch to handle traffic for a directly
    > connected  host (not to uncommen) you would want that to use =
normal
    > ethernet macaddress switching. So of course you do not want to =
have to
    > choose between vlan and gmpls, you would want both at the same =
time.
    >=20
    > /per
    >=20
    >=20
    > >
    > > /Loa
    > >
    > > P=E4r Mattsson wrote:
    > >>>hi par, one of the possibilities that has been considered to =
cope with
    > >>>this requirement is to use a dedicated TPID for the Ethernet =
labeled
    > >>>frames; this would allow differentiated processing with =
non-labeled
    > >>>framesthanks.
    > >>
    > >>
    > >> That seems to make more sence. If that frame is to be sized =
like a
    > >> 802.1q
    > >> frame. There is not that much space left to a label. Or is the =
demand to
    > >> use jumboframes ?
    > >> Has there been any discussion on labelstacking, and mainly =
where to
    > >> place
    > >> the information?
    > >>
    > >> Regards.
    > >> Per
    > >>
    > >>
    > >>
    > >
    > >
    > > --
    > > Loa Andersson
    > >
    > > Principal Networking Architect
    > > Acreo AB                           phone:  +46 8 632 77 14
    > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
    > > Kista, Sweden                      email:  =
[email-masked]
    > >                                             [email-masked]
    >=20
    >=20
    >=20
    >=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------=_NextPart_000_013F_01C58EAD.F99BA260
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I think Ben and Juergen have a point =
here. There is=20
nothing that could be dynamically provisioned that could not be also =
provisioned=20
by management. In other words data plane is the King here. We need data =
plane=20
standard(s) on how we encode a label, whether we need a label stack or =
not, how=20
the labeled traffic is supposed to be&nbsp;treated, how labeled traffic =
co-exist=20
with non-label traffic, etc. This is something that not for CCAMP to =
define.=20
Take for example TDM networks. GMPLS only provides a way to dynamically=20
provision G.707 networks. Hence there is a need in parallel =
standardization=20
activities in ITU. Only after that we can discuss how all that could be=20
dynamically provisioned, that is the aspects of control plane. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Igor</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Mack-Crane, T. Benjamin</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Adrian Farrel</A> ; <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">P=E4r Mattsson</A> ; <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Loa Andersson</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, July 22, 2005 =
10:23=20
AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Frameformat in a =
l2cs gmpls=20
  rnvironment.</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>I think Juergen has raised an important =
question.&nbsp;=20
  How frames are labeled (and the related data plane forwarding =
behavior) is not=20
  defined by the control plane.&nbsp; The control plane serves to =
provision the=20
  data plane, not define it.&nbsp; In the framework draft it is not =
clear what=20
  data plane standards are covered by the stated control plane=20
  requirements.&nbsp; Some references should be supplied.&nbsp; In any =
case, the=20
  labeling and forwarding behavior should be defined&nbsp;by these =
referenced=20
  standards, not&nbsp;by GMPLS.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>(I am assuming definition of new data plane =
standards is=20
  out of scope for CCAMP.)</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Ben</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
    [mailto:[email-masked]] <B>On Behalf Of </B>Adrian=20
    Farrel<BR><B>Sent:</B> Friday, July 22, 2005 8:37 AM<BR><B>To:</B> =
P=E4r=20
    Mattsson; Loa Andersson<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B>=20
    Re: Frameformat in a l2cs gmpls rnvironment.<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DCourier size=3D2>It is always refreshing how =
engineers jump=20
    straight to a discussion of the solution :-)</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DCourier size=3D2>Perhaps we can assume that the =
framework=20
    draft is a good representation of the problem space, and that we are =
ready=20
    to start discussing the solutions.</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DCourier size=3D2>One (perhaps the only?) =
significant question=20
    to answer is how the frames will be labelled. This question is one =
we must=20
    come to as soon as we are confident that the requirements need to be =

    addressed at all.</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DCourier size=3D2>As has been pointed out, there =
are several=20
    possibilities and to pick from these we need to =
understand:</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>1. Do we need to support explicit =
label=20
    stacking?</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Note that this is =
not supported=20
    in TDM, LSC or FSC.</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>2. Do we need to be able to =
control (perhaps=20
    through an</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;external =
signaling=20
    controller) existing hardware and </FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; install LSPs through =
existing=20
    networks?</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>3. Do we need to support existing =
function=20
    simultaneous to</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; the support of GMPLS =
L2=20
    LSPs?</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DCourier size=3D2>I think that from a chair's =
perspective I can=20
    give some limited guidance.</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DCourier size=3D2>A. These questions must be raised =
and=20
    answered in the framework I-D</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>B. The answer to question 3 is =
"yes". This=20
    means that the use of labels</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; must not =
significantly deplete=20
    any namespace used to support other</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; =
function.</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>C. CCAMP is chartered to look at =
the control=20
    of transport networks. This</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;includes Metro, =
but I am=20
    unsure about Campus. It does not&nbsp;cover </FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; signaling to the=20
    desktop.</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DCourier size=3D2>----- Original Message ----- =
</FONT>
    <DIV><FONT face=3DCourier size=3D2>From: "P=E4r Mattsson" =
&lt;</FONT><A=20
    href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
    size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>To: "Loa Andersson" &lt;</FONT><A =

    href=3D"mailto:[email-masked]"><FONT face=3DCourier =
size=3D2>[email-masked]</FONT></A><FONT=20
    face=3DCourier size=3D2>&gt;</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>Cc: &lt;</FONT><A=20
    href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
    size=3D2>[email-masked]</FONT></A><FONT face=3DCourier=20
    size=3D2>&gt;</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>Sent: Friday, July 22, 2005 11:41 =

    AM</FONT></DIV>
    <DIV><FONT face=3DCourier size=3D2>Subject: Re: Frameformat in a =
l2cs gmpls=20
    rnvironment.</FONT></DIV></DIV>
    <DIV><FONT face=3DCourier><BR><FONT =
size=3D2></FONT></FONT></DIV><FONT=20
    face=3DCourier size=3D2>&gt; &gt; Per and Dimitri,<BR>&gt; =
&gt;<BR>&gt; &gt; I=20
    would like to come down stronger than that, for me it is<BR>&gt; =
&gt; a very=20
    strong requirement that the same switch can handle<BR>&gt; &gt; both =
VLANs=20
    and GMPLs trafic correctly. I can't dsee how that<BR>&gt; &gt; could =
be done=20
    if using the VLAN tpid to indicate GMPLS<BR>&gt; &gt; =
traffic.<BR>&gt;=20
    <BR>&gt; If you ever want that same switch to handle traffic for a=20
    directly<BR>&gt; connected&nbsp; host (not to uncommen) you would =
want that=20
    to use normal<BR>&gt; ethernet macaddress switching. So of course =
you do not=20
    want to have to<BR>&gt; choose between vlan and gmpls, you would =
want both=20
    at the same time.<BR>&gt; <BR>&gt; /per<BR>&gt; <BR>&gt; <BR>&gt;=20
    &gt;<BR>&gt; &gt; /Loa<BR>&gt; &gt;<BR>&gt; &gt; P=E4r Mattsson =
wrote:<BR>&gt;=20
    &gt;&gt;&gt;hi par, one of the possibilities that has been =
considered to=20
    cope with<BR>&gt; &gt;&gt;&gt;this requirement is to use a dedicated =
TPID=20
    for the Ethernet labeled<BR>&gt; &gt;&gt;&gt;frames; this would =
allow=20
    differentiated processing with non-labeled<BR>&gt;=20
    &gt;&gt;&gt;framesthanks.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; =
&gt;&gt;=20
    That seems to make more sence. If that frame is to be sized like =
a<BR>&gt;=20
    &gt;&gt; 802.1q<BR>&gt; &gt;&gt; frame. There is not that much space =
left to=20
    a label. Or is the demand to<BR>&gt; &gt;&gt; use jumboframes =
?<BR>&gt;=20
    &gt;&gt; Has there been any discussion on labelstacking, and mainly =
where=20
    to<BR>&gt; &gt;&gt; place<BR>&gt; &gt;&gt; the information?<BR>&gt;=20
    &gt;&gt;<BR>&gt; &gt;&gt; Regards.<BR>&gt; &gt;&gt; Per<BR>&gt;=20
    &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;<BR>&gt; =
&gt;<BR>&gt;=20
    &gt; --<BR>&gt; &gt; Loa Andersson<BR>&gt; &gt;<BR>&gt; &gt; =
Principal=20
    Networking Architect<BR>&gt; &gt; Acreo=20
    =
AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
    phone:&nbsp; +46 8 632 77 14<BR>&gt; &gt; Isafjordsgatan=20
    =
22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    mobile: +46 739 81 21 64<BR>&gt; &gt; Kista,=20
    =
Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    email:&nbsp; </FONT><A href=3D"mailto:[email-masked]"><FONT=20
    face=3DCourier size=3D2>[email-masked]</FONT></A><BR><FONT =
face=3DCourier=20
    size=3D2>&gt;=20
    =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    </FONT><A href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
    size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier size=3D2>&gt; =
&gt;<BR>&gt;=20
    <BR>&gt; <BR>&gt; <BR>&gt; =
</FONT></BLOCKQUOTE><PRE>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
</PRE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_013F_01C58EAD.F99BA260--

Delivery-date: Fri, 22 Jul 2005 15:01:10 +0000
Date: Fri, 22 Jul 2005 16:57:09 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: Heiles Juergen <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

Juergen,

that is only because we were told to avoid "solutions" in the
framework, consequently we who route studd that is not necessarily
based on vlan did not discuss how we wanted to "label" the frame.

The proposal to use the vlan (tpid 8100) did include the solution
in the document, which if we listen the wg chairs it should not have.

What I belive is that when we start use GMPLS labled frames in an
Ethernet network the behavior will be different from those that
are vlan-tagged, hence it won't be possible to use the vlan-tag
as gmpls-label, the switch can distinguish betwen them.

Also there is a clear requirement in the section 6.2 that labels
should be locally significant.

/Loa

Heiles Juergen wrote:
> Loa,
> 
> I interpret the ID as a proposal to use GMPLS for VLAN setup. So GMPLS and VLAN to not compete. The VLAN is at the data plane and GMPLS at the control plane. The question is how and should different control plane techniques like GMPLS and (GVRP and STB) work together?
> 
> Regards
> 
> Juergen
>  
> 
> 
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Loa Andersson
>>Sent: Friday, July 22, 2005 2:53 PM
>>To: [email-masked]
>>Cc: [email-masked]; [email-masked]
>>Subject: Re: Frameformat in a l2cs gmpls rnvironment.
>>
>>Richard,
>>
>>I agree to most of this. Since we have doubts about the viability
>>of taking GMPLS all the way to end-user or enterprise I think it
>>would be good, from a wg perspective, if we agreed to solve the
>>core network problems first.
>>
>>Do you have any comment on the requirement to run both VLANs and
>>GMPLS on the same switch?
>>
>>/Loa
>>
>>[email-masked] wrote:
>>
>>>Regardless of whether or not a switch is directly connected
>>
>> > to hosts, it must be able to forward packets using the 
>>connectionless
>> > Ethernet data plane. This is due to the fundamental 
>>requirement that
>> > for GMPLS switches to be able to exchange control information with
>> > each other, a data plane for control traffic must be present.
>> > This is akin to using the IP data plane for MPLS signalling in an
>> > IP/MPLS network. An alternative would be to use a static reserved
>> > L2-LSP for control traffic in the same way that reserved VPI/VCIs
>> > are used for PNNI signalling in ATM.
>>
>>>Regarding connecting hosts to GMPLS switches, I personally don't 
>>
>> > think extending L2-LSPs into the enterprise/home network is
>> > commercially viable. However, if you do want to use GMPLS switches
>> > in the home/enterprise network and for some reason don't want to
>> > extend L2-LSPs down to the host then you will not be performing
>> > normal Ethernet Mac address switching anyway. Instead you will
>> > need some kind of policy on the switch that maps connectionless
>> > Ethernet packets (e.g. based on MAC src/dest, 802.1p, VLAN) to a
>> > L2-LSP. This is because multiple L2-LSPs to the same destination
>> > (e.g. a gateway router) may exist for different services/flows
>> > (e.g. video download, VoIP call, etc.).
>>
>>>Regards,
>>>Richard
>>>
>>>
>>>
>>>>From: [email-masked] [mailto:[email-masked]]On
>>>>Behalf Of Pär Mattsson
>>>>Sent: 22 July 2005 11:42
>>>>To: Loa Andersson
>>>>Cc: [email-masked]
>>>>Subject: Re: Frameformat in a l2cs gmpls rnvironment.
>>>>
>>>>
>>>>
>>>>
>>>>>Per and Dimitri,
>>>>>
>>>>>I would like to come down stronger than that, for me it is
>>>>>a very strong requirement that the same switch can handle
>>>>>both VLANs and GMPLs trafic correctly. I can't dsee how that
>>>>>could be done if using the VLAN tpid to indicate GMPLS
>>>>>traffic.
>>>>
>>>>If you ever want that same switch to handle traffic for a directly
>>>>connected  host (not to uncommen) you would want that to use normal
>>>>ethernet macaddress switching. So of course you do not want 
>>
>>to have to
>>
>>>>choose between vlan and gmpls, you would want both at the same time.
>>>>
>>>>/per
>>>>
>>>>
>>>>
>>>>
>>>>>/Loa
>>>>>
>>>>>Pär Mattsson wrote:
>>>>>
>>>>>
>>>>>>>hi par, one of the possibilities that has been considered 
>>>>
>>>>to cope with
>>>>
>>>>
>>>>>>>this requirement is to use a dedicated TPID for the 
>>>>
>>>>Ethernet labeled
>>>>
>>>>
>>>>>>>frames; this would allow differentiated processing with 
>>
>>non-labeled
>>
>>>>>>>framesthanks.
>>>>>>
>>>>>>
>>>>>>That seems to make more sence. If that frame is to be sized like a
>>>>>>802.1q
>>>>>>frame. There is not that much space left to a label. Or is 
>>>>
>>>>the demand to
>>>>
>>>>
>>>>>>use jumboframes ?
>>>>>>Has there been any discussion on labelstacking, and 
>>
>>mainly where to
>>
>>>>>>place
>>>>>>the information?
>>>>>>
>>>>>>Regards.
>>>>>>Per
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>Loa Andersson
>>>>>
>>>>>Principal Networking Architect
>>>>>Acreo AB                           phone:  +46 8 632 77 14
>>>>>Isafjordsgatan 22                  mobile: +46 739 81 21 64
>>>>>Kista, Sweden                      email:  [email-masked]
>>>>>                                           [email-masked]
>>>>>
>>>>
>>>>
>>>>
>>
>>-- 
>>Loa Andersson
>>
>>Principal Networking Architect
>>Acreo AB                           phone:  +46 8 632 77 14
>>Isafjordsgatan 22                  mobile: +46 739 81 21 64
>>Kista, Sweden                      email:  [email-masked]
>>                                            [email-masked]
>>
> 
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Fri, 22 Jul 2005 14:26:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 09:23:59 -0500
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>, "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58EC9.2CDB7192
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
I think Juergen has raised an important question.  How frames are labeled (=
and the related data plane forwarding behavior) is not defined by the contr=
ol plane.  The control plane serves to provision the data plane, not define=
 it.  In the framework draft it is not clear what data plane standards are =
covered by the stated control plane requirements.  Some references should b=
e supplied.  In any case, the labeling and forwarding behavior should be de=
fined by these referenced standards, not by GMPLS.
=20
(I am assuming definition of new data plane standards is out of scope for C=
CAMP.)
=20
Regards,
Ben

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf=
 Of Adrian Farrel
	Sent: Friday, July 22, 2005 8:37 AM
	To: P=E4r Mattsson; Loa Andersson
	Cc: [email-masked]
	Subject: Re: Frameformat in a l2cs gmpls rnvironment.
=09
=09
	Hi,
	=20
	It is always refreshing how engineers jump straight to a discussion of the=
 solution :-)
	=20
	Perhaps we can assume that the framework draft is a good representation of=
 the problem space, and that we are ready to start discussing the solutions.
	=20
	One (perhaps the only?) significant question to answer is how the frames w=
ill be labelled. This question is one we must come to as soon as we are con=
fident that the requirements need to be addressed at all.
	=20
	As has been pointed out, there are several possibilities and to pick from =
these we need to understand:
	1. Do we need to support explicit label stacking?
	   Note that this is not supported in TDM, LSC or FSC.
	2. Do we need to be able to control (perhaps through an
	   external signaling controller) existing hardware and=20
	   install LSPs through existing networks?
	3. Do we need to support existing function simultaneous to
	   the support of GMPLS L2 LSPs?
	=20
	I think that from a chair's perspective I can give some limited guidance.
	=20
	A. These questions must be raised and answered in the framework I-D
	B. The answer to question 3 is "yes". This means that the use of labels
	   must not significantly deplete any namespace used to support other
	   function.
	C. CCAMP is chartered to look at the control of transport networks. This
	   includes Metro, but I am unsure about Campus. It does not cover=20
	   signaling to the desktop.
	=20
	Thanks,
	Adrian
	=20
	----- Original Message -----=20
	From: "P=E4r Mattsson" <[email-masked] <mailto:[email-masked]> >
	To: "Loa Andersson" <[email-masked] <mailto:[email-masked]> >
	Cc: <[email-masked] <mailto:[email-masked]> >
	Sent: Friday, July 22, 2005 11:41 AM
	Subject: Re: Frameformat in a l2cs gmpls rnvironment.
=09
=09
	> > Per and Dimitri,
	> >
	> > I would like to come down stronger than that, for me it is
	> > a very strong requirement that the same switch can handle
	> > both VLANs and GMPLs trafic correctly. I can't dsee how that
	> > could be done if using the VLAN tpid to indicate GMPLS
	> > traffic.
	>=20
	> If you ever want that same switch to handle traffic for a directly
	> connected  host (not to uncommen) you would want that to use normal
	> ethernet macaddress switching. So of course you do not want to have to
	> choose between vlan and gmpls, you would want both at the same time.
	>=20
	> /per
	>=20
	>=20
	> >
	> > /Loa
	> >
	> > P=E4r Mattsson wrote:
	> >>>hi par, one of the possibilities that has been considered to cope with
	> >>>this requirement is to use a dedicated TPID for the Ethernet labeled
	> >>>frames; this would allow differentiated processing with non-labeled
	> >>>framesthanks.
	> >>
	> >>
	> >> That seems to make more sence. If that frame is to be sized like a
	> >> 802.1q
	> >> frame. There is not that much space left to a label. Or is the demand=
 to
	> >> use jumboframes ?
	> >> Has there been any discussion on labelstacking, and mainly where to
	> >> place
	> >> the information?
	> >>
	> >> Regards.
	> >> Per
	> >>
	> >>
	> >>
	> >
	> >
	> > --
	> > Loa Andersson
	> >
	> > Principal Networking Architect
	> > Acreo AB                           phone:  +46 8 632 77 14
	> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
	> > Kista, Sweden                      email:  [email-masked] <mai=
lto:[email-masked]>=20
	> >                                             [email-masked] <mailto:[email-masked]=
e>=20
	>=20
	>=20
	>=20
	>=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C58EC9.2CDB7192
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>I think Juergen has raised an important question.&=
nbsp; How=20
frames are labeled (and the related data plane forwarding behavior) is not=20
defined by the control plane.&nbsp; The control plane serves to provision t=
he=20
data plane, not define it.&nbsp; In the framework draft it is not clear wha=
t=20
data plane standards are covered by the stated control plane requirements.&=
nbsp;=20
Some references should be supplied.&nbsp; In any case, the labeling and=20
forwarding behavior should be defined&nbsp;by these referenced standards,=20
not&nbsp;by GMPLS.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>(I am assuming definition of new data plane standa=
rds is=20
out of scope for CCAMP.)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D481061614-22072005><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Ben</FONT></SPAN></DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli=
d; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Adrian=20
  Farrel<BR><B>Sent:</B> Friday, July 22, 2005 8:37 AM<BR><B>To:</B> P=E4r=20
  Mattsson; Loa Andersson<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</=
B>=20
  Re: Frameformat in a l2cs gmpls rnvironment.<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>It is always refreshing how engineers =
jump=20
  straight to a discussion of the solution :-)</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Perhaps we can assume that the framewo=
rk draft=20
  is a good representation of the problem space, and that we are ready to s=
tart=20
  discussing the solutions.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>One (perhaps the only?) significant qu=
estion to=20
  answer is how the frames will be labelled. This question is one we must c=
ome=20
  to as soon as we are confident that the requirements need to be addressed=
 at=20
  all.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>As has been pointed out, there are sev=
eral=20
  possibilities and to pick from these we need to understand:</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>1. Do we need to support explicit labe=
l=20
  stacking?</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Note that this is not sup=
ported in=20
  TDM, LSC or FSC.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>2. Do we need to be able to control (p=
erhaps=20
  through an</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;external signaling=20
  controller) existing hardware and </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; install LSPs through exis=
ting=20
  networks?</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>3. Do we need to support existing func=
tion=20
  simultaneous to</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; the support of GMPLS L2=20
  LSPs?</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>I think that from a chair's perspectiv=
e I can=20
  give some limited guidance.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>A. These questions must be raised and =
answered=20
  in the framework I-D</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>B. The answer to question 3 is "yes". =
This=20
  means that the use of labels</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; must not significantly de=
plete any=20
  namespace used to support other</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; function.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>C. CCAMP is chartered to look at the c=
ontrol of=20
  transport networks. This</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;includes Metro, but =
I am=20
  unsure about Campus. It does not&nbsp;cover </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; signaling to the=20
  desktop.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>----- Original Message ----- </FONT>
  <DIV><FONT face=3DCourier size=3D2>From: "P=E4r Mattsson" &lt;</FONT><A=20
  href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
  size=3D2>[email-masked]</FONT></A><FONT face=3DCourier size=3D2>&gt;</FONT=
></DIV>
  <DIV><FONT face=3DCourier size=3D2>To: "Loa Andersson" &lt;</FONT><A=20
  href=3D"mailto:[email-masked]"><FONT face=3DCourier size=3D2>[email-masked]</FONT><=
/A><FONT=20
  face=3DCourier size=3D2>&gt;</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>Cc: &lt;</FONT><A=20
  href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
  size=3D2>[email-masked]</FONT></A><FONT face=3DCourier=20
size=3D2>&gt;</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>Sent: Friday, July 22, 2005 11:41=20
  AM</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>Subject: Re: Frameformat in a l2cs gmp=
ls=20
  rnvironment.</FONT></DIV></DIV>
  <DIV><FONT face=3DCourier><BR><FONT size=3D2></FONT></FONT></DIV><FONT=20
  face=3DCourier size=3D2>&gt; &gt; Per and Dimitri,<BR>&gt; &gt;<BR>&gt; &=
gt; I=20
  would like to come down stronger than that, for me it is<BR>&gt; &gt; a v=
ery=20
  strong requirement that the same switch can handle<BR>&gt; &gt; both VLAN=
s and=20
  GMPLs trafic correctly. I can't dsee how that<BR>&gt; &gt; could be done =
if=20
  using the VLAN tpid to indicate GMPLS<BR>&gt; &gt; traffic.<BR>&gt; <BR>&=
gt;=20
  If you ever want that same switch to handle traffic for a directly<BR>&gt=
;=20
  connected&nbsp; host (not to uncommen) you would want that to use=20
  normal<BR>&gt; ethernet macaddress switching. So of course you do not wan=
t to=20
  have to<BR>&gt; choose between vlan and gmpls, you would want both at the=
 same=20
  time.<BR>&gt; <BR>&gt; /per<BR>&gt; <BR>&gt; <BR>&gt; &gt;<BR>&gt; &gt;=20
  /Loa<BR>&gt; &gt;<BR>&gt; &gt; P=E4r Mattsson wrote:<BR>&gt; &gt;&gt;&gt;=
hi par,=20
  one of the possibilities that has been considered to cope with<BR>&gt;=20
  &gt;&gt;&gt;this requirement is to use a dedicated TPID for the Ethernet=20
  labeled<BR>&gt; &gt;&gt;&gt;frames; this would allow differentiated proce=
ssing=20
  with non-labeled<BR>&gt; &gt;&gt;&gt;framesthanks.<BR>&gt; &gt;&gt;<BR>&g=
t;=20
  &gt;&gt;<BR>&gt; &gt;&gt; That seems to make more sence. If that frame is=
 to=20
  be sized like a<BR>&gt; &gt;&gt; 802.1q<BR>&gt; &gt;&gt; frame. There is =
not=20
  that much space left to a label. Or is the demand to<BR>&gt; &gt;&gt; use=20
  jumboframes ?<BR>&gt; &gt;&gt; Has there been any discussion on labelstac=
king,=20
  and mainly where to<BR>&gt; &gt;&gt; place<BR>&gt; &gt;&gt; the=20
  information?<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; Regards.<BR>&gt; &gt;&gt;=20
  Per<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;<BR>&g=
t;=20
  &gt;<BR>&gt; &gt; --<BR>&gt; &gt; Loa Andersson<BR>&gt; &gt;<BR>&gt; &gt;=20
  Principal Networking Architect<BR>&gt; &gt; Acreo=20
  AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
  phone:&nbsp; +46 8 632 77 14<BR>&gt; &gt; Isafjordsgatan=20
  22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mobile: +46 739 81 21 64<BR>&gt; &gt; Kista,=20
  Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  email:&nbsp; </FONT><A href=3D"mailto:[email-masked]"><FONT face=
=3DCourier=20
  size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier size=
=3D2>&gt;=20
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><A href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
  size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier size=3D2>&gt; &gt;<=
BR>&gt;=20
  <BR>&gt; <BR>&gt; <BR>&gt; </FONT></BLOCKQUOTE><pre>=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
</pre></BODY></HTML>

------_=_NextPart_001_01C58EC9.2CDB7192--

Delivery-date: Fri, 22 Jul 2005 14:20:46 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>, "Loa Andersson" <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 16:19:35 +0200

adrian -

what do you EXACTLY mean with the following sentence

"This question is one we must come to as soon as we are confident that the
requirements need to be addressed at all."

please clarify - btw who is "we" in this context ?

this sentence reads to me as "CCAMP has not yet committed to work on this
topic" is my reading correct ? or do you mean something else with this ?

thanks,
- dimitri.

Delivery-date: Fri, 22 Jul 2005 14:05:03 +0000
To: Heiles Juergen <[email-masked]>
Cc: Loa Andersson <[email-masked]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 16:03:13 +0200

Delivery-date: Fri, 22 Jul 2005 13:38:59 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>, "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 14:37:03 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_191C_01C58ECA.D361FF00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

It is always refreshing how engineers jump straight to a discussion of =
the solution :-)

Perhaps we can assume that the framework draft is a good representation =
of the problem space, and that we are ready to start discussing the =
solutions.

One (perhaps the only?) significant question to answer is how the frames =
will be labelled. This question is one we must come to as soon as we are =
confident that the requirements need to be addressed at all.

As has been pointed out, there are several possibilities and to pick =
from these we need to understand:
1. Do we need to support explicit label stacking?
   Note that this is not supported in TDM, LSC or FSC.
2. Do we need to be able to control (perhaps through an
   external signaling controller) existing hardware and=20
   install LSPs through existing networks?
3. Do we need to support existing function simultaneous to
   the support of GMPLS L2 LSPs?

I think that from a chair's perspective I can give some limited =
guidance.

A. These questions must be raised and answered in the framework I-D
B. The answer to question 3 is "yes". This means that the use of labels
   must not significantly deplete any namespace used to support other
   function.
C. CCAMP is chartered to look at the control of transport networks. This
   includes Metro, but I am unsure about Campus. It does not cover=20
   signaling to the desktop.

Thanks,
Adrian

----- Original Message -----=20
From: "P=E4r Mattsson" <[email-masked]>
To: "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 22, 2005 11:41 AM
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

> > Per and Dimitri,
> >
> > I would like to come down stronger than that, for me it is
> > a very strong requirement that the same switch can handle
> > both VLANs and GMPLs trafic correctly. I can't dsee how that
> > could be done if using the VLAN tpid to indicate GMPLS
> > traffic.
>=20
> If you ever want that same switch to handle traffic for a directly
> connected  host (not to uncommen) you would want that to use normal
> ethernet macaddress switching. So of course you do not want to have to
> choose between vlan and gmpls, you would want both at the same time.
>=20
> /per
>=20
>=20
> >
> > /Loa
> >
> > P=E4r Mattsson wrote:
> >>>hi par, one of the possibilities that has been considered to cope =
with
> >>>this requirement is to use a dedicated TPID for the Ethernet =
labeled
> >>>frames; this would allow differentiated processing with non-labeled
> >>>framesthanks.
> >>
> >>
> >> That seems to make more sence. If that frame is to be sized like a
> >> 802.1q
> >> frame. There is not that much space left to a label. Or is the =
demand to
> >> use jumboframes ?
> >> Has there been any discussion on labelstacking, and mainly where to
> >> place
> >> the information?
> >>
> >> Regards.
> >> Per
> >>
> >>
> >>
> >
> >
> > --
> > Loa Andersson
> >
> > Principal Networking Architect
> > Acreo AB                           phone:  +46 8 632 77 14
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > Kista, Sweden                      email:  [email-masked]
> >                                             [email-masked]
> >
>=20
>=20
>=20
> 
------=_NextPart_000_191C_01C58ECA.D361FF00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>It is always refreshing how engineers =
jump=20
straight to a discussion of the solution :-)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Perhaps we can assume that the =
framework draft is=20
a good representation of the problem space, and that we are ready to =
start=20
discussing the solutions.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>One (perhaps the only?) significant =
question to=20
answer is how the frames will be labelled. This question is one we must =
come to=20
as soon as we are confident that the requirements need to be addressed =
at=20
all.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>As has been pointed out, there are =
several=20
possibilities and to pick from these we need to understand:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>1. Do we need to support explicit =
label=20
stacking?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Note that this is not =
supported in=20
TDM, LSC or FSC.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>2. Do we need to be able to control =
(perhaps=20
through an</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;external signaling =
controller)=20
existing hardware and </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; install LSPs through =
existing=20
networks?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>3. Do we need to support existing =
function=20
simultaneous to</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; the support of GMPLS L2=20
LSPs?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I think that from a chair's =
perspective I can=20
give some limited guidance.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>A. These questions must be raised and =
answered in=20
the framework I-D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>B. The answer to question 3 is "yes". =
This means=20
that the use of labels</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; must not significantly =
deplete any=20
namespace used to support other</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; function.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>C. CCAMP is chartered to look at the =
control of=20
transport networks. This</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;includes Metro, but =
I am unsure=20
about Campus. It does not&nbsp;cover </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; signaling to the=20
desktop.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DCourier size=3D2>From: "P=E4r Mattsson" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>To: "Loa Andersson" &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier =
size=3D2>[email-masked]</FONT></A><FONT=20
face=3DCourier size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Cc: &lt;</FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Sent: Friday, July 22, 2005 11:41 =
AM</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Subject: Re: Frameformat in a l2cs =
gmpls=20
rnvironment.</FONT></DIV></DIV>
<DIV><FONT face=3DCourier><BR><FONT size=3D2></FONT></FONT></DIV><FONT =
face=3DCourier=20
size=3D2>&gt; &gt; Per and Dimitri,<BR>&gt; &gt;<BR>&gt; &gt; I would =
like to come=20
down stronger than that, for me it is<BR>&gt; &gt; a very strong =
requirement=20
that the same switch can handle<BR>&gt; &gt; both VLANs and GMPLs trafic =

correctly. I can't dsee how that<BR>&gt; &gt; could be done if using the =
VLAN=20
tpid to indicate GMPLS<BR>&gt; &gt; traffic.<BR>&gt; <BR>&gt; If you =
ever want=20
that same switch to handle traffic for a directly<BR>&gt; =
connected&nbsp; host=20
(not to uncommen) you would want that to use normal<BR>&gt; ethernet =
macaddress=20
switching. So of course you do not want to have to<BR>&gt; choose =
between vlan=20
and gmpls, you would want both at the same time.<BR>&gt; <BR>&gt; =
/per<BR>&gt;=20
<BR>&gt; <BR>&gt; &gt;<BR>&gt; &gt; /Loa<BR>&gt; &gt;<BR>&gt; &gt; P=E4r =
Mattsson=20
wrote:<BR>&gt; &gt;&gt;&gt;hi par, one of the possibilities that has =
been=20
considered to cope with<BR>&gt; &gt;&gt;&gt;this requirement is to use a =

dedicated TPID for the Ethernet labeled<BR>&gt; &gt;&gt;&gt;frames; this =
would=20
allow differentiated processing with non-labeled<BR>&gt;=20
&gt;&gt;&gt;framesthanks.<BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; =
&gt;&gt;=20
That seems to make more sence. If that frame is to be sized like =
a<BR>&gt;=20
&gt;&gt; 802.1q<BR>&gt; &gt;&gt; frame. There is not that much space =
left to a=20
label. Or is the demand to<BR>&gt; &gt;&gt; use jumboframes ?<BR>&gt; =
&gt;&gt;=20
Has there been any discussion on labelstacking, and mainly where =
to<BR>&gt;=20
&gt;&gt; place<BR>&gt; &gt;&gt; the information?<BR>&gt; =
&gt;&gt;<BR>&gt;=20
&gt;&gt; Regards.<BR>&gt; &gt;&gt; Per<BR>&gt; &gt;&gt;<BR>&gt; =
&gt;&gt;<BR>&gt;=20
&gt;&gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; --<BR>&gt; &gt; Loa=20
Andersson<BR>&gt; &gt;<BR>&gt; &gt; Principal Networking =
Architect<BR>&gt; &gt;=20
Acreo=20
AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
phone:&nbsp; +46 8 632 77 14<BR>&gt; &gt; Isafjordsgatan=20
22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
mobile: +46 739 81 21 64<BR>&gt; &gt; Kista,=20
Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
email:&nbsp; </FONT><A href=3D"mailto:[email-masked]"><FONT =
face=3DCourier=20
size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt;=20
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</FONT><A href=3D"mailto:[email-masked]"><FONT face=3DCourier=20
size=3D2>[email-masked]</FONT></A><BR><FONT face=3DCourier size=3D2>&gt; =
&gt;<BR>&gt;=20
<BR>&gt; <BR>&gt; <BR>&gt; </FONT></BODY></HTML>

------=_NextPart_000_191C_01C58ECA.D361FF00--

Delivery-date: Fri, 22 Jul 2005 13:24:42 +0000
From: Heiles Juergen <[email-masked]>
To: Loa Andersson <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 15:23:43 +0200

Loa,

I interpret the ID as a proposal to use GMPLS for VLAN setup. So GMPLS =
and VLAN to not compete. The VLAN is at the data plane and GMPLS at the =
control plane. The question is how and should different control plane =
techniques like GMPLS and (GVRP and STB) work together?

Regards

Juergen
=20

> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Friday, July 22, 2005 2:53 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Frameformat in a l2cs gmpls rnvironment.
>=20
> Richard,
>=20
> I agree to most of this. Since we have doubts about the viability
> of taking GMPLS all the way to end-user or enterprise I think it
> would be good, from a wg perspective, if we agreed to solve the
> core network problems first.
>=20
> Do you have any comment on the requirement to run both VLANs and
> GMPLS on the same switch?
>=20
> /Loa
>=20
> [email-masked] wrote:
> > Regardless of whether or not a switch is directly connected
>  > to hosts, it must be able to forward packets using the=20
> connectionless
>  > Ethernet data plane. This is due to the fundamental=20
> requirement that
>  > for GMPLS switches to be able to exchange control information with
>  > each other, a data plane for control traffic must be present.
>  > This is akin to using the IP data plane for MPLS signalling in an
>  > IP/MPLS network. An alternative would be to use a static reserved
>  > L2-LSP for control traffic in the same way that reserved VPI/VCIs
>  > are used for PNNI signalling in ATM.
> >=20
> > Regarding connecting hosts to GMPLS switches, I personally don't=20
>  > think extending L2-LSPs into the enterprise/home network is
>  > commercially viable. However, if you do want to use GMPLS switches
>  > in the home/enterprise network and for some reason don't want to
>  > extend L2-LSPs down to the host then you will not be performing
>  > normal Ethernet Mac address switching anyway. Instead you will
>  > need some kind of policy on the switch that maps connectionless
>  > Ethernet packets (e.g. based on MAC src/dest, 802.1p, VLAN) to a
>  > L2-LSP. This is because multiple L2-LSPs to the same destination
>  > (e.g. a gateway router) may exist for different services/flows
>  > (e.g. video download, VoIP call, etc.).
> >=20
> > Regards,
> > Richard
> >=20
> >=20
> >>From: [email-masked] [mailto:[email-masked]]On
> >>Behalf Of P=E4r Mattsson
> >>Sent: 22 July 2005 11:42
> >>To: Loa Andersson
> >>Cc: [email-masked]
> >>Subject: Re: Frameformat in a l2cs gmpls rnvironment.
> >>
> >>
> >>
> >>>Per and Dimitri,
> >>>
> >>>I would like to come down stronger than that, for me it is
> >>>a very strong requirement that the same switch can handle
> >>>both VLANs and GMPLs trafic correctly. I can't dsee how that
> >>>could be done if using the VLAN tpid to indicate GMPLS
> >>>traffic.
> >>
> >>If you ever want that same switch to handle traffic for a directly
> >>connected  host (not to uncommen) you would want that to use normal
> >>ethernet macaddress switching. So of course you do not want=20
> to have to
> >>choose between vlan and gmpls, you would want both at the same =
time.
> >>
> >>/per
> >>
> >>
> >>
> >>>/Loa
> >>>
> >>>P=E4r Mattsson wrote:
> >>>
> >>>>>hi par, one of the possibilities that has been considered=20
> >>
> >>to cope with
> >>
> >>>>>this requirement is to use a dedicated TPID for the=20
> >>
> >>Ethernet labeled
> >>
> >>>>>frames; this would allow differentiated processing with=20
> non-labeled
> >>>>>framesthanks.
> >>>>
> >>>>
> >>>>That seems to make more sence. If that frame is to be sized like =
a
> >>>>802.1q
> >>>>frame. There is not that much space left to a label. Or is 
> >>
> >>the demand to
> >>
> >>>>use jumboframes ?
> >>>>Has there been any discussion on labelstacking, and=20
> mainly where to
> >>>>place
> >>>>the information?
> >>>>
> >>>>Regards.
> >>>>Per
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>--
> >>>Loa Andersson
> >>>
> >>>Principal Networking Architect
> >>>Acreo AB                           phone:  +46 8 632 77 14
> >>>Isafjordsgatan 22                  mobile: +46 739 81 21 64
> >>>Kista, Sweden                      email:  [email-masked]
> >>>                                            [email-masked]
> >>>
> >>
> >>
> >>
> >=20
>=20
>=20
> --=20
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                             [email-masked]
>=20

Delivery-date: Fri, 22 Jul 2005 13:24:34 +0000
To: Loa Andersson <[email-masked]>
Cc: =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>, [email-masked]
From: [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 15:24:10 +0200

Delivery-date: Fri, 22 Jul 2005 13:18:21 +0000
From: Heiles Juergen <[email-masked]>
To: Loa Andersson <[email-masked]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>
Cc: [email-masked]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 15:17:19 +0200

GMPLS for SONET/SDH has no impact on the SONET/SDH data plane. It =
introduces a control plane for connection setup instead of a network =
management based connection setup. GMPLS for Ethernet can work in the =
same way. Ethernet as such is cl, but VLANs are setup and GMPLS can =
provide a control plane for VLAN setup. The Ethernet data plane is not =
changed and MAC address learning and forwarding is still be done within =
a VLAN. So no change to the Ethernet data plane. No GMPLS traffic is =
introduced, it is still VLAN traffic.
Introducing a dedicated GMPLS label for Ethernet (GMPLS traffic) goes =
beyond GMPLS as a control plane technique.

Regards

Juergen

=20

> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Friday, July 22, 2005 12:05 PM
> To: P=E4r Mattsson
> Cc: [email-masked]
> Subject: Re: Frameformat in a l2cs gmpls rnvironment.
>=20
> Per and Dimitri,
>=20
> I would like to come down stronger than that, for me it is
> a very strong requirement that the same switch can handle
> both VLANs and GMPLs trafic correctly. I can't dsee how that
> could be done if using the VLAN tpid to indicate GMPLS
> traffic.
>=20
> /Loa
>=20
> P=E4r Mattsson wrote:
> >>hi par, one of the possibilities that has been considered=20
> to cope with
> >>this requirement is to use a dedicated TPID for the Ethernet =
labeled
> >>frames; this would allow differentiated processing with non-labeled
> >>framesthanks.
> >=20
> >=20
> > That seems to make more sence. If that frame is to be sized=20
> like a 802.1q
> > frame. There is not that much space left to a label. Or is=20
> the demand to
> > use jumboframes ?
> > Has there been any discussion on labelstacking, and mainly=20
> where to place
> > the information?
> >=20
> > Regards.
> > Per
> >=20
> >=20
> >=20
>=20
>=20
> --=20
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                             [email-masked]
>=20

Delivery-date: Fri, 22 Jul 2005 12:57:45 +0000
Date: Fri, 22 Jul 2005 14:53:28 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To:  [email-masked]
CC:  [email-masked],  [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

Richard,

I agree to most of this. Since we have doubts about the viability
of taking GMPLS all the way to end-user or enterprise I think it
would be good, from a wg perspective, if we agreed to solve the
core network problems first.

Do you have any comment on the requirement to run both VLANs and
GMPLS on the same switch?

/Loa

[email-masked] wrote:
> Regardless of whether or not a switch is directly connected
 > to hosts, it must be able to forward packets using the connectionless
 > Ethernet data plane. This is due to the fundamental requirement that
 > for GMPLS switches to be able to exchange control information with
 > each other, a data plane for control traffic must be present.
 > This is akin to using the IP data plane for MPLS signalling in an
 > IP/MPLS network. An alternative would be to use a static reserved
 > L2-LSP for control traffic in the same way that reserved VPI/VCIs
 > are used for PNNI signalling in ATM.
> 
> Regarding connecting hosts to GMPLS switches, I personally don't 
 > think extending L2-LSPs into the enterprise/home network is
 > commercially viable. However, if you do want to use GMPLS switches
 > in the home/enterprise network and for some reason don't want to
 > extend L2-LSPs down to the host then you will not be performing
 > normal Ethernet Mac address switching anyway. Instead you will
 > need some kind of policy on the switch that maps connectionless
 > Ethernet packets (e.g. based on MAC src/dest, 802.1p, VLAN) to a
 > L2-LSP. This is because multiple L2-LSPs to the same destination
 > (e.g. a gateway router) may exist for different services/flows
 > (e.g. video download, VoIP call, etc.).
> 
> Regards,
> Richard
> 
> 
>>From: [email-masked] [mailto:[email-masked]]On
>>Behalf Of Pär Mattsson
>>Sent: 22 July 2005 11:42
>>To: Loa Andersson
>>Cc: [email-masked]
>>Subject: Re: Frameformat in a l2cs gmpls rnvironment.
>>
>>
>>
>>>Per and Dimitri,
>>>
>>>I would like to come down stronger than that, for me it is
>>>a very strong requirement that the same switch can handle
>>>both VLANs and GMPLs trafic correctly. I can't dsee how that
>>>could be done if using the VLAN tpid to indicate GMPLS
>>>traffic.
>>
>>If you ever want that same switch to handle traffic for a directly
>>connected  host (not to uncommen) you would want that to use normal
>>ethernet macaddress switching. So of course you do not want to have to
>>choose between vlan and gmpls, you would want both at the same time.
>>
>>/per
>>
>>
>>
>>>/Loa
>>>
>>>Pär Mattsson wrote:
>>>
>>>>>hi par, one of the possibilities that has been considered 
>>
>>to cope with
>>
>>>>>this requirement is to use a dedicated TPID for the 
>>
>>Ethernet labeled
>>
>>>>>frames; this would allow differentiated processing with non-labeled
>>>>>framesthanks.
>>>>
>>>>
>>>>That seems to make more sence. If that frame is to be sized like a
>>>>802.1q
>>>>frame. There is not that much space left to a label. Or is 
>>
>>the demand to
>>
>>>>use jumboframes ?
>>>>Has there been any discussion on labelstacking, and mainly where to
>>>>place
>>>>the information?
>>>>
>>>>Regards.
>>>>Per
>>>>
>>>>
>>>>
>>>
>>>
>>>--
>>>Loa Andersson
>>>
>>>Principal Networking Architect
>>>Acreo AB                           phone:  +46 8 632 77 14
>>>Isafjordsgatan 22                  mobile: +46 739 81 21 64
>>>Kista, Sweden                      email:  [email-masked]
>>>                                            [email-masked]
>>>
>>
>>
>>
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Fri, 22 Jul 2005 11:46:19 +0000
Content-Class: urn:content-classes:message
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 12:44:08 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Regardless of whether or not a switch is directly connected to hosts, it =
must be able to forward packets using the connectionless Ethernet data =
plane. This is due to the fundamental requirement that for GMPLS =
switches to be able to exchange control information with each other, a =
data plane for control traffic must be present. This is akin to using =
the IP data plane for MPLS signalling in an IP/MPLS network. An =
alternative would be to use a static reserved L2-LSP for control traffic =
in the same way that reserved VPI/VCIs are used for PNNI signalling in =
ATM.

Regarding connecting hosts to GMPLS switches, I personally don't think =
extending L2-LSPs into the enterprise/home network is commercially =
viable. However, if you do want to use GMPLS switches in the =
home/enterprise network and for some reason don't want to extend L2-LSPs =
down to the host then you will not be performing normal Ethernet Mac =
address switching anyway. Instead you will need some kind of policy on =
the switch that maps connectionless Ethernet packets (e.g. based on MAC =
src/dest, 802.1p, VLAN) to a L2-LSP. This is because multiple L2-LSPs to =
the same destination (e.g. a gateway router) may exist for different =
services/flows (e.g. video download, VoIP call, etc.).

Regards,
Richard

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of P=E4r Mattsson
> Sent: 22 July 2005 11:42
> To: Loa Andersson
> Cc: [email-masked]
> Subject: Re: Frameformat in a l2cs gmpls rnvironment.
>=20
>=20
> > Per and Dimitri,
> >
> > I would like to come down stronger than that, for me it is
> > a very strong requirement that the same switch can handle
> > both VLANs and GMPLs trafic correctly. I can't dsee how that
> > could be done if using the VLAN tpid to indicate GMPLS
> > traffic.
>=20
> If you ever want that same switch to handle traffic for a directly
> connected  host (not to uncommen) you would want that to use normal
> ethernet macaddress switching. So of course you do not want to have to
> choose between vlan and gmpls, you would want both at the same time.
>=20
> /per
>=20
>=20
> >
> > /Loa
> >
> > P=E4r Mattsson wrote:
> >>>hi par, one of the possibilities that has been considered=20
> to cope with
> >>>this requirement is to use a dedicated TPID for the=20
> Ethernet labeled
> >>>frames; this would allow differentiated processing with non-labeled
> >>>framesthanks.
> >>
> >>
> >> That seems to make more sence. If that frame is to be sized like a
> >> 802.1q
> >> frame. There is not that much space left to a label. Or is=20
> the demand to
> >> use jumboframes ?
> >> Has there been any discussion on labelstacking, and mainly where to
> >> place
> >> the information?
> >>
> >> Regards.
> >> Per
> >>
> >>
> >>
> >
> >
> > --
> > Loa Andersson
> >
> > Principal Networking Architect
> > Acreo AB                           phone:  +46 8 632 77 14
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > Kista, Sweden                      email:  [email-masked]
> >                                             [email-masked]
> >
>=20
>=20
>=20

Delivery-date: Fri, 22 Jul 2005 10:43:18 +0000
Date: Fri, 22 Jul 2005 12:41:55 +0200 (CEST)
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
From: P=?iso-8859-1?Q?=E4r_Mattsson?= <[email-masked]>
To: "Loa Andersson" <[email-masked]>
Cc: [email-masked]

> Per and Dimitri,
>
> I would like to come down stronger than that, for me it is
> a very strong requirement that the same switch can handle
> both VLANs and GMPLs trafic correctly. I can't dsee how that
> could be done if using the VLAN tpid to indicate GMPLS
> traffic.

If you ever want that same switch to handle traffic for a directly
connected  host (not to uncommen) you would want that to use normal
ethernet macaddress switching. So of course you do not want to have to
choose between vlan and gmpls, you would want both at the same time.

/per

>
> /Loa
>
> Pär Mattsson wrote:
>>>hi par, one of the possibilities that has been considered to cope with
>>>this requirement is to use a dedicated TPID for the Ethernet labeled
>>>frames; this would allow differentiated processing with non-labeled
>>>framesthanks.
>>
>>
>> That seems to make more sence. If that frame is to be sized like a
>> 802.1q
>> frame. There is not that much space left to a label. Or is the demand to
>> use jumboframes ?
>> Has there been any discussion on labelstacking, and mainly where to
>> place
>> the information?
>>
>> Regards.
>> Per
>>
>>
>>
>
>
> --
> Loa Andersson
>
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                             [email-masked]
>

Delivery-date: Fri, 22 Jul 2005 10:28:24 +0000
To: =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Subject: Re:Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 12:27:37 +0200

Delivery-date: Fri, 22 Jul 2005 10:25:22 +0000
Date: Fri, 22 Jul 2005 12:04:53 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: =?ISO-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>
CC:  [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.

Per and Dimitri,

I would like to come down stronger than that, for me it is
a very strong requirement that the same switch can handle
both VLANs and GMPLs trafic correctly. I can't dsee how that
could be done if using the VLAN tpid to indicate GMPLS
traffic.

/Loa

Pär Mattsson wrote:
>>hi par, one of the possibilities that has been considered to cope with
>>this requirement is to use a dedicated TPID for the Ethernet labeled
>>frames; this would allow differentiated processing with non-labeled
>>framesthanks.
> 
> 
> That seems to make more sence. If that frame is to be sized like a 802.1q
> frame. There is not that much space left to a label. Or is the demand to
> use jumboframes ?
> Has there been any discussion on labelstacking, and mainly where to place
> the information?
> 
> Regards.
> Per
> 
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Fri, 22 Jul 2005 09:55:38 +0000
Date: Fri, 22 Jul 2005 11:54:40 +0200 (CEST)
Subject: Re:Re: Frameformat in a l2cs gmpls rnvironment.
From: P=?iso-8859-1?Q?=E4r_Mattsson?= <[email-masked]>
To: [email-masked]

> hi par, one of the possibilities that has been considered to cope with
> this requirement is to use a dedicated TPID for the Ethernet labeled
> frames; this would allow differentiated processing with non-labeled
> framesthanks.

That seems to make more sence. If that frame is to be sized like a 802.1q
frame. There is not that much space left to a label. Or is the demand to
use jumboframes ?
Has there been any discussion on labelstacking, and mainly where to place
the information?

Regards.
Per

Delivery-date: Fri, 22 Jul 2005 09:46:35 +0000
To: =?iso-8859-1?Q?P=E4r_Mattsson?= <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 11:45:34 +0200

Delivery-date: Fri, 22 Jul 2005 09:39:00 +0000
Date: Fri, 22 Jul 2005 11:36:44 +0200 (CEST)
Subject: Frameformat in a l2cs gmpls rnvironment.
From: P=?iso-8859-1?Q?=E4r_Mattsson?= <[email-masked]>
To: [email-masked]

Hi all.
After reading the draft
(draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt) and thinking
for awhile on different ways to implementing this, i was wondering what
alternatives there is for the framformat for this. I understand that one
option is using TPID=8100, but what became of the lokal significant label,
and that all switches should be able to switch current ethernet format at
the same time. How to distinguish between GMPLS and VLAN ?
Do anybody have any comment on this ?

Regards.
Per

Delivery-date: Fri, 22 Jul 2005 04:25:02 +0000
Date: Fri, 22 Jul 2005 13:22:57 +0900
From: Tomohiro Otani <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-00

Hi Dimitri and everyone,

We uploaded 01 version of this draft.
Your comments and feedback are highly appreciated.

With best regards,

tomo

-----------------------------------------------------------------------------
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: GMPLS constraints consideration for CSPF path computation
	Author(s)	: T. Otani, et al.
	Filename	: draft-otani-ccamp-gmpls-cspf-constraints-01.txt
	Pages		: 0
	Date		: 2005-7-21
	
This draft provides the guideline to consider generalized multi-
protocol label switching (GMPLS) traffic-engineering (TE) attributes 
for constraint-based shortest path first (CSPF) path computation at a 
source node in a GMPLS network environment. This draft summarizes 
most possible cases of GMPLS constraint TE attributes at an ingress 
link, transit links and an egress link to establish a GMPLS label 
switched path (LSP) appropriately.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-01.txt

[email-masked] wrote:

>hi,
>
>i would say that 1) should be considered iff there have been several identified 
>misbehaviour detected and inconsistencies observed such that a set of 
>prescriptive guidelines have to be put together (but this would translate some 
>"common" mis-interpretation of the set of documents we currently have)
>
>if this is not the case, then beside some base description/clarification, i 
>don't see how we could turn this into 2) or 3) without obtaining a larger sample 
>of CSPF/routing practices - the difference between 2) and 3) being that in the 
>former case, information gathered is processed to describe practices and devise 
>operational guidelines while in the latter the document appears as a collection 
>of practices from individual practices
>
>in any case, and in order to progress - we need more feedback -
>
> 
>
>thanks,
>
>-dimitri.
>
>
>*Tomohiro Otani <[email-masked]>*
>Sent by: [email-masked]
>07/19/2005 09:48 ZE9
>
>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>cc: [email-masked]
>bcc:
>Subject: Re: 
>http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-00
>
>
>Hi Dimitri,
>
>Per our initial discussion, we would like to formulate
>the unified view on CSPF consideration, and we simply
>thought it is BCP.
>
>Considering more deeply, our draft does not define the
>protocol itself but the protocol related specification
>
>In that sense, you are right, it is prescriptive more
>than descriptive for guiding operations. Moreover, I came
>up my mind that it may be more standard track than informational.
>But I am not sure. What's your thought on this ?
>
>With best regards,
>
>tomo
>
>PS: We posted 01 version.
>
>
>
>
>[email-masked] wrote:
>
> >authors, is the purpose of the above mentioned draft:
> >
> > 1. prescriptive (even if informational)
> >
> > 2. descriptive for guiding operations (BCP)
> >
> > 3. informative (survey-like)
> >
> >from what i read, it is more 1 like - is my understanding correct ?
> >
> >
> >
>
>  
>

Delivery-date: Fri, 22 Jul 2005 01:25:02 +0000
Date: Fri, 22 Jul 2005 10:23:38 +0900
From: Kenji Kumaki <[email-masked]>
To: [email-masked]
Subject: draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt

Hi,

We updated the following draft.

"Operational, Deployment and Interworking Considerations for GMPLS "
http://www.ietf.org/internet-drafts/draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt

Since last draft,we mainly updated the following items.
1. merged "GMPLS Deployment in Existing IP/MPLS networks" draft
http://www.ietf.org/internet-drafts/draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt
2. changed the title of I-D and section due to merge of "GMPLS
Deployment in Existing IP/MPLS networks" draft
3. added MPLS/GMPLS deployment,operational and interworking requirements
as a section
4. added MPLS/GMPLS LSP Resource Affinity Mapping
5. removed section 3.1 OSPF extensions for Link Priority Identification
           section 3.2 ISIS extensions for Link Priority Identification
6. added Terminology
7. category change: BCP
8. corrected some typos 

We welcome your comments and feedback on this list or during Paris
meeting.

Thanks,
Kenji
-- 
Kenji Kumaki <[email-masked]>

Delivery-date: Fri, 22 Jul 2005 00:30:05 +0000
From: [email-masked]
Message-Type: Multiple Part
To: <[email-masked]>
Date: Fri, 22 Jul 2005 09:26:45 +0900
Subject: Re:draft-otani-ccamp-interas-gmpls-te-03.txt (support)

Hi Session Chair and everyone;

We think that "draft-otani-ccamp-interas-gmpls-te-03.txt"
opens a very important scheme in the GMPLS inter-domain
TE requirement for several vendors. We support his proposal 
and hope that the draft would pass through the charter process
and be a WG document as soon as possible.

Regards,

Kazuhiko Sagara
Hitachi
-----------------------------------------------------------------------------
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: GMPLS Inter-domain Traffic Engineering Requirements
	Author(s)	: T. Otani, et al.
	Filename	: draft-otani-ccamp-interas-gmpls-te-03.txt
	Pages		: 15
	Date		: 2005-7-20
	
This draft provides requirements for the support of generalized 
multi-protocol label switching (GMPLS) inter-domain traffic 
engineering (TE). Its main objective is to present the differences 
between MPLS inter-domain TE and GMPLS inter-domain TE.  This draft 
covers not only GMPLS Inter-domain architecture but also functional 
requirements in terms of GMPLS signaling and routing in order to 
specify these in a GMPLS Inter-domain environment.

Delivery-date: Thu, 21 Jul 2005 14:59:17 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 
Bcc: 
Subject: RE: End-to-end L2-LSP
Date: Thu, 21 Jul 2005 23:59:07 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message

Hi, Richard,
 
Thank you for your tons of questions. 
It is a bit hard to answer in single mail. 
So, I divided it in two pieces. 
Here I send you the first part of answers to questions 1~5.

>I agree that extending signalling down to the end-user is one 
>possible solution to address charging/billing issues, another possible 
>solution would be to use session based billing. I also agree that using 
>L2-LSPs could be a viable solution for providing traffic separation 
>and bandwidth guarantees in a service providers network, another 

Indeed, that's one important message I wanted to cast in this WG. 
Not only this is technically interesting, but the behind goal is about 
improving income structure of Internet service providers. 
I hope this can be an answer to the issue of QoS&Pricing 
that Neil Harrison once noted in last mail of this thread.
 
Customers may basically use cl-ps service in fixed rate base, and 
when they need real-time service such as IP-TV or video phone, 
they may request simple CBR-like co-ps SVC-based service 
(i.e. L2-LSP) over cl-ps network using GMPLS signal. 
This way, operators may improve their service structure and invest 
to upgrade their access network.

[snip]
>1. If you want to eliminate the possibility of congestion in the 
>enterprise/home network using L2-LSPs for the reasons you 
>give below, then on every node in the network you will need: 
> 
>- A CPU: for control plane protocol processing 
>- Routing: At least static, an IGP for large networks and 
>OSPF-TE if TE is required 
>- Signalling: RSVP-TE 
>- Policing: Per connection policing, e.g. per VLAN 
> 
>I do not know how much it would cost to upgrade the $20 five 
>port 10/100 switch sitting on my desk to support all this, 
>but I do not believe this would be a trivial amount, particularly 
>at the volumes demanded by enterprises. 

I guess your five port $20 switch will be connected to machines 
owned only by you. If you can control resource usage of your 
machines, you don't need GMPLS implemented switch. 
However, if you need to share a switch with some of your colleague, 
I will recommend spending more that $20 on switch in order to enjoy 
nice video communication while your colleague abusing your 
network with P2P file transfer. I think this is worth while to spend 
money considering importance of your personal communication. 
As I noted in previous mail, GMPLS implemented switch will be 
necessary in nodes where automated resource control is crucial.

>In addition, a hierarchical 
>architecture would be required for the solution to scale and 
>therefore aggregation switches within the enterprise network 
>would also need to support hierarchical CAC and policing.

This is beyond issue we can discuss at the moment. 
I'd like further technical discussion, however, 
I think we need to wait until this idea of L2-LSP is 
officially chartered in CCAMP. 
I hope enough number of people support the idea that 
we can continue work on this issue.

>2. Unless you want to reinvent LANE, then you will need to 
>continue to support CL Ethernet broadcasts and multicasts on 
>GMPLS enabled switches. To protect the L2-LSP traffic from 
>CL broadcast traffic you could rate limit it to say 1% of 
>the bandwidth available. However, how would you capacity 
>plan for and rate limit (dynamic, receiver driven) multicast 
>traffic for which usage patterns are difficult to predict? 
>In my opinion you will need to use over provisioning along with CoS, 
>which would raise the question, why is over provisioning 
>and CoS OK for multicast traffic 
>(which could be critical, e.g. trading floor information), 
>but not OK for unicast traffic?

There will be a technical solution for multicast and broadcast. 
A member of DT once showed his interest on multicast solution 
for Ethernet using RSVP instead of IGMP. 
I also have an idea of extending point-to-point L2-LSP to 
multipoint L2-LSP as similar way that learning bridges 
learn backward path from source address.

However, I have some doubt on necessity of multicast service. 
Do we really need multicast for streaming service in local/access ? 
I think even IP-TV will be better serviced using point-to-point 
connection in access network. 
There's very low chance of two subscribers receiving same channel 
at the same time if the receiver group is not that great. 
Multicasting is necessary in core network, however I doubt the 
same needs in local/access network, except some rare case.
 
>3. Routers are relatively stable systems that are switched on 
>permanently and therefore RSVP-TE sessions are stable 
>and only go down when there is a failure. End user systems 
>however such as PCs, set top boxes, games consoles, etc. 
>are not always switched on and are not as stable. 
>What will the effect on the network be when large number 
>of RSVP-TE sessions are going up/down, e.g. as a result 
>of game console resets or PC crashes/freezes? 
>These effects will ripple through the enterprise/home 
>network into the operators network, and therefore mechanisms 
>must be put in place to protect against them.

Control overhead of RSVP was discussed a lot in conjunction with IntServ. 
There have been proposals to reduce the overhead in core network 
such as RFC3175 or [HIER]. In particular, proposed architecture for 
LSP aggregation [HIER] will greatly help to solve the issue.

% [HIER] draft-ieft-mpls-lsp-hierarchy-08.txt

>4. When an IP device wants to forward a packet it uses ARP 
>to discover the MAC address of the IP next hop 
>(unless its already in the MAC table) and adds the Ethernet 
>header before forwarding the packet on. Now, if you want to 
>extend connections down to the end user device, then the 
>device will need to map IP traffic to different L2-LSPs. 
>A simple 1-to-1 mapping between an IP next hop address 
>and a MAC address will not be sufficient as there may 
>be multiple connections (e.g. using different VLAN IDs) 
>associated with an IP next hop. So, policies will need 
>to be configured on end user devices to map IP traffic 
>(e.g. based on src/dest IP address, port numbers, etc.) 
>to a specific L2-LSP (e.g. based on src/dest MAC address and/or VLAN ID). 

You pointed out important issue. 
Currently, Ethernet layer only maps IP and MAC in 1-to-1. 
Unless Ethernet-IP interface is extended as you suggested, 
users must be satisfied with at most single L2-LSP established 
between machine to machine. If they want another connection, 
they have to disconnect previous connection. 
This scenario will be OK in most real-life applications. 
However in future, extension to layer interface will be necessary 
and the solution should be consulted with IEEE.

>5. End user devices such as PCs and VoIP phones are 
>likely to only need to support a relatively low number 
>of L2-LSPs. However, devices such as content servers 
>and call servers/gateways will need to support 
>hundreds/thousands of L2-LSPs. Connection setup and 
>state maintenance for large numbers of L2-LSPs will 
>consume a significant amount of processing resources, 
>as will policies to map IP traffic to the different L2-LSPs. 
>Therefore, I would expect that the system software 
>(and possibly hardware) will need to be designed from 
>the ground up to be able to support large numbers of L2-LSPs.

Some high-performance servers are capable of handling 
millions of TCP connections. 
I believe the added complexity for LSP connection 
will not be far greater that the work-load normally assumed 
in contemporary servers.

It may be a problem to local gateways if the signaling load 
is not bypassed. However, even in this case, there can be 
some solutions we can devise.
ok, for rest of questions, 
I'll reply it in next mail. 

thanks

Jaihyung 

-----?? ???----- 
?? ??: "[email-masked]" <[email-masked]> 
?? ??: 2005-07-21 ?? 12:09:56 
?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: 
??: RE: End-to-end L2-LSP 

Jaihyung, 

I agree that extending signalling down to the end-user is one possible solution to address charging/billing issues, another possible solution would be to use session based billing. I also agree that using L2-LSPs could be a viable solution for providing traffic separation and bandwidth guarantees in a service providers network, another possible solution would be to extended MPLS into the access network. 

However, if you want to extend L2-LSPs (not just signalling) down to the end user, then there are a number of complicated technical and commercial issues that must be overcome. Please see below for some of the key issues: 

1. If you want to eliminate the possibility of congestion in the enterprise/home network using L2-LSPs for the reasons you give below, then on every node in the network you will need: 

- A CPU: for control plane protocol processing 
- Routing: At least static, an IGP for large networks and OSPF-TE if TE is required 
- Signalling: RSVP-TE 
- Policing: Per connection policing, e.g. per VLAN 

I do not know how much it would cost to upgrade the $20 five port 10/100 switch sitting on my desk to support all this, but I do not believe this would be a trivial amount, particularly at the volumes demanded by enterprises. In addition, a hierarchical architecture would be required for the solution to scale and therefore aggregation switches within the enterprise network would also need to support hierarchical CAC and policing. 

2. Unless you want to reinvent LANE, then you will need to continue to support CL Ethernet broadcasts and multicasts on GMPLS enabled switches. To protect the L2-LSP traffic from CL broadcast traffic you could rate limit it to say 1% of the bandwidth available. However, how would you capacity plan for and rate limit (dynamic, receiver driven) multicast traffic for which usage patterns are difficult to predict? In my opinion you will need to use over provisioning along with CoS, which would raise the question, why is over provisioning and CoS OK for multicast traffic (which could be critical, e.g. trading floor information), but not OK for unicast traffic? 

3. Routers are relatively stable systems that are switched on permanently and therefore RSVP-TE sessions are stable and only go down when there is a failure. End user systems however such as PCs, set top boxes, games consoles, etc. are not always switched on and are not as stable. What will the effect on the network be when large number of RSVP-TE sessions are going up/down, e.g. as a result of game console resets or PC crashes/freezes? These effects will ripple through the enterprise/home network into the operators network, and therefore mechanisms must be put in place to protect against them. 

4. When an IP device wants to forward a packet it uses ARP to discover the MAC address of the IP next hop (unless its already in the MAC table) and adds the Ethernet header before forwarding the packet on. Now, if you want to extend connections down to the end user device, then the device will need to map IP traffic to different L2-LSPs. A simple 1-to-1 mapping between an IP next hop address and a MAC address will not be sufficient as there may be multiple connections (e.g. using different VLAN IDs) associated with an IP next hop. So, policies will need to be configured on end user devices to map IP traffic (e.g. based on src/dest IP address, port numbers, etc.) to a specific L2-LSP (e.g. based on src/dest MAC address and/or VLAN ID).  

5. End user devices such as PCs and VoIP phones are likely to only need to support a relatively low number of L2-LSPs. However, devices such as content servers and call servers/gateways will need to support hundreds/thousands of L2-LSPs. Connection setup and state maintenance for large numbers of L2-LSPs will consume a significant amount of processing resources, as will policies to map IP traffic to the different L2-LSPs. Therefore, I would expect that the system software (and possibly hardware) will need to be designed from the ground up to be able to support large numbers of L2-LSPs. 

6. Enterprise networks are built using not just switches but routers as well. Firstly, for L2-LSPs to be set up between switches and routers, they must belong to the same address space to communicate with each other. However, this address space must be separate from the IPv4 forwarding address space. To use an example of why this is true, routers connected via Ethernet segments are considered to be directly connected, however, if the IPv4 and L2-LSP address spaces were the same, then IP routers separated by GMPLS switches would be multiple hops away from each other. In addition to address space separation, routing protocol instances must also be separated. This need for this separation is obvious when considering using a link state routing protocol which relies on a topological view of the network, i.e. the IPv4 and L2-LSP topologies are different. 

Secondly, routers break up Ethernet segments and must therefore must always be the headend or tailend for a L2-LSPs, i.e. they cannot be midpoints. This means that from a control plane perspective, on receiving a L2-LSP path message a router must terminate the LSP and send back a resv message whether it is the intended destination/sink or not. It must then originate a path message for a new L2-LSP and send it onto the next hop GMPLS switch. This is not how RSVP-TE works today and therefore will require modifications. In addition, traffic will be blackholed if transmitted by the source before all the separate L2-LSPs have been setup end-to-end to the sink/destination. This means that some kind of end-to-end signalling message will need to be sent by the sink/destination once the final L2-LSP has been established to inform the source that the end-to-end connectivity has been provided. This functionality is not supported by RSVP-TE today and will therefore require protocol modifications. 

Thirdly, routers forward packets based on information in the IP header. So, when a router receives a packet via a L2-LSP it will strip of the L2 header and perform an IP lookup. Now, for the packet to be forwarded using the correct L2-LSP the router must have a policy that tells it which L2-LSP to use as there may be multiple L2-LSPs to the same destination, e.g. for different voice calls or video downloads. However, before a policy can even be configured, the router needs to know what traffic (e.g. based on src/dest address, port number, DSCP, etc.) to map to which L2-LSP, and this information needs to come from the traffic source using signalling, i.e. RSVP-TE. I do not believe this is supported today and will therefore require modifications. 

Regards, 
Richard 

> From: CHO, JAI HYUNG [mailto:[email-masked]] 
> Sent: 14 July 2005 04:24 
> To: Spencer,R,Richard,XDE73 R; [email-masked] 
> Subject: RE: End-to-end L2-LSP 
> 
> Dear Richard, 
> 
> See in-line please, 
> 
> >Thank you for taking the time to respond to my questions. I 
> anticipated 
> >that your response would include "over-provisioning is the 
> best answer" 
> >to decrease the chance of congestion on non-GMPLS switches. 
> >This is what is done in the LAN environment today in 
> conjunction with CoS, 
> >and this is why I believe there will be two opposing views on how 
> >far L2-LSP connections should be extended down to the user. One view 
> >is that over provisioning and CoS work fine in the 
> enterprise network today, 
> >and therefore the L2-LSP should only be extended down to the point 
> >at which the enterprise network connects to the SP network, 
> >e.g. Ethernet DSLAM. I think the other view will be that 
> over provisioning 
> >and CoS in the enterprise network don't work and therefore L2-LSPs 
> >should be provided end-to-end using only GMPLS capable switches. 
> >I wouldn't have thought there would be much call for mixed 
> >GMPLS/non-GMPLS enterprise networks (except for during migration) 
> >due to the opposing views, e.g. if over provisioning is good 
> enough for 
> >one switch, why isn't it good enough for the other? 
> 
> Over-provisioned network is non-guaranteed network. It can't prevent 
> occasional congestion at any rate. Further, network condition 
> in private 
> network is very diverse. You can't predict minimum service level 
> inside every private network. 
> 
> Suppose that an ISP want to provide high-quality, video-phone service 
> for enterprise users. Nothing can be guaranteed inside the 
> over-provisioned 
> customer network. If the service level is not satisfactory, 
> customers will complain 
> to service provider even if the main cause is in his network 
> or destination network. 
> We need some structure that coordinate service quality in 
> both private sector, 
> as well as in public sector consistently. 
> An end-to-end signal is an effective means to communicate between 
> user terminal, private switches and provider switches, and 
> concert service 
> quality at each different operations network. This is a goal 
> that RSVP (RFC2205) 
> pursued, however ineffective in local network because 
> Ethernet industry 
> didn't support RSVP over Ethernet (RFC2814, 2815, 2816). 
> Now we have another opportunity to realize the goal using L2-LSP. 
> Therefore, I believe end-to-end LSP is necessary even in 
> enterprise network 
> for the purpose of providing guaranteed commercial service. 
> 
> >I think where most people will agree is that using connections 
> >in the SPs access network does make sense in order to 
> provide efficient 
> >link utilisation and per connection policing to ensure one customers 
> >traffic can not affect another's. Regarding the ability to 
> set up new 
> >connections based on a request from the user (rather than 
> constraining 
> >RSVP signalling to inside the SP network), I think this will come 
> >down to enterprise customer demand for improved service performance. 
> >If a customer wasn't getting the performance they needed from their 
> >SP and was offered a new service that allowed them to setup 
> new L2-LSP 
> >connections on demand that would offer better performance 
> (e.g. for voice 
> >calls or video conferences), then upgrading the user devices 
> to support 
> >the new service could well be an attractive proposition. If 
> on the other 
> 
> Yes, this will be one of prospective service newly enabled 
> using L2-LSP. 
> 
> >hand a customer buys a best effort service and considers the 
> performance 
> >to be 'good enough', then there would be no reason to go to 
> the expense 
> >of upgrading the user devices to support the set up of L2-LSPs. 
> 
> Ever increasing besteffort bandwidth will eventually not satisfy 
> both providers and customers for many reasons. Service providers 
> will have difficulty in collecting expenses enough to invest 
> on increased 
> bandwidth. This will in turn gradually downgrade overall 
> communication quality, 
> and applications requiring real-time service will never 
> satisfy customers. 
> We already see such symptom in some low-price service providers. 
> I believe new service structure that can provide difference 
> of service 
> quality will offer benefit to customers, providers as well as 
> vendors in the end. 
> 
> I also look forward to see you at Paris and continue helpful 
> discussion. 
> 
> Sincerely 
> 
> Jaihyung 
> 
> 
>  
> 
> Dr. Jaihyung Cho 
> ETRI, Korea 
> phone :       042) 860-5514 
> oversea: +82-42-860-5514 
> fax:         +82-42-861-5550 
> 
> 
> 
> 
> -----?? ???----- 
> ?? ??: "[email-masked]" <[email-masked]> 
> ?? ??: 2005-07-14 ?? 1:10:30 
> ?? ??: "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]> 
> ??: 
> ??: RE: End-to-end L2-LSP 
> 
> 
> 
> Jaihyung, 
> 
> Thank you for taking the time to respond to my questions. I 
> anticipated that your response would include 
> "over-provisioning is the best answer" to decrease the chance 
> of congestion on non-GMPLS switches. This is what is done in 
> the LAN environment today in conjunction with CoS, and this 
> is why I believe there will be two opposing views on how far 
> L2-LSP connections should be extended down to the user. One 
> view is that over provisioning and CoS work fine in the 
> enterprise network today, and therefore the L2-LSP should 
> only be extended down to the point at which the enterprise 
> network connects to the SP network, e.g. Ethernet DSLAM. I 
> think the other view will be that over provisioning and CoS 
> in the enterprise network don't work and therefore L2-LSPs 
> should be provided end-to-end using only GMPLS capable 
> switches. I wouldn't have thought there would be much call 
> for mixed GMPLS/non-GMPLS enterprise networks (except for 
> during migration) due to the opposing views, e.g. if over 
> provisioning is good enough for one switch, why isn't it good 
> enough for the other? 
> 
> I think where most people will agree is that using 
> connections in the SPs access network does make sense in 
> order to provide efficient link utilisation and per 
> connection policing to ensure one customers traffic can not 
> affect another's. Regarding the ability to set up new 
> connections based on a request from the user (rather than 
> constraining RSVP signalling to inside the SP network), I 
> think this will come down to enterprise customer demand for 
> improved service performance. If a customer wasn't getting 
> the performance they needed from their SP and was offered a 
> new service that allowed them to setup new L2-LSP connections 
> on demand that would offer better performance (e.g. for voice 
> calls or video conferences), then upgrading the user devices 
> to support the new service could well be an attractive 
> proposition. If on the other hand a customer buys a best 
> effort service and considers the performance to be 'good 
> enough', then there would be no reason to go to the expense 
> of upgrading the user devices to support the set up of L2-LSPs. 
> 
> I look forward to the discussions in Paris. 
> 
> Regards, 
> Richard 
> 
> > From: CHO, JAI HYUNG [mailto:[email-masked]] 
> > Sent: 13 July 2005 15:14 
> > To: Spencer,R,Richard,XDE73 R; [email-masked] 
> > Subject: RE: End-to-end L2-LSP 
> > 
> > 
> >  
> >  
> > Dear Richard Spencer 
> >  
> > see in-line 
> >  
> > >Jaihyung, 
> > > 
> > >Perhaps I'm becoming too much of a pessimist;-) 
> >  
> > oh, not at all, 
> > you are reasonable enough to dig up unclear knowledge 
> > please go ahead until you finally get satisfactory answer. 
> >  
> > 
> > >Ignoring the commercial aspects, please can you help clarify 
> > a few technical 
> > >questions I have in order to help me gain a better 
> > understanding of the proposal? 
> > > 
> > >1. You say that one of the key reasons for using GMPLS in 
> > the enterprise 
> > >network is to provide end-to-end QoS control. However, you 
> > also say that not 
> > >all the switches will need to support GMPLS, only those at 
> > bottle necks. 
> > >Please can you expand on this to explain how you can have 
> end-to-end 
> > >QoS control when the L2-LSP is not end-to-end? 
> >  
> > 
> > The contextual meaning of 'End-to-end LSP' is that GMPLS label is 
> > assigned from source terminal and removed at destination terminal, 
> > because RSVP-TE message is exchanged from host to host. 
> > It may not perfectly guarantee QoS when the GMPLS deployment 
> > is not complete, however it will at least be good enough 
> > for end-user applications to tell those GMPLS implemented 
> L2 switches 
> > what frame must be given priority service when congestion occur. 
> >  
> > 
> > >As being discussed 
> > >on the PWE3 mailing list, the performance a service receives 
> > is only as 
> > >good as the worst performing server layer. Therefore, if 
> there is a 
> > >standard 802.1 workgroup switch between the user and the 
> > L2-LSP that is 
> > >experiencing congestion (e.g. due to a large amount of 
> > peer-to-peer traffic), 
> > >then the QoS that the user receives will only be as good as 
> > that provided 
> > >by the congested workgroup switch. 
> >  
> > 
> > of course, ETH-GMPLS does not prevent congestion inevitably 
> occurring 
> > in those non-GMPLS deployed part. 
> >  
> > 
> > >The only way I can see a network using a mixture of GMPLS 
> > and non-GMPLS 
> > >switches guaranteeing end-to-end QoS would be to design the 
> > network in 
> > >such a way that the non-GMPLS switches could never become 
> congested. 
> >  
> > 
> > Yes, that will be the way wise network designer improve 
> their network. 
> >  
> > 
> > >To do this would require that RSVP requests be used for ALL 
> > traffic flows 
> > >to ensure that there was enough bandwidth available, along 
> > with strict 
> > >per L2-LSP policing on the user devices (e.g. PC). 
> > >However, the obvious flaw in this approach is that someone could 
> > >just come along and connect 
> > >an end device to a non-GMPLS switch and start transmitting traffic 
> > >(without performing CAC/policing) causing the switch to 
> > become congested. 
> > >Therefore, please can you explain how end-to-end QoS can be 
> > guaranteed 
> > >in a mixed non-GMPLS and GMPLS switching environment? 
> >  
> > 
> > Of course traffic came from non controlled ingress can not be 
> > prevented 
> > in non-GMPLS node. There's no magic. Only the 
> > over-provisioning is the 
> > best answer. However, once the aggregated traffic pass 'ANY' one of 
> > GMPLS enabled node, those uncontrolled traffic will suffer 
> > queuing discipline. 
> >  
> > 
> > >2. Section 5.1 currently states "When the customer initiates 
> > data transmission, 
> > >the access switch maps the user flow into the L2 LSP. 
> > Mapping procedure is 
> > >subject to implementation choices, and is out of the scope of this 
> > >document." In order to be able to map any traffic, first of 
> > all the switch needs 
> > >to know what type of traffic (e.g. based on source/dest MAC, 
> > VLAN ID, 802.1p 
> > >bits, etc) should be mapped to the L2-LSP. In Figure 1, if 
> > an L2-LSP is set up 
> > >from the DSLAM to the edge router based on a request from 
> > the user (e.g. via 
> > >a PC or VoIP phone), then won't the user also need to signal 
> > what type of 
> > >traffic should to be mapped to the L2-LSP? 
> >  
> > 
> > Thank you for pointing out important thing. 
> > That's the most unfortunate part I reluctantly agreed because the 
> > work condition in the framework DT was not to span L2-LSP 
> > beyond provider network. 
> > As you noticed, mapping user traffic at provider access is awkward. 
> > A smooth method will be for user terminal aware of the L2 label 
> > to use by receiving RSVP-TE message. 
> > However, there was strong argument that RSVP-TE must not 
> > go beyond provider network because the DT is not chartered 
> > to work in customer network. 
> > That's why I requested amendment of CCAMP charter 
> > to include user terminal explicitly in CCAMP work scope, so that 
> > avoid such silly argument in future. 
> >  
> > 
> > >3. In section 5.1, the text states that the aggregation 
> > switch between the 
> > >DSLAM and edge router may be a 802.1 switch, i.e. it doesn't 
> > have to support 
> > >GMPLS. To set up a connection, first of all there needs to 
> > be a data plane 
> > >capable of carrying control plane traffic between GMPLS 
> > peers. Secondly, 
> > >the GMPLS peers need reachability information in order to 
> > forward control 
> > >messages onto the next peer (i.e. a static or IGP route). If 
> > the GMPLS peers 
> > >(e.g. the DSLAM and edge router in Figure 1) are not 
> > directly connected, 
> > >then the GMPLS control packets will need to be forwarded by 
> > the 802.1 switch. 
> > >Would the idea be to have say a "control traffic VLAN" 
> > configured between the 
> > >DSLAM and edge router via the transit 802.1 switch so that 
> > control packets 
> > >could be forwarded transparently by the 802.1 switch? 
> >  
> > 
> > Although it doesn't preclude use of VLAN, I think such 
> > special configuration 
> > for RSVP-TE control message is not necessary in legacy switches. 
> > Legacy switches only need to pass RSVP-TE messages as they 
> > pass normal data frames. Only the GMPLS implemented switches 
> > need to distinguish frames containing RSVP-TE messages and 
> > snoop them. 
> > Detail of implementation is, of course, for future discussion. 
> >  
> > 
> > >4. If we assume that control messages can be transparently 
> forwarded 
> > >by the intermediate 802.1 aggregation switch then how are 
> > user frames 
> > >forwarded in the data plane by the 802.1 switch? 
> >  
> > 
> > Legacy switches do not distinguish control/data frames. 
> >  
> > 
> > >If the DSLAM sets up a L2-LSP 
> > >to the edge router using say VLAN ID 99, how does the switch 
> > know that any 
> > >packets coming in with a VLAN ID of 99 should be forwarded 
> > out of the port 
> > >connecting to the edge router? 
> >  
> > 
> > oh, you misunderstood the L2-LSP. 
> > The question you are asking depends on how L2 label is encoded. 
> > there was hot debate in the DT about the issue how L2 label 
> > is encoded. 
> > My proposal is to use part of MAC address for label and the 
> > other people 
> > argued to use VLAN ID for label. The debate was not concluded 
> > because the goal of the L2SC framework document is not to select 
> > implementation method but to draw necessary work scope. 
> > I believe this issue will be dealt in depth after Paris meeting. 
> > So, please reserve your question until then and ask to those 
> > VLAN proponents. 
> >  
> > 
> > >5. During connection setup, I take it that the GMPLS peers 
> > assume that 
> > >resources are available within the intermediate 802.1 switch 
> > to support 
> > >the connection (as its transparent). However, as there is no 
> > >CAC/policing being performed by the 802.1 switch 
> > >(the L2-LSPs are transparent), and due to the any-to-any and 
> > broadcast 
> > >based nature of Ethernet (i.e. its CL properties), then 
> how can this 
> > >assumption be made? This comes back to my original question, how 
> > >can end-to-end QoS be guaranteed in an environment where there is 
> > >a mixture of 802.1 and GMPLS enabled switches? 
> >  
> > 
> > yes, you came back to the question I answered in above ;-) 
> > so, please see above. 
> > GMPLS enabled nodes must be positioned at points congestion 
> > is likely to be expected. 
> >  
> > Thanks 
> >  
> > Jaihyung 
> >  
> > 
> > ============================================ 
> > 
> >  
> > 
> > -----?? ???----- 
> > ?? ??: "[email-masked]" <[email-masked]> 
> > ?? ??: 2005-07-13 ?? 8:53:13 
> > ?? ??: "[email-masked]" <[email-masked]>, 
> > "[email-masked]" <[email-masked]> 
> > ??: 
> > ??: RE: End-to-end L2-LSP 
> > 
> > 
> > 
> > 
> > Jaihyung, 
> > 
> > Perhaps I'm becoming too much of a pessimist;-) Ignoring the 
> > commercial aspects, please can you help clarify a few 
> > technical questions I have in order to help me gain a better 
> > understanding of the proposal? 
> > 
> > 1. You say that one of the key reasons for using GMPLS in the 
> > enterprise network is to provide end-to-end QoS control. 
> > However, you also say that not all the switches will need to 
> > support GMPLS, only those at bottle necks. Please can you 
> > expand on this to explain how you can have end-to-end QoS 
> > control when the L2-LSP is not end-to-end? As being discussed 
> > on the PWE3 mailing list, the performance a service receives 
> > is only as good as the worst performing server layer. 
> > Therefore, if there is a standard 802.1 workgroup switch 
> > between the user and the L2-LSP that is experiencing 
> > congestion (e.g. due to a large amount of peer-to-peer 
> > traffic), then the QoS that the user receives will only be as 
> > good as that provided by the congested workgroup switch. 
> > 
> > The only way I can see a network using a mixture of GMPLS and 
> > non-GMPLS switches guaranteeing end-to-end QoS would be to 
> > design the network in such a way that the non-GMPLS switches 
> > could never become congested. To do this would require that 
> > RSVP requests be used for ALL traffic flows to ensure that 
> > there was enough bandwidth available, along with strict per 
> > L2-LSP policing on the user devices (e.g. PC). However, the 
> > obvious flaw in this approach is that someone could just come 
> > along and connect an end device to a non-GMPLS switch and 
> > start transmitting traffic (without performing CAC/policing) 
> > causing the switch to become congested. Therefore, please can 
> > you explain how end-to-end QoS can be guaranteed in a mixed 
> > non-GMPLS and GMPLS switching environment? 
> > 
> > 2. Section 5.1 currently states "When the customer initiates 
> > data transmission, the access switch maps the user flow into 
> > the L2 LSP. Mapping procedure is subject to implementation 
> > choices, and is out of the scope of this document." In order 
> > to be able to map any traffic, first of all the switch needs 
> > to know what type of traffic (e.g. based on source/dest MAC, 
> > VLAN ID, 802.1p bits, etc) should be mapped to the L2-LSP. In 
> > Figure 1, if an L2-LSP is set up from the DSLAM to the edge 
> > router based on a request from the user (e.g. via a PC or 
> > VoIP phone), then won't the user also need to signal what 
> > type of traffic should to be mapped to the L2-LSP? 
> > 
> > 3. In section 5.1, the text states that the aggregation 
> > switch between the DSLAM and edge router may be a 802.1 
> > switch, i.e. it doesn't have to support GMPLS. To set up a 
> > connection, first of all there needs to be a data plane 
> > capable of carrying control plane traffic between GMPLS 
> > peers. Secondly, the GMPLS peers need reachability 
> > information in order to forward control messages onto the 
> > next peer (i.e. a static or IGP route). If the GMPLS peers 
> > (e.g. the DSLAM and edge router in Figure 1) are not directly 
> > connected, then the GMPLS control packets will need to be 
> > forwarded by the 802.1 switch. Would the idea be to have say 
> > a "control traffic VLAN" configured between the DSLAM and 
> > edge router via the transit 802.1 switch so that control 
> > packets could be forwarded transparently by the 802.1 switch? 
> > 
> > 4. If we assume that control messages can be transparently 
> > forwarded by the intermediate 802.1 aggregation switch then 
> > how are user frames forwarded in the data plane by the 802.1 
> > switch? If the DSLAM sets up a L2-LSP to the edge router 
> > using say VLAN ID 99, how does the switch know that any 
> > packets coming in with a VLAN ID of 99 should be forwarded 
> > out of the port connecting to the edge router? 
> > 
> > 5. During connection setup, I take it that the GMPLS peers 
> > assume that resources are available within the intermediate 
> > 802.1 switch to support the connection (as its transparent). 
> > However, as there is no CAC/policing being performed by the 
> > 802.1 switch (the L2-LSPs are transparent), and due to the 
> > any-to-any and broadcast based nature of Ethernet (i.e. its 
> > CL properties), then how can this assumption be made? This 
> > comes back to my original question, how can end-to-end QoS be 
> > guaranteed in an environment where there is a mixture of 
> > 802.1 and GMPLS enabled switches? 
> > 
> > Thanks, 
> > Richard 
> > 
> > > From: CHO, JAI HYUNG [mailto:[email-masked]] 
> > > Sent: 12 July 2005 09:21 
> > > To: Spencer,R,Richard,XDE73 R; [email-masked] 
> > > Subject: RE: End-to-end L2-LSP 
> > > 
> > > 
> > > 
> > > 
> > > Dear Richard, 
> > > 
> > > Yes, I believe it is not only commercially profitable but it 
> > > may also grow total 
> > > revenue of service operators by introducing new services. 
> > > 
> > > For example, think the example of IP phone you referred. 
> > > How do you think you can provide reliable VoIP service and 
> > > safely authenticate phone users and charge fees as counted by 
> > > packet usage 
> > > using simple Ethernet based xDSL network ? 
> > > 
> > > There's hardly new service that providers may offer using 
> > > Ethernet based 
> > > architecture, and collect sufficient profit to investment. 
> > > 
> > > A sophisticated ATM switch might do the work if it is not 
> > expensive. 
> > > However, my intension is modifiying existing design of 
> > > Ethernet hardware 
> > > with a little bit additional cost,  and provide the level of 
> > > service that 
> > > ATM switches might offer. 
> > > 
> > > We have initial design of the Ethernet-MPLS hardware. I 
> don't think 
> > > GMPLS enabled Ethernet switch will be so complex. The 
> market price 
> > > of GMPLS enabled switch will not be so expensive than normal 
> > > Ethernet switches. 
> > > 
> > > Further, it only requires upgrade of switches in some 
> > > bottleneck points of network. 
> > > Read the framework documents of L2SC. It doesn't require 
> > > entire replacement 
> > > of switches to introduce new service. 
> > > 
> > > Every year, ISPs purchase new access switches and replaces 
> > > old machines. 
> > > With a bit additional cost, ISPs may use the GMPLS enabled 
> > switch for 
> > > normal Ethernet switching in initial deployment. 
> > > 
> > > When the GMPLS function is enabled in some upgraded part of 
> > network, 
> > > ISPs may provide high quality, reliable VoIP service to 
> > xDSL customers 
> > > using RSVP-TE enabled VoIP phone. 
> > > The high quality video-phone service enabled by GMPLS will be 
> > > competable to legacy voice only phone service. 
> > > 
> > > 
> > > There are lots of things I can argue about commercial aspects 
> > > of this technique. 
> > > However I don't think it is not appropriate to discuss this 
> > > issue in this mailing list. 
> > > All I can say is, 
> > > yes, I believe that it may be commercially viable. 
> > > 
> > > 
> > > Thanks 
> > > 
> > > Jaihyung 
> > > 
> > > ================================================ 
> > > 
> > > Do you really think the benefits of extended GMPLS down to 
> > > the end user could ever justify the costs involved in 
> > > upgrading LAN switches and things like IP phones (simple low 
> > > cost commodity items) to support GMPLS signalling/routing? 
> > > 
> > > Your proposal may be technically possible (though it would 
> > > require new hardware and significant software upgrades), but 
> > > commercially I would consider this to be a non-starter. 
> > > 
> > > Regards, 
> > > Richard 
> > > 
> > > > From: [email-masked] 
> > [mailto:[email-masked]]On 
> > > > Behalf Of CHO, JAI HYUNG 
> > > > Sent: 12 July 2005 01:10 
> > > > To: [email-masked] 
> > > > Subject: End-to-end L2-LSP 
> > > > 
> > > > 
> > > >  
> > > > Dear all, 
> > > > 
> > > > Greetings. 
> > > > 
> > > > I am a co-editor of the Ethernet-GMPLS framework document. 
> > > > (draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt) 
> > > > 
> > > > I am writing this to explain the motivation behind the 
> > > > proposal of scenario-1, and to raise the issue of 
> > > > end-to-end LSP to be included in CCAMP charter. 
> > > > 
> > > > An important goal intended in scenario-1 is 
> > > > QoS control over end-to-end packet delivery using LSP. 
> > > > In other words, the purpose of scenario-1 is extending coverage 
> > > > of GMPLS control including customer network and 
> end-user device, 
> > > > such as PC, VoIP phone, IP-TV, or even future 4G mobile phone. 
> > > > End-user applications will have a means to request resources 
> > > > to network using GMPLS signal. 
> > > > 
> > > > Unfortunately, this view is not included in the 
> > > > framework because there was strong opinion that 
> > > > L2-LSP must not span beyond provider network because 
> > > > CCAMP is not chartered to work on customer 
> > > > network. I am wondering if this is right argument. 
> > > > Perhaps the charter can be amended to include this work. 
> > > > 
> > > > I believe there is little technical reason to preclude 
> > > > LSP being used in customer network. It is a reasonable 
> > > > assumption that private company may also use GMPLS 
> > > > implemented Ethernet switch, once the L2SC work is successful. 
> > > > Currently, CCAMP is the only place discussing the matter of 
> > > > Ethernet and LSP. There is no other WG dealing similar issue. 
> > > > If CCAMP wants to work on Ethernet, 
> > > > I think the coverage of common GMPLS control must be 
> > > > extended to include all area where Ethernet is deployed. 
> > > > Currently, Ethernet is dominantly deployed in first-mile 
> > > > network where access network as well as customer network 
> > > > and user hosts are usually included. Therefore, user host must 
> > > > be considered as initiation and termination point of L2-LSP. 
> > > > 
> > > > Another important reason to include user host in CCAMP 
> > > > work scope is to achieve consistent end-to-end control of QoS. 
> > > > End-to-end QoS has long been desired goal since RSVP was 
> > > > first designed. This goal can be best achieved using 
> > > > end-to-end GMPLS signal and L2-LSP. 
> > > > Currently, RSVP (RFC2205) is available in many user hosts. 
> > > > There is only a little difference between RSVP and RSVP-TE. 
> > > > If the RSVP-TE signal of provider network can reach user host 
> > > > across Ethernet based private network, an LSP can be 
> established 
> > > > from application to application via the provider backbone. 
> > > > Service providers will be able to control application flows 
> > > > in L2-LSP level as well as in aggregated LSP pipe of similar 
> > > > application type. A variety of new services will be 
> enabled using 
> > > > the enhanced capability of distinguishing and controlling each 
> > > > individual application flow. 
> > > > 
> > > > I personally believe that end-to-end L2-LSP may offer 
> > > > innovative solutions for servicing IP-TV as well as fast 
> > mobility. 
> > > > There have been some experimental approaches combining 
> > > > MPLS and IP mobility. However such potential of the new 
> > > > application can only be explored when end-user host is 
> > > > included in the scope of CCAMP work area. 
> > > > 
> > > > Therefore, I hereby sincerely request people's attention 
> > > > and support on this perspective of end-to-end LSP. 
> > > > If there is enough number of people agree on this view, 
> > > > the WG can request the necessary update of the charter. 
> > > > 
> > > > Thank you. 
> > > >  
> > > > Jaihyung Cho 
> > > >  
> > > >  
> > > >  
> > > > ETRI, Korea 
> > > > phone :       042) 860-5514 
> > > > oversea: +82-42-860-5514 
> > > > fax:         +82-42-861-5550 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 

Delivery-date: Thu, 21 Jul 2005 11:35:13 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Tom Petch" <[email-masked]>, <[email-masked]>
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Thu, 21 Jul 2005 12:27:01 +0100

OK
Understood.

A
----- Original Message ----- 
From: "Tom Petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 20, 2005 8:41 PM
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
Lexicography

> <inline>
> Tom Petch
> ----- Original Message -----
> From: "Adrian Farrel" <[email-masked]>
> To: "Tom Petch" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, July 20, 2005 11:54 AM
> Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
> Lexicography
>
>
> > Tom,
> >
> > I don't think it is CCAMP's role to correct the English of another SDO
:-)
> >
> > Adrian
>
> OK, but then I do not think you should reply "Correct" because IMHO it
is not
> correct; the response should be something about what, primarily, CCAMP
is
> responsible for:-)
>
> > ----- Original Message -----
> > From: "Tom Petch" <[email-masked]>
> > To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
> > Sent: Tuesday, July 19, 2005 7:18 PM
> > Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on
ASON
> > Lexicography
> >
> >
> > > Adrian
> > >
> > > I think it should be
> > > "
> > >  - CCAMP has primary responsibility for the descriptions of GMPLS
terms
> > >
> > >  Correct "
> > >
> > > even if that is not what SG15 said.
> > >
> > > Primarily (sic) CCAMP has responsibility for the specification of
GMPLS,
> > not
> > > just its terms:-)
> > >
> > > Tom Petch
> > >
> > > ----- Original Message -----
> > > From: "Adrian Farrel" <[email-masked]>
> > > To: <[email-masked]>
> > > Cc: "'Kireeti Kompella'" <[email-masked]>; <[email-masked]>;
"Bill
> > Fenner"
> > > <[email-masked]>; "Scott Bradner" <[email-masked]>
> > > Sent: Tuesday, July 19, 2005 1:59 PM
> > > Subject: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
> > > Lexicography
> > >
> > >
> > > > Hi,
> > > >
> > > > Please comment on this draft response liaison which I intend to
send
> > on
> > > > Monday 25th July.
> > > > You can see the original incoming liaison at
> > > > http://www.olddog.co.uk/incoming.htm
> > > >
> > > > Thanks,
> > > > Adrian
> > > > =====
> > > > To: ITU-T SG15 Questions 12 and 14
> > > > From: IETF CCAMP Working Group
> > > > Subject: Response to your liaison on GMPLS/ASON Lexicography
> > > > For: Action
> > > > Deadline: August 31st 2005
> > > >
> > > > The CCAMP Working Group would like to thank SG15 and especially
> > Questions
> > > > 12 and 14 for the time and effort they put into providing input
and
> > > > feedback on the GMPLS/ASON lexicography Internet-Draft that is
being
> > > > developed by CCAMP. Much of the material supplied as direct
comments
> > or as
> > > > mark-ups to the Internet-Draft has been incorporated into the
latest
> > > > revision which is available at
> > > >
> > >
> >
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-03.
> > > txt
> > > >
> > > > In your liaison you state some assumptions which we would like to
> > comment
> > > > on as follows.
> > > >
> > > > - The purpose of the document is to enable those familiar with
ASON
> > > >   to understand GMPLS terminology in an ASON context
> > > >
> > > > Correct.
> > > >
> > > > - GMPLS terms are described informally in the document in a way
that
> > > >   is generally consistent with GMPLS (existing RFCs and work in
> > progress)
> > > >
> > > > While the definition of GMPLS terms would be helpful for
understanding
> > > > GMPLS terms in a GMPLS context, that is not the purpose of this
> > document.
> > > >
> > > > - Based on these descriptions, interpretations of these GMPLS
terms
> > > >   in ASON terminology are provided
> > > >
> > > > It is intended that the interpretation of the GMPLS terms is not
based
> > on
> > > > these descriptions, but based on the full meaning of the GMPLS
terms.
> > The
> > > > descriptions of the GMPLS terms are provided in this
Internet-Draft
> > for
> > > > context and a brief summary.
> > > >
> > > > - CCAMP has primarily responsibility for the descriptions of GMPLS
> > terms
> > > >
> > > > Correct.
> > > >
> > > > - Q12/15 has responsibility to provide input to the GMPLS-ASON
> > > >   interpretations (based on the descriptions in this draft)
> > > >
> > > > We welcome this assumption of responsibility by Q12/15 to provide
> > input to
> > > > the Internet-Draft. While the Internet-Draft remains under the
overall
> > > > editorial control of the CCAMP working group, we hope to be able
to
> > use
> > > > the text supplied by Q12/15 with only editorial changes.
> > > >
> > > >
> > > > Additionally, we welcome the pledge to continue work on this
> > > > Internet-Draft through correspondence on the Q12/15 mailing list,
and
> > > > thank Q12/15 for assigning Ben Mack-Crane as the SG15
representative
> > on
> > > > this matter. Ben has proved very helpful in clarifying and
developing
> > > > comments received from SG15.
> > > >
> > > >
> > > > We have had several email exchanges with Ben about a few of the
> > specific
> > > > comments made in your review of the 02 revision of the
Internet-Draft.
> > > > Although he has taken these comments to the Q12/15 mailing list no
> > > > response has been received, perhaps due to pressure of time. We
are
> > taking
> > > > the opportunity to restate several questions here for your
convenience
> > and
> > > > would appreciate your answers as part of the response to this
liaison.
> > > >
> > > > 1. Definition of a Resource (section 3.2)
> > > >    You have supplied us with the simple text that says...
> > > >      In ASON applications:
> > > >      A resource refers only to a link connection (e.g. VC-11,
> > > >      VC-4 etc.).
> > > >
> > > >    We would like to clarify this because we don't understand how
> > > >    the original text is wrong. It used to say...
> > > >      ITU-T [should be ASON] terms for resource:
> > > >      - Connection point (cp) in the context of link discovery
> > > >        and resource management (allocation, binding into
> > > >        cross-connects, etc.);
> > > >      - Link connection or trail termination in the context of
> > > >        routing, path computation and signaling.
> > > >
> > > >    Recall that we are talking about the ASON terms for what GMPLS
> > > >    calls a resource. We think the following...
> > > >    In ASON a link connection is an association of output cp on one
> > > >    side of the link and input cp on the other side of the link. In
> > > >    GMPLS by resource we mean in most of the cases the local end of
> > > >    the resource (which is cp in ASON terminology). This is true in
> > > >    the context of link discovery.
> > > >
> > > >    More importantly, this is also true in the context of a
> > > >    signaling application. Specifically, when a GMPLS signaling
> > > >    sub-system requests allocation of a resource, the GMPLS
> > > >    Resource Manager allocates only the local end of the
> > > >    resource. This happens on both sides of the link, that is, we
> > > >    allocate input and output resources. This contrasts with ASON,
> > > >    where there is a much more versatile LRM, and the connection
> > > >    manager (signaling application) allocates link connections
> > > >    only on the output side, leaving LRM to coordinate the
> > > >    allocation with the neighbor.
> > > >
> > > >    However, in GMPLS TE advertisements we account only for
> > > >    outgoing resources, that is, we don't advertise incoming
> > > >    resources on the assumption that they match the outgoing
> > > >    resources for the discovered TE links.
> > > >
> > > >    Bottom line: we believe that we should retain the previous
> > > >    definitions, and have not made this change in the new
> > > >    revision. We would like to discuss this point further with
> > > >    Q12/15.
> > > >
> > > > 2. Link ends and Data links (Section 3.5 - was section 3.4)
> > > >
> > > > 2a.Although we understand that ASON does not require the concept
> > > >    of a link end, GMPLS does. Therefore we should provide some
> > > >    form of language to help people do the mapping.
> > > >
> > > >    The proposed new text from Q12/15 removes all reference to
> > > >    link ends from the ASON section, and we feel this is a
> > > >    mistake and propose the following text:
> > > >      In ASON, a GMPLS unidirectional data link end is a
> > > >      collection of connection points from the same client
> > > >      layer that are supported by a single trail termination
> > > >      (access point).
> > > >
> > > >    This text depends on the fact that a link end is described as
> > > >    a set of resources that transfer traffic to a neighbor.
> > > >
> > > > 2b.The new text from Q12/15 gives us...
> > > >      A GMPLS data link is an ASON link supported by a single
> > > >      server trail.
> > > >
> > > >    We are not sure that we understand this correctly. It
> > > >    appears to say that a unidirectional data link could be
> > > >    supported by multiple trail terminations (access points).
> > > >    This seems to suggest that a client would have to make a
> > > >    choice about where to send data, which seems to imply it
> > > >    really has to choose between data links! We are confused!
> > > >
> > > >    We think some of this problem may come from the *need* in
> > > >    GMPLS to identify data link ends. There may be some value in
> > > >    stressing that a GMPLS link end is supported by exactly one
> > > >    trail termination. When several trail terminations are
> > > >    involved, we can still talk about single TE link (as a
> > > >    bundle), but each component link will be a distinct data
> > > >    link. We think that in ASON the SNPP (TE link in GMPLS
> > > >    language) could be supported by multiple terminations.
> > > >
> > > > 3. Link interfaces (section 3.6 - was 3.5)
> > > >    The new text from Q12/15 gives us...
> > > >      A GMPLS interface is "all the stuff between a physical
> > > >      interface and a matrix in an ASON network element." More
> > > >      precisely, it is a trail termination function and adaptation
> > > >      function for which adapted client layer connection points
> > > >      are bound to a matrix.
> > > >
> > > >    We think "physical interface" may be ambiguous in the multi-
> > > >    layer context. We think the "stuff" should be between a link
> > > >    and a matrix, since we are talking about links in distinct
> > > >    layers.
> > > >
> > > >
> > > > In addition to your feedback on the specific points above, we
would
> > > > welcome your continued comments and review of the Internet-Draft.
> > > >
> > > > Regards,
> > > > Adrian Farrel and Kireeti Kompella
> > > > IETF CCAMP Working Group Co-chairs
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
>
>
>

Delivery-date: Thu, 21 Jul 2005 10:11:00 +0000
Date: Thu, 21 Jul 2005 19:09:11 +0900
From: Tomohiro Otani <[email-masked]>
To: [email-masked]
Subject: draft-otani-ccamp-interas-gmpls-te-03.txt

Hi everyone,

We updated the GMPLS inter-domain TE req. draft.  Since last meeting,
we believe this document has been already stable and well-recognized, 
however, per the last meeting discussion, we have to wait for the 
charter being revised, in order to be a WG document (This must be 
initiated by chairs).

Until then, we continue to update the contents and indeed welcome your 
feedback and comments through this list or during the meeting in Paris.

Regards,

tomo

-----------------------------------------------------------------------------
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: GMPLS Inter-domain Traffic Engineering Requirements
	Author(s)	: T. Otani, et al.
	Filename	: draft-otani-ccamp-interas-gmpls-te-03.txt
	Pages		: 15
	Date		: 2005-7-20
	
This draft provides requirements for the support of generalized 
multi-protocol label switching (GMPLS) inter-domain traffic 
engineering (TE). Its main objective is to present the differences 
between MPLS inter-domain TE and GMPLS inter-domain TE.  This draft 
covers not only GMPLS Inter-domain architecture but also functional 
requirements in terms of GMPLS signaling and routing in order to 
specify these in a GMPLS Inter-domain environment.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-otani-ccamp-interas-gmpls-te-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Delivery-date: Thu, 21 Jul 2005 00:31:57 +0000
Date: Thu, 21 Jul 2005 09:30:10 +0900
From: Kohei Shiomoto <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D ACTION:draft-oki-ccamp-gmpls-ip-interworking-06.txt]

Hi all

A new version of the MPLS-GMPLS interwork and migration draft has been
uploaded.

"IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS migration"
http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-06.txt

Summary of change:
Section 2 (New)
- Addressed interworking MPLS-TE and GMPLS
     "Three issues on interworking between MPLS-based packet networks
     and GMPLS-based optical transport network result from the fact
     that control and data planes are separated in GMPLS-based
     optical transport networks. These three issues are (1) lack of
     routing and signaling adjacencies, (2) control plane resource
     exhaustion, and (3) TE path computation over the border between
     MPLS and GMPLS domains."
Section 3
- Added 3.7 Integrated migration model
Section 5
- Removed 4.2.1 Segment stitching of the previous version
- Moved 5.1.2 Discovery of GMPLS signaling capability from 4.2.4 of the
previous version.
- Added 5.3 Path computation
Throughout the document
- Cleaned up text for readability (Removed redundancy, etc)

Comments and feedbacks are highly appreciated.
Best regards,
--
Kohei Shiomoto

-------- Original Message --------
Subject: I-D ACTION:draft-oki-ccamp-gmpls-ip-interworking-06.txt
Date: Tue, 19 Jul 2005 10:50:01 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: IP/MPLS-GMPLS interworking in support of
                          IP/MPLS to GMPLS migration
	Author(s)	: E. Oki, et al.
	Filename	: draft-oki-ccamp-gmpls-ip-interworking-06.txt
	Pages		: 17
	Date		: 2005-7-19
	
Over time Multi-Protocol Label Switching (MPLS) traffic
     engineered networks may be migrated to use Generalized MPLS
     (GMPLS). This will allow the networks to benefit from many new
     features that have been added to the GMPLS protocols.
     Additionally, such migration will facilitate easy interworking
     of packet networks that are controlled by IP/MPLS-TE protocols
     and networks that are controlled by GMPLS protocols.

     During this migration phase MPLS and GMPLS capable elements will
     have to co-exist and interwork. GMPLS signaling and routing
     protocols are subtly different from the MPLS protocols and so
     interworking and migration strategies are needed.

     This document describes issues associated with interworking of
     IP/MPLS-TE networks and GMPLS-based optical networks. Then it
     describes possible migration scenarios, mechanisms to compensate
     for the differences between MPLS and GMPLS protocols, and how to
     apply those mechanisms in order to achieve migration from MPLS
     to GMPLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-06.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-oki-ccamp-gmpls-ip-interworking-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-- 
Kohei Shiomoto, Ph.D
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone +81 422 59 4402    Fax +81 422 59 3787

Delivery-date: Wed, 20 Jul 2005 20:45:00 +0000
Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Wed, 20 Jul 2005 21:41:51 +0200

<inline>
Tom Petch
----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: "Tom Petch" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 20, 2005 11:54 AM
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
Lexicography

> Tom,
>
> I don't think it is CCAMP's role to correct the English of another SDO :-)
>
> Adrian

OK, but then I do not think you should reply "Correct" because IMHO it is not
correct; the response should be something about what, primarily, CCAMP is
responsible for:-)

> ----- Original Message -----
> From: "Tom Petch" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 19, 2005 7:18 PM
> Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
> Lexicography
>
>
> > Adrian
> >
> > I think it should be
> > "
> >  - CCAMP has primary responsibility for the descriptions of GMPLS terms
> >
> >  Correct "
> >
> > even if that is not what SG15 said.
> >
> > Primarily (sic) CCAMP has responsibility for the specification of GMPLS,
> not
> > just its terms:-)
> >
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "Adrian Farrel" <[email-masked]>
> > To: <[email-masked]>
> > Cc: "'Kireeti Kompella'" <[email-masked]>; <[email-masked]>; "Bill
> Fenner"
> > <[email-masked]>; "Scott Bradner" <[email-masked]>
> > Sent: Tuesday, July 19, 2005 1:59 PM
> > Subject: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
> > Lexicography
> >
> >
> > > Hi,
> > >
> > > Please comment on this draft response liaison which I intend to send
> on
> > > Monday 25th July.
> > > You can see the original incoming liaison at
> > > http://www.olddog.co.uk/incoming.htm
> > >
> > > Thanks,
> > > Adrian
> > > =====
> > > To: ITU-T SG15 Questions 12 and 14
> > > From: IETF CCAMP Working Group
> > > Subject: Response to your liaison on GMPLS/ASON Lexicography
> > > For: Action
> > > Deadline: August 31st 2005
> > >
> > > The CCAMP Working Group would like to thank SG15 and especially
> Questions
> > > 12 and 14 for the time and effort they put into providing input and
> > > feedback on the GMPLS/ASON lexicography Internet-Draft that is being
> > > developed by CCAMP. Much of the material supplied as direct comments
> or as
> > > mark-ups to the Internet-Draft has been incorporated into the latest
> > > revision which is available at
> > >
> >
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-03.
> > txt
> > >
> > > In your liaison you state some assumptions which we would like to
> comment
> > > on as follows.
> > >
> > > - The purpose of the document is to enable those familiar with ASON
> > >   to understand GMPLS terminology in an ASON context
> > >
> > > Correct.
> > >
> > > - GMPLS terms are described informally in the document in a way that
> > >   is generally consistent with GMPLS (existing RFCs and work in
> progress)
> > >
> > > While the definition of GMPLS terms would be helpful for understanding
> > > GMPLS terms in a GMPLS context, that is not the purpose of this
> document.
> > >
> > > - Based on these descriptions, interpretations of these GMPLS terms
> > >   in ASON terminology are provided
> > >
> > > It is intended that the interpretation of the GMPLS terms is not based
> on
> > > these descriptions, but based on the full meaning of the GMPLS terms.
> The
> > > descriptions of the GMPLS terms are provided in this Internet-Draft
> for
> > > context and a brief summary.
> > >
> > > - CCAMP has primarily responsibility for the descriptions of GMPLS
> terms
> > >
> > > Correct.
> > >
> > > - Q12/15 has responsibility to provide input to the GMPLS-ASON
> > >   interpretations (based on the descriptions in this draft)
> > >
> > > We welcome this assumption of responsibility by Q12/15 to provide
> input to
> > > the Internet-Draft. While the Internet-Draft remains under the overall
> > > editorial control of the CCAMP working group, we hope to be able to
> use
> > > the text supplied by Q12/15 with only editorial changes.
> > >
> > >
> > > Additionally, we welcome the pledge to continue work on this
> > > Internet-Draft through correspondence on the Q12/15 mailing list, and
> > > thank Q12/15 for assigning Ben Mack-Crane as the SG15 representative
> on
> > > this matter. Ben has proved very helpful in clarifying and developing
> > > comments received from SG15.
> > >
> > >
> > > We have had several email exchanges with Ben about a few of the
> specific
> > > comments made in your review of the 02 revision of the Internet-Draft.
> > > Although he has taken these comments to the Q12/15 mailing list no
> > > response has been received, perhaps due to pressure of time. We are
> taking
> > > the opportunity to restate several questions here for your convenience
> and
> > > would appreciate your answers as part of the response to this liaison.
> > >
> > > 1. Definition of a Resource (section 3.2)
> > >    You have supplied us with the simple text that says...
> > >      In ASON applications:
> > >      A resource refers only to a link connection (e.g. VC-11,
> > >      VC-4 etc.).
> > >
> > >    We would like to clarify this because we don't understand how
> > >    the original text is wrong. It used to say...
> > >      ITU-T [should be ASON] terms for resource:
> > >      - Connection point (cp) in the context of link discovery
> > >        and resource management (allocation, binding into
> > >        cross-connects, etc.);
> > >      - Link connection or trail termination in the context of
> > >        routing, path computation and signaling.
> > >
> > >    Recall that we are talking about the ASON terms for what GMPLS
> > >    calls a resource. We think the following...
> > >    In ASON a link connection is an association of output cp on one
> > >    side of the link and input cp on the other side of the link. In
> > >    GMPLS by resource we mean in most of the cases the local end of
> > >    the resource (which is cp in ASON terminology). This is true in
> > >    the context of link discovery.
> > >
> > >    More importantly, this is also true in the context of a
> > >    signaling application. Specifically, when a GMPLS signaling
> > >    sub-system requests allocation of a resource, the GMPLS
> > >    Resource Manager allocates only the local end of the
> > >    resource. This happens on both sides of the link, that is, we
> > >    allocate input and output resources. This contrasts with ASON,
> > >    where there is a much more versatile LRM, and the connection
> > >    manager (signaling application) allocates link connections
> > >    only on the output side, leaving LRM to coordinate the
> > >    allocation with the neighbor.
> > >
> > >    However, in GMPLS TE advertisements we account only for
> > >    outgoing resources, that is, we don't advertise incoming
> > >    resources on the assumption that they match the outgoing
> > >    resources for the discovered TE links.
> > >
> > >    Bottom line: we believe that we should retain the previous
> > >    definitions, and have not made this change in the new
> > >    revision. We would like to discuss this point further with
> > >    Q12/15.
> > >
> > > 2. Link ends and Data links (Section 3.5 - was section 3.4)
> > >
> > > 2a.Although we understand that ASON does not require the concept
> > >    of a link end, GMPLS does. Therefore we should provide some
> > >    form of language to help people do the mapping.
> > >
> > >    The proposed new text from Q12/15 removes all reference to
> > >    link ends from the ASON section, and we feel this is a
> > >    mistake and propose the following text:
> > >      In ASON, a GMPLS unidirectional data link end is a
> > >      collection of connection points from the same client
> > >      layer that are supported by a single trail termination
> > >      (access point).
> > >
> > >    This text depends on the fact that a link end is described as
> > >    a set of resources that transfer traffic to a neighbor.
> > >
> > > 2b.The new text from Q12/15 gives us...
> > >      A GMPLS data link is an ASON link supported by a single
> > >      server trail.
> > >
> > >    We are not sure that we understand this correctly. It
> > >    appears to say that a unidirectional data link could be
> > >    supported by multiple trail terminations (access points).
> > >    This seems to suggest that a client would have to make a
> > >    choice about where to send data, which seems to imply it
> > >    really has to choose between data links! We are confused!
> > >
> > >    We think some of this problem may come from the *need* in
> > >    GMPLS to identify data link ends. There may be some value in
> > >    stressing that a GMPLS link end is supported by exactly one
> > >    trail termination. When several trail terminations are
> > >    involved, we can still talk about single TE link (as a
> > >    bundle), but each component link will be a distinct data
> > >    link. We think that in ASON the SNPP (TE link in GMPLS
> > >    language) could be supported by multiple terminations.
> > >
> > > 3. Link interfaces (section 3.6 - was 3.5)
> > >    The new text from Q12/15 gives us...
> > >      A GMPLS interface is "all the stuff between a physical
> > >      interface and a matrix in an ASON network element." More
> > >      precisely, it is a trail termination function and adaptation
> > >      function for which adapted client layer connection points
> > >      are bound to a matrix.
> > >
> > >    We think "physical interface" may be ambiguous in the multi-
> > >    layer context. We think the "stuff" should be between a link
> > >    and a matrix, since we are talking about links in distinct
> > >    layers.
> > >
> > >
> > > In addition to your feedback on the specific points above, we would
> > > welcome your continued comments and review of the Internet-Draft.
> > >
> > > Regards,
> > > Adrian Farrel and Kireeti Kompella
> > > IETF CCAMP Working Group Co-chairs
> > >
> > >
> >
> >
> >
> >
>

Delivery-date: Wed, 20 Jul 2005 19:51:57 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt 
Date: Wed, 20 Jul 2005 15:50:03 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized MPLS (GMPLS) RSVP-TE Signalling in
                          support of Automatically Switched Optical
                          Network (ASON)
	Author(s)	: J. Drake, et al.
	Filename	: draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt
	Pages		: 40
	Date		: 2005-7-20
	
This document specifies how Generalized MPLS (GMPLS) RSVP-TE 
   signaling may be used and extended to satisfy the requirements of the 
   Automatically Switched Optical Network (ASON) architecture specified 
   by the ITU-T. The requirements are in a companion document 
   "Requirements for Generalized MPLS (GMPLS) Usage and Extensions for 
   Automatically Switched Optical Network (ASON)." 

   In particular, this document details the mechanisms for setting up 
   Soft Permanent Connections (SPC), the necessary extensions in 
   delivering full and logical call/connection separation support, the 
   extended restart capabilities during control plane failures, extended 
   label usage and crankback signalling capability. 
    
   The mechanisms proposed in this document are applicable to any 
   environment (including multi-area) and for any type of interface: 
   packet, layer-2, time-division multiplexed, lambda or fiber 
   switching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 20 Jul 2005 19:16:05 +0000
Date: Wed, 20 Jul 2005 12:15:46 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: LSP stitching questions for discussion
To: [email-masked], Igor Bryskin <[email-masked]>
Cc: [email-masked], Arthi Ayyangar <[email-masked]>, [email-masked]

--0-499060946-1121886946=:94207
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

[dp] ok - last try for an end-to-end PSC-1 LSP of 2MB you could make use of a PSC-1 segment of 4MB 

Ah, Ok. I see your point and agree.

Igor

You are right: whether PSC1 and PSC2 are separate network layers or not is a topic of a separate (painful :=)) discussion. However, I just wanted to point out here that a PSC2 LSP is a provisioned as such for a reason: it is meant to *nest* PSC1 LSPs rather than to stitch them. From the VNT management point of view PSC2 and PSC1 are separate topological layers. that is PSC2 produces topology for PSC1, just like VC4 produces topology for VC12.
The only difference is that in the latter case this relationship is forced by the hardware, and in the former case is not (just logical). Take for example C and C++ programming. Certain things you simply forced not to do in C++, whereas in C you could but shouldn't.

See you in Paris.
Igor

"Igor Bryskin" <[email-masked]>
Sent by: [email-masked]
07/20/2005 13:25 AST

To: "Arthi Ayyangar" <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: <[email-masked]>
bcc: 
Subject: Re: LSP stitching questions for discussion

Dimitri,

It seems to me that I mostly agree(?!) with what you wrote in this mail. I'd still want to confirm your views  on the following questions:

a) Is it possible (should we allow) to stitch  PSC1 e2e LSP by a LSC LSP segment ? 

b) Is it possible (should we allow) to stitch  VC12 e2e LSP by a VC4 LSP segment ? 
c) Is it possible (should we allow) to stitch  PSC1 e2e LSP by a PSC2 LSP segment ?

My answers are NO to all three questions. You can sticth PSC1 with PSC1, VC12 with VC12, etc. In all other cases you need, first, to setup a hierarchical LSP (H-LSP) (whether it is FA-LSP (single domain) or not (multi-domain)) in order to create a data link of the e2e LSP switching capability and only after that you can also use a stitching segment on top of  this H-LSP).

See also in-line.

Igor

----- Original Message ----- 
From: [email-masked] 
To: Arthi Ayyangar 
Cc: Igor Bryskin ; [email-masked] 
Sent: Wednesday, July 20, 2005 4:46 AM
Subject: Re: LSP stitching questions for discussion

arthi, 

first a recap: this item on stitching was initiated in order to allow per "domain" control of end-to-end (contiguous) LSP, as part of a separate document, and not to extend its scope (unduly, in this case, see below) but mainly in order to have the set of all related protocol mechanisms within a specific document -

from this initial working assumption, it is clear that the segment must have the properties of the incoming end-to-end LSP which are determined among other by its switching type e.g. PSC-3 or TDM, the first requirement of LSP stitching is contiguity of the end-to-end LSP at the data plane level (after stitching operation) - and this by definition of the initial working assumption -

IB>> Agree

note: the only latitude which is left (for a given switching type e.g. PSC-2) is due to the properties of packet (PSC) networks that allows you stitch a segment having a larger Max Reservable Bandwidth and Unreserved Bandwidth (we would have equivalent latitude for other attributes but this is a local policy decision - which at the end is the sole purpose of this approach)

IB>> Disagree. Conceptually PCS1 and PSC2 are different layers and the latter cannot stitch the former, just like in case VC12 and VC4. You should nest PSC1 within PSC2 instead.

Here are some of the questions related to LSP stitching to start a
discussion on the usage of LSP stitching.

>1) Are the control plane signaling procedures for LSP stitching as
>described in this ID, (explicit request for LSP stitching on
>LSP segment, different label allocation rules; etc) REQUIRED to stitch
>packet LSPs in data plane 

-> yes (beside manual config operation)

IB>> Agree

>2) Are the control plane signaling procedures for LSP stitching as
>described in this ID, (explicit request for LSP stitching on
>LSP segment, different label allocation rules; etc) REQUIRED to stitch
>non-packet LSPs in data plane ?

-> yes (beside manual config operation)

IB>> Agree

>3) If an e2e LSP crosses a region boundary (based on different TE
>link switching capabilities), then can I use LSP stitching 
>a) control plane procedures for packet LSPs
>b) data plane procedures for packet LSPs
>c) control plane procedures for non-packet LSPs
>d) data plane procedures for non-packet LSPs

-> no, when crossing a region boundary, you simply use a document named "draft-mpls-lsp-hierarchy-08.txt" which is in the RFC Editor queue, but this does not prevent from creating an LSP segment on top of an FA-LSP (see below)

IB>> Agree with the caviat that it should be H-LSP instead of FA-LSP to cover single and multi-domain scenarios

>4) If the switching type of an e2e LSP is different from that of an LSP
>segment, can I use LSP stitching 
>a) control plane procedures for packet LSPs
>b) data plane procedures for packet LSPs
>c) control plane procedures for non-packet LSPs
>d) data plane procedures for non-packet LSPs

-> no, in this case progression of the end-to-end LSP establishment, implies that the LSP segment must fulfil a set of constraints carried as part of the incoming end-to-end LSP request, in this case one has to create an LSP segment (with a switching type equal to the incoming end-to-end LSP switching type) over that FA (i.e. referred here above to the LSP segment with a different Switching Type)

IB>> Agree with the caviat that it should be H-LSP instead of FA-LSP to cover single and multi-domain scenarios

Cheers,

Igor

>Note that although 3) and 4) appear to be the same, the reason I have
>them as different questions is that in one case the TE link switching
>capability is examined and in the other case the Generalized Label Request
>is examined.

-> what it appears to me is that this discussion mixes the issue of the operation describing the stitching operations at the domain boundaries from the LSP segment creation itself i.e. an LSP segment can indeed be an FA link inherited from the creation of an (intra-domain) FA-LSP - 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-499060946-1121886946=:94207
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P>[dp] ok - last try for an end-to-end PSC-1 LSP of 2MB you could make use of a PSC-1 segment of 4MB </P>
<P>Ah, Ok. I see your point and agree.</P>
<P>Igor</P>
<P><BR>You are right: whether PSC1 and PSC2 are separate network layers or not is a topic of a separate (painful :=)) discussion. However, I just wanted to point out here that a PSC2 LSP is a provisioned as such for a reason:&nbsp;it is meant to *nest* PSC1 LSPs rather than to stitch them. From the VNT management point of view PSC2 and PSC1 are separate topological layers. that is PSC2 produces topology for PSC1, just like VC4 produces topology for VC12.<BR>The only difference is that in the latter case this relationship is forced by the hardware, and in the former case is not (just logical). Take for example C and C++ programming. Certain things you simply forced not to do in C++, whereas in C you could but shouldn't.<BR><BR>See you in Paris.<BR>Igor<BR><FONT size=4></FONT><BR><BR><BR><BR><B>"Igor Bryskin" &lt;[email-masked]&gt;</B><BR>Sent by: [email-masked]<BR>07/20/2005 13:25 AST<BR><BR>To:<FONT size=4> </FONT>"Arthi Ayyangar" &lt;[email-masked]&gt;, Dimitri
 PAPADIMITRIOU/BE/ALCATEL@ALCATEL<BR>cc:<FONT size=4> </FONT>&lt;[email-masked]&gt;<BR>bcc:<FONT size=4> </FONT><BR>Subject:<FONT size=4> </FONT>Re: LSP stitching questions for discussion<BR><BR><BR><FONT size=4>Dimitri,</FONT><BR><BR><FONT size=4>It seems to me that I mostly agree(?!) with what you wrote in this mail. I'd still want to confirm your views&nbsp; on the following questions:</FONT><BR><BR><BR><FONT size=4>a) Is it possible (should we allow) to stitch&nbsp; PSC1 e2e LSP by a LSC LSP segment ? </FONT><BR><BR><FONT size=4>b) Is it possible (should we allow) to stitch&nbsp;&nbsp;VC12 e2e LSP by a&nbsp;VC4 LSP segment ? </FONT><BR><FONT size=4>c) Is it possible (should we allow) to stitch&nbsp;&nbsp;PSC1 e2e LSP by a&nbsp;PSC2 LSP segment ?</FONT><BR><BR><FONT size=4>My answers are NO to all three questions. You can sticth PSC1 with PSC1, VC12 with VC12, etc. In all other cases you need, first, to setup a hierarchical LSP (H-LSP) (whether it is FA-LSP (single domain) or
 not&nbsp;(multi-domain)) in order to create a data link of the e2e LSP switching capability and only after that you can also&nbsp;use a stitching segment on top of &nbsp;this H-LSP).</FONT><BR><BR><FONT size=4>See also in-line.</FONT><BR><BR><FONT size=4>Igor</FONT><BR><BR><BR><FONT size=5>----- Original Message ----- </FONT><BR><FONT size=5><B>From:</B> </FONT><FONT color=blue size=5><U><A href="mailto:[email-masked]">[email-masked]</A></U></FONT><FONT color=black size=5> </FONT><BR><FONT size=5><B>To:</B> </FONT><FONT color=blue size=5><U><A href="mailto:[email-masked]">Arthi Ayyangar</A></U></FONT><FONT color=black size=5> </FONT><BR><FONT size=5><B>Cc:</B> </FONT><FONT color=blue size=5><U><A href="mailto:[email-masked]">Igor Bryskin</A></U></FONT><FONT color=black size=5> ; </FONT><FONT color=blue size=5><U><A href="mailto:[email-masked]">[email-masked]</A></U></FONT><FONT color=black size=5> </FONT><BR><FONT
 size=5><B>Sent:</B> Wednesday, July 20, 2005 4:46 AM</FONT><BR><FONT size=5><B>Subject:</B> Re: LSP stitching questions for discussion</FONT><BR><BR><FONT size=5>arthi, </FONT><BR><BR><BR><BR><FONT size=5>first a recap: this item on stitching was initiated in order to allow per "domain" control of end-to-end (contiguous) LSP, as part of a separate document, and not to extend its scope (unduly, in this case, see below) but mainly in order to have the set of all related protocol mechanisms within a specific document -</FONT><BR><BR><BR><BR><FONT size=5>from this initial working assumption, it is clear that the segment must have the properties of the incoming end-to-end LSP which are determined among other by its switching type e.g. PSC-3 or TDM, the first requirement of LSP stitching is contiguity of the end-to-end LSP at the data plane level (after stitching operation) - and this by definition of the initial working assumption -</FONT><BR><BR><FONT size=5>IB&gt;&gt;
 Agree</FONT><BR><BR><FONT size=5>note: the only latitude which is left (for a given switching type e.g. PSC-2) is due to the properties of packet (PSC) networks that allows you stitch a segment having a larger Max Reservable Bandwidth and Unreserved Bandwidth (we would have equivalent latitude for other attributes but this is a local policy decision - which at the end is the sole purpose of this approach)</FONT><BR><BR><FONT size=5>IB&gt;&gt; Disagree. Conceptually PCS1 and PSC2 are different layers and the latter cannot stitch the former, just like in case VC12 and VC4. You should nest PSC1 within PSC2 instead.</FONT><BR><BR><BR><BR><FONT size=5>Here are some of the questions related to LSP stitching to start a</FONT><BR><FONT size=5>discussion on the usage of LSP stitching.</FONT><BR><BR><FONT size=5>&gt;1) Are the control plane signaling procedures for LSP stitching as</FONT><BR><FONT size=5>&gt;described in this ID, (explicit request for LSP stitching on</FONT><BR><FONT
 size=5>&gt;LSP segment, different label allocation rules; etc) REQUIRED to stitch</FONT><BR><FONT size=5>&gt;packet LSPs in data plane </FONT><BR><BR><BR><FONT size=5>-&gt; yes (beside manual config operation)</FONT><BR><BR><FONT size=5>IB&gt;&gt; Agree</FONT><BR><BR><BR><FONT size=5>&gt;2) Are the control plane signaling procedures for LSP stitching as</FONT><BR><FONT size=5>&gt;described in this ID, (explicit request for LSP stitching on</FONT><BR><FONT size=5>&gt;LSP segment, different label allocation rules; etc) REQUIRED to stitch</FONT><BR><FONT size=5>&gt;non-packet LSPs in data plane ?</FONT><BR><BR><BR><FONT size=5>-&gt; yes (beside manual config operation)</FONT><BR><BR><FONT size=5>IB&gt;&gt; Agree</FONT><BR><BR><BR><FONT size=5>&gt;3) If an e2e LSP crosses a region boundary (based on different TE</FONT><BR><FONT size=5>&gt;link switching capabilities), then can I use LSP stitching </FONT><BR><FONT size=5>&gt;a) control plane procedures for packet LSPs</FONT><BR><FONT
 size=5>&gt;b) data plane procedures for packet LSPs</FONT><BR><FONT size=5>&gt;c) control plane procedures for non-packet LSPs</FONT><BR><FONT size=5>&gt;d) data plane procedures for non-packet LSPs</FONT><BR><BR><BR><FONT size=5>-&gt; no, when crossing a region boundary, you simply use a document named "draft-mpls-lsp-hierarchy-08.txt" which is in the RFC Editor queue, but this does not prevent from creating an LSP segment on top of an FA-LSP (see below)</FONT><BR><BR><FONT size=5>IB&gt;&gt; Agree with the caviat that it should be H-LSP instead of FA-LSP to cover single and multi-domain scenarios</FONT><BR><BR><BR><FONT size=5>&gt;4) If the switching type of an e2e LSP is different from that of an LSP</FONT><BR><FONT size=5>&gt;segment, can I use LSP stitching </FONT><BR><FONT size=5>&gt;a) control plane procedures for packet LSPs</FONT><BR><FONT size=5>&gt;b) data plane procedures for packet LSPs</FONT><BR><FONT size=5>&gt;c) control plane procedures for non-packet
 LSPs</FONT><BR><FONT size=5>&gt;d) data plane procedures for non-packet LSPs</FONT><BR><BR><BR><FONT size=5>-&gt; no, in this case progression of the end-to-end LSP establishment, implies that the LSP segment must fulfil a set of constraints carried as part of the incoming end-to-end LSP request, in this case one has to create an LSP segment (with a switching type equal to the incoming end-to-end LSP switching type) over that FA (i.e. referred here above to the LSP segment with a different Switching Type)</FONT><BR><BR><BR><FONT size=5>IB&gt;&gt; Agree with the caviat that it should be H-LSP instead of FA-LSP to cover single and multi-domain scenarios</FONT><BR><BR><FONT size=4>Cheers,</FONT><BR><BR><FONT size=4>Igor</FONT><BR><BR><FONT size=5>&gt;Note that although 3) and 4) appear to be the same, the reason I have</FONT><BR><FONT size=5>&gt;them as different questions is that in one case the TE link switching</FONT><BR><FONT size=5>&gt;capability is examined and in the other case
 the Generalized Label Request</FONT><BR><FONT size=5>&gt;is examined.</FONT><BR><BR><BR><BR><FONT size=5>-&gt; what it appears to me is that this discussion mixes the issue of the operation describing the stitching operations at the domain boundaries from the LSP segment creation itself i.e. an LSP segment can indeed be an FA link inherited from the creation of an (intra-domain) FA-LSP - </FONT></P></BLOCKQUOTE></DIV><p>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam?  Yahoo! Mail has the best spam protection around <br>http://mail.yahoo.com 
--0-499060946-1121886946=:94207--

Delivery-date: Wed, 20 Jul 2005 19:08:22 +0000
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: LSP stitching questions for discussion
Date: Wed, 20 Jul 2005 21:08:01 +0200

Delivery-date: Wed, 20 Jul 2005 19:01:16 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: "Arthi Ayyangar" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: LSP stitching questions for discussion
Date: Wed, 20 Jul 2005 15:00:43 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_013A_01C58D3B.CD519570
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dimitri,

igor -=20

  it is "no" to all the below a), b) and c) - as logical consequence of =
the current GMPLS architecture

  note: to clarify one of my note here below (where it seems you were =
not in agreement) about PSC LSP bandwidth and segment stitching i.e. =
larger bandwidth reservation for the segment than for the end-to-end LSP =
does not mean different PSC level (note: PSC-1, -2, -3 and -4 are not =
"layers" they should simply be referred to as levels but this is another =
discussion) so i wanted to clarify that the default admission control =
rules for the packet case - within the same PSC level - could be relaxed =
compared to the other switching technologies without stretching the =
stitching concept

  IB>> My question c) was:
  c) Is it possible (should we allow) to stitch  PSC1 e2e LSP by a PSC2 =
LSP segment ?

  If you say NO to this question, than the answer contradicts to what =
you said above in your note.

  You are right: whether PSC1 and PSC2 are separate network layers or =
not is a topic of a separate (painful :=3D)) discussion. However, I just =
wanted to point out here that a PSC2 LSP is a provisioned as such for a =
reason: it is meant to *nest* PSC1 LSPs rather than to stitch them. From =
the VNT management point of view PSC2 and PSC1 are separate topological =
layers. that is PSC2 produces topology for PSC1, just like VC4 produces =
topology for VC12.
  The only difference is that in the latter case this relationship is =
forced by the hardware, and in the former case is not (just logical). =
Take for example C and C++ programming. Certain things you simply forced =
not to do in C++, whereas in C you could but shouldn't.

  See you in Paris.
  Igor

  "Igor Bryskin" <[email-masked]>
  Sent by: [email-masked]
  07/20/2005 13:25 AST

  To: "Arthi Ayyangar" <[email-masked]>, Dimitri =
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
  cc: <[email-masked]>
  bcc:=20
  Subject: Re: LSP stitching questions for discussion

  Dimitri,

  It seems to me that I mostly agree(?!) with what you wrote in this =
mail. I'd still want to confirm your views  on the following questions:

  a) Is it possible (should we allow) to stitch  PSC1 e2e LSP by a LSC =
LSP segment ?=20

  b) Is it possible (should we allow) to stitch  VC12 e2e LSP by a VC4 =
LSP segment ?=20
  c) Is it possible (should we allow) to stitch  PSC1 e2e LSP by a PSC2 =
LSP segment ?

  My answers are NO to all three questions. You can sticth PSC1 with =
PSC1, VC12 with VC12, etc. In all other cases you need, first, to setup =
a hierarchical LSP (H-LSP) (whether it is FA-LSP (single domain) or not =
(multi-domain)) in order to create a data link of the e2e LSP switching =
capability and only after that you can also use a stitching segment on =
top of  this H-LSP).

  See also in-line.

  Igor

  ----- Original Message -----=20
  From: [email-masked]=20
  To: Arthi Ayyangar=20
  Cc: Igor Bryskin ; [email-masked]=20
  Sent: Wednesday, July 20, 2005 4:46 AM
  Subject: Re: LSP stitching questions for discussion

  arthi,=20

  first a recap: this item on stitching was initiated in order to allow =
per "domain" control of end-to-end (contiguous) LSP, as part of a =
separate document, and not to extend its scope (unduly, in this case, =
see below) but mainly in order to have the set of all related protocol =
mechanisms within a specific document -

  from this initial working assumption, it is clear that the segment =
must have the properties of the incoming end-to-end LSP which are =
determined among other by its switching type e.g. PSC-3 or TDM, the =
first requirement of LSP stitching is contiguity of the end-to-end LSP =
at the data plane level (after stitching operation) - and this by =
definition of the initial working assumption -

  IB>> Agree

  note: the only latitude which is left (for a given switching type e.g. =
PSC-2) is due to the properties of packet (PSC) networks that allows you =
stitch a segment having a larger Max Reservable Bandwidth and Unreserved =
Bandwidth (we would have equivalent latitude for other attributes but =
this is a local policy decision - which at the end is the sole purpose =
of this approach)

  IB>> Disagree. Conceptually PCS1 and PSC2 are different layers and the =
latter cannot stitch the former, just like in case VC12 and VC4. You =
should nest PSC1 within PSC2 instead.

  Here are some of the questions related to LSP stitching to start a
  discussion on the usage of LSP stitching.

  >1) Are the control plane signaling procedures for LSP stitching as
  >described in this ID, (explicit request for LSP stitching on
  >LSP segment, different label allocation rules; etc) REQUIRED to =
stitch
  >packet LSPs in data plane ?

  -> yes (beside manual config operation)

  IB>> Agree

  >2) Are the control plane signaling procedures for LSP stitching as
  >described in this ID, (explicit request for LSP stitching on
  >LSP segment, different label allocation rules; etc) REQUIRED to =
stitch
  >non-packet LSPs in data plane ?

  -> yes (beside manual config operation)

  IB>> Agree

  >3) If an e2e LSP crosses a region boundary (based on different TE
  >link switching capabilities), then can I use LSP stitching -
  >a) control plane procedures for packet LSPs
  >b) data plane procedures for packet LSPs
  >c) control plane procedures for non-packet LSPs
  >d) data plane procedures for non-packet LSPs

  -> no, when crossing a region boundary, you simply use a document =
named "draft-mpls-lsp-hierarchy-08.txt" which is in the RFC Editor =
queue, but this does not prevent from creating an LSP segment on top of =
an FA-LSP (see below)

  IB>> Agree with the caviat that it should be H-LSP instead of FA-LSP =
to cover single and multi-domain scenarios

  >4) If the switching type of an e2e LSP is different from that of an =
LSP
  >segment, can I use LSP stitching=20
  >a) control plane procedures for packet LSPs
  >b) data plane procedures for packet LSPs
  >c) control plane procedures for non-packet LSPs
  >d) data plane procedures for non-packet LSPs

  -> no, in this case progression of the end-to-end LSP establishment, =
implies that the LSP segment must fulfil a set of constraints carried as =
part of the incoming end-to-end LSP request, in this case one has to =
create an LSP segment (with a switching type equal to the incoming =
end-to-end LSP switching type) over that FA (i.e. referred here above to =
the LSP segment with a different Switching Type)

  IB>> Agree with the caviat that it should be H-LSP instead of FA-LSP =
to cover single and multi-domain scenarios

  Cheers,

  Igor

  >Note that although 3) and 4) appear to be the same, the reason I have
  >them as different questions is that in one case the TE link switching
  >capability is examined and in the other case the Generalized Label =
Request
  >is examined.

  -> what it appears to me is that this discussion mixes the issue of =
the operation describing the stitching operations at the domain =
boundaries from the LSP segment creation itself i.e. an LSP segment can =
indeed be an FA link inherited from the creation of an (intra-domain) =
FA-LSP -=20

------=_NextPart_000_013A_01C58D3B.CD519570
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dimitri,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DMonospace,Courier>igor - </FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P>&nbsp;</P>
  <P><FONT face=3DMonospace,Courier>it is "no" to all the below a), b) =
and c) - as=20
  logical consequence of the current GMPLS architecture</FONT></P>
  <P>&nbsp;</P>
  <P><FONT face=3DMonospace,Courier>note: to clarify one of my note here =
below=20
  (where it seems you were not in agreement) about PSC LSP bandwidth and =
segment=20
  stitching i.e. larger bandwidth reservation for the segment than for =
the=20
  end-to-end LSP does not mean different PSC level (note: PSC-1, -2, -3 =
and -4=20
  are not "layers" they should simply be referred to as levels but this =
is=20
  another discussion) so i wanted to clarify that the default admission =
control=20
  rules for the packet case - within the same PSC level - could be =
relaxed=20
  compared to the other switching technologies without stretching the =
stitching=20
  concept</FONT></P><FONT face=3D"Courier New"></FONT></BLOCKQUOTE>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3D"Courier New">IB&gt;&gt; My question c) =
was:</FONT></DIV>
  <DIV><FONT face=3D"Courier New"><FONT face=3D"Times New Roman">c) Is =
it possible=20
  (should we allow) to stitch&nbsp;&nbsp;PSC1 e2e LSP by a&nbsp;PSC2 LSP =
segment=20
  ?</FONT><BR></FONT></DIV>
  <DIV><FONT face=3D"Courier New">If you say NO to this question, than =
the answer=20
  contradicts to what you said above in your note.</FONT></DIV>
  <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New"><FONT face=3DArial size=3D2>You are =
right: whether=20
  PSC1 and PSC2 are separate network layers or not is a topic of a =
separate=20
  (painful :=3D)) discussion. However, I just wanted to point out here =
that a PSC2=20
  LSP is a provisioned as such for a reason:&nbsp;it is meant to *nest* =
PSC1=20
  LSPs rather than to stitch them. From the VNT management point of view =
PSC2=20
  and PSC1 are separate topological layers. that is PSC2 produces =
topology for=20
  PSC1, just like VC4 produces topology for VC12.</FONT></FONT></DIV>
  <DIV><FONT face=3D"Courier New"><FONT face=3DArial size=3D2>The only =
difference is=20
  that in the latter case this relationship is forced by the hardware, =
and in=20
  the former case is not (just logical). Take for example C and C++ =
programming.=20
  Certain things you simply forced not to do in C++, whereas in C you =
could but=20
  shouldn't.</FONT></FONT></DIV>
  <DIV><FONT face=3D"Courier New"><FONT face=3DArial=20
  size=3D2></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New"><FONT face=3DArial size=3D2>See you in =

  Paris.</FONT></FONT></DIV>
  <DIV><FONT face=3D"Courier New"><FONT face=3DArial =
size=3D2>Igor</FONT></DIV></FONT>
  <P><FONT face=3DArial size=3D2></FONT><BR><BR></P>
  <P><FONT size=3D2><B>"Igor Bryskin"=20
  &lt;[email-masked]&gt;</B></FONT><BR><FONT size=3D2>Sent by:=20
  [email-masked]</FONT><BR><FONT size=3D2>07/20/2005 13:25=20
  AST</FONT><BR><BR><FONT size=3D2>To:</FONT> <FONT size=3D2>"Arthi =
Ayyangar"=20
  &lt;[email-masked]&gt;, Dimitri=20
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL</FONT><BR><FONT size=3D2>cc:</FONT> =
<FONT=20
  size=3D2>&lt;[email-masked]&gt;</FONT><BR><FONT =
size=3D2>bcc:</FONT> <BR><FONT=20
  size=3D2>Subject:</FONT> <FONT size=3D2>Re: LSP stitching questions =
for=20
  discussion</FONT><BR><BR><BR></P>
  <P>Dimitri,<BR><BR>It seems to me that I mostly agree(?!) with what =
you wrote=20
  in this mail. I'd still want to confirm your views&nbsp; on the =
following=20
  questions:<BR><BR><BR>a) Is it possible (should we allow) to =
stitch&nbsp; PSC1=20
  e2e LSP by a LSC LSP segment ? <BR><BR>b) Is it possible (should we =
allow) to=20
  stitch&nbsp;&nbsp;VC12 e2e LSP by a&nbsp;VC4 LSP segment ? <BR>c) Is =
it=20
  possible (should we allow) to stitch&nbsp;&nbsp;PSC1 e2e LSP by =
a&nbsp;PSC2=20
  LSP segment ?<BR><BR>My answers are NO to all three questions. You can =
sticth=20
  PSC1 with PSC1, VC12 with VC12, etc. In all other cases you need, =
first, to=20
  setup a hierarchical LSP (H-LSP) (whether it is FA-LSP (single domain) =
or=20
  not&nbsp;(multi-domain)) in order to create a data link of the e2e LSP =

  switching capability and only after that you can also&nbsp;use a =
stitching=20
  segment on top of &nbsp;this H-LSP).<BR><BR>See also=20
  in-line.<BR><BR>Igor<BR><BR><BR><FONT size=3D4>----- Original Message =
-----=20
  </FONT><BR><FONT size=3D4><B>From:</B> </FONT><FONT color=3Dblue =
size=3D4><U><A=20
  =
href=3D"mailto:[email-masked]">Dimitri.Papadimitriou@al=
catel.be</A></U></FONT><FONT=20
  color=3Dblack size=3D4> </FONT><BR><FONT size=3D4><B>To:</B> =
</FONT><FONT color=3Dblue=20
  size=3D4><U><A href=3D"mailto:[email-masked]">Arthi=20
  Ayyangar</A></U></FONT><FONT color=3Dblack size=3D4> </FONT><BR><FONT=20
  size=3D4><B>Cc:</B> </FONT><FONT color=3Dblue size=3D4><U><A=20
  href=3D"mailto:[email-masked]">Igor Bryskin</A></U></FONT><FONT =
color=3Dblack=20
  size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A></U></FONT><FONT=
=20
  color=3Dblack size=3D4> </FONT><BR><FONT size=3D4><B>Sent:</B> =
Wednesday, July 20,=20
  2005 4:46 AM</FONT><BR><FONT size=3D4><B>Subject:</B> Re: LSP =
stitching=20
  questions for discussion</FONT><BR><BR><FONT size=3D4>arthi,=20
  </FONT><BR><BR><BR><BR><FONT size=3D4>first a recap: this item on =
stitching was=20
  initiated in order to allow per "domain" control of end-to-end =
(contiguous)=20
  LSP, as part of a separate document, and not to extend its scope =
(unduly, in=20
  this case, see below) but mainly in order to have the set of all =
related=20
  protocol mechanisms within a specific document =
-</FONT><BR><BR><BR><BR><FONT=20
  size=3D4>from this initial working assumption, it is clear that the =
segment must=20
  have the properties of the incoming end-to-end LSP which are =
determined among=20
  other by its switching type e.g. PSC-3 or TDM, the first requirement =
of LSP=20
  stitching is contiguity of the end-to-end LSP at the data plane level =
(after=20
  stitching operation) - and this by definition of the initial working=20
  assumption -</FONT><BR><BR><FONT size=3D4>IB&gt;&gt; =
Agree</FONT><BR><BR><FONT=20
  size=3D4>note: the only latitude which is left (for a given switching =
type e.g.=20
  PSC-2) is due to the properties of packet (PSC) networks that allows =
you=20
  stitch a segment having a larger Max Reservable Bandwidth and =
Unreserved=20
  Bandwidth (we would have equivalent latitude for other attributes but =
this is=20
  a local policy decision - which at the end is the sole purpose of this =

  approach)</FONT><BR><BR><FONT size=3D4>IB&gt;&gt; Disagree. =
Conceptually PCS1=20
  and PSC2 are different layers and the latter cannot stitch the former, =
just=20
  like in case VC12 and VC4. You should nest PSC1 within PSC2=20
  instead.</FONT><BR><BR><BR><BR><FONT size=3D4>Here are some of the =
questions=20
  related to LSP stitching to start a</FONT><BR><FONT =
size=3D4>discussion on the=20
  usage of LSP stitching.</FONT><BR><BR><FONT size=3D4>&gt;1) Are the =
control=20
  plane signaling procedures for LSP stitching as</FONT><BR><FONT=20
  size=3D4>&gt;described in this ID, (explicit request for LSP stitching =

  on</FONT><BR><FONT size=3D4>&gt;LSP segment, different label =
allocation rules;=20
  etc) REQUIRED to stitch</FONT><BR><FONT size=3D4>&gt;packet LSPs in =
data plane=20
  ?</FONT><BR><BR><BR><FONT size=3D4>-&gt; yes (beside manual config=20
  operation)</FONT><BR><BR><FONT size=3D4>IB&gt;&gt; =
Agree</FONT><BR><BR><BR><FONT=20
  size=3D4>&gt;2) Are the control plane signaling procedures for LSP =
stitching=20
  as</FONT><BR><FONT size=3D4>&gt;described in this ID, (explicit =
request for LSP=20
  stitching on</FONT><BR><FONT size=3D4>&gt;LSP segment, different label =

  allocation rules; etc) REQUIRED to stitch</FONT><BR><FONT=20
  size=3D4>&gt;non-packet LSPs in data plane ?</FONT><BR><BR><BR><FONT=20
  size=3D4>-&gt; yes (beside manual config =
operation)</FONT><BR><BR><FONT=20
  size=3D4>IB&gt;&gt; Agree</FONT><BR><BR><BR><FONT size=3D4>&gt;3) If =
an e2e LSP=20
  crosses a region boundary (based on different TE</FONT><BR><FONT=20
  size=3D4>&gt;link switching capabilities), then can I use LSP =
stitching=20
  -</FONT><BR><FONT size=3D4>&gt;a) control plane procedures for packet=20
  LSPs</FONT><BR><FONT size=3D4>&gt;b) data plane procedures for packet=20
  LSPs</FONT><BR><FONT size=3D4>&gt;c) control plane procedures for =
non-packet=20
  LSPs</FONT><BR><FONT size=3D4>&gt;d) data plane procedures for =
non-packet=20
  LSPs</FONT><BR><BR><BR><FONT size=3D4>-&gt; no, when crossing a region =
boundary,=20
  you simply use a document named "draft-mpls-lsp-hierarchy-08.txt" =
which is in=20
  the RFC Editor queue, but this does not prevent from creating an LSP =
segment=20
  on top of an FA-LSP (see below)</FONT><BR><BR><FONT =
size=3D4>IB&gt;&gt; Agree=20
  with the caviat that it should be H-LSP instead of FA-LSP to cover =
single and=20
  multi-domain scenarios</FONT><BR><BR><BR><FONT size=3D4>&gt;4) If the =
switching=20
  type of an e2e LSP is different from that of an LSP</FONT><BR><FONT=20
  size=3D4>&gt;segment, can I use LSP stitching </FONT><BR><FONT =
size=3D4>&gt;a)=20
  control plane procedures for packet LSPs</FONT><BR><FONT =
size=3D4>&gt;b) data=20
  plane procedures for packet LSPs</FONT><BR><FONT size=3D4>&gt;c) =
control plane=20
  procedures for non-packet LSPs</FONT><BR><FONT size=3D4>&gt;d) data =
plane=20
  procedures for non-packet LSPs</FONT><BR><BR><BR><FONT size=3D4>-&gt; =
no, in=20
  this case progression of the end-to-end LSP establishment, implies =
that the=20
  LSP segment must fulfil a set of constraints carried as part of the =
incoming=20
  end-to-end LSP request, in this case one has to create an LSP segment =
(with a=20
  switching type equal to the incoming end-to-end LSP switching type) =
over that=20
  FA (i.e. referred here above to the LSP segment with a different =
Switching=20
  Type)</FONT><BR><FONT size=3D4></FONT><BR><BR><FONT =
size=3D4>IB&gt;&gt; Agree with=20
  the caviat that it should be H-LSP instead of FA-LSP to cover single =
and=20
  multi-domain scenarios</FONT><BR><BR>Cheers,<BR><BR>Igor<BR><BR><FONT=20
  size=3D4>&gt;Note that although 3) and 4) appear to be the same, the =
reason I=20
  have</FONT><BR><FONT size=3D4>&gt;them as different questions is that =
in one=20
  case the TE link switching</FONT><BR><FONT size=3D4>&gt;capability is =
examined=20
  and in the other case the Generalized Label Request</FONT><BR><FONT=20
  size=3D4>&gt;is examined.</FONT><BR><BR><BR><BR><FONT size=3D4>-&gt; =
what it=20
  appears to me is that this discussion mixes the issue of the operation =

  describing the stitching operations at the domain boundaries from the =
LSP=20
  segment creation itself i.e. an LSP segment can indeed be an FA link =
inherited=20
  from the creation of an (intra-domain) FA-LSP -=20
</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_013A_01C58D3B.CD519570--

Delivery-date: Wed, 20 Jul 2005 18:34:31 +0000
To: "Igor Bryskin" <[email-masked]>
Cc: "Arthi Ayyangar" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: LSP stitching questions for discussion
Date: Wed, 20 Jul 2005 20:33:07 +0200

Delivery-date: Wed, 20 Jul 2005 18:19:12 +0000
Date: Wed, 20 Jul 2005 11:18:37 -0700 (PDT)
From: Igor Bryskin <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
To: Arthi Ayyangar <[email-masked]>, Igor Bryskin <[email-masked]>
Cc: [email-masked]

--0-512571639-1121883517=:99174
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Thanks, sounds like a good idea.
 
Igor

Arthi Ayyangar <[email-masked]> wrote:
Hi Igor,

> One more comment. I think the draft should give a clear and unambiguous
> answer to how e2e LSP and a stitching LSP (S-LSP) relate from the switching
> capability point of view. Specifically, should they belong to the same
> network layer, should they share the same switching type or maybe there are
> no limitations at all, and you can stitch your e2e LSP pretty much with
> anything you got, provided that this "anything" has enough bandwidth.
>
> Let me give you a specific example. Is it possible to stitch a PSC1 e2e LSP
> with a PSC2 S-LSP? You probably remember our discussion with Kireeti in
> Minneapolis (and you were also part of it), and he said (and I 100% agree
> with him) that although it is doable (you can do anything you want with the
> label stack), it is not right and this should be logically prohibited. What
> you should do in this case is to nest the e2e LSP within the PSC2 LSP (that
> is, use it as H-LSP) even in case it consumes the entire PSC2 LSP bandwidth.
---> I do remember this discussion.

> It is more clear in non-PSC cases. Although it is possible to "stitch" an
> e2e VC12 LSP with a VC4 S-LSP, I could not imagine that a network operator
> would ever agree with such solution. He is likely to say " What ? If the
> service is supposed to stay for 12 month, than for entire year I pretty much
> burry my 62 VC12 channels - I cannot use them even conceptually in case
> when, say, on the next day I'll have to provide another 62 VC12 services
> that could've used these wasted resources"
>
> On the other hand I know plenty GMPLS people who would say: "Sure, no
> problem. Of course we can stitch a PSC e2e LSP with lambda S-LSP: If
> somebody wants to do a trick stupid as it is, why should we prevent him from
> doing so?"
----> I know some of these people too. :-)

> The bottom line is that a discussion like this in the draft and consensus
> on how we see the stitching IMO would be extremely valuable for the GMPLS
> multi-layer story, and I don't see a reason why this could not be achieved
> in the frame of this work.
------> I agree that we should have a discussion on this, but I would
like folks to have this discussion on the list first, which I thank
you for initiating.

Yes, the draft has to state clearly whether LSP stitching between
different switching capabilities is allowed or not. But it's more than
that. Currently, the draft talks about this under sections 3.1 and 4.1
and 4.1.2.

But, let us have this discussion on the list and we will be glad to add
what's missing (with required details) to the ID, depending on the
consensus reached. I will send out the questions to start the discussion
in the next email.

thanks,
-arthi

>
> ----- Original Message -----
> From: "Arthi Ayyangar" 
> To: "Igor Bryskin" 
> Cc: ; ;
> 
> Sent: Monday, July 18, 2005 2:51 PM
> Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
>
>
> > Hi Igor,
> >
> > Please see inline.
> >
> > > 1. Why are saying that LSP Stitching is a private case of LSP Hierarchy?
> >
> > > there is more differences than similarities:
> > > The differences are:
> > > 1) In case of H-LSP there is a data plane adjacency, while in case of
> S-LSP
> > > there is none (as you correctly pointed out);
> > > 2) In case of H-LSP there is an adaptation in data plane (label push/pop
> for
> > > PSC), while in case of S-LSP there is none - just simple
> cross-connecting
> > > ( label swap) as in case of two "native " e2e LSP adjacent segments ;
> > > 3) H-LSP could be used by many e2e LSPs, while S-LSP could be used by
> > > exactly one e2e LSP
> > > 4) Signaling is different - there is no label negotiation in stitching
> > > 5) H-LSP is used as a "true" data link, specifically there is a resource
> > > allocation on the H-LSP edges, while in case of S-LSP there is none
> > > 6) From MLN point of view, H-LSP is created in a server (lower) layer,
> while
> > > the S-LSP is created in the client (same as e2e LSP) layer.
> > >
> > > There are two similarities that I can think of:
> > > 1) There is a signaling and possibly routing (see below) adjacencies
> between
> > > the ends;
> > > 2) Both H-LSP and S-LSP could be advertised as separate TE links or as
> TE
> > > bundles
> > >
> > > I would recommend to dedicate a paragraph and enlist there similarities
> and
> > > differencies
> > -------> Based on the discussions on the list over the last revision, the
> > message that the authors received was that we do not want to go about such
> > a lengthy discussion of similarities and differences (NOTE that the draft
> > already does clearly highlight them where applicable). Instead we want
> > this ID to simply explain how LSP stitching functions. In other words the
> > idea was to make this ID a complete document by itself. But since it does
> > borrow concepts from the LSP hierarchy ID, just state the concepts that
> > are applicable or inapplicable.
> >
> > > 2. Why are you saying that a TE Link based on S-LSP can be used for
> exactly
> > > one e2e LSP? Parallel S-LSPs could be advertised as a single TE link
> > > (bundle, see above) and hence can accomadate several e2e LSPs.
> > ----> Igor, the draft does talk about this Bundling case.
> >
> > > 3. You are saying that S-LSP does not have a routing peering. Actually,
> in
> > > this respect it is no different from H-LSP: if it is advertised as a TE
> link
> > > into the same TE domain that was used for S-LSP creation (unlikely IMO
> > > scenario) than it does not require the routing adjacency (in other
> words, it
> > > is an FA according to LSP-HIER definition), otherwise, it IS NOT and FA
> and
> > > does require the direct routing peering in the domain it is advertised
> to
> > > make it useful as a TE link in this domain
> > -----> I am sorry, but I am missing your point here completely. Are you
> > saying that the statement "the end points of an LSP segment do not have a
> > routing adjacency", is incorrect or are you saying that "this is
> > obvious" ? It is unclear to me what exactly your argument is. Please
> > clarify.
> >
> > thanks,
> > -arthi
> >
> > >
> > > Cheers,
> > > Igor
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: 
> > > To: 
> > > Cc: 
> > > Sent: Friday, July 15, 2005 3:50 PM
> > > Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
> > >
> > >
> > > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > > > This draft is a work item of the Common Control and Measurement Plane
> > > Working Group of the IETF.
> > > >
> > > > Title : Label Switched Path Stitching with Generalized MPLS Traffic
> > > Engineering
> > > > Author(s) : A. Ayyangar, J. Vasseur
> > > > Filename : draft-ietf-ccamp-lsp-stitching-01.txt
> > > > Pages : 19
> > > > Date : 2005-7-15
> > > >
> > > > In certain scenarios, there may be a need to combine together two
> > > > different Generalized Multi-Protocol Label Switching (GMPLS) Label
> > > > Switched Paths (LSPs) such that in the data plane, a single end-to-
> > > > end (e2e) LSP is achieved and all traffic from one LSP is switched
> > > > onto the other LSP. We will refer to this as "LSP stitching".
> This
> > > > document covers cases where: a) the node performing the stitching
> > > > does not require configuration of every LSP pair to be stitched
> > > > together b) the node performing the stitching is not the egress of
> > > > any of the LSPs c) LSP stitching not only results in an end-to-end
> > > > LSP in the data plane, but there is also a corresponding end-to-end
> > > > LSP (RSVP session) in the control plane. It might be possible to
> > > > configure a GMPLS node to switch the traffic from an LSP for which
> it
> > > > is the egress, to another LSP for which it is the ingress, without
> > > > requiring any signaling or routing extensions whatsoever,
> completely
> > > > transparent to other nodes. This will also result in LSP stitching
> > > > in the data plane. However, this document does not cover this
> > > > scenario of LSP stitching.
> > > >
> > > > A URL for this Internet-Draft is:
> > > >
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt
> > > >
> > > > To remove yourself from the I-D Announcement list, send a message to
> > > > [email-masked] with the word unsubscribe in the body of
> the
> > > message.
> > > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > > to change your subscription settings.
> > > >
> > > >
> > > > Internet-Drafts are also available by anonymous FTP. Login with the
> > > username
> > > > "anonymous" and a password of your e-mail address. After logging in,
> > > > type "cd internet-drafts" and then
> > > > "get draft-ietf-ccamp-lsp-stitching-01.txt".
> > > >
> > > > A list of Internet-Drafts directories can be found in
> > > > http://www.ietf.org/shadow.html
> > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > >
> > > > Internet-Drafts can also be obtained by e-mail.
> > > >
> > > > Send a message to:
> > > > [email-masked].
> > > > In the body type:
> > > > "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
> > > >
> > > > NOTE: The mail server at ietf.org can return the document in
> > > > MIME-encoded form by using the "mpack" utility. To use this
> > > > feature, insert the command "ENCODING mime" before the "FILE"
> > > > command. To decode the response(s), you will need "munpack" or
> > > > a MIME-compliant mail reader. Different MIME-compliant mail readers
> > > > exhibit different behavior, especially when dealing with
> > > > "multipart" MIME messages (i.e. documents which have been split
> > > > up into multiple messages), so check your local documentation on
> > > > how to manipulate these messages.
> > > >
> > > >
> > > > Below is the data which will enable a MIME compliant mail reader
> > > > implementation to automatically retrieve the ASCII version of the
> > > > Internet-Draft.
> > > >
> > >
> >
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-512571639-1121883517=:99174
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>Thanks, sounds like a good idea.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Igor<BR><BR><B><I>Arthi Ayyangar &lt;[email-masked]&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Hi Igor,<BR><BR>&gt; One more comment. I think the draft should give a clear and unambiguous<BR>&gt; answer to how e2e LSP and a stitching LSP (S-LSP) relate from the switching<BR>&gt; capability point of view. Specifically, should they belong to the same<BR>&gt; network layer, should they share the same switching type or maybe there are<BR>&gt; no limitations at all, and you can stitch your e2e LSP pretty much with<BR>&gt; anything you got, provided that this "anything" has enough bandwidth.<BR>&gt;<BR>&gt; Let me give you a specific example. Is it possible to stitch a PSC1 e2e LSP<BR>&gt; with a PSC2 S-LSP? You probably remember our discussion with Kireeti in<BR>&gt; Minneapolis (and you were also part of it), and he said (and I 100% agree<BR>&gt; with him) that although it is doable (you can do anything you want with the<BR>&gt; label stack), it is not right and this should be
 logically prohibited. What<BR>&gt; you should do in this case is to nest the e2e LSP within the PSC2 LSP (that<BR>&gt; is, use it as H-LSP) even in case it consumes the entire PSC2 LSP bandwidth.<BR><AA>---&gt; I do remember this discussion.<BR><BR><BR>&gt; It is more clear in non-PSC cases. Although it is possible to "stitch" an<BR>&gt; e2e VC12 LSP with a VC4 S-LSP, I could not imagine that a network operator<BR>&gt; would ever agree with such solution. He is likely to say " What ? If the<BR>&gt; service is supposed to stay for 12 month, than for entire year I pretty much<BR>&gt; burry my 62 VC12 channels - I cannot use them even conceptually in case<BR>&gt; when, say, on the next day I'll have to provide another 62 VC12 services<BR>&gt; that could've used these wasted resources"<BR>&gt;<BR>&gt; On the other hand I know plenty GMPLS people who would say: "Sure, no<BR>&gt; problem. Of course we can stitch a PSC e2e LSP with lambda S-LSP: If<BR>&gt; somebody wants to do a trick
 stupid as it is, why should we prevent him from<BR>&gt; doing so?"<BR><AA>----&gt; I know some of these people too. :-)<BR><BR>&gt; The bottom line is that a discussion like this in the draft and consensus<BR>&gt; on how we see the stitching IMO would be extremely valuable for the GMPLS<BR>&gt; multi-layer story, and I don't see a reason why this could not be achieved<BR>&gt; in the frame of this work.<BR><AA>------&gt; I agree that we should have a discussion on this, but I would<BR>like folks to have this discussion on the list first, which I thank<BR>you for initiating.<BR><BR>Yes, the draft has to state clearly whether LSP stitching between<BR>different switching capabilities is allowed or not. But it's more than<BR>that. Currently, the draft talks about this under sections 3.1 and 4.1<BR>and 4.1.2.<BR><BR>But, let us have this discussion on the list and we will be glad to add<BR>what's missing (with required details) to the ID, depending on the<BR>consensus reached. I will send
 out the questions to start the discussion<BR>in the next email.<BR><BR>thanks,<BR>-arthi<BR><BR>&gt;<BR>&gt; ----- Original Message -----<BR>&gt; From: "Arthi Ayyangar" <[email-masked]><BR>&gt; To: "Igor Bryskin" <[email-masked]><BR>&gt; Cc: <[email-masked]>; <[email-masked]>;<BR>&gt; <[email-masked]><BR>&gt; Sent: Monday, July 18, 2005 2:51 PM<BR>&gt; Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt<BR>&gt;<BR>&gt;<BR>&gt; &gt; Hi Igor,<BR>&gt; &gt;<BR>&gt; &gt; Please see inline.<BR>&gt; &gt;<BR>&gt; &gt; &gt; 1. Why are saying that LSP Stitching is a private case of LSP Hierarchy?<BR>&gt; &gt;<BR>&gt; &gt; &gt; there is more differences than similarities:<BR>&gt; &gt; &gt; The differences are:<BR>&gt; &gt; &gt; 1) In case of H-LSP there is a data plane adjacency, while in case of<BR>&gt; S-LSP<BR>&gt; &gt; &gt; there is none (as you correctly pointed out);<BR>&gt; &gt; &gt; 2) In case of H-LSP there is an adaptation in data plane (label
 push/pop<BR>&gt; for<BR>&gt; &gt; &gt; PSC), while in case of S-LSP there is none - just simple<BR>&gt; cross-connecting<BR>&gt; &gt; &gt; ( label swap) as in case of two "native " e2e LSP adjacent segments ;<BR>&gt; &gt; &gt; 3) H-LSP could be used by many e2e LSPs, while S-LSP could be used by<BR>&gt; &gt; &gt; exactly one e2e LSP<BR>&gt; &gt; &gt; 4) Signaling is different - there is no label negotiation in stitching<BR>&gt; &gt; &gt; 5) H-LSP is used as a "true" data link, specifically there is a resource<BR>&gt; &gt; &gt; allocation on the H-LSP edges, while in case of S-LSP there is none<BR>&gt; &gt; &gt; 6) From MLN point of view, H-LSP is created in a server (lower) layer,<BR>&gt; while<BR>&gt; &gt; &gt; the S-LSP is created in the client (same as e2e LSP) layer.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; There are two similarities that I can think of:<BR>&gt; &gt; &gt; 1) There is a signaling and possibly routing (see below) adjacencies<BR>&gt; between<BR>&gt; &gt; &gt; the
 ends;<BR>&gt; &gt; &gt; 2) Both H-LSP and S-LSP could be advertised as separate TE links or as<BR>&gt; TE<BR>&gt; &gt; &gt; bundles<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; I would recommend to dedicate a paragraph and enlist there similarities<BR>&gt; and<BR>&gt; &gt; &gt; differencies<BR>&gt; &gt; -------&gt; Based on the discussions on the list over the last revision, the<BR>&gt; &gt; message that the authors received was that we do not want to go about such<BR>&gt; &gt; a lengthy discussion of similarities and differences (NOTE that the draft<BR>&gt; &gt; already does clearly highlight them where applicable). Instead we want<BR>&gt; &gt; this ID to simply explain how LSP stitching functions. In other words the<BR>&gt; &gt; idea was to make this ID a complete document by itself. But since it does<BR>&gt; &gt; borrow concepts from the LSP hierarchy ID, just state the concepts that<BR>&gt; &gt; are applicable or inapplicable.<BR>&gt; &gt;<BR>&gt; &gt; &gt; 2. Why are you saying that a
 TE Link based on S-LSP can be used for<BR>&gt; exactly<BR>&gt; &gt; &gt; one e2e LSP? Parallel S-LSPs could be advertised as a single TE link<BR>&gt; &gt; &gt; (bundle, see above) and hence can accomadate several e2e LSPs.<BR>&gt; &gt; ----&gt; Igor, the draft does talk about this Bundling case.<BR>&gt; &gt;<BR>&gt; &gt; &gt; 3. You are saying that S-LSP does not have a routing peering. Actually,<BR>&gt; in<BR>&gt; &gt; &gt; this respect it is no different from H-LSP: if it is advertised as a TE<BR>&gt; link<BR>&gt; &gt; &gt; into the same TE domain that was used for S-LSP creation (unlikely IMO<BR>&gt; &gt; &gt; scenario) than it does not require the routing adjacency (in other<BR>&gt; words, it<BR>&gt; &gt; &gt; is an FA according to LSP-HIER definition), otherwise, it IS NOT and FA<BR>&gt; and<BR>&gt; &gt; &gt; does require the direct routing peering in the domain it is advertised<BR>&gt; to<BR>&gt; &gt; &gt; make it useful as a TE link in this domain<BR>&gt; &gt; -----&gt; I am
 sorry, but I am missing your point here completely. Are you<BR>&gt; &gt; saying that the statement "the end points of an LSP segment do not have a<BR>&gt; &gt; routing adjacency", is incorrect or are you saying that "this is<BR>&gt; &gt; obvious" ? It is unclear to me what exactly your argument is. Please<BR>&gt; &gt; clarify.<BR>&gt; &gt;<BR>&gt; &gt; thanks,<BR>&gt; &gt; -arthi<BR>&gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Cheers,<BR>&gt; &gt; &gt; Igor<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; ----- Original Message -----<BR>&gt; &gt; &gt; From: <[email-masked]><BR>&gt; &gt; &gt; To: <[email-masked]><BR>&gt; &gt; &gt; Cc: <[email-masked]><BR>&gt; &gt; &gt; Sent: Friday, July 15, 2005 3:50 PM<BR>&gt; &gt; &gt; Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; A New Internet-Draft is available from the on-line Internet-Drafts<BR>&gt; &gt; &gt;
 directories.<BR>&gt; &gt; &gt; &gt; This draft is a work item of the Common Control and Measurement Plane<BR>&gt; &gt; &gt; Working Group of the IETF.<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Title : Label Switched Path Stitching with Generalized MPLS Traffic<BR>&gt; &gt; &gt; Engineering<BR>&gt; &gt; &gt; &gt; Author(s) : A. Ayyangar, J. Vasseur<BR>&gt; &gt; &gt; &gt; Filename : draft-ietf-ccamp-lsp-stitching-01.txt<BR>&gt; &gt; &gt; &gt; Pages : 19<BR>&gt; &gt; &gt; &gt; Date : 2005-7-15<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; In certain scenarios, there may be a need to combine together two<BR>&gt; &gt; &gt; &gt; different Generalized Multi-Protocol Label Switching (GMPLS) Label<BR>&gt; &gt; &gt; &gt; Switched Paths (LSPs) such that in the data plane, a single end-to-<BR>&gt; &gt; &gt; &gt; end (e2e) LSP is achieved and all traffic from one LSP is switched<BR>&gt; &gt; &gt; &gt; onto the other LSP. We will refer to this as "LSP stitching".<BR>&gt; This<BR>&gt; &gt;
 &gt; &gt; document covers cases where: a) the node performing the stitching<BR>&gt; &gt; &gt; &gt; does not require configuration of every LSP pair to be stitched<BR>&gt; &gt; &gt; &gt; together b) the node performing the stitching is not the egress of<BR>&gt; &gt; &gt; &gt; any of the LSPs c) LSP stitching not only results in an end-to-end<BR>&gt; &gt; &gt; &gt; LSP in the data plane, but there is also a corresponding end-to-end<BR>&gt; &gt; &gt; &gt; LSP (RSVP session) in the control plane. It might be possible to<BR>&gt; &gt; &gt; &gt; configure a GMPLS node to switch the traffic from an LSP for which<BR>&gt; it<BR>&gt; &gt; &gt; &gt; is the egress, to another LSP for which it is the ingress, without<BR>&gt; &gt; &gt; &gt; requiring any signaling or routing extensions whatsoever,<BR>&gt; completely<BR>&gt; &gt; &gt; &gt; transparent to other nodes. This will also result in LSP stitching<BR>&gt; &gt; &gt; &gt; in the data plane. However, this document does not cover this<BR>&gt;
 &gt; &gt; &gt; scenario of LSP stitching.<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; A URL for this Internet-Draft is:<BR>&gt; &gt; &gt; &gt;<BR>&gt; http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; To remove yourself from the I-D Announcement list, send a message to<BR>&gt; &gt; &gt; &gt; [email-masked] with the word unsubscribe in the body of<BR>&gt; the<BR>&gt; &gt; &gt; message.<BR>&gt; &gt; &gt; &gt; You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce<BR>&gt; &gt; &gt; &gt; to change your subscription settings.<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Internet-Drafts are also available by anonymous FTP. Login with the<BR>&gt; &gt; &gt; username<BR>&gt; &gt; &gt; &gt; "anonymous" and a password of your e-mail address. After logging in,<BR>&gt; &gt; &gt; &gt; type "cd internet-drafts" and then<BR>&gt; &gt; &gt; &gt; "get
 draft-ietf-ccamp-lsp-stitching-01.txt".<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; A list of Internet-Drafts directories can be found in<BR>&gt; &gt; &gt; &gt; http://www.ietf.org/shadow.html<BR>&gt; &gt; &gt; &gt; or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Internet-Drafts can also be obtained by e-mail.<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Send a message to:<BR>&gt; &gt; &gt; &gt; [email-masked].<BR>&gt; &gt; &gt; &gt; In the body type:<BR>&gt; &gt; &gt; &gt; "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; NOTE: The mail server at ietf.org can return the document in<BR>&gt; &gt; &gt; &gt; MIME-encoded form by using the "mpack" utility. To use this<BR>&gt; &gt; &gt; &gt; feature, insert the command "ENCODING mime" before the "FILE"<BR>&gt; &gt; &gt; &gt; command. To decode the response(s), you will need "munpack" or<BR>&gt; &gt; &gt; &gt;
 a MIME-compliant mail reader. Different MIME-compliant mail readers<BR>&gt; &gt; &gt; &gt; exhibit different behavior, especially when dealing with<BR>&gt; &gt; &gt; &gt; "multipart" MIME messages (i.e. documents which have been split<BR>&gt; &gt; &gt; &gt; up into multiple messages), so check your local documentation on<BR>&gt; &gt; &gt; &gt; how to manipulate these messages.<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Below is the data which will enable a MIME compliant mail reader<BR>&gt; &gt; &gt; &gt; implementation to automatically retrieve the ASCII version of the<BR>&gt; &gt; &gt; &gt; Internet-Draft.<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt;<BR>&gt;<BR><BR></BLOCKQUOTE><p>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam?  Yahoo! Mail has the best spam protection around <br>http://mail.yahoo.com 
--0-512571639-1121883517=:99174--

Delivery-date: Wed, 20 Jul 2005 17:47:34 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Stephen Shew" <[email-masked]>, <[email-masked]>
Subject: Re: 
Date: Wed, 20 Jul 2005 13:46:58 -0400

Stephen,

Great to hear from you.

I agree with what you said. As you correctly pointed out, there are cases
already when provisioning of an LSP does not require operations in the data
plane (e.g. make-before-break). In these cases, however, the CP is aware
that necessary data plane related provisioning is in-place already. When we
move ownership from MP to CP, the procedures from the CP point of view are
almost the same  - one exception is that the CP is not aware of the fact
that the network resources are in place already, and with simple signaling
extensions it is possible to achieve the goal with very little pain and as
reliable as make-before-break procedure is.

One other similar example. When the CP on some controller is re-synched
(after the crash or software upgrade) the situation is almost identical -
the crossconnects are in place already, the only thing to do is to restore
the CP states. The only difference here. though, that the CP can figure out
by itself that resources are in-place

Igor

----- Original Message ----- 
From: "Stephen Shew" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 20, 2005 5:54 AM

Adrian, see comment below.

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Tuesday, July 19, 2005 10:02
> To: George Newsome
> Cc: [email-masked]
> Subject: Re: Moving LSP ownership between control plane and
> management plane
>
>
> Thanks George,
>
> Useful input.
<snip>

> > - Call awareness of migration vs. connection being unaware
> of migration.
> >   When connection state is being created to match an existing
> > connection, the connection controllers (CCs) do not require
> awareness
> > of why this is happening as the context could be migration or
> > recovery.  A mechanism to create control state without affecting
> > transport plane state is needed in the CCs.  Call
> controllers though
> > do need migration awareness as they need to obtain/derive call
> > identification from the MP.
>
> I disagree.
> Connection controllers must be able to distinguish between
> resources that are already in use and cannot be assigned to a
> new connection, and those that are already in use and can be
> assigned to a new connection because the connection is
> replacing an existing connection. If this were happening
> entirely within the control plane we would use resource
> sharing, but when the operation spans the control and
> management planes resource ownership/sharing is more complex
> and the conneciotn controller needs to be able to issue the
> approriate instrucitons for the assignment of the resources.
> On the other hand, call controllers do not need awareness of
> the details of the realisation of the connections.

I'm not sure if the difference between migration awareness and the
action of creating connection state for an existing transport connection
is clear in the original point.  I agree with your first sentence and
think that signalling could be extended to include the case where
connection details (in a complete ERO) are supplied with the attribute
that the cross connections are already in place.  Similarly, teardown of
connection state can occur where cross connections are not undone.  I
still agree though with the original point and note that it does not say
that call controllers are aware of connection details.  Call controllers
are aware that a migration action is the reason for triggering the
connection controller to establish state.

The point about awareness refers to an understanding of why LSP state is
being created.  If existing LSP state is being replaced by another one
(e.g., a recovery scenario or maybe a change of the extent of the
transport connection), then I think it's sufficient for the connection
controller to be told that it should not change the cross connection
(matrix level subnetwork connection).  If the overall action fails for
some reason, the call entity can then decide whether to try again,
and/or tell the management plane what happened.

I believe that this is consistent with what the existing protocol(s)
know when they are creating LSPs.  For example, a protocol instance is
not aware whether the connection being created is a result of a "break
before make" or "make before break" scenario, or that it is the 3rd
connection being created for a VCAT group. This understanding should
only be known by the initiator of the action.

Stephen

Delivery-date: Wed, 20 Jul 2005 17:26:27 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: LSP stitching questions for discussion
Date: Wed, 20 Jul 2005 13:25:19 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_00BB_01C58D2E.79B452C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dimitri,

It seems to me that I mostly agree(?!) with what you wrote in this mail. =
I'd still want to confirm your views  on the following questions:

a) Is it possible (should we allow) to stitch  PSC1 e2e LSP by a LSC LSP =
segment ?
b) Is it possible (should we allow) to stitch  VC12 e2e LSP by a VC4 LSP =
segment ?
c) Is it possible (should we allow) to stitch  PSC1 e2e LSP by a PSC2 =
LSP segment ?

My answers are NO to all three questions. You can sticth PSC1 with PSC1, =
VC12 with VC12, etc. In all other cases you need, first, to setup a =
hierarchical LSP (H-LSP) (whether it is FA-LSP (single domain) or not =
(multi-domain)) in order to create a data link of the e2e LSP switching =
capability and only after that you can also use a stitching segment on =
top of  this H-LSP).

See also in-line.

Igor
  ----- Original Message -----=20
  From: [email-masked]=20
  To: Arthi Ayyangar=20
  Cc: Igor Bryskin ; [email-masked]=20
  Sent: Wednesday, July 20, 2005 4:46 AM
  Subject: Re: LSP stitching questions for discussion

  arthi,=20

  first a recap: this item on stitching was initiated in order to allow =
per "domain" control of end-to-end (contiguous) LSP, as part of a =
separate document, and not to extend its scope (unduly, in this case, =
see below) but mainly in order to have the set of all related protocol =
mechanisms within a specific document -

  from this initial working assumption, it is clear that the segment =
must have the properties of the incoming end-to-end LSP which are =
determined among other by its switching type e.g. PSC-3 or TDM, the =
first requirement of LSP stitching is contiguity of the end-to-end LSP =
at the data plane level (after stitching operation) - and this by =
definition of the initial working assumption -

  IB>> Agree

  note: the only latitude which is left (for a given switching type e.g. =
PSC-2) is due to the properties of packet (PSC) networks that allows you =
stitch a segment having a larger Max Reservable Bandwidth and Unreserved =
Bandwidth (we would have equivalent latitude for other attributes but =
this is a local policy decision - which at the end is the sole purpose =
of this approach)

  IB>> Disagree. Conceptually PCS1 and PSC2 are different layers and the =
latter cannot stitch the former, just like in case VC12 and VC4. You =
should nest PSC1 within PSC2 instead.

  Here are some of the questions related to LSP stitching to start a
  discussion on the usage of LSP stitching.

  >1) Are the control plane signaling procedures for LSP stitching as
  >described in this ID, (explicit request for LSP stitching on
  >LSP segment, different label allocation rules; etc) REQUIRED to =
stitch
  >packet LSPs in data plane ?

  -> yes (beside manual config operation)

  IB>> Agree

  >2) Are the control plane signaling procedures for LSP stitching as
  >described in this ID, (explicit request for LSP stitching on
  >LSP segment, different label allocation rules; etc) REQUIRED to =
stitch
  >non-packet LSPs in data plane ?

  -> yes (beside manual config operation)

  IB>> Agree

  >3) If an e2e LSP crosses a region boundary (based on different TE
  >link switching capabilities), then can I use LSP stitching -
  >a) control plane procedures for packet LSPs
  >b) data plane procedures for packet LSPs
  >c) control plane procedures for non-packet LSPs
  >d) data plane procedures for non-packet LSPs

  -> no, when crossing a region boundary, you simply use a document =
named "draft-mpls-lsp-hierarchy-08.txt" which is in the RFC Editor =
queue, but this does not prevent from creating an LSP segment on top of =
an FA-LSP (see below)

  IB>> Agree with the caviat that it should be H-LSP instead of FA-LSP =
to cover single and multi-domain scenarios

  >4) If the switching type of an e2e LSP is different from that of an =
LSP
  >segment, can I use LSP stitching -
  >a) control plane procedures for packet LSPs
  >b) data plane procedures for packet LSPs
  >c) control plane procedures for non-packet LSPs
  >d) data plane procedures for non-packet LSPs

  -> no, in this case progression of the end-to-end LSP establishment, =
implies that the LSP segment must fulfil a set of constraints carried as =
part of the incoming end-to-end LSP request, in this case one has to =
create an LSP segment (with a switching type equal to the incoming =
end-to-end LSP switching type) over that FA (i.e. referred here above to =
the LSP segment with a different Switching Type)

  IB>> Agree with the caviat that it should be H-LSP instead of FA-LSP =
to cover single and multi-domain scenarios

  Cheers,

  Igor

  >Note that although 3) and 4) appear to be the same, the reason I have
  >them as different questions is that in one case the TE link switching
  >capability is examined and in the other case the Generalized Label =
Request
  >is examined.

  -> what it appears to me is that this discussion mixes the issue of =
the operation describing the stitching operations at the domain =
boundaries from the LSP segment creation itself i.e. an LSP segment can =
indeed be an FA link inherited from the creation of an (intra-domain) =
FA-LSP -=20

------=_NextPart_000_00BB_01C58D2E.79B452C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dimitri,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>It seems to me that I mostly agree(?!) =
with what=20
you wrote in this mail. I'd still want to confirm your views&nbsp; on =
the=20
following questions:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>a) Is it possible (should we allow) to =
stitch&nbsp;=20
PSC1 e2e LSP by a LSC LSP segment ?
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>b) Is it possible (should we allow) to=20
stitch&nbsp;&nbsp;VC12 e2e LSP by a&nbsp;VC4 LSP segment ?
<DIV><FONT face=3DArial size=3D2>c) Is it possible (should we allow) to=20
stitch&nbsp;&nbsp;PSC1 e2e LSP by a&nbsp;PSC2 LSP segment ?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>My answers are NO to all three questions. You can sticth PSC1 with =
PSC1,=20
VC12 with VC12, etc. In all other cases you need, first, to setup a =
hierarchical=20
LSP (H-LSP) (whether it is FA-LSP (single domain) or =
not&nbsp;(multi-domain)) in=20
order to create a data link of the e2e LSP switching capability and only =
after=20
that you can also&nbsp;use a stitching segment on top of &nbsp;this=20
H-LSP).</DIV>
<DIV>&nbsp;</DIV>
<DIV>See also in-line.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Igor</DIV></FONT></DIV></FONT></FONT></FONT><FONT face=3DArial=20
size=3D2></FONT></DIV></DIV></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  =
href=3D"mailto:[email-masked]">Dimitri.Papadimitriou@al=
catel.be</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Arthi Ayyangar</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Igor Bryskin</A> ; <A=20
  title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, July 20, 2005 =
4:46=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: LSP stitching =
questions for=20
  discussion</DIV>
  <DIV><BR></DIV>
  <P><FONT face=3DMonospace,Courier>arthi, </FONT></P>
  <P>&nbsp;</P>
  <P><FONT face=3DMonospace,Courier>first a recap: this item on =
stitching was=20
  initiated in order to allow per "domain" control of end-to-end =
(contiguous)=20
  LSP, as part of a separate document, and not to extend its scope =
(unduly, in=20
  this case, see below) but mainly in order to have the set of all =
related=20
  protocol mechanisms within a specific document -</FONT></P>
  <P>&nbsp;</P>
  <P><FONT face=3DMonospace,Courier>from this initial working =
assumption, it is=20
  clear that the segment must have the properties of the incoming =
end-to-end LSP=20
  which are determined among other by its switching type e.g. PSC-3 or =
TDM, the=20
  first requirement of LSP stitching is contiguity of the end-to-end LSP =
at the=20
  data plane level (after stitching operation) - and this by definition =
of the=20
  initial working assumption -</FONT></P>
  <P><FONT face=3D"Courier New">IB&gt;&gt; Agree</FONT></P>
  <P><FONT face=3DMonospace,Courier>note: the only latitude which is =
left (for a=20
  given switching type e.g. PSC-2) is due to the properties of packet =
(PSC)=20
  networks that allows you stitch a segment having a larger Max =
Reservable=20
  Bandwidth and Unreserved Bandwidth (we would have equivalent latitude =
for=20
  other attributes but this is a local policy decision - which at the =
end is the=20
  sole purpose of this approach)</FONT></P>
  <P><FONT face=3D"Courier New">IB&gt;&gt; Disagree. Conceptually PCS1 =
and PSC2=20
  are different layers and the latter cannot stitch the former, just =
like in=20
  case VC12 and VC4. You should nest PSC1 within PSC2 =
instead.</FONT></P>
  <P><FONT face=3DMonospace,Courier><BR><BR>Here are some of the =
questions related=20
  to LSP stitching to start a<BR>discussion on the usage of LSP=20
  stitching.<BR><BR>&gt;1) Are the control plane signaling procedures =
for LSP=20
  stitching as<BR>&gt;described in this ID, (explicit request for LSP =
stitching=20
  on<BR>&gt;LSP segment, different label allocation rules; etc) REQUIRED =
to=20
  stitch<BR>&gt;packet LSPs in data plane ?<BR></FONT></P>
  <P><FONT face=3DMonospace,Courier>-&gt; yes (beside manual config=20
  operation)</FONT></P>
  <P><FONT face=3D"Courier New">IB&gt;&gt; Agree</FONT></P>
  <P><FONT face=3DMonospace,Courier><BR>&gt;2) Are the control plane =
signaling=20
  procedures for LSP stitching as<BR>&gt;described in this ID, (explicit =
request=20
  for LSP stitching on<BR>&gt;LSP segment, different label allocation =
rules;=20
  etc) REQUIRED to stitch<BR>&gt;non-packet LSPs in data plane =
?<BR></FONT></P>
  <P><FONT face=3DMonospace,Courier>-&gt; yes (beside manual config=20
  operation)</FONT></P>
  <P><FONT face=3D"Courier New">IB&gt;&gt; Agree</FONT></P>
  <P><FONT face=3DMonospace,Courier><BR>&gt;3) If an e2e LSP crosses a =
region=20
  boundary (based on different TE<BR>&gt;link switching capabilities), =
then can=20
  I use LSP stitching -<BR>&gt;a) control plane procedures for packet=20
  LSPs<BR>&gt;b) data plane procedures for packet LSPs<BR>&gt;c) control =
plane=20
  procedures for non-packet LSPs<BR>&gt;d) data plane procedures for =
non-packet=20
  LSPs<BR></FONT></P>
  <P><FONT face=3DMonospace,Courier>-&gt; no, when crossing a region =
boundary, you=20
  simply use a document named "draft-mpls-lsp-hierarchy-08.txt" which is =
in the=20
  RFC Editor queue, but this does not prevent from creating an LSP =
segment on=20
  top of an FA-LSP (see below)</FONT></P>
  <P><FONT face=3D"Courier New">IB&gt;&gt; Agree with the caviat that it =
should be=20
  H-LSP instead of FA-LSP to cover single and multi-domain =
scenarios</FONT></P>
  <P><FONT face=3DMonospace,Courier><BR>&gt;4) If the switching type of =
an e2e LSP=20
  is different from that of an LSP<BR>&gt;segment, can I use LSP =
stitching=20
  -<BR>&gt;a) control plane procedures for packet LSPs<BR>&gt;b) data =
plane=20
  procedures for packet LSPs<BR>&gt;c) control plane procedures for =
non-packet=20
  LSPs<BR>&gt;d) data plane procedures for non-packet =
LSPs<BR></FONT></P>
  <P><FONT face=3DMonospace,Courier>-&gt; no, in this case progression =
of the=20
  end-to-end LSP establishment, implies that the LSP segment must fulfil =
a set=20
  of constraints carried as part of the incoming end-to-end LSP request, =
in this=20
  case one has to create an LSP segment (with a switching type equal to =
the=20
  incoming end-to-end LSP switching type) over that FA (i.e. referred =
here above=20
  to the LSP segment with a different Switching Type)</FONT></P><FONT=20
  face=3DMonospace,Courier>
  <P><FONT face=3D"Courier New">IB&gt;&gt; Agree with the caviat that it =
should be=20
  H-LSP instead of FA-LSP to cover single and multi-domain =
scenarios</FONT></P>
  <P><FONT face=3DArial size=3D2>Cheers,</FONT></P>
  <P><FONT face=3DArial size=3D2>Igor</FONT></P>
  <P>&gt;Note that although 3) and 4) appear to be the same, the reason =
I=20
  have<BR>&gt;them as different questions is that in one case the TE =
link=20
  switching<BR>&gt;capability is examined and in the other case the =
Generalized=20
  Label Request<BR>&gt;is examined.<BR><BR></P></FONT>
  <P><FONT face=3DMonospace,Courier>-&gt; what it appears to me is that =
this=20
  discussion mixes the issue of the operation describing the stitching=20
  operations at the domain boundaries from the LSP segment creation =
itself i.e.=20
  an LSP segment can indeed be an FA link inherited from the creation of =
an=20
  (intra-domain) FA-LSP - </FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00BB_01C58D2E.79B452C0--

Delivery-date: Wed, 20 Jul 2005 15:40:08 +0000
Sensitivity: 
Subject: RE: Moving LSP ownership between control plane and management plane
To: [email-masked]
Cc: [email-masked]
From: "Dino Bramanti" <[email-masked]>
Date: Wed, 20 Jul 2005 17:39:41 +0200

Dimitri,

as Diego says in his post, the main use for the procedure defined in our ID
is for MP->CP handover.
This at least could be its immediate possible use and surely it is the
reason why we started thinking
about a similar mechanism within CP. But we have proposed the complete
procedure including the reverse CP->MP handover for several reasons.
The first one is related to the need of reverting back what MP-CP procedure
does in case of some kind of failure during its action. In addition, the
possibility of doing a CP->MP handover of LSP, leaving untouched
corresponding data plane state, could be useful for specific needs. An
example could be a Control Plane software upgrade to be performed on
network elements that are in service and carrying traffic over data plane.
In such a case it could be possible to perform a CP->MP handover of a
number of LSP, transfering their ownership to MP for the time required.

Furthermore, taking Stephen's suggestion about it and looking at the
proposed mechanism (i.e. handover flag usage within GRSVPTE signaling flow)
as a general way to act on CP state without affecting data plane state, the
need for a two-way procedure is required to provide it with maximum
flexibility.

Thank you
dino

>diego

>as part of the motivation section of this document it would be indeed
interesting to be much more explicit about the CP->MP >handover purpose(s)
before progressing on this part of the mechanism

>- d.

Delivery-date: Wed, 20 Jul 2005 15:10:30 +0000
Content-Class: urn:content-classes:message
Subject: RE: End-to-end L2-LSP
Date: Wed, 20 Jul 2005 16:09:56 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Jaihyung,

I agree that extending signalling down to the end-user is one possible =
solution to address charging/billing issues, another possible solution =
would be to use session based billing. I also agree that using L2-LSPs =
could be a viable solution for providing traffic separation and =
bandwidth guarantees in a service providers network, another possible =
solution would be to extended MPLS into the access network.

However, if you want to extend L2-LSPs (not just signalling) down to the =
end user, then there are a number of complicated technical and =
commercial issues that must be overcome. Please see below for some of =
the key issues:

1. If you want to eliminate the possibility of congestion in the =
enterprise/home network using L2-LSPs for the reasons you give below, =
then on every node in the network you will need:

- A CPU: for control plane protocol processing
- Routing: At least static, an IGP for large networks and OSPF-TE if TE =
is required
- Signalling: RSVP-TE
- Policing: Per connection policing, e.g. per VLAN

I do not know how much it would cost to upgrade the $20 five port 10/100 =
switch sitting on my desk to support all this, but I do not believe this =
would be a trivial amount, particularly at the volumes demanded by =
enterprises. In addition, a hierarchical architecture would be required =
for the solution to scale and therefore aggregation switches within the =
enterprise network would also need to support hierarchical CAC and =
policing.

2. Unless you want to reinvent LANE, then you will need to continue to =
support CL Ethernet broadcasts and multicasts on GMPLS enabled switches. =
To protect the L2-LSP traffic from CL broadcast traffic you could rate =
limit it to say 1% of the bandwidth available. However, how would you =
capacity plan for and rate limit (dynamic, receiver driven) multicast =
traffic for which usage patterns are difficult to predict? In my opinion =
you will need to use over provisioning along with CoS, which would raise =
the question, why is over provisioning and CoS OK for multicast traffic =
(which could be critical, e.g. trading floor information), but not OK =
for unicast traffic?

3. Routers are relatively stable systems that are switched on =
permanently and therefore RSVP-TE sessions are stable and only go down =
when there is a failure. End user systems however such as PCs, set top =
boxes, games consoles, etc. are not always switched on and are not as =
stable. What will the effect on the network be when large number of =
RSVP-TE sessions are going up/down, e.g. as a result of game console =
resets or PC crashes/freezes? These effects will ripple through the =
enterprise/home network into the operators network, and therefore =
mechanisms must be put in place to protect against them.

4. When an IP device wants to forward a packet it uses ARP to discover =
the MAC address of the IP next hop (unless its already in the MAC table) =
and adds the Ethernet header before forwarding the packet on. Now, if =
you want to extend connections down to the end user device, then the =
device will need to map IP traffic to different L2-LSPs. A simple 1-to-1 =
mapping between an IP next hop address and a MAC address will not be =
sufficient as there may be multiple connections (e.g. using different =
VLAN IDs) associated with an IP next hop. So, policies will need to be =
configured on end user devices to map IP traffic (e.g. based on src/dest =
IP address, port numbers, etc.) to a specific L2-LSP (e.g. based on =
src/dest MAC address and/or VLAN ID). =20

5. End user devices such as PCs and VoIP phones are likely to only need =
to support a relatively low number of L2-LSPs. However, devices such as =
content servers and call servers/gateways will need to support =
hundreds/thousands of L2-LSPs. Connection setup and state maintenance =
for large numbers of L2-LSPs will consume a significant amount of =
processing resources, as will policies to map IP traffic to the =
different L2-LSPs. Therefore, I would expect that the system software =
(and possibly hardware) will need to be designed from the ground up to =
be able to support large numbers of L2-LSPs.

6. Enterprise networks are built using not just switches but routers as =
well. Firstly, for L2-LSPs to be set up between switches and routers, =
they must belong to the same address space to communicate with each =
other. However, this address space must be separate from the IPv4 =
forwarding address space. To use an example of why this is true, routers =
connected via Ethernet segments are considered to be directly connected, =
however, if the IPv4 and L2-LSP address spaces were the same, then IP =
routers separated by GMPLS switches would be multiple hops away from =
each other. In addition to address space separation, routing protocol =
instances must also be separated. This need for this separation is =
obvious when considering using a link state routing protocol which =
relies on a topological view of the network, i.e. the IPv4 and L2-LSP =
topologies are different.=20

Secondly, routers break up Ethernet segments and must therefore must =
always be the headend or tailend for a L2-LSPs, i.e. they cannot be =
midpoints. This means that from a control plane perspective, on =
receiving a L2-LSP path message a router must terminate the LSP and send =
back a resv message whether it is the intended destination/sink or not. =
It must then originate a path message for a new L2-LSP and send it onto =
the next hop GMPLS switch. This is not how RSVP-TE works today and =
therefore will require modifications. In addition, traffic will be =
blackholed if transmitted by the source before all the separate L2-LSPs =
have been setup end-to-end to the sink/destination. This means that some =
kind of end-to-end signalling message will need to be sent by the =
sink/destination once the final L2-LSP has been established to inform =
the source that the end-to-end connectivity has been provided. This =
functionality is not supported by RSVP-TE today and will therefore =
require protocol modifications.

Thirdly, routers forward packets based on information in the IP header. =
So, when a router receives a packet via a L2-LSP it will strip of the L2 =
header and perform an IP lookup. Now, for the packet to be forwarded =
using the correct L2-LSP the router must have a policy that tells it =
which L2-LSP to use as there may be multiple L2-LSPs to the same =
destination, e.g. for different voice calls or video downloads. However, =
before a policy can even be configured, the router needs to know what =
traffic (e.g. based on src/dest address, port number, DSCP, etc.) to map =
to which L2-LSP, and this information needs to come from the traffic =
source using signalling, i.e. RSVP-TE. I do not believe this is =
supported today and will therefore require modifications.

Regards,
Richard

> From: CHO, JAI HYUNG [mailto:[email-masked]]
> Sent: 14 July 2005 04:24
> To: Spencer,R,Richard,XDE73 R; [email-masked]
> Subject: RE: End-to-end L2-LSP
>=20
> Dear Richard,
>=20
> See in-line please,
>=20
> >Thank you for taking the time to respond to my questions. I=20
> anticipated=20
> >that your response would include "over-provisioning is the=20
> best answer"=20
> >to decrease the chance of congestion on non-GMPLS switches.=20
> >This is what is done in the LAN environment today in=20
> conjunction with CoS,=20
> >and this is why I believe there will be two opposing views on how=20
> >far L2-LSP connections should be extended down to the user. One view=20
> >is that over provisioning and CoS work fine in the=20
> enterprise network today,=20
> >and therefore the L2-LSP should only be extended down to the point=20
> >at which the enterprise network connects to the SP network,=20
> >e.g. Ethernet DSLAM. I think the other view will be that=20
> over provisioning=20
> >and CoS in the enterprise network don't work and therefore L2-LSPs=20
> >should be provided end-to-end using only GMPLS capable switches.=20
> >I wouldn't have thought there would be much call for mixed=20
> >GMPLS/non-GMPLS enterprise networks (except for during migration)=20
> >due to the opposing views, e.g. if over provisioning is good=20
> enough for=20
> >one switch, why isn't it good enough for the other?
>=20
> Over-provisioned network is non-guaranteed network. It can't prevent=20
> occasional congestion at any rate. Further, network condition=20
> in private=20
> network is very diverse. You can't predict minimum service level=20
> inside every private network.=20
>=20
> Suppose that an ISP want to provide high-quality, video-phone service=20
> for enterprise users. Nothing can be guaranteed inside the=20
> over-provisioned=20
> customer network. If the service level is not satisfactory,=20
> customers will complain=20
> to service provider even if the main cause is in his network=20
> or destination network.=20
> We need some structure that coordinate service quality in=20
> both private sector,=20
> as well as in public sector consistently.=20
> An end-to-end signal is an effective means to communicate between=20
> user terminal, private switches and provider switches, and=20
> concert service=20
> quality at each different operations network. This is a goal=20
> that RSVP (RFC2205)=20
> pursued, however ineffective in local network because=20
> Ethernet industry=20
> didn't support RSVP over Ethernet (RFC2814, 2815, 2816).=20
> Now we have another opportunity to realize the goal using L2-LSP.=20
> Therefore, I believe end-to-end LSP is necessary even in=20
> enterprise network=20
> for the purpose of providing guaranteed commercial service.
>=20
> >I think where most people will agree is that using connections=20
> >in the SPs access network does make sense in order to=20
> provide efficient=20
> >link utilisation and per connection policing to ensure one customers=20
> >traffic can not affect another's. Regarding the ability to=20
> set up new=20
> >connections based on a request from the user (rather than=20
> constraining=20
> >RSVP signalling to inside the SP network), I think this will come=20
> >down to enterprise customer demand for improved service performance.=20
> >If a customer wasn't getting the performance they needed from their=20
> >SP and was offered a new service that allowed them to setup=20
> new L2-LSP=20
> >connections on demand that would offer better performance=20
> (e.g. for voice=20
> >calls or video conferences), then upgrading the user devices=20
> to support=20
> >the new service could well be an attractive proposition. If=20
> on the other=20
>=20
> Yes, this will be one of prospective service newly enabled=20
> using L2-LSP.
>=20
> >hand a customer buys a best effort service and considers the=20
> performance=20
> >to be 'good enough', then there would be no reason to go to=20
> the expense=20
> >of upgrading the user devices to support the set up of L2-LSPs.
>=20
> Ever increasing besteffort bandwidth will eventually not satisfy=20
> both providers and customers for many reasons. Service providers=20
> will have difficulty in collecting expenses enough to invest=20
> on increased=20
> bandwidth. This will in turn gradually downgrade overall=20
> communication quality,=20
> and applications requiring real-time service will never=20
> satisfy customers.=20
> We already see such symptom in some low-price service providers.=20
> I believe new service structure that can provide difference=20
> of service=20
> quality will offer benefit to customers, providers as well as=20
> vendors in the end.
>=20
> I also look forward to see you at Paris and continue helpful=20
> discussion.
>=20
> Sincerely
>=20
> Jaihyung
>=20
>=20
> =20
>=20
> Dr. Jaihyung Cho
> ETRI, Korea
> phone :       042) 860-5514
> oversea: +82-42-860-5514
> fax:         +82-42-861-5550=20
>=20
>=20
>=20
>=20
> -----?? ???-----=20
> ?? ??: "[email-masked]" <[email-masked]>=20
> ?? ??: 2005-07-14 ?? 1:10:30=20
> ?? ??: "[email-masked]" <[email-masked]>,=20
> "[email-masked]" <[email-masked]>=20
> ??:=20
> ??: RE: End-to-end L2-LSP=20
>=20
>=20
>=20
> Jaihyung,=20
>=20
> Thank you for taking the time to respond to my questions. I=20
> anticipated that your response would include=20
> "over-provisioning is the best answer" to decrease the chance=20
> of congestion on non-GMPLS switches. This is what is done in=20
> the LAN environment today in conjunction with CoS, and this=20
> is why I believe there will be two opposing views on how far=20
> L2-LSP connections should be extended down to the user. One=20
> view is that over provisioning and CoS work fine in the=20
> enterprise network today, and therefore the L2-LSP should=20
> only be extended down to the point at which the enterprise=20
> network connects to the SP network, e.g. Ethernet DSLAM. I=20
> think the other view will be that over provisioning and CoS=20
> in the enterprise network don't work and therefore L2-LSPs=20
> should be provided end-to-end using only GMPLS capable=20
> switches. I wouldn't have thought there would be much call=20
> for mixed GMPLS/non-GMPLS enterprise networks (except for=20
> during migration) due to the opposing views, e.g. if over=20
> provisioning is good enough for one switch, why isn't it good=20
> enough for the other?=20
>=20
> I think where most people will agree is that using=20
> connections in the SPs access network does make sense in=20
> order to provide efficient link utilisation and per=20
> connection policing to ensure one customers traffic can not=20
> affect another's. Regarding the ability to set up new=20
> connections based on a request from the user (rather than=20
> constraining RSVP signalling to inside the SP network), I=20
> think this will come down to enterprise customer demand for=20
> improved service performance. If a customer wasn't getting=20
> the performance they needed from their SP and was offered a=20
> new service that allowed them to setup new L2-LSP connections=20
> on demand that would offer better performance (e.g. for voice=20
> calls or video conferences), then upgrading the user devices=20
> to support the new service could well be an attractive=20
> proposition. If on the other hand a customer buys a best=20
> effort service and considers the performance to be 'good=20
> enough', then there would be no reason to go to the expense=20
> of upgrading the user devices to support the set up of L2-LSPs.=20
>=20
> I look forward to the discussions in Paris.=20
>=20
> Regards,=20
> Richard=20
>=20
> > -----Original Message-----=20
> > From: CHO, JAI HYUNG [mailto:[email-masked]]=20
> > Sent: 13 July 2005 15:14=20
> > To: Spencer,R,Richard,XDE73 R; [email-masked]=20
> > Subject: RE: End-to-end L2-LSP=20
> >=20
> >=20
> > =20
> > =20
> > Dear Richard Spencer=20
> > =20
> > see in-line=20
> > =20
> > >Jaihyung,=20
> > >=20
> > >Perhaps I'm becoming too much of a pessimist;-)=20
> > =20
> > oh, not at all,=20
> > you are reasonable enough to dig up unclear knowledge=20
> > please go ahead until you finally get satisfactory answer.=20
> > =20
> >=20
> > >Ignoring the commercial aspects, please can you help clarify=20
> > a few technical=20
> > >questions I have in order to help me gain a better=20
> > understanding of the proposal?=20
> > >=20
> > >1. You say that one of the key reasons for using GMPLS in=20
> > the enterprise=20
> > >network is to provide end-to-end QoS control. However, you=20
> > also say that not=20
> > >all the switches will need to support GMPLS, only those at=20
> > bottle necks.=20
> > >Please can you expand on this to explain how you can have=20
> end-to-end=20
> > >QoS control when the L2-LSP is not end-to-end?=20
> > =20
> >=20
> > The contextual meaning of 'End-to-end LSP' is that GMPLS label is=20
> > assigned from source terminal and removed at destination terminal,=20
> > because RSVP-TE message is exchanged from host to host.=20
> > It may not perfectly guarantee QoS when the GMPLS deployment=20
> > is not complete, however it will at least be good enough=20
> > for end-user applications to tell those GMPLS implemented=20
> L2 switches=20
> > what frame must be given priority service when congestion occur.=20
> > =20
> >=20
> > >As being discussed=20
> > >on the PWE3 mailing list, the performance a service receives=20
> > is only as=20
> > >good as the worst performing server layer. Therefore, if=20
> there is a=20
> > >standard 802.1 workgroup switch between the user and the=20
> > L2-LSP that is=20
> > >experiencing congestion (e.g. due to a large amount of=20
> > peer-to-peer traffic),=20
> > >then the QoS that the user receives will only be as good as=20
> > that provided=20
> > >by the congested workgroup switch.=20
> > =20
> >=20
> > of course, ETH-GMPLS does not prevent congestion inevitably=20
> occurring=20
> > in those non-GMPLS deployed part.=20
> > =20
> >=20
> > >The only way I can see a network using a mixture of GMPLS=20
> > and non-GMPLS=20
> > >switches guaranteeing end-to-end QoS would be to design the=20
> > network in=20
> > >such a way that the non-GMPLS switches could never become=20
> congested.=20
> > =20
> >=20
> > Yes, that will be the way wise network designer improve=20
> their network.=20
> > =20
> >=20
> > >To do this would require that RSVP requests be used for ALL=20
> > traffic flows=20
> > >to ensure that there was enough bandwidth available, along=20
> > with strict=20
> > >per L2-LSP policing on the user devices (e.g. PC).=20
> > >However, the obvious flaw in this approach is that someone could=20
> > >just come along and connect=20
> > >an end device to a non-GMPLS switch and start transmitting traffic=20
> > >(without performing CAC/policing) causing the switch to=20
> > become congested.=20
> > >Therefore, please can you explain how end-to-end QoS can be=20
> > guaranteed=20
> > >in a mixed non-GMPLS and GMPLS switching environment?=20
> > =20
> >=20
> > Of course traffic came from non controlled ingress can not be=20
> > prevented=20
> > in non-GMPLS node. There's no magic. Only the=20
> > over-provisioning is the=20
> > best answer. However, once the aggregated traffic pass 'ANY' one of=20
> > GMPLS enabled node, those uncontrolled traffic will suffer=20
> > queuing discipline.=20
> > =20
> >=20
> > >2. Section 5.1 currently states "When the customer initiates=20
> > data transmission,=20
> > >the access switch maps the user flow into the L2 LSP.=20
> > Mapping procedure is=20
> > >subject to implementation choices, and is out of the scope of this=20
> > >document." In order to be able to map any traffic, first of=20
> > all the switch needs=20
> > >to know what type of traffic (e.g. based on source/dest MAC,=20
> > VLAN ID, 802.1p=20
> > >bits, etc) should be mapped to the L2-LSP. In Figure 1, if=20
> > an L2-LSP is set up=20
> > >from the DSLAM to the edge router based on a request from=20
> > the user (e.g. via=20
> > >a PC or VoIP phone), then won't the user also need to signal=20
> > what type of=20
> > >traffic should to be mapped to the L2-LSP?=20
> > =20
> >=20
> > Thank you for pointing out important thing.=20
> > That's the most unfortunate part I reluctantly agreed because the=20
> > work condition in the framework DT was not to span L2-LSP=20
> > beyond provider network.=20
> > As you noticed, mapping user traffic at provider access is awkward.=20
> > A smooth method will be for user terminal aware of the L2 label=20
> > to use by receiving RSVP-TE message.=20
> > However, there was strong argument that RSVP-TE must not=20
> > go beyond provider network because the DT is not chartered=20
> > to work in customer network.=20
> > That's why I requested amendment of CCAMP charter=20
> > to include user terminal explicitly in CCAMP work scope, so that=20
> > avoid such silly argument in future.=20
> > =20
> >=20
> > >3. In section 5.1, the text states that the aggregation=20
> > switch between the=20
> > >DSLAM and edge router may be a 802.1 switch, i.e. it doesn't=20
> > have to support=20
> > >GMPLS. To set up a connection, first of all there needs to=20
> > be a data plane=20
> > >capable of carrying control plane traffic between GMPLS=20
> > peers. Secondly,=20
> > >the GMPLS peers need reachability information in order to=20
> > forward control=20
> > >messages onto the next peer (i.e. a static or IGP route). If=20
> > the GMPLS peers=20
> > >(e.g. the DSLAM and edge router in Figure 1) are not=20
> > directly connected,=20
> > >then the GMPLS control packets will need to be forwarded by=20
> > the 802.1 switch.=20
> > >Would the idea be to have say a "control traffic VLAN"=20
> > configured between the=20
> > >DSLAM and edge router via the transit 802.1 switch so that=20
> > control packets=20
> > >could be forwarded transparently by the 802.1 switch?=20
> > =20
> >=20
> > Although it doesn't preclude use of VLAN, I think such=20
> > special configuration=20
> > for RSVP-TE control message is not necessary in legacy switches.=20
> > Legacy switches only need to pass RSVP-TE messages as they=20
> > pass normal data frames. Only the GMPLS implemented switches=20
> > need to distinguish frames containing RSVP-TE messages and=20
> > snoop them.=20
> > Detail of implementation is, of course, for future discussion.=20
> > =20
> >=20
> > >4. If we assume that control messages can be transparently=20
> forwarded=20
> > >by the intermediate 802.1 aggregation switch then how are=20
> > user frames=20
> > >forwarded in the data plane by the 802.1 switch?=20
> > =20
> >=20
> > Legacy switches do not distinguish control/data frames.=20
> > =20
> >=20
> > >If the DSLAM sets up a L2-LSP=20
> > >to the edge router using say VLAN ID 99, how does the switch=20
> > know that any=20
> > >packets coming in with a VLAN ID of 99 should be forwarded=20
> > out of the port=20
> > >connecting to the edge router?=20
> > =20
> >=20
> > oh, you misunderstood the L2-LSP.=20
> > The question you are asking depends on how L2 label is encoded.=20
> > there was hot debate in the DT about the issue how L2 label=20
> > is encoded.=20
> > My proposal is to use part of MAC address for label and the=20
> > other people=20
> > argued to use VLAN ID for label. The debate was not concluded=20
> > because the goal of the L2SC framework document is not to select=20
> > implementation method but to draw necessary work scope.=20
> > I believe this issue will be dealt in depth after Paris meeting.=20
> > So, please reserve your question until then and ask to those=20
> > VLAN proponents.=20
> > =20
> >=20
> > >5. During connection setup, I take it that the GMPLS peers=20
> > assume that=20
> > >resources are available within the intermediate 802.1 switch=20
> > to support=20
> > >the connection (as its transparent). However, as there is no=20
> > >CAC/policing being performed by the 802.1 switch=20
> > >(the L2-LSPs are transparent), and due to the any-to-any and=20
> > broadcast=20
> > >based nature of Ethernet (i.e. its CL properties), then=20
> how can this=20
> > >assumption be made? This comes back to my original question, how=20
> > >can end-to-end QoS be guaranteed in an environment where there is=20
> > >a mixture of 802.1 and GMPLS enabled switches?=20
> > =20
> >=20
> > yes, you came back to the question I answered in above ;-)=20
> > so, please see above.=20
> > GMPLS enabled nodes must be positioned at points congestion=20
> > is likely to be expected.=20
> > =20
> > Thanks=20
> > =20
> > Jaihyung=20
> > =20
> >=20
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> >=20
> > =20
> >=20
> > -----?? ???-----=20
> > ?? ??: "[email-masked]" <[email-masked]>=20
> > ?? ??: 2005-07-13 ?? 8:53:13=20
> > ?? ??: "[email-masked]" <[email-masked]>,=20
> > "[email-masked]" <[email-masked]>=20
> > ??:=20
> > ??: RE: End-to-end L2-LSP=20
> >=20
> >=20
> >=20
> >=20
> > Jaihyung,=20
> >=20
> > Perhaps I'm becoming too much of a pessimist;-) Ignoring the=20
> > commercial aspects, please can you help clarify a few=20
> > technical questions I have in order to help me gain a better=20
> > understanding of the proposal?=20
> >=20
> > 1. You say that one of the key reasons for using GMPLS in the=20
> > enterprise network is to provide end-to-end QoS control.=20
> > However, you also say that not all the switches will need to=20
> > support GMPLS, only those at bottle necks. Please can you=20
> > expand on this to explain how you can have end-to-end QoS=20
> > control when the L2-LSP is not end-to-end? As being discussed=20
> > on the PWE3 mailing list, the performance a service receives=20
> > is only as good as the worst performing server layer.=20
> > Therefore, if there is a standard 802.1 workgroup switch=20
> > between the user and the L2-LSP that is experiencing=20
> > congestion (e.g. due to a large amount of peer-to-peer=20
> > traffic), then the QoS that the user receives will only be as=20
> > good as that provided by the congested workgroup switch.=20
> >=20
> > The only way I can see a network using a mixture of GMPLS and=20
> > non-GMPLS switches guaranteeing end-to-end QoS would be to=20
> > design the network in such a way that the non-GMPLS switches=20
> > could never become congested. To do this would require that=20
> > RSVP requests be used for ALL traffic flows to ensure that=20
> > there was enough bandwidth available, along with strict per=20
> > L2-LSP policing on the user devices (e.g. PC). However, the=20
> > obvious flaw in this approach is that someone could just come=20
> > along and connect an end device to a non-GMPLS switch and=20
> > start transmitting traffic (without performing CAC/policing)=20
> > causing the switch to become congested. Therefore, please can=20
> > you explain how end-to-end QoS can be guaranteed in a mixed=20
> > non-GMPLS and GMPLS switching environment?=20
> >=20
> > 2. Section 5.1 currently states "When the customer initiates=20
> > data transmission, the access switch maps the user flow into=20
> > the L2 LSP. Mapping procedure is subject to implementation=20
> > choices, and is out of the scope of this document." In order=20
> > to be able to map any traffic, first of all the switch needs=20
> > to know what type of traffic (e.g. based on source/dest MAC,=20
> > VLAN ID, 802.1p bits, etc) should be mapped to the L2-LSP. In=20
> > Figure 1, if an L2-LSP is set up from the DSLAM to the edge=20
> > router based on a request from the user (e.g. via a PC or=20
> > VoIP phone), then won't the user also need to signal what=20
> > type of traffic should to be mapped to the L2-LSP?=20
> >=20
> > 3. In section 5.1, the text states that the aggregation=20
> > switch between the DSLAM and edge router may be a 802.1=20
> > switch, i.e. it doesn't have to support GMPLS. To set up a=20
> > connection, first of all there needs to be a data plane=20
> > capable of carrying control plane traffic between GMPLS=20
> > peers. Secondly, the GMPLS peers need reachability=20
> > information in order to forward control messages onto the=20
> > next peer (i.e. a static or IGP route). If the GMPLS peers=20
> > (e.g. the DSLAM and edge router in Figure 1) are not directly=20
> > connected, then the GMPLS control packets will need to be=20
> > forwarded by the 802.1 switch. Would the idea be to have say=20
> > a "control traffic VLAN" configured between the DSLAM and=20
> > edge router via the transit 802.1 switch so that control=20
> > packets could be forwarded transparently by the 802.1 switch?=20
> >=20
> > 4. If we assume that control messages can be transparently=20
> > forwarded by the intermediate 802.1 aggregation switch then=20
> > how are user frames forwarded in the data plane by the 802.1=20
> > switch? If the DSLAM sets up a L2-LSP to the edge router=20
> > using say VLAN ID 99, how does the switch know that any=20
> > packets coming in with a VLAN ID of 99 should be forwarded=20
> > out of the port connecting to the edge router?=20
> >=20
> > 5. During connection setup, I take it that the GMPLS peers=20
> > assume that resources are available within the intermediate=20
> > 802.1 switch to support the connection (as its transparent).=20
> > However, as there is no CAC/policing being performed by the=20
> > 802.1 switch (the L2-LSPs are transparent), and due to the=20
> > any-to-any and broadcast based nature of Ethernet (i.e. its=20
> > CL properties), then how can this assumption be made? This=20
> > comes back to my original question, how can end-to-end QoS be=20
> > guaranteed in an environment where there is a mixture of=20
> > 802.1 and GMPLS enabled switches?=20
> >=20
> > Thanks,=20
> > Richard=20
> >=20
> > > -----Original Message-----=20
> > > From: CHO, JAI HYUNG [mailto:[email-masked]]=20
> > > Sent: 12 July 2005 09:21=20
> > > To: Spencer,R,Richard,XDE73 R; [email-masked]=20
> > > Subject: RE: End-to-end L2-LSP=20
> > >=20
> > >=20
> > >=20
> > >=20
> > > Dear Richard,=20
> > >=20
> > > Yes, I believe it is not only commercially profitable but it=20
> > > may also grow total=20
> > > revenue of service operators by introducing new services.=20
> > >=20
> > > For example, think the example of IP phone you referred.=20
> > > How do you think you can provide reliable VoIP service and=20
> > > safely authenticate phone users and charge fees as counted by=20
> > > packet usage=20
> > > using simple Ethernet based xDSL network ?=20
> > >=20
> > > There's hardly new service that providers may offer using=20
> > > Ethernet based=20
> > > architecture, and collect sufficient profit to investment.=20
> > >=20
> > > A sophisticated ATM switch might do the work if it is not=20
> > expensive.=20
> > > However, my intension is modifiying existing design of=20
> > > Ethernet hardware=20
> > > with a little bit additional cost,  and provide the level of=20
> > > service that=20
> > > ATM switches might offer.=20
> > >=20
> > > We have initial design of the Ethernet-MPLS hardware. I=20
> don't think=20
> > > GMPLS enabled Ethernet switch will be so complex. The=20
> market price=20
> > > of GMPLS enabled switch will not be so expensive than normal=20
> > > Ethernet switches.=20
> > >=20
> > > Further, it only requires upgrade of switches in some=20
> > > bottleneck points of network.=20
> > > Read the framework documents of L2SC. It doesn't require=20
> > > entire replacement=20
> > > of switches to introduce new service.=20
> > >=20
> > > Every year, ISPs purchase new access switches and replaces=20
> > > old machines.=20
> > > With a bit additional cost, ISPs may use the GMPLS enabled=20
> > switch for=20
> > > normal Ethernet switching in initial deployment.=20
> > >=20
> > > When the GMPLS function is enabled in some upgraded part of=20
> > network,=20
> > > ISPs may provide high quality, reliable VoIP service to=20
> > xDSL customers=20
> > > using RSVP-TE enabled VoIP phone.=20
> > > The high quality video-phone service enabled by GMPLS will be=20
> > > competable to legacy voice only phone service.=20
> > >=20
> > >=20
> > > There are lots of things I can argue about commercial aspects=20
> > > of this technique.=20
> > > However I don't think it is not appropriate to discuss this=20
> > > issue in this mailing list.=20
> > > All I can say is,=20
> > > yes, I believe that it may be commercially viable.=20
> > >=20
> > >=20
> > > Thanks=20
> > >=20
> > > Jaihyung=20
> > >=20
> > > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> > >=20
> > > Do you really think the benefits of extended GMPLS down to=20
> > > the end user could ever justify the costs involved in=20
> > > upgrading LAN switches and things like IP phones (simple low=20
> > > cost commodity items) to support GMPLS signalling/routing?=20
> > >=20
> > > Your proposal may be technically possible (though it would=20
> > > require new hardware and significant software upgrades), but=20
> > > commercially I would consider this to be a non-starter.=20
> > >=20
> > > Regards,=20
> > > Richard=20
> > >=20
> > > > -----Original Message-----=20
> > > > From: [email-masked]=20
> > [mailto:[email-masked]]On=20
> > > > Behalf Of CHO, JAI HYUNG=20
> > > > Sent: 12 July 2005 01:10=20
> > > > To: [email-masked]=20
> > > > Subject: End-to-end L2-LSP=20
> > > >=20
> > > >=20
> > > > =20
> > > > Dear all,=20
> > > >=20
> > > > Greetings.=20
> > > >=20
> > > > I am a co-editor of the Ethernet-GMPLS framework document.=20
> > > > (draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt)=20
> > > >=20
> > > > I am writing this to explain the motivation behind the=20
> > > > proposal of scenario-1, and to raise the issue of=20
> > > > end-to-end LSP to be included in CCAMP charter.=20
> > > >=20
> > > > An important goal intended in scenario-1 is=20
> > > > QoS control over end-to-end packet delivery using LSP.=20
> > > > In other words, the purpose of scenario-1 is extending coverage=20
> > > > of GMPLS control including customer network and=20
> end-user device,=20
> > > > such as PC, VoIP phone, IP-TV, or even future 4G mobile phone.=20
> > > > End-user applications will have a means to request resources=20
> > > > to network using GMPLS signal.=20
> > > >=20
> > > > Unfortunately, this view is not included in the=20
> > > > framework because there was strong opinion that=20
> > > > L2-LSP must not span beyond provider network because=20
> > > > CCAMP is not chartered to work on customer=20
> > > > network. I am wondering if this is right argument.=20
> > > > Perhaps the charter can be amended to include this work.=20
> > > >=20
> > > > I believe there is little technical reason to preclude=20
> > > > LSP being used in customer network. It is a reasonable=20
> > > > assumption that private company may also use GMPLS=20
> > > > implemented Ethernet switch, once the L2SC work is successful.=20
> > > > Currently, CCAMP is the only place discussing the matter of=20
> > > > Ethernet and LSP. There is no other WG dealing similar issue.=20
> > > > If CCAMP wants to work on Ethernet,=20
> > > > I think the coverage of common GMPLS control must be=20
> > > > extended to include all area where Ethernet is deployed.=20
> > > > Currently, Ethernet is dominantly deployed in first-mile=20
> > > > network where access network as well as customer network=20
> > > > and user hosts are usually included. Therefore, user host must=20
> > > > be considered as initiation and termination point of L2-LSP.=20
> > > >=20
> > > > Another important reason to include user host in CCAMP=20
> > > > work scope is to achieve consistent end-to-end control of QoS.=20
> > > > End-to-end QoS has long been desired goal since RSVP was=20
> > > > first designed. This goal can be best achieved using=20
> > > > end-to-end GMPLS signal and L2-LSP.=20
> > > > Currently, RSVP (RFC2205) is available in many user hosts.=20
> > > > There is only a little difference between RSVP and RSVP-TE.=20
> > > > If the RSVP-TE signal of provider network can reach user host=20
> > > > across Ethernet based private network, an LSP can be=20
> established=20
> > > > from application to application via the provider backbone.=20
> > > > Service providers will be able to control application flows=20
> > > > in L2-LSP level as well as in aggregated LSP pipe of similar=20
> > > > application type. A variety of new services will be=20
> enabled using=20
> > > > the enhanced capability of distinguishing and controlling each=20
> > > > individual application flow.=20
> > > >=20
> > > > I personally believe that end-to-end L2-LSP may offer=20
> > > > innovative solutions for servicing IP-TV as well as fast=20
> > mobility.=20
> > > > There have been some experimental approaches combining=20
> > > > MPLS and IP mobility. However such potential of the new=20
> > > > application can only be explored when end-user host is=20
> > > > included in the scope of CCAMP work area.=20
> > > >=20
> > > > Therefore, I hereby sincerely request people's attention=20
> > > > and support on this perspective of end-to-end LSP.=20
> > > > If there is enough number of people agree on this view,=20
> > > > the WG can request the necessary update of the charter.=20
> > > >=20
> > > > Thank you.=20
> > > > =20
> > > > Jaihyung Cho=20
> > > > =20
> > > > =20
> > > > =20
> > > > ETRI, Korea=20
> > > > phone :       042) 860-5514=20
> > > > oversea: +82-42-860-5514=20
> > > > fax:         +82-42-861-5550=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20

Delivery-date: Wed, 20 Jul 2005 14:50:19 +0000
Sensitivity: 
Subject: RE: Moving LSP ownership between control plane and management plane
To: [email-masked]
Cc: "<ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 16:48:14 +0200

In line

Regards

Diego

"Stephen Shew" <[email-masked]> on 20/07/2005 14.25.18

To:    "Diego Caviglia" <[email-masked]>
cc:    <[email-masked]>

Subject:    RE:  Moving LSP ownership between control plane and management
       plane

[CUT]

I have no issue with the motivation.  I just think there are more
scenarios for creating control plane state for an existing cross
connection.
[dc] Yes I agree, do you have any suggestion on other scenarios?

> If you do this then the bit should be renamed something like
> "cross-connection exists" and if set, then the signaling
> protocol does not tell the cross connection to set/release
> it. [dc] That is how it works apart for the name of the flag.

I realize that. What I'm suggesting is that the name reflect an action
rather than one of several possible purposes.
[dc] No problem with this, actually the original name of the flag was Fake
flag indicating that creation and deletion are not for real.
If there are no objection on this we can change the flag name.

[CUT]

The suggestion was that there are other scenarios in which establishment
of new LSP state for an existing cross connection is useful.  In the
MP->CP case, the MP initially holds state for the connection and before
the action is completed, both MP and CP hold state.  In the two LSP
example above, two entities in the CP hold state about the same
connection.  I see these two cases as similar in that the general case
is about multiple entities holding state for the same resource.
[dc] Yes agreed

> Stephen
> > Behalf Of Diego Caviglia
> > Sent: Wednesday, July 20, 2005 05:44
> > To: [email-masked]
> > Cc: ""Dimitri.Papadimitriou" <Dimitri.Papadimitriou";
> "ccamp" <ccamp;
> > "gnewsome" <gnewsome; "adrian" <adrian
> > Subject: RE: Moving LSP ownership between control plane and
> management
> > plane
> >
> >
> >
> > Sorry for this but may be not all have read the ID, I hope
> that having
> > the text help the discussion.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> >
> >    Network Working Group
> >    Internet Draft
> > Diego Caviglia
> >    Document: draft-caviglia-mp2cpcp2mp-02.txt             Marconi
> >    Proposed Status: Updates RFC 3473
> > Dino Bramanti
> >
> >   Marconi
> >    Expires: December 2005
> > Nicola Ciulli
>
> <snip>
>
>
>
>
>
>
>
>

Delivery-date: Wed, 20 Jul 2005 14:50:11 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt 
Date: Wed, 20 Jul 2005 10:50:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Evaluation of existing Routing Protocols 
                          against ASON Routing Requirements
	Author(s)	: D. Papadimitriou, et al.
	Filename	: draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt
	Pages		: 0
	Date		: 2005-7-20
	
The Generalized MPLS (GMPLS) suite of protocols has been defined to 
   control different switching technologies as well as different 
   applications. These include support for requesting TDM connections 
   including SONET/SDH and Optical Transport Networks (OTNs). 

   This document provides an evaluation of the IETF Routing Protocols 
   against the routing requirements for an Automatically Switched 
   Optical Network (ASON) as defined by ITU-T.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 20 Jul 2005 12:26:45 +0000
Content-class: urn:content-classes:message
Subject: RE:  Moving LSP ownership between control plane and management plane
Date: Wed, 20 Jul 2005 08:25:18 -0400
From: "Stephen Shew" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>
Cc: <[email-masked]>

See below.

> From: Diego Caviglia [mailto:[email-masked]]=20
> Sent: Wednesday, July 20, 2005 07:33
> To: Shew, Stephen [CAR:QT30:EXCH]
> Cc: [email-masked]
> Subject: Re:
>=20
>=20
>=20
> Hi Stephen,
>             my answers in line.
>=20
> Regards
>=20
> Diego
>=20
>=20
>=20
> "Stephen Shew" <[email-masked]>@ops.ietf.org on 20/07/2005 12.22.49
>=20
> Sent by:    [email-masked]
>=20
>=20
> To:    "\"ccamp\" <ccamp"
> cc:
>=20
> Subject:
>=20
>=20
> Diego, my suggestion for this draft is that it separate the=20
> mechanism (not setting the cross connects specified in an=20
> ERO), from the reason for doing so.  This is because the=20
> mechanism could be used for more than just CP<->MP handoff.=20
> [dc] Hmmm I've defined that application mainly for two reason:
> 1     up to my knowledge that is the 'killer application' for=20
> this kind of
> protocol modification
> 2     my understanding of CCAMP is that a good motivation needs to be
> provided to modify GRSVP-TE and this leads to point 1

I have no issue with the motivation.  I just think there are more
scenarios for creating control plane state for an existing cross
connection.

> If you do this then the bit should be renamed something like=20
> "cross-connection exists" and if set, then the signaling=20
> protocol does not tell the cross connection to set/release=20
> it. [dc] That is how it works apart for the name of the flag.

I realize that. What I'm suggesting is that the name reflect an action
rather than one of several possible purposes.

> Did you consider a generalization of this where in the ERO,=20
> each element has this type of flag?  If so, you could use the=20
> mechanism to say replace two LSPs where the tail of one is=20
> next to the head of the other, with a single LSP.  The action=20
> would be to signal an ERO containing connection details of=20
> each LSP that have the flag on, and where they join, have the=20
> flag off. [dc] If I've understood corretly your point, what=20
> you are saying is a little bir different from what the ID=20
> proposes.  I mean in your exaple you have two different LSPs=20
> that already have some control plane information associated=20
> with them and you want to splice them together.  In this case=20
> you have to replace the CP information while the ID proposes=20
> to add CP information to a XC that don't have it.  Do you=20
> agree with that?

The suggestion was that there are other scenarios in which establishment
of new LSP state for an existing cross connection is useful.  In the
MP->CP case, the MP initially holds state for the connection and before
the action is completed, both MP and CP hold state.  In the two LSP
example above, two entities in the CP hold state about the same
connection.  I see these two cases as similar in that the general case
is about multiple entities holding state for the same resource.

>=20
> Stephen
>=20
>=20
> > From: [email-masked] [mailto:[email-masked]] On=20
> > Behalf Of Diego Caviglia
> > Sent: Wednesday, July 20, 2005 05:44
> > To: [email-masked]
> > Cc: ""Dimitri.Papadimitriou" <Dimitri.Papadimitriou";=20
> "ccamp" <ccamp;=20
> > "gnewsome" <gnewsome; "adrian" <adrian
> > Subject: RE: Moving LSP ownership between control plane and=20
> management=20
> > plane
> >
> >
> >
> > Sorry for this but may be not all have read the ID, I hope=20
> that having=20
> > the text help the discussion.
> >
> > Regards
> >
> > Diego
> >
> >
> >
> >
> >    Network Working Group
> >    Internet Draft
> > Diego Caviglia
> >    Document: draft-caviglia-mp2cpcp2mp-02.txt             Marconi
> >    Proposed Status: Updates RFC 3473
> > Dino Bramanti
> >
> >   Marconi
> >    Expires: December 2005
> > Nicola Ciulli
>=20
> <snip>
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20

Delivery-date: Wed, 20 Jul 2005 11:39:45 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>, <[email-masked]>
Cc: "Igor Bryskin" <[email-masked]>, <[email-masked]>
Subject: Re: LSP stitching questions for discussion
Date: Wed, 20 Jul 2005 12:28:48 +0100

Hi all,

> first a recap: this item on stitching was initiated in order to allow
per
> "domain" control of end-to-end (contiguous) LSP, as part of a separate
> document, and not to extend its scope (unduly, in this case, see below)
> but mainly in order to have the set of all related protocol mechanisms
> within a specific document -

I partially agree.
I would say that stitching was first introduced in the context of
per-domain control of end-to-end LSPs, but that it quickly became apparent
that stitching was an entity in its own right. That is, stitching is a
control plane and data plane technique.
I wanted to separate the function from the applicability, and in
particular I wanted to make sure that the function was not burried inside
an inter-domain I-D that would hide the function and potentially limit its
applicability.
Thus, the chairs insisted that the work was pulled out into a separate I-D
that, as you say, has the set of all related protocol mechanisms within a
specific document.

> from this initial working assumption, it is clear that the segment must
have
> the properties of the incoming end-to-end LSP which are determined among
> other by its switching type e.g. PSC-3 or TDM, the first requirement of
LSP
> stitching is contiguity of the end-to-end LSP at the data plane level
(after
> stitching operation) - and this by definition of the initial working
assumption -

Well, you'll note that I did not quite agree with your initial working
assumption. I am one of those people that fit into the category that Igor
outlined: I believe that it is technically possible to stitch a segment of
a lower layer between two segments of a higher layer. This is *far* from
saying that I can see a good reason to do this.
Indeed, it seems that the mechanisms we are developing say that when
domains exist in distinct layers we would normally use hierarchical LSPs,
and when domains exist in the same layer we would use stitched LSPs.
We should think carefully, however, before specifying in the control plane
that a specific hardware dpleoyment is illegal.

> note: the only latitude which is left (for a given switching type e.g.
PSC-2) is due
> to the properties of packet (PSC) networks that allows you stitch a
segment
> having a larger Max Reservable Bandwidth and Unreserved Bandwidth (we
> would have equivalent latitude for other attributes but this is a local
policy
> decision - which at the end is the sole purpose of this approach)
>
> > Here are some of the questions related to LSP stitching to start a
> > discussion on the usage of LSP stitching.
> >
> >1) Are the control plane signaling procedures for LSP stitching as
> >described in this ID, (explicit request for LSP stitching on
> >LSP segment, different label allocation rules; etc) REQUIRED to stitch
> >packet LSPs in data plane ?
>
> -> yes (beside manual config operation)
>
> >2) Are the control plane signaling procedures for LSP stitching as
> >described in this ID, (explicit request for LSP stitching on
> >LSP segment, different label allocation rules; etc) REQUIRED to stitch
> >non-packet LSPs in data plane ?
>
> -> yes (beside manual config operation)
>
> >3) If an e2e LSP crosses a region boundary (based on different TE
> >link switching capabilities), then can I use LSP stitching -
> >a) control plane procedures for packet LSPs
> >b) data plane procedures for packet LSPs
> >c) control plane procedures for non-packet LSPs
> >d) data plane procedures for non-packet LSPs
>
>
> -> no, when crossing a region boundary, you simply use a document
> named "draft-mpls-lsp-hierarchy-08.txt" which is in the RFC Editor
> queue, but this does not prevent from creating an LSP segment on top
> of an FA-LSP (see below)

I must ask "why not?"
If the answer is that it cannot be done in hardware, I think this is
incorrect.
If the answer is that it does not need to be done because hierarchical
LSPs exist, then I can buy that argument, but only because I cannot think
of a reason to use stitched segments in this way.

> >4) If the switching type of an e2e LSP is different from that of an LSP
> >segment, can I use LSP stitching -
> >a) control plane procedures for packet LSPs
> >b) data plane procedures for packet LSPs
> >c) control plane procedures for non-packet LSPs
> >d) data plane procedures for non-packet LSPs
>
> -> no, in this case progression of the end-to-end LSP establishment,
implies
> that the LSP segment must fulfil a set of constraints carried as part of
the
> incoming end-to-end LSP request, in this case one has to create an LSP
> segment (with a switching type equal to the incoming end-to-end LSP
> switching type) over that FA (i.e. referred here above to the LSP
segment
> with a different Switching Type)

I don't see any difference between questions 3 and 4 notwithstanding the
explanatory paragraph below.

Please note that, given the appropriate adaptation capabilities I can
advertise an LSP that crosses a lower layer as a TE link in a higher
layer. When I do this, I advertise the switching capabilities of the TE
link as those of the higher layer, not the lower layer.

The same technique could be applied for stitching segments (provided
suitable adaptation exists). Agreed this might represent a waste of
bandwidth in the lower layer. Agreed there appears to be no reason to do
this when hierarchical LSPs can be created.

I just want to separate requirements/desires from technical possibilities.

> >Note that although 3) and 4) appear to be the same, the reason I have
> >them as different questions is that in one case the TE link switching
> >capability is examined and in the other case the Generalized Label
Request
> >is examined.
>
> -> what it appears to me is that this discussion mixes the issue of the
operation
> describing the stitching operations at the domain boundaries from the
LSP
> segment creation itself i.e. an LSP segment can indeed be an FA link
inherited
> from the creation of an (intra-domain) FA-LSP -

Yes. It is worth noting that if you create a hierarchical LSP *within* a
domain, you have necessarily created a layer (or region) boundary.
If you create a stitching segment within a domain, you do not do this.

Layer boundaries may not be important in PSC networks since PSC1 and PSC2
are very similar. But layer boundaries are really important in TDM, LSC
and FSC networks. In these cases stitching segments within the layer may
play an important role for domain sub-division.

Adrian

Delivery-date: Wed, 20 Jul 2005 11:32:43 +0000
Sensitivity: 
Subject: Re:
To: [email-masked]
Cc: [email-masked]
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 13:32:40 +0200

Hi Stephen,
            my answers in line.

Regards

Diego

"Stephen Shew" <[email-masked]>@ops.ietf.org on 20/07/2005 12.22.49

Sent by:    [email-masked]

To:    "\"ccamp\" <ccamp"
cc:

Subject:

Diego, my suggestion for this draft is that it separate the mechanism
(not setting the cross connects specified in an ERO), from the reason
for doing so.  This is because the mechanism could be used for more than
just CP<->MP handoff.
[dc] Hmmm I've defined that application mainly for two reason:
1     up to my knowledge that is the 'killer application' for this kind of
protocol modification
2     my understanding of CCAMP is that a good motivation needs to be
provided to modify GRSVP-TE and this leads to point 1

If you do this then the bit should be renamed something like
"cross-connection exists" and if set, then the signaling
protocol does not tell the cross connection to set/release it.
[dc] That is how it works apart for the name of the flag.

Did you consider a generalization of this where in the ERO, each element
has this type of flag?  If so, you could use the mechanism to say
replace two LSPs where the tail of one is next to the head of the other,
with a single LSP.  The action would be to signal an ERO containing
connection details of each LSP that have the flag on, and where they
join, have the flag off.
[dc] If I've understood corretly your point, what you are saying is a
little bir different from what the ID proposes.  I mean in your exaple you
have two different LSPs that already have some control plane information
associated with them and you want to splice them together.  In this case
you have to replace the CP information while the ID proposes to add CP
information to a XC that don't have it.  Do you agree with that?

Stephen

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Diego Caviglia
> Sent: Wednesday, July 20, 2005 05:44
> To: [email-masked]
> Cc: ""Dimitri.Papadimitriou" <Dimitri.Papadimitriou"; "ccamp"
> <ccamp; "gnewsome" <gnewsome; "adrian" <adrian
> Subject: RE: Moving LSP ownership between control plane and
> management plane
>
>
>
> Sorry for this but may be not all have read the ID, I hope
> that having the text help the discussion.
>
> Regards
>
> Diego
>
>
>
>
>    Network Working Group
>    Internet Draft
> Diego Caviglia
>    Document: draft-caviglia-mp2cpcp2mp-02.txt             Marconi
>    Proposed Status: Updates RFC 3473
> Dino Bramanti
>
>   Marconi
>    Expires: December 2005
> Nicola Ciulli

<snip>

Delivery-date: Wed, 20 Jul 2005 11:25:10 +0000
To: "Diego Caviglia" <[email-masked]>
Cc: "Dimitri.Papadimitriou" <[email-masked]>, "ccamp" <[email-masked]>, "gnewsome" <[email-masked]>, "adrian" <[email-masked]>
From: [email-masked]
Subject: RE: Moving LSP ownership between control plane and management plane
Date: Wed, 20 Jul 2005 13:23:42 +0200

Delivery-date: Wed, 20 Jul 2005 10:29:30 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Tom Petch" <[email-masked]>, <[email-masked]>
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Wed, 20 Jul 2005 10:54:04 +0100

Tom,

I don't think it is CCAMP's role to correct the English of another SDO :-)

Thanks,
Adrian
----- Original Message ----- 
From: "Tom Petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 19, 2005 7:18 PM
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
Lexicography

> Adrian
>
> I think it should be
> "
>  - CCAMP has primary responsibility for the descriptions of GMPLS terms
>
>  Correct "
>
> even if that is not what SG15 said.
>
> Primarily (sic) CCAMP has responsibility for the specification of GMPLS,
not
> just its terms:-)
>
> Tom Petch
>
> ----- Original Message -----
> From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Cc: "'Kireeti Kompella'" <[email-masked]>; <[email-masked]>; "Bill
Fenner"
> <[email-masked]>; "Scott Bradner" <[email-masked]>
> Sent: Tuesday, July 19, 2005 1:59 PM
> Subject: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
> Lexicography
>
>
> > Hi,
> >
> > Please comment on this draft response liaison which I intend to send
on
> > Monday 25th July.
> > You can see the original incoming liaison at
> > http://www.olddog.co.uk/incoming.htm
> >
> > Thanks,
> > Adrian
> > =====
> > To: ITU-T SG15 Questions 12 and 14
> > From: IETF CCAMP Working Group
> > Subject: Response to your liaison on GMPLS/ASON Lexicography
> > For: Action
> > Deadline: August 31st 2005
> >
> > The CCAMP Working Group would like to thank SG15 and especially
Questions
> > 12 and 14 for the time and effort they put into providing input and
> > feedback on the GMPLS/ASON lexicography Internet-Draft that is being
> > developed by CCAMP. Much of the material supplied as direct comments
or as
> > mark-ups to the Internet-Draft has been incorporated into the latest
> > revision which is available at
> >
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-03.
> txt
> >
> > In your liaison you state some assumptions which we would like to
comment
> > on as follows.
> >
> > - The purpose of the document is to enable those familiar with ASON
> >   to understand GMPLS terminology in an ASON context
> >
> > Correct.
> >
> > - GMPLS terms are described informally in the document in a way that
> >   is generally consistent with GMPLS (existing RFCs and work in
progress)
> >
> > While the definition of GMPLS terms would be helpful for understanding
> > GMPLS terms in a GMPLS context, that is not the purpose of this
document.
> >
> > - Based on these descriptions, interpretations of these GMPLS terms
> >   in ASON terminology are provided
> >
> > It is intended that the interpretation of the GMPLS terms is not based
on
> > these descriptions, but based on the full meaning of the GMPLS terms.
The
> > descriptions of the GMPLS terms are provided in this Internet-Draft
for
> > context and a brief summary.
> >
> > - CCAMP has primarily responsibility for the descriptions of GMPLS
terms
> >
> > Correct.
> >
> > - Q12/15 has responsibility to provide input to the GMPLS-ASON
> >   interpretations (based on the descriptions in this draft)
> >
> > We welcome this assumption of responsibility by Q12/15 to provide
input to
> > the Internet-Draft. While the Internet-Draft remains under the overall
> > editorial control of the CCAMP working group, we hope to be able to
use
> > the text supplied by Q12/15 with only editorial changes.
> >
> >
> > Additionally, we welcome the pledge to continue work on this
> > Internet-Draft through correspondence on the Q12/15 mailing list, and
> > thank Q12/15 for assigning Ben Mack-Crane as the SG15 representative
on
> > this matter. Ben has proved very helpful in clarifying and developing
> > comments received from SG15.
> >
> >
> > We have had several email exchanges with Ben about a few of the
specific
> > comments made in your review of the 02 revision of the Internet-Draft.
> > Although he has taken these comments to the Q12/15 mailing list no
> > response has been received, perhaps due to pressure of time. We are
taking
> > the opportunity to restate several questions here for your convenience
and
> > would appreciate your answers as part of the response to this liaison.
> >
> > 1. Definition of a Resource (section 3.2)
> >    You have supplied us with the simple text that says...
> >      In ASON applications:
> >      A resource refers only to a link connection (e.g. VC-11,
> >      VC-4 etc.).
> >
> >    We would like to clarify this because we don't understand how
> >    the original text is wrong. It used to say...
> >      ITU-T [should be ASON] terms for resource:
> >      - Connection point (cp) in the context of link discovery
> >        and resource management (allocation, binding into
> >        cross-connects, etc.);
> >      - Link connection or trail termination in the context of
> >        routing, path computation and signaling.
> >
> >    Recall that we are talking about the ASON terms for what GMPLS
> >    calls a resource. We think the following...
> >    In ASON a link connection is an association of output cp on one
> >    side of the link and input cp on the other side of the link. In
> >    GMPLS by resource we mean in most of the cases the local end of
> >    the resource (which is cp in ASON terminology). This is true in
> >    the context of link discovery.
> >
> >    More importantly, this is also true in the context of a
> >    signaling application. Specifically, when a GMPLS signaling
> >    sub-system requests allocation of a resource, the GMPLS
> >    Resource Manager allocates only the local end of the
> >    resource. This happens on both sides of the link, that is, we
> >    allocate input and output resources. This contrasts with ASON,
> >    where there is a much more versatile LRM, and the connection
> >    manager (signaling application) allocates link connections
> >    only on the output side, leaving LRM to coordinate the
> >    allocation with the neighbor.
> >
> >    However, in GMPLS TE advertisements we account only for
> >    outgoing resources, that is, we don't advertise incoming
> >    resources on the assumption that they match the outgoing
> >    resources for the discovered TE links.
> >
> >    Bottom line: we believe that we should retain the previous
> >    definitions, and have not made this change in the new
> >    revision. We would like to discuss this point further with
> >    Q12/15.
> >
> > 2. Link ends and Data links (Section 3.5 - was section 3.4)
> >
> > 2a.Although we understand that ASON does not require the concept
> >    of a link end, GMPLS does. Therefore we should provide some
> >    form of language to help people do the mapping.
> >
> >    The proposed new text from Q12/15 removes all reference to
> >    link ends from the ASON section, and we feel this is a
> >    mistake and propose the following text:
> >      In ASON, a GMPLS unidirectional data link end is a
> >      collection of connection points from the same client
> >      layer that are supported by a single trail termination
> >      (access point).
> >
> >    This text depends on the fact that a link end is described as
> >    a set of resources that transfer traffic to a neighbor.
> >
> > 2b.The new text from Q12/15 gives us...
> >      A GMPLS data link is an ASON link supported by a single
> >      server trail.
> >
> >    We are not sure that we understand this correctly. It
> >    appears to say that a unidirectional data link could be
> >    supported by multiple trail terminations (access points).
> >    This seems to suggest that a client would have to make a
> >    choice about where to send data, which seems to imply it
> >    really has to choose between data links! We are confused!
> >
> >    We think some of this problem may come from the *need* in
> >    GMPLS to identify data link ends. There may be some value in
> >    stressing that a GMPLS link end is supported by exactly one
> >    trail termination. When several trail terminations are
> >    involved, we can still talk about single TE link (as a
> >    bundle), but each component link will be a distinct data
> >    link. We think that in ASON the SNPP (TE link in GMPLS
> >    language) could be supported by multiple terminations.
> >
> > 3. Link interfaces (section 3.6 - was 3.5)
> >    The new text from Q12/15 gives us...
> >      A GMPLS interface is "all the stuff between a physical
> >      interface and a matrix in an ASON network element." More
> >      precisely, it is a trail termination function and adaptation
> >      function for which adapted client layer connection points
> >      are bound to a matrix.
> >
> >    We think "physical interface" may be ambiguous in the multi-
> >    layer context. We think the "stuff" should be between a link
> >    and a matrix, since we are talking about links in distinct
> >    layers.
> >
> >
> > In addition to your feedback on the specific points above, we would
> > welcome your continued comments and review of the Internet-Draft.
> >
> > Regards,
> > Adrian Farrel and Kireeti Kompella
> > IETF CCAMP Working Group Co-chairs
> >
> >
>
>
>
>

Delivery-date: Wed, 20 Jul 2005 10:29:24 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Scott Brim \(sbrim\)" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Wed, 20 Jul 2005 10:45:16 +0100

Scott,

In general, providing a long list of RFCs and I-Ds would probably not be
helpful. In any case, it can be obtained by looking at the CCAMP and MPLS
charter pages.

On several occasions someone has suggested compiling a compendium of GMPLS
terms with cross-references to RFCs and I-Ds, while others have said this
is not worth the effort because it would be necessary to read the
referenced documents in their entirety anyway. The chairs have always said
that they would welcome such a compendium if someone wrote it and did a
thorough job, but no-one has stepped up to do this task.

The main point of my original comment is that the Lexicography is not this
compendium.

Thanks,
Adrian

----- Original Message ----- 
From: "Scott Brim (sbrim)" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 19, 2005 8:30 PM
Subject: RE: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
Lexicography

On Tuesday, July 19, 2005 06:59 AM, Adrian Farrel allegedly wrote:

> While the definition of GMPLS terms would be helpful for
> understanding GMPLS terms in a GMPLS context, that is not the
> purpose of this document.

It would be polite to tell them where to find the definions :-)

Delivery-date: Wed, 20 Jul 2005 10:29:16 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Thomas D. Nadeau" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: Re: no more milestones?
Date: Wed, 20 Jul 2005 10:49:07 +0100

Hi Ichiro,

In the agenda (now on-line at http://www.olddog.co.uk/63/ccamp.htm) you'll
see that we have set aside just over 30 minutes to discuss the work plan
for CCAMP.

The chairs will prepare some material based on the discussions last
November and the new work that has come forward since then. We will post
this material in advance of the meeting to give people a chance to think
and talk about it.

Hopefully, in the meeting or before, we can discover the process we should
follow and go on to clarify what the working group should be working on
for the next 12 months or so.

Thanks,
Adrian

> I agree that base signalling and routing GMPLS protocols need to be
> worked out, and at the same time I would like to see GMPLS applications
> in operational networks.
>
> I remember about the vote on specific items (to-be-rechartered items)
which
> included basic signalling and routing aspects as well as some extended
> applications.
> At that time, I felt we had a long and good discussion already about
what
> would be on the revised charter and it was very close to decide.
>
> Now, though (because?) I don't know what process is done and further
needed
> beyond what we already went through and saw, I appreciate if we can see
new
> milestones reflecting the vote and recent discussions so that we can
determine in
> Paris hopefully without, but with some more discussion if needed.
>
> Thanks.
>
> Ichiro Inoue
>
>  >  >> I would like to see:
>  >  >> - a refinement of the charter to focus the next work items
>  >  >> - a year's worth of milestones to ensure we stay focused.
>  >  >>
>  >  >> On the other hand, we should aim to close down CCAMP and move the
>  >  >> work to
>  >  >> other or new working groups.
>  >  >>
>  >  >
>  >  > coupling both sentences does it mean in your view
>  >  >
>  >  > 1) define several short-term milestones for refining topics that
>  >  > have been
>  >  > already initiated and requires further well scoped attention
>  >  >
>  >  > 2) (brand) new topics should target new working groups - as
already
>  >  > initiated with L1VPN for inst. - or existing working groups
>  >  >
>  >  > nevertheless, i do not see why this automatically means CCAMP can
not
>  >  > remain the focal point concerning *base* GMPLS signaling and
routing
>  >  > protocols

Delivery-date: Wed, 20 Jul 2005 10:23:32 +0000
Content-class: urn:content-classes:message
Subject: 
Date: Wed, 20 Jul 2005 06:22:49 -0400
From: "Stephen Shew" <[email-masked]>
To: "\"ccamp\" <ccamp" <[email-masked]>

Diego, my suggestion for this draft is that it separate the mechanism
(not setting the cross connects specified in an ERO), from the reason
for doing so.  This is because the mechanism could be used for more than
just CP<->MP handoff.  If you do this then the bit should be renamed
something like "cross-connection exists" and if set, then the signaling
protocol does not tell the cross connection to set/release it.

Did you consider a generalization of this where in the ERO, each element
has this type of flag?  If so, you could use the mechanism to say
replace two LSPs where the tail of one is next to the head of the other,
with a single LSP.  The action would be to signal an ERO containing
connection details of each LSP that have the flag on, and where they
join, have the flag off.

Stephen

> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Diego Caviglia
> Sent: Wednesday, July 20, 2005 05:44
> To: [email-masked]
> Cc: ""Dimitri.Papadimitriou" <Dimitri.Papadimitriou"; "ccamp"=20
> <ccamp; "gnewsome" <gnewsome; "adrian" <adrian
> Subject: RE: Moving LSP ownership between control plane and=20
> management plane
>=20
>=20
>=20
> Sorry for this but may be not all have read the ID, I hope=20
> that having the text help the discussion.
>=20
> Regards
>=20
> Diego
>=20
>=20
>=20
>=20
>    Network Working Group
>    Internet Draft                                       =20
> Diego Caviglia
>    Document: draft-caviglia-mp2cpcp2mp-02.txt             Marconi
>    Proposed Status: Updates RFC 3473                     =20
> Dino Bramanti
>                                                              =20
>   Marconi
>    Expires: December 2005                                =20
> Nicola Ciulli

<snip>=20

Delivery-date: Wed, 20 Jul 2005 09:54:35 +0000
Content-class: urn:content-classes:message
Subject: 
Date: Wed, 20 Jul 2005 05:54:07 -0400
From: "Stephen Shew" <[email-masked]>
To: <[email-masked]>

Adrian, see comment below.

> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Tuesday, July 19, 2005 10:02
> To: George Newsome
> Cc: [email-masked]
> Subject: Re: Moving LSP ownership between control plane and=20
> management plane
>=20
>=20
> Thanks George,
>=20
> Useful input.
<snip>

> > - Call awareness of migration vs. connection being unaware=20
> of migration.
> >   When connection state is being created to match an existing=20
> > connection, the connection controllers (CCs) do not require=20
> awareness=20
> > of why this is happening as the context could be migration or=20
> > recovery.  A mechanism to create control state without affecting=20
> > transport plane state is needed in the CCs.  Call=20
> controllers though=20
> > do need migration awareness as they need to obtain/derive call=20
> > identification from the MP.
>=20
> I disagree.
> Connection controllers must be able to distinguish between=20
> resources that are already in use and cannot be assigned to a=20
> new connection, and those that are already in use and can be=20
> assigned to a new connection because the connection is=20
> replacing an existing connection. If this were happening=20
> entirely within the control plane we would use resource=20
> sharing, but when the operation spans the control and=20
> management planes resource ownership/sharing is more complex=20
> and the conneciotn controller needs to be able to issue the=20
> approriate instrucitons for the assignment of the resources.=20
> On the other hand, call controllers do not need awareness of=20
> the details of the realisation of the connections.

I'm not sure if the difference between migration awareness and the
action of creating connection state for an existing transport connection
is clear in the original point.  I agree with your first sentence and
think that signalling could be extended to include the case where
connection details (in a complete ERO) are supplied with the attribute
that the cross connections are already in place.  Similarly, teardown of
connection state can occur where cross connections are not undone.  I
still agree though with the original point and note that it does not say
that call controllers are aware of connection details.  Call controllers
are aware that a migration action is the reason for triggering the
connection controller to establish state.

The point about awareness refers to an understanding of why LSP state is
being created.  If existing LSP state is being replaced by another one
(e.g., a recovery scenario or maybe a change of the extent of the
transport connection), then I think it's sufficient for the connection
controller to be told that it should not change the cross connection
(matrix level subnetwork connection).  If the overall action fails for
some reason, the call entity can then decide whether to try again,
and/or tell the management plane what happened.

I believe that this is consistent with what the existing protocol(s)
know when they are creating LSPs.  For example, a protocol instance is
not aware whether the connection being created is a result of a "break
before make" or "make before break" scenario, or that it is the 3rd
connection being created for a VCAT group. This understanding should
only be known by the initiator of the action.

Stephen

Delivery-date: Wed, 20 Jul 2005 09:44:43 +0000
Sensitivity: 
Subject: RE: Moving LSP ownership between control plane and management plane
To: [email-masked]
Cc: "\"\"Dimitri.Papadimitriou\" <Dimitri.Papadimitriou\"" <[email-masked]>, ""ccamp" <ccamp" <[email-masked]>, ""gnewsome" <gnewsome" <[email-masked]>, ""adrian" <adrian" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 11:44:13 +0200

Sorry for this but may be not all have read the ID, I hope that having =
the
text help the discussion.

Regards

Diego

   Network Working Group
   Internet Draft                                        Diego Caviglia=

   Document: draft-caviglia-mp2cpcp2mp-02.txt             Marconi
   Proposed Status: Updates RFC 3473                      Dino Bramanti=

                                                                Marconi=

   Expires: December 2005                                 Nicola Ciulli=

                                                              NextWorks=

                                                              June 2005=

     GMPLS Signaling Extensions for the Transfer of Ownership of Label
         Switched Paths Between the Management and Control Planes

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six month=
s
   and may be updated, replaced, or obsoleted by other documents at any=

   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress=C6=C6.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   During migration scenarios it may be desirable to transfer the
   ownership of a Label Switched Path (LSP) from the Management Plane
   (MP) to the Control Plane (CP), or vice versa. If the LSP is carryin=
g
   traffic this change needs to be made "in service," that is, without
   affecting traffic.
   This memo provides minor extensions to the Generalized Multi Protoco=
l
   Label Switching (GMPLS) signaling protocol, GRSVP_TE (Generalized
   Resource Reservation Protocol with Traffic Engineering Extensions),

Caviglia et al.        Expires - December 2005               [Page 1]
=0C                     draft-caviglia-mp2cpcp2mp-02            June 20=
05

   to enable such transfer of ownership and describes the proposed
   procedures.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in thi=
s
   document are to be interpreted as described in RFC-2119 [1].

Table of Contents

   1. Introduction...................................................2
   2. Problem Explanation............................................3
   3. Proposed solution..............................................3
   4. LSP Ownership Handover Procedure Between Management And Control
   Planes............................................................5
      4.1 "MP to CP handover" - LSP Ownership Transfer From Management
      Plane To Control Plane.........................................5
      4.2 MP to CP Handover Procedure Failure Handling...............8
      4.3 "CP to MP handover" - LSP Ownership Transfer From Control
      Plane To     Management Plane..................................8
      4.4 CP to MP Handover Procedure Failure Handling...............9
   5. RSVP Message Formats..........................................10
      5.1 Object Modification.......................................10
   6. Security Considerations.......................................10
   7. IANA Consideration............................................10
   8. References....................................................11
   9. Acknowledgments...............................................11
   Author's Addresses...............................................11

1. Introduction

   In a typical, traditional transport network scenario, Data Plane
   connections between two endpoints are controlled basically by means
   of a Network Management System (NMS) operating within Management
   Plane (MP). NMS/MP is the owner of such transport connections, being=

   responsible of their set up, tear down and maintenance. The adoption=

   and use of a GMPLS Control Plane over networks that are controlled b=
y
   NMS at Management Plane level and that are already in service could
   not be considered a green field application. In this context, let's
   indicate with the term Label Switched Path (LSP) the Data Plane
   forwarding path and Data Plane state associated to a connection,
   whose control is owned by either Management or Control Plane (via
   GRSVP-TE). In a mixed scenario, LSPs owned by Management Plane and
   LSPs owned by Control Plane have to coexist and a way to move their
   control and ownership between planes, while preserving corresponding=

Caviglia et al.        Expires - December 2005               [Page 2]
=0C                     draft-caviglia-mp2cpcp2mp-02            June 20=
05

   Data Plane traffic, is needed. It is in fact possible that a network=

   operator wants to move the control of a Management Plane owned
   transport connection to Control Plane and, in the same way, the
   opposite operation is also needed. In this memo let's indicate with
   "MP to CP handover" the procedure that is aimed at moving the contro=
l
   and ownership of a transport connection owned by Management Plane to=

   Control Plane. Let's call "CP to MP handover" the opposite procedure=
,
   aimed at moving the ownership of a LSP from Control Plane to
   Management Plane.

2. Problem Explanation

   Having the ownership of a LSP means basically having the access to
   the information associated to a physical Data Plane connection
   between two endpoints (ingress and egress of LSP) that traverses a
   list of nodes. The owner of a LSP has to store and use such
   information (LSP hop list, associated TE information etc.) to contro=
l
   completely the LSP. Let's take the case of a Data Plane connection
   between an ingress node and an egress node, which has been set up by=

   means of NMS. The network resources allocated to this connection
   cannot be used or controlled by GRSVP-TE as it doesn't have any
   information record about it. If a standard GRSVP-TE setup request
   over the same resources was issued, the nodes will reject it, as the=
y
   find the involved resources already allocated. A standard GRSVP-TE
   release request for that LSP wont be successful as well, because LSP=

   related information to be matched with the one sent in signaling
   messages is not available at Control Plane level.
   If a Data Plane connection between an ingress node and an egress has=

   been set up via GRSVP-TE signaling, all the info related to the LSP
   is present at Control Plane level which is the owner of that
   connection. If NMS wants to take over the LSP, the Control Plane has=

   to be informed that involved resources are no more under its control=
.
   In both cases, the point is that the Data Plane connection has to
   stay up, but related information allowing control of the LSP has to
   be handed over to Control Plane or Management Plane. In other words,=

   a handover of LSP ownership between planes means that Data Plane
   circuit has to stay untouched in terms of topology and resources
   allocated, not only in terms of carried traffic.

3. Proposed solution

   A new flag in the Administrative Status Object (RFC 3471[4] and RFC
   3473 [5]), named Handover flag, is proposed in this memo as a mean t=
o
   make possible necessary information exchange among GMPLS enabled
   nodes, in order to implement and support the functionality introduce=
d

Caviglia et al.        Expires - December 2005               [Page 3]
=0C                     draft-caviglia-mp2cpcp2mp-02            June 20=
05

   above. The idea is that standard GRSVP-TE signaling flow can be used=

   to inform nodes about the ownership handover procedure, where such
   flow has to be flagged in order to distinguish it from normal LSP
   setup/release procedure. When a LSP owned by Management Plane has to=

   be handed over to Control Plane, a signaling set-up with HANDOVER
   flag set has to be sent from ingress node. At ingress node all the
   information related to the LSP is passed to GRSVP-TE, which uses it
   to fill in the PATH message (Explicit Route Object - ERO, Traffic
   Engineering and context information). Such PATH message, sent with
   HANDOVER flag set, reaches the nodes along the LSP path and informs
   them that the referred LSP is already present at Data Plane level an=
d
   that it has to be adopted by Control Plane. After a node has receive=
d
   such special PATH, it becomes owner of the LSP and treat it like any=

   other LSP set up via GRSVP-TE. Let's call this procedure "MP to CP
   handover".
   The opposite procedure "CP to MP handover" works in a similar way.
   When a LSP owned by Control Plane has to be handed over to Managemen=
t
   Plane, a signaling PATH DOWN with HANDOVER flag set has to be sent
   from ingress node along the LSP path, informing involved nodes that =
a
   CP to MP handover is in progress for that LSP.
   The information about that LSP under control within GRSVP-TE scope i=
s
   passed to Management Plane at ingress node, and in every node, which=

   receives flagged PATH DOWN. A node is able to recognize such special=

   PATH DOWN by reading the handover flag value. If a node finds that
   flag set, then it is aware that that the related LSP has to stay
   untouched at Data Plane level, but its ownership has to be passed to=

   Management Plane. It is worth stressing that, when the LSP is adopte=
d
   either by CP or MP, i.e. at the end of signaling with Handover flag
   set, normal CP procedures or MP procedures have to take their place
   as usual when needed. This means that a LSP formerly owned by MP,
   signaled within CP with Handover flag set (i.e. handed over to CP)
   can be deleted by usual relevant Control Plane signaling flows (i.e.=

   with Handover flag not set). The same applies when considering the
   handover of a LSP from CP to MP when, at the end of procedure, the
   LSP belongs to Management Plane and can be fully controlled by NMS.
   In other words, after the LSP handover procedures have taken place,
   the LSP is not different from the other LSP owned by handover
   destination entity and it has to be treated with usual rules for tha=
t
   entity.
   This is in some way similar to the Restart Procedure, (Section 4.3
   RFC 3473 [5]), in the sense that the status of the physical resource=
s
   at Data Plane has to stay unmodified but the associated information
   allowing its control has to be transferred. The modification propose=
d
   in this document refers only to Administrative Status object, that
   is, the message flow is left unmodified for both set-up and deletion=
.
   Following section gives detailed description of proposed "MP to CP
   handover" and "CP to MP handover" procedures.
   In the following the handover of a bidirectional LSP is assumed. The=

   case of unidirectional LSP can be easily derived from that.

Caviglia et al.        Expires - December 2005               [Page 4]
=0C                     draft-caviglia-mp2cpcp2mp-02            June 20=
05

4. LSP Ownership Handover Procedure Between Management And Control
   Planes

   Resv Confirm message within LSP setup signaling flow SHOULD be
   supported in order to manage at best LSP Ownership Handover Procedur=
e
   Between Control And Management Planes. If Resv Confirm is not presen=
t
   in message set used for LSP setup, the handover procedure described
   below is still applicable using the simple Path/Resv sequence (with
   handover flag set as detailed in the following). In that case,
   handover related operations that in the following description are
   triggered by reception of Resv Confirm, MUST to be executed at the
   reception of Resv message.

4.1 "MP to CP handover" - LSP Ownership Transfer From Management Plane
    To Control Plane

   Let's consider the case of a Data Plane connection between two nodes=

   acting as ingress and egress for a LSP. Let's assume that Management=

   Plane has the ownership and control of the LSP and that we want to
   hand it over to Control Plane.
   At the ingress node NMS initiates the transfer of LSP related
   information residing within Management Plane to GRSVP-TE records
   within Control Plane. We assume that this happens under operator or
   management application control and in particular that:

   - Control requests are sent to the ingress LSR by the MP

   - The MP has some way of knowing when the CP has completed its task
     or has failed.

   Ingress node collects from MP all the LSP related information needed=

   at Control Plane level. The way this operation is done and where suc=
h
   information is collected within MP is outside the scope of this memo=
.
   A relevant part of such information is represented by the LSP path,
   which has to be handed over to CP to be used by signaling entity to
   fill the Explicit Route Object (ERO) during setup.
   In order to support the MP to CP handover of LSP, the ERO object in
   the Path message MUST be filled with all the LSP relevant informatio=
n
   down to the Label level.  That can be done by means of the object an=
d
   procedures defined in [5].
   The precise filling of the ERO object is needed as we are assuming
   that the LSP already exists in the network and that every signaling
   relevant info about it is available and accessible to MP in terms of=

   required LSP parameters to build a GRSVP-TE PATH message. After
   gathering all the LSP related information, the ingress node sends ou=
t
   a GRSVP-TE PATH message including the Administrative Status Object
   with HANDOVER flag set.

Caviglia et al.        Expires - December 2005               [Page 5]
=0C                     draft-caviglia-mp2cpcp2mp-02            June 20=
05

   Upon reception of such GRSVP-TE PATH, a node MUST be able to
   understand that a MP to CP handover procedure is in progress by
   reading Handover flag.
   Either the ingress node of the LSP (upon request from MP) and
   intermediate and egress nodes (when receiving a Path message
   containing an Administrative Status object with the Handover flag
   set) is informed about the fact that a LSP adoption procedure is
   requested or ongoing. The node assumes that a Data Plane resource
   related to the info carried in Path Message is already allocated and=

   in place. The node SHOULD check however the consistence of the actua=
l
   Data Plane status of such resource:

   - If the check goes OK, then a GRSVP-TE record for the LSP is
     created associating it to the corresponding Data Plane state. The
     node accepts all the LSP information carried in PATH (if the node
     is not ingress of the LSP, otherwise the information is sent from
     relevant MP entity) and stores it in Path State Block. After that,=

     the procedure goes on as described below.

   - If the check goes NOT OK, that is actual Data Plane state for the
     indicated resource is different from the one indicated in the Path=

     message, then:

        o A PathErr with Path State Removed flag set should be generate=
d

        o GMPLS Control Plane state information about it is not accepte=
d
          by the  handover destination entity

   In both cases, no operation is done over Data Plane. In case of
   positive check, no change is required at that level since the
   connection is already set up and in service. In case of negative
   check, a mismatch or some other error has occurred and no LSP contro=
l
   handover is possible. The procedure rolls back and information
   transfer process from MP to CP at ingress node of the LSP has to be
   fixed and reinitiated. A node participating in a MP to CP handover
   procedure MUST in fact keep track of the special 'handover' conditio=
n
   of the LSP involved, by retaining handover flag status within GRSVP-=

   TE records.
   This is important because during handover procedure no other Data
   Plane, Control Plane or Management Plane action has to be taken on
   the LSP outside the control of the procedure itself. Such special
   state regarding the involved LSP has to be retained until the
   procedure itself has correctly ended.
   After propagating handover Path, a node MUST wait for a Resv message=

   including Administrative Status Object with handover flag set. After=

   receiving it, the actual migration of LSP information is complete.
   However, Handover flag is cleared in Path/Resv state block of the
   involved LSP, only by reception of ResvConfirm message (or Resv

Caviglia et al.        Expires - December 2005               [Page 6]
=0C                     draft-caviglia-mp2cpcp2mp-02            June 20=
05

   message, if ResvConfirm is not supported). After the flag is cleared=
,
   the LSP is left completely under control of GRSVP- TE within Control=

   Plane. This means that any memory about the former MP ownership of
   the LSP is lost.
   The following example covers all possible MP to CP Handover
   scenarios, either in case of success or failure. In the example we
   assume that Data Plane connection, whose control and control
   information has to be handed over from MP to CP, is TDM based (eithe=
r
   SDH or SONET). A more generic case, where the Data Plane resource
   making up the LSP is not tied to a specific technology, can easily b=
e
   derived from this one. The table refers to possible cases when a nod=
e
   at CP level has received LSP information provided by MP and verifies=

   if handover is feasible.
   Let's consider a LSP over the network, connecting a ingress node I
   with an egress node E. Let's call timeslot A and B the Data Plane
   resources referred by control information involved in Handover in a
   given node traversed by the LSP. This means that Handover flagged
   signaling refers to A-B cross-connection over Data Plane.
   The ingress node initiates the procedure upon request from Managemen=
t
   Plane. The way LSP related information is passed from MP to ingress
   node is outside the scope of this procedure description.
   Intermediates nodes and egress node receive the request for LSP
   adoption and the information needed for the operation from Handover
   flagged GRSVP-TE signaling.
   The symbol <----> in table below indicates that the two Timeslots
   involved in Data Plane cross-connection are actually cross-connected=

   over Data Plane, hence Data Plane state corresponds to the indicatio=
n
   provided by LSP data held by MP and in the process of being handed
   over to CP.

         |Actual Data|Control Plane  |Management Plane|Data Plane
         |Plane State|LSP data record|LSP data record |Resources check
   Case 1|  A<---->B |No info yet    |MP expects A-B  |OK to MP to CP
         |           |               |                |LSP handover
   Case 2|  A<---->C |No info yet    |MP expects A-B  |NOT OK for MP to=

         |           |               |                |CP LSP handover

   Case 1:
   - LSP info from Management Plane to be used for LSP control hand
     over to GRSVP-TE matches Data Plane state in terms of involved
     resources
   - LSP data record is not owned yet by Control Plane, hence LSP
     control is still up to MP
   - Checks are OK, so GRSVP-TE state (related to involved LSP) is
     associated to Data Plane state after Handover flagged signaling
     flow (Path/Resv/Resv Confirm with Handover flag set) has ended.
   - At the end of signaling the LSP is completely under CP control.
   - No actions are taken in the Data Plane.

Caviglia et al.        Expires - December 2005               [Page 7]
=0C                     draft-caviglia-mp2cpcp2mp-02            June 20=
05

   Case 2:
   - LSP info from Management Plane to be used for LSP control hand
     over to GRSVP-TE doesn't match Data Plane state in terms of
     involved resources.
   - Control Plane does not own LSP data record yet; hence LSP control
     is still up to MP.
   - Checks are NOT OK. A-B connection is not actually present over
     Data Plane and indicated resources are used within other context
     (A is x-connected to C).
   - GRSVP-TE state (related to involved LSP) is not associated to the
     cross connection after Handover flagged Path message.
   - A PathErr with Path State Removed flag set MUST be sent Upstream.
   - LSP ownership remains completely under MP control. Handover has
     failed.
   - No actions are taken in the Data Plane.

4.2 MP to CP Handover Procedure Failure Handling

   When a mismatch is detected between LSP information owned by MP (and=

   going to be handed over to CP) and the actual Data Plane state
   corresponding to that LSP, actions have to be taken to roll back the=

   LSP ownership handover correctly.
   If such mismatch is detected at LSP ingress node, the issue has to b=
e

   resolved directly between ingress node and MP designed entity and
   this lies outside the scope of this memo. No Control plane signaling=

   is involved yet at this stage.
   If the mismatch is detected at intermediate or egress nodes, when th=
e
   LSP control information arrives at the node via handover flagged Pat=
h
   message, the node MUST reject it by issuing PathErr with Path State
   Removed towards the ingress node. In such a way the procedure is
   interrupted at that node, upstream nodes are informed and no changes=

   are done over control and Data Plane. When a node receives PathErr
   with Path State Removed referred to a LSP, whose data record at CP
   has handover flag set (being in 'handover state'), it MUST clear suc=
h
   LSP data record and propagate the PathErr message upstream.
   No Data Plane actions have to be taken in this case as well.
   The same applies to PathTear message.

4.3 "CP to MP handover" - LSP Ownership Transfer From Control Plane To
    Management Plane

   Let's now consider the case of LSP Ownership Transfer From Control
   Plane To     Management Plane. The scenario is still a Data Plane
   connection between two     nodes acting as ingress and egress for a

Caviglia et al.        Expires - December 2005               [Page 8]
=0C                     draft-caviglia-mp2cpcp2mp-02            June 20=
05

   LSP. But let's assume in this case     that Control Plane has the
   ownership and control of the LSP and that we want    to hand it over=

   to Management Plane. This means that at the end of such    procedure=
,
   the Data Plane state related to that connection is still untouched,
   but the LSP related information record is no more owned by GRSVP-TE
   over Control Plane.
   In other words, after LSP ownership transfer from CP to MP, the LSP
   is no more under control of GRSVP-TE, which is no more able to "see"=

   the LSP itself. This Section covers the procedure needed to manage
   this procedure as a dual, opposite procedure respect to the one
   described in previous section.
   The procedure is performed at a signaling level as described in
   Section 7.2.1 of the RFC 3473 [5].

   At LSP ingress node, relevant MP entity requests the ownership of th=
e
   LSP, How this is done is outside the scope of memo. Ingress node and=

   MP exchange the relevant information for this task and then
   propagates it over Control Plane by means of GRSVP-TE tear down
   signaling flow as detailed below.
   Ingress node MUST send out a Path Down message, with Handover and
   Reflect bits in Admin Status set. No action is taken over Data Plane=

   and Control Plane keeps track of special handover state the LSP is
   in.
   Transit and Egress nodes, upon reception of such handover Path Down,=

   propagate it without any Data Plane action, retaining the handover
   state information associated to the LSP. After that, every node wait=
s
   until the Handover bit is received back in the Resv. Then a PathTear=

   is issued and the whole LSP information record is cleared from GRSVP=
-
   TE data structures. In other words, a normal LSP tear down signaling=

   is exchanged between nodes traversed by the LSP, but handover flag
   set in Path Down message indicates that no Data Plane action has to
   correspond to Control Plane signaling. At the end of handover tear
   down signaling flow, the LSP is released from Control Plane point of=

   view, but its Data Plane state is still unmodified and it is now
   owned and controllable by MP.

4.4 CP to MP Handover Procedure Failure Handling

   Failures during CP to MP handover procedure MUST be managed at
   signaling level as in normal LSP tear down procedure. The only
   difference is the handover flag set in Administrative Status Object
   inside Path Down message which MUST be read by receiving node and
   imposes that no action has to be made over Data Plane resource whose=

   corresponding Control Plane record is involved in handover procedure=
.

Caviglia et al.        Expires - December 2005               [Page 9]
=0C                     draft-caviglia-mp2cpcp2mp-02            June 20=
05

5. RSVP Message Formats

   This memo does not introduce any modification in RSVP messages.

5.1 Object Modification

   This memo introduces a new flag into the Administrative Status
   object.
   The Admin_Status Object is defined in RFC 3473 [5].
   This document uses the H-bit of the Admin_Status object. The bit is
   bit number (TBD by IANA).

   Handover signaling (H): 1 bit

   When set, indicates that a Handover procedure for the transfer of LS=
P
   ownership between Management and Control Planes is ongoing .

6. Security Considerations

   The procedures described in this document rely completely on GRSVP-T=
E
   messages and mechanism. The use of Handover Flag set in Admin Status=

   Object basically informs the receiving entity that no operations are=

   to be done over Data Plane as consequence of such special signaling
   flow. Using specially flagged signaling messages we want to limit th=
e
   function of setup and tear down messages to Control Plane, making
   them not effective over related Data Plane resource usage. So, no
   additional or special issues are arisen by adopting this procedure,
   that aren't already brought up by the use of the same messages,
   without handover flag setting, for LSP control. For GRSVP-TE Securit=
y
   please refer to [3].

7. IANA Consideration

   IANA has been asked to manage the bit allocations for the
   Administrative Status object [6].
   This document requires the allocation of the Handover bit: the H-bit=
.
   IANA is requested to allocate a bit for this purpose.

Caviglia et al.        Expires - December 2005              [Page 10]
=0C                     draft-caviglia-mp2cpcp2mp-02            June 20=
05

8. References

   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP=

   9, RFC 2026, October 1996.

   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997

   [3] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
   Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon
   Internet Ltd., November 1997

   [4] L. Berger (Ed.) =E6=E6Generalized Multi-Protocol Label Switching=

   (GMPLS) Signaling Functional Description=C6=C6, RFC 3471, January 20=
03

   [5] L. Berger (Ed.) =E6=E6Generalized Multi-Protocol Label Switching=

   (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering
   (RSVP-TE) Extensions=C6=C6, RFC 3473, January 2003

   [6] Zamfir, A., " Component Link Recording and Resource Control for

   GMPLS Link Bundles", draft-zamfir-explicit-resource-control-bundle-
   03, February 2004 - work in progress.

   [7] L. Berger (Ed.) "GMPLS - Communication of Alarm Information",
   draft-ietf-ccamp-gmpls-alarm-spec-02.txt, November 2004, work in
   progress.

9. Acknowledgments

   Adrian Farrel provided editorial assistance to prepare this draft fo=
r
   publication.

Author's Addresses

   Diego Caviglia
   Marconi
   Via A. Negrone 1/A
   Genova-Sestri Ponente, Italy
   Phone: +390106003738
   Email: [email-masked]

   Dino Bramanti
   Marconi
   Via Moruzzi 1

Caviglia et al.        Expires - December 2005              [Page 11]
=0C                     draft-caviglia-mp2cpcp2mp-02            June 20=
05

   C/O Area Ricerca CNR
   Pisa, Italy
   Email: [email-masked]

   Nicola Ciulli
   NextWorks
   Corso Italia 116
   56125 Pisa, Italy
   Email: [email-masked]

Intellectual Property Rights Notices

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed t=
o
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information=

   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use o=
f
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository a=
t
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   [email-masked].

Full Copyright Statement

   Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on a=
n
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENT=
S
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Caviglia et al.        Expires - December 2005              [Page 12]
=0C                     draft-caviglia-mp2cpcp2mp-02            June 20=
05

Caviglia et al.        Expires - December 2005              [Page 13]

=

Delivery-date: Wed, 20 Jul 2005 09:37:14 +0000
Sensitivity: 
Subject: RE: Moving LSP ownership between control plane and management plane
To: "Dimitri.Papadimitriou" <[email-masked]>
Cc: "ccamp" <[email-masked]>, "gnewsome" <[email-masked]>, "adrian" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 11:37:09 +0200

Dimitri,
         yes of course the main application is MP-->CP the CP-->MP is just
for simmetry;-))

Diego

[email-masked] on 20/07/2005 11.30.35

To:    "Diego Caviglia" <[email-masked]>
cc:    [email-masked], [email-masked], [email-masked]

Subject:    RE: Moving LSP ownership between control plane and management
       plane

diego -

"My basic question is: do someone think that having a mechanism to move
MP/CP created LSP under the CP/MP domain is useless?"

no -

in part. the MP->CP handover is a key mechanism for migration toward GMPLS
CP

-dimitri.

Delivery-date: Wed, 20 Jul 2005 09:31:58 +0000
Sensitivity: 
Subject: Re: Moving LSP ownership between control plane and management plane
To: "George Newsome <gnewsome" <[email-masked]>
Cc: "Adrian Farrel <adrian" <[email-masked]>, "ccamp" <[email-masked]>, "Neil Harrison <neil.2.harrison" <[email-masked]>, "Dino Bramanti <Dino.Bramanti" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 11:32:04 +0200

Hi Geroge,
           sorry but I don't see how the management effort is something
related to this ID and more in general with CCAMP.

There are already RFC ID that provide tools to signal LSP with ERO filled
up to the Label level and of course this can be done only via management, I
don't remeber any objections on that due to NMS impact.

I'd like to discuss here (I mean in the CCAMP ML) about the ID, that is, if
it useful and if could work and not about the difficulties it implies for
the NMS.

I'm open to discuss, and actually I did, NMS related issues on the ITU-T
ML.

Regards

Diego

George Newsome <[email-masked]>@ops.ietf.org on 20/07/2005 11.03.00

Sent by:    [email-masked]

To:    Adrian Farrel <[email-masked]>
cc:    [email-masked], Neil Harrison <[email-masked]>, Dino
       Bramanti <[email-masked]>

Subject:    Re: Moving LSP ownership between control plane and management
       plane

Adrian, Dino, etc.,

This thread has rapidly got too long, and I don't have the time at the
moment to argue the toss, so I'll reply as a note rather than
intersperse remarks.

On Adrian's question of which operators were at Holmdel - AT&T and
T-Systems. On do operators think they want this - some do some don't.
BT clearly don't see much value in fiddling with signaling.

You ask whether this might be done in service, and there are certainly
those who would like to see just that. Related questions are how many
times in the life of the system might this be done for the same
connection? Is it cost effective to develop a highly reliable solution
that is used just once in the life of the system?

However this is not so much a discussion of whether this could be
useful, but a technical discussion of whether changing a bit (and a slew
of procedures) in a signaling protocol actually provides the claimed
facility.

Because of the effort the management system needs to provide before
signaling might be involved, changing the signaling protocol gives the
illusion of success, yet does not provide the claimed service at all.

Once the management systems have got as far as assigning control plane
names, we can ask what happens to the cross connect object when it is
deleted as part of the hand off procedure? The behavior of this object
is that its deletion results in dropping the matrix connection, which is
exactly not required during the change over.

It is my considered opinion that fiddling with signaling merely
obfuscates the significant difficulties, which are glossed over by
stating that those difficulties occur at a different time.

Regards

             George

Adrian Farrel wrote:

> Thanks George,
>
> Useful input.
>
>
>>You asked for comments on this proposal, which was presented to ITU-T
>>Q14 experts in January of this year.
>
>
> Can you confirm that there were plenty of providers represented at the
> meeting.
>
>
>>There are so many issues involved in moving a connection from the
>>management plane to the control plane that involve intensive management
>>action, that it is not evident that signaling need be involved at all.
>
>
> Interesting. It is certainly valuable to have a list of these issues out
> in the open. I have made some comments in the appended meeting report.
>
> If the control plane is to take over the connection then we assume that
> signaling state must be built so that the control plane could then modify
> or tear down the connection. how would you propose that this be done
> without involving signaling?
>
>
>>As a personal opinion, it makes little sense to consider moving the
>>connection. It makes more sense to replace the connection with one set
>>up via the control plane, and to then delete the original management set
>>up connection.
>
>
> The question arrises of how this would be done in a network with limited
> resources. That is, if it is possible to set up a parallel conneciton
then
> the method you describe would be fine, but if there are not enough
> parallel resources then would you propose that a lambda (for example)
> could be used for the management-established connection and for the
> control-plane-owned connection at the same time? This might present some
> difficulties as well.
>
> Do you have an opinion on my main question which is whether this tyoe of
> change-over would ever be done in service?
>
> Thanks,
> Adrian
>
>
>>Excerpt of the meeting report of Q14 Experts, January 2005
>>
>>WD06 (Marconi) "G.7713 Modification in order to support Circuit
>>Migration" contains a modified version of draft G.7713 Revision as was
>>presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This
>>contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to extend
>>the concept of Call/Connection setup to setup/adopt and release to
>>release/de-adopt. In Connection Adoption both the SNC are not actually
>>created and the LC are not actually established due to the fact that the
>>underlying physical resources are already in place. In the
>>Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated,
>>only the Control Plane information associated with then is removed and
>>the ownership is moved to Management Plane. Attributes for indicating
>>Adoption/Dis-adoption are proposed for the INNI Connection messages.
>>
>>The discussion was mainly on the Management plane and Control plane
>>actions required before signalling is involved. The group noted that the
>>following issues need to be addressed:
>>
>>- Naming of transport resources to the control plane.  Before a call can
>>be placed under signalling control, links that are involved in the
>>connection need to be given control plane names.  Without these, no
>>explicit route can be formed to match the resources of the connection.
>
>
> This is pretty obvious. But actually, this is an issue with moving the
> resources from one plane to another (or having them present in both
> planes). It is certainly a prerequisite for moving the connection, but it
> is not functionally an element of moving the connection.
>
> The draft, as I read it, assumes that these operations have been
completed
> and then asks "how do I move the connection from one plane to the other?"
>
>
>>- Resource state while under dual CP and MP views.  After resources are
>>given control plane names, the resources are still viewed by the
>>management plane.  It may be necessary to create a new state for the
>>resource to indicate that the management plane cannot perform some
>>actions on the connection points as the control plane is about to take
>
> over.
>
> Yes. There is certainly scope for a race condition here. I believe that
> the I-D proposes to (try to) make the transfer an atomic action from the
> point of view of the change-over.
>
> Note, however, that it is wrong to assume that a resource belongs only to
> the control or to the management plane at any moment in time. This may be
> true with respect to the ability to provision/control connections, but
> resources that are available for use by the control plane can still be
> managed through the management plane. Thus, you take a laser out of
> service through the management plane, not through the control plane.
>
>
>>- Role of discovery functions (esp. CELA).  After control plane names
>>are allocated, distributed control plane functions need to be associated
>>and communication adjacencies formed.  This too is a precursor to any
>>signalling procedures in migrating from the MP to CP.
>
>
> Note to CCAMP: CELA is Control Entity Logical Adjacency.
> This too is "obvious".
> But this discussion seems to be wide of the mark. Before deploying a
> control plane, it is clear that this type of operation needs to take
> place. Since (within the context of CCAMP) a control plane *is* going to
> be deployed, we can assume this operation and move on to the discussion
in
> the draft.
>
>
>>- Similarity of migration to synchronization after CP failure and
>>subsequent recovery.  Connection control procedures might be the same in
>>migrating a call from the MP to the CP as the situation when the CP has
>>failed and is recovering.  Here, the network connections are already in
>>place, but connection and call state need to be created to match it.
>>Knowledge of the call and what the connection should be is obtained from
>>the MP for migration, and from some reliable database in the recovery
>
> case.
>
> This is a valid point.
> Control plane failure, however, is unlikely to be total. That is, it
would
> be unusual for more than one control plane link or node to fail. Thus, in
> the control plane, the "reliable database" is distributed and recovery
can
> follow the procedures outlined in
draft-ietf-ccamp-rsvp-restart-ext-03.txt
>
> It would certainly be worth considering whether the procedures used for
> control plane recovery could be applied to transfer of ownership from the
> management to control plane. at the moment, I suspect that they could not
> because the restart extensions assume a specific period during which
> signaling is associated with recovery.
>
> We would also need to look at the reverse process (transfer from CP to
MP)
> that is not possible to cover by CP restart procedures.
>
>
>>- Call awareness of migration vs. connection being unaware of migration.
>>  When connection state is being created to match an existing
>>connection, the connection controllers (CCs) do not require awareness of
>>why this is happening as the context could be migration or recovery.  A
>>mechanism to create control state without affecting transport plane
>>state is needed in the CCs.  Call controllers though do need migration
>>awareness as they need to obtain/derive call identification from the MP.
>
>
> I disagree.
> Connection controllers must be able to distinguish between resources that
> are already in use and cannot be assigned to a new connection, and those
> that are already in use and can be assigned to a new connection because
> the connection is replacing an existing connection. If this were
happening
> entirely within the control plane we would use resource sharing, but when
> the operation spans the control and management planes resource
> ownership/sharing is more complex and the conneciotn controller needs to
> be able to issue the approriate instrucitons for the assignment of the
> resources.
> On the other hand, call controllers do not need awareness of the details
> of the realisation of the connections.
>
>
>>In summary, the group decided that it is premature to consider
>>signalling procedure before the above issues, amongst other, have been
>>studied. However the contribution does enable the group to expose in a
>>larger context the interaction between CP and MP for connection
>>migration. The above issues were included in SP24 of the G.7713 Living
>>List (see WD22).
>
>
>

Delivery-date: Wed, 20 Jul 2005 09:31:22 +0000
To: "Diego Caviglia" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Subject: RE: Moving LSP ownership between control plane and management plane
Date: Wed, 20 Jul 2005 11:30:35 +0200

Delivery-date: Wed, 20 Jul 2005 09:04:12 +0000
Date: Wed, 20 Jul 2005 05:03:00 -0400
From: George Newsome <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: [email-masked], Neil Harrison <[email-masked]>, Dino Bramanti <[email-masked]>
Subject: Re: Moving LSP ownership between control plane and management plane

Adrian, Dino, etc.,

This thread has rapidly got too long, and I don't have the time at the 
moment to argue the toss, so I'll reply as a note rather than 
intersperse remarks.

On Adrian's question of which operators were at Holmdel - AT&T and 
T-Systems. On do operators think they want this - some do some don't.
BT clearly don't see much value in fiddling with signaling.

You ask whether this might be done in service, and there are certainly 
those who would like to see just that. Related questions are how many 
times in the life of the system might this be done for the same 
connection? Is it cost effective to develop a highly reliable solution 
that is used just once in the life of the system?

However this is not so much a discussion of whether this could be 
useful, but a technical discussion of whether changing a bit (and a slew 
of procedures) in a signaling protocol actually provides the claimed 
facility.

Because of the effort the management system needs to provide before 
signaling might be involved, changing the signaling protocol gives the 
illusion of success, yet does not provide the claimed service at all.

Once the management systems have got as far as assigning control plane 
names, we can ask what happens to the cross connect object when it is 
deleted as part of the hand off procedure? The behavior of this object 
is that its deletion results in dropping the matrix connection, which is 
exactly not required during the change over.

It is my considered opinion that fiddling with signaling merely 
obfuscates the significant difficulties, which are glossed over by 
stating that those difficulties occur at a different time.

Regards

	George

Adrian Farrel wrote:

> Thanks George,
> 
> Useful input.
> 
> 
>>You asked for comments on this proposal, which was presented to ITU-T
>>Q14 experts in January of this year.
> 
> 
> Can you confirm that there were plenty of providers represented at the
> meeting.
> 
> 
>>There are so many issues involved in moving a connection from the
>>management plane to the control plane that involve intensive management
>>action, that it is not evident that signaling need be involved at all.
> 
> 
> Interesting. It is certainly valuable to have a list of these issues out
> in the open. I have made some comments in the appended meeting report.
> 
> If the control plane is to take over the connection then we assume that
> signaling state must be built so that the control plane could then modify
> or tear down the connection. how would you propose that this be done
> without involving signaling?
> 
> 
>>As a personal opinion, it makes little sense to consider moving the
>>connection. It makes more sense to replace the connection with one set
>>up via the control plane, and to then delete the original management set
>>up connection.
> 
> 
> The question arrises of how this would be done in a network with limited
> resources. That is, if it is possible to set up a parallel conneciton then
> the method you describe would be fine, but if there are not enough
> parallel resources then would you propose that a lambda (for example)
> could be used for the management-established connection and for the
> control-plane-owned connection at the same time? This might present some
> difficulties as well.
> 
> Do you have an opinion on my main question which is whether this tyoe of
> change-over would ever be done in service?
> 
> Thanks,
> Adrian
> 
> 
>>Excerpt of the meeting report of Q14 Experts, January 2005
>>
>>WD06 (Marconi) "G.7713 Modification in order to support Circuit
>>Migration" contains a modified version of draft G.7713 Revision as was
>>presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This
>>contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to extend
>>the concept of Call/Connection setup to setup/adopt and release to
>>release/de-adopt. In Connection Adoption both the SNC are not actually
>>created and the LC are not actually established due to the fact that the
>>underlying physical resources are already in place. In the
>>Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated,
>>only the Control Plane information associated with then is removed and
>>the ownership is moved to Management Plane. Attributes for indicating
>>Adoption/Dis-adoption are proposed for the INNI Connection messages.
>>
>>The discussion was mainly on the Management plane and Control plane
>>actions required before signalling is involved. The group noted that the
>>following issues need to be addressed:
>>
>>- Naming of transport resources to the control plane.  Before a call can
>>be placed under signalling control, links that are involved in the
>>connection need to be given control plane names.  Without these, no
>>explicit route can be formed to match the resources of the connection.
> 
> 
> This is pretty obvious. But actually, this is an issue with moving the
> resources from one plane to another (or having them present in both
> planes). It is certainly a prerequisite for moving the connection, but it
> is not functionally an element of moving the connection.
> 
> The draft, as I read it, assumes that these operations have been completed
> and then asks "how do I move the connection from one plane to the other?"
> 
> 
>>- Resource state while under dual CP and MP views.  After resources are
>>given control plane names, the resources are still viewed by the
>>management plane.  It may be necessary to create a new state for the
>>resource to indicate that the management plane cannot perform some
>>actions on the connection points as the control plane is about to take
> 
> over.
> 
> Yes. There is certainly scope for a race condition here. I believe that
> the I-D proposes to (try to) make the transfer an atomic action from the
> point of view of the change-over.
> 
> Note, however, that it is wrong to assume that a resource belongs only to
> the control or to the management plane at any moment in time. This may be
> true with respect to the ability to provision/control connections, but
> resources that are available for use by the control plane can still be
> managed through the management plane. Thus, you take a laser out of
> service through the management plane, not through the control plane.
> 
> 
>>- Role of discovery functions (esp. CELA).  After control plane names
>>are allocated, distributed control plane functions need to be associated
>>and communication adjacencies formed.  This too is a precursor to any
>>signalling procedures in migrating from the MP to CP.
> 
> 
> Note to CCAMP: CELA is Control Entity Logical Adjacency.
> This too is "obvious".
> But this discussion seems to be wide of the mark. Before deploying a
> control plane, it is clear that this type of operation needs to take
> place. Since (within the context of CCAMP) a control plane *is* going to
> be deployed, we can assume this operation and move on to the discussion in
> the draft.
> 
> 
>>- Similarity of migration to synchronization after CP failure and
>>subsequent recovery.  Connection control procedures might be the same in
>>migrating a call from the MP to the CP as the situation when the CP has
>>failed and is recovering.  Here, the network connections are already in
>>place, but connection and call state need to be created to match it.
>>Knowledge of the call and what the connection should be is obtained from
>>the MP for migration, and from some reliable database in the recovery
> 
> case.
> 
> This is a valid point.
> Control plane failure, however, is unlikely to be total. That is, it would
> be unusual for more than one control plane link or node to fail. Thus, in
> the control plane, the "reliable database" is distributed and recovery can
> follow the procedures outlined in draft-ietf-ccamp-rsvp-restart-ext-03.txt
> 
> It would certainly be worth considering whether the procedures used for
> control plane recovery could be applied to transfer of ownership from the
> management to control plane. at the moment, I suspect that they could not
> because the restart extensions assume a specific period during which
> signaling is associated with recovery.
> 
> We would also need to look at the reverse process (transfer from CP to MP)
> that is not possible to cover by CP restart procedures.
> 
> 
>>- Call awareness of migration vs. connection being unaware of migration.
>>  When connection state is being created to match an existing
>>connection, the connection controllers (CCs) do not require awareness of
>>why this is happening as the context could be migration or recovery.  A
>>mechanism to create control state without affecting transport plane
>>state is needed in the CCs.  Call controllers though do need migration
>>awareness as they need to obtain/derive call identification from the MP.
> 
> 
> I disagree.
> Connection controllers must be able to distinguish between resources that
> are already in use and cannot be assigned to a new connection, and those
> that are already in use and can be assigned to a new connection because
> the connection is replacing an existing connection. If this were happening
> entirely within the control plane we would use resource sharing, but when
> the operation spans the control and management planes resource
> ownership/sharing is more complex and the conneciotn controller needs to
> be able to issue the approriate instrucitons for the assignment of the
> resources.
> On the other hand, call controllers do not need awareness of the details
> of the realisation of the connections.
> 
> 
>>In summary, the group decided that it is premature to consider
>>signalling procedure before the above issues, amongst other, have been
>>studied. However the contribution does enable the group to expose in a
>>larger context the interaction between CP and MP for connection
>>migration. The above issues were included in SP24 of the G.7713 Living
>>List (see WD22).
> 
> 
> 

Delivery-date: Wed, 20 Jul 2005 08:56:52 +0000
Content-class: urn:content-classes:message
Subject: RE: Moving LSP ownership between control plane and management plane
Date: Wed, 20 Jul 2005 09:56:04 +0100
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Diego.....No I don't think what you are saying is useless, and I'm
sorry if that was the impression I conveyed .......in fact you MUST
consider these aspects (eg the ones George flagged) when you add a CP.
What I was trying to point out is the IMPORTANCE of a CP here relative
to other stuff.  Let me just play out the logic again as briefly as I
can.

As we move towards the duct the importance/value of the control-plane
diminishes.  So for addressing S-PVCs and resilience issues its
fine......where I have grave doubts are those who think they can create
'topology on the fly' (for other client layer networks).  A key factor
here is acceptable GoS/business models....our studies indicate that to
be viable one would need a waiting time (post demand epoch) of at least
the same order as the expected holding time.....now figure out what that
really means.  And of course this still assumes everything BELOW this
SVC level is already provisioned. =20

Then there is the issue of 'who owns which layer?'.....and this means
the overriding requirement that must be addressed 1st is client/server
functional decoupling.  Closely related to this 'who owns which layer'
issue is how the 3 planes of one layer network are provided over the
*traffic plane* of another/lower layer network....and I gave a very
detailed response to Igor on this recently.

And once you piece it all together then you realise we can't have full
convergence from IP to Optics....and a smart observer at this point
might ask 'so why are folks being prescriptive about the choice of
functional components, eg addressing, signalling, routing?'  For example
I could postulate that PNNI is a better signalling protocol than RSVP
...and why would anyone in their right minds start with v4 addressing
when they already know its problems? Should at least use v6 here IMO.
Maybe I only need static routing and this should be a centralised
function? =20

And finally...even when you add the CP it is fact of life, with which I
see you agree, that the MP is still king here.....a CP without a good MP
is rather useless.

regards, neil

> From: Diego Caviglia [mailto:[email-masked]]
> Sent: 20 July 2005 08:52
> To: Harrison,N,Neil,IKM1 R
> Cc: <gnewsome; <adrian; <ccamp
> Subject: RE: Moving LSP ownership between control plane and=20
> management plane
>=20
>=20
>=20
> Hi Neil,
>          it always a pleasure read your e-mail but I think
> I'm missing something.
>=20
> The basic purpose of the ID is to provide a simple mechanism
> to move LSPs from a domain to another, I don't see any=20
> implication, with layering. Better to say this ID have the=20
> same implication with layering as 'normal' signalling.
>=20
> Moreover I agree with you that NMS is the 'king' of the
> network and in fact the ID forseen that is MNS to provide the=20
> right information to CP to move the LSP from a domain to another one.
>=20
> My basic question is: do someone think that having a
> mechanism to move MP/CP created LSP under the CP/MP domain is useless?
>=20
> My experience tell me that the answer is no, but I'm open to
> discuss this.
>=20
> Regards
>=20
> Diego
>=20
>=20
>=20
> <[email-masked]>@ops.ietf.org on 19/07/2005 23.36.27
>=20
> Sent by:    [email-masked]
>=20
>=20
> To:    <[email-masked]>, <[email-masked]>
> cc:    <[email-masked]>
>=20
> Subject:    RE: Moving LSP ownership between control plane=20
> and management
>        plane
>=20
> Hi George....nice to hear from you...hope all is well with you,
>=20
> This all sounds very reasonable to me.  At the end of the
> day, all a signalling protocol is is a distributed agent of=20
> network management.....in the types of large BW granularity=20
> networks being
> discussed the NMS will always be king.   Sorry if that's a problem to
> some folks, its just a fact for the way we see/implement it.
>=20
> This also follows from a good understanding of the
> commercials at play here.  That is, there is a major=20
> difference between:
> -            a public service context (cf PSTN), or extending=20
> a similar
> capability out to end-systems in the co-ps mode say, where=20
> end-systems/applications drive trail set-up (ie SVCs across a=20
> UNI). Here one hopes there could be a large population of users (think
> peer-peer/BB) and that the trail holding-times are not 'too=20
> long'.  In this environment there could be a viable business=20
> case based on a providing a given GoS at some cost.....and it=20
> might solve some
> (otherwise) hard QoS/pricing problems for operators....but I digress;
> -            a private network builder service context where one is a
> providing a (relatively long time-constant)=20
> traffic-engineering function to a higher layer network, ie=20
> creating its topology.  This is a client/server relationship=20
> and THE starting point for this must be functional decoupling=20
> of the client and server layer networks because they will=20
> often be owned by different parties.  We are talking=20
> relatively long forecast/planning cycles here and long trail=20
> holding times....esp when it comes to real physical build. =20
> Further, the potential population is rather small compared to=20
> the previous case.  If folks look at whether there is a=20
> viable business case here based on a providing a given GoS at=20
> some cost in an acceptable time period I suspect they will be=20
> disappointed.
>=20
> What this all means is that the control-plane is not such an
> important topic as we move down the layered network stack=20
> towards the duct....increasingly other factors like strong=20
> NMS and OAM assume a far greater importance.  This is not to=20
> say a control-plane is not useful
> but:
> -            we should be clear there cannot be any common=20
> addressing and
> routing functions across a set of nested layer networks,=20
> which is very obvious when different parties own different=20
> layer networks....one can (and should) re-use components (if=20
> they are the right ones), but they will need to operate in=20
> different layer network spaces
> -            signalling is a useful agent for functions like=20
> S-PVCs and
> resilience.
>=20
> Well that's our analysis anyway....if anyone knows different
> I'd be happy to review their commercial assumptions with folks here.
>=20
>=20
> regards, Neil
>=20
> > Behalf Of George Newsome
> > Sent: 19 July 2005 12:44
> > To: Adrian Farrel
> > Cc: [email-masked]
> > Subject: Re: Moving LSP ownership between control plane and=20
> management
> > plane
> >
> >
> > Adrian,
> >
> > You asked for comments on this proposal, which was
> presented to ITU-T
> > Q14 experts in January of this year.
> >
> > There are so many issues involved in moving a connection from the
> > management plane to the control plane that involve intensive=20
> > management action, that it is not evident that signaling need be=20
> > involved at all.
> >
> > As a personal opinion, it makes little sense to consider moving the
> > connection. It makes more sense to replace the connection=20
> with one set
> > up via the control plane, and to then delete the original
> management
> > set up connection.
> >
> > Appended is an excerpt of the meeting report detailing some of the
> > issues that need to be resolved before signaling need be considered.
> >
> > Regards
> >
> >            George
> >
> > Excerpt of the meeting report of Q14 Experts, January 2005
> >
> > WD06 (Marconi) "G.7713 Modification in order to support Circuit
> > Migration" contains a modified version of draft G.7713=20
> Revision as was
> > presented in the Berlin meeting (WD 11, i.e., TD50/3
> Dec.2004).  This
> > contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to
> > extend the concept of Call/Connection setup to setup/adopt=20
> and release
> > to release/de-adopt. In Connection Adoption both the SNC are not=20
> > actually created and the LC are not actually established due to the
> > fact that the
> > underlying physical resources are already in place. In the
> > Call/Connection dis-adoption SNC-LC-SNC is not actually=20
> de-allocated,
> > only the Control Plane information associated with then is removed=20
> > and the ownership is moved to Management Plane. Attributes for
> indicating
> > Adoption/Dis-adoption are proposed for the INNI Connection messages.
> >
> > The discussion was mainly on the Management plane and Control plane
> > actions required before signalling is involved. The group=20
> noted that
> > the following issues need to be addressed:
> >
> > - Naming of transport resources to the control plane.
> Before a call
> > can be placed under signalling control, links that are
> involved in the
> > connection need to be given control plane names.  Without these, no
> > explicit route can be formed to match the resources of the=20
> connection.
> >
> > - Resource state while under dual CP and MP views.  After resources
> > are given control plane names, the resources are still=20
> viewed by the
> > management plane.  It may be necessary to create a new
> state for the
> > resource to indicate that the management plane cannot perform some
> > actions on the connection points as the control plane is=20
> about to take
> > over.
> >
> > - Role of discovery functions (esp. CELA).  After control
> plane names
> > are allocated, distributed control plane functions need to be
> > associated and communication adjacencies formed.  This too is a=20
> > precursor to any signalling procedures in migrating from=20
> the MP to CP.
> >
> > - Similarity of migration to synchronization after CP failure and
> > subsequent recovery.  Connection control procedures might=20
> be the same
> > in migrating a call from the MP to the CP as the situation
> when the CP
> > has failed and is recovering.  Here, the network connections are=20
> > already in place, but connection and call state need to be created=20
> > to match it. Knowledge of the call and what the connection should be

> > is obtained from
> > the MP for migration, and from some reliable database in the
> > recovery case.
> >
> > - Call awareness of migration vs. connection being unaware of
> > migration.
> >   When connection state is being created to match an existing=20
> > connection, the connection controllers (CCs) do not require=20
> awareness
> > of why this is happening as the context could be migration or=20
> > recovery.  A mechanism to create control state without affecting=20
> > transport plane state is needed in the CCs.  Call controllers though

> > do need migration
> > awareness as they need to obtain/derive call identification
> > from the MP.
> >
> > In summary, the group decided that it is premature to consider
> > signalling procedure before the above issues, amongst=20
> other, have been
> > studied. However the contribution does enable the group to
> expose in a
> > larger context the interaction between CP and MP for connection=20
> > migration. The above issues were included in SP24 of the G.7713=20
> > Living List (see WD22).
> >
> >
> >
> >
>=20
>=20
>=20
>=20
>=20
>=20
>=20

Delivery-date: Wed, 20 Jul 2005 08:47:44 +0000
To: Arthi Ayyangar <[email-masked]>
Cc: Igor Bryskin <[email-masked]>, [email-masked]
From: [email-masked]
Subject: Re: LSP stitching questions for discussion
Date: Wed, 20 Jul 2005 10:46:49 +0200

Delivery-date: Wed, 20 Jul 2005 08:14:06 +0000
Sensitivity: 
Subject: Re: Moving LSP ownership between control plane and management plane
To: "George Newsome <gnewsome" <[email-masked]>
Cc: "Adrian Farrel <adrian" <[email-masked]>, "ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 10:13:55 +0200

Hi Geroge,
           I remember quite well that discussuion, but I also remember that
the common feeling was that the proposed feature is useful.

I can agree that this implies some discussion on the naming of the resource
and so on but the ID assumes that all this stuff has been resolved.

Some more comment in line.

Regards

Diego

George Newsome <[email-masked]>@ops.ietf.org on 19/07/2005 13.44.29

Sent by:    [email-masked]

To:    Adrian Farrel <[email-masked]>
cc:    [email-masked]

Subject:    Re: Moving LSP ownership between control plane and management
       plane

Adrian,

You asked for comments on this proposal, which was presented to ITU-T
Q14 experts in January of this year.

There are so many issues involved in moving a connection from the
management plane to the control plane that involve intensive management
action, that it is not evident that signaling need be involved at all.
[dc] I agree with the fisrt part of your sentence but not with the second.
>From a CP point of view 'adopt' a LSP or create a new one is more or less
the same (in fact the ID basically adds only one bit to the already
existing signalling protocol) so saying that '...is not evident that
signaling need be involved at all' for an adoption can be extended to
signaling in general and that is why I disagree.

As a personal opinion, it makes little sense to consider moving the
connection. It makes more sense to replace the connection with one set
up via the control plane, and to then delete the original management set
up connection.
[dc] Sorry but seems that this is traffic affecting that is something that
usually operators wants to avoid.

Appended is an excerpt of the meeting report detailing some of the
issues that need to be resolved before signaling need be considered.

Regards

             George

Excerpt of the meeting report of Q14 Experts, January 2005

WD06 (Marconi) "G.7713 Modification in order to support Circuit
Migration" contains a modified version of draft G.7713 Revision as was
presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This
contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to extend
the concept of Call/Connection setup to setup/adopt and release to
release/de-adopt. In Connection Adoption both the SNC are not actually
created and the LC are not actually established due to the fact that the
underlying physical resources are already in place. In the
Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated,
only the Control Plane information associated with then is removed and
the ownership is moved to Management Plane. Attributes for indicating
Adoption/Dis-adoption are proposed for the INNI Connection messages.

The discussion was mainly on the Management plane and Control plane
actions required before signalling is involved. The group noted that the
following issues need to be addressed:

- Naming of transport resources to the control plane.  Before a call can
be placed under signalling control, links that are involved in the
connection need to be given control plane names.  Without these, no
explicit route can be formed to match the resources of the connection.
[dc] This is outside the scope of the ID and probabily also from the scope
of the CCAMP/IETF.
We assume that this point has been resolved in the ID.

- Resource state while under dual CP and MP views.  After resources are
given control plane names, the resources are still viewed by the
management plane.  It may be necessary to create a new state for the
resource to indicate that the management plane cannot perform some
actions on the connection points as the control plane is about to take
over.
[dc] Again this is a NMS related issue that is uotside the scope of the
ID/CCAMP and may be IETF.

- Role of discovery functions (esp. CELA).  After control plane names
are allocated, distributed control plane functions need to be associated
and communication adjacencies formed.  This too is a precursor to any
signalling procedures in migrating from the MP to CP.
[dc] Yes but the ID assumes that this has been done.

- Similarity of migration to synchronization after CP failure and
subsequent recovery.  Connection control procedures might be the same in
migrating a call from the MP to the CP as the situation when the CP has
failed and is recovering.  Here, the network connections are already in
place, but connection and call state need to be created to match it.
Knowledge of the call and what the connection should be is obtained from
the MP for migration, and from some reliable database in the recovery case.
[dc] Adrian comment is also my comment

- Call awareness of migration vs. connection being unaware of migration.
  When connection state is being created to match an existing
connection, the connection controllers (CCs) do not require awareness of
why this is happening as the context could be migration or recovery.  A
mechanism to create control state without affecting transport plane
state is needed in the CCs.  Call controllers though do need migration
awareness as they need to obtain/derive call identification from the MP.
[dc] As above.

In summary, the group decided that it is premature to consider
signalling procedure before the above issues, amongst other, have been
studied. However the contribution does enable the group to expose in a
larger context the interaction between CP and MP for connection
migration. The above issues were included in SP24 of the G.7713 Living
List (see WD22).

Delivery-date: Wed, 20 Jul 2005 07:52:41 +0000
Sensitivity: 
Subject: RE: Moving LSP ownership between control plane and management plane
To: "<neil.2.harrison" <[email-masked]>
Cc: "<gnewsome" <[email-masked]>, "<adrian" <[email-masked]>, "<ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 20 Jul 2005 09:51:43 +0200

Hi Neil,
         it always a pleasure read your e-mail but I think I'm missing
something.

The basic purpose of the ID is to provide a simple mechanism to move LSPs
from a domain to another, I don't see any implication, with layering.
Better to say this ID have the same implication with layering as 'normal'
signalling.

Moreover I agree with you that NMS is the 'king' of the network and in fact
the ID forseen that is MNS to provide the right information to CP to move
the LSP from a domain to another one.

My basic question is: do someone think that having a mechanism to move
MP/CP created LSP under the CP/MP domain is useless?

My experience tell me that the answer is no, but I'm open to discuss this.

Regards

Diego

<[email-masked]>@ops.ietf.org on 19/07/2005 23.36.27

Sent by:    [email-masked]

To:    <[email-masked]>, <[email-masked]>
cc:    <[email-masked]>

Subject:    RE: Moving LSP ownership between control plane and management
       plane

Hi George....nice to hear from you...hope all is well with you,

This all sounds very reasonable to me.  At the end of the day, all a
signalling protocol is is a distributed agent of network
management.....in the types of large BW granularity networks being
discussed the NMS will always be king.   Sorry if that's a problem to
some folks, its just a fact for the way we see/implement it.

This also follows from a good understanding of the commercials at play
here.  That is, there is a major difference between:
-            a public service context (cf PSTN), or extending a similar
capability out to end-systems in the co-ps mode say, where
end-systems/applications drive trail set-up (ie SVCs across a UNI).
Here one hopes there could be a large population of users (think
peer-peer/BB) and that the trail holding-times are not 'too long'.  In
this environment there could be a viable business case based on a
providing a given GoS at some cost.....and it might solve some
(otherwise) hard QoS/pricing problems for operators....but I digress;
-            a private network builder service context where one is a
providing a (relatively long time-constant) traffic-engineering function
to a higher layer network, ie creating its topology.  This is a
client/server relationship and THE starting point for this must be
functional decoupling of the client and server layer networks because
they will often be owned by different parties.  We are talking
relatively long forecast/planning cycles here and long trail holding
times....esp when it comes to real physical build.  Further, the
potential population is rather small compared to the previous case.  If
folks look at whether there is a viable business case here based on a
providing a given GoS at some cost in an acceptable time period I
suspect they will be disappointed.

What this all means is that the control-plane is not such an important
topic as we move down the layered network stack towards the
duct....increasingly other factors like strong NMS and OAM assume a far
greater importance.  This is not to say a control-plane is not useful
but:
-            we should be clear there cannot be any common addressing and
routing functions across a set of nested layer networks, which is very
obvious when different parties own different layer networks....one can
(and should) re-use components (if they are the right ones), but they
will need to operate in different layer network spaces
-            signalling is a useful agent for functions like S-PVCs and
resilience.

Well that's our analysis anyway....if anyone knows different I'd be
happy to review their commercial assumptions with folks here.

regards, Neil

> Behalf Of George Newsome
> Sent: 19 July 2005 12:44
> To: Adrian Farrel
> Cc: [email-masked]
> Subject: Re: Moving LSP ownership between control plane and
> management plane
>
>
> Adrian,
>
> You asked for comments on this proposal, which was presented to ITU-T
> Q14 experts in January of this year.
>
> There are so many issues involved in moving a connection from the
> management plane to the control plane that involve intensive
> management action, that it is not evident that signaling need be
> involved at all.
>
> As a personal opinion, it makes little sense to consider moving the
> connection. It makes more sense to replace the connection with one set
> up via the control plane, and to then delete the original
> management set
> up connection.
>
> Appended is an excerpt of the meeting report detailing some of the
> issues that need to be resolved before signaling need be considered.
>
> Regards
>
>            George
>
> Excerpt of the meeting report of Q14 Experts, January 2005
>
> WD06 (Marconi) "G.7713 Modification in order to support Circuit
> Migration" contains a modified version of draft G.7713 Revision as was
> presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This
> contribution addresses SP24 (PC ? SPC) of G.7713. It proposes
> to extend
> the concept of Call/Connection setup to setup/adopt and release to
> release/de-adopt. In Connection Adoption both the SNC are not
> actually
> created and the LC are not actually established due to the
> fact that the
> underlying physical resources are already in place. In the
> Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated,
> only the Control Plane information associated with then is
> removed and
> the ownership is moved to Management Plane. Attributes for indicating
> Adoption/Dis-adoption are proposed for the INNI Connection messages.
>
> The discussion was mainly on the Management plane and Control plane
> actions required before signalling is involved. The group noted that
> the following issues need to be addressed:
>
> - Naming of transport resources to the control plane.  Before a call
> can be placed under signalling control, links that are involved in the
> connection need to be given control plane names.  Without these, no
> explicit route can be formed to match the resources of the connection.
>
> - Resource state while under dual CP and MP views.  After resources
> are given control plane names, the resources are still viewed by the
> management plane.  It may be necessary to create a new state for the
> resource to indicate that the management plane cannot perform some
> actions on the connection points as the control plane is
> about to take over.
>
> - Role of discovery functions (esp. CELA).  After control plane names
> are allocated, distributed control plane functions need to be
> associated and communication adjacencies formed.  This too is a
> precursor to any signalling procedures in migrating from the MP to CP.
>
> - Similarity of migration to synchronization after CP failure and
> subsequent recovery.  Connection control procedures might be the same
> in migrating a call from the MP to the CP as the situation when
> the CP has
> failed and is recovering.  Here, the network connections are
> already in
> place, but connection and call state need to be created to match it.
> Knowledge of the call and what the connection should be is
> obtained from
> the MP for migration, and from some reliable database in the
> recovery case.
>
> - Call awareness of migration vs. connection being unaware of
> migration.
>   When connection state is being created to match an existing
> connection, the connection controllers (CCs) do not require
> awareness of
> why this is happening as the context could be migration or
> recovery.  A
> mechanism to create control state without affecting transport plane
> state is needed in the CCs.  Call controllers though do need
> migration
> awareness as they need to obtain/derive call identification
> from the MP.
>
> In summary, the group decided that it is premature to consider
> signalling procedure before the above issues, amongst other, have been
> studied. However the contribution does enable the group to
> expose in a
> larger context the interaction between CP and MP for connection
> migration. The above issues were included in SP24 of the
> G.7713 Living
> List (see WD22).
>
>
>
>

Delivery-date: Wed, 20 Jul 2005 07:16:13 +0000
Sensitivity: 
Subject: Re: Moving LSP ownership between control plane and management plane
To: [email-masked]
From: "Dino Bramanti" <[email-masked]>
Date: Wed, 20 Jul 2005 09:15:56 +0200

Thanks Adrian for commenting on proposed ID.
I do agree basically with everything you are saying in your post.
I confirm that our intention was trying to define a simple control plane
mechanism, with (very) low impact on
existing GRSVPTE procedures and message set, but still able to control the
handover of LSP ownership between planes.

In fact I agree that the definition of procedures within management plane
to be done prior to LSP signaling within control plane are quite
a complicated work, requiring probably a bigger effort.
However, the proposed handover procedure has to take place conceptually and
temporally after the information collection phase (and address translation
/ parameter mapping between management plane and control plane "language")
and it is not dependent on how this is done.
If we accept that signaling mechanism has to be involved "somehow" in a LSP
handover operation (and I think so, for the very same reasons as Adrian in
his post), then we can try to resolve the whole problem of MP/CP migration
of LSP looking separately at its different phases. The phase covering the
collection of the whole information required to signal a LSP over control
plane is outside the scope of the ID, which takes it as a starting point
for the definition of proposed mechanism. That is, we assume that MP has to
provide CP with all the information needed to format a valid GRSVPTE path
message, this being possible because the dataplane of the LSP to be handed
over is already in place and in service and visible from its current owning
plane.

dino

Thanks George,

Useful input.

> You asked for comments on this proposal, which was presented to ITU-T
> Q14 experts in January of this year.

Can you confirm that there were plenty of providers represented at the
meeting.

> There are so many issues involved in moving a connection from the
> management plane to the control plane that involve intensive management
> action, that it is not evident that signaling need be involved at all.

Interesting. It is certainly valuable to have a list of these issues out
in the open. I have made some comments in the appended meeting report.

If the control plane is to take over the connection then we assume that
signaling state must be built so that the control plane could then modify
or tear down the connection. how would you propose that this be done
without involving signaling?

> As a personal opinion, it makes little sense to consider moving the
> connection. It makes more sense to replace the connection with one set
> up via the control plane, and to then delete the original management set
> up connection.

The question arrises of how this would be done in a network with limited
resources. That is, if it is possible to set up a parallel conneciton then
the method you describe would be fine, but if there are not enough
parallel resources then would you propose that a lambda (for example)
could be used for the management-established connection and for the
control-plane-owned connection at the same time? This might present some
difficulties as well.

Do you have an opinion on my main question which is whether this tyoe of
change-over would ever be done in service?

Thanks,
Adrian

> Excerpt of the meeting report of Q14 Experts, January 2005
>
> WD06 (Marconi) "G.7713 Modification in order to support Circuit
> Migration" contains a modified version of draft G.7713 Revision as was
> presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This
> contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to extend
> the concept of Call/Connection setup to setup/adopt and release to
> release/de-adopt. In Connection Adoption both the SNC are not actually
> created and the LC are not actually established due to the fact that the
> underlying physical resources are already in place. In the
> Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated,
> only the Control Plane information associated with then is removed and
> the ownership is moved to Management Plane. Attributes for indicating
> Adoption/Dis-adoption are proposed for the INNI Connection messages.
>
> The discussion was mainly on the Management plane and Control plane
> actions required before signalling is involved. The group noted that the
> following issues need to be addressed:
>
> - Naming of transport resources to the control plane.  Before a call can
> be placed under signalling control, links that are involved in the
> connection need to be given control plane names.  Without these, no
> explicit route can be formed to match the resources of the connection.

This is pretty obvious. But actually, this is an issue with moving the
resources from one plane to another (or having them present in both
planes). It is certainly a prerequisite for moving the connection, but it
is not functionally an element of moving the connection.

The draft, as I read it, assumes that these operations have been completed
and then asks "how do I move the connection from one plane to the other?"

> - Resource state while under dual CP and MP views.  After resources are
> given control plane names, the resources are still viewed by the
> management plane.  It may be necessary to create a new state for the
> resource to indicate that the management plane cannot perform some
> actions on the connection points as the control plane is about to take
over.

Yes. There is certainly scope for a race condition here. I believe that
the I-D proposes to (try to) make the transfer an atomic action from the
point of view of the change-over.

Note, however, that it is wrong to assume that a resource belongs only to
the control or to the management plane at any moment in time. This may be
true with respect to the ability to provision/control connections, but
resources that are available for use by the control plane can still be
managed through the management plane. Thus, you take a laser out of
service through the management plane, not through the control plane.

> - Role of discovery functions (esp. CELA).  After control plane names
> are allocated, distributed control plane functions need to be associated
> and communication adjacencies formed.  This too is a precursor to any
> signalling procedures in migrating from the MP to CP.

Note to CCAMP: CELA is Control Entity Logical Adjacency.
This too is "obvious".
But this discussion seems to be wide of the mark. Before deploying a
control plane, it is clear that this type of operation needs to take
place. Since (within the context of CCAMP) a control plane *is* going to
be deployed, we can assume this operation and move on to the discussion in
the draft.

> - Similarity of migration to synchronization after CP failure and
> subsequent recovery.  Connection control procedures might be the same in
> migrating a call from the MP to the CP as the situation when the CP has
> failed and is recovering.  Here, the network connections are already in
> place, but connection and call state need to be created to match it.
> Knowledge of the call and what the connection should be is obtained from
> the MP for migration, and from some reliable database in the recovery
case.

This is a valid point.
Control plane failure, however, is unlikely to be total. That is, it would
be unusual for more than one control plane link or node to fail. Thus, in
the control plane, the "reliable database" is distributed and recovery can
follow the procedures outlined in draft-ietf-ccamp-rsvp-restart-ext-03.txt

It would certainly be worth considering whether the procedures used for
control plane recovery could be applied to transfer of ownership from the
management to control plane. at the moment, I suspect that they could not
because the restart extensions assume a specific period during which
signaling is associated with recovery.

We would also need to look at the reverse process (transfer from CP to MP)
that is not possible to cover by CP restart procedures.

> - Call awareness of migration vs. connection being unaware of migration.
>   When connection state is being created to match an existing
> connection, the connection controllers (CCs) do not require awareness of
> why this is happening as the context could be migration or recovery.  A
> mechanism to create control state without affecting transport plane
> state is needed in the CCs.  Call controllers though do need migration
> awareness as they need to obtain/derive call identification from the MP.

I disagree.
Connection controllers must be able to distinguish between resources that
are already in use and cannot be assigned to a new connection, and those
that are already in use and can be assigned to a new connection because
the connection is replacing an existing connection. If this were happening
entirely within the control plane we would use resource sharing, but when
the operation spans the control and management planes resource
ownership/sharing is more complex and the conneciotn controller needs to
be able to issue the approriate instrucitons for the assignment of the
resources.
On the other hand, call controllers do not need awareness of the details
of the realisation of the connections.

> In summary, the group decided that it is premature to consider
> signalling procedure before the above issues, amongst other, have been
> studied. However the contribution does enable the group to expose in a
> larger context the interaction between CP and MP for connection
> migration. The above issues were included in SP24 of the G.7713 Living
> List (see WD22).

Delivery-date: Wed, 20 Jul 2005 06:43:12 +0000
Content-class: urn:content-classes:message
Subject: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-01.txt 
Date: Wed, 20 Jul 2005 08:41:28 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58CF6.0EC950A5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

Here is a new revision of the MLN/MRN evaluation draft.
It takes into account comments/suggestions received on the lists.

Here are the major changes:

-Terminology MLN/MRN aligned with the requirement draft.
-Concept of "Virtual FA" removed. Replaced by "Virtual TE-link":
This requires an association between end-points so as to exchange
several parameters (interface ids...).
This may rely on extensions of the Call procedure.
-Some rewording for clarification.

Please comment on this new version,

Regards,

JL et. al.

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>=20
>=20
> 	Title		: Evaluation of existing GMPLS Protocols against
>                           Multi Layer and Multi Region Networks
> MLN/MRN)
> 	Author(s)	: J. Le Roux, et al.
> 	Filename	: draft-leroux-ccamp-gmpls-mrn-eval-01.txt
> 	Pages		: 13
> 	Date		: 2005-7-19
> =09
> This document provides an evaluation of Generalized Multi-Protocol=20
>    Label Switching (GMPLS) protocols and mechanisms against the=20
>    requirements for Multi-Layer Networks (MLN) and Multi Region
> Networks=20
>    (MRN). In addition, this document identifies areas where additional
>=20
>    protocol extensions or procedures are needed to satisfy these=20
>    requirements, and provides guidelines for potential extensions.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-
> 01.txt
>=20
> To remove yourself from the I-D Announcement list, send a message to=20
> i-d-announce-request at ietf.org with the word unsubscribe in the body
> of the message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>=20
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-leroux-ccamp-gmpls-mrn-eval-01.txt".
>=20
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html=20
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	mailserv at ietf.org.
> In the body type:
> 	"FILE
> /internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-01.txt".
> =09
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 	=09
> 	=09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-
> 01.txt>
> <ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-
> 01.txt> =20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce at ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>=20
>=20

------_=_NextPart_001_01C58CF6.0EC950A5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-01.txt </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hi all,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Here is a new =
revision of the MLN/MRN evaluation draft.</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">It takes into =
account comments/suggestions received on the lists.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Here are the major =
changes:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">-Terminology MLN/MRN =
aligned with the requirement draft.</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">-Concept of =
&quot;Virtual FA&quot; removed. Replaced by &quot;Virtual =
TE-link&quot;:</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">This requires an =
association between end-points so as to exchange several parameters =
(interface ids&#8230;).</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">This may rely on =
extensions of the Call procedure.</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">-Some rewording for =
clarification.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Please comment on =
this new version,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">JL et. al.</FONT>
</P>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Courier New">A New Internet-Draft is available =
from the on-line Internet-Drafts directories.</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Title&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Evaluation of existing =
GMPLS Protocols against</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; Multi Layer and Multi Region Networks MLN/MRN)</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : J. =
Le Roux, et al.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
: draft-leroux-ccamp-gmpls-mrn-eval-01.txt</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Pages&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 13</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2005-7-19</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20

<BR><FONT SIZE=3D2 FACE=3D"Courier New">This document provides an =
evaluation of Generalized Multi-Protocol </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; Label Switching =
(GMPLS) protocols and mechanisms against the </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; requirements for =
Multi-Layer Networks (MLN) and Multi Region Networks </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; (MRN). In addition, =
this document identifies areas where additional </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; protocol extensions =
or procedures are needed to satisfy these </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; requirements, and =
provides guidelines for potential extensions.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">A URL for this Internet-Draft =
is:</FONT>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-=
eval-01.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://www.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eva=
l-01.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">To remove yourself from the I-D =
Announcement list, send a message to </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">i-d-announce-request at ietf.org =
with the word unsubscribe in the body of the message.&nbsp; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">You can also visit </FONT><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/I-D-announce"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">https://www1.ietf.org/mailman/listinfo/I-D-announce</FONT></U></A><F=
ONT SIZE=3D2 FACE=3D"Courier New"> </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">to change your subscription =
settings.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Internet-Drafts are also =
available by anonymous FTP. Login with the username</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&quot;anonymous&quot; and a =
password of your e-mail address. After logging in,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">type &quot;cd =
internet-drafts&quot; and then</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">&quot;get =
draft-leroux-ccamp-gmpls-mrn-eval-01.txt&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">A list of Internet-Drafts =
directories can be found in</FONT>

<BR><A HREF=3D"http://www.ietf.org/shadow.html"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://www.ietf.org/shadow.html</FONT></U></A><FONT SIZE=3D2 =
FACE=3D"Courier New"> </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">or </FONT><A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</FONT></U></A>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Internet-Drafts can also be =
obtained by e-mail.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Send a message to:</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">mailserv at ietf.org.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">In the body type:</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">&quot;FILE =
/internet-drafts/draft-leroux-ccamp-gmpls-mrn-eval-01.txt&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20

<BR><FONT SIZE=3D2 FACE=3D"Courier New">NOTE:&nbsp;&nbsp; The mail =
server at ietf.org can return the document in</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">MIME-encoded form by using the &quot;mpack&quot; =
utility.&nbsp; To use this</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">feature, insert the command &quot;ENCODING =
mime&quot; before the &quot;FILE&quot;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">command.&nbsp; To decode the response(s), you will =
need &quot;munpack&quot; or</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">a MIME-compliant mail reader.&nbsp; Different =
MIME-compliant mail readers</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">exhibit different behavior, especially when dealing =
with</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">&quot;multipart&quot; MIME messages (i.e. documents =
which have been split</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">up into multiple messages), so check your local =
documentation on</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">how to manipulate these messages.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Below is the data which will =
enable a MIME compliant mail reader</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">implementation to automatically =
retrieve the ASCII version of the</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Internet-Draft.</FONT>

<BR><A =
HREF=3D"ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mrn-e=
val-01.txt"><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New =
Roman">&lt;ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-gmpls-mr=
n-eval-01.txt&gt;</FONT></U></A><FONT FACE=3D"Times New Roman"> </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">_______________________________________________</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">I-D-Announce mailing list</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">I-D-Announce at ietf.org</FONT>

<BR><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/i-d-announce"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">https://www1.ietf.org/mailman/listinfo/i-d-announce</FONT></U></A>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C58CF6.0EC950A5--

Delivery-date: Wed, 20 Jul 2005 01:50:45 +0000
Date: Wed, 20 Jul 2005 10:50:51 +0900
From: Tomohiro Otani <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-00

Hi Dimitri,

Ok, I understand what you said. We need more feedback about this.

Regards,

tomo

[email-masked] wrote:

>hi,
>
>i would say that 1) should be considered iff there have been several identified 
>misbehaviour detected and inconsistencies observed such that a set of 
>prescriptive guidelines have to be put together (but this would translate some 
>"common" mis-interpretation of the set of documents we currently have)
>
>if this is not the case, then beside some base description/clarification, i 
>don't see how we could turn this into 2) or 3) without obtaining a larger sample 
>of CSPF/routing practices - the difference between 2) and 3) being that in the 
>former case, information gathered is processed to describe practices and devise 
>operational guidelines while in the latter the document appears as a collection 
>of practices from individual practices
>
>in any case, and in order to progress - we need more feedback -
>
> 
>
>thanks,
>
>-dimitri.
>
>
>*Tomohiro Otani <[email-masked]>*
>Sent by: [email-masked]
>07/19/2005 09:48 ZE9
>
>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>cc: [email-masked]
>bcc:
>Subject: Re: 
>http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-00
>
>
>Hi Dimitri,
>
>Per our initial discussion, we would like to formulate
>the unified view on CSPF consideration, and we simply
>thought it is BCP.
>
>Considering more deeply, our draft does not define the
>protocol itself but the protocol related specification
>
>In that sense, you are right, it is prescriptive more
>than descriptive for guiding operations. Moreover, I came
>up my mind that it may be more standard track than informational.
>But I am not sure. What's your thought on this ?
>
>With best regards,
>
>tomo
>
>PS: We posted 01 version.
>
>
>
>
>[email-masked] wrote:
>
> >authors, is the purpose of the above mentioned draft:
> >
> > 1. prescriptive (even if informational)
> >
> > 2. descriptive for guiding operations (BCP)
> >
> > 3. informative (survey-like)
> >
> >from what i read, it is more 1 like - is my understanding correct ?
> >
> >
> >
>
>  
>

Delivery-date: Wed, 20 Jul 2005 00:22:29 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Tue, 19 Jul 2005 19:19:50 -0500
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Cc: "Kireeti Kompella" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>, "Scott Bradner" <[email-masked]>

Hello Adrian,

I have provided some clarification of the assumptions in-line below,
which may be helpful in determining whether the CCAMP comments are
appropriate.

Regards,
Ben

> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Tuesday, July 19, 2005 6:59 AM
> To: [email-masked]
> Cc: 'Kireeti Kompella'; [email-masked]; Bill Fenner; Scott Bradner
> Subject: Proposed response to ITU-T SG15 Questions 12 and 14=20
> on ASON Lexicography
>=20
> Hi,
>=20
> Please comment on this draft response liaison which I intend=20
> to send on
> Monday 25th July.
> You can see the original incoming liaison at
> http://www.olddog.co.uk/incoming.htm
>=20
> Thanks,
> Adrian
> =3D=3D=3D=3D=3D
> To: ITU-T SG15 Questions 12 and 14
> From: IETF CCAMP Working Group
> Subject: Response to your liaison on GMPLS/ASON Lexicography
> For: Action
> Deadline: August 31st 2005
>=20
> The CCAMP Working Group would like to thank SG15 and=20
> especially Questions
> 12 and 14 for the time and effort they put into providing input and
> feedback on the GMPLS/ASON lexicography Internet-Draft that is being
> developed by CCAMP. Much of the material supplied as direct=20
> comments or as
> mark-ups to the Internet-Draft has been incorporated into the latest
> revision which is available at
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-aso
> n-lexicography-03.txt
>=20
> In your liaison you state some assumptions which we would=20
> like to comment
> on as follows.
>=20
> - The purpose of the document is to enable those familiar with ASON
>   to understand GMPLS terminology in an ASON context
>=20
> Correct.
>=20
> - GMPLS terms are described informally in the document in a way that
>   is generally consistent with GMPLS (existing RFCs and work=20
> in progress)
>=20
> While the definition of GMPLS terms would be helpful for understanding
> GMPLS terms in a GMPLS context, that is not the purpose of=20
> this document.

This assumption is intended to convey that the descriptions in this
draft
are not definitional (authoritative), but that they can be used as a
basis
for the ASON interpretation (since concise defintions of GMPLS terms are
not available, in part due to the fact that some GMPLS terms in the Lex
draft are not yet used in GMPLS RFCs or internet drafts).

It was not intended to convey anything about their use in a GMPLS
context.

>=20
> - Based on these descriptions, interpretations of these GMPLS terms
>   in ASON terminology are provided
>=20
> It is intended that the interpretation of the GMPLS terms is=20
> not based on
> these descriptions, but based on the full meaning of the=20
> GMPLS terms. The
> descriptions of the GMPLS terms are provided in this=20
> Internet-Draft for
> context and a brief summary.

This presents a difficult problem.  It is not feasible for the ITU
experts to review the ASON interpretations without some basis.
If the intended basis is existing GMPLS RFCs and drafts, a proper
review would require reading and understanding all the uses
of GMPLS terms in those documents.  I have attempted this, for
the normative references, and I believe it is unreasonable to expect
this to be an effective method of review.  For example, as noted
above, some terms in the Lex draft are not used in the normative
references.  In other cases, terms are not used consistently and
it would be difficult for reviewers to determine which uses are
"correct."  As a result, a review on this basis may not be feasible
given the time available to ITU experts.

This assumption was included to make the review process tractable.
The ITU experts provided comments based on the descriptions
of GMPLS terms in the Lex draft.  If this is not what CCAMP is
expecting, some clarification of the expectations would be helpful.

>=20
> - CCAMP has primarily responsibility for the descriptions of=20
> GMPLS terms
>=20
> Correct.
>=20
> - Q12/15 has responsibility to provide input to the GMPLS-ASON
>   interpretations (based on the descriptions in this draft)
>=20
> We welcome this assumption of responsibility by Q12/15 to=20
> provide input to
> the Internet-Draft. While the Internet-Draft remains under the overall
> editorial control of the CCAMP working group, we hope to be=20
> able to use
> the text supplied by Q12/15 with only editorial changes.

This is the understanding of SG15 as well (that SG15 would provide
comments, not finished text).  The comments were provided in the
liaison as edited text as a convenience, not intended as final text.

>=20
>=20
Snip...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Delivery-date: Tue, 19 Jul 2005 23:21:53 +0000
Date: Tue, 19 Jul 2005 16:21:30 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: Igor Bryskin <[email-masked]>
cc: [email-masked]
Subject: LSP stitching questions for discussion

Hi,

Here are some of the questions related to LSP stitching to start a
discussion on the usage of LSP stitching.

1) Are the control plane signaling procedures for LSP stitching as
   described in this ID, (explicit request for LSP stitching on
   LSP segment, different label allocation rules; etc) REQUIRED to stitch
   packet LSPs in data plane ?

2) Are the control plane signaling procedures for LSP stitching as
   described in this ID, (explicit request for LSP stitching on
   LSP segment, different label allocation rules; etc) REQUIRED to stitch
   non-packet LSPs in data plane ?

3) If an e2e LSP crosses a region boundary (based on different TE
   link switching capabilities), then can I use LSP stitching -
   a) control plane procedures for packet LSPs
   b) data plane procedures for packet LSPs
   c) control plane procedures for non-packet LSPs
   d) data plane procedures for non-packet LSPs

4) If the switching type of an e2e LSP is different from that of an LSP
   segment, can I use LSP stitching -
   a) control plane procedures for packet LSPs
   b) data plane procedures for packet LSPs
   c) control plane procedures for non-packet LSPs
   d) data plane procedures for non-packet LSPs

Note that although 3) and 4) appear to be the same, the reason I have
them as different questions is that in one case the TE link switching
capability is examined and in the other case the Generalized Label Request
is examined.

thanks,
-arthi

Delivery-date: Tue, 19 Jul 2005 23:08:22 +0000
Date: Tue, 19 Jul 2005 16:07:49 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: Igor Bryskin <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 

Hi Igor,

> One more comment. I think the draft should give a clear and unambiguous
> answer to how e2e LSP and a stitching LSP (S-LSP) relate from the switching
> capability point of view. Specifically, should they belong to the same
> network layer, should they share the same switching type or maybe there are
> no limitations at all, and you can stitch your e2e LSP pretty much with
> anything you got, provided that this "anything" has enough bandwidth.
>
> Let me give you a specific example. Is it possible to stitch a PSC1 e2e LSP
> with a PSC2 S-LSP? You probably remember our discussion with Kireeti in
> Minneapolis (and you were also part of it), and he said (and I 100% agree
> with him) that although it is doable (you can do anything you want with the
> label stack), it is not right and this should be logically prohibited. What
> you should do in this case is to nest the e2e LSP within the PSC2 LSP (that
> is, use it as H-LSP) even in case it consumes the entire PSC2 LSP bandwidth.
<AA>---> I do remember this discussion.

> It is more clear in non-PSC cases. Although it is possible to "stitch" an
> e2e VC12 LSP with a VC4 S-LSP, I could not imagine that a network operator
> would ever agree with such solution. He is likely to say " What ?  If the
> service is supposed to stay for 12 month, than for entire year I pretty much
> burry my 62 VC12 channels - I cannot use them even conceptually in case
> when, say, on the next day I'll have to provide another 62 VC12 services
> that could've used these wasted resources"
>
> On the other hand I know plenty GMPLS people who would say: "Sure, no
> problem. Of course we can stitch a PSC e2e LSP with lambda S-LSP:  If
> somebody wants to do a trick stupid as it is, why should we prevent him from
> doing so?"
<AA>----> I know some of these people too. :-)

> The bottom line is that a discussion like this in the draft and consensus
> on how we see the stitching IMO would be extremely valuable for the GMPLS
> multi-layer story, and I don't see a reason why this could not be achieved
> in the frame of this work.
<AA>------> I agree that we should have a discussion on this, but I would
like folks to have this discussion on the list first, which I thank
you for initiating.

Yes, the draft has to state clearly whether LSP stitching between
different switching capabilities is allowed or not. But it's more than
that. Currently, the draft talks about this under sections 3.1 and 4.1
and 4.1.2.

But, let us have this discussion on the list and we will be glad to add
what's missing (with required details) to the ID, depending on the
consensus reached. I will send out the questions to start the discussion
in the next email.

thanks,
-arthi

>
> ----- Original Message -----
> From: "Arthi Ayyangar" <[email-masked]>
> To: "Igor Bryskin" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> Sent: Monday, July 18, 2005 2:51 PM
> Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
>
>
> > Hi Igor,
> >
> > Please see inline.
> >
> > > 1. Why are saying that LSP Stitching is a private case of LSP Hierarchy?
> >
> > > there is more differences than similarities:
> > > The differences are:
> > > 1) In case of H-LSP there is a data plane adjacency, while in case of
> S-LSP
> > > there is none (as you correctly pointed out);
> > > 2) In case of H-LSP there is an adaptation in data plane (label push/pop
> for
> > > PSC), while in case of S-LSP there is none - just simple
> cross-connecting
> > > ( label swap) as in case of two "native " e2e LSP adjacent segments ;
> > > 3) H-LSP could be used by many e2e LSPs, while S-LSP could be used by
> > > exactly one e2e LSP
> > > 4) Signaling is different - there is no label negotiation in stitching
> > > 5) H-LSP is used as a "true" data link, specifically there is a resource
> > > allocation on the H-LSP edges, while in case of S-LSP there is none
> > > 6) From MLN point of view, H-LSP is created in a server (lower) layer,
> while
> > > the S-LSP is created in the client (same as e2e LSP) layer.
> > >
> > > There are two similarities that I can think of:
> > > 1) There is a signaling and possibly routing (see below) adjacencies
> between
> > > the ends;
> > > 2) Both H-LSP and S-LSP could be advertised as separate TE links or as
> TE
> > > bundles
> > >
> > > I would recommend to dedicate a paragraph and enlist there similarities
> and
> > > differencies
> > -------> Based on the discussions on the list over the last revision, the
> > message that the authors received was that we do not want to go about such
> > a lengthy discussion of similarities and differences (NOTE that the draft
> > already does clearly highlight them where applicable). Instead we want
> > this ID to simply explain how LSP stitching functions. In other words the
> > idea was to make this ID a complete document by itself. But since it does
> > borrow concepts from the LSP hierarchy ID, just state the concepts that
> > are applicable or inapplicable.
> >
> > > 2. Why are you saying that a TE Link based on S-LSP can be used for
> exactly
> > > one e2e LSP? Parallel S-LSPs could be advertised as a single TE link
> > > (bundle, see above) and hence can accomadate several e2e LSPs.
> > ----> Igor, the draft does talk about this Bundling case.
> >
> > > 3. You are saying that S-LSP does not have a routing peering. Actually,
> in
> > > this respect it is no different from H-LSP: if it is advertised as a TE
> link
> > > into the same TE domain  that was used for S-LSP creation (unlikely IMO
> > > scenario) than it does not require the routing adjacency (in other
> words, it
> > > is an FA according to LSP-HIER definition), otherwise, it IS  NOT and FA
> and
> > > does require the direct routing peering in the domain it is advertised
> to
> > > make it useful as a TE link in this domain
> > -----> I am sorry, but I am missing your point here completely. Are you
> > saying that the statement "the end points of an LSP segment do not have a
> > routing adjacency", is incorrect  or are you saying that "this is
> > obvious" ? It is unclear to me  what exactly your argument is. Please
> > clarify.
> >
> > thanks,
> > -arthi
> >
> > >
> > > Cheers,
> > > Igor
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: <[email-masked]>
> > > To: <[email-masked]>
> > > Cc: <[email-masked]>
> > > Sent: Friday, July 15, 2005 3:50 PM
> > > Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
> > >
> > >
> > > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > > > This draft is a work item of the Common Control and Measurement Plane
> > > Working Group of the IETF.
> > > >
> > > > Title : Label Switched Path Stitching with Generalized MPLS Traffic
> > > Engineering
> > > > Author(s) : A. Ayyangar, J. Vasseur
> > > > Filename : draft-ietf-ccamp-lsp-stitching-01.txt
> > > > Pages : 19
> > > > Date : 2005-7-15
> > > >
> > > > In certain scenarios, there may be a need to combine together two
> > > >    different Generalized Multi-Protocol Label Switching (GMPLS) Label
> > > >    Switched Paths (LSPs) such that in the data plane, a single end-to-
> > > >    end (e2e) LSP is achieved and all traffic from one LSP is switched
> > > >    onto the other LSP.  We will refer to this as "LSP stitching".
> This
> > > >    document covers cases where: a) the node performing the stitching
> > > >    does not require configuration of every LSP pair to be stitched
> > > >    together b) the node performing the stitching is not the egress of
> > > >    any of the LSPs c) LSP stitching not only results in an end-to-end
> > > >    LSP in the data plane, but there is also a corresponding end-to-end
> > > >    LSP (RSVP session) in the control plane.  It might be possible to
> > > >    configure a GMPLS node to switch the traffic from an LSP for which
> it
> > > >    is the egress, to another LSP for which it is the ingress, without
> > > >    requiring any signaling or routing extensions whatsoever,
> completely
> > > >    transparent to other nodes.  This will also result in LSP stitching
> > > >    in the data plane.  However, this document does not cover this
> > > >    scenario of LSP stitching.
> > > >
> > > > A URL for this Internet-Draft is:
> > > >
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt
> > > >
> > > > To remove yourself from the I-D Announcement list, send a message to
> > > > [email-masked] with the word unsubscribe in the body of
> the
> > > message.
> > > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > > to change your subscription settings.
> > > >
> > > >
> > > > Internet-Drafts are also available by anonymous FTP. Login with the
> > > username
> > > > "anonymous" and a password of your e-mail address. After logging in,
> > > > type "cd internet-drafts" and then
> > > > "get draft-ietf-ccamp-lsp-stitching-01.txt".
> > > >
> > > > A list of Internet-Drafts directories can be found in
> > > > http://www.ietf.org/shadow.html
> > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > >
> > > > Internet-Drafts can also be obtained by e-mail.
> > > >
> > > > Send a message to:
> > > > [email-masked].
> > > > In the body type:
> > > > "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
> > > >
> > > > NOTE: The mail server at ietf.org can return the document in
> > > > MIME-encoded form by using the "mpack" utility.  To use this
> > > > feature, insert the command "ENCODING mime" before the "FILE"
> > > > command.  To decode the response(s), you will need "munpack" or
> > > > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > > > exhibit different behavior, especially when dealing with
> > > > "multipart" MIME messages (i.e. documents which have been split
> > > > up into multiple messages), so check your local documentation on
> > > > how to manipulate these messages.
> > > >
> > > >
> > > > Below is the data which will enable a MIME compliant mail reader
> > > > implementation to automatically retrieve the ASCII version of the
> > > > Internet-Draft.
> > > >
> > >
> >
>

Delivery-date: Tue, 19 Jul 2005 22:57:31 +0000
To: Tomohiro Otani <[email-masked]>
Cc: [email-masked], [email-masked]
From: [email-masked]
Subject: Re: http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-00
Date: Wed, 20 Jul 2005 00:56:09 +0200

Delivery-date: Tue, 19 Jul 2005 21:37:52 +0000
Content-class: urn:content-classes:message
Subject: RE: Moving LSP ownership between control plane and management plane
Date: Tue, 19 Jul 2005 22:36:27 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi George....nice to hear from you...hope all is well with you,

This all sounds very reasonable to me.  At the end of the day, all a
signalling protocol is is a distributed agent of network
management.....in the types of large BW granularity networks being
discussed the NMS will always be king.   Sorry if that's a problem to
some folks, its just a fact for the way we see/implement it.

This also follows from a good understanding of the commercials at play
here.  That is, there is a major difference between:
-	a public service context (cf PSTN), or extending a similar
capability out to end-systems in the co-ps mode say, where
end-systems/applications drive trail set-up (ie SVCs across a UNI).
Here one hopes there could be a large population of users (think
peer-peer/BB) and that the trail holding-times are not 'too long'.  In
this environment there could be a viable business case based on a
providing a given GoS at some cost.....and it might solve some
(otherwise) hard QoS/pricing problems for operators....but I digress;
-	a private network builder service context where one is a
providing a (relatively long time-constant) traffic-engineering function
to a higher layer network, ie creating its topology.  This is a
client/server relationship and THE starting point for this must be
functional decoupling of the client and server layer networks because
they will often be owned by different parties.  We are talking
relatively long forecast/planning cycles here and long trail holding
times....esp when it comes to real physical build.  Further, the
potential population is rather small compared to the previous case.  If
folks look at whether there is a viable business case here based on a
providing a given GoS at some cost in an acceptable time period I
suspect they will be disappointed.

What this all means is that the control-plane is not such an important
topic as we move down the layered network stack towards the
duct....increasingly other factors like strong NMS and OAM assume a far
greater importance.  This is not to say a control-plane is not useful
but:
-	we should be clear there cannot be any common addressing and
routing functions across a set of nested layer networks, which is very
obvious when different parties own different layer networks....one can
(and should) re-use components (if they are the right ones), but they
will need to operate in different layer network spaces
-	signalling is a useful agent for functions like S-PVCs and
resilience.

Well that's our analysis anyway....if anyone knows different I'd be
happy to review their commercial assumptions with folks here.

regards, Neil

> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of George Newsome
> Sent: 19 July 2005 12:44
> To: Adrian Farrel
> Cc: [email-masked]
> Subject: Re: Moving LSP ownership between control plane and
> management plane
>=20
>=20
> Adrian,
>=20
> You asked for comments on this proposal, which was presented to ITU-T=20
> Q14 experts in January of this year.
>=20
> There are so many issues involved in moving a connection from the=20
> management plane to the control plane that involve intensive=20
> management action, that it is not evident that signaling need be=20
> involved at all.
>=20
> As a personal opinion, it makes little sense to consider moving the=20
> connection. It makes more sense to replace the connection with one set
> up via the control plane, and to then delete the original=20
> management set=20
> up connection.
>=20
> Appended is an excerpt of the meeting report detailing some of the=20
> issues that need to be resolved before signaling need be considered.
>=20
> Regards
>=20
> 	George
>=20
> Excerpt of the meeting report of Q14 Experts, January 2005
>=20
> WD06 (Marconi) "G.7713 Modification in order to support Circuit=20
> Migration" contains a modified version of draft G.7713 Revision as was
> presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This=20
> contribution addresses SP24 (PC ? SPC) of G.7713. It proposes=20
> to extend=20
> the concept of Call/Connection setup to setup/adopt and release to=20
> release/de-adopt. In Connection Adoption both the SNC are not=20
> actually=20
> created and the LC are not actually established due to the=20
> fact that the=20
> underlying physical resources are already in place. In the=20
> Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated,=20
> only the Control Plane information associated with then is=20
> removed and=20
> the ownership is moved to Management Plane. Attributes for indicating=20
> Adoption/Dis-adoption are proposed for the INNI Connection messages.
>=20
> The discussion was mainly on the Management plane and Control plane=20
> actions required before signalling is involved. The group noted that=20
> the following issues need to be addressed:
>=20
> - Naming of transport resources to the control plane.  Before a call=20
> can be placed under signalling control, links that are involved in the
> connection need to be given control plane names.  Without these, no=20
> explicit route can be formed to match the resources of the connection.
>=20
> - Resource state while under dual CP and MP views.  After resources=20
> are given control plane names, the resources are still viewed by the
> management plane.  It may be necessary to create a new state for the=20
> resource to indicate that the management plane cannot perform some=20
> actions on the connection points as the control plane is=20
> about to take over.
>=20
> - Role of discovery functions (esp. CELA).  After control plane names=20
> are allocated, distributed control plane functions need to be=20
> associated and communication adjacencies formed.  This too is a=20
> precursor to any signalling procedures in migrating from the MP to CP.
>=20
> - Similarity of migration to synchronization after CP failure and=20
> subsequent recovery.  Connection control procedures might be the same=20
> in migrating a call from the MP to the CP as the situation when
> the CP has=20
> failed and is recovering.  Here, the network connections are=20
> already in=20
> place, but connection and call state need to be created to match it.=20
> Knowledge of the call and what the connection should be is=20
> obtained from=20
> the MP for migration, and from some reliable database in the=20
> recovery case.
>=20
> - Call awareness of migration vs. connection being unaware of=20
> migration.
>   When connection state is being created to match an existing
> connection, the connection controllers (CCs) do not require=20
> awareness of=20
> why this is happening as the context could be migration or=20
> recovery.  A=20
> mechanism to create control state without affecting transport plane=20
> state is needed in the CCs.  Call controllers though do need=20
> migration=20
> awareness as they need to obtain/derive call identification=20
> from the MP.
>=20
> In summary, the group decided that it is premature to consider=20
> signalling procedure before the above issues, amongst other, have been
> studied. However the contribution does enable the group to=20
> expose in a=20
> larger context the interaction between CP and MP for connection=20
> migration. The above issues were included in SP24 of the=20
> G.7713 Living=20
> List (see WD22).
>=20
>=20
>=20
>=20

Delivery-date: Tue, 19 Jul 2005 19:51:04 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-04.txt 
Date: Tue, 19 Jul 2005 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Exclude Routes - Extension to RSVP-TE
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-rsvp-te-exclude-route-04.txt
	Pages		: 34
	Date		: 2005-7-19
	
The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
   Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
   Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
   Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
   abstract nodes and resources to be explicitly included in a path
   setup, but not to be explicitly excluded.

   In some networks where precise explicit paths are not computed at the
   head end it may be useful to specify and signal abstract nodes and
   resources that are to be explicitly excluded from routes.  These
   exclusions may apply to the whole path, or to parts of a path between
   two abstract nodes specified in an explicit path.  How Shared Risk
   Link Groups (SLRGs) can be excluded is also specified in this
   document.

   This document specifies ways to communicate route exclusions during
   path setup using RSVP-TE.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-rsvp-te-exclude-route-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-rsvp-te-exclude-route-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 19 Jul 2005 19:50:56 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-01.txt 
Date: Tue, 19 Jul 2005 15:50:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Inter domain GMPLS Traffic Engineering - RSVP-TE extensions
	Author(s)	: A. Ayyangar, J. Vasseur
	Filename	: draft-ietf-ccamp-inter-domain-rsvp-te-01.txt
	Pages		: 17
	Date		: 2005-7-19
	
This document describes extensions to Generalized Multi-Protocol Label
Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering
(RSVP-TE) signaling required to support mechanisms for the establishment
and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths
(LSPs), both packet and non-packet, that traverse multiple domains. For
the purpose of this document, a domain is considered to be any
collection of network elements within a common realm of address space or
path computation responsibility. Examples of such domains include
Autonomous Systems, IGP areas and GMPLS overlay networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-inter-domain-rsvp-te-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-rsvp-te-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 19 Jul 2005 19:31:44 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Tue, 19 Jul 2005 15:30:44 -0400
From: "Scott Brim \(sbrim\)" <[email-masked]>
To: <[email-masked]>

On Tuesday, July 19, 2005 06:59 AM, Adrian Farrel allegedly wrote:

> While the definition of GMPLS terms would be helpful for
> understanding GMPLS terms in a GMPLS context, that is not the
> purpose of this document. =20

It would be polite to tell them where to find the definions :-)

Delivery-date: Tue, 19 Jul 2005 19:21:18 +0000
Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Tue, 19 Jul 2005 20:18:16 +0200

Adrian

I think it should be
"
 - CCAMP has primary responsibility for the descriptions of GMPLS terms

 Correct "

even if that is not what SG15 said.

Primarily (sic) CCAMP has responsibility for the specification of GMPLS, not
just its terms:-)

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>; <[email-masked]>; "Bill Fenner"
<[email-masked]>; "Scott Bradner" <[email-masked]>
Sent: Tuesday, July 19, 2005 1:59 PM
Subject: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON
Lexicography

> Hi,
>
> Please comment on this draft response liaison which I intend to send on
> Monday 25th July.
> You can see the original incoming liaison at
> http://www.olddog.co.uk/incoming.htm
>
> Thanks,
> Adrian
> =====
> To: ITU-T SG15 Questions 12 and 14
> From: IETF CCAMP Working Group
> Subject: Response to your liaison on GMPLS/ASON Lexicography
> For: Action
> Deadline: August 31st 2005
>
> The CCAMP Working Group would like to thank SG15 and especially Questions
> 12 and 14 for the time and effort they put into providing input and
> feedback on the GMPLS/ASON lexicography Internet-Draft that is being
> developed by CCAMP. Much of the material supplied as direct comments or as
> mark-ups to the Internet-Draft has been incorporated into the latest
> revision which is available at
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-03.
txt
>
> In your liaison you state some assumptions which we would like to comment
> on as follows.
>
> - The purpose of the document is to enable those familiar with ASON
>   to understand GMPLS terminology in an ASON context
>
> Correct.
>
> - GMPLS terms are described informally in the document in a way that
>   is generally consistent with GMPLS (existing RFCs and work in progress)
>
> While the definition of GMPLS terms would be helpful for understanding
> GMPLS terms in a GMPLS context, that is not the purpose of this document.
>
> - Based on these descriptions, interpretations of these GMPLS terms
>   in ASON terminology are provided
>
> It is intended that the interpretation of the GMPLS terms is not based on
> these descriptions, but based on the full meaning of the GMPLS terms. The
> descriptions of the GMPLS terms are provided in this Internet-Draft for
> context and a brief summary.
>
> - CCAMP has primarily responsibility for the descriptions of GMPLS terms
>
> Correct.
>
> - Q12/15 has responsibility to provide input to the GMPLS-ASON
>   interpretations (based on the descriptions in this draft)
>
> We welcome this assumption of responsibility by Q12/15 to provide input to
> the Internet-Draft. While the Internet-Draft remains under the overall
> editorial control of the CCAMP working group, we hope to be able to use
> the text supplied by Q12/15 with only editorial changes.
>
>
> Additionally, we welcome the pledge to continue work on this
> Internet-Draft through correspondence on the Q12/15 mailing list, and
> thank Q12/15 for assigning Ben Mack-Crane as the SG15 representative on
> this matter. Ben has proved very helpful in clarifying and developing
> comments received from SG15.
>
>
> We have had several email exchanges with Ben about a few of the specific
> comments made in your review of the 02 revision of the Internet-Draft.
> Although he has taken these comments to the Q12/15 mailing list no
> response has been received, perhaps due to pressure of time. We are taking
> the opportunity to restate several questions here for your convenience and
> would appreciate your answers as part of the response to this liaison.
>
> 1. Definition of a Resource (section 3.2)
>    You have supplied us with the simple text that says...
>      In ASON applications:
>      A resource refers only to a link connection (e.g. VC-11,
>      VC-4 etc.).
>
>    We would like to clarify this because we don't understand how
>    the original text is wrong. It used to say...
>      ITU-T [should be ASON] terms for resource:
>      - Connection point (cp) in the context of link discovery
>        and resource management (allocation, binding into
>        cross-connects, etc.);
>      - Link connection or trail termination in the context of
>        routing, path computation and signaling.
>
>    Recall that we are talking about the ASON terms for what GMPLS
>    calls a resource. We think the following...
>    In ASON a link connection is an association of output cp on one
>    side of the link and input cp on the other side of the link. In
>    GMPLS by resource we mean in most of the cases the local end of
>    the resource (which is cp in ASON terminology). This is true in
>    the context of link discovery.
>
>    More importantly, this is also true in the context of a
>    signaling application. Specifically, when a GMPLS signaling
>    sub-system requests allocation of a resource, the GMPLS
>    Resource Manager allocates only the local end of the
>    resource. This happens on both sides of the link, that is, we
>    allocate input and output resources. This contrasts with ASON,
>    where there is a much more versatile LRM, and the connection
>    manager (signaling application) allocates link connections
>    only on the output side, leaving LRM to coordinate the
>    allocation with the neighbor.
>
>    However, in GMPLS TE advertisements we account only for
>    outgoing resources, that is, we don't advertise incoming
>    resources on the assumption that they match the outgoing
>    resources for the discovered TE links.
>
>    Bottom line: we believe that we should retain the previous
>    definitions, and have not made this change in the new
>    revision. We would like to discuss this point further with
>    Q12/15.
>
> 2. Link ends and Data links (Section 3.5 - was section 3.4)
>
> 2a.Although we understand that ASON does not require the concept
>    of a link end, GMPLS does. Therefore we should provide some
>    form of language to help people do the mapping.
>
>    The proposed new text from Q12/15 removes all reference to
>    link ends from the ASON section, and we feel this is a
>    mistake and propose the following text:
>      In ASON, a GMPLS unidirectional data link end is a
>      collection of connection points from the same client
>      layer that are supported by a single trail termination
>      (access point).
>
>    This text depends on the fact that a link end is described as
>    a set of resources that transfer traffic to a neighbor.
>
> 2b.The new text from Q12/15 gives us...
>      A GMPLS data link is an ASON link supported by a single
>      server trail.
>
>    We are not sure that we understand this correctly. It
>    appears to say that a unidirectional data link could be
>    supported by multiple trail terminations (access points).
>    This seems to suggest that a client would have to make a
>    choice about where to send data, which seems to imply it
>    really has to choose between data links! We are confused!
>
>    We think some of this problem may come from the *need* in
>    GMPLS to identify data link ends. There may be some value in
>    stressing that a GMPLS link end is supported by exactly one
>    trail termination. When several trail terminations are
>    involved, we can still talk about single TE link (as a
>    bundle), but each component link will be a distinct data
>    link. We think that in ASON the SNPP (TE link in GMPLS
>    language) could be supported by multiple terminations.
>
> 3. Link interfaces (section 3.6 - was 3.5)
>    The new text from Q12/15 gives us...
>      A GMPLS interface is "all the stuff between a physical
>      interface and a matrix in an ASON network element." More
>      precisely, it is a trail termination function and adaptation
>      function for which adapted client layer connection points
>      are bound to a matrix.
>
>    We think "physical interface" may be ambiguous in the multi-
>    layer context. We think the "stuff" should be between a link
>    and a matrix, since we are talking about links in distinct
>    layers.
>
>
> In addition to your feedback on the specific points above, we would
> welcome your continued comments and review of the Internet-Draft.
>
> Regards,
> Adrian Farrel and Kireeti Kompella
> IETF CCAMP Working Group Co-chairs
>
>

Delivery-date: Tue, 19 Jul 2005 18:43:29 +0000
Date: Tue, 19 Jul 2005 11:41:39 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: Adrian Farrel <[email-masked]>
cc: [email-masked], Igor Bryskin <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

> Say rather, "can be admitted over a TE link supported by LSP segments".
> That is, a segment can only admit one LSP, but a bundle of segments
> advertised as a TE link, can admit multiple LSPs.
-----> Yes, this more accurate.

thanks,
-arthi

Delivery-date: Tue, 19 Jul 2005 16:57:29 +0000
Date: Wed, 20 Jul 2005 01:58:21 +0900
To: <[email-masked]>
From: "[email-masked]" <[email-masked]>
Subject: Re: no more milestones?
Cc: "Thomas D. Nadeau" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>

Hi,

I agree that base signalling and routing GMPLS protocols need to be
worked out, and at the same time I would like to see GMPLS applications
in operational networks.

I remember about the vote on specific items (to-be-rechartered items) which
included basic signalling and routing aspects as well as some extended 
applications.
At that time, I felt we had a long and good discussion already about what 
would be
on the revised charter and it was very close to decide.

Now, though (because?) I don't know what process is done and further needed
beyond what we already went through and saw, I appreciate if we can see new 
milestones
reflecting the vote and recent discussions so that we can determine in Paris
hopefully without, but with some more discussion if needed.

Thanks.

Ichiro Inoue

 >  >> I would like to see:
 >  >> - a refinement of the charter to focus the next work items
 >  >> - a year's worth of milestones to ensure we stay focused.
 >  >>
 >  >> On the other hand, we should aim to close down CCAMP and move the
 >  >> work to
 >  >> other or new working groups.
 >  >>
 >  >
 >  > coupling both sentences does it mean in your view
 >  >
 >  > 1) define several short-term milestones for refining topics that
 >  > have been
 >  > already initiated and requires further well scoped attention
 >  >
 >  > 2) (brand) new topics should target new working groups - as already
 >  > initiated with L1VPN for inst. - or existing working groups
 >  >
 >  > nevertheless, i do not see why this automatically means CCAMP can not
 >  > remain the focal point concerning *base* GMPLS signaling and routing
 >  > protocols
 >

Delivery-date: Tue, 19 Jul 2005 14:51:24 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-03.txt 
Date: Tue, 19 Jul 2005 10:50:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Extensions to GMPLS RSVP Graceful Restart
	Author(s)	: A. Satyanarayana
	Filename	: draft-ietf-ccamp-rsvp-restart-ext-03.txt
	Pages		: 24
	Date		: 2005-7-19
	
This document describes extensions to the RSVP Graceful Restart
   mechanisms defined in RFC 3473.  The extensions enable the recovery
   of RSVP signaling state based on the Path message last sent by the
   node being restarted.  Previously defined Graceful Restart
   mechanisms, also called recovery from nodal faults, permit recovery
   of signaling state from adjacent nodes when the data plane has
   retained the associated forwarding state across a restart.  These
   mechanisms do not fully support signaling state recovery on ingress
   nodes or recovery of all RSVP objects.  The presented extensions use
   the RSVP Hello extensions defined in RFC 3209, and extensions for
   state recovery on nodal faults defined in RFC 3473.  With the
   presented extensions the restarting node can recover all previously
   transmitted Path state including the Explicit Route Object and the
   downstream (outgoing) interface identifiers.  The extensions can also
   be used to recover signaling state after the restart of an ingress
   node.  The extensions optionally support the use of Summary Refresh,
   defined in RFC 2961, to reduce the number of messages exchanged
   during the Recovery Phase when the restarting node has recovered
   signaling state locally for one or more LSPs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-rsvp-restart-ext-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-rsvp-restart-ext-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 19 Jul 2005 14:24:57 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Date: Tue, 19 Jul 2005 10:24:35 -0400

Arthi,

One more comment. I think the draft should give a clear and unambiguous
answer to how e2e LSP and a stitching LSP (S-LSP) relate from the switching
capability point of view. Specifically, should they belong to the same
network layer, should they share the same switching type or maybe there are
no limitations at all, and you can stitch your e2e LSP pretty much with
anything you got, provided that this "anything" has enough bandwidth.

Let me give you a specific example. Is it possible to stitch a PSC1 e2e LSP
with a PSC2 S-LSP? You probably remember our discussion with Kireeti in
Minneapolis (and you were also part of it), and he said (and I 100% agree
with him) that although it is doable (you can do anything you want with the
label stack), it is not right and this should be logically prohibited. What
you should do in this case is to nest the e2e LSP within the PSC2 LSP (that
is, use it as H-LSP) even in case it consumes the entire PSC2 LSP bandwidth.

It is more clear in non-PSC cases. Although it is possible to "stitch" an
e2e VC12 LSP with a VC4 S-LSP, I could not imagine that a network operator
would ever agree with such solution. He is likely to say " What ?  If the
service is supposed to stay for 12 month, than for entire year I pretty much
burry my 62 VC12 channels - I cannot use them even conceptually in case
when, say, on the next day I'll have to provide another 62 VC12 services
that could've used these wasted resources"

On the other hand I know plenty GMPLS people who would say: "Sure, no
problem. Of course we can stitch a PSC e2e LSP with lambda S-LSP:  If
somebody wants to do a trick stupid as it is, why should we prevent him from
doing so?"

The bottom line is that a discussion like this in the draft and consensus
on how we see the stitching IMO would be extremely valuable for the GMPLS
multi-layer story, and I don't see a reason why this could not be achieved
in the frame of this work.

Igor

----- Original Message ----- 
From: "Arthi Ayyangar" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, July 18, 2005 2:51 PM
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

> Hi Igor,
>
> Please see inline.
>
> > 1. Why are saying that LSP Stitching is a private case of LSP Hierarchy?
>
> > there is more differences than similarities:
> > The differences are:
> > 1) In case of H-LSP there is a data plane adjacency, while in case of
S-LSP
> > there is none (as you correctly pointed out);
> > 2) In case of H-LSP there is an adaptation in data plane (label push/pop
for
> > PSC), while in case of S-LSP there is none - just simple
cross-connecting
> > ( label swap) as in case of two "native " e2e LSP adjacent segments ;
> > 3) H-LSP could be used by many e2e LSPs, while S-LSP could be used by
> > exactly one e2e LSP
> > 4) Signaling is different - there is no label negotiation in stitching
> > 5) H-LSP is used as a "true" data link, specifically there is a resource
> > allocation on the H-LSP edges, while in case of S-LSP there is none
> > 6) From MLN point of view, H-LSP is created in a server (lower) layer,
while
> > the S-LSP is created in the client (same as e2e LSP) layer.
> >
> > There are two similarities that I can think of:
> > 1) There is a signaling and possibly routing (see below) adjacencies
between
> > the ends;
> > 2) Both H-LSP and S-LSP could be advertised as separate TE links or as
TE
> > bundles
> >
> > I would recommend to dedicate a paragraph and enlist there similarities
and
> > differencies
> -------> Based on the discussions on the list over the last revision, the
> message that the authors received was that we do not want to go about such
> a lengthy discussion of similarities and differences (NOTE that the draft
> already does clearly highlight them where applicable). Instead we want
> this ID to simply explain how LSP stitching functions. In other words the
> idea was to make this ID a complete document by itself. But since it does
> borrow concepts from the LSP hierarchy ID, just state the concepts that
> are applicable or inapplicable.
>
> > 2. Why are you saying that a TE Link based on S-LSP can be used for
exactly
> > one e2e LSP? Parallel S-LSPs could be advertised as a single TE link
> > (bundle, see above) and hence can accomadate several e2e LSPs.
> ----> Igor, the draft does talk about this Bundling case.
>
> > 3. You are saying that S-LSP does not have a routing peering. Actually,
in
> > this respect it is no different from H-LSP: if it is advertised as a TE
link
> > into the same TE domain  that was used for S-LSP creation (unlikely IMO
> > scenario) than it does not require the routing adjacency (in other
words, it
> > is an FA according to LSP-HIER definition), otherwise, it IS  NOT and FA
and
> > does require the direct routing peering in the domain it is advertised
to
> > make it useful as a TE link in this domain
> -----> I am sorry, but I am missing your point here completely. Are you
> saying that the statement "the end points of an LSP segment do not have a
> routing adjacency", is incorrect  or are you saying that "this is
> obvious" ? It is unclear to me  what exactly your argument is. Please
> clarify.
>
> thanks,
> -arthi
>
> >
> > Cheers,
> > Igor
> >
> >
> >
> > ----- Original Message -----
> > From: <[email-masked]>
> > To: <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Friday, July 15, 2005 3:50 PM
> > Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
> >
> >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > > This draft is a work item of the Common Control and Measurement Plane
> > Working Group of the IETF.
> > >
> > > Title : Label Switched Path Stitching with Generalized MPLS Traffic
> > Engineering
> > > Author(s) : A. Ayyangar, J. Vasseur
> > > Filename : draft-ietf-ccamp-lsp-stitching-01.txt
> > > Pages : 19
> > > Date : 2005-7-15
> > >
> > > In certain scenarios, there may be a need to combine together two
> > >    different Generalized Multi-Protocol Label Switching (GMPLS) Label
> > >    Switched Paths (LSPs) such that in the data plane, a single end-to-
> > >    end (e2e) LSP is achieved and all traffic from one LSP is switched
> > >    onto the other LSP.  We will refer to this as "LSP stitching".
This
> > >    document covers cases where: a) the node performing the stitching
> > >    does not require configuration of every LSP pair to be stitched
> > >    together b) the node performing the stitching is not the egress of
> > >    any of the LSPs c) LSP stitching not only results in an end-to-end
> > >    LSP in the data plane, but there is also a corresponding end-to-end
> > >    LSP (RSVP session) in the control plane.  It might be possible to
> > >    configure a GMPLS node to switch the traffic from an LSP for which
it
> > >    is the egress, to another LSP for which it is the ingress, without
> > >    requiring any signaling or routing extensions whatsoever,
completely
> > >    transparent to other nodes.  This will also result in LSP stitching
> > >    in the data plane.  However, this document does not cover this
> > >    scenario of LSP stitching.
> > >
> > > A URL for this Internet-Draft is:
> > >
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt
> > >
> > > To remove yourself from the I-D Announcement list, send a message to
> > > [email-masked] with the word unsubscribe in the body of
the
> > message.
> > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > to change your subscription settings.
> > >
> > >
> > > Internet-Drafts are also available by anonymous FTP. Login with the
> > username
> > > "anonymous" and a password of your e-mail address. After logging in,
> > > type "cd internet-drafts" and then
> > > "get draft-ietf-ccamp-lsp-stitching-01.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > > [email-masked].
> > > In the body type:
> > > "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
> > >
> > > NOTE: The mail server at ietf.org can return the document in
> > > MIME-encoded form by using the "mpack" utility.  To use this
> > > feature, insert the command "ENCODING mime" before the "FILE"
> > > command.  To decode the response(s), you will need "munpack" or
> > > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > > exhibit different behavior, especially when dealing with
> > > "multipart" MIME messages (i.e. documents which have been split
> > > up into multiple messages), so check your local documentation on
> > > how to manipulate these messages.
> > >
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> > >
> >
>

Delivery-date: Tue, 19 Jul 2005 14:14:01 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: Re: no more milestones?
Date: Tue, 19 Jul 2005 15:15:50 +0100

Hi Dimitri,

> much thanks for your reply - just to clarify, in the below when you
state:
>
>> "If, on the other hand, we are not going to add this stuff to the
charter,
>> it would be very important for us to be clear about this so that the
people
>> working in these areas know that they must take their work to another
WG or
>> BOF."
>
> when you state "... to another WG" do you mean an existing WG, and in
such
> a case do you have any specific WG in mind ? any clarification much
> appreciated

I have nothing specific in mind. Just to note that that which is not CCAMP
is something else.

A

Delivery-date: Tue, 19 Jul 2005 14:03:37 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "George Newsome" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Moving LSP ownership between control plane and management plane
Date: Tue, 19 Jul 2005 15:02:24 +0100

Thanks George,

Useful input.

> You asked for comments on this proposal, which was presented to ITU-T
> Q14 experts in January of this year.

Can you confirm that there were plenty of providers represented at the
meeting.

> There are so many issues involved in moving a connection from the
> management plane to the control plane that involve intensive management
> action, that it is not evident that signaling need be involved at all.

Interesting. It is certainly valuable to have a list of these issues out
in the open. I have made some comments in the appended meeting report.

If the control plane is to take over the connection then we assume that
signaling state must be built so that the control plane could then modify
or tear down the connection. how would you propose that this be done
without involving signaling?

> As a personal opinion, it makes little sense to consider moving the
> connection. It makes more sense to replace the connection with one set
> up via the control plane, and to then delete the original management set
> up connection.

The question arrises of how this would be done in a network with limited
resources. That is, if it is possible to set up a parallel conneciton then
the method you describe would be fine, but if there are not enough
parallel resources then would you propose that a lambda (for example)
could be used for the management-established connection and for the
control-plane-owned connection at the same time? This might present some
difficulties as well.

Do you have an opinion on my main question which is whether this tyoe of
change-over would ever be done in service?

Thanks,
Adrian

> Excerpt of the meeting report of Q14 Experts, January 2005
>
> WD06 (Marconi) "G.7713 Modification in order to support Circuit
> Migration" contains a modified version of draft G.7713 Revision as was
> presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This
> contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to extend
> the concept of Call/Connection setup to setup/adopt and release to
> release/de-adopt. In Connection Adoption both the SNC are not actually
> created and the LC are not actually established due to the fact that the
> underlying physical resources are already in place. In the
> Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated,
> only the Control Plane information associated with then is removed and
> the ownership is moved to Management Plane. Attributes for indicating
> Adoption/Dis-adoption are proposed for the INNI Connection messages.
>
> The discussion was mainly on the Management plane and Control plane
> actions required before signalling is involved. The group noted that the
> following issues need to be addressed:
>
> - Naming of transport resources to the control plane.  Before a call can
> be placed under signalling control, links that are involved in the
> connection need to be given control plane names.  Without these, no
> explicit route can be formed to match the resources of the connection.

This is pretty obvious. But actually, this is an issue with moving the
resources from one plane to another (or having them present in both
planes). It is certainly a prerequisite for moving the connection, but it
is not functionally an element of moving the connection.

The draft, as I read it, assumes that these operations have been completed
and then asks "how do I move the connection from one plane to the other?"

> - Resource state while under dual CP and MP views.  After resources are
> given control plane names, the resources are still viewed by the
> management plane.  It may be necessary to create a new state for the
> resource to indicate that the management plane cannot perform some
> actions on the connection points as the control plane is about to take
over.

Yes. There is certainly scope for a race condition here. I believe that
the I-D proposes to (try to) make the transfer an atomic action from the
point of view of the change-over.

Note, however, that it is wrong to assume that a resource belongs only to
the control or to the management plane at any moment in time. This may be
true with respect to the ability to provision/control connections, but
resources that are available for use by the control plane can still be
managed through the management plane. Thus, you take a laser out of
service through the management plane, not through the control plane.

> - Role of discovery functions (esp. CELA).  After control plane names
> are allocated, distributed control plane functions need to be associated
> and communication adjacencies formed.  This too is a precursor to any
> signalling procedures in migrating from the MP to CP.

Note to CCAMP: CELA is Control Entity Logical Adjacency.
This too is "obvious".
But this discussion seems to be wide of the mark. Before deploying a
control plane, it is clear that this type of operation needs to take
place. Since (within the context of CCAMP) a control plane *is* going to
be deployed, we can assume this operation and move on to the discussion in
the draft.

> - Similarity of migration to synchronization after CP failure and
> subsequent recovery.  Connection control procedures might be the same in
> migrating a call from the MP to the CP as the situation when the CP has
> failed and is recovering.  Here, the network connections are already in
> place, but connection and call state need to be created to match it.
> Knowledge of the call and what the connection should be is obtained from
> the MP for migration, and from some reliable database in the recovery
case.

This is a valid point.
Control plane failure, however, is unlikely to be total. That is, it would
be unusual for more than one control plane link or node to fail. Thus, in
the control plane, the "reliable database" is distributed and recovery can
follow the procedures outlined in draft-ietf-ccamp-rsvp-restart-ext-03.txt

It would certainly be worth considering whether the procedures used for
control plane recovery could be applied to transfer of ownership from the
management to control plane. at the moment, I suspect that they could not
because the restart extensions assume a specific period during which
signaling is associated with recovery.

We would also need to look at the reverse process (transfer from CP to MP)
that is not possible to cover by CP restart procedures.

> - Call awareness of migration vs. connection being unaware of migration.
>   When connection state is being created to match an existing
> connection, the connection controllers (CCs) do not require awareness of
> why this is happening as the context could be migration or recovery.  A
> mechanism to create control state without affecting transport plane
> state is needed in the CCs.  Call controllers though do need migration
> awareness as they need to obtain/derive call identification from the MP.

I disagree.
Connection controllers must be able to distinguish between resources that
are already in use and cannot be assigned to a new connection, and those
that are already in use and can be assigned to a new connection because
the connection is replacing an existing connection. If this were happening
entirely within the control plane we would use resource sharing, but when
the operation spans the control and management planes resource
ownership/sharing is more complex and the conneciotn controller needs to
be able to issue the approriate instrucitons for the assignment of the
resources.
On the other hand, call controllers do not need awareness of the details
of the realisation of the connections.

> In summary, the group decided that it is premature to consider
> signalling procedure before the above issues, amongst other, have been
> studied. However the contribution does enable the group to expose in a
> larger context the interaction between CP and MP for connection
> migration. The above issues were included in SP24 of the G.7713 Living
> List (see WD22).

Delivery-date: Tue, 19 Jul 2005 13:50:02 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
From: [email-masked]
Subject: Re: no more milestones?
Date: Tue, 19 Jul 2005 15:49:05 +0200

hi adrian,

much thanks for your reply - just to clarify, in the below when you state:

"If, on the other hand, we are not going to add this stuff to the charter,
it would be very important for us to be clear about this so that the people
working in these areas know that they must take their work to another WG or
BOF."

when you state "... to another WG" do you mean an existing WG, and in such
a case do you have any specific WG in mind ? any clarification much
appreciated

thanks,
- dimitri.

---

Hi Dimitri,

> > I would like to see:
> > - a refinement of the charter to focus the next work items
> > - a year's worth of milestones to ensure we stay focused.
> >
> > On the other hand, we should aim to close down CCAMP and move the work
to
> > other or new working groups.
>
> coupling both sentences does it mean in your view
>
> 1) define several short-term milestones for refining topics that have
been
> already initiated and requires further well scoped attention
>
> 2) (brand) new topics should target new working groups - as already
> initiated with L1VPN for inst. - or existing working groups
>
> nevertheless, i do not see why this automatically means CCAMP can not
> remain the focal point concerning *base* GMPLS signaling and routing
> protocols

To answer your question: yes, I would like to see both. We need some
short-term milestones to guide and refine our work on existing topics. For
example, to complete the inter-domain work, possibly including issues of
protection and restoration.

But there are also some topics that are broadly covered by the CCAMP
scope, where we would benefit greatly by having a specific description on
the charter, and detailed milestones. I am thinking about L2SC, MRN,
MPLS/GMPLS interworking as discussed on the mailing list last November.
While we could sort of take on these things under the vague scope of the
current charter, I would prefer for us to be open, clear and focused.

And this covers your last point. I, too, don't see why CCAMP should not
remain the focal point for GMPLS signaling and routing protocols. However,
to do so in an efficient and proper manner, we should add the appropriate
milestones to the charter. If, on the other hand, we are not going to add
this stuff to the charter, it would be very important for us to be clear
about this so that the people working in these areas know that they must
take their work to another WG or BOF.

Thanks,
Adrian

Delivery-date: Tue, 19 Jul 2005 13:37:26 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: Feedback on draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt
Date: Tue, 19 Jul 2005 15:36:19 +0200

ccamp'ers, all,

as already stated on this list we have put together our thoughts and
produced the above mentioned document; its purpose is to initiate
DISCUSSION on the following points:

- are the proposed GMPLS for Ethernet deployment scenarios representative
enough of the user community's expectations ?

- if yes, is the interest in GMPLS for Ethernet in-/out-side the CCAMP WG
community strong enough to consider the corr. GMPLS signaling and routing
requirements (second part of the document) as part of the CCAMP WG effort ?

- if not, would you let us know why ?

much thanks for your feedback
- dimitri.

Envelope-to: [email-masked]
Delivery-date: Tue, 19 Jul 2005 12:35:51 +0000
Date: Tue, 19 Jul 2005 21:35:28 +0900 (JST)
From: Kenichi Nagami <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: GMPLS OSPF-TE MIB

Hi tomo,

This work is interesting and important from management point of view.
I have questions and comments.

- Does this MIB support for only GMPLS OSPF-TE or both GMPLS OSPF-TE and OSPF-TE (RFC3630) ?

- I think INDEX of the ospfTeLsdbEntry need to add Area ID. Because OSPF opaque LSA type 10 is
  "area local scope".

- There are a log of error for MIB definition. Could you fix them?
  For example,
  1) "--" is needed "in xxx"
     current
    DESCRIPTION
          "Initial version. Published as RFC xxxx." -- RFC-editor pls fill
          in xxx"

     changed
    DESCRIPTION
          "Initial version. Published as RFC xxxx." -- RFC-editor pls fill
         --  in xxx"

  2) need to "," in ospfTeMainGroup OBJECT-GROUP
             ospfTeSwitchingType
             ospfTeEncoding
     are changed to
             ospfTeSwitchingType,
             ospfTeEncoding,

Regards,

Ken Nagami
Intec Netcore

>
>At 08:52 05/07/15, Tomohiro Otani wrote:
>Hi everyone,

>We posted a new draft about GMPLS OSPF-TE MIB as follows.
>http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-ospf-mib-00.txt

>We welcome your comments and feedbacks, pls.
>And please make a comment whether this is within ccamp WG or not (OSPF-WG?).

>We believe that this is a very significant definition of OSPF-TE MIB,
>being complementary to other GMPLS related MIBs (TE/LSR/LMP mibs) in order
>to deploy GMPLS control plane in the actual environment with simple but
>reliable network management.

>With best regards,

>tomo

Delivery-date: Tue, 19 Jul 2005 12:26:43 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>, "Scott Bradner" <[email-masked]>
Subject: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Tue, 19 Jul 2005 12:59:12 +0100

Hi,

Please comment on this draft response liaison which I intend to send on
Monday 25th July.
You can see the original incoming liaison at
http://www.olddog.co.uk/incoming.htm

Thanks,
Adrian
=====
To: ITU-T SG15 Questions 12 and 14
From: IETF CCAMP Working Group
Subject: Response to your liaison on GMPLS/ASON Lexicography
For: Action
Deadline: August 31st 2005

The CCAMP Working Group would like to thank SG15 and especially Questions
12 and 14 for the time and effort they put into providing input and
feedback on the GMPLS/ASON lexicography Internet-Draft that is being
developed by CCAMP. Much of the material supplied as direct comments or as
mark-ups to the Internet-Draft has been incorporated into the latest
revision which is available at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-03.txt

In your liaison you state some assumptions which we would like to comment
on as follows.

- The purpose of the document is to enable those familiar with ASON
  to understand GMPLS terminology in an ASON context

Correct.

- GMPLS terms are described informally in the document in a way that
  is generally consistent with GMPLS (existing RFCs and work in progress)

While the definition of GMPLS terms would be helpful for understanding
GMPLS terms in a GMPLS context, that is not the purpose of this document.

- Based on these descriptions, interpretations of these GMPLS terms
  in ASON terminology are provided

It is intended that the interpretation of the GMPLS terms is not based on
these descriptions, but based on the full meaning of the GMPLS terms. The
descriptions of the GMPLS terms are provided in this Internet-Draft for
context and a brief summary.

- CCAMP has primarily responsibility for the descriptions of GMPLS terms

Correct.

- Q12/15 has responsibility to provide input to the GMPLS-ASON
  interpretations (based on the descriptions in this draft)

We welcome this assumption of responsibility by Q12/15 to provide input to
the Internet-Draft. While the Internet-Draft remains under the overall
editorial control of the CCAMP working group, we hope to be able to use
the text supplied by Q12/15 with only editorial changes.

Additionally, we welcome the pledge to continue work on this
Internet-Draft through correspondence on the Q12/15 mailing list, and
thank Q12/15 for assigning Ben Mack-Crane as the SG15 representative on
this matter. Ben has proved very helpful in clarifying and developing
comments received from SG15.

We have had several email exchanges with Ben about a few of the specific
comments made in your review of the 02 revision of the Internet-Draft.
Although he has taken these comments to the Q12/15 mailing list no
response has been received, perhaps due to pressure of time. We are taking
the opportunity to restate several questions here for your convenience and
would appreciate your answers as part of the response to this liaison.

1. Definition of a Resource (section 3.2)
   You have supplied us with the simple text that says...
     In ASON applications:
     A resource refers only to a link connection (e.g. VC-11,
     VC-4 etc.).

   We would like to clarify this because we don't understand how
   the original text is wrong. It used to say...
     ITU-T [should be ASON] terms for resource:
     - Connection point (cp) in the context of link discovery
       and resource management (allocation, binding into
       cross-connects, etc.);
     - Link connection or trail termination in the context of
       routing, path computation and signaling.

   Recall that we are talking about the ASON terms for what GMPLS
   calls a resource. We think the following...
   In ASON a link connection is an association of output cp on one
   side of the link and input cp on the other side of the link. In
   GMPLS by resource we mean in most of the cases the local end of
   the resource (which is cp in ASON terminology). This is true in
   the context of link discovery.

   More importantly, this is also true in the context of a
   signaling application. Specifically, when a GMPLS signaling
   sub-system requests allocation of a resource, the GMPLS
   Resource Manager allocates only the local end of the
   resource. This happens on both sides of the link, that is, we
   allocate input and output resources. This contrasts with ASON,
   where there is a much more versatile LRM, and the connection
   manager (signaling application) allocates link connections
   only on the output side, leaving LRM to coordinate the
   allocation with the neighbor.

   However, in GMPLS TE advertisements we account only for
   outgoing resources, that is, we don't advertise incoming
   resources on the assumption that they match the outgoing
   resources for the discovered TE links.

   Bottom line: we believe that we should retain the previous
   definitions, and have not made this change in the new
   revision. We would like to discuss this point further with
   Q12/15.

2. Link ends and Data links (Section 3.5 - was section 3.4)

2a.Although we understand that ASON does not require the concept
   of a link end, GMPLS does. Therefore we should provide some
   form of language to help people do the mapping.

   The proposed new text from Q12/15 removes all reference to
   link ends from the ASON section, and we feel this is a
   mistake and propose the following text:
     In ASON, a GMPLS unidirectional data link end is a
     collection of connection points from the same client
     layer that are supported by a single trail termination
     (access point).

   This text depends on the fact that a link end is described as
   a set of resources that transfer traffic to a neighbor.

2b.The new text from Q12/15 gives us...
     A GMPLS data link is an ASON link supported by a single
     server trail.

   We are not sure that we understand this correctly. It
   appears to say that a unidirectional data link could be
   supported by multiple trail terminations (access points).
   This seems to suggest that a client would have to make a
   choice about where to send data, which seems to imply it
   really has to choose between data links! We are confused!

   We think some of this problem may come from the *need* in
   GMPLS to identify data link ends. There may be some value in
   stressing that a GMPLS link end is supported by exactly one
   trail termination. When several trail terminations are
   involved, we can still talk about single TE link (as a
   bundle), but each component link will be a distinct data
   link. We think that in ASON the SNPP (TE link in GMPLS
   language) could be supported by multiple terminations.

3. Link interfaces (section 3.6 - was 3.5)
   The new text from Q12/15 gives us...
     A GMPLS interface is "all the stuff between a physical
     interface and a matrix in an ASON network element." More
     precisely, it is a trail termination function and adaptation
     function for which adapted client layer connection points
     are bound to a matrix.

   We think "physical interface" may be ambiguous in the multi-
   layer context. We think the "stuff" should be between a link
   and a matrix, since we are talking about links in distinct
   layers.

In addition to your feedback on the specific points above, we would
welcome your continued comments and review of the Internet-Draft.

Regards,
Adrian Farrel and Kireeti Kompella
IETF CCAMP Working Group Co-chairs

Delivery-date: Tue, 19 Jul 2005 11:47:14 +0000
Date: Tue, 19 Jul 2005 07:44:29 -0400
From: George Newsome <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]
Subject: Re: Moving LSP ownership between control plane and management plane

Adrian,

You asked for comments on this proposal, which was presented to ITU-T 
Q14 experts in January of this year.

There are so many issues involved in moving a connection from the 
management plane to the control plane that involve intensive management 
action, that it is not evident that signaling need be involved at all.

As a personal opinion, it makes little sense to consider moving the 
connection. It makes more sense to replace the connection with one set 
up via the control plane, and to then delete the original management set 
up connection.

Appended is an excerpt of the meeting report detailing some of the 
issues that need to be resolved before signaling need be considered.

Regards

	George

Excerpt of the meeting report of Q14 Experts, January 2005

WD06 (Marconi) "G.7713 Modification in order to support Circuit 
Migration" contains a modified version of draft G.7713 Revision as was 
presented in the Berlin meeting (WD 11, i.e., TD50/3 Dec.2004).  This 
contribution addresses SP24 (PC ? SPC) of G.7713. It proposes to extend 
the concept of Call/Connection setup to setup/adopt and release to 
release/de-adopt. In Connection Adoption both the SNC are not actually 
created and the LC are not actually established due to the fact that the 
underlying physical resources are already in place. In the 
Call/Connection dis-adoption SNC-LC-SNC is not actually de-allocated, 
only the Control Plane information associated with then is removed and 
the ownership is moved to Management Plane. Attributes for indicating 
Adoption/Dis-adoption are proposed for the INNI Connection messages.

The discussion was mainly on the Management plane and Control plane 
actions required before signalling is involved. The group noted that the 
following issues need to be addressed:

- Naming of transport resources to the control plane.  Before a call can 
be placed under signalling control, links that are involved in the 
connection need to be given control plane names.  Without these, no 
explicit route can be formed to match the resources of the connection.

- Resource state while under dual CP and MP views.  After resources are 
given control plane names, the resources are still viewed by the 
management plane.  It may be necessary to create a new state for the 
resource to indicate that the management plane cannot perform some 
actions on the connection points as the control plane is about to take over.

- Role of discovery functions (esp. CELA).  After control plane names 
are allocated, distributed control plane functions need to be associated 
and communication adjacencies formed.  This too is a precursor to any 
signalling procedures in migrating from the MP to CP.

- Similarity of migration to synchronization after CP failure and 
subsequent recovery.  Connection control procedures might be the same in 
migrating a call from the MP to the CP as the situation when the CP has 
failed and is recovering.  Here, the network connections are already in 
place, but connection and call state need to be created to match it. 
Knowledge of the call and what the connection should be is obtained from 
the MP for migration, and from some reliable database in the recovery case.

- Call awareness of migration vs. connection being unaware of migration. 
  When connection state is being created to match an existing 
connection, the connection controllers (CCs) do not require awareness of 
why this is happening as the context could be migration or recovery.  A 
mechanism to create control state without affecting transport plane 
state is needed in the CCs.  Call controllers though do need migration 
awareness as they need to obtain/derive call identification from the MP.

In summary, the group decided that it is premature to consider 
signalling procedure before the above issues, amongst other, have been 
studied. However the contribution does enable the group to expose in a 
larger context the interaction between CP and MP for connection 
migration. The above issues were included in SP24 of the G.7713 Living 
List (see WD22).

Delivery-date: Tue, 19 Jul 2005 08:39:11 +0000
Content-class: urn:content-classes:message
Subject: TR :  I-D ACTION:draft-leroux-ccamp-ctrl-saturation-01.txt 
Date: Tue, 19 Jul 2005 10:37:23 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58C3D.1688A89B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

	Hi all,

	Here is a new version of the control plane saturation ID, which
takes into account comments received on=20
	the list and also some offline comments.
	Here are the major changes:
	-A new co-author
	-Motivations and elements of procedure have been clarified
	-Added new flags in the IGP Saturation TLV so as to indicate the
reasons for the saturation
	-Added Inter-AS considerations
	-Some rewording for the sake of clarity

	Your comments on this new revision would be really appreciated.

	Adrian, Kireeti, we would like to see this item as part of the
potential rechartering discussion...

	Best Regards,

	JL et al.

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>=20
>=20
> 	Title		: Procedure to handle (G)MPLS-TE control plane
>                           saturation
> 	Author(s)	: J. Le Roux, et al.
> 	Filename	: draft-leroux-ccamp-ctrl-saturation-01.txt
> 	Pages		: 10
> 	Date		: 2005-7-18
> =09
> This document defines extensions to RSVP-TE (Resource Reservation=20
>    Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to
>=20
>    notify about control plane resources saturation, when an LSR runs
> out=20
>    of control plane resources available to support any additional LSP.
>=20
>    Such notification may serve as trigger for the impacted Head-end
> LSR=20
>    to take appropriate actions.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturation
> -01.txt
>=20
> To remove yourself from the I-D Announcement list, send a message to=20
> i-d-announce-request at ietf.org with the word unsubscribe in the body
> of the message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>=20
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-leroux-ccamp-ctrl-saturation-01.txt".
>=20
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html=20
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	mailserv at ietf.org.
> In the body type:
> 	"FILE
> /internet-drafts/draft-leroux-ccamp-ctrl-saturation-01.txt".
> =09
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 	=09
> 	=09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturation
> -01.txt>
> <ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturation
> -01.txt> =20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce at ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>=20

------_=_NextPart_001_01C58C3D.1688A89B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>TR :  I-D ACTION:draft-leroux-ccamp-ctrl-saturation-01.txt =
</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hi all,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Here is a new version =
of the control plane saturation ID, which takes into account comments =
received on </FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">the list and also =
some offline comments.</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Here are the major =
changes:</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">-A new =
co-author</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">-Motivations and =
elements of procedure have been clarified</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">-Added new flags in =
the IGP Saturation TLV so as to indicate the reasons for the =
saturation</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">-Added Inter-AS =
considerations</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">-Some rewording for =
the sake of clarity</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Your comments on this =
new revision would be really appreciated.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Adrian, Kireeti, we =
would like to see this item as part of the potential rechartering =
discussion...</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Best Regards,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">JL et al.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">A New Internet-Draft is available =
from the on-line Internet-Drafts directories.</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Title&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Procedure to handle =
(G)MPLS-TE control plane</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; saturation</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : J. =
Le Roux, et al.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
: draft-leroux-ccamp-ctrl-saturation-01.txt</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Pages&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 10</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2005-7-18</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20

<BR><FONT SIZE=3D2 FACE=3D"Courier New">This document defines extensions =
to RSVP-TE (Resource Reservation </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; Protocol-Traffic =
Engineering) and IGP (IS-IS and OSPF), in order to </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; notify about =
control plane resources saturation, when an LSR runs out </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; of control plane =
resources available to support any additional LSP. </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; Such notification =
may serve as trigger for the impacted Head-end LSR </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; to take appropriate =
actions.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">A URL for this Internet-Draft =
is:</FONT>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-satur=
ation-01.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturati=
on-01.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">To remove yourself from the I-D =
Announcement list, send a message to </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">i-d-announce-request at ietf.org =
with the word unsubscribe in the body of the message.&nbsp; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">You can also visit </FONT><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/I-D-announce"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">https://www1.ietf.org/mailman/listinfo/I-D-announce</FONT></U></A><F=
ONT SIZE=3D2 FACE=3D"Courier New"> </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">to change your subscription =
settings.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Internet-Drafts are also =
available by anonymous FTP. Login with the username</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&quot;anonymous&quot; and a =
password of your e-mail address. After logging in,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">type &quot;cd =
internet-drafts&quot; and then</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">&quot;get =
draft-leroux-ccamp-ctrl-saturation-01.txt&quot;.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">A list of Internet-Drafts =
directories can be found in</FONT>

<BR><A HREF=3D"http://www.ietf.org/shadow.html"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://www.ietf.org/shadow.html</FONT></U></A><FONT SIZE=3D2 =
FACE=3D"Courier New"> </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">or </FONT><A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</FONT></U></A>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Internet-Drafts can also be =
obtained by e-mail.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Send a message to:</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">mailserv at ietf.org.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">In the body type:</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">&quot;FILE =
/internet-drafts/draft-leroux-ccamp-ctrl-saturation-01.txt&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20

<BR><FONT SIZE=3D2 FACE=3D"Courier New">NOTE:&nbsp;&nbsp; The mail =
server at ietf.org can return the document in</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">MIME-encoded form by using the &quot;mpack&quot; =
utility.&nbsp; To use this</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">feature, insert the command &quot;ENCODING =
mime&quot; before the &quot;FILE&quot;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">command.&nbsp; To decode the response(s), you will =
need &quot;munpack&quot; or</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">a MIME-compliant mail reader.&nbsp; Different =
MIME-compliant mail readers</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">exhibit different behavior, especially when dealing =
with</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">&quot;multipart&quot; MIME messages (i.e. documents =
which have been split</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">up into multiple messages), so check your local =
documentation on</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">how to manipulate these messages.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Below is the data which will =
enable a MIME compliant mail reader</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">implementation to automatically =
retrieve the ASCII version of the</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Internet-Draft.</FONT>

<BR><A =
HREF=3D"ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-satura=
tion-01.txt"><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New =
Roman">&lt;ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat=
uration-01.txt&gt;</FONT></U></A><FONT FACE=3D"Times New Roman"> </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">_______________________________________________</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">I-D-Announce mailing list</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">I-D-Announce at ietf.org</FONT>

<BR><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/i-d-announce"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">https://www1.ietf.org/mailman/listinfo/i-d-announce</FONT></U></A>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C58C3D.1688A89B--

Delivery-date: Tue, 19 Jul 2005 08:39:06 +0000
Content-class: urn:content-classes:message
Subject: RE: no more milestones?
Date: Tue, 19 Jul 2005 09:36:18 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Thanks Adrian,
>=20
> Hi Neil and Tom,
>=20
> >> There are for instance, ops/management-related items
> >> for "base" CCAMP items that need to be worked on.  The=20
> question for=20
> >> me is why can't we continue to work on these?  I thought=20
> these things=20
> >> were automatic chartered items, and thus should be ongoing work=20
> >> items.
> >
> >You are right Tom to raise the point about the importance of network=20
> >management here.  When we are dealing with large BW=20
> granularity co-cs=20
> >mode technologies then virtually all the really important issues are=20
> >concerned with the efficacy of the management-plane solution....the=20
> >control-plane plays a minor support role (for a whole raft of=20
> >technical/commercial/operational reasons). This is of course=20
> quite the=20
> >opposite to a cl-ps layer network like IP.  We look to TMF for=20
> >expertise here in developing the required management=20
> information models=20
> >which are based on functional architecture.
>=20
> I think you are right, Neil, that we would largely look=20
> outside the IETF for management plane solutions.
NH=3D> I know some folks must think 'why does he keep banging about =
stuff
like functional architecture, 3 network modes, client/server
relationships,  etc'....well, its for sound practical reasons, and one
of them being the importance of the management information models we
operators need if we are going to get the right equipment specifications
and maximally effective downstream NMS/OSS.  These facets can only be as
good as the base networking specification of the data and control
planes, ie if these violate architectural rules of the mode concerned or
have functional deficiencies then no amount of effort/money subsequently
thrown at the management piece can really recover the situation.  And
speaking as an operator I am very concerned about whole-life costs and
this is why the above stuff is important to me......esp noting there is
a significant time-constant between cause and effect, so its often very
easy to make mistakes early on that don't become apparent wrt
implications until several years later.....and then its invariably too
late to fix easily.

So if there is one key message I'd like folks to get it's this:  We must
strive to get the networking aspects of the data-plane and control-plane
right/complete for the mode we are considering from t=3D0....if we =
don't,
the NMS/OSS folks who pick this up later cannot recover the situation.
Folks involved in any aspect of networking (esp those creating
standards) should therefore try and make the effort to better understand
functional architecture stuff.=20
>=20
> What Tom is referring to, of course, is the management=20
> aspects necessary as part of the control plane solutions.=20
> Aspects such as MIB modules, PIBs, OAM etc.
NH=3D> Understood and agreed Adrian.....and I'm glad to note here you
mention OAM as a 'for instance' here.  This is a good example of what I
was referring to above, ie this needs to be an integral part of the
trail's characteristic information specification at t=3D0.  Some folks =
may
remember that ~3-4 years ago I spent a futile year or so trying to
convince the MPLS crowd that they must consider this aspect AND that it
must not be proxied by a control-plane solution (this becomes very
obviously true when the data-plane and control-plane protocols run on
logically distinct layer networks within the SAME networking system, as
indeed they are forced to in the co-cs mode).  However, I should also
mention that if one breaks the connectivity rules of the co mode (ie
merging as we find with LDP and PHP in some spins of MPLS) then there
are no good/simple solutions to OAM/fault management (or indeed traffic
or performance management).....this is just a consequence you now have
to accept and live with.
>=20
> I'm sure that I don't have to remind you that GMPLS is a=20
> control plane technology not a data plane technology. The=20
> applicability of GMPLS is to any co data plane technology and=20
> therefore it embraces both co-cs and co-ps.
NH=3D> No you don't have to remind me of this.....and you are mentioning =
a
really important thing here that, if I may, I'd like to amplify a
little:

-	all technologies map to one of the 3 networking modes.....the
exact behaviour of a given technology is then dependent on
well/completely it is functionally specified for its target environment,
and how well it respects modal networking constraints.  In terms of what
this means practically, then (i) it makes huge amounts of sense to seek
convergence within each mode but it is not sensible to think exactly the
same approach can be applied across all 3 modes, and (ii) each mode has
very important behavioural differences that we should seek to exploit as
these are the key to addressing what are otherwise very hard networking
problems.  {Aside - There is actually a unifying model based on
Shannon's Information Theory which brings the G.805 (co) and G.809 (cl)
func arch perspectives together which one of my colleagues is working on
(paper to be issued later this year), but in terms of what we see
manifested we simply need to note that its these differences that are
the key to tackling some otherwise very hard networking problems in the
areas of QoS/performance-inheritance/pricing/complexity/etc
management....I gave some hints on this in the thread 'End-to-end
L2-LSP' 15 July 05.}

-	the major difference between GMPLS and MPLS is, as you correctly
observe Adrian, that no data-plane structures have been specified for
the former in IETF whereas they have for the latter (and it is this that
is the source of the problems for MPLS as-is...we could actually fix
these if there was the will to let go of a few misplaced beliefs.....but
I am not sure that there is that will given how far some of this stuff
has now gone).

-	unlike the co-ps mode the co-cs mode is rather 'self-protecting'
of abuse, ie its very difficult to do bad things to it even if you
try....and the reasons why this is so is hidden-away in the underlying
Information Theory constraints of what 'labelling' means in this mode
(see also my rather detailed response to Igor Bryskin of recent,
'Network modes and layer network relationships' 13 July 05, which
explains why one can't have a single control-plane running 'IP to
Optics').  So in the co-cs mode:  OOB control/management is forced,
there are no 'QoS classes', we can always have proper client/server
functional decoupling (subject to my observations wrt the nonsense of
'topology on the fly', etc) one cannot merge co-cs trails and of course
trail must go from source to sink (ie can't prematurely stop at the
wrong place).  There are also some interesting consequential issues wrt
performance inheritance in nested client/server layer network
relationships if one thinks any mode can arbitrarily support any other
mode (eg PWE3 stuff).

-	it ought to be somewhat intuitively obvious that its a good idea
to try and re-use the same base control-plane components/design for the
co-ps mode as the co-cs mode.  And this is one reason (there are
actually lots of reasons) why I am supportive of the folks who also
advocate this view.....and I think you share this view Adrian.

regards, Neil
>=20
> In answer to Tom's question, we are not prohibited from=20
> working on these things, but we are rather adrift without any=20
> milestones. i would certainly say that the right place to=20
> bring drafts for discussion is the CCAMP list.
>=20
> However, before committing the WG to any specific drafts the=20
> chairs need to be guided by an up-to-date charter with real=20
> milestones. I do hope that the discussions in Paris will lead=20
> to these so that we can get on with the work that everyone is=20
> so keen to do.
>=20
> Cheers,
> Adrian
>=20
>=20

Delivery-date: Tue, 19 Jul 2005 00:48:54 +0000
Date: Tue, 19 Jul 2005 09:48:32 +0900
From: Tomohiro Otani <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-00

Hi Dimitri,

Per our initial discussion, we would like to formulate
the unified view on CSPF consideration, and we simply
thought it is BCP.

Considering more deeply, our draft does not define the
protocol itself but the protocol related specification

In that sense, you are right, it is prescriptive more
than descriptive for guiding operations. Moreover, I came
up my mind that it may be more standard track than informational.
But I am not sure. What's your thought on this ?

With best regards,

tomo

PS: We posted 01 version.

[email-masked] wrote:

>authors, is the purpose of the above mentioned draft:
>
> 1. prescriptive (even if informational)
>
> 2. descriptive for guiding operations (BCP)
>
> 3. informative (survey-like)
>
>from what i read, it is more 1 like - is my understanding correct ?
>
>  
>

Delivery-date: Mon, 18 Jul 2005 21:47:50 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Date: Mon, 18 Jul 2005 17:47:37 -0400

Arthi,

----- Original Message ----- 
From: "Arthi Ayyangar" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, July 18, 2005 2:51 PM
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

> Hi Igor,
>
> Please see inline.
>
> > 1. Why are saying that LSP Stitching is a private case of LSP Hierarchy?
>
> > there is more differences than similarities:
> > The differences are:
> > 1) In case of H-LSP there is a data plane adjacency, while in case of
S-LSP
> > there is none (as you correctly pointed out);
> > 2) In case of H-LSP there is an adaptation in data plane (label push/pop
for
> > PSC), while in case of S-LSP there is none - just simple
cross-connecting
> > ( label swap) as in case of two "native " e2e LSP adjacent segments ;
> > 3) H-LSP could be used by many e2e LSPs, while S-LSP could be used by
> > exactly one e2e LSP
> > 4) Signaling is different - there is no label negotiation in stitching
> > 5) H-LSP is used as a "true" data link, specifically there is a resource
> > allocation on the H-LSP edges, while in case of S-LSP there is none
> > 6) From MLN point of view, H-LSP is created in a server (lower) layer,
while
> > the S-LSP is created in the client (same as e2e LSP) layer.
> >
> > There are two similarities that I can think of:
> > 1) There is a signaling and possibly routing (see below) adjacencies
between
> > the ends;
> > 2) Both H-LSP and S-LSP could be advertised as separate TE links or as
TE
> > bundles
> >
> > I would recommend to dedicate a paragraph and enlist there similarities
and
> > differencies
> -------> Based on the discussions on the list over the last revision, the
> message that the authors received was that we do not want to go about such
> a lengthy discussion of similarities and differences (NOTE that the draft
> already does clearly highlight them where applicable). Instead we want
> this ID to simply explain how LSP stitching functions. In other words the
> idea was to make this ID a complete document by itself. But since it does
> borrow concepts from the LSP hierarchy ID, just state the concepts that
> are applicable or inapplicable.

IB>> I see a problem here. Since we do not have another draft providing the
tight definition of LSP stitching, it is not good enough to describe it in
some light narrative manner. In section 1 you are saying:

1.  Introduction

LSP stitching is a special case of LSP hierarchy.  In case of LSP
   stitching, instead of an FA LSP, an "LSP segment" is created between
   two GMPLS nodes ....

I don't think  that "LSP stitching is a special case of LSP hierarchy". The
two mechanism have some remote IMO resemblance in control plane and have
nothing in common in the data plane. The biggest difference is that the
stitching happens within the same network layer and hence in sharp contrast
to LSP hierarchy does not require reconfigurations in lower (fat pipe)
layer(s). Just because of that the stitching could be much more attractive
mechanism for control plane. At least there will be no questions like " Who
is going to pay for unused bandwidth?"
Anyway, all I asked was for a small paragraph summarizing similarities and
differences of both planes. That IMO would help.

One more point. You use terms FAs and FA-LSPs everywhere in the draft. This
is confusing because what you really mean hear is Hierarchical LSPs (H-LSPs)
and TE links enabled by H-LSPs.  As I mentioned earlier, there is no place
for these terms in your draft because it mostly concerns about TE
inter-domain scenarios, while [LSP-HIER] has a focus on a single domain and
strictly mandates the LSP to be advertised into the *same* domain to be
considered as FA-LSP

>
> > 2. Why are you saying that a TE Link based on S-LSP can be used for
exactly
> > one e2e LSP? Parallel S-LSPs could be advertised as a single TE link
> > (bundle, see above) and hence can accomadate several e2e LSPs.
> ----> Igor, the draft does talk about this Bundling case.

IB>> My problem here is with the statement from section 2:

"An LSP segment TE link SHOULD NOT admit more than one e2e LSP into
  it. "  You do describe the bundling, which contradicts the statement
above. It may accept as many e2e LSPs as it has component links

>
> > 3. You are saying that S-LSP does not have a routing peering. Actually,
in
> > this respect it is no different from H-LSP: if it is advertised as a TE
link
> > into the same TE domain  that was used for S-LSP creation (unlikely IMO
> > scenario) than it does not require the routing adjacency (in other
words, it
> > is an FA according to LSP-HIER definition), otherwise, it IS  NOT and FA
and
> > does require the direct routing peering in the domain it is advertised
to
> > make it useful as a TE link in this domain
> -----> I am sorry, but I am missing your point here completely. Are you
> saying that the statement "the end points of an LSP segment do not have a
> routing adjacency", is incorrect  or are you saying that "this is
> obvious" ? It is unclear to me  what exactly your argument is. Please
> clarify.

IB>> To be more clear I should say the following. If an LSP segment is
advertised into a different TE domain it SHOULD have a routing peering
between the ends in the domain it is advertised, otherwise, it could not be
used as a TE link in this domain. This is because generally speaking the
data plane connectivity does not guarantee control plane connectivity in the
domain the link is advertised, and in GMPLS a connection could not be used
as a TE link without control channel connecting nodes handling the link. The
same applies to hierarchical LSPs as well. The exception is LSP (stitching
or hierarchy) advertised into the same domain, in this case it is FA-LSP and
does not need direct routing peering to be used as a TE link.

Cheers,
Igor

>
> thanks,
> -arthi
>
> >
> > Cheers,
> > Igor
> >
> >
> >
> > ----- Original Message -----
> > From: <[email-masked]>
> > To: <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Friday, July 15, 2005 3:50 PM
> > Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
> >
> >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > > This draft is a work item of the Common Control and Measurement Plane
> > Working Group of the IETF.
> > >
> > > Title : Label Switched Path Stitching with Generalized MPLS Traffic
> > Engineering
> > > Author(s) : A. Ayyangar, J. Vasseur
> > > Filename : draft-ietf-ccamp-lsp-stitching-01.txt
> > > Pages : 19
> > > Date : 2005-7-15
> > >
> > > In certain scenarios, there may be a need to combine together two
> > >    different Generalized Multi-Protocol Label Switching (GMPLS) Label
> > >    Switched Paths (LSPs) such that in the data plane, a single end-to-
> > >    end (e2e) LSP is achieved and all traffic from one LSP is switched
> > >    onto the other LSP.  We will refer to this as "LSP stitching".
This
> > >    document covers cases where: a) the node performing the stitching
> > >    does not require configuration of every LSP pair to be stitched
> > >    together b) the node performing the stitching is not the egress of
> > >    any of the LSPs c) LSP stitching not only results in an end-to-end
> > >    LSP in the data plane, but there is also a corresponding end-to-end
> > >    LSP (RSVP session) in the control plane.  It might be possible to
> > >    configure a GMPLS node to switch the traffic from an LSP for which
it
> > >    is the egress, to another LSP for which it is the ingress, without
> > >    requiring any signaling or routing extensions whatsoever,
completely
> > >    transparent to other nodes.  This will also result in LSP stitching
> > >    in the data plane.  However, this document does not cover this
> > >    scenario of LSP stitching.
> > >
> > > A URL for this Internet-Draft is:
> > >
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt
> > >
> > > To remove yourself from the I-D Announcement list, send a message to
> > > [email-masked] with the word unsubscribe in the body of
the
> > message.
> > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > to change your subscription settings.
> > >
> > >
> > > Internet-Drafts are also available by anonymous FTP. Login with the
> > username
> > > "anonymous" and a password of your e-mail address. After logging in,
> > > type "cd internet-drafts" and then
> > > "get draft-ietf-ccamp-lsp-stitching-01.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > > [email-masked].
> > > In the body type:
> > > "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
> > >
> > > NOTE: The mail server at ietf.org can return the document in
> > > MIME-encoded form by using the "mpack" utility.  To use this
> > > feature, insert the command "ENCODING mime" before the "FILE"
> > > command.  To decode the response(s), you will need "munpack" or
> > > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > > exhibit different behavior, especially when dealing with
> > > "multipart" MIME messages (i.e. documents which have been split
> > > up into multiple messages), so check your local documentation on
> > > how to manipulate these messages.
> > >
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> > >
> >
>

Delivery-date: Mon, 18 Jul 2005 21:40:36 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Moving LSP ownership between control plane and management plane
Date: Mon, 18 Jul 2005 22:40:11 +0100

Hi,

You may not have seen this I-D because it lacks the "ccamp" element in its
name.

It discusses the issues for switching ownership of an LSP from the
management plane to the control plane and back again.

Can we have some comments from the CCAMP community (and especially from
the providers) on whether this function is necessary. Would you consider
deploying a control plane into an active network, or would you shut the
network (or at least the LSPs) for maintenance, and bring it (or them)
back up using the control plane?

The I-D also proposes a relatively simple solution and I would welcome
comments on this, too.

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 30, 2005 11:50 PM
Subject: I-D ACTION:draft-caviglia-mp2cpcp2mp-02.txt

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : GMPLS Signaling Extensions for the Transfer of
>                           Ownership of Label Switched Paths Between
>                           the Management and Control Planes
> Author(s) : D. Caviglia, et al.
> Filename : draft-caviglia-mp2cpcp2mp-02.txt
> Pages : 13
> Date : 2005-6-30
>
> During migration scenarios it may be desirable to transfer the
>    ownership of a Label Switched Path (LSP) from the Management Plane
>    (MP) to the Control Plane (CP), or vice versa. If the LSP is carrying
>    traffic this change needs to be made "in service," that is, without
>    affecting traffic.
>    This memo provides minor extensions to the Generalized Multi Protocol
>    Label Switching (GMPLS) signaling protocol, GRSVP_TE (Generalized
>    Resource Reservation Protocol with Traffic Engineering Extensions),
>    to enable such transfer of ownership and describes the proposed
>    procedures.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-caviglia-mp2cpcp2mp-02.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-caviglia-mp2cpcp2mp-02.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-caviglia-mp2cpcp2mp-02.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

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

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>

Delivery-date: Mon, 18 Jul 2005 21:40:29 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>, <[email-masked]>
Cc: "Igor Bryskin" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Date: Mon, 18 Jul 2005 22:23:17 +0100

Hi,

[[email-masked] and [email-masked] omitted from the cc
list]

[SNIP]

> > [dp] i would simply recommend to state what an LSP segment is (as
stated,
> > this comparison has been used to show differences in terms of control
> > plane processing and keeping it at that level is sensible) and not
embark
> > this document into terms and complex comparisons that are at the end
of
> > no real help
> <AA>----> I tend to agree with this.

Yes. If there is a need to compare the two techniques or to do
applicbality then that is another I-D. I am not sure that there is a need.

I would like to see this I-D restricted, as Arthi said, to a description
of what Stitching is and how it works.

> > 2. Why are you saying that a TE Link based on S-LSP can be used for
> > exactly
> > one e2e LSP? Parallel S-LSPs could be advertised as a single TE link
> > (bundle, see above) and hence can accomadate several e2e LSPs.
> >
> > [dp] i think the purpose is to say that a "triggered" LSP segment can
be
> > used by a single end-to-end LSP compared to the situation occurring
with
> > FA, where the triggered FA-LSP can then carry multiple nested LSPs
> <AA>------> As I mentioned in the email to Igor, the sentence
immediately
> following this does talk about the bundling case. What is missing is
> probably an additional sentence which explicitly states that when such
> bundling is use, more that one e2e LSP can be admitted over the LSP
> segment. That can be clarified.

Say rather, "can be admitted over a TE link supported by LSP segments".
That is, a segment can only admit one LSP, but a bundle of segments
advertised as a TE link, can admit multiple LSPs.

A

Delivery-date: Mon, 18 Jul 2005 20:49:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: Re: no more milestones?
Date: Mon, 18 Jul 2005 21:40:59 +0100

Hi Neil and Tom,

>> There are for instance, ops/management-related items
>> for "base" CCAMP items that need to be worked on.  The question
>> for me is why can't we continue to work on these?  I thought
>> these things were automatic chartered items, and thus should
>> be ongoing work items.
>
>You are right Tom to raise the point about the importance of
>network management here.  When we are dealing with large BW
>granularity co-cs mode technologies then virtually all the
>really important issues are concerned with the efficacy of the
>management-plane solution....the control-plane plays a minor
>support role (for a whole raft of technical/commercial/operational
>reasons). This is of course quite the opposite to a cl-ps layer
>network like IP.  We look to TMF for expertise here in developing
>the required management information models which are based on
>functional architecture.

I think you are right, Neil, that we would largely look outside the IETF
for management plane solutions.

What Tom is referring to, of course, is the management aspects necessary
as part of the control plane solutions. Aspects such as MIB modules, PIBs,
OAM etc.

I'm sure that I don't have to remind you that GMPLS is a control plane
technology not a data plane technology. The applicability of GMPLS is to
any co data plane technology and therefore it embraces both co-cs and
co-ps.

In answer to Tom's question, we are not prohibited from working on these
things, but we are rather adrift without any milestones. i would certainly
say that the right place to bring drafts for discussion is the CCAMP list.

However, before committing the WG to any specific drafts the chairs need
to be guided by an up-to-date charter with real milestones. I do hope that
the discussions in Paris will lead to these so that we can get on with the
work that everyone is so keen to do.

Cheers,
Adrian

Delivery-date: Mon, 18 Jul 2005 20:49:46 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: Re: no more milestones?
Date: Mon, 18 Jul 2005 21:47:09 +0100

Hi Dimitri,

> > I would like to see:
> > - a refinement of the charter to focus the next work items
> > - a year's worth of milestones to ensure we stay focused.
> >
> > On the other hand, we should aim to close down CCAMP and move the work
to
> > other or new working groups.
>
> coupling both sentences does it mean in your view
>
> 1) define several short-term milestones for refining topics that have
been
> already initiated and requires further well scoped attention
>
> 2) (brand) new topics should target new working groups - as already
> initiated with L1VPN for inst. - or existing working groups
>
> nevertheless, i do not see why this automatically means CCAMP can not
> remain the focal point concerning *base* GMPLS signaling and routing
> protocols

To answer your question: yes, I would like to see both. We need some
short-term milestones to guide and refine our work on existing topics. For
example, to complete the inter-domain work, possibly including issues of
protection and restoration.

But there are also some topics that are broadly covered by the CCAMP
scope, where we would benefit greatly by having a specific description on
the charter, and detailed milestones. I am thinking about L2SC, MRN,
MPLS/GMPLS interworking as discussed on the mailing list last November.
While we could sort of take on these things under the vague scope of the
current charter, I would prefer for us to be open, clear and focused.

And this covers your last point. I, too, don't see why CCAMP should not
remain the focal point for GMPLS signaling and routing protocols. However,
to do so in an efficient and proper manner, we should add the appropriate
milestones to the charter. If, on the other hand, we are not going to add
this stuff to the charter, it would be very important for us to be clear
about this so that the people working in these areas know that they must
take their work to another WG or BOF.

Thanks,
Adrian

Delivery-date: Mon, 18 Jul 2005 19:23:00 +0000
To: "Thomas D. Nadeau" <[email-masked]>
Cc: [email-masked], "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
From: [email-masked]
Subject: Re: no more milestones?
Date: Mon, 18 Jul 2005 21:20:39 +0200

Delivery-date: Mon, 18 Jul 2005 19:20:35 +0000
Date: Mon, 18 Jul 2005 12:20:01 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: Igor Bryskin <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

Igor,

> Thanks for the comments. However, I still want to hear from the authors,
> especially wrt purposes and intentions of this draft.
                ^^^^^^^^^^^^^^^^^^^^^^^^
<AA>----> You among other folks in the WG very strongly requested that
such an ID be written and hence this portion was removed from the
inter-domain ID and written as a separate ID given that it has broader
scope. The way you are posing the question, it appears as if you have
some doubts now. :-)

I didn't see the
> stament that LSP stitching is purely control plane feature( which is NOT
> IMO, just like LSP Hierarchy it has control and data plane sides).
> Neither I read that the intention of this draft is to describe only the
> control plane side.
<AA>-----> I don't think Dimitri made a statement which said "LSP
stitching is a purely control plane feature". I believe his point was that
the "special case of lsp hierarchy" applies to the control plane aspect.

Anyway, LSP stitching involves both control and data plane aspects
(label related procedures) and the draft explains both the aspects, where
applicable. Is there a problem ?

> Furthermore, I suggest not to use terms "FA-LSP" and "FA" in this draft.
<AA>----> Good suggestion. The draft atleast to my knowledge does not use
these terms in the context of LSP stitching. If you find any specific
cases of this usage, please point them out to me and I will be happy to
address them.

thanks,
-arthi

> It is surely the intention (:=) to cover inter-domain scenario ( I can't
> imagine a practical reason for using stitching in a single TE domain).
> Recall, that according to LSP-HIER and according to discussions that we
> had (initiated, by the way, by you), LSP is FA-LSP *only* if it is
> advertised into the same domain where it was created, which is not the
> case in the TE inter-domain context.
>
> See also comments in-line.
>
> Igor
>   ----- Original Message -----
>   From: [email-masked]
>   To: Igor Bryskin
>   Cc: [email-masked] ; [email-masked] ; [email-masked]
>   Sent: Sunday, July 17, 2005 4:36 PM
>   Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
>
>
>   igor - see in-line
>
>   beside this i welcome the serious re-writing effort provided by the authors compared to the previous version of this document
>
>   IB>> Agree, this a signifficant step in the right direction
>
>   "Igor Bryskin" <[email-masked]>
>   Sent by: [email-masked]
>   07/17/2005 13:18 AST
>
>   To: <[email-masked]>, <[email-masked]>
>   cc: <[email-masked]>
>   bcc:
>   Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
>
>
>
>
>   Arthi && JP.
>
>   I have a couple of questions.
>
>   1. Why are saying that LSP Stitching is a private case of LSP Hierarchy?
>
>   [dp] purpose is imho on the control plane mechanism and from this perspective only point 4) remains - the effect of having a "logical" TE link -
>
>   IMO there is more differences than similarities:
>   The differences are:
>   1) In case of H-LSP there is a data plane adjacency, while in case of S-LSP
>   there is none (as you correctly pointed out);
>   2) In case of H-LSP there is an adaptation in data plane (label push/pop for
>   PSC), while in case of S-LSP there is none - just simple cross-connecting
>   ( label swap) as in case of two "native " e2e LSP adjacent segments ;
>   3) H-LSP could be used by many e2e LSPs, while S-LSP could be used by
>   exactly one e2e LSP
>   4) Signaling is different - there is no label negotiation in stitching
>   5) H-LSP is used as a "true" data link, specifically there is a resource
>   allocation on the H-LSP edges, while in case of S-LSP there is none
>   6) From MLN point of view, H-LSP is created in a server (lower) layer, while
>   the S-LSP is created in the client (same as e2e LSP) layer.
>
>   There are two similarities that I can think of:
>   1) There is a signaling and possibly routing (see below) adjacencies between
>   the ends;
>   2) Both H-LSP and S-LSP could be advertised as separate TE links or as TE
>   bundles
>
>   I would recommend to dedicate a paragraph and enlist there similarities and
>   differencies
>
>   [dp] i would simply recommend to state what an LSP segment is (as stated, this comparison has been used to show differences in terms of control plane processing and keeping it at that level is sensible) and not embark this document into terms and complex comparisons that are at the end of no real help
>
>   2. Why are you saying that a TE Link based on S-LSP can be used for exactly
>   one e2e LSP? Parallel S-LSPs could be advertised as a single TE link
>   (bundle, see above) and hence can accomadate several e2e LSPs.
>
>   [dp] i think the purpose is to say that a "triggered" LSP segment can be used by a single end-to-end LSP compared to the situation occurring with FA, where the triggered FA-LSP can then carry multiple nested LSPs
>
>   IB>> It is possible to imagine that a single e2e LSP triggers several parallel S-LSPs which could be advertised as a single TE link. Besides, it is even more easy to imagine that S-LSPs are pre-provisioned in one TE domain and advertised as bundles into other domains
>
>   3. You are saying that S-LSP does not have a routing peering. Actually, in
>   this respect it is no different from H-LSP: if it is advertised as a TE link
>   into the same TE domain  that was used for S-LSP creation (unlikely IMO
>   scenario) than it does not require the routing adjacency (in other words, it
>   is an FA according to LSP-HIER definition), otherwise, it IS  NOT and FA and
>   does require the direct routing peering in the domain it is advertised to
>   make it useful as a TE link in this domain
>
>
>   [dp] again the document correctly states that a routing adj. is not going to be established on the LSP segment
>
>   IB>> This is not true. If an S-LSP is advertised in a different domain, there needs to be a routing peering between the ends of the S-LSP in the domain it is advertised in order for the S-LSP to be used as a TE link. There is no difference here compared to Hierarchical LSP (H-LSP)
>
>
>   Cheers,
>   Igor
>
>
>
>   ----- Original Message -----
>   From: <[email-masked]>
>   To: <[email-masked]>
>   Cc: <[email-masked]>
>   Sent: Friday, July 15, 2005 3:50 PM
>   Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
>
>
>   > A New Internet-Draft is available from the on-line Internet-Drafts
>   directories.
>   > This draft is a work item of the Common Control and Measurement Plane
>   Working Group of the IETF.
>   >
>   > Title : Label Switched Path Stitching with Generalized MPLS Traffic
>   Engineering
>   > Author(s) : A. Ayyangar, J. Vasseur
>   > Filename : draft-ietf-ccamp-lsp-stitching-01.txt
>   > Pages : 19
>   > Date : 2005-7-15
>   >
>   > In certain scenarios, there may be a need to combine together two
>   >    different Generalized Multi-Protocol Label Switching (GMPLS) Label
>   >    Switched Paths (LSPs) such that in the data plane, a single end-to-
>   >    end (e2e) LSP is achieved and all traffic from one LSP is switched
>   >    onto the other LSP.  We will refer to this as "LSP stitching".  This
>   >    document covers cases where: a) the node performing the stitching
>   >    does not require configuration of every LSP pair to be stitched
>   >    together b) the node performing the stitching is not the egress of
>   >    any of the LSPs c) LSP stitching not only results in an end-to-end
>   >    LSP in the data plane, but there is also a corresponding end-to-end
>   >    LSP (RSVP session) in the control plane.  It might be possible to
>   >    configure a GMPLS node to switch the traffic from an LSP for which it
>   >    is the egress, to another LSP for which it is the ingress, without
>   >    requiring any signaling or routing extensions whatsoever, completely
>   >    transparent to other nodes.  This will also result in LSP stitching
>   >    in the data plane.  However, this document does not cover this
>   >    scenario of LSP stitching.
>   >
>   > A URL for this Internet-Draft is:
>   > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt
>   >
>   > To remove yourself from the I-D Announcement list, send a message to
>   > [email-masked] with the word unsubscribe in the body of the
>   message.
>   > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>   > to change your subscription settings.
>   >
>   >
>   > Internet-Drafts are also available by anonymous FTP. Login with the
>   username
>   > "anonymous" and a password of your e-mail address. After logging in,
>   > type "cd internet-drafts" and then
>   > "get draft-ietf-ccamp-lsp-stitching-01.txt".
>   >
>   > A list of Internet-Drafts directories can be found in
>   > http://www.ietf.org/shadow.html
>   > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>   >
>   >
>   > Internet-Drafts can also be obtained by e-mail.
>   >
>   > Send a message to:
>   > [email-masked].
>   > In the body type:
>   > "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
>   >
>   > NOTE: The mail server at ietf.org can return the document in
>   > MIME-encoded form by using the "mpack" utility.  To use this
>   > feature, insert the command "ENCODING mime" before the "FILE"
>   > command.  To decode the response(s), you will need "munpack" or
>   > a MIME-compliant mail reader.  Different MIME-compliant mail readers
>   > exhibit different behavior, especially when dealing with
>   > "multipart" MIME messages (i.e. documents which have been split
>   > up into multiple messages), so check your local documentation on
>   > how to manipulate these messages.
>   >
>   >
>   > Below is the data which will enable a MIME compliant mail reader
>   > implementation to automatically retrieve the ASCII version of the
>   > Internet-Draft.
>   >
>
>

Delivery-date: Mon, 18 Jul 2005 18:57:41 +0000
Date: Mon, 18 Jul 2005 11:57:25 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: [email-masked]
cc: Igor Bryskin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

Hi Dimitri/Igor,

> beside this i welcome the serious re-writing effort provided by the
> authors compared to the previous version of this document
<AA>---> Thanks!

<snipped>
> [dp] i would simply recommend to state what an LSP segment is (as stated,
> this comparison has been used to show differences in terms of control
> plane processing and keeping it at that level is sensible) and not embark
> this document into terms and complex comparisons that are at the end of
> no real help
<AA>----> I tend to agree with this.

> 2. Why are you saying that a TE Link based on S-LSP can be used for
> exactly
> one e2e LSP? Parallel S-LSPs could be advertised as a single TE link
> (bundle, see above) and hence can accomadate several e2e LSPs.
>
> [dp] i think the purpose is to say that a "triggered" LSP segment can be
> used by a single end-to-end LSP compared to the situation occurring with
> FA, where the triggered FA-LSP can then carry multiple nested LSPs
<AA>------> As I mentioned in the email to Igor, the sentence immediately
following this does talk about the bundling case. What is missing is
probably an additional sentence which explicitly states that when such
bundling is use, more that one e2e LSP can be admitted over the LSP
segment. That can be clarified.

thanks,
-arthi

> 3. You are saying that S-LSP does not have a routing peering. Actually,
> in
> this respect it is no different from H-LSP: if it is advertised as a TE
> link
> into the same TE domain  that was used for S-LSP creation (unlikely IMO
> scenario) than it does not require the routing adjacency (in other words,
> it
> is an FA according to LSP-HIER definition), otherwise, it IS  NOT and FA
> and
> does require the direct routing peering in the domain it is advertised to
> make it useful as a TE link in this domain
>
> [dp] again the document correctly states that a routing adj. is not going
> to be established on the LSP segment
> Cheers,
> Igor
>
>
>
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, July 15, 2005 3:50 PM
> Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
>
>
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Common Control and Measurement Plane
> Working Group of the IETF.
> >
> > Title : Label Switched Path Stitching with Generalized MPLS Traffic
> Engineering
> > Author(s) : A. Ayyangar, J. Vasseur
> > Filename : draft-ietf-ccamp-lsp-stitching-01.txt
> > Pages : 19
> > Date : 2005-7-15
> >
> > In certain scenarios, there may be a need to combine together two
> >    different Generalized Multi-Protocol Label Switching (GMPLS) Label
> >    Switched Paths (LSPs) such that in the data plane, a single end-to-
> >    end (e2e) LSP is achieved and all traffic from one LSP is switched
> >    onto the other LSP.  We will refer to this as "LSP stitching".  This
> >    document covers cases where: a) the node performing the stitching
> >    does not require configuration of every LSP pair to be stitched
> >    together b) the node performing the stitching is not the egress of
> >    any of the LSPs c) LSP stitching not only results in an end-to-end
> >    LSP in the data plane, but there is also a corresponding end-to-end
> >    LSP (RSVP session) in the control plane.  It might be possible to
> >    configure a GMPLS node to switch the traffic from an LSP for which
> it
> >    is the egress, to another LSP for which it is the ingress, without
> >    requiring any signaling or routing extensions whatsoever, completely
> >    transparent to other nodes.  This will also result in LSP stitching
> >    in the data plane.  However, this document does not cover this
> >    scenario of LSP stitching.
> >
> > A URL for this Internet-Draft is:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > [email-masked] with the word unsubscribe in the body of
> the
> message.
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-ietf-ccamp-lsp-stitching-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > [email-masked].
> > In the body type:
> > "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility.  To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command.  To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
>
>
>

Delivery-date: Mon, 18 Jul 2005 18:54:44 +0000
Date: Mon, 18 Jul 2005 11:51:57 -0700 (PDT)
From: Arthi Ayyangar <[email-masked]>
To: Igor Bryskin <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 

Hi Igor,

Please see inline.

> 1. Why are saying that LSP Stitching is a private case of LSP Hierarchy?

> there is more differences than similarities:
> The differences are:
> 1) In case of H-LSP there is a data plane adjacency, while in case of S-LSP
> there is none (as you correctly pointed out);
> 2) In case of H-LSP there is an adaptation in data plane (label push/pop for
> PSC), while in case of S-LSP there is none - just simple cross-connecting
> ( label swap) as in case of two "native " e2e LSP adjacent segments ;
> 3) H-LSP could be used by many e2e LSPs, while S-LSP could be used by
> exactly one e2e LSP
> 4) Signaling is different - there is no label negotiation in stitching
> 5) H-LSP is used as a "true" data link, specifically there is a resource
> allocation on the H-LSP edges, while in case of S-LSP there is none
> 6) From MLN point of view, H-LSP is created in a server (lower) layer, while
> the S-LSP is created in the client (same as e2e LSP) layer.
>
> There are two similarities that I can think of:
> 1) There is a signaling and possibly routing (see below) adjacencies between
> the ends;
> 2) Both H-LSP and S-LSP could be advertised as separate TE links or as TE
> bundles
>
> I would recommend to dedicate a paragraph and enlist there similarities and
> differencies
-------> Based on the discussions on the list over the last revision, the
message that the authors received was that we do not want to go about such
a lengthy discussion of similarities and differences (NOTE that the draft
already does clearly highlight them where applicable). Instead we want
this ID to simply explain how LSP stitching functions. In other words the
idea was to make this ID a complete document by itself. But since it does
borrow concepts from the LSP hierarchy ID, just state the concepts that
are applicable or inapplicable.

> 2. Why are you saying that a TE Link based on S-LSP can be used for exactly
> one e2e LSP? Parallel S-LSPs could be advertised as a single TE link
> (bundle, see above) and hence can accomadate several e2e LSPs.
----> Igor, the draft does talk about this Bundling case.

> 3. You are saying that S-LSP does not have a routing peering. Actually, in
> this respect it is no different from H-LSP: if it is advertised as a TE link
> into the same TE domain  that was used for S-LSP creation (unlikely IMO
> scenario) than it does not require the routing adjacency (in other words, it
> is an FA according to LSP-HIER definition), otherwise, it IS  NOT and FA and
> does require the direct routing peering in the domain it is advertised to
> make it useful as a TE link in this domain
-----> I am sorry, but I am missing your point here completely. Are you
saying that the statement "the end points of an LSP segment do not have a
routing adjacency", is incorrect  or are you saying that "this is
obvious" ? It is unclear to me  what exactly your argument is. Please
clarify.

thanks,
-arthi

>
> Cheers,
> Igor
>
>
>
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, July 15, 2005 3:50 PM
> Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
>
>
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Common Control and Measurement Plane
> Working Group of the IETF.
> >
> > Title : Label Switched Path Stitching with Generalized MPLS Traffic
> Engineering
> > Author(s) : A. Ayyangar, J. Vasseur
> > Filename : draft-ietf-ccamp-lsp-stitching-01.txt
> > Pages : 19
> > Date : 2005-7-15
> >
> > In certain scenarios, there may be a need to combine together two
> >    different Generalized Multi-Protocol Label Switching (GMPLS) Label
> >    Switched Paths (LSPs) such that in the data plane, a single end-to-
> >    end (e2e) LSP is achieved and all traffic from one LSP is switched
> >    onto the other LSP.  We will refer to this as "LSP stitching".  This
> >    document covers cases where: a) the node performing the stitching
> >    does not require configuration of every LSP pair to be stitched
> >    together b) the node performing the stitching is not the egress of
> >    any of the LSPs c) LSP stitching not only results in an end-to-end
> >    LSP in the data plane, but there is also a corresponding end-to-end
> >    LSP (RSVP session) in the control plane.  It might be possible to
> >    configure a GMPLS node to switch the traffic from an LSP for which it
> >    is the egress, to another LSP for which it is the ingress, without
> >    requiring any signaling or routing extensions whatsoever, completely
> >    transparent to other nodes.  This will also result in LSP stitching
> >    in the data plane.  However, this document does not cover this
> >    scenario of LSP stitching.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > [email-masked] with the word unsubscribe in the body of the
> message.
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-ietf-ccamp-lsp-stitching-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > [email-masked].
> > In the body type:
> > "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility.  To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command.  To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
>

Delivery-date: Mon, 18 Jul 2005 13:39:19 +0000
Content-class: urn:content-classes:message
Subject: RE: no more milestones?
Date: Mon, 18 Jul 2005 14:38:24 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Thomas D. Nadeau Sent: 18 July 2005 14:06
> On Jul 18, 2005, at 9:00 AM, [email-masked] wrote:
>=20
> >
> > hi adrian
> >
> >
> >> I would like to see:
> >> - a refinement of the charter to focus the next work items
> >> - a year's worth of milestones to ensure we stay focused.
> >>
> >> On the other hand, we should aim to close down CCAMP and move the
> >> work to
> >> other or new working groups.
> >>
> >
> > coupling both sentences does it mean in your view
> >
> > 1) define several short-term milestones for refining topics that =20
> > have been
> > already initiated and requires further well scoped attention
> >
> > 2) (brand) new topics should target new working groups - as already
> > initiated with L1VPN for inst. - or existing working groups
> >
> > nevertheless, i do not see why this automatically means=20
> CCAMP can not
> > remain the focal point concerning *base* GMPLS signaling and routing
> > protocols
>=20
>      I agree. There are for instance, ops/management-related items
> for "base" CCAMP items that need to be worked on.  The question
> for me is why can't we continue to work on these?  I thought
> these things were automatic chartered items, and thus should
> be ongoing work items.
>=20
>      --Tom
NH=3D> You are right Tom to raise the point about the importance of
network management here.  When we are dealing with large BW granularity
co-cs mode technologies then virtually all the really important issues
are concerned with the efficacy of the management-plane solution....the
control-plane plays a minor support role (for a whole raft of
technical/commercial/operational reasons).  This is of course quite the
opposite to a cl-ps layer network like IP.  We look to TMF for expertise
here in developing the required management information models which are
based on functional architecture.

regards, Neil
>=20
>=20
> > thanks,
> > - dimitri.
>=20
>=20

Delivery-date: Mon, 18 Jul 2005 13:06:36 +0000
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: no more milestones?
Date: Mon, 18 Jul 2005 09:06:07 -0400
To: [email-masked]

On Jul 18, 2005, at 9:00 AM, [email-masked] wrote:

>
> hi adrian
>
>
>> I would like to see:
>> - a refinement of the charter to focus the next work items
>> - a year's worth of milestones to ensure we stay focused.
>>
>> On the other hand, we should aim to close down CCAMP and move the  
>> work to
>> other or new working groups.
>>
>
> coupling both sentences does it mean in your view
>
> 1) define several short-term milestones for refining topics that  
> have been
> already initiated and requires further well scoped attention
>
> 2) (brand) new topics should target new working groups - as already
> initiated with L1VPN for inst. - or existing working groups
>
> nevertheless, i do not see why this automatically means CCAMP can not
> remain the focal point concerning *base* GMPLS signaling and routing
> protocols

     I agree. There are for instance, ops/management-related items
for "base" CCAMP items that need to be worked on.  The question
for me is why can't we continue to work on these?  I thought
these things were automatic chartered items, and thus should
be ongoing work items.

     --Tom

> thanks,
> - dimitri.

Delivery-date: Mon, 18 Jul 2005 13:01:35 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
From: [email-masked]
Subject: Re: no more milestones?
Date: Mon, 18 Jul 2005 15:00:51 +0200

hi adrian

> I would like to see:
> - a refinement of the charter to focus the next work items
> - a year's worth of milestones to ensure we stay focused.
>
> On the other hand, we should aim to close down CCAMP and move the work to
> other or new working groups.

coupling both sentences does it mean in your view

1) define several short-term milestones for refining topics that have been
already initiated and requires further well scoped attention

2) (brand) new topics should target new working groups - as already
initiated with L1VPN for inst. - or existing working groups

nevertheless, i do not see why this automatically means CCAMP can not
remain the focal point concerning *base* GMPLS signaling and routing
protocols

thanks,
- dimitri.

Delivery-date: Mon, 18 Jul 2005 12:07:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>
Cc: <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: Re: no more milestones?
Date: Mon, 18 Jul 2005 13:07:28 +0100

Hi Tom,

Yes, CCAMP is a little bit in limbo at the moment.

Since Minneapolis we have:
- completed our last milestone (submitted the GMPLS MIB I-Ds)
- advanced 8 I-Ds to the ADs after WG last call
- advanced 3 I-Ds to the MIB doctors after WG last call
- completed WG last call on 2 further I-Ds

This is pretty good progress. It leaves us with 7 active working group
drafts all of which are nearing completion.

There is a lot of work going on around the topic of GMPLS and we should
find a home for that work within the IETF. As evidenced by the discussions
on the mailing list this time last year, there is a lot of support for
placing that work in CCAMP. The preliminary charter discussions we had in
November last year indicated the priorities that the community placed on
this work, but I think some new topics have arisen in the mean time.

I would like to see:
- a refinement of the charter to focus the next work items
- a year's worth of milestones to ensure we stay focused.

On the other hand, we should aim to close down CCAMP and move the work to
other or new working groups.

Hopefully these are issues that can be resolved in the meeting in Paris.
I would very much like to hear people's opinions expressed on this list
before the meeting, and comments/guidance from the ADs would be helpful.

Cheers,
Adrian
----- Original Message ----- 
From: "Thomas D. Nadeau" <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 15, 2005 1:50 AM
Subject: no more milestones?

>      Why the WG is stuck without any milestones
> and unable to take on more work?  Are there
> any plans to extend the charter?
>
>      --Tom

Delivery-date: Mon, 18 Jul 2005 12:07:48 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Date: Mon, 18 Jul 2005 08:06:19 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_0078_01C58B6F.94415EF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dimitri,

Thanks for the comments. However, I still want to hear from the authors, =
especially wrt purposes and intentions of this draft. I didn't see the =
stament that LSP stitching is purely control plane feature( which is NOT =
IMO, just like LSP Hierarchy it has control and data plane sides). =
Neither I read that the intention of this draft is to describe only the =
control plane side.=20

Furthermore, I suggest not to use terms "FA-LSP" and "FA" in this draft. =
It is surely the intention (:=3D) to cover inter-domain scenario ( I =
can't imagine a practical reason for using stitching in a single TE =
domain). Recall, that according to LSP-HIER and according to discussions =
that we had (initiated, by the way, by you), LSP is FA-LSP *only* if it =
is advertised into the same domain where it was created, which is not =
the case in the TE inter-domain context.

See also comments in-line.

Igor =20
  ----- Original Message -----=20
  From: [email-masked]=20
  To: Igor Bryskin=20
  Cc: [email-masked] ; [email-masked] ; =
[email-masked]=20
  Sent: Sunday, July 17, 2005 4:36 PM
  Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

  igor - see in-line

  beside this i welcome the serious re-writing effort provided by the =
authors compared to the previous version of this document

  IB>> Agree, this a signifficant step in the right direction

  "Igor Bryskin" <[email-masked]>
  Sent by: [email-masked]
  07/17/2005 13:18 AST

  To: <[email-masked]>, <[email-masked]>
  cc: <[email-masked]>
  bcc:=20
  Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

  Arthi && JP.

  I have a couple of questions.

  1. Why are saying that LSP Stitching is a private case of LSP =
Hierarchy?=20

  [dp] purpose is imho on the control plane mechanism and from this =
perspective only point 4) remains - the effect of having a "logical" TE =
link -

  IMO there is more differences than similarities:
  The differences are:
  1) In case of H-LSP there is a data plane adjacency, while in case of =
S-LSP
  there is none (as you correctly pointed out);
  2) In case of H-LSP there is an adaptation in data plane (label =
push/pop for
  PSC), while in case of S-LSP there is none - just simple =
cross-connecting
  ( label swap) as in case of two "native " e2e LSP adjacent segments ;
  3) H-LSP could be used by many e2e LSPs, while S-LSP could be used by
  exactly one e2e LSP
  4) Signaling is different - there is no label negotiation in stitching
  5) H-LSP is used as a "true" data link, specifically there is a =
resource
  allocation on the H-LSP edges, while in case of S-LSP there is none
  6) From MLN point of view, H-LSP is created in a server (lower) layer, =
while
  the S-LSP is created in the client (same as e2e LSP) layer.

  There are two similarities that I can think of:
  1) There is a signaling and possibly routing (see below) adjacencies =
between
  the ends;
  2) Both H-LSP and S-LSP could be advertised as separate TE links or as =
TE
  bundles

  I would recommend to dedicate a paragraph and enlist there =
similarities and
  differencies

  [dp] i would simply recommend to state what an LSP segment is (as =
stated, this comparison has been used to show differences in terms of =
control plane processing and keeping it at that level is sensible) and =
not embark this document into terms and complex comparisons that are at =
the end of no real help

  2. Why are you saying that a TE Link based on S-LSP can be used for =
exactly
  one e2e LSP? Parallel S-LSPs could be advertised as a single TE link
  (bundle, see above) and hence can accomadate several e2e LSPs.

  [dp] i think the purpose is to say that a "triggered" LSP segment can =
be used by a single end-to-end LSP compared to the situation occurring =
with FA, where the triggered FA-LSP can then carry multiple nested LSPs

  IB>> It is possible to imagine that a single e2e LSP triggers several =
parallel S-LSPs which could be advertised as a single TE link. Besides, =
it is even more easy to imagine that S-LSPs are pre-provisioned in one =
TE domain and advertised as bundles into other domains

  3. You are saying that S-LSP does not have a routing peering. =
Actually, in
  this respect it is no different from H-LSP: if it is advertised as a =
TE link
  into the same TE domain  that was used for S-LSP creation (unlikely =
IMO
  scenario) than it does not require the routing adjacency (in other =
words, it
  is an FA according to LSP-HIER definition), otherwise, it IS  NOT and =
FA and
  does require the direct routing peering in the domain it is advertised =
to
  make it useful as a TE link in this domain

  [dp] again the document correctly states that a routing adj. is not =
going to be established on the LSP segment=20

  IB>> This is not true. If an S-LSP is advertised in a different =
domain, there needs to be a routing peering between the ends of the =
S-LSP in the domain it is advertised in order for the S-LSP to be used =
as a TE link. There is no difference here compared to Hierarchical LSP =
(H-LSP)

  =20
  Cheers,
  Igor

  ----- Original Message -----
  From: <[email-masked]>
  To: <[email-masked]>
  Cc: <[email-masked]>
  Sent: Friday, July 15, 2005 3:50 PM
  Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

  > A New Internet-Draft is available from the on-line Internet-Drafts
  directories.
  > This draft is a work item of the Common Control and Measurement =
Plane
  Working Group of the IETF.
  >
  > Title : Label Switched Path Stitching with Generalized MPLS Traffic
  Engineering
  > Author(s) : A. Ayyangar, J. Vasseur
  > Filename : draft-ietf-ccamp-lsp-stitching-01.txt
  > Pages : 19
  > Date : 2005-7-15
  >
  > In certain scenarios, there may be a need to combine together two
  >    different Generalized Multi-Protocol Label Switching (GMPLS) =
Label
  >    Switched Paths (LSPs) such that in the data plane, a single =
end-to-
  >    end (e2e) LSP is achieved and all traffic from one LSP is =
switched
  >    onto the other LSP.  We will refer to this as "LSP stitching".  =
This
  >    document covers cases where: a) the node performing the stitching
  >    does not require configuration of every LSP pair to be stitched
  >    together b) the node performing the stitching is not the egress =
of
  >    any of the LSPs c) LSP stitching not only results in an =
end-to-end
  >    LSP in the data plane, but there is also a corresponding =
end-to-end
  >    LSP (RSVP session) in the control plane.  It might be possible to
  >    configure a GMPLS node to switch the traffic from an LSP for =
which it
  >    is the egress, to another LSP for which it is the ingress, =
without
  >    requiring any signaling or routing extensions whatsoever, =
completely
  >    transparent to other nodes.  This will also result in LSP =
stitching
  >    in the data plane.  However, this document does not cover this
  >    scenario of LSP stitching.
  >
  > A URL for this Internet-Draft is:
  > =
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt=

  >
  > To remove yourself from the I-D Announcement list, send a message to
  > [email-masked] with the word unsubscribe in the body =
of the
  message.
  > You can also visit =
https://www1.ietf.org/mailman/listinfo/I-D-announce
  > to change your subscription settings.
  >
  >
  > Internet-Drafts are also available by anonymous FTP. Login with the
  username
  > "anonymous" and a password of your e-mail address. After logging in,
  > type "cd internet-drafts" and then
  > "get draft-ietf-ccamp-lsp-stitching-01.txt".
  >
  > A list of Internet-Drafts directories can be found in
  > http://www.ietf.org/shadow.html
  > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
  >
  >
  > Internet-Drafts can also be obtained by e-mail.
  >
  > Send a message to:
  > [email-masked].
  > In the body type:
  > "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
  >
  > NOTE: The mail server at ietf.org can return the document in
  > MIME-encoded form by using the "mpack" utility.  To use this
  > feature, insert the command "ENCODING mime" before the "FILE"
  > command.  To decode the response(s), you will need "munpack" or
  > a MIME-compliant mail reader.  Different MIME-compliant mail readers
  > exhibit different behavior, especially when dealing with
  > "multipart" MIME messages (i.e. documents which have been split
  > up into multiple messages), so check your local documentation on
  > how to manipulate these messages.
  >
  >
  > Below is the data which will enable a MIME compliant mail reader
  > implementation to automatically retrieve the ASCII version of the
  > Internet-Draft.
  >

------=_NextPart_000_0078_01C58B6F.94415EF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dimitri,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks for the comments. However, I =
still want to=20
hear from the authors, especially wrt purposes and intentions of this =
draft. I=20
didn't see the stament that LSP stitching is purely control plane =
feature( which=20
is NOT&nbsp;IMO, just like LSP Hierarchy it has control and data plane =
sides).=20
Neither I read that the intention of this draft is to describe only the =
control=20
plane side. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Furthermore, I suggest not to use terms =
"FA-LSP"=20
and "FA" in this draft. It is surely the intention (:=3D) to cover =
inter-domain=20
scenario ( I can't imagine a practical reason for using stitching in a =
single TE=20
domain). Recall, that according to LSP-HIER and according to discussions =
that we=20
had (initiated, by the way, by you),&nbsp;LSP is FA-LSP *only* if it is=20
advertised into the same domain where it was created, which is not the =
case in=20
the TE inter-domain context.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>See also comments in-line.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Igor&nbsp;&nbsp;</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  =
href=3D"mailto:[email-masked]">Dimitri.Papadimitriou@al=
catel.be</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Igor Bryskin</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> ; <A=20
  title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> =
; <A=20
  title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, July 17, 2005 =
4:36 PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: I-D=20
  ACTION:draft-ietf-ccamp-lsp-stitching-01.txt</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
  face=3DArial size=3D2></FONT><BR></DIV>
  <P><FONT face=3DMonospace,Courier>igor - see in-line</FONT></P>
  <P><FONT face=3DMonospace,Courier>beside this i welcome the serious =
re-writing=20
  effort provided by the authors compared to the previous version of =
this=20
  document</FONT></P>
  <P><FONT face=3D"Courier New">IB&gt;&gt; Agree, this a signifficant =
step in the=20
  right direction</FONT><BR><BR><FONT size=3D2><B>"Igor Bryskin" &lt;<A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</B></FONT><=
BR><FONT=20
  size=3D2>Sent by: <A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A></FO=
NT><BR><FONT=20
  size=3D2>07/17/2005 13:18 AST</FONT><BR><BR><FONT size=3D2>To:</FONT> =
<FONT=20
  size=3D2>&lt;<A=20
  href=3D"mailto:[email-masked]">[email-masked]</A>&gt;, =
&lt;<A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;=
</FONT><BR><FONT=20
  size=3D2>cc:</FONT> <FONT size=3D2>&lt;<A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</FONT><BR><=
FONT=20
  size=3D2>bcc:</FONT> <BR><FONT size=3D2>Subject:</FONT> <FONT =
size=3D2>Re: I-D=20
  ACTION:draft-ietf-ccamp-lsp-stitching-01.txt</FONT><BR><BR><BR></P>
  <P><FONT face=3DMonospace,Courier>Arthi &amp;&amp; =
JP.<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>I have a couple of =
questions.<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>1. Why are saying that LSP Stitching is a =
private case=20
  of LSP Hierarchy? </FONT></P>
  <P><FONT face=3DMonospace,Courier>[dp] purpose is imho on the control =
plane=20
  mechanism and from this perspective only point 4) remains - the effect =
of=20
  having a "logical" TE link -</FONT></P>
  <P><FONT face=3DMonospace,Courier>IMO there is more differences than=20
  similarities:<BR>The differences are:<BR>1) In case of H-LSP there is =
a data=20
  plane adjacency, while in case of S-LSP<BR>there is none (as you =
correctly=20
  pointed out);<BR>2) In case of H-LSP there is an adaptation in data =
plane=20
  (label push/pop for<BR>PSC), while in case of S-LSP there is none - =
just=20
  simple cross-connecting<BR>( label swap) as in case of two "native " =
e2e LSP=20
  adjacent segments ;<BR>3) H-LSP could be used by many e2e LSPs, while =
S-LSP=20
  could be used by<BR>exactly one e2e LSP<BR>4) Signaling is different - =
there=20
  is no label negotiation in stitching<BR>5) H-LSP is used as a "true" =
data=20
  link, specifically there is a resource<BR>allocation on the H-LSP =
edges, while=20
  in case of S-LSP there is none<BR>6) From MLN point of view, H-LSP is =
created=20
  in a server (lower) layer, while<BR>the S-LSP is created in the client =
(same=20
  as e2e LSP) layer.<BR></FONT><BR><FONT face=3DMonospace,Courier>There =
are two=20
  similarities that I can think of:<BR>1) There is a signaling and =
possibly=20
  routing (see below) adjacencies between<BR>the ends;<BR>2) Both H-LSP =
and=20
  S-LSP could be advertised as separate TE links or as =
TE<BR>bundles<BR><BR>I=20
  would recommend to dedicate a paragraph and enlist there similarities=20
  and<BR>differencies</FONT></P>
  <P><FONT face=3DMonospace,Courier>[dp] i would simply recommend to =
state what an=20
  LSP segment is (as stated, this comparison has been used to show =
differences=20
  in terms of control plane processing and keeping it at that level is =
sensible)=20
  and not embark this document into terms and complex comparisons that =
are at=20
  the end of no real help<BR><BR>2. Why are you saying that a TE Link =
based on=20
  S-LSP can be used for exactly<BR>one e2e LSP? Parallel S-LSPs could be =

  advertised as a single TE link<BR>(bundle, see above) and hence can =
accomadate=20
  several e2e LSPs.</FONT></P>
  <P><FONT face=3DMonospace,Courier>[dp] i think the purpose is to say =
that a=20
  "triggered" LSP segment can be used by a single end-to-end LSP =
compared to the=20
  situation occurring with FA, where the triggered FA-LSP can then carry =

  multiple nested LSPs</FONT></P>
  <P><FONT face=3DMonospace,Courier>IB&gt;&gt; It is possible to imagine =
that a=20
  single e2e LSP&nbsp;triggers several parallel S-LSPs which could be =
advertised=20
  as a single TE link. Besides, it is even more easy to imagine that =
S-LSPs are=20
  pre-provisioned in one TE domain and advertised as bundles into other=20
  domains<BR><BR>3. You are saying that S-LSP does not have a routing =
peering.=20
  Actually, in<BR>this respect it is no different from H-LSP: if it is=20
  advertised as a TE link<BR>into the same TE domain &nbsp;that was used =
for=20
  S-LSP creation (unlikely IMO<BR>scenario) than it does not require the =
routing=20
  adjacency (in other words, it<BR>is an FA according to LSP-HIER =
definition),=20
  otherwise, it IS &nbsp;NOT and FA and<BR>does require the direct =
routing=20
  peering in the domain it is advertised to<BR>make it useful as a TE =
link in=20
  this domain<BR></P></FONT>
  <P><FONT face=3DMonospace,Courier>[dp] again the document correctly =
states that=20
  a routing adj. is not going to be established on the LSP segment =
</FONT></P>
  <P><FONT face=3DArial size=3D2>IB&gt;&gt; This is not true. If an =
S-LSP is=20
  advertised in a different domain, there needs to be a routing peering =
between=20
  the ends of the S-LSP in the domain it is advertised in order for the =
S-LSP to=20
  be used as a TE link. There is no difference here compared to =
Hierarchical LSP=20
  (H-LSP)</FONT></P>
  <P>&nbsp;<BR><FONT=20
  face=3DMonospace,Courier>Cheers,<BR>Igor<BR></FONT><BR><BR><BR><FONT=20
  face=3DMonospace,Courier>----- Original Message -----<BR>From:=20
  &lt;[email-masked]&gt;<BR>To: =
&lt;[email-masked]&gt;<BR>Cc:=20
  &lt;[email-masked]&gt;<BR>Sent: Friday, July 15, 2005 3:50 =
PM<BR>Subject:=20
  I-D =
ACTION:draft-ietf-ccamp-lsp-stitching-01.txt<BR></FONT><BR><BR><FONT=20
  face=3DMonospace,Courier>&gt; A New Internet-Draft is available from =
the on-line=20
  Internet-Drafts<BR>directories.<BR>&gt; This draft is a work item of =
the=20
  Common Control and Measurement Plane<BR>Working Group of the=20
  IETF.<BR>&gt;<BR>&gt; Title : Label Switched Path Stitching with =
Generalized=20
  MPLS Traffic<BR>Engineering<BR>&gt; Author(s) : A. Ayyangar, J.=20
  Vasseur<BR>&gt; Filename : =
draft-ietf-ccamp-lsp-stitching-01.txt<BR>&gt; Pages=20
  : 19<BR>&gt; Date : 2005-7-15<BR>&gt;<BR>&gt; In certain scenarios, =
there may=20
  be a need to combine together two<BR>&gt; &nbsp; &nbsp;different =
Generalized=20
  Multi-Protocol Label Switching (GMPLS) Label<BR>&gt; &nbsp; =
&nbsp;Switched=20
  Paths (LSPs) such that in the data plane, a single end-to-<BR>&gt; =
&nbsp;=20
  &nbsp;end (e2e) LSP is achieved and all traffic from one LSP is=20
  switched<BR>&gt; &nbsp; &nbsp;onto the other LSP. &nbsp;We will refer =
to this=20
  as "LSP stitching". &nbsp;This<BR>&gt; &nbsp; &nbsp;document covers =
cases=20
  where: a) the node performing the stitching<BR>&gt; &nbsp; &nbsp;does =
not=20
  require configuration of every LSP pair to be stitched<BR>&gt; &nbsp;=20
  &nbsp;together b) the node performing the stitching is not the egress=20
  of<BR>&gt; &nbsp; &nbsp;any of the LSPs c) LSP stitching not only =
results in=20
  an end-to-end<BR>&gt; &nbsp; &nbsp;LSP in the data plane, but there is =
also a=20
  corresponding end-to-end<BR>&gt; &nbsp; &nbsp;LSP (RSVP session) in =
the=20
  control plane. &nbsp;It might be possible to<BR>&gt; &nbsp; =
&nbsp;configure a=20
  GMPLS node to switch the traffic from an LSP for which it<BR>&gt; =
&nbsp;=20
  &nbsp;is the egress, to another LSP for which it is the ingress,=20
  without<BR>&gt; &nbsp; &nbsp;requiring any signaling or routing =
extensions=20
  whatsoever, completely<BR>&gt; &nbsp; &nbsp;transparent to other =
nodes.=20
  &nbsp;This will also result in LSP stitching<BR>&gt; &nbsp; &nbsp;in =
the data=20
  plane. &nbsp;However, this document does not cover this<BR>&gt; &nbsp; =

  &nbsp;scenario of LSP stitching.<BR>&gt;<BR>&gt; A URL for this =
Internet-Draft=20
  is:<BR>&gt; <A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitchin=
g-01.txt">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitch=
ing-01.txt</A><BR>&gt;<BR>&gt;=20
  To remove yourself from the I-D Announcement list, send a message =
to<BR>&gt;=20
  [email-masked] with the word unsubscribe in the body of =

  the<BR>message.<BR>&gt; You can also visit <A=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1=
.ietf.org/mailman/listinfo/I-D-announce</A><BR>&gt;=20
  to change your subscription settings.<BR>&gt;<BR>&gt;<BR>&gt; =
Internet-Drafts=20
  are also available by anonymous FTP. Login with =
the<BR>username<BR>&gt;=20
  "anonymous" and a password of your e-mail address. After logging =
in,<BR>&gt;=20
  type "cd internet-drafts" and then<BR>&gt; "get=20
  draft-ietf-ccamp-lsp-stitching-01.txt".<BR>&gt;<BR>&gt; A list of=20
  Internet-Drafts directories can be found in<BR>&gt; <A=20
  =
href=3D"http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html<=
/A><BR>&gt;=20
  or <A=20
  =
href=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt</A><BR>&gt;<BR>&gt;<BR>&gt;=20
  Internet-Drafts can also be obtained by e-mail.<BR>&gt;<BR>&gt; Send a =
message=20
  to:<BR>&gt; [email-masked].<BR>&gt; In the body type:<BR>&gt; "FILE =

  =
/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".<BR>&gt;<BR>&gt; =
NOTE:=20
  The mail server at ietf.org can return the document in<BR>&gt; =
MIME-encoded=20
  form by using the "mpack" utility. &nbsp;To use this<BR>&gt; feature, =
insert=20
  the command "ENCODING mime" before the "FILE"<BR>&gt; command. =
&nbsp;To decode=20
  the response(s), you will need "munpack" or<BR>&gt; a MIME-compliant =
mail=20
  reader. &nbsp;Different MIME-compliant mail readers<BR>&gt; exhibit =
different=20
  behavior, especially when dealing with<BR>&gt; "multipart" MIME =
messages (i.e.=20
  documents which have been split<BR>&gt; up into multiple messages), so =
check=20
  your local documentation on<BR>&gt; how to manipulate these=20
  messages.<BR>&gt;<BR>&gt;<BR>&gt; Below is the data which will enable =
a MIME=20
  compliant mail reader<BR>&gt; implementation to automatically retrieve =
the=20
  ASCII version of the<BR>&gt;=20
Internet-Draft.<BR>&gt;<BR></P></FONT></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0078_01C58B6F.94415EF0--

Delivery-date: Mon, 18 Jul 2005 08:15:14 +0000
Date: Mon, 18 Jul 2005 09:11:56 +0000
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------xsxuvegyuekptxkkwapv
Content-Type: text/plain; charset="UTF-8"; format="flowed"

+----------------------------------------------------+

Panda GateDefender has detected malicious content (Virus) in the following file: [Doll.cpl]
W32/Bagle.AH.worm

The file has been deleted to protect the network.
07/18/2005 08:05 +0100

www.pandasoftware.com

+----------------------------------------------------+

----------xsxuvegyuekptxkkwapv
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>The snake<br><br>

<br>
</body></html>

----------xsxuvegyuekptxkkwapv--

Delivery-date: Sun, 17 Jul 2005 20:37:52 +0000
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Date: Sun, 17 Jul 2005 22:36:06 +0200

Delivery-date: Sun, 17 Jul 2005 17:21:28 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Date: Sun, 17 Jul 2005 13:18:24 -0400

Arthi && JP.

I have a couple of questions.

1. Why are saying that LSP Stitching is a private case of LSP Hierarchy? IMO
there is more differences than similarities:
The differences are:
1) In case of H-LSP there is a data plane adjacency, while in case of S-LSP
there is none (as you correctly pointed out);
2) In case of H-LSP there is an adaptation in data plane (label push/pop for
PSC), while in case of S-LSP there is none - just simple cross-connecting
( label swap) as in case of two "native " e2e LSP adjacent segments ;
3) H-LSP could be used by many e2e LSPs, while S-LSP could be used by
exactly one e2e LSP
4) Signaling is different - there is no label negotiation in stitching
5) H-LSP is used as a "true" data link, specifically there is a resource
allocation on the H-LSP edges, while in case of S-LSP there is none
6) From MLN point of view, H-LSP is created in a server (lower) layer, while
the S-LSP is created in the client (same as e2e LSP) layer.

There are two similarities that I can think of:
1) There is a signaling and possibly routing (see below) adjacencies between
the ends;
2) Both H-LSP and S-LSP could be advertised as separate TE links or as TE
bundles

I would recommend to dedicate a paragraph and enlist there similarities and
differencies

2. Why are you saying that a TE Link based on S-LSP can be used for exactly
one e2e LSP? Parallel S-LSPs could be advertised as a single TE link
(bundle, see above) and hence can accomadate several e2e LSPs.

3. You are saying that S-LSP does not have a routing peering. Actually, in
this respect it is no different from H-LSP: if it is advertised as a TE link
into the same TE domain  that was used for S-LSP creation (unlikely IMO
scenario) than it does not require the routing adjacency (in other words, it
is an FA according to LSP-HIER definition), otherwise, it IS  NOT and FA and
does require the direct routing peering in the domain it is advertised to
make it useful as a TE link in this domain

Cheers,
Igor

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 15, 2005 3:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Common Control and Measurement Plane
Working Group of the IETF.
>
> Title : Label Switched Path Stitching with Generalized MPLS Traffic
Engineering
> Author(s) : A. Ayyangar, J. Vasseur
> Filename : draft-ietf-ccamp-lsp-stitching-01.txt
> Pages : 19
> Date : 2005-7-15
>
> In certain scenarios, there may be a need to combine together two
>    different Generalized Multi-Protocol Label Switching (GMPLS) Label
>    Switched Paths (LSPs) such that in the data plane, a single end-to-
>    end (e2e) LSP is achieved and all traffic from one LSP is switched
>    onto the other LSP.  We will refer to this as "LSP stitching".  This
>    document covers cases where: a) the node performing the stitching
>    does not require configuration of every LSP pair to be stitched
>    together b) the node performing the stitching is not the egress of
>    any of the LSPs c) LSP stitching not only results in an end-to-end
>    LSP in the data plane, but there is also a corresponding end-to-end
>    LSP (RSVP session) in the control plane.  It might be possible to
>    configure a GMPLS node to switch the traffic from an LSP for which it
>    is the egress, to another LSP for which it is the ingress, without
>    requiring any signaling or routing extensions whatsoever, completely
>    transparent to other nodes.  This will also result in LSP stitching
>    in the data plane.  However, this document does not cover this
>    scenario of LSP stitching.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of the
message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ccamp-lsp-stitching-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

Delivery-date: Fri, 15 Jul 2005 19:51:24 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Date: Fri, 15 Jul 2005 15:50:03 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Label Switched Path Stitching with Generalized MPLS Traffic Engineering
	Author(s)	: A. Ayyangar, J. Vasseur
	Filename	: draft-ietf-ccamp-lsp-stitching-01.txt
	Pages		: 19
	Date		: 2005-7-15
	
In certain scenarios, there may be a need to combine together two
   different Generalized Multi-Protocol Label Switching (GMPLS) Label
   Switched Paths (LSPs) such that in the data plane, a single end-to-
   end (e2e) LSP is achieved and all traffic from one LSP is switched
   onto the other LSP.  We will refer to this as "LSP stitching".  This
   document covers cases where: a) the node performing the stitching
   does not require configuration of every LSP pair to be stitched
   together b) the node performing the stitching is not the egress of
   any of the LSPs c) LSP stitching not only results in an end-to-end
   LSP in the data plane, but there is also a corresponding end-to-end
   LSP (RSVP session) in the control plane.  It might be possible to
   configure a GMPLS node to switch the traffic from an LSP for which it
   is the egress, to another LSP for which it is the ingress, without
   requiring any signaling or routing extensions whatsoever, completely
   transparent to other nodes.  This will also result in LSP stitching
   in the data plane.  However, this document does not cover this
   scenario of LSP stitching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-lsp-stitching-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lsp-stitching-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 15 Jul 2005 16:22:15 +0000
content-class: urn:content-classes:message
Subject: RE: End-to-end L2-LSP
Date: Fri, 15 Jul 2005 17:20:56 +0100
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi Jaihyung,

Having had some private requests to 'say something' on the list here I =
want to respond to a point you raise below, viz:

"Ever increasing best effort bandwidth will eventually not satisfy=20
both providers and customers for many reasons. Service providers=20
will have difficulty in collecting expenses enough to invest on =
increased=20
bandwidth. This will in turn gradually downgrade overall communication =
quality,=20
and applications requiring real-time service will never satisfy =
customers.=20
We already see such symptom in some low-price service providers.=20
I believe new service structure that can provide difference of service=20
quality will offer benefit to customers, providers as well as vendors in =
the end."

See if these observations help:

Real world networks (any mode) run at low utilisations over most of =
their working life for a whole raft of important reasons.  In this =
'normal' operating region the key challenge for the network architecture =
is that it must enable operators the ability to create consistently =
meaningful/priced services over all load points.....else longer-term =
investment will suffer.  If the network architecture cannot address this =
then we have a serious problem brewing for not only this industry but =
all those dependent on it....and currently this would appear to be the =
case.  Many operators are already discovering that 'ever faster and =
faster' access without some fair usage pricing is not satisfactory.  And =
please don't assume this is an operator only problem (ie a mindset of =
'here are some capabilities now you figure out how to use them' is not =
good enough).....if the operator community cannot generate a fair return =
on investment then both vendors and customers will ultimately all =
suffer.  There is no free lunch here....but we do need a fairly priced =
lunch.

When networks fail and enter the 'abnormal' operating region the nature =
of the key networking challenge changes significantly.  Here the key =
issue for the network architecture is targeted traffic survivability.  =
So how does one decide which traffic units are more important than other =
ones?...esp if I make the observation that ANY application can assume =
ANY 'importance' but yet all applications of a common kind have a fixed =
QoS requirement.  And this should not be just considered in the context =
of public services, we also need to include private network builder =
services.

I am of the strong opinion that trying to solve the above =
service-oriented problems by having lots of QoS classes in a single =
networking mode/technology won't work very well (understatement).  And =
there is a substantial body of historical networking evidence to support =
this view (and some interesting analysis, eg by Andrew Odlyzko).  Go =
have look at the truly successful networks that have prrofs by long-term =
existence and the one thing you will note that these all have in common =
is they do not have multiple QoS classes.  ATM tried multiple QoS =
classes and it was a failure.  Only AAL5 and AAL1 have any major use =
today.  So why is this?  Well its actually rather easy to explain:

Applications have only 3 broad classifications:  messages, files and =
streams.  It's therefore intuitively obvious one does need a large set =
of QoS/traffic classes to address this.  Indeed, in IP networking we =
find UDP, TCP and RTP map very nicely to the key major traffic =
classes.....this is NOT to say the serving network can effectively (ie =
includes cost) provide for these however.  AAL5 caters largely for the =
message/file class and AAL1 the stream class.  Everything else boils =
down to BW squeezing.....but successful networks run at low loads over =
most of their lives and BW is no longer such a scarce commodity that we =
need to try and conserve it everywhere.  Indeed BW should be used as a =
tool to drive down complexity....and complexity costs are indeed =
increasing (ask any operator about opex).  In fact a '1 mode/technology =
mindset' incurs lots of complexity.

Now although the above considers the public networking case it does not =
really address the needs of the private networking case.  Here, the =
basic service building block is a client/server layer network =
relationship where the client and server layer networks must be =
functionally decoupled....if for no other reason (and there are many =
other reasons) than the fact that the client and server layer networks =
may be owned by different operating parties.  In such a relationship how =
can anyone make any meaningful judgement as to a given application's =
importance?.....vis-=E0-vis the same application (but different user =
instance) in the same private network service instance, or the same =
application in some other customer's private network service instance.  =
And note that once we nest several layer networks deep then sight of =
ultimate end-user applications gets lost...as indeed they must, else the =
management of those lower layer networks would become intractably =
complex.

There is also a performance inheritance issue here, since the =
performance of layer network N is a combination of (i) impairments =
introduce by the nodes at layer N and (ii) the impairments introduced in =
the link-connections of layer N which come from trails at layer =
N-1.....this performance inheritance issue recurses to the duct.

So how are we to address the above issues of:
-	consistently meaningful/priced services in the normal operating =
regions?
-	correctly targeted traffic survivability in the abnormal operating =
region?
-	and across all public and private services?.....noting the important =
client/server relationship between layered networks mentioned above

I actually think there is a good solution to these problems....but it =
requires we let go of any technology religion and consider all 3 =
networking modes working in concert.  One key point to note is that in =
the co modes the trail object allows us to decouple the QoS semantic of =
child traffic units carried (that can change epoch by epoch) from the =
importance semantic of the parent trail entity (which is temporally =
invariant).

For the private services case the issue is very simple.  One must =
provide a co-cs or co-ps CBR-like server layer.  Indeed, its no =
coincidence that as one nears the duct all transport networks look like =
this.  They are the most efficient way of handling bulk traffic of any =
type as any major operator will tell you.

For the public service case let us assume a customer could select the =
mode he/she wanted to use and pay for this accordingly.  So for message =
and some file applications the customer may be happy with a simple cl-ps =
mode service (1 QoS class).  For stream and some file applications the =
customer may be happy to pay for a simple CBR-like co-ps SVC-based =
service (again 1 QoS class).  Just have think about this...and I mean =
really think....of how this could address some otherwise very hard =
problems in the QoS/pricing area.  And just consider how simple both the =
data-plane (classifiers/marking/shaping/policing/CAC/whatever) and =
control-plane (routing and signalling messages sets) components become.

You can think of this as the marriage of the best of the Internet and =
PSTN worlds if you like.  I do believe this scenario is worthy of =
serious consideration and should not be dismissed lightly.

regards, Neil

> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of CHO, JAI HYUNG
> Sent: 14 July 2005 04:24
> To: Spencer,R,Richard,XGH5 R; [email-masked]
> Subject: RE: End-to-end L2-LSP
>=20
>=20
> =20
> =20
> Dear Richard,
>=20
> See in-line please,
>=20
> >Thank you for taking the time to respond to my questions. I=20
> anticipated
> >that your response would include "over-provisioning is the=20
> best answer"=20
> >to decrease the chance of congestion on non-GMPLS switches.=20
> >This is what is done in the LAN environment today in=20
> conjunction with CoS,=20
> >and this is why I believe there will be two opposing views on how=20
> >far L2-LSP connections should be extended down to the user. One view=20
> >is that over provisioning and CoS work fine in the=20
> enterprise network today,=20
> >and therefore the L2-LSP should only be extended down to the point=20
> >at which the enterprise network connects to the SP network,=20
> >e.g. Ethernet DSLAM. I think the other view will be that=20
> over provisioning=20
> >and CoS in the enterprise network don't work and therefore L2-LSPs=20
> >should be provided end-to-end using only GMPLS capable switches.=20
> >I wouldn't have thought there would be much call for mixed=20
> >GMPLS/non-GMPLS enterprise networks (except for during migration)=20
> >due to the opposing views, e.g. if over provisioning is good=20
> enough for=20
> >one switch, why isn't it good enough for the other?
>=20
> Over-provisioned network is non-guaranteed network. It can't prevent=20
> occasional congestion at any rate. Further, network condition=20
> in private=20
> network is very diverse. You can't predict minimum service level=20
> inside every private network.=20
>=20
> Suppose that an ISP want to provide high-quality, video-phone service=20
> for enterprise users. Nothing can be guaranteed inside the=20
> over-provisioned=20
> customer network. If the service level is not satisfactory,=20
> customers will complain=20
> to service provider even if the main cause is in his network=20
> or destination network.=20
> We need some structure that coordinate service quality in=20
> both private sector,=20
> as well as in public sector consistently.=20
> An end-to-end signal is an effective means to communicate between=20
> user terminal, private switches and provider switches, and=20
> concert service=20
> quality at each different operations network. This is a goal=20
> that RSVP (RFC2205)=20
> pursued, however ineffective in local network because=20
> Ethernet industry=20
> didn't support RSVP over Ethernet (RFC2814, 2815, 2816).=20
> Now we have another opportunity to realize the goal using L2-LSP.=20
> Therefore, I believe end-to-end LSP is necessary even in=20
> enterprise network=20
> for the purpose of providing guaranteed commercial service.
>=20
> >I think where most people will agree is that using connections
> >in the SPs access network does make sense in order to=20
> provide efficient=20
> >link utilisation and per connection policing to ensure one customers=20
> >traffic can not affect another's. Regarding the ability to=20
> set up new=20
> >connections based on a request from the user (rather than=20
> constraining=20
> >RSVP signalling to inside the SP network), I think this will come=20
> >down to enterprise customer demand for improved service performance.=20
> >If a customer wasn't getting the performance they needed from their=20
> >SP and was offered a new service that allowed them to setup=20
> new L2-LSP=20
> >connections on demand that would offer better performance=20
> (e.g. for voice=20
> >calls or video conferences), then upgrading the user devices=20
> to support=20
> >the new service could well be an attractive proposition. If=20
> on the other=20
>=20
> Yes, this will be one of prospective service newly enabled=20
> using L2-LSP.
>=20
> >hand a customer buys a best effort service and considers the=20
> >performance
> >to be 'good enough', then there would be no reason to go to=20
> the expense=20
> >of upgrading the user devices to support the set up of L2-LSPs.
>=20
> Ever increasing besteffort bandwidth will eventually not satisfy=20
> both providers and customers for many reasons. Service providers=20
> will have difficulty in collecting expenses enough to invest=20
> on increased=20
> bandwidth. This will in turn gradually downgrade overall=20
> communication quality,=20
> and applications requiring real-time service will never=20
> satisfy customers.=20
> We already see such symptom in some low-price service providers.=20
> I believe new service structure that can provide difference=20
> of service=20
> quality will offer benefit to customers, providers as well as=20
> vendors in the end.
>=20
> I also look forward to see you at Paris and continue helpful=20
> discussion.
>=20
> Sincerely
>=20
> Jaihyung
>=20
>=20
> =20
>=20
> Dr. Jaihyung Cho
> ETRI, Korea
> phone :       042) 860-5514
> oversea: +82-42-860-5514
> fax:         +82-42-861-5550=20
>=20
>=20
>=20
>=20
> -----?? ???-----=20
> ?? ??: "[email-masked]" <[email-masked]>=20
> ?? ??: 2005-07-14 ?? 1:10:30=20
> ?? ??: "[email-masked]" <[email-masked]>,=20
> "[email-masked]" <[email-masked]>=20
> ??:=20
> ??: RE: End-to-end L2-LSP=20
>=20
>=20
>=20
> Jaihyung,=20
>=20
> Thank you for taking the time to respond to my questions. I=20
> anticipated that your response would include=20
> "over-provisioning is the best answer" to decrease the chance=20
> of congestion on non-GMPLS switches. This is what is done in=20
> the LAN environment today in conjunction with CoS, and this=20
> is why I believe there will be two opposing views on how far=20
> L2-LSP connections should be extended down to the user. One=20
> view is that over provisioning and CoS work fine in the=20
> enterprise network today, and therefore the L2-LSP should=20
> only be extended down to the point at which the enterprise=20
> network connects to the SP network, e.g. Ethernet DSLAM. I=20
> think the other view will be that over provisioning and CoS=20
> in the enterprise network don't work and therefore L2-LSPs=20
> should be provided end-to-end using only GMPLS capable=20
> switches. I wouldn't have thought there would be much call=20
> for mixed GMPLS/non-GMPLS enterprise networks (except for=20
> during migration) due to the opposing views, e.g. if over=20
> provisioning is good enough for one switch, why isn't it good=20
> enough for the other?=20
>=20
> I think where most people will agree is that using=20
> connections in the SPs access network does make sense in=20
> order to provide efficient link utilisation and per=20
> connection policing to ensure one customers traffic can not=20
> affect another's. Regarding the ability to set up new=20
> connections based on a request from the user (rather than=20
> constraining RSVP signalling to inside the SP network), I=20
> think this will come down to enterprise customer demand for=20
> improved service performance. If a customer wasn't getting=20
> the performance they needed from their SP and was offered a=20
> new service that allowed them to setup new L2-LSP connections=20
> on demand that would offer better performance (e.g. for voice=20
> calls or video conferences), then upgrading the user devices=20
> to support the new service could well be an attractive=20
> proposition. If on the other hand a customer buys a best=20
> effort service and considers the performance to be 'good=20
> enough', then there would be no reason to go to the expense=20
> of upgrading the user devices to support the set up of L2-LSPs.=20
>=20
> I look forward to the discussions in Paris.=20
>=20
> Regards,=20
> Richard=20
>=20
> > From: CHO, JAI HYUNG [mailto:[email-masked]]=20
> > Sent: 13 July 2005 15:14=20
> > To: Spencer,R,Richard,XDE73 R; [email-masked]=20
> > Subject: RE: End-to-end L2-LSP=20
> >=20
> >=20
> > =20
> > =20
> > Dear Richard Spencer
> > =20
> > see in-line
> > =20
> > >Jaihyung,
> > >=20
> > >Perhaps I'm becoming too much of a pessimist;-)
> > =20
> > oh, not at all,
> > you are reasonable enough to dig up unclear knowledge=20
> > please go ahead until you finally get satisfactory answer.=20
> > =20
> >=20
> > >Ignoring the commercial aspects, please can you help clarify
> > a few technical
> > >questions I have in order to help me gain a better
> > understanding of the proposal?
> > >=20
> > >1. You say that one of the key reasons for using GMPLS in
> > the enterprise
> > >network is to provide end-to-end QoS control. However, you
> > also say that not
> > >all the switches will need to support GMPLS, only those at
> > bottle necks.
> > >Please can you expand on this to explain how you can have=20
> end-to-end
> > >QoS control when the L2-LSP is not end-to-end?=20
> > =20
> >=20
> > The contextual meaning of 'End-to-end LSP' is that GMPLS label is
> > assigned from source terminal and removed at destination terminal,=20
> > because RSVP-TE message is exchanged from host to host.=20
> > It may not perfectly guarantee QoS when the GMPLS deployment=20
> > is not complete, however it will at least be good enough=20
> > for end-user applications to tell those GMPLS implemented=20
> L2 switches=20
> > what frame must be given priority service when congestion occur.=20
> > =20
> >=20
> > >As being discussed
> > >on the PWE3 mailing list, the performance a service receives=20
> > is only as
> > >good as the worst performing server layer. Therefore, if there is a
> > >standard 802.1 workgroup switch between the user and the=20
> > L2-LSP that is
> > >experiencing congestion (e.g. due to a large amount of
> > peer-to-peer traffic),
> > >then the QoS that the user receives will only be as good as
> > that provided
> > >by the congested workgroup switch.
> > =20
> >=20
> > of course, ETH-GMPLS does not prevent congestion inevitably=20
> occurring
> > in those non-GMPLS deployed part.=20
> > =20
> >=20
> > >The only way I can see a network using a mixture of GMPLS
> > and non-GMPLS
> > >switches guaranteeing end-to-end QoS would be to design the
> > network in
> > >such a way that the non-GMPLS switches could never become=20
> congested.
> > =20
> >=20
> > Yes, that will be the way wise network designer improve=20
> their network.
> > =20
> >=20
> > >To do this would require that RSVP requests be used for ALL
> > traffic flows
> > >to ensure that there was enough bandwidth available, along
> > with strict
> > >per L2-LSP policing on the user devices (e.g. PC).
> > >However, the obvious flaw in this approach is that someone could=20
> > >just come along and connect=20
> > >an end device to a non-GMPLS switch and start transmitting traffic=20
> > >(without performing CAC/policing) causing the switch to=20
> > become congested.
> > >Therefore, please can you explain how end-to-end QoS can be
> > guaranteed
> > >in a mixed non-GMPLS and GMPLS switching environment?
> > =20
> >=20
> > Of course traffic came from non controlled ingress can not be
> > prevented=20
> > in non-GMPLS node. There's no magic. Only the=20
> > over-provisioning is the=20
> > best answer. However, once the aggregated traffic pass 'ANY' one of=20
> > GMPLS enabled node, those uncontrolled traffic will suffer=20
> > queuing discipline.=20
> > =20
> >=20
> > >2. Section 5.1 currently states "When the customer initiates
> > data transmission,
> > >the access switch maps the user flow into the L2 LSP.
> > Mapping procedure is
> > >subject to implementation choices, and is out of the scope of this
> > >document." In order to be able to map any traffic, first of=20
> > all the switch needs
> > >to know what type of traffic (e.g. based on source/dest MAC,
> > VLAN ID, 802.1p
> > >bits, etc) should be mapped to the L2-LSP. In Figure 1, if
> > an L2-LSP is set up
> > >from the DSLAM to the edge router based on a request from
> > the user (e.g. via
> > >a PC or VoIP phone), then won't the user also need to signal
> > what type of
> > >traffic should to be mapped to the L2-LSP?
> > =20
> >=20
> > Thank you for pointing out important thing.
> > That's the most unfortunate part I reluctantly agreed because the=20
> > work condition in the framework DT was not to span L2-LSP=20
> > beyond provider network.=20
> > As you noticed, mapping user traffic at provider access is awkward.=20
> > A smooth method will be for user terminal aware of the L2 label=20
> > to use by receiving RSVP-TE message.=20
> > However, there was strong argument that RSVP-TE must not=20
> > go beyond provider network because the DT is not chartered=20
> > to work in customer network.=20
> > That's why I requested amendment of CCAMP charter=20
> > to include user terminal explicitly in CCAMP work scope, so that=20
> > avoid such silly argument in future.=20
> > =20
> >=20
> > >3. In section 5.1, the text states that the aggregation
> > switch between the
> > >DSLAM and edge router may be a 802.1 switch, i.e. it doesn't
> > have to support
> > >GMPLS. To set up a connection, first of all there needs to
> > be a data plane
> > >capable of carrying control plane traffic between GMPLS
> > peers. Secondly,
> > >the GMPLS peers need reachability information in order to
> > forward control
> > >messages onto the next peer (i.e. a static or IGP route). If
> > the GMPLS peers
> > >(e.g. the DSLAM and edge router in Figure 1) are not
> > directly connected,
> > >then the GMPLS control packets will need to be forwarded by
> > the 802.1 switch.
> > >Would the idea be to have say a "control traffic VLAN"
> > configured between the
> > >DSLAM and edge router via the transit 802.1 switch so that
> > control packets
> > >could be forwarded transparently by the 802.1 switch?
> > =20
> >=20
> > Although it doesn't preclude use of VLAN, I think such
> > special configuration=20
> > for RSVP-TE control message is not necessary in legacy switches.=20
> > Legacy switches only need to pass RSVP-TE messages as they=20
> > pass normal data frames. Only the GMPLS implemented switches=20
> > need to distinguish frames containing RSVP-TE messages and=20
> > snoop them.=20
> > Detail of implementation is, of course, for future discussion.=20
> > =20
> >=20
> > >4. If we assume that control messages can be transparently=20
> forwarded
> > >by the intermediate 802.1 aggregation switch then how are=20
> > user frames
> > >forwarded in the data plane by the 802.1 switch?
> > =20
> >=20
> > Legacy switches do not distinguish control/data frames.
> > =20
> >=20
> > >If the DSLAM sets up a L2-LSP
> > >to the edge router using say VLAN ID 99, how does the switch=20
> > know that any
> > >packets coming in with a VLAN ID of 99 should be forwarded
> > out of the port
> > >connecting to the edge router?
> > =20
> >=20
> > oh, you misunderstood the L2-LSP.
> > The question you are asking depends on how L2 label is encoded.=20
> > there was hot debate in the DT about the issue how L2 label=20
> > is encoded.=20
> > My proposal is to use part of MAC address for label and the=20
> > other people=20
> > argued to use VLAN ID for label. The debate was not concluded=20
> > because the goal of the L2SC framework document is not to select=20
> > implementation method but to draw necessary work scope.=20
> > I believe this issue will be dealt in depth after Paris meeting.=20
> > So, please reserve your question until then and ask to those=20
> > VLAN proponents.=20
> > =20
> >=20
> > >5. During connection setup, I take it that the GMPLS peers
> > assume that
> > >resources are available within the intermediate 802.1 switch
> > to support
> > >the connection (as its transparent). However, as there is no
> > >CAC/policing being performed by the 802.1 switch=20
> > >(the L2-LSPs are transparent), and due to the any-to-any and=20
> > broadcast
> > >based nature of Ethernet (i.e. its CL properties), then=20
> how can this
> > >assumption be made? This comes back to my original question, how=20
> > >can end-to-end QoS be guaranteed in an environment where there is=20
> > >a mixture of 802.1 and GMPLS enabled switches?=20
> > =20
> >=20
> > yes, you came back to the question I answered in above ;-)
> > so, please see above.=20
> > GMPLS enabled nodes must be positioned at points congestion=20
> > is likely to be expected.=20
> > =20
> > Thanks
> > =20
> > Jaihyung
> > =20
> >=20
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >=20
> > =20
> >=20
> > -----?? ???-----
> > ?? ??: "[email-masked]" <[email-masked]>=20
> > ?? ??: 2005-07-13 ?? 8:53:13=20
> > ?? ??: "[email-masked]" <[email-masked]>,=20
> > "[email-masked]" <[email-masked]>=20
> > ??:=20
> > ??: RE: End-to-end L2-LSP=20
> >=20
> >=20
> >=20
> >=20
> > Jaihyung,
> >=20
> > Perhaps I'm becoming too much of a pessimist;-) Ignoring the
> > commercial aspects, please can you help clarify a few=20
> > technical questions I have in order to help me gain a better=20
> > understanding of the proposal?=20
> >=20
> > 1. You say that one of the key reasons for using GMPLS in the
> > enterprise network is to provide end-to-end QoS control.=20
> > However, you also say that not all the switches will need to=20
> > support GMPLS, only those at bottle necks. Please can you=20
> > expand on this to explain how you can have end-to-end QoS=20
> > control when the L2-LSP is not end-to-end? As being discussed=20
> > on the PWE3 mailing list, the performance a service receives=20
> > is only as good as the worst performing server layer.=20
> > Therefore, if there is a standard 802.1 workgroup switch=20
> > between the user and the L2-LSP that is experiencing=20
> > congestion (e.g. due to a large amount of peer-to-peer=20
> > traffic), then the QoS that the user receives will only be as=20
> > good as that provided by the congested workgroup switch.=20
> >=20
> > The only way I can see a network using a mixture of GMPLS and
> > non-GMPLS switches guaranteeing end-to-end QoS would be to=20
> > design the network in such a way that the non-GMPLS switches=20
> > could never become congested. To do this would require that=20
> > RSVP requests be used for ALL traffic flows to ensure that=20
> > there was enough bandwidth available, along with strict per=20
> > L2-LSP policing on the user devices (e.g. PC). However, the=20
> > obvious flaw in this approach is that someone could just come=20
> > along and connect an end device to a non-GMPLS switch and=20
> > start transmitting traffic (without performing CAC/policing)=20
> > causing the switch to become congested. Therefore, please can=20
> > you explain how end-to-end QoS can be guaranteed in a mixed=20
> > non-GMPLS and GMPLS switching environment?=20
> >=20
> > 2. Section 5.1 currently states "When the customer initiates
> > data transmission, the access switch maps the user flow into=20
> > the L2 LSP. Mapping procedure is subject to implementation=20
> > choices, and is out of the scope of this document." In order=20
> > to be able to map any traffic, first of all the switch needs=20
> > to know what type of traffic (e.g. based on source/dest MAC,=20
> > VLAN ID, 802.1p bits, etc) should be mapped to the L2-LSP. In=20
> > Figure 1, if an L2-LSP is set up from the DSLAM to the edge=20
> > router based on a request from the user (e.g. via a PC or=20
> > VoIP phone), then won't the user also need to signal what=20
> > type of traffic should to be mapped to the L2-LSP?=20
> >=20
> > 3. In section 5.1, the text states that the aggregation
> > switch between the DSLAM and edge router may be a 802.1=20
> > switch, i.e. it doesn't have to support GMPLS. To set up a=20
> > connection, first of all there needs to be a data plane=20
> > capable of carrying control plane traffic between GMPLS=20
> > peers. Secondly, the GMPLS peers need reachability=20
> > information in order to forward control messages onto the=20
> > next peer (i.e. a static or IGP route). If the GMPLS peers=20
> > (e.g. the DSLAM and edge router in Figure 1) are not directly=20
> > connected, then the GMPLS control packets will need to be=20
> > forwarded by the 802.1 switch. Would the idea be to have say=20
> > a "control traffic VLAN" configured between the DSLAM and=20
> > edge router via the transit 802.1 switch so that control=20
> > packets could be forwarded transparently by the 802.1 switch?=20
> >=20
> > 4. If we assume that control messages can be transparently
> > forwarded by the intermediate 802.1 aggregation switch then=20
> > how are user frames forwarded in the data plane by the 802.1=20
> > switch? If the DSLAM sets up a L2-LSP to the edge router=20
> > using say VLAN ID 99, how does the switch know that any=20
> > packets coming in with a VLAN ID of 99 should be forwarded=20
> > out of the port connecting to the edge router?=20
> >=20
> > 5. During connection setup, I take it that the GMPLS peers
> > assume that resources are available within the intermediate=20
> > 802.1 switch to support the connection (as its transparent).=20
> > However, as there is no CAC/policing being performed by the=20
> > 802.1 switch (the L2-LSPs are transparent), and due to the=20
> > any-to-any and broadcast based nature of Ethernet (i.e. its=20
> > CL properties), then how can this assumption be made? This=20
> > comes back to my original question, how can end-to-end QoS be=20
> > guaranteed in an environment where there is a mixture of=20
> > 802.1 and GMPLS enabled switches?=20
> >=20
> > Thanks,
> > Richard=20
> >=20
> > > From: CHO, JAI HYUNG [mailto:[email-masked]]=20
> > > Sent: 12 July 2005 09:21=20
> > > To: Spencer,R,Richard,XDE73 R; [email-masked]=20
> > > Subject: RE: End-to-end L2-LSP=20
> > >=20
> > >=20
> > >=20
> > >=20
> > > Dear Richard,
> > >=20
> > > Yes, I believe it is not only commercially profitable but it
> > > may also grow total=20
> > > revenue of service operators by introducing new services.=20
> > >=20
> > > For example, think the example of IP phone you referred.
> > > How do you think you can provide reliable VoIP service and=20
> > > safely authenticate phone users and charge fees as counted by=20
> > > packet usage=20
> > > using simple Ethernet based xDSL network ?=20
> > >=20
> > > There's hardly new service that providers may offer using
> > > Ethernet based=20
> > > architecture, and collect sufficient profit to investment.=20
> > >=20
> > > A sophisticated ATM switch might do the work if it is not
> > expensive.
> > > However, my intension is modifiying existing design of
> > > Ethernet hardware=20
> > > with a little bit additional cost,  and provide the level of=20
> > > service that=20
> > > ATM switches might offer.=20
> > >=20
> > > We have initial design of the Ethernet-MPLS hardware. I=20
> don't think
> > > GMPLS enabled Ethernet switch will be so complex. The=20
> market price=20
> > > of GMPLS enabled switch will not be so expensive than normal=20
> > > Ethernet switches.=20
> > >=20
> > > Further, it only requires upgrade of switches in some
> > > bottleneck points of network.=20
> > > Read the framework documents of L2SC. It doesn't require=20
> > > entire replacement=20
> > > of switches to introduce new service.=20
> > >=20
> > > Every year, ISPs purchase new access switches and replaces
> > > old machines.=20
> > > With a bit additional cost, ISPs may use the GMPLS enabled=20
> > switch for
> > > normal Ethernet switching in initial deployment.
> > >=20
> > > When the GMPLS function is enabled in some upgraded part of
> > network,
> > > ISPs may provide high quality, reliable VoIP service to
> > xDSL customers
> > > using RSVP-TE enabled VoIP phone.
> > > The high quality video-phone service enabled by GMPLS will be=20
> > > competable to legacy voice only phone service.=20
> > >=20
> > >=20
> > > There are lots of things I can argue about commercial aspects
> > > of this technique.=20
> > > However I don't think it is not appropriate to discuss this=20
> > > issue in this mailing list.=20
> > > All I can say is,=20
> > > yes, I believe that it may be commercially viable.=20
> > >=20
> > >=20
> > > Thanks
> > >=20
> > > Jaihyung
> > >=20
> > > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >=20
> > > Do you really think the benefits of extended GMPLS down to
> > > the end user could ever justify the costs involved in=20
> > > upgrading LAN switches and things like IP phones (simple low=20
> > > cost commodity items) to support GMPLS signalling/routing?=20
> > >=20
> > > Your proposal may be technically possible (though it would
> > > require new hardware and significant software upgrades), but=20
> > > commercially I would consider this to be a non-starter.=20
> > >=20
> > > Regards,
> > > Richard=20
> > >=20
> > > > From: [email-masked]=20
> > [mailto:[email-masked]]On
> > > > Behalf Of CHO, JAI HYUNG
> > > > Sent: 12 July 2005 01:10=20
> > > > To: [email-masked]=20
> > > > Subject: End-to-end L2-LSP=20
> > > >=20
> > > >=20
> > > > =20
> > > > Dear all,
> > > >=20
> > > > Greetings.
> > > >=20
> > > > I am a co-editor of the Ethernet-GMPLS framework document.
> > > > (draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt)=20
> > > >=20
> > > > I am writing this to explain the motivation behind the
> > > > proposal of scenario-1, and to raise the issue of=20
> > > > end-to-end LSP to be included in CCAMP charter.=20
> > > >=20
> > > > An important goal intended in scenario-1 is
> > > > QoS control over end-to-end packet delivery using LSP.=20
> > > > In other words, the purpose of scenario-1 is extending coverage=20
> > > > of GMPLS control including customer network and=20
> end-user device,=20
> > > > such as PC, VoIP phone, IP-TV, or even future 4G mobile phone.=20
> > > > End-user applications will have a means to request resources=20
> > > > to network using GMPLS signal.=20
> > > >=20
> > > > Unfortunately, this view is not included in the
> > > > framework because there was strong opinion that=20
> > > > L2-LSP must not span beyond provider network because=20
> > > > CCAMP is not chartered to work on customer=20
> > > > network. I am wondering if this is right argument.=20
> > > > Perhaps the charter can be amended to include this work.=20
> > > >=20
> > > > I believe there is little technical reason to preclude
> > > > LSP being used in customer network. It is a reasonable=20
> > > > assumption that private company may also use GMPLS=20
> > > > implemented Ethernet switch, once the L2SC work is successful.=20
> > > > Currently, CCAMP is the only place discussing the matter of=20
> > > > Ethernet and LSP. There is no other WG dealing similar issue.=20
> > > > If CCAMP wants to work on Ethernet,=20
> > > > I think the coverage of common GMPLS control must be=20
> > > > extended to include all area where Ethernet is deployed.=20
> > > > Currently, Ethernet is dominantly deployed in first-mile=20
> > > > network where access network as well as customer network=20
> > > > and user hosts are usually included. Therefore, user host must=20
> > > > be considered as initiation and termination point of L2-LSP.=20
> > > >=20
> > > > Another important reason to include user host in CCAMP
> > > > work scope is to achieve consistent end-to-end control of QoS.=20
> > > > End-to-end QoS has long been desired goal since RSVP was=20
> > > > first designed. This goal can be best achieved using=20
> > > > end-to-end GMPLS signal and L2-LSP.=20
> > > > Currently, RSVP (RFC2205) is available in many user hosts.=20
> > > > There is only a little difference between RSVP and RSVP-TE.=20
> > > > If the RSVP-TE signal of provider network can reach user host=20
> > > > across Ethernet based private network, an LSP can be=20
> established=20
> > > > from application to application via the provider backbone.=20
> > > > Service providers will be able to control application flows=20
> > > > in L2-LSP level as well as in aggregated LSP pipe of similar=20
> > > > application type. A variety of new services will be=20
> enabled using=20
> > > > the enhanced capability of distinguishing and controlling each=20
> > > > individual application flow.=20
> > > >=20
> > > > I personally believe that end-to-end L2-LSP may offer
> > > > innovative solutions for servicing IP-TV as well as fast=20
> > mobility.
> > > > There have been some experimental approaches combining
> > > > MPLS and IP mobility. However such potential of the new=20
> > > > application can only be explored when end-user host is=20
> > > > included in the scope of CCAMP work area.=20
> > > >=20
> > > > Therefore, I hereby sincerely request people's attention
> > > > and support on this perspective of end-to-end LSP.=20
> > > > If there is enough number of people agree on this view,=20
> > > > the WG can request the necessary update of the charter.=20
> > > >=20
> > > > Thank you.
> > > > =20
> > > > Jaihyung Cho
> > > > =20
> > > > =20
> > > > =20
> > > > ETRI, Korea=20
> > > > phone :       042) 860-5514=20
> > > > oversea: +82-42-860-5514=20
> > > > fax:         +82-42-861-5550=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20
>=20

Delivery-date: Fri, 15 Jul 2005 14:00:47 +0000
To: [email-masked]
Cc: [email-masked], [email-masked]
From: [email-masked]
Subject: Re: Draft agenda for Paris
Date: Fri, 15 Jul 2005 15:58:41 +0200

hi adrian, kireeti,

thanks for posting this agenda, this said, two important issues are imho
creating increasing concern in this WG:

1. CCAMP WG backlog -> if one considers the current size of the WG I-Ds
still under discussion, it has reached more than a reasonable size now
since roughly 2/3 (25 over 36, if my count is correct) of the listed WG I-D
documents are pending in RFC Editor queue, under reviews, etc. - the
important issue is that one of the argument commonly used is "GMPLS beside
signaling is still at the draft level" e.g. GMPLS UNI and other routing
docs (meaning not stable, even if this not the case) but this is a REAL
argument playing against GMPLS development and deployment => so, if an
in-depth effort is not triggered this situation is going to persist for a
long time, i would suggest we put this real issue over the next CCAMP
meeting boiler plate

2. CCAMP WG recharter -> we are discussing this "re-charter" since quite
some time now and there are no stated milestones beside closing items we
have initiated since then (or introduce here and there some informational
document trying to clarify achievements). As illustrative examples, pending
items such as I/W and MRN (and derivates), are impacted by this delayed
process:

-> for I/W: there is a need for a DT-like approach since there are several
I-Ds popping up and there is no real common WG vision, a 3-step approach
(10 page framework/problem statement - solution/ mechanism - and then
applicability) would be more than advisabe here as there is a need to clean
up the orientations and come with a real focused stepwise process; with the
current situation we are missing the increasing demand with confusing
vision on migration mechanisms and this is also playing against GMPLS
deployment

-> for MRN and derivates: the real problem is the scope, as long as the
scope is left open - and this is a WG responsibility - people have the
tendancy to consider it as a moving target instead of stabilizing it and so
at the end delaying instead of achieving stepwise progress that the
industry requires

the major resulting issue here (if this can not be addressed rapidly) will
soon become "if the CCAMP WG is not willing to open its charter and address
real community concerns what is the longer term role of this WG ?" and i am
afraid to say here that this is going to leave us with two major options
either split effort in smaller scoped WGs or do like with SIP and split
into a base WG and an investigation WG.

so, in brief, i would like to ask you and Kireeti, to seriously consider
these issues and let us know how this inconfortable situation can be
tackled and what are the actions to undertake in order to make it evolving
rapidly

thanks,
- dimitri.

Delivery-date: Fri, 15 Jul 2005 09:19:19 +0000
To: [email-masked]
From: [email-masked]
Subject: http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-00
Date: Fri, 15 Jul 2005 11:15:42 +0200

Delivery-date: Fri, 15 Jul 2005 00:52:51 +0000
To: [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: no more milestones?
Date: Thu, 14 Jul 2005 17:50:34 -0700

     Why the WG is stuck without any milestones
and unable to take on more work?  Are there
any plans to extend the charter?

     --Tom

Delivery-date: Thu, 14 Jul 2005 23:52:38 +0000
Date: Fri, 15 Jul 2005 08:52:19 +0900
From: Tomohiro Otani <[email-masked]>
To: [email-masked]
Subject: GMPLS OSPF-TE MIB

Hi everyone,

We posted a new draft about GMPLS OSPF-TE MIB as follows.
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-ospf-mib-00.txt

We welcome your comments and feedbacks, pls.
And please make a comment whether this is within ccamp WG or not (OSPF-WG?).

We believe that this is a very significant definition of OSPF-TE MIB,
being complementary to other GMPLS related MIBs (TE/LSR/LMP mibs) in order
to deploy GMPLS control plane in the actual environment with simple but
reliable network management.

With best regards,

tomo

------------------------------------
Tomohiro Otani
KDDI R&D Laboratories, Inc.
Optical network architecture lab.
2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan
TEL: +81-49-278-7357
FAX: +81-49-278-7811
E-mail: [email-masked]
------------------------------------

Delivery-date: Thu, 14 Jul 2005 18:52:13 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Draft agenda for Paris
Date: Thu, 14 Jul 2005 19:53:01 +0100

Hi,

We have come up with the following draft agenda.

Before you all shout that your I-D is not on the list, as yourselves
- Has the I-D been discussed much on the mailing list?
- What would I like to see cut to make space for my I-D?
- What benefit will the WG gain from discussing the I-D in the meeting.

Recall, the purpose of an agenda slot is to allow the floor to discuss
your I-D. It is not for you to present the contents or your I-D because
(obviously) your I-D is so well written that everyone already understands
the contents.

A slide template and hints can be found at
http://www.olddog.co.uk/ccamp.htm

Please email me your final set of slides by close of business Monday 1st
August.

Thanks,
Adrian

===

CCAMP Agenda - IETF-63 Paris

Administrivia [10 minutes]                               (10)

ITU-T Liaison report [10 minutes]                        (20)

Status of WG [5 minutes]                                 (25)
- Remaining milestones
- Drafts with RFC Editor
- Drafts with AD
- Drafts still in working group

WG drafts Status and Plans                               (70)
- Inter-domain
   - Stitching (Arthi) [5 minutes]
     draft-ietf-ccamp-lsp-stitching-01.txt
   - Inter-domain Signaling (Arthi) [5 minutes]
     draft-ietf-ccamp-inter-domain-rsvp-te-00.txt
   - PD-Path (JP) [5 minutes]
     draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
- GMPLS Addressing (Richard) [10 minutes]
  draft-ietf-ccamp-gmpls-addressing-01.txt
- ASON/GMPLS Lexicography (Igor) [10 minutes]
  draft-ietf-ccamp-gmpls-ason-lexicography-03.txt
- ASON routing evaluation (Dimitri) [5 minutes]
  draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt
- ASON signaling (Dimitri) [5 minutes]
  draft-ietf-ccamp-gmpls-rsvp-te-ason-03.txt

Working Group Work Plan                                 (105)
- Options for progress (chairs) [5 minutes]
- Potential new work (chairs) [15 minutes]
- Charter discussion (chairs and ADs) [15 minutes]

Layer Two Switching                                     (125)
- Framework (Dimitri) [10 minutes]
  draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt
- Next steps (chairs) [10 minutes]

Other drafts                                            (150)
- Advertising node TE capabilities (JP) [5 minutes]
  draft-vasseur-ccamp-te-node-cap
  draft-vasseur-ccamp-automesh
- Advanced constraints
  draft-otani-ccamp-gmpls-cspf-constraints (Tomohiro) [5 minutes]
  draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt (Don) [5 mins]
- VCAT/LCAS
  draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt (Greg) [5 mins]
  draft-imajuku-ccamp-gmpls-vcat-lagr-req-00.txt (Wataru) [5 mins]

Delivery-date: Thu, 14 Jul 2005 08:46:44 +0000
Date: Thu, 14 Jul 2005 09:43:37 +0000
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------vmfswhkcqaueuwndugfu
Content-Type: text/plain; charset="UTF-8"; format="flowed"

+----------------------------------------------------+

Panda GateDefender has detected malicious content (Virus) in the following file: [Dog.cpl]
W32/Bagle.AH.worm

The file has been deleted to protect the network.
07/14/2005 08:37 +0100

www.pandasoftware.com

+----------------------------------------------------+

----------vmfswhkcqaueuwndugfu
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>Lovely animals<br><br>

<br>
</body></html>

----------vmfswhkcqaueuwndugfu--

Delivery-date: Thu, 14 Jul 2005 03:25:08 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 
Bcc: 
Subject: RE: End-to-end L2-LSP
Date: Thu, 14 Jul 2005 12:24:26 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message

Dear Richard,

See in-line please,

>Thank you for taking the time to respond to my questions. I anticipated 
>that your response would include "over-provisioning is the best answer" 
>to decrease the chance of congestion on non-GMPLS switches. 
>This is what is done in the LAN environment today in conjunction with CoS, 
>and this is why I believe there will be two opposing views on how 
>far L2-LSP connections should be extended down to the user. One view 
>is that over provisioning and CoS work fine in the enterprise network today, 
>and therefore the L2-LSP should only be extended down to the point 
>at which the enterprise network connects to the SP network, 
>e.g. Ethernet DSLAM. I think the other view will be that over provisioning 
>and CoS in the enterprise network don't work and therefore L2-LSPs 
>should be provided end-to-end using only GMPLS capable switches. 
>I wouldn't have thought there would be much call for mixed 
>GMPLS/non-GMPLS enterprise networks (except for during migration) 
>due to the opposing views, e.g. if over provisioning is good enough for 
>one switch, why isn't it good enough for the other?

Over-provisioned network is non-guaranteed network. It can't prevent 
occasional congestion at any rate. Further, network condition in private 
network is very diverse. You can't predict minimum service level 
inside every private network. 

Suppose that an ISP want to provide high-quality, video-phone service 
for enterprise users. Nothing can be guaranteed inside the over-provisioned 
customer network. If the service level is not satisfactory, customers will complain 
to service provider even if the main cause is in his network or destination network. 
We need some structure that coordinate service quality in both private sector, 
as well as in public sector consistently. 
An end-to-end signal is an effective means to communicate between 
user terminal, private switches and provider switches, and concert service 
quality at each different operations network. This is a goal that RSVP (RFC2205) 
pursued, however ineffective in local network because Ethernet industry 
didn't support RSVP over Ethernet (RFC2814, 2815, 2816). 
Now we have another opportunity to realize the goal using L2-LSP. 
Therefore, I believe end-to-end LSP is necessary even in enterprise network 
for the purpose of providing guaranteed commercial service.

>I think where most people will agree is that using connections 
>in the SPs access network does make sense in order to provide efficient 
>link utilisation and per connection policing to ensure one customers 
>traffic can not affect another's. Regarding the ability to set up new 
>connections based on a request from the user (rather than constraining 
>RSVP signalling to inside the SP network), I think this will come 
>down to enterprise customer demand for improved service performance. 
>If a customer wasn't getting the performance they needed from their 
>SP and was offered a new service that allowed them to setup new L2-LSP 
>connections on demand that would offer better performance (e.g. for voice 
>calls or video conferences), then upgrading the user devices to support 
>the new service could well be an attractive proposition. If on the other 

Yes, this will be one of prospective service newly enabled using L2-LSP.

>hand a customer buys a best effort service and considers the performance 
>to be 'good enough', then there would be no reason to go to the expense 
>of upgrading the user devices to support the set up of L2-LSPs.

Ever increasing besteffort bandwidth will eventually not satisfy 
both providers and customers for many reasons. Service providers 
will have difficulty in collecting expenses enough to invest on increased 
bandwidth. This will in turn gradually downgrade overall communication quality, 
and applications requiring real-time service will never satisfy customers. 
We already see such symptom in some low-price service providers. 
I believe new service structure that can provide difference of service 
quality will offer benefit to customers, providers as well as vendors in the end.

I also look forward to see you at Paris and continue helpful discussion.

Sincerely

Jaihyung

Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550 

-----?? ???----- 
?? ??: "[email-masked]" <[email-masked]> 
?? ??: 2005-07-14 ?? 1:10:30 
?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: 
??: RE: End-to-end L2-LSP 

Jaihyung, 

Thank you for taking the time to respond to my questions. I anticipated that your response would include "over-provisioning is the best answer" to decrease the chance of congestion on non-GMPLS switches. This is what is done in the LAN environment today in conjunction with CoS, and this is why I believe there will be two opposing views on how far L2-LSP connections should be extended down to the user. One view is that over provisioning and CoS work fine in the enterprise network today, and therefore the L2-LSP should only be extended down to the point at which the enterprise network connects to the SP network, e.g. Ethernet DSLAM. I think the other view will be that over provisioning and CoS in the enterprise network don't work and therefore L2-LSPs should be provided end-to-end using only GMPLS capable switches. I wouldn't have thought there would be much call for mixed GMPLS/non-GMPLS enterprise networks (except for during migration) due to the opposing views, e.g. if over provisioning is good enough for one switch, why isn't it good enough for the other? 

I think where most people will agree is that using connections in the SPs access network does make sense in order to provide efficient link utilisation and per connection policing to ensure one customers traffic can not affect another's. Regarding the ability to set up new connections based on a request from the user (rather than constraining RSVP signalling to inside the SP network), I think this will come down to enterprise customer demand for improved service performance. If a customer wasn't getting the performance they needed from their SP and was offered a new service that allowed them to setup new L2-LSP connections on demand that would offer better performance (e.g. for voice calls or video conferences), then upgrading the user devices to support the new service could well be an attractive proposition. If on the other hand a customer buys a best effort service and considers the performance to be 'good enough', then there would be no reason to go to the expense of upgrading the user devices to support the set up of L2-LSPs. 

I look forward to the discussions in Paris. 

Regards, 
Richard 

> From: CHO, JAI HYUNG [mailto:[email-masked]] 
> Sent: 13 July 2005 15:14 
> To: Spencer,R,Richard,XDE73 R; [email-masked] 
> Subject: RE: End-to-end L2-LSP 
> 
> 
>  
>  
> Dear Richard Spencer 
>  
> see in-line 
>  
> >Jaihyung, 
> > 
> >Perhaps I'm becoming too much of a pessimist;-) 
>  
> oh, not at all, 
> you are reasonable enough to dig up unclear knowledge 
> please go ahead until you finally get satisfactory answer. 
>  
> 
> >Ignoring the commercial aspects, please can you help clarify 
> a few technical 
> >questions I have in order to help me gain a better 
> understanding of the proposal? 
> > 
> >1. You say that one of the key reasons for using GMPLS in 
> the enterprise 
> >network is to provide end-to-end QoS control. However, you 
> also say that not 
> >all the switches will need to support GMPLS, only those at 
> bottle necks. 
> >Please can you expand on this to explain how you can have end-to-end 
> >QoS control when the L2-LSP is not end-to-end? 
>  
> 
> The contextual meaning of 'End-to-end LSP' is that GMPLS label is 
> assigned from source terminal and removed at destination terminal, 
> because RSVP-TE message is exchanged from host to host. 
> It may not perfectly guarantee QoS when the GMPLS deployment 
> is not complete, however it will at least be good enough 
> for end-user applications to tell those GMPLS implemented L2 switches 
> what frame must be given priority service when congestion occur. 
>  
> 
> >As being discussed 
> >on the PWE3 mailing list, the performance a service receives 
> is only as 
> >good as the worst performing server layer. Therefore, if there is a 
> >standard 802.1 workgroup switch between the user and the 
> L2-LSP that is 
> >experiencing congestion (e.g. due to a large amount of 
> peer-to-peer traffic), 
> >then the QoS that the user receives will only be as good as 
> that provided 
> >by the congested workgroup switch. 
>  
> 
> of course, ETH-GMPLS does not prevent congestion inevitably occurring 
> in those non-GMPLS deployed part. 
>  
> 
> >The only way I can see a network using a mixture of GMPLS 
> and non-GMPLS 
> >switches guaranteeing end-to-end QoS would be to design the 
> network in 
> >such a way that the non-GMPLS switches could never become congested. 
>  
> 
> Yes, that will be the way wise network designer improve their network. 
>  
> 
> >To do this would require that RSVP requests be used for ALL 
> traffic flows 
> >to ensure that there was enough bandwidth available, along 
> with strict 
> >per L2-LSP policing on the user devices (e.g. PC). 
> >However, the obvious flaw in this approach is that someone could 
> >just come along and connect 
> >an end device to a non-GMPLS switch and start transmitting traffic 
> >(without performing CAC/policing) causing the switch to 
> become congested. 
> >Therefore, please can you explain how end-to-end QoS can be 
> guaranteed 
> >in a mixed non-GMPLS and GMPLS switching environment? 
>  
> 
> Of course traffic came from non controlled ingress can not be 
> prevented 
> in non-GMPLS node. There's no magic. Only the 
> over-provisioning is the 
> best answer. However, once the aggregated traffic pass 'ANY' one of 
> GMPLS enabled node, those uncontrolled traffic will suffer 
> queuing discipline. 
>  
> 
> >2. Section 5.1 currently states "When the customer initiates 
> data transmission, 
> >the access switch maps the user flow into the L2 LSP. 
> Mapping procedure is 
> >subject to implementation choices, and is out of the scope of this 
> >document." In order to be able to map any traffic, first of 
> all the switch needs 
> >to know what type of traffic (e.g. based on source/dest MAC, 
> VLAN ID, 802.1p 
> >bits, etc) should be mapped to the L2-LSP. In Figure 1, if 
> an L2-LSP is set up 
> >from the DSLAM to the edge router based on a request from 
> the user (e.g. via 
> >a PC or VoIP phone), then won't the user also need to signal 
> what type of 
> >traffic should to be mapped to the L2-LSP? 
>  
> 
> Thank you for pointing out important thing. 
> That's the most unfortunate part I reluctantly agreed because the 
> work condition in the framework DT was not to span L2-LSP 
> beyond provider network. 
> As you noticed, mapping user traffic at provider access is awkward. 
> A smooth method will be for user terminal aware of the L2 label 
> to use by receiving RSVP-TE message. 
> However, there was strong argument that RSVP-TE must not 
> go beyond provider network because the DT is not chartered 
> to work in customer network. 
> That's why I requested amendment of CCAMP charter 
> to include user terminal explicitly in CCAMP work scope, so that 
> avoid such silly argument in future. 
>  
> 
> >3. In section 5.1, the text states that the aggregation 
> switch between the 
> >DSLAM and edge router may be a 802.1 switch, i.e. it doesn't 
> have to support 
> >GMPLS. To set up a connection, first of all there needs to 
> be a data plane 
> >capable of carrying control plane traffic between GMPLS 
> peers. Secondly, 
> >the GMPLS peers need reachability information in order to 
> forward control 
> >messages onto the next peer (i.e. a static or IGP route). If 
> the GMPLS peers 
> >(e.g. the DSLAM and edge router in Figure 1) are not 
> directly connected, 
> >then the GMPLS control packets will need to be forwarded by 
> the 802.1 switch. 
> >Would the idea be to have say a "control traffic VLAN" 
> configured between the 
> >DSLAM and edge router via the transit 802.1 switch so that 
> control packets 
> >could be forwarded transparently by the 802.1 switch? 
>  
> 
> Although it doesn't preclude use of VLAN, I think such 
> special configuration 
> for RSVP-TE control message is not necessary in legacy switches. 
> Legacy switches only need to pass RSVP-TE messages as they 
> pass normal data frames. Only the GMPLS implemented switches 
> need to distinguish frames containing RSVP-TE messages and 
> snoop them. 
> Detail of implementation is, of course, for future discussion. 
>  
> 
> >4. If we assume that control messages can be transparently forwarded 
> >by the intermediate 802.1 aggregation switch then how are 
> user frames 
> >forwarded in the data plane by the 802.1 switch? 
>  
> 
> Legacy switches do not distinguish control/data frames. 
>  
> 
> >If the DSLAM sets up a L2-LSP 
> >to the edge router using say VLAN ID 99, how does the switch 
> know that any 
> >packets coming in with a VLAN ID of 99 should be forwarded 
> out of the port 
> >connecting to the edge router? 
>  
> 
> oh, you misunderstood the L2-LSP. 
> The question you are asking depends on how L2 label is encoded. 
> there was hot debate in the DT about the issue how L2 label 
> is encoded. 
> My proposal is to use part of MAC address for label and the 
> other people 
> argued to use VLAN ID for label. The debate was not concluded 
> because the goal of the L2SC framework document is not to select 
> implementation method but to draw necessary work scope. 
> I believe this issue will be dealt in depth after Paris meeting. 
> So, please reserve your question until then and ask to those 
> VLAN proponents. 
>  
> 
> >5. During connection setup, I take it that the GMPLS peers 
> assume that 
> >resources are available within the intermediate 802.1 switch 
> to support 
> >the connection (as its transparent). However, as there is no 
> >CAC/policing being performed by the 802.1 switch 
> >(the L2-LSPs are transparent), and due to the any-to-any and 
> broadcast 
> >based nature of Ethernet (i.e. its CL properties), then how can this 
> >assumption be made? This comes back to my original question, how 
> >can end-to-end QoS be guaranteed in an environment where there is 
> >a mixture of 802.1 and GMPLS enabled switches? 
>  
> 
> yes, you came back to the question I answered in above ;-) 
> so, please see above. 
> GMPLS enabled nodes must be positioned at points congestion 
> is likely to be expected. 
>  
> Thanks 
>  
> Jaihyung 
>  
> 
> ============================================ 
> 
>  
> 
> -----?? ???----- 
> ?? ??: "[email-masked]" <[email-masked]> 
> ?? ??: 2005-07-13 ?? 8:53:13 
> ?? ??: "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]> 
> ??: 
> ??: RE: End-to-end L2-LSP 
> 
> 
> 
> 
> Jaihyung, 
> 
> Perhaps I'm becoming too much of a pessimist;-) Ignoring the 
> commercial aspects, please can you help clarify a few 
> technical questions I have in order to help me gain a better 
> understanding of the proposal? 
> 
> 1. You say that one of the key reasons for using GMPLS in the 
> enterprise network is to provide end-to-end QoS control. 
> However, you also say that not all the switches will need to 
> support GMPLS, only those at bottle necks. Please can you 
> expand on this to explain how you can have end-to-end QoS 
> control when the L2-LSP is not end-to-end? As being discussed 
> on the PWE3 mailing list, the performance a service receives 
> is only as good as the worst performing server layer. 
> Therefore, if there is a standard 802.1 workgroup switch 
> between the user and the L2-LSP that is experiencing 
> congestion (e.g. due to a large amount of peer-to-peer 
> traffic), then the QoS that the user receives will only be as 
> good as that provided by the congested workgroup switch. 
> 
> The only way I can see a network using a mixture of GMPLS and 
> non-GMPLS switches guaranteeing end-to-end QoS would be to 
> design the network in such a way that the non-GMPLS switches 
> could never become congested. To do this would require that 
> RSVP requests be used for ALL traffic flows to ensure that 
> there was enough bandwidth available, along with strict per 
> L2-LSP policing on the user devices (e.g. PC). However, the 
> obvious flaw in this approach is that someone could just come 
> along and connect an end device to a non-GMPLS switch and 
> start transmitting traffic (without performing CAC/policing) 
> causing the switch to become congested. Therefore, please can 
> you explain how end-to-end QoS can be guaranteed in a mixed 
> non-GMPLS and GMPLS switching environment? 
> 
> 2. Section 5.1 currently states "When the customer initiates 
> data transmission, the access switch maps the user flow into 
> the L2 LSP. Mapping procedure is subject to implementation 
> choices, and is out of the scope of this document." In order 
> to be able to map any traffic, first of all the switch needs 
> to know what type of traffic (e.g. based on source/dest MAC, 
> VLAN ID, 802.1p bits, etc) should be mapped to the L2-LSP. In 
> Figure 1, if an L2-LSP is set up from the DSLAM to the edge 
> router based on a request from the user (e.g. via a PC or 
> VoIP phone), then won't the user also need to signal what 
> type of traffic should to be mapped to the L2-LSP? 
> 
> 3. In section 5.1, the text states that the aggregation 
> switch between the DSLAM and edge router may be a 802.1 
> switch, i.e. it doesn't have to support GMPLS. To set up a 
> connection, first of all there needs to be a data plane 
> capable of carrying control plane traffic between GMPLS 
> peers. Secondly, the GMPLS peers need reachability 
> information in order to forward control messages onto the 
> next peer (i.e. a static or IGP route). If the GMPLS peers 
> (e.g. the DSLAM and edge router in Figure 1) are not directly 
> connected, then the GMPLS control packets will need to be 
> forwarded by the 802.1 switch. Would the idea be to have say 
> a "control traffic VLAN" configured between the DSLAM and 
> edge router via the transit 802.1 switch so that control 
> packets could be forwarded transparently by the 802.1 switch? 
> 
> 4. If we assume that control messages can be transparently 
> forwarded by the intermediate 802.1 aggregation switch then 
> how are user frames forwarded in the data plane by the 802.1 
> switch? If the DSLAM sets up a L2-LSP to the edge router 
> using say VLAN ID 99, how does the switch know that any 
> packets coming in with a VLAN ID of 99 should be forwarded 
> out of the port connecting to the edge router? 
> 
> 5. During connection setup, I take it that the GMPLS peers 
> assume that resources are available within the intermediate 
> 802.1 switch to support the connection (as its transparent). 
> However, as there is no CAC/policing being performed by the 
> 802.1 switch (the L2-LSPs are transparent), and due to the 
> any-to-any and broadcast based nature of Ethernet (i.e. its 
> CL properties), then how can this assumption be made? This 
> comes back to my original question, how can end-to-end QoS be 
> guaranteed in an environment where there is a mixture of 
> 802.1 and GMPLS enabled switches? 
> 
> Thanks, 
> Richard 
> 
> > From: CHO, JAI HYUNG [mailto:[email-masked]] 
> > Sent: 12 July 2005 09:21 
> > To: Spencer,R,Richard,XDE73 R; [email-masked] 
> > Subject: RE: End-to-end L2-LSP 
> > 
> > 
> > 
> > 
> > Dear Richard, 
> > 
> > Yes, I believe it is not only commercially profitable but it 
> > may also grow total 
> > revenue of service operators by introducing new services. 
> > 
> > For example, think the example of IP phone you referred. 
> > How do you think you can provide reliable VoIP service and 
> > safely authenticate phone users and charge fees as counted by 
> > packet usage 
> > using simple Ethernet based xDSL network ? 
> > 
> > There's hardly new service that providers may offer using 
> > Ethernet based 
> > architecture, and collect sufficient profit to investment. 
> > 
> > A sophisticated ATM switch might do the work if it is not 
> expensive. 
> > However, my intension is modifiying existing design of 
> > Ethernet hardware 
> > with a little bit additional cost,  and provide the level of 
> > service that 
> > ATM switches might offer. 
> > 
> > We have initial design of the Ethernet-MPLS hardware. I don't think 
> > GMPLS enabled Ethernet switch will be so complex. The market price 
> > of GMPLS enabled switch will not be so expensive than normal 
> > Ethernet switches. 
> > 
> > Further, it only requires upgrade of switches in some 
> > bottleneck points of network. 
> > Read the framework documents of L2SC. It doesn't require 
> > entire replacement 
> > of switches to introduce new service. 
> > 
> > Every year, ISPs purchase new access switches and replaces 
> > old machines. 
> > With a bit additional cost, ISPs may use the GMPLS enabled 
> switch for 
> > normal Ethernet switching in initial deployment. 
> > 
> > When the GMPLS function is enabled in some upgraded part of 
> network, 
> > ISPs may provide high quality, reliable VoIP service to 
> xDSL customers 
> > using RSVP-TE enabled VoIP phone. 
> > The high quality video-phone service enabled by GMPLS will be 
> > competable to legacy voice only phone service. 
> > 
> > 
> > There are lots of things I can argue about commercial aspects 
> > of this technique. 
> > However I don't think it is not appropriate to discuss this 
> > issue in this mailing list. 
> > All I can say is, 
> > yes, I believe that it may be commercially viable. 
> > 
> > 
> > Thanks 
> > 
> > Jaihyung 
> > 
> > ================================================ 
> > 
> > Do you really think the benefits of extended GMPLS down to 
> > the end user could ever justify the costs involved in 
> > upgrading LAN switches and things like IP phones (simple low 
> > cost commodity items) to support GMPLS signalling/routing? 
> > 
> > Your proposal may be technically possible (though it would 
> > require new hardware and significant software upgrades), but 
> > commercially I would consider this to be a non-starter. 
> > 
> > Regards, 
> > Richard 
> > 
> > > From: [email-masked] 
> [mailto:[email-masked]]On 
> > > Behalf Of CHO, JAI HYUNG 
> > > Sent: 12 July 2005 01:10 
> > > To: [email-masked] 
> > > Subject: End-to-end L2-LSP 
> > > 
> > > 
> > >  
> > > Dear all, 
> > > 
> > > Greetings. 
> > > 
> > > I am a co-editor of the Ethernet-GMPLS framework document. 
> > > (draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt) 
> > > 
> > > I am writing this to explain the motivation behind the 
> > > proposal of scenario-1, and to raise the issue of 
> > > end-to-end LSP to be included in CCAMP charter. 
> > > 
> > > An important goal intended in scenario-1 is 
> > > QoS control over end-to-end packet delivery using LSP. 
> > > In other words, the purpose of scenario-1 is extending coverage 
> > > of GMPLS control including customer network and end-user device, 
> > > such as PC, VoIP phone, IP-TV, or even future 4G mobile phone. 
> > > End-user applications will have a means to request resources 
> > > to network using GMPLS signal. 
> > > 
> > > Unfortunately, this view is not included in the 
> > > framework because there was strong opinion that 
> > > L2-LSP must not span beyond provider network because 
> > > CCAMP is not chartered to work on customer 
> > > network. I am wondering if this is right argument. 
> > > Perhaps the charter can be amended to include this work. 
> > > 
> > > I believe there is little technical reason to preclude 
> > > LSP being used in customer network. It is a reasonable 
> > > assumption that private company may also use GMPLS 
> > > implemented Ethernet switch, once the L2SC work is successful. 
> > > Currently, CCAMP is the only place discussing the matter of 
> > > Ethernet and LSP. There is no other WG dealing similar issue. 
> > > If CCAMP wants to work on Ethernet, 
> > > I think the coverage of common GMPLS control must be 
> > > extended to include all area where Ethernet is deployed. 
> > > Currently, Ethernet is dominantly deployed in first-mile 
> > > network where access network as well as customer network 
> > > and user hosts are usually included. Therefore, user host must 
> > > be considered as initiation and termination point of L2-LSP. 
> > > 
> > > Another important reason to include user host in CCAMP 
> > > work scope is to achieve consistent end-to-end control of QoS. 
> > > End-to-end QoS has long been desired goal since RSVP was 
> > > first designed. This goal can be best achieved using 
> > > end-to-end GMPLS signal and L2-LSP. 
> > > Currently, RSVP (RFC2205) is available in many user hosts. 
> > > There is only a little difference between RSVP and RSVP-TE. 
> > > If the RSVP-TE signal of provider network can reach user host 
> > > across Ethernet based private network, an LSP can be established 
> > > from application to application via the provider backbone. 
> > > Service providers will be able to control application flows 
> > > in L2-LSP level as well as in aggregated LSP pipe of similar 
> > > application type. A variety of new services will be enabled using 
> > > the enhanced capability of distinguishing and controlling each 
> > > individual application flow. 
> > > 
> > > I personally believe that end-to-end L2-LSP may offer 
> > > innovative solutions for servicing IP-TV as well as fast 
> mobility. 
> > > There have been some experimental approaches combining 
> > > MPLS and IP mobility. However such potential of the new 
> > > application can only be explored when end-user host is 
> > > included in the scope of CCAMP work area. 
> > > 
> > > Therefore, I hereby sincerely request people's attention 
> > > and support on this perspective of end-to-end LSP. 
> > > If there is enough number of people agree on this view, 
> > > the WG can request the necessary update of the charter. 
> > > 
> > > Thank you. 
> > >  
> > > Jaihyung Cho 
> > >  
> > >  
> > >  
> > > ETRI, Korea 
> > > phone :       042) 860-5514 
> > > oversea: +82-42-860-5514 
> > > fax:         +82-42-861-5550 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 

Delivery-date: Wed, 13 Jul 2005 16:11:35 +0000
content-class: urn:content-classes:message
Subject: RE: End-to-end L2-LSP
Date: Wed, 13 Jul 2005 17:10:30 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Jaihyung,

Thank you for taking the time to respond to my questions. I anticipated =
that your response would include "over-provisioning is the best answer" =
to decrease the chance of congestion on non-GMPLS switches. This is what =
is done in the LAN environment today in conjunction with CoS, and this =
is why I believe there will be two opposing views on how far L2-LSP =
connections should be extended down to the user. One view is that over =
provisioning and CoS work fine in the enterprise network today, and =
therefore the L2-LSP should only be extended down to the point at which =
the enterprise network connects to the SP network, e.g. Ethernet DSLAM. =
I think the other view will be that over provisioning and CoS in the =
enterprise network don't work and therefore L2-LSPs should be provided =
end-to-end using only GMPLS capable switches. I wouldn't have thought =
there would be much call for mixed GMPLS/non-GMPLS enterprise networks =
(except for during migration) due to the opposing views, e.g. if over =
provisioning is good enough for one switch, why isn't it good enough for =
the other?

I think where most people will agree is that using connections in the =
SPs access network does make sense in order to provide efficient link =
utilisation and per connection policing to ensure one customers traffic =
can not affect another's. Regarding the ability to set up new =
connections based on a request from the user (rather than constraining =
RSVP signalling to inside the SP network), I think this will come down =
to enterprise customer demand for improved service performance. If a =
customer wasn't getting the performance they needed from their SP and =
was offered a new service that allowed them to setup new L2-LSP =
connections on demand that would offer better performance (e.g. for =
voice calls or video conferences), then upgrading the user devices to =
support the new service could well be an attractive proposition. If on =
the other hand a customer buys a best effort service and considers the =
performance to be 'good enough', then there would be no reason to go to =
the expense of upgrading the user devices to support the set up of =
L2-LSPs.

I look forward to the discussions in Paris.

Regards,
Richard

> From: CHO, JAI HYUNG [mailto:[email-masked]]
> Sent: 13 July 2005 15:14
> To: Spencer,R,Richard,XDE73 R; [email-masked]
> Subject: RE: End-to-end L2-LSP
>=20
>=20
> =20
> =20
> Dear Richard Spencer=20
> =20
> see in-line
> =20
> >Jaihyung,=20
> >=20
> >Perhaps I'm becoming too much of a pessimist;-)=20
> =20
> oh, not at all,=20
> you are reasonable enough to dig up unclear knowledge=20
> please go ahead until you finally get satisfactory answer.
> =20
>=20
> >Ignoring the commercial aspects, please can you help clarify=20
> a few technical=20
> >questions I have in order to help me gain a better=20
> understanding of the proposal?=20
> >=20
> >1. You say that one of the key reasons for using GMPLS in=20
> the enterprise=20
> >network is to provide end-to-end QoS control. However, you=20
> also say that not=20
> >all the switches will need to support GMPLS, only those at=20
> bottle necks.=20
> >Please can you expand on this to explain how you can have end-to-end=20
> >QoS control when the L2-LSP is not end-to-end?=20
> =20
>=20
> The contextual meaning of 'End-to-end LSP' is that GMPLS label is=20
> assigned from source terminal and removed at destination terminal,=20
> because RSVP-TE message is exchanged from host to host.=20
> It may not perfectly guarantee QoS when the GMPLS deployment=20
> is not complete, however it will at least be good enough=20
> for end-user applications to tell those GMPLS implemented L2 switches=20
> what frame must be given priority service when congestion occur.
> =20
>=20
> >As being discussed=20
> >on the PWE3 mailing list, the performance a service receives=20
> is only as=20
> >good as the worst performing server layer. Therefore, if there is a=20
> >standard 802.1 workgroup switch between the user and the=20
> L2-LSP that is=20
> >experiencing congestion (e.g. due to a large amount of=20
> peer-to-peer traffic),=20
> >then the QoS that the user receives will only be as good as=20
> that provided=20
> >by the congested workgroup switch.
> =20
>=20
> of course, ETH-GMPLS does not prevent congestion inevitably occurring=20
> in those non-GMPLS deployed part.=20
> =20
>=20
> >The only way I can see a network using a mixture of GMPLS=20
> and non-GMPLS=20
> >switches guaranteeing end-to-end QoS would be to design the=20
> network in=20
> >such a way that the non-GMPLS switches could never become congested.
> =20
>=20
> Yes, that will be the way wise network designer improve their network.
> =20
>=20
> >To do this would require that RSVP requests be used for ALL=20
> traffic flows=20
> >to ensure that there was enough bandwidth available, along=20
> with strict=20
> >per L2-LSP policing on the user devices (e.g. PC).=20
> >However, the obvious flaw in this approach is that someone could=20
> >just come along and connect=20
> >an end device to a non-GMPLS switch and start transmitting traffic=20
> >(without performing CAC/policing) causing the switch to=20
> become congested.=20
> >Therefore, please can you explain how end-to-end QoS can be=20
> guaranteed=20
> >in a mixed non-GMPLS and GMPLS switching environment?
> =20
>=20
> Of course traffic came from non controlled ingress can not be=20
> prevented=20
> in non-GMPLS node. There's no magic. Only the=20
> over-provisioning is the=20
> best answer. However, once the aggregated traffic pass 'ANY' one of=20
> GMPLS enabled node, those uncontrolled traffic will suffer=20
> queuing discipline.
> =20
>=20
> >2. Section 5.1 currently states "When the customer initiates=20
> data transmission,=20
> >the access switch maps the user flow into the L2 LSP.=20
> Mapping procedure is=20
> >subject to implementation choices, and is out of the scope of this=20
> >document." In order to be able to map any traffic, first of=20
> all the switch needs=20
> >to know what type of traffic (e.g. based on source/dest MAC,=20
> VLAN ID, 802.1p=20
> >bits, etc) should be mapped to the L2-LSP. In Figure 1, if=20
> an L2-LSP is set up=20
> >from the DSLAM to the edge router based on a request from=20
> the user (e.g. via=20
> >a PC or VoIP phone), then won't the user also need to signal=20
> what type of=20
> >traffic should to be mapped to the L2-LSP?
> =20
>=20
> Thank you for pointing out important thing.=20
> That's the most unfortunate part I reluctantly agreed because the=20
> work condition in the framework DT was not to span L2-LSP=20
> beyond provider network.=20
> As you noticed, mapping user traffic at provider access is awkward.=20
> A smooth method will be for user terminal aware of the L2 label=20
> to use by receiving RSVP-TE message.=20
> However, there was strong argument that RSVP-TE must not=20
> go beyond provider network because the DT is not chartered=20
> to work in customer network.=20
> That's why I requested amendment of CCAMP charter=20
> to include user terminal explicitly in CCAMP work scope, so that=20
> avoid such silly argument in future.
> =20
>=20
> >3. In section 5.1, the text states that the aggregation=20
> switch between the=20
> >DSLAM and edge router may be a 802.1 switch, i.e. it doesn't=20
> have to support=20
> >GMPLS. To set up a connection, first of all there needs to=20
> be a data plane=20
> >capable of carrying control plane traffic between GMPLS=20
> peers. Secondly,=20
> >the GMPLS peers need reachability information in order to=20
> forward control=20
> >messages onto the next peer (i.e. a static or IGP route). If=20
> the GMPLS peers=20
> >(e.g. the DSLAM and edge router in Figure 1) are not=20
> directly connected,=20
> >then the GMPLS control packets will need to be forwarded by=20
> the 802.1 switch.=20
> >Would the idea be to have say a "control traffic VLAN"=20
> configured between the=20
> >DSLAM and edge router via the transit 802.1 switch so that=20
> control packets=20
> >could be forwarded transparently by the 802.1 switch?
> =20
>=20
> Although it doesn't preclude use of VLAN, I think such=20
> special configuration=20
> for RSVP-TE control message is not necessary in legacy switches.=20
> Legacy switches only need to pass RSVP-TE messages as they=20
> pass normal data frames. Only the GMPLS implemented switches=20
> need to distinguish frames containing RSVP-TE messages and=20
> snoop them.=20
> Detail of implementation is, of course, for future discussion.
> =20
>=20
> >4. If we assume that control messages can be transparently forwarded=20
> >by the intermediate 802.1 aggregation switch then how are=20
> user frames=20
> >forwarded in the data plane by the 802.1 switch?=20
> =20
>=20
> Legacy switches do not distinguish control/data frames.
> =20
>=20
> >If the DSLAM sets up a L2-LSP=20
> >to the edge router using say VLAN ID 99, how does the switch=20
> know that any=20
> >packets coming in with a VLAN ID of 99 should be forwarded=20
> out of the port=20
> >connecting to the edge router?
> =20
>=20
> oh, you misunderstood the L2-LSP.=20
> The question you are asking depends on how L2 label is encoded.=20
> there was hot debate in the DT about the issue how L2 label=20
> is encoded.=20
> My proposal is to use part of MAC address for label and the=20
> other people=20
> argued to use VLAN ID for label. The debate was not concluded=20
> because the goal of the L2SC framework document is not to select=20
> implementation method but to draw necessary work scope.=20
> I believe this issue will be dealt in depth after Paris meeting.=20
> So, please reserve your question until then and ask to those=20
> VLAN proponents.
> =20
>=20
> >5. During connection setup, I take it that the GMPLS peers=20
> assume that=20
> >resources are available within the intermediate 802.1 switch=20
> to support=20
> >the connection (as its transparent). However, as there is no=20
> >CAC/policing being performed by the 802.1 switch=20
> >(the L2-LSPs are transparent), and due to the any-to-any and=20
> broadcast=20
> >based nature of Ethernet (i.e. its CL properties), then how can this=20
> >assumption be made? This comes back to my original question, how=20
> >can end-to-end QoS be guaranteed in an environment where there is=20
> >a mixture of 802.1 and GMPLS enabled switches?
> =20
>=20
> yes, you came back to the question I answered in above ;-)=20
> so, please see above.=20
> GMPLS enabled nodes must be positioned at points congestion=20
> is likely to be expected.
> =20
> Thanks
> =20
> Jaihyung
> =20
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
>=20
> =20
>=20
> -----?? ???-----=20
> ?? ??: "[email-masked]" <[email-masked]>=20
> ?? ??: 2005-07-13 ?? 8:53:13=20
> ?? ??: "[email-masked]" <[email-masked]>,=20
> "[email-masked]" <[email-masked]>=20
> ??:=20
> ??: RE: End-to-end L2-LSP=20
>=20
>=20
>=20
>=20
> Jaihyung,=20
>=20
> Perhaps I'm becoming too much of a pessimist;-) Ignoring the=20
> commercial aspects, please can you help clarify a few=20
> technical questions I have in order to help me gain a better=20
> understanding of the proposal?=20
>=20
> 1. You say that one of the key reasons for using GMPLS in the=20
> enterprise network is to provide end-to-end QoS control.=20
> However, you also say that not all the switches will need to=20
> support GMPLS, only those at bottle necks. Please can you=20
> expand on this to explain how you can have end-to-end QoS=20
> control when the L2-LSP is not end-to-end? As being discussed=20
> on the PWE3 mailing list, the performance a service receives=20
> is only as good as the worst performing server layer.=20
> Therefore, if there is a standard 802.1 workgroup switch=20
> between the user and the L2-LSP that is experiencing=20
> congestion (e.g. due to a large amount of peer-to-peer=20
> traffic), then the QoS that the user receives will only be as=20
> good as that provided by the congested workgroup switch.=20
>=20
> The only way I can see a network using a mixture of GMPLS and=20
> non-GMPLS switches guaranteeing end-to-end QoS would be to=20
> design the network in such a way that the non-GMPLS switches=20
> could never become congested. To do this would require that=20
> RSVP requests be used for ALL traffic flows to ensure that=20
> there was enough bandwidth available, along with strict per=20
> L2-LSP policing on the user devices (e.g. PC). However, the=20
> obvious flaw in this approach is that someone could just come=20
> along and connect an end device to a non-GMPLS switch and=20
> start transmitting traffic (without performing CAC/policing)=20
> causing the switch to become congested. Therefore, please can=20
> you explain how end-to-end QoS can be guaranteed in a mixed=20
> non-GMPLS and GMPLS switching environment?=20
>=20
> 2. Section 5.1 currently states "When the customer initiates=20
> data transmission, the access switch maps the user flow into=20
> the L2 LSP. Mapping procedure is subject to implementation=20
> choices, and is out of the scope of this document." In order=20
> to be able to map any traffic, first of all the switch needs=20
> to know what type of traffic (e.g. based on source/dest MAC,=20
> VLAN ID, 802.1p bits, etc) should be mapped to the L2-LSP. In=20
> Figure 1, if an L2-LSP is set up from the DSLAM to the edge=20
> router based on a request from the user (e.g. via a PC or=20
> VoIP phone), then won't the user also need to signal what=20
> type of traffic should to be mapped to the L2-LSP?=20
>=20
> 3. In section 5.1, the text states that the aggregation=20
> switch between the DSLAM and edge router may be a 802.1=20
> switch, i.e. it doesn't have to support GMPLS. To set up a=20
> connection, first of all there needs to be a data plane=20
> capable of carrying control plane traffic between GMPLS=20
> peers. Secondly, the GMPLS peers need reachability=20
> information in order to forward control messages onto the=20
> next peer (i.e. a static or IGP route). If the GMPLS peers=20
> (e.g. the DSLAM and edge router in Figure 1) are not directly=20
> connected, then the GMPLS control packets will need to be=20
> forwarded by the 802.1 switch. Would the idea be to have say=20
> a "control traffic VLAN" configured between the DSLAM and=20
> edge router via the transit 802.1 switch so that control=20
> packets could be forwarded transparently by the 802.1 switch?=20
>=20
> 4. If we assume that control messages can be transparently=20
> forwarded by the intermediate 802.1 aggregation switch then=20
> how are user frames forwarded in the data plane by the 802.1=20
> switch? If the DSLAM sets up a L2-LSP to the edge router=20
> using say VLAN ID 99, how does the switch know that any=20
> packets coming in with a VLAN ID of 99 should be forwarded=20
> out of the port connecting to the edge router?=20
>=20
> 5. During connection setup, I take it that the GMPLS peers=20
> assume that resources are available within the intermediate=20
> 802.1 switch to support the connection (as its transparent).=20
> However, as there is no CAC/policing being performed by the=20
> 802.1 switch (the L2-LSPs are transparent), and due to the=20
> any-to-any and broadcast based nature of Ethernet (i.e. its=20
> CL properties), then how can this assumption be made? This=20
> comes back to my original question, how can end-to-end QoS be=20
> guaranteed in an environment where there is a mixture of=20
> 802.1 and GMPLS enabled switches?=20
>=20
> Thanks,=20
> Richard=20
>=20
> > -----Original Message-----=20
> > From: CHO, JAI HYUNG [mailto:[email-masked]]=20
> > Sent: 12 July 2005 09:21=20
> > To: Spencer,R,Richard,XDE73 R; [email-masked]=20
> > Subject: RE: End-to-end L2-LSP=20
> >=20
> >=20
> >=20
> >=20
> > Dear Richard,=20
> >=20
> > Yes, I believe it is not only commercially profitable but it=20
> > may also grow total=20
> > revenue of service operators by introducing new services.=20
> >=20
> > For example, think the example of IP phone you referred.=20
> > How do you think you can provide reliable VoIP service and=20
> > safely authenticate phone users and charge fees as counted by=20
> > packet usage=20
> > using simple Ethernet based xDSL network ?=20
> >=20
> > There's hardly new service that providers may offer using=20
> > Ethernet based=20
> > architecture, and collect sufficient profit to investment.=20
> >=20
> > A sophisticated ATM switch might do the work if it is not=20
> expensive.=20
> > However, my intension is modifiying existing design of=20
> > Ethernet hardware=20
> > with a little bit additional cost,  and provide the level of=20
> > service that=20
> > ATM switches might offer.=20
> >=20
> > We have initial design of the Ethernet-MPLS hardware. I don't think=20
> > GMPLS enabled Ethernet switch will be so complex. The market price=20
> > of GMPLS enabled switch will not be so expensive than normal=20
> > Ethernet switches.=20
> >=20
> > Further, it only requires upgrade of switches in some=20
> > bottleneck points of network.=20
> > Read the framework documents of L2SC. It doesn't require=20
> > entire replacement=20
> > of switches to introduce new service.=20
> >=20
> > Every year, ISPs purchase new access switches and replaces=20
> > old machines.=20
> > With a bit additional cost, ISPs may use the GMPLS enabled=20
> switch for=20
> > normal Ethernet switching in initial deployment.=20
> >=20
> > When the GMPLS function is enabled in some upgraded part of=20
> network,=20
> > ISPs may provide high quality, reliable VoIP service to=20
> xDSL customers=20
> > using RSVP-TE enabled VoIP phone.=20
> > The high quality video-phone service enabled by GMPLS will be=20
> > competable to legacy voice only phone service.=20
> >=20
> >=20
> > There are lots of things I can argue about commercial aspects=20
> > of this technique.=20
> > However I don't think it is not appropriate to discuss this=20
> > issue in this mailing list.=20
> > All I can say is,=20
> > yes, I believe that it may be commercially viable.=20
> >=20
> >=20
> > Thanks=20
> >=20
> > Jaihyung=20
> >=20
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> >=20
> > Do you really think the benefits of extended GMPLS down to=20
> > the end user could ever justify the costs involved in=20
> > upgrading LAN switches and things like IP phones (simple low=20
> > cost commodity items) to support GMPLS signalling/routing?=20
> >=20
> > Your proposal may be technically possible (though it would=20
> > require new hardware and significant software upgrades), but=20
> > commercially I would consider this to be a non-starter.=20
> >=20
> > Regards,=20
> > Richard=20
> >=20
> > > -----Original Message-----=20
> > > From: [email-masked]=20
> [mailto:[email-masked]]On=20
> > > Behalf Of CHO, JAI HYUNG=20
> > > Sent: 12 July 2005 01:10=20
> > > To: [email-masked]=20
> > > Subject: End-to-end L2-LSP=20
> > >=20
> > >=20
> > > =20
> > > Dear all,=20
> > >=20
> > > Greetings.=20
> > >=20
> > > I am a co-editor of the Ethernet-GMPLS framework document.=20
> > > (draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt)=20
> > >=20
> > > I am writing this to explain the motivation behind the=20
> > > proposal of scenario-1, and to raise the issue of=20
> > > end-to-end LSP to be included in CCAMP charter.=20
> > >=20
> > > An important goal intended in scenario-1 is=20
> > > QoS control over end-to-end packet delivery using LSP.=20
> > > In other words, the purpose of scenario-1 is extending coverage=20
> > > of GMPLS control including customer network and end-user device,=20
> > > such as PC, VoIP phone, IP-TV, or even future 4G mobile phone.=20
> > > End-user applications will have a means to request resources=20
> > > to network using GMPLS signal.=20
> > >=20
> > > Unfortunately, this view is not included in the=20
> > > framework because there was strong opinion that=20
> > > L2-LSP must not span beyond provider network because=20
> > > CCAMP is not chartered to work on customer=20
> > > network. I am wondering if this is right argument.=20
> > > Perhaps the charter can be amended to include this work.=20
> > >=20
> > > I believe there is little technical reason to preclude=20
> > > LSP being used in customer network. It is a reasonable=20
> > > assumption that private company may also use GMPLS=20
> > > implemented Ethernet switch, once the L2SC work is successful.=20
> > > Currently, CCAMP is the only place discussing the matter of=20
> > > Ethernet and LSP. There is no other WG dealing similar issue.=20
> > > If CCAMP wants to work on Ethernet,=20
> > > I think the coverage of common GMPLS control must be=20
> > > extended to include all area where Ethernet is deployed.=20
> > > Currently, Ethernet is dominantly deployed in first-mile=20
> > > network where access network as well as customer network=20
> > > and user hosts are usually included. Therefore, user host must=20
> > > be considered as initiation and termination point of L2-LSP.=20
> > >=20
> > > Another important reason to include user host in CCAMP=20
> > > work scope is to achieve consistent end-to-end control of QoS.=20
> > > End-to-end QoS has long been desired goal since RSVP was=20
> > > first designed. This goal can be best achieved using=20
> > > end-to-end GMPLS signal and L2-LSP.=20
> > > Currently, RSVP (RFC2205) is available in many user hosts.=20
> > > There is only a little difference between RSVP and RSVP-TE.=20
> > > If the RSVP-TE signal of provider network can reach user host=20
> > > across Ethernet based private network, an LSP can be established=20
> > > from application to application via the provider backbone.=20
> > > Service providers will be able to control application flows=20
> > > in L2-LSP level as well as in aggregated LSP pipe of similar=20
> > > application type. A variety of new services will be enabled using=20
> > > the enhanced capability of distinguishing and controlling each=20
> > > individual application flow.=20
> > >=20
> > > I personally believe that end-to-end L2-LSP may offer=20
> > > innovative solutions for servicing IP-TV as well as fast=20
> mobility.=20
> > > There have been some experimental approaches combining=20
> > > MPLS and IP mobility. However such potential of the new=20
> > > application can only be explored when end-user host is=20
> > > included in the scope of CCAMP work area.=20
> > >=20
> > > Therefore, I hereby sincerely request people's attention=20
> > > and support on this perspective of end-to-end LSP.=20
> > > If there is enough number of people agree on this view,=20
> > > the WG can request the necessary update of the charter.=20
> > >=20
> > > Thank you.=20
> > > =20
> > > Jaihyung Cho=20
> > > =20
> > > =20
> > > =20
> > > ETRI, Korea=20
> > > phone :       042) 860-5514=20
> > > oversea: +82-42-860-5514=20
> > > fax:         +82-42-861-5550=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20

Delivery-date: Wed, 13 Jul 2005 14:14:55 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 
Bcc: 
Subject: RE: End-to-end L2-LSP
Date: Wed, 13 Jul 2005 23:14:22 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message

Dear Richard Spencer 
 
see in-line
 
>Jaihyung, 
> 
>Perhaps I'm becoming too much of a pessimist;-) 
 
oh, not at all, 
you are reasonable enough to dig up unclear knowledge 
please go ahead until you finally get satisfactory answer.

>Ignoring the commercial aspects, please can you help clarify a few technical 
>questions I have in order to help me gain a better understanding of the proposal? 
> 
>1. You say that one of the key reasons for using GMPLS in the enterprise 
>network is to provide end-to-end QoS control. However, you also say that not 
>all the switches will need to support GMPLS, only those at bottle necks. 
>Please can you expand on this to explain how you can have end-to-end 
>QoS control when the L2-LSP is not end-to-end? 

The contextual meaning of 'End-to-end LSP' is that GMPLS label is 
assigned from source terminal and removed at destination terminal, 
because RSVP-TE message is exchanged from host to host. 
It may not perfectly guarantee QoS when the GMPLS deployment 
is not complete, however it will at least be good enough 
for end-user applications to tell those GMPLS implemented L2 switches 
what frame must be given priority service when congestion occur.

>As being discussed 
>on the PWE3 mailing list, the performance a service receives is only as 
>good as the worst performing server layer. Therefore, if there is a 
>standard 802.1 workgroup switch between the user and the L2-LSP that is 
>experiencing congestion (e.g. due to a large amount of peer-to-peer traffic), 
>then the QoS that the user receives will only be as good as that provided 
>by the congested workgroup switch.

of course, ETH-GMPLS does not prevent congestion inevitably occurring 
in those non-GMPLS deployed part. 

>The only way I can see a network using a mixture of GMPLS and non-GMPLS 
>switches guaranteeing end-to-end QoS would be to design the network in 
>such a way that the non-GMPLS switches could never become congested.

Yes, that will be the way wise network designer improve their network.

>To do this would require that RSVP requests be used for ALL traffic flows 
>to ensure that there was enough bandwidth available, along with strict 
>per L2-LSP policing on the user devices (e.g. PC). 
>However, the obvious flaw in this approach is that someone could 
>just come along and connect 
>an end device to a non-GMPLS switch and start transmitting traffic 
>(without performing CAC/policing) causing the switch to become congested. 
>Therefore, please can you explain how end-to-end QoS can be guaranteed 
>in a mixed non-GMPLS and GMPLS switching environment?

Of course traffic came from non controlled ingress can not be prevented 
in non-GMPLS node. There's no magic. Only the over-provisioning is the 
best answer. However, once the aggregated traffic pass 'ANY' one of 
GMPLS enabled node, those uncontrolled traffic will suffer queuing discipline.

>2. Section 5.1 currently states "When the customer initiates data transmission, 
>the access switch maps the user flow into the L2 LSP. Mapping procedure is 
>subject to implementation choices, and is out of the scope of this 
>document." In order to be able to map any traffic, first of all the switch needs 
>to know what type of traffic (e.g. based on source/dest MAC, VLAN ID, 802.1p 
>bits, etc) should be mapped to the L2-LSP. In Figure 1, if an L2-LSP is set up 
>from the DSLAM to the edge router based on a request from the user (e.g. via 
>a PC or VoIP phone), then won't the user also need to signal what type of 
>traffic should to be mapped to the L2-LSP?

Thank you for pointing out important thing. 
That's the most unfortunate part I reluctantly agreed because the 
work condition in the framework DT was not to span L2-LSP 
beyond provider network. 
As you noticed, mapping user traffic at provider access is awkward. 
A smooth method will be for user terminal aware of the L2 label 
to use by receiving RSVP-TE message. 
However, there was strong argument that RSVP-TE must not 
go beyond provider network because the DT is not chartered 
to work in customer network. 
That's why I requested amendment of CCAMP charter 
to include user terminal explicitly in CCAMP work scope, so that 
avoid such silly argument in future.

>3. In section 5.1, the text states that the aggregation switch between the 
>DSLAM and edge router may be a 802.1 switch, i.e. it doesn't have to support 
>GMPLS. To set up a connection, first of all there needs to be a data plane 
>capable of carrying control plane traffic between GMPLS peers. Secondly, 
>the GMPLS peers need reachability information in order to forward control 
>messages onto the next peer (i.e. a static or IGP route). If the GMPLS peers 
>(e.g. the DSLAM and edge router in Figure 1) are not directly connected, 
>then the GMPLS control packets will need to be forwarded by the 802.1 switch. 
>Would the idea be to have say a "control traffic VLAN" configured between the 
>DSLAM and edge router via the transit 802.1 switch so that control packets 
>could be forwarded transparently by the 802.1 switch?

Although it doesn't preclude use of VLAN, I think such special configuration 
for RSVP-TE control message is not necessary in legacy switches. 
Legacy switches only need to pass RSVP-TE messages as they 
pass normal data frames. Only the GMPLS implemented switches 
need to distinguish frames containing RSVP-TE messages and snoop them. 
Detail of implementation is, of course, for future discussion.

>4. If we assume that control messages can be transparently forwarded 
>by the intermediate 802.1 aggregation switch then how are user frames 
>forwarded in the data plane by the 802.1 switch? 

Legacy switches do not distinguish control/data frames.

>If the DSLAM sets up a L2-LSP 
>to the edge router using say VLAN ID 99, how does the switch know that any 
>packets coming in with a VLAN ID of 99 should be forwarded out of the port 
>connecting to the edge router?

oh, you misunderstood the L2-LSP. 
The question you are asking depends on how L2 label is encoded. 
there was hot debate in the DT about the issue how L2 label is encoded. 
My proposal is to use part of MAC address for label and the other people 
argued to use VLAN ID for label. The debate was not concluded 
because the goal of the L2SC framework document is not to select 
implementation method but to draw necessary work scope. 
I believe this issue will be dealt in depth after Paris meeting. 
So, please reserve your question until then and ask to those VLAN proponents.

>5. During connection setup, I take it that the GMPLS peers assume that 
>resources are available within the intermediate 802.1 switch to support 
>the connection (as its transparent). However, as there is no 
>CAC/policing being performed by the 802.1 switch 
>(the L2-LSPs are transparent), and due to the any-to-any and broadcast 
>based nature of Ethernet (i.e. its CL properties), then how can this 
>assumption be made? This comes back to my original question, how 
>can end-to-end QoS be guaranteed in an environment where there is 
>a mixture of 802.1 and GMPLS enabled switches?

yes, you came back to the question I answered in above ;-) 
so, please see above. 
GMPLS enabled nodes must be positioned at points congestion 
is likely to be expected.
 
Thanks
 
Jaihyung

============================================ 

-----?? ???----- 
?? ??: "[email-masked]" <[email-masked]> 
?? ??: 2005-07-13 ?? 8:53:13 
?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: 
??: RE: End-to-end L2-LSP 

Jaihyung, 

Perhaps I'm becoming too much of a pessimist;-) Ignoring the commercial aspects, please can you help clarify a few technical questions I have in order to help me gain a better understanding of the proposal? 

1. You say that one of the key reasons for using GMPLS in the enterprise network is to provide end-to-end QoS control. However, you also say that not all the switches will need to support GMPLS, only those at bottle necks. Please can you expand on this to explain how you can have end-to-end QoS control when the L2-LSP is not end-to-end? As being discussed on the PWE3 mailing list, the performance a service receives is only as good as the worst performing server layer. Therefore, if there is a standard 802.1 workgroup switch between the user and the L2-LSP that is experiencing congestion (e.g. due to a large amount of peer-to-peer traffic), then the QoS that the user receives will only be as good as that provided by the congested workgroup switch. 

The only way I can see a network using a mixture of GMPLS and non-GMPLS switches guaranteeing end-to-end QoS would be to design the network in such a way that the non-GMPLS switches could never become congested. To do this would require that RSVP requests be used for ALL traffic flows to ensure that there was enough bandwidth available, along with strict per L2-LSP policing on the user devices (e.g. PC). However, the obvious flaw in this approach is that someone could just come along and connect an end device to a non-GMPLS switch and start transmitting traffic (without performing CAC/policing) causing the switch to become congested. Therefore, please can you explain how end-to-end QoS can be guaranteed in a mixed non-GMPLS and GMPLS switching environment? 

2. Section 5.1 currently states "When the customer initiates data transmission, the access switch maps the user flow into the L2 LSP. Mapping procedure is subject to implementation choices, and is out of the scope of this document." In order to be able to map any traffic, first of all the switch needs to know what type of traffic (e.g. based on source/dest MAC, VLAN ID, 802.1p bits, etc) should be mapped to the L2-LSP. In Figure 1, if an L2-LSP is set up from the DSLAM to the edge router based on a request from the user (e.g. via a PC or VoIP phone), then won't the user also need to signal what type of traffic should to be mapped to the L2-LSP? 

3. In section 5.1, the text states that the aggregation switch between the DSLAM and edge router may be a 802.1 switch, i.e. it doesn't have to support GMPLS. To set up a connection, first of all there needs to be a data plane capable of carrying control plane traffic between GMPLS peers. Secondly, the GMPLS peers need reachability information in order to forward control messages onto the next peer (i.e. a static or IGP route). If the GMPLS peers (e.g. the DSLAM and edge router in Figure 1) are not directly connected, then the GMPLS control packets will need to be forwarded by the 802.1 switch. Would the idea be to have say a "control traffic VLAN" configured between the DSLAM and edge router via the transit 802.1 switch so that control packets could be forwarded transparently by the 802.1 switch? 

4. If we assume that control messages can be transparently forwarded by the intermediate 802.1 aggregation switch then how are user frames forwarded in the data plane by the 802.1 switch? If the DSLAM sets up a L2-LSP to the edge router using say VLAN ID 99, how does the switch know that any packets coming in with a VLAN ID of 99 should be forwarded out of the port connecting to the edge router? 

5. During connection setup, I take it that the GMPLS peers assume that resources are available within the intermediate 802.1 switch to support the connection (as its transparent). However, as there is no CAC/policing being performed by the 802.1 switch (the L2-LSPs are transparent), and due to the any-to-any and broadcast based nature of Ethernet (i.e. its CL properties), then how can this assumption be made? This comes back to my original question, how can end-to-end QoS be guaranteed in an environment where there is a mixture of 802.1 and GMPLS enabled switches? 

Thanks, 
Richard 

> From: CHO, JAI HYUNG [mailto:[email-masked]] 
> Sent: 12 July 2005 09:21 
> To: Spencer,R,Richard,XDE73 R; [email-masked] 
> Subject: RE: End-to-end L2-LSP 
> 
> 
> 
> 
> Dear Richard, 
> 
> Yes, I believe it is not only commercially profitable but it 
> may also grow total 
> revenue of service operators by introducing new services. 
> 
> For example, think the example of IP phone you referred. 
> How do you think you can provide reliable VoIP service and 
> safely authenticate phone users and charge fees as counted by 
> packet usage 
> using simple Ethernet based xDSL network ? 
> 
> There's hardly new service that providers may offer using 
> Ethernet based 
> architecture, and collect sufficient profit to investment. 
> 
> A sophisticated ATM switch might do the work if it is not expensive. 
> However, my intension is modifiying existing design of 
> Ethernet hardware 
> with a little bit additional cost,  and provide the level of 
> service that 
> ATM switches might offer. 
> 
> We have initial design of the Ethernet-MPLS hardware. I don't think 
> GMPLS enabled Ethernet switch will be so complex. The market price 
> of GMPLS enabled switch will not be so expensive than normal 
> Ethernet switches. 
> 
> Further, it only requires upgrade of switches in some 
> bottleneck points of network. 
> Read the framework documents of L2SC. It doesn't require 
> entire replacement 
> of switches to introduce new service. 
> 
> Every year, ISPs purchase new access switches and replaces 
> old machines. 
> With a bit additional cost, ISPs may use the GMPLS enabled switch for 
> normal Ethernet switching in initial deployment. 
> 
> When the GMPLS function is enabled in some upgraded part of network, 
> ISPs may provide high quality, reliable VoIP service to xDSL customers 
> using RSVP-TE enabled VoIP phone. 
> The high quality video-phone service enabled by GMPLS will be 
> competable to legacy voice only phone service. 
> 
> 
> There are lots of things I can argue about commercial aspects 
> of this technique. 
> However I don't think it is not appropriate to discuss this 
> issue in this mailing list. 
> All I can say is, 
> yes, I believe that it may be commercially viable. 
> 
> 
> Thanks 
> 
> Jaihyung 
> 
> ================================================ 
> 
> Do you really think the benefits of extended GMPLS down to 
> the end user could ever justify the costs involved in 
> upgrading LAN switches and things like IP phones (simple low 
> cost commodity items) to support GMPLS signalling/routing? 
> 
> Your proposal may be technically possible (though it would 
> require new hardware and significant software upgrades), but 
> commercially I would consider this to be a non-starter. 
> 
> Regards, 
> Richard 
> 
> > From: [email-masked] [mailto:[email-masked]]On 
> > Behalf Of CHO, JAI HYUNG 
> > Sent: 12 July 2005 01:10 
> > To: [email-masked] 
> > Subject: End-to-end L2-LSP 
> > 
> > 
> >  
> > Dear all, 
> > 
> > Greetings. 
> > 
> > I am a co-editor of the Ethernet-GMPLS framework document. 
> > (draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt) 
> > 
> > I am writing this to explain the motivation behind the 
> > proposal of scenario-1, and to raise the issue of 
> > end-to-end LSP to be included in CCAMP charter. 
> > 
> > An important goal intended in scenario-1 is 
> > QoS control over end-to-end packet delivery using LSP. 
> > In other words, the purpose of scenario-1 is extending coverage 
> > of GMPLS control including customer network and end-user device, 
> > such as PC, VoIP phone, IP-TV, or even future 4G mobile phone. 
> > End-user applications will have a means to request resources 
> > to network using GMPLS signal. 
> > 
> > Unfortunately, this view is not included in the 
> > framework because there was strong opinion that 
> > L2-LSP must not span beyond provider network because 
> > CCAMP is not chartered to work on customer 
> > network. I am wondering if this is right argument. 
> > Perhaps the charter can be amended to include this work. 
> > 
> > I believe there is little technical reason to preclude 
> > LSP being used in customer network. It is a reasonable 
> > assumption that private company may also use GMPLS 
> > implemented Ethernet switch, once the L2SC work is successful. 
> > Currently, CCAMP is the only place discussing the matter of 
> > Ethernet and LSP. There is no other WG dealing similar issue. 
> > If CCAMP wants to work on Ethernet, 
> > I think the coverage of common GMPLS control must be 
> > extended to include all area where Ethernet is deployed. 
> > Currently, Ethernet is dominantly deployed in first-mile 
> > network where access network as well as customer network 
> > and user hosts are usually included. Therefore, user host must 
> > be considered as initiation and termination point of L2-LSP. 
> > 
> > Another important reason to include user host in CCAMP 
> > work scope is to achieve consistent end-to-end control of QoS. 
> > End-to-end QoS has long been desired goal since RSVP was 
> > first designed. This goal can be best achieved using 
> > end-to-end GMPLS signal and L2-LSP. 
> > Currently, RSVP (RFC2205) is available in many user hosts. 
> > There is only a little difference between RSVP and RSVP-TE. 
> > If the RSVP-TE signal of provider network can reach user host 
> > across Ethernet based private network, an LSP can be established 
> > from application to application via the provider backbone. 
> > Service providers will be able to control application flows 
> > in L2-LSP level as well as in aggregated LSP pipe of similar 
> > application type. A variety of new services will be enabled using 
> > the enhanced capability of distinguishing and controlling each 
> > individual application flow. 
> > 
> > I personally believe that end-to-end L2-LSP may offer 
> > innovative solutions for servicing IP-TV as well as fast mobility. 
> > There have been some experimental approaches combining 
> > MPLS and IP mobility. However such potential of the new 
> > application can only be explored when end-user host is 
> > included in the scope of CCAMP work area. 
> > 
> > Therefore, I hereby sincerely request people's attention 
> > and support on this perspective of end-to-end LSP. 
> > If there is enough number of people agree on this view, 
> > the WG can request the necessary update of the charter. 
> > 
> > Thank you. 
> >  
> > Jaihyung Cho 
> >  
> >  
> >  
> > ETRI, Korea 
> > phone :       042) 860-5514 
> > oversea: +82-42-860-5514 
> > fax:         +82-42-861-5550 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 

Delivery-date: Wed, 13 Jul 2005 11:54:55 +0000
content-class: urn:content-classes:message
Subject: RE: End-to-end L2-LSP
Date: Wed, 13 Jul 2005 12:53:13 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Jaihyung,

Perhaps I'm becoming too much of a pessimist;-) Ignoring the commercial =
aspects, please can you help clarify a few technical questions I have in =
order to help me gain a better understanding of the proposal?=20

1. You say that one of the key reasons for using GMPLS in the enterprise =
network is to provide end-to-end QoS control. However, you also say that =
not all the switches will need to support GMPLS, only those at bottle =
necks. Please can you expand on this to explain how you can have =
end-to-end QoS control when the L2-LSP is not end-to-end? As being =
discussed on the PWE3 mailing list, the performance a service receives =
is only as good as the worst performing server layer. Therefore, if =
there is a standard 802.1 workgroup switch between the user and the =
L2-LSP that is experiencing congestion (e.g. due to a large amount of =
peer-to-peer traffic), then the QoS that the user receives will only be =
as good as that provided by the congested workgroup switch.

The only way I can see a network using a mixture of GMPLS and non-GMPLS =
switches guaranteeing end-to-end QoS would be to design the network in =
such a way that the non-GMPLS switches could never become congested. To =
do this would require that RSVP requests be used for ALL traffic flows =
to ensure that there was enough bandwidth available, along with strict =
per L2-LSP policing on the user devices (e.g. PC). However, the obvious =
flaw in this approach is that someone could just come along and connect =
an end device to a non-GMPLS switch and start transmitting traffic =
(without performing CAC/policing) causing the switch to become =
congested. Therefore, please can you explain how end-to-end QoS can be =
guaranteed in a mixed non-GMPLS and GMPLS switching environment?=20

2. Section 5.1 currently states "When the customer initiates data =
transmission, the access switch maps the user flow into the L2 LSP. =
Mapping procedure is subject to implementation choices, and is out of =
the scope of this document." In order to be able to map any traffic, =
first of all the switch needs to know what type of traffic (e.g. based =
on source/dest MAC, VLAN ID, 802.1p bits, etc) should be mapped to the =
L2-LSP. In Figure 1, if an L2-LSP is set up from the DSLAM to the edge =
router based on a request from the user (e.g. via a PC or VoIP phone), =
then won't the user also need to signal what type of traffic should to =
be mapped to the L2-LSP?

3. In section 5.1, the text states that the aggregation switch between =
the DSLAM and edge router may be a 802.1 switch, i.e. it doesn't have to =
support GMPLS. To set up a connection, first of all there needs to be a =
data plane capable of carrying control plane traffic between GMPLS =
peers. Secondly, the GMPLS peers need reachability information in order =
to forward control messages onto the next peer (i.e. a static or IGP =
route). If the GMPLS peers (e.g. the DSLAM and edge router in Figure 1) =
are not directly connected, then the GMPLS control packets will need to =
be forwarded by the 802.1 switch. Would the idea be to have say a =
"control traffic VLAN" configured between the DSLAM and edge router via =
the transit 802.1 switch so that control packets could be forwarded =
transparently by the 802.1 switch?

4. If we assume that control messages can be transparently forwarded by =
the intermediate 802.1 aggregation switch then how are user frames =
forwarded in the data plane by the 802.1 switch? If the DSLAM sets up a =
L2-LSP to the edge router using say VLAN ID 99, how does the switch know =
that any packets coming in with a VLAN ID of 99 should be forwarded out =
of the port connecting to the edge router?

5. During connection setup, I take it that the GMPLS peers assume that =
resources are available within the intermediate 802.1 switch to support =
the connection (as its transparent). However, as there is no =
CAC/policing being performed by the 802.1 switch (the L2-LSPs are =
transparent), and due to the any-to-any and broadcast based nature of =
Ethernet (i.e. its CL properties), then how can this assumption be made? =
This comes back to my original question, how can end-to-end QoS be =
guaranteed in an environment where there is a mixture of 802.1 and GMPLS =
enabled switches?

Thanks,
Richard

> From: CHO, JAI HYUNG [mailto:[email-masked]]
> Sent: 12 July 2005 09:21
> To: Spencer,R,Richard,XDE73 R; [email-masked]
> Subject: RE: End-to-end L2-LSP
>=20
>=20
>=20
>=20
> Dear Richard,
>=20
> Yes, I believe it is not only commercially profitable but it=20
> may also grow total=20
> revenue of service operators by introducing new services.
>=20
> For example, think the example of IP phone you referred.
> How do you think you can provide reliable VoIP service and=20
> safely authenticate phone users and charge fees as counted by=20
> packet usage
> using simple Ethernet based xDSL network ?
>=20
> There's hardly new service that providers may offer using=20
> Ethernet based=20
> architecture, and collect sufficient profit to investment.
>=20
> A sophisticated ATM switch might do the work if it is not expensive.=20
> However, my intension is modifiying existing design of=20
> Ethernet hardware
> with a little bit additional cost,  and provide the level of=20
> service that=20
> ATM switches might offer.
>=20
> We have initial design of the Ethernet-MPLS hardware. I don't think
> GMPLS enabled Ethernet switch will be so complex. The market price
> of GMPLS enabled switch will not be so expensive than normal=20
> Ethernet switches.
>=20
> Further, it only requires upgrade of switches in some=20
> bottleneck points of network.
> Read the framework documents of L2SC. It doesn't require=20
> entire replacement
> of switches to introduce new service.=20
>=20
> Every year, ISPs purchase new access switches and replaces=20
> old machines.
> With a bit additional cost, ISPs may use the GMPLS enabled switch for
> normal Ethernet switching in initial deployment.=20
>=20
> When the GMPLS function is enabled in some upgraded part of network,=20
> ISPs may provide high quality, reliable VoIP service to xDSL customers
> using RSVP-TE enabled VoIP phone.=20
> The high quality video-phone service enabled by GMPLS will be=20
> competable to legacy voice only phone service.
>=20
>=20
> There are lots of things I can argue about commercial aspects=20
> of this technique.
> However I don't think it is not appropriate to discuss this=20
> issue in this mailing list.
> All I can say is,
> yes, I believe that it may be commercially viable.
>=20
>=20
> Thanks=20
>=20
> Jaihyung
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Do you really think the benefits of extended GMPLS down to=20
> the end user could ever justify the costs involved in=20
> upgrading LAN switches and things like IP phones (simple low=20
> cost commodity items) to support GMPLS signalling/routing?=20
>=20
> Your proposal may be technically possible (though it would=20
> require new hardware and significant software upgrades), but=20
> commercially I would consider this to be a non-starter.=20
>=20
> Regards,=20
> Richard=20
>=20
> > -----Original Message-----=20
> > From: [email-masked] [mailto:[email-masked]]On=20
> > Behalf Of CHO, JAI HYUNG=20
> > Sent: 12 July 2005 01:10=20
> > To: [email-masked]=20
> > Subject: End-to-end L2-LSP=20
> >=20
> >=20
> > =20
> > Dear all,=20
> >=20
> > Greetings.=20
> >=20
> > I am a co-editor of the Ethernet-GMPLS framework document.=20
> > (draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt)=20
> >=20
> > I am writing this to explain the motivation behind the=20
> > proposal of scenario-1, and to raise the issue of=20
> > end-to-end LSP to be included in CCAMP charter.=20
> >=20
> > An important goal intended in scenario-1 is=20
> > QoS control over end-to-end packet delivery using LSP.=20
> > In other words, the purpose of scenario-1 is extending coverage=20
> > of GMPLS control including customer network and end-user device,=20
> > such as PC, VoIP phone, IP-TV, or even future 4G mobile phone.=20
> > End-user applications will have a means to request resources=20
> > to network using GMPLS signal.=20
> >=20
> > Unfortunately, this view is not included in the=20
> > framework because there was strong opinion that=20
> > L2-LSP must not span beyond provider network because=20
> > CCAMP is not chartered to work on customer=20
> > network. I am wondering if this is right argument.=20
> > Perhaps the charter can be amended to include this work.=20
> >=20
> > I believe there is little technical reason to preclude=20
> > LSP being used in customer network. It is a reasonable=20
> > assumption that private company may also use GMPLS=20
> > implemented Ethernet switch, once the L2SC work is successful.=20
> > Currently, CCAMP is the only place discussing the matter of=20
> > Ethernet and LSP. There is no other WG dealing similar issue.=20
> > If CCAMP wants to work on Ethernet,=20
> > I think the coverage of common GMPLS control must be=20
> > extended to include all area where Ethernet is deployed.=20
> > Currently, Ethernet is dominantly deployed in first-mile=20
> > network where access network as well as customer network=20
> > and user hosts are usually included. Therefore, user host must=20
> > be considered as initiation and termination point of L2-LSP.=20
> >=20
> > Another important reason to include user host in CCAMP=20
> > work scope is to achieve consistent end-to-end control of QoS.=20
> > End-to-end QoS has long been desired goal since RSVP was=20
> > first designed. This goal can be best achieved using=20
> > end-to-end GMPLS signal and L2-LSP.=20
> > Currently, RSVP (RFC2205) is available in many user hosts.=20
> > There is only a little difference between RSVP and RSVP-TE.=20
> > If the RSVP-TE signal of provider network can reach user host=20
> > across Ethernet based private network, an LSP can be established=20
> > from application to application via the provider backbone.=20
> > Service providers will be able to control application flows=20
> > in L2-LSP level as well as in aggregated LSP pipe of similar=20
> > application type. A variety of new services will be enabled using=20
> > the enhanced capability of distinguishing and controlling each=20
> > individual application flow.=20
> >=20
> > I personally believe that end-to-end L2-LSP may offer=20
> > innovative solutions for servicing IP-TV as well as fast mobility.=20
> > There have been some experimental approaches combining=20
> > MPLS and IP mobility. However such potential of the new=20
> > application can only be explored when end-user host is=20
> > included in the scope of CCAMP work area.=20
> >=20
> > Therefore, I hereby sincerely request people's attention=20
> > and support on this perspective of end-to-end LSP.=20
> > If there is enough number of people agree on this view,=20
> > the WG can request the necessary update of the charter.=20
> >=20
> > Thank you.=20
> > =20
> > Jaihyung Cho=20
> > =20
> > =20
> > =20
> > ETRI, Korea=20
> > phone :       042) 860-5514=20
> > oversea: +82-42-860-5514=20
> > fax:         +82-42-861-5550=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20

Delivery-date: Wed, 13 Jul 2005 09:18:39 +0000
Date: Wed, 13 Jul 2005 10:15:39 +0000
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

----------muscriekmblqemuwjvvd
Content-Type: text/plain; charset="UTF-8"; format="flowed"

+----------------------------------------------------+

Panda GateDefender has detected malicious content (Virus) in the following file: [MP3.cpl]
W32/Bagle.AH.worm

The file has been deleted to protect the network.
07/13/2005 09:10 +0100

www.pandasoftware.com

+----------------------------------------------------+

----------muscriekmblqemuwjvvd
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>The snake<br><br>

<br>
</body></html>

----------muscriekmblqemuwjvvd--

Delivery-date: Tue, 12 Jul 2005 11:39:07 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt
Date: Tue, 12 Jul 2005 13:37:22 +0200

i just noticed that in the below e-mail, i did not explicitly mention that
it would be appropriate in case your feedback is "not positive" to explain
the potential reasons

note: this would help us (in case) to structure a bit the discussions
during next IETF meeting

---

ccamp'ers

during last IETF meeting it was reported that "ADs request a framework doc
and include how it relates to other SDOs, max 10 pages" on GMPLS for
Ethernet.

A DT has been put in place (the "GMPLS for Ethernet" design team) to
develop a framework and the basic requirements. DT details can be found at:
<https://psg.com/lists/ccamp/ccamp.2005/msg00502.html>

the first output of the design team is available at
<http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt>

last round of discussions on this topic did generate a flury of e-mails on
the CCAMP mailing list - showing at least that specific issues needed to be
adequately addressed - this time and with the help of this document i hope
we can come to something more structured and hopefully more conclusive

thanks for your feedback !

Delivery-date: Tue, 12 Jul 2005 08:20:23 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 
Bcc: 
Subject: RE: End-to-end L2-LSP
Date: Tue, 12 Jul 2005 17:20:49 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message

Dear Richard,

Yes, I believe it is not only commercially profitable but it may also grow total 
revenue of service operators by introducing new services.

For example, think the example of IP phone you referred.
How do you think you can provide reliable VoIP service and 
safely authenticate phone users and charge fees as counted by packet usage
using simple Ethernet based xDSL network ?

There's hardly new service that providers may offer using Ethernet based 
architecture, and collect sufficient profit to investment.

A sophisticated ATM switch might do the work if it is not expensive. 
However, my intension is modifiying existing design of Ethernet hardware
with a little bit additional cost,  and provide the level of service that 
ATM switches might offer.

We have initial design of the Ethernet-MPLS hardware. I don't think
GMPLS enabled Ethernet switch will be so complex. The market price
of GMPLS enabled switch will not be so expensive than normal 
Ethernet switches.

Further, it only requires upgrade of switches in some bottleneck points of network.
Read the framework documents of L2SC. It doesn't require entire replacement
of switches to introduce new service. 

Every year, ISPs purchase new access switches and replaces old machines.
With a bit additional cost, ISPs may use the GMPLS enabled switch for
normal Ethernet switching in initial deployment. 

When the GMPLS function is enabled in some upgraded part of network, 
ISPs may provide high quality, reliable VoIP service to xDSL customers
using RSVP-TE enabled VoIP phone. 
The high quality video-phone service enabled by GMPLS will be 
competable to legacy voice only phone service.

There are lots of things I can argue about commercial aspects of this technique.
However I don't think it is not appropriate to discuss this issue in this mailing list.
All I can say is,
yes, I believe that it may be commercially viable.

Thanks 

Jaihyung

================================================

Do you really think the benefits of extended GMPLS down to the end user could ever justify the costs involved in upgrading LAN switches and things like IP phones (simple low cost commodity items) to support GMPLS signalling/routing? 

Your proposal may be technically possible (though it would require new hardware and significant software upgrades), but commercially I would consider this to be a non-starter. 

Regards, 
Richard 

> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of CHO, JAI HYUNG 
> Sent: 12 July 2005 01:10 
> To: [email-masked] 
> Subject: End-to-end L2-LSP 
> 
> 
>  
> Dear all, 
> 
> Greetings. 
> 
> I am a co-editor of the Ethernet-GMPLS framework document. 
> (draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt) 
> 
> I am writing this to explain the motivation behind the 
> proposal of scenario-1, and to raise the issue of 
> end-to-end LSP to be included in CCAMP charter. 
> 
> An important goal intended in scenario-1 is 
> QoS control over end-to-end packet delivery using LSP. 
> In other words, the purpose of scenario-1 is extending coverage 
> of GMPLS control including customer network and end-user device, 
> such as PC, VoIP phone, IP-TV, or even future 4G mobile phone. 
> End-user applications will have a means to request resources 
> to network using GMPLS signal. 
> 
> Unfortunately, this view is not included in the 
> framework because there was strong opinion that 
> L2-LSP must not span beyond provider network because 
> CCAMP is not chartered to work on customer 
> network. I am wondering if this is right argument. 
> Perhaps the charter can be amended to include this work. 
> 
> I believe there is little technical reason to preclude 
> LSP being used in customer network. It is a reasonable 
> assumption that private company may also use GMPLS 
> implemented Ethernet switch, once the L2SC work is successful. 
> Currently, CCAMP is the only place discussing the matter of 
> Ethernet and LSP. There is no other WG dealing similar issue. 
> If CCAMP wants to work on Ethernet, 
> I think the coverage of common GMPLS control must be 
> extended to include all area where Ethernet is deployed. 
> Currently, Ethernet is dominantly deployed in first-mile 
> network where access network as well as customer network 
> and user hosts are usually included. Therefore, user host must 
> be considered as initiation and termination point of L2-LSP. 
> 
> Another important reason to include user host in CCAMP 
> work scope is to achieve consistent end-to-end control of QoS. 
> End-to-end QoS has long been desired goal since RSVP was 
> first designed. This goal can be best achieved using 
> end-to-end GMPLS signal and L2-LSP. 
> Currently, RSVP (RFC2205) is available in many user hosts. 
> There is only a little difference between RSVP and RSVP-TE. 
> If the RSVP-TE signal of provider network can reach user host 
> across Ethernet based private network, an LSP can be established 
> from application to application via the provider backbone. 
> Service providers will be able to control application flows 
> in L2-LSP level as well as in aggregated LSP pipe of similar 
> application type. A variety of new services will be enabled using 
> the enhanced capability of distinguishing and controlling each 
> individual application flow. 
> 
> I personally believe that end-to-end L2-LSP may offer 
> innovative solutions for servicing IP-TV as well as fast mobility. 
> There have been some experimental approaches combining 
> MPLS and IP mobility. However such potential of the new 
> application can only be explored when end-user host is 
> included in the scope of CCAMP work area. 
> 
> Therefore, I hereby sincerely request people's attention 
> and support on this perspective of end-to-end LSP. 
> If there is enough number of people agree on this view, 
> the WG can request the necessary update of the charter. 
> 
> Thank you. 
>  
> Jaihyung Cho 
>  
>  
>  
> ETRI, Korea 
> phone :       042) 860-5514 
> oversea: +82-42-860-5514 
> fax:         +82-42-861-5550 
> 
> 
> 
> 
> 
> 
> 

Delivery-date: Tue, 12 Jul 2005 07:11:21 +0000
content-class: urn:content-classes:message
Subject: RE: End-to-end L2-LSP
Date: Tue, 12 Jul 2005 08:09:49 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Jaihyung Cho,

Do you really think the benefits of extended GMPLS down to the end user =
could ever justify the costs involved in upgrading LAN switches and =
things like IP phones (simple low cost commodity items) to support GMPLS =
signalling/routing?

Your proposal may be technically possible (though it would require new =
hardware and significant software upgrades), but commercially I would =
consider this to be a non-starter.

Regards,
Richard

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of CHO, JAI HYUNG
> Sent: 12 July 2005 01:10
> To: [email-masked]
> Subject: End-to-end L2-LSP
>=20
>=20
> =20
> Dear all,
>=20
> Greetings.
>=20
> I am a co-editor of the Ethernet-GMPLS framework document.=20
> (draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt)
>=20
> I am writing this to explain the motivation behind the=20
> proposal of scenario-1, and to raise the issue of=20
> end-to-end LSP to be included in CCAMP charter.
>=20
> An important goal intended in scenario-1 is=20
> QoS control over end-to-end packet delivery using LSP.=20
> In other words, the purpose of scenario-1 is extending coverage=20
> of GMPLS control including customer network and end-user device,=20
> such as PC, VoIP phone, IP-TV, or even future 4G mobile phone.=20
> End-user applications will have a means to request resources=20
> to network using GMPLS signal.
>=20
> Unfortunately, this view is not included in the=20
> framework because there was strong opinion that=20
> L2-LSP must not span beyond provider network because=20
> CCAMP is not chartered to work on customer=20
> network. I am wondering if this is right argument.=20
> Perhaps the charter can be amended to include this work.
>=20
> I believe there is little technical reason to preclude=20
> LSP being used in customer network. It is a reasonable=20
> assumption that private company may also use GMPLS=20
> implemented Ethernet switch, once the L2SC work is successful.=20
> Currently, CCAMP is the only place discussing the matter of=20
> Ethernet and LSP. There is no other WG dealing similar issue.=20
> If CCAMP wants to work on Ethernet,=20
> I think the coverage of common GMPLS control must be=20
> extended to include all area where Ethernet is deployed.=20
> Currently, Ethernet is dominantly deployed in first-mile=20
> network where access network as well as customer network=20
> and user hosts are usually included. Therefore, user host must=20
> be considered as initiation and termination point of L2-LSP.
>=20
> Another important reason to include user host in CCAMP=20
> work scope is to achieve consistent end-to-end control of QoS.=20
> End-to-end QoS has long been desired goal since RSVP was=20
> first designed. This goal can be best achieved using=20
> end-to-end GMPLS signal and L2-LSP.=20
> Currently, RSVP (RFC2205) is available in many user hosts.=20
> There is only a little difference between RSVP and RSVP-TE.=20
> If the RSVP-TE signal of provider network can reach user host=20
> across Ethernet based private network, an LSP can be established=20
> from application to application via the provider backbone.=20
> Service providers will be able to control application flows=20
> in L2-LSP level as well as in aggregated LSP pipe of similar=20
> application type. A variety of new services will be enabled using=20
> the enhanced capability of distinguishing and controlling each=20
> individual application flow.
>=20
> I personally believe that end-to-end L2-LSP may offer=20
> innovative solutions for servicing IP-TV as well as fast mobility.=20
> There have been some experimental approaches combining=20
> MPLS and IP mobility. However such potential of the new=20
> application can only be explored when end-user host is=20
> included in the scope of CCAMP work area.
>=20
> Therefore, I hereby sincerely request people's attention=20
> and support on this perspective of end-to-end LSP.=20
> If there is enough number of people agree on this view,=20
> the WG can request the necessary update of the charter.
>=20
> Thank you.
> =20
> Jaihyung Cho
> =20
> =20
> =20
> ETRI, Korea
> phone :       042) 860-5514
> oversea: +82-42-860-5514
> fax:         +82-42-861-5550=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20

Delivery-date: Tue, 12 Jul 2005 00:11:08 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: <[email-masked]>
Cc: 
Bcc: 
Subject: End-to-end L2-LSP
Date: Tue, 12 Jul 2005 09:09:31 +0900
Comment: GQ19@|@ZEk=E?,18?x, BcN1b<z:P<.F@, 4c4g
Content-Class: urn:content-classes:message

Dear all,

Greetings.

I am a co-editor of the Ethernet-GMPLS framework document. 
(draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt)

I am writing this to explain the motivation behind the 
proposal of scenario-1, and to raise the issue of 
end-to-end LSP to be included in CCAMP charter.

An important goal intended in scenario-1 is 
QoS control over end-to-end packet delivery using LSP. 
In other words, the purpose of scenario-1 is extending coverage 
of GMPLS control including customer network and end-user device, 
such as PC, VoIP phone, IP-TV, or even future 4G mobile phone. 
End-user applications will have a means to request resources 
to network using GMPLS signal.

Unfortunately, this view is not included in the 
framework because there was strong opinion that 
L2-LSP must not span beyond provider network because 
CCAMP is not chartered to work on customer 
network. I am wondering if this is right argument. 
Perhaps the charter can be amended to include this work.

I believe there is little technical reason to preclude 
LSP being used in customer network. It is a reasonable 
assumption that private company may also use GMPLS 
implemented Ethernet switch, once the L2SC work is successful. 
Currently, CCAMP is the only place discussing the matter of 
Ethernet and LSP. There is no other WG dealing similar issue. 
If CCAMP wants to work on Ethernet, 
I think the coverage of common GMPLS control must be 
extended to include all area where Ethernet is deployed. 
Currently, Ethernet is dominantly deployed in first-mile 
network where access network as well as customer network 
and user hosts are usually included. Therefore, user host must 
be considered as initiation and termination point of L2-LSP.

Another important reason to include user host in CCAMP 
work scope is to achieve consistent end-to-end control of QoS. 
End-to-end QoS has long been desired goal since RSVP was 
first designed. This goal can be best achieved using 
end-to-end GMPLS signal and L2-LSP. 
Currently, RSVP (RFC2205) is available in many user hosts. 
There is only a little difference between RSVP and RSVP-TE. 
If the RSVP-TE signal of provider network can reach user host 
across Ethernet based private network, an LSP can be established 
from application to application via the provider backbone. 
Service providers will be able to control application flows 
in L2-LSP level as well as in aggregated LSP pipe of similar 
application type. A variety of new services will be enabled using 
the enhanced capability of distinguishing and controlling each 
individual application flow.

I personally believe that end-to-end L2-LSP may offer 
innovative solutions for servicing IP-TV as well as fast mobility. 
There have been some experimental approaches combining 
MPLS and IP mobility. However such potential of the new 
application can only be explored when end-user host is 
included in the scope of CCAMP work area.

Therefore, I hereby sincerely request people's attention 
and support on this perspective of end-to-end LSP. 
If there is enough number of people agree on this view, 
the WG can request the necessary update of the charter.

Thank you.
 
Jaihyung Cho

ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550 

Delivery-date: Mon, 11 Jul 2005 22:36:52 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Provisional scheduling for Paris
Date: Mon, 11 Jul 2005 23:30:19 +0100

Hi,

CCAMP has been *provisionally* scheduled for Wednesday at 2pm

We cannot guarantee that this slot will be held.

Cheers,
Adrian

Delivery-date: Mon, 11 Jul 2005 21:22:37 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt
Date: Mon, 11 Jul 2005 23:21:28 +0200

ccamp'ers

during last IETF meeting it was reported that "ADs request a framework doc
and include how it relates to other SDOs, max 10 pages" on GMPLS for
Ethernet.

A DT has been put in place (the "GMPLS for Ethernet" design team) to
develop a framework and the basic requirements. DT details can be found at:
<https://psg.com/lists/ccamp/ccamp.2005/msg00502.html>

the first output of the design team is available at
<http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt>

last round of discussions on this topic did generate a flury of e-mails on
the CCAMP mailing list - showing at least that specific issues needed to be
adequately addressed - this time and with the help of this document i hope
we can come to something more structured and hopefully more conclusive

thanks for your feedback !
---

To: [email-masked]
cc:
bcc:
Subject: I-D
ACTION:draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

      Title       : A Framework for Generalized MPLS (GMPLS) Ethernet
      Author(s)   : D. Papadimitriou, J. Choi
      Filename    :
draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt
      Pages       : 16
      Date        : 2005-7-11

   Most efforts on Generalized MPLS (GMPLS) have been focused on
   environments covering Circuit oriented LSPs (Sonet/SDH, OTH, etc.)
   and IP/MPLS Packet switched networks. However, there is minimal
   documentation on GMPLS support of Layer-2 Label Switched Paths (L2
   LSPs), e.g. native Ethernet LSPs, Asynchronous Transfer Mode (ATM)
   LSPs and Frame Relay (FR) LSPs. This document provides a framework
   for GMPLS in support of L2 LSPs in several network environments, in
   particular, Ethernet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
      "get draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
      [email-masked].
In the body type:
      "FILE
/internet-drafts/draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt".

NOTE: The mail server at ietf.org can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e. documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

ftp://ftp.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

Delivery-date: Mon, 11 Jul 2005 16:44:17 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>, "Scott Bradner" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, "Hiroshi Ohta" <[email-masked]>
Subject: Response to your liaison on the SG15 OTNT Standardization Work Plan
Date: Mon, 11 Jul 2005 17:27:06 +0100

To: ITU-T Study Group 15
From: IETF CCAMP Working Group
Subject: Response to your liaison on the SG15 OTNT Standardization Work
              Plan
For: Information

The CCAMP working group would like to thank Study Group 15 for sharing
their current OTNT Standardization Work Plan. This has been made available
to the CCAMP participants.

We note that the work plan is kept updated for free download at
http://www.itu.int/itudoc/itu-t/com15/otn/index.html and thank the ITU-T
for this courtesy.

We would like to draw your attention to the following updates to your list
of RFCs and Internet-Drafts relevant to GMPLS and the ASON control plane.
We are sure that you will want to update your documentation accordingly.

Up-to-date information on CCAMP Internet-Drafts and RFCs can always be
found at http://www.ietf.org/html.charters/ccamp-charter.html with more
detail tracked at http://www.olddog.co.uk/ccamp-drafts.htm

Further drafts and RFCs will no doubt apply to the work you plan for the
MPLS transport network. You should contact the MPLS working group
for an up-to-date list.

draft-ietf-ccamp-gmpls-tc-mib-07.txt
    Definitions of Textual Conventions for Generalized Multiprotocol Label
    Switching (GMPLS) Management

draft-ietf-ccamp-gmpls-lsr-mib-08.txt
    Generalized Multiprotocol Label Switching (GMPLS) Label Switching
    Router (LSR) Management Information Base

draft-ietf-ccamp-gmpls-te-mib-09.txt
    Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering
Management Information Base

draft-ietf-ccamp-crankback-05.txt
    Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE

draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt
     Requirements for Generalized MPLS (GMPLS) Routing for Automatically
     Switched Optical Network (ASON)

draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt
     Evaluation of existing Routing Protocols against ASON routing
     requirements

draft-ietf-ccamp-gmpls-segment-recovery-02.txt
     GMPLS Based Segment Recovery

draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt
     Node ID based RSVP Hello: A Clarification Statement

draft-ietf-ccamp-loose-path-reopt-01.txt
     Reoptimization of Multiprotocol Label Switching (MPLS) Traffic
    Engineering (TE) loosely routed Label Switch Path (LSP)

draft-ietf-ccamp-transport-lmp-02.txt
      A Transport Network View of the Link Management Protocol

draft-ietf-ccamp-rsvp-restart-ext-02.txt
      Extensions to GMPLS RSVP Graceful Restart

draft-ietf-ccamp-inter-domain-framework-03.txt
      A Framework for Inter-Domain MPLS Traffic Engineering

RFC 4054
     Impairments and Other Constraints on Optical Layer Routing

draft-ietf-pce-architecture-00.txt
     Path Computation Element (PCE) Architecture

draft-ietf-mpls-lsp-hierarchy-08.txt
      LSP Hierarchy with Generalized MPLS TE

draft-ietf-mpls-bundle-06.txt
      Link Bundling in MPLS Traffic Engineering

draft-ietf-ccamp-gmpls-ason-lexicography-03.txt
      A Lexicography for the Interpretation of Generalized Multiprotocol
      Label Switching (GMPLS) Terminology within The Context of the
      ITU-T's Automatically Switched Optical Network (ASON)
      Architecture

Best regards,
Adrian Farrel and Kireeti Kompella
IETF CCAMP Working Group co-chairs

Delivery-date: Thu, 07 Jul 2005 19:51:36 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-04.txt 
Date: Thu, 07 Jul 2005 15:50:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: A Framework for Inter-Domain MPLS Traffic Engineering
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-inter-domain-framework-04.txt
	Pages		: 20
	Date		: 2005-7-7
	
This document provides a framework for establishing and controlling
   Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain
   networks.

   For the purposes of this document, a domain is considered to be any
   collection of network elements within a common sphere of address
   management or path computational responsibility. Examples of such
   domains include IGP areas and Autonomous Systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-inter-domain-framework-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-framework-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 07 Jul 2005 06:07:48 +0000
From: "Fabien Verhaeghe" <[email-masked]>
To: <[email-masked]>
Subject: LMP TestStatusSuccess local_link_Id field
Date: Thu, 7 Jul 2005 08:02:52 +0200

Hi,

A question about link verification procedure in LMP protocol.

When testing data link not yet assigned to a TE link (Link_Id set to 0 and
verifyalllink flag
clear in BeginVerify), what are we suppose to encode in the LOCAL_LINK_ID
field of
the testStatusSuccess message?

Shouldn't this field be optionnal like in the BeginVerifyAck/Nack message?

Thanks
Fabien Verhaeghe

Delivery-date: Wed, 06 Jul 2005 22:01:41 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Inter-domain Framework Last Call ended
Date: Wed, 6 Jul 2005 22:48:40 +0100

Hi,

The second last call has ended with just one comment: Igor supplied the
text he had previously promised about the danger of loops in the domain
boundary computation model.

This can be found as the last two paragraphs of section 3.3 in revision 04
of the I-D that I have just submitted.

Thanks,
Adrian