Re: LCAS and GMPLS

[Huub van Helvoort <[e-mail]>]

Hello Wataru,

You wrote:

> 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 issue.

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 ---

>>
>> 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.

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





Envelope-to: [e-mail]
Delivery-date: Sun, 31 Jul 2005 14:22:51 +0000
Message-ID: <[e-mail]>
Date: Sun, 31 Jul 2005 16:21:35 +0200
From: Huub van Helvoort <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To: ccamp <[e-mail]>
Subject: Re: LCAS and GMPLS
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello Wataru,

You wrote:

> 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 issue.

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 ---

>>
>> 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.

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



Envelope-to: [e-mail]
Delivery-date: Sun, 31 Jul 2005 11:17:31 +0000
Message-ID: <007e01c595c1$c0a47fc0$5e1cff56@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Slides please
Date: Sun, 31 Jul 2005 12:19:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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



Envelope-to: [e-mail]
Delivery-date: Sun, 31 Jul 2005 10:50:11 +0000
Message-ID: <006601c595bd$a6f4b620$5e1cff56@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>
Cc: "'Jean Philippe Vasseur'" <[e-mail]>, <[e-mail]>, <[e-mail]>
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
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Sat, 30 Jul 2005 09:32:29 +0000
From: "Adrian Farrel" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Date: Sat, 30 Jul 2005 10:29:57 +0100
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-Id: <[e-mail]>

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: <[e-mail]>
To: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
Cc: "Arthi Ayyangar" <[e-mail]>; <[e-mail]>;
<[e-mail]>
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 : [e-mail]
> > > > [mailto:[e-mail]] De la part de
> > > > [e-mail] Envoyé : vendredi 15 juillet
> > 2005 21:50 À :
> > > > [e-mail] Cc : [e-mail] 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
> > > > [e-mail] 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:
> > > > [e-mail].
> > > > 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.
> > > >
> > >
> > 
>




Envelope-to: [e-mail]
Delivery-date: Fri, 29 Jul 2005 20:43:10 +0000
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: Re: Proposed liaison to SG15 on RFC 4139
Date: Fri, 29 Jul 2005 22:42:18 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmhpIGFkcmlhbiAtIDwvRk9OVD48L1A+
PFA+Jm5ic3A7PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5pIHRoaW5rIHdv
cnRoIGNvbnNpZGVyaW5nIHRoaXMgYWN0aW9uICZuYnNwOzwvRk9OVD48L1A+PFA+PEZPTlQgRkFD
RT0iTW9ub3NwYWNlLENvdXJpZXIiPm5vdGU6IGRvIHlvdSB0aGluayB0aGlzIGxpYWlzb24gc2hv
dWxkIGFsc28gaW5jbHVkZSBhbiBpbmZvcm1hdGlvbmFsIHN0YXRlbWVudCBjb25jZXJuaW5nIHRo
ZSBzdWJzZXF1ZW50IGFjdGlvbnMgaW4gdGVybXMgb2Ygc2lnbmFsaW5nIHByb3RvY29sIHdvcmsg
PzwvRk9OVD48L1A+PFA+Jm5ic3A7PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy
Ij50aGFua3MsPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+LSBk
aW1pdHJpLjwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9Mj48Qj4mcXVvdDtBZHJpYW4gRmFycmVs
JnF1b3Q7ICZsdDtvbGRkb2dAY2xhcmEuY28udWsmZ3Q7PC9CPjwvRk9OVD48QlI+PEZPTlQgU0la
RT0yPlNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+PEZPTlQgU0la
RT0yPjA3LzI5LzIwMDUgMDg6MzI8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj5QbGVhc2UgcmVzcG9u
ZCB0byBhZHJpYW48L0ZPTlQ+PEJSPjxCUj4gPEZPTlQgU0laRT0yPlRvOjwvRk9OVD4gPEZPTlQg
U0laRT0yPmNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZP
TlQ+IDxGT05UIFNJWkU9Mj5zb2JAaGFydmFyZC5lZHUsIHppbmluQHBzZy5jb20sIGZlbm5lckBy
ZXNlYXJjaC5hdHQuY29tPC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4g
PEZPTlQgU0laRT0yPlN1YmplY3Q6PC9GT05UPiA8Rk9OVCBTSVpFPTI+UHJvcG9zZWQgbGlhaXNv
biB0byBTRzE1IG9uIFJGQyA0MTM5PC9GT05UPjxCUj4gPEJSPjxCUj48L1A+PFA+PEZPTlQgRkFD
RT0iTW9ub3NwYWNlLENvdXJpZXIiPkhpLDxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9z
cGFjZSxDb3VyaWVyIj5JIHByb3Bvc2UgdG8gc2VuZCB0aGlzIGxpYWlzb24gdG8gU3R1ZHkgR3Jv
dXAgMTUgb2YgdGhlIElUVS1ULjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxD
b3VyaWVyIj5Db21tZW50cyBwbGVhc2UuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3Nw
YWNlLENvdXJpZXIiPlRoYW5rcyw8QlI+QWRyaWFuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0i
TW9ub3NwYWNlLENvdXJpZXIiPj09PT09PT08QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25v
c3BhY2UsQ291cmllciI+VG86IElUVS1UIFN0dWR5IEdyb3VwIDE1PEJSPkZyb206IElFVEYgQ0NB
TVAgV29ya2luZyBHcm91cDxCUj5TdWJqZWN0OiBOZXcgUmVxdWVzdCBmb3IgQ29tbWVudCBQdWJs
aXNoZWQ8QlI+Rm9yOiBJbmZvcm1hdGlvbjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9z
cGFjZSxDb3VyaWVyIj5UaGUgQ0NBTVAgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURiB3aXNoZXMg
dG8gaW5mb3JtIFN0dWR5IEdyb3VwIDE1IG9mIHRoZTxCUj5JVFUtVCBvZiB0aGUgcHVibGljYXRp
b24gb2YgYSBuZXcgUmVxdWVzdCBmb3IgQ29tbWVudC48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNF
PSJNb25vc3BhY2UsQ291cmllciI+UkZDIDQxMzkgJnF1b3Q7UmVxdWlyZW1lbnRzIGZvciBHZW5l
cmFsaXplZCBNUExTIChHTVBMUykgU2lnbmFsaW5nIFVzYWdlIGFuZDxCUj5FeHRlbnNpb25zIGZv
ciBBdXRvbWF0aWNhbGx5IFN3aXRjaGVkIE9wdGljYWwgTmV0d29yayAoQVNPTikmcXVvdDsgaXMg
YXZhaWxhYmxlPEJSPmZyb20gdGhlIFJGQyBFZGl0b3IncyByZXBvc2l0b3J5IGF0PEJSPjxBIEhS
RUY9ZnRwOi8vZnRwLnJmYy1lZGl0b3Iub3JnL2luLW5vdGVzL3JmYzQxMzkudHh0PmZ0cDovL2Z0
cC5yZmMtZWRpdG9yLm9yZy9pbi1ub3Rlcy9yZmM0MTM5LnR4dDwvQT48QlI+PC9GT05UPjxCUj48
Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VGhlIEFic3RyYWN0IG9mIHRoaXMgUkZDIHJl
YWRzIGFzIGZvbGxvd3MuPEJSPjwvRk9OVD48L1A+PFVMPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxD
b3VyaWVyIj5UaGUgR2VuZXJhbGl6ZWQgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChH
TVBMUykgc3VpdGUgb2Y8QlI+cHJvdG9jb2xzIGhhcyBiZWVuIGRlZmluZWQgdG8gY29udHJvbCBk
aWZmZXJlbnQgc3dpdGNoaW5nPEJSPnRlY2hub2xvZ2llcyBhbmQgZGlmZmVyZW50IGFwcGxpY2F0
aW9ucy4gJm5ic3A7VGhlc2UgaW5jbHVkZSBzdXBwb3J0PEJSPmZvciByZXF1ZXN0aW5nIFRpbWUg
RGl2aXNpb24gTXVsdGlwbGV4aW5nIChURE0pIGNvbm5lY3Rpb25zLCBpbmNsdWRpbmc8QlI+U3lu
Y2hyb25vdXMgT3B0aWNhbCBOZXR3b3JrIChTT05FVCkvU3luY2hyb25vdXMgRGlnaXRhbCBIaWVy
YXJjaHk8QlI+KFNESCkgYW5kIE9wdGljYWwgVHJhbnNwb3J0IE5ldHdvcmtzIChPVE5zKS48L0ZP
TlQ+PEJSPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VGhpcyBkb2N1bWVudCBj
b25jZW50cmF0ZXMgb24gdGhlIHNpZ25hbGluZyBhc3BlY3RzIG9mIHRoZSBHTVBMUzxCUj5zdWl0
ZSBvZiBwcm90b2NvbHMuICZuYnNwO0l0IGlkZW50aWZpZXMgdGhlIGZlYXR1cmVzIHRvIGJlIGNv
dmVyZWQgYnkgdGhlPEJSPkdNUExTIHNpZ25hbGluZyBwcm90b2NvbCB0byBzdXBwb3J0IHRoZSBj
YXBhYmlsaXRpZXMgb2YgYW48QlI+QXV0b21hdGljYWxseSBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdv
cmsgKEFTT04pLiAmbmJzcDtUaGlzIGRvY3VtZW50IHByb3ZpZGVzPEJSPmEgcHJvYmxlbSBzdGF0
ZW1lbnQgYW5kIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGZvciB0aGUgR01QTFM8QlI+c2lnbmFs
aW5nIHByb3RvY29sIHRvIHN1cHBvcnQgdGhlIEFTT04gZnVuY3Rpb25hbGl0eS48L0ZPTlQ+PEJS
PjwvVUw+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlRoZSBDQ0FNUCBXb3JraW5n
IEdyb3VwIHdvdWxkIGxpa2UgdG8gdGhhbmsgdGhlIG1lbWJlcnMgYW5kIFF1ZXN0aW9ucyBvZjxC
Uj5TdHVkeSBHcm91cCAxNSBmb3IgdGhlIGhlbHBmdWwgaW5wdXQgYW5kIHJldmlldyBmZWVkYmFj
ayB0aGF0IHRoZXkgcHJvdmlkZWQ8QlI+d2hpbGUgdGhpcyBkb2N1bWVudCB3YXMgYmVpbmcgZGV2
ZWxvcGVkLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5SZWdh
cmRzLDxCUj5BZHJpYW4gRmFycmVsIGFuZCBLaXJlZXRpIEtvbXBlbGxhPEJSPkNDQU1QIFdvcmtp
bmcgR3JvdXAgQ28tY2hhaXJzPEJSPjwvRk9OVD48L1A+



Envelope-to: [e-mail]
Delivery-date: Fri, 29 Jul 2005 20:41:41 +0000
To: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
Cc: "Arthi Ayyangar" <[e-mail]>, <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Date: Fri, 29 Jul 2005 22:39:04 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+Jm5ic3A7PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5oaSBqLWwsIGFydGhp
PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+PEJSPiZndDsgJmd0
OyAtSW4gc2VjdGlvbiA0LjEuMiB5b3UgcGFydGlhbGx5IGRlc2NyaWJlIGJpZGlyZWN0aW9uYWwg
TFNQPEJSPiZndDsgc3RpdGNoaW5nPEJSPiZndDsgJmd0OyBwcm9jZWR1cmUuIFlvdSBtZW50aW9u
IHRoYXQgYW4gVXBzdHJlYW0gTGFiZWwgTVVTVCBOT1QgYmU8QlI+Jmd0OyBhbGxvY2F0ZWQgYnk8
QlI+Jmd0OyAmZ3Q7IHRoZSBlbmQtdG8tZW5kIExTUCBvbiB0aGUgTFNQIHNlZ21lbnQsIHdoaWNo
IGlzIE9LLiBCdXQ8QlI+Jmd0OyB0aGVuIGhvdyB0aGU8QlI+Jmd0OyAmZ3Q7IExTUC1TZWdtZW50
IEVncmVzcyB3aWxsIG5vdyB0aGF0IHRoZSBlbmQtdG8tZW5kIExTUCBpczxCUj4mZ3Q7IGJpZGly
ZWN0aW9uYWw/PEJSPiZndDsgQUEtLS0tLS0tLSZndDsgRXhjZWxsZW50IHBvaW50LjxCUj4mZ3Q7
PEJSPiZndDsgJmd0OyBXaGF0IGFib3V0IGRlZmluaW5nIGEgZmxhZyBpbiB0aGUgQXR0cmlidXRl
cyBGbGFncyBUTFYgb2YgdGhlPEJSPiZndDsgJmd0OyBMU1BfQVRUUklCVVRFIG9iamVjdCBzbyBh
cyB0byBpbmRpY2F0ZSB0aGF0IHRoZSBMU1AgaXM8QlI+Jmd0OyBiaWRpcmVjdGlvbmFsPzxCUj4m
Z3Q7IEFBLS0tLS0tJmd0OyBUaGF0IHdvdWxkIGJlIGEgY2hhbmdlIHRvIHRoZSBwcm9jZXNzaW5n
IHRoYXQgR01QTFM8QlI+Jmd0OyBub2RlcyB1c2U8QlI+Jmd0OyBBQS0tLS0tLSZndDsgdG88QlI+
Jmd0OyBkZXRlY3QgYmlkaXJlY3Rpb25hbGl0eSwgaXNuJ3QgaXQgPyBOb3JtYWxseSBub2RlcyBs
b29rIGZvcjxCUj4mZ3Q7IHRoZSBVcHN0cmVhbSBMYWJlbCBvYmplY3QgdG8gZGV0ZWN0IGJpZGly
ZWN0aW9uYWxpdHkuPEJSPiZndDs8QlI+Jmd0OyBTbyBsZXQgdXMgc2F5IHRoYXQgYW4gTFNQIGlz
IGJpZGlyZWN0aW9uYWwgaWYgYSkgYW4gVXBzdHJlYW08QlI+Jmd0OyBMYWJlbCBpcyBwcmVzZW50
IG9yIGIpIG5vIFVwc3RyZWFtIExhYmVsLCBidXQgYml0IHNldCBpbjxCUj4mZ3Q7IExTUF9BVFRS
SUJVVEUgb3IgYykgYm90aCBIb3dldmVyLCByZWxpYW5jZSBvbiBhbiBlMmU8QlI+Jmd0OyBhdHRy
aWJ1dGVzIGJpdCBzZXQgYnkgaGVhZCBlbmQsIG1lYW5zIGV4aXN0aW5nIGhlYWQgZW5kcyB3aWxs
PEJSPiZndDsgbm90IGJlIHNldHRpbmcgdGhpcyBiaXQsIHNvIHRoYXQgd2lsbCBiZSBhbiBpc3N1
ZSAod3J0IGNvbXBhdGliaWxpdHkpLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFj
ZSxDb3VyaWVyIj5KTExSOiBJIGFncmVlIHRoaXMgbWF5IHJhaXNlIHNvbWUgYmFja3dhcmQgY29t
cGF0aWJpbGl0eSBpc3N1ZXMuPEJSPlRoaXMgd291bGQgcmVxdWlyZSB0aGF0IGhlYWQtZW5kcyBi
ZSB1cGdyYWRlZC4uLjxCUj48L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy
aWVyIj5EUDogdGhlIG90aGVyIGlzc3VlIGlzIGhhdmluZyB0d28gbWV0aG9kcyBmb3IgaW5kaWNh
dGluZyB0aGUgc2FtZSB0aGluZyBpcyBhbHNvIG5vdCBhZHZpc2FibGU8L0ZPTlQ+PC9QPjxQPjxG
T05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj48QlI+Jmd0OyBDb3VsZCBiZSBuaWNlIGlmIHRo
aXMgc2lnbmFsaW5nIHdhcyBqdXN0IGJldHdlZW4gdGhlIG5vZGU8QlI+Jmd0OyBkb2luZyB0aGUg
c3RpdGNoaW5nIGFuZCB0aGUgZW5kIHBvaW50IG9mIHRoZSBMU1Agc2VnbWVudCw8QlI+Jmd0OyBz
aW5jZSB0aGlzIGlzIHRoZSBob3AgdGhhdCB0aGUgYmlkaXJlY3Rpb25hbGl0eSBpbmZvcm1hdGlv
bjxCUj4mZ3Q7IGlzIGxvc3QuIExldCBtZSB0aGluayBhYm91dCB0aGlzLjxCUj48L0ZPTlQ+PEJS
PjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5KTExSOiBZZXMsIGFuZCB3aGF0IGFib3V0
IGRlZmluaW5nIGEgbmV3IE1QTFMgbGFiZWwgdmFsdWUsIGxldCBzYXkgbGFiZWwgNCA9ICZxdW90
O05vIGxhYmVsIGFzc2lnbmVkJnF1b3Q7LCB3aXRoIGEgc2VtYW50aWMgZGlzdGluY3QgZnJvbSBs
YWJlbCAzIHNlbWFudGljICg9bGFiZWwgcG9wKS4gVGhlIFVQU1RSRUFNIGxhYmVsIG9iamVjdCB3
aXRoIHRoaXMgbmV3IGxhYmVsIHZhbHVlICZuYnNwO3dvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBl
bmQtdG8tZW5kIFBhdGggbWVzc2FnZSBvdmVyIHRoZSBMU1AtU2VnbWVudC4uLjxCUj48L0ZPTlQ+
PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5EUDogYXNzdW1pbmcgYW4gaW5m
b3JtYXRpb24gaGFzIHRvIGJlIHBhc3NlZCBmb3IgdGhlIGluZGljYXRpbmcgdGhpcyBjYXBhYmls
aXR5IGkgZG8gYWxzbyB0aGluayBhIG1ldGhvZCBsaWtlIHBhc3NpbmcgYW4gaW1wbGljaXQgaW5k
aWNhdGlvbiBpbiB0aGUgdXBzdHJlYW0gbGFiZWwgdmFsdWUgd291bGQgYmUgbW9yZSBhcHByb3By
aWF0ZWQgKG5vdGUgdGhhdCB0aGUgaW5pdGlhbCBpc3N1ZSBpcyBkdWUgdG8gdGhlIGZhY3Qgb25l
IHdvdWxkIGFsbG93IGZvciB1bmlkaXJlY3Rpb25hbCBlMmUgTFNQIG1ha2luZyB1c2Ugb2YgYmlk
aXJlY3Rpb25hbCBMU1Agc2VnbWVudHMgLSBzZWUgY29tbWVudCBmcm9tIEotTCBoZXJlIGJlbG93
IC0gYW5kIG5vdCBtYWludGFpbmluZyBhIDE6MSByZWxhdGlvbnNoaXAgZm9yIHRoZSBkaXJlY3Rp
b25hbGl0eSBiZXR3ZWVuIHRoZSBlMmUgTFNQIGFuZCB0aGUgTFNQIHNlZ21lbnQgdGhhdCBjYW4g
YmUgcmV0cmlldmVkIHdpdGggdGhlIHByb2NlZHVyZSBkZXNjcmliZWQgaW4gc2VjdGlvbiA0LjIu
NCAtIGFuZCBzbyB0aGUgZmlyc3QgcXVlc3Rpb24gaXMgaXQgd29ydGggYWxsb3dpbmcgdGhpcz8p
IDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPjxCUj4mZ3Q7ICZn
dDsgQWxzbyB0aGUgc2VsZWN0aW9uIG9mIHRoZSBMU1Agc2VnbWVudCBpbiBjYXNlIG9mIGJpZGly
ZWN0aW9uYWwgTFNQPEJSPiZndDsgJmd0OyBzaG91bGQgYmUgZGV0YWlsZWQgKGUuZy4gSWYgdGhl
IGVuZC10by1lbmQgTFNQIGlzPEJSPiZndDsgYmlkaXJlY2l0b25hbCB0aGVuPEJSPiZndDsgJmd0
OyB0aGUgTFNQLXNlZ21lbnQgTVVTVCBiZSBiaWRpcmVjdGlvbmFsLiBBbHNvIHNoYWxsIHdlIGFs
bG93IHRoYXQgdHdvPEJSPiZndDsgJmd0OyB1bmlkcmVjdGlvbmFsIGVuZC10by1lbmQgTFNQIHVz
ZSB0aGUgc2FtZSBiaWRpcmVjdGlvbmFsIExTUCBzZWdtZW50PEJSPiZndDsgJmd0OyAob25lIGlu
IGVhY2ggZGlyZWN0aW9uKT88QlI+Jmd0OyBBQS0tLS0mZ3Q7IFllcywgdGhpcyBzaG91bGQgYmUg
b2theS4gSU1PLjxCUj4mZ3Q7PEJSPiZndDsgJmd0OyAtQXQgdGhlIGVuZCBvZiBzZWN0aW9uIDQu
Mi41IHlvdSBtZW50aW9uIHRoYXQgTFNQLVNlZ21lbnQ8QlI+Jmd0OyBmYWlsdXJlIG9yPEJSPiZn
dDsgJmd0OyBtYWludGVuYW5jZSBTSE9VTEQgYmUgdHJlYXRlZCBhcyBhIGZhaWx1cmUgZXZlbnQg
Zm9yIHRoZTxCUj4mZ3Q7IGVuZC10by1lbmQgTFNQLjxCUj4mZ3Q7ICZndDsgSSBhZ3JlZSBmb3Ig
TFNQLVNlZ21lbnQgZmFpbHVyZSBidXQgbm90IGZvciBMU1AtU2VnbWVudCBtYWludGVuYW5jZS48
QlI+Jmd0OyAmZ3Q7IExTUC1TZWdtZW50IG1haW50ZW5hbmNlIHNob3VsZCBiZSB0cmVhdGVkIGFz
IFRFLWxpbms8QlI+Jmd0OyBtYWludGVuYW5jZSBmb3I8QlI+Jmd0OyAmZ3Q7IHRoZSBlbmQtdG8t
ZW5kIExTUCwgYW5kIHByb2NlZHVyZXMgZGVmaW5lZCBpbiBHTVBMUzxCUj4mZ3Q7IGdyYWNlZnVs
IFRFLWxpbms8QlI+Jmd0OyAmZ3Q7IHNodXRkb3duIGRyYWZ0IG1heSBiZSB1c2VmdWwgKFNwZWNp
ZmljIFJTVlAgZXJyb3IgY29kZSBhbmQgVEUtbGluazxCUj4mZ3Q7ICZndDsgYXR0cmlidXRlKS4u
LjxCUj4mZ3Q7IEFBLS0tJmd0OyBZZXMsIEkgYWdyZWU7IHdlIHdpbGwgbWVudGlvbiB0aGlzLiBB
Y3R1YWxseSB0aGUgZ3JhY2VmdWw8QlI+Jmd0OyBBQS0tLSZndDsgdGVhcmRvd248QlI+Jmd0OyBz
ZW50ZW5jZSBvY2N1cnMgZmV3IHBhcmFncmFwaHMgYmVmb3JlLCBidXQgbm90IGluIHRoZSByaWdo
dDxCUj4mZ3Q7IGNvbnRleHQuIFNvIHdlIHdpbGwgY2xhcmlmeSB0aGUgYWJvdmUuPEJSPjwvRk9O
VD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkRQOiBpIGFtIG5vdCBzdXJl
IHRvIHVuZGVyc3RhbmQgdGhlIGNvbW1lbnQsIHRoZSBzZW50ZW5jZSBzcGVha3MgYWJvdXQgZGVs
ZXRpb24gb2YgdGhlIExTUCBzZWdtZW50IGR1ZSB0byBmYWlsdXJlL21haW50ZW5hbmNlIHNob3Vs
ZCBiZSB0cmVhdGVkIGFzIGEgZmFpbHVyZSBldmVudCBmb3IgdGhlIGUyZSBMU1AsIHNvIGkgZG9u
J3QgdGhpbmsgdGhlIGluaXRpYWwgc2VudGVuY2Ugd2FzIG1lYW50IHRvIHRyYW5zbGF0ZWQgdGhl
IGluaXRpYWwgY29tbWVudCwgYW55d2F5IGl0IHdvdWxkIGJlIG9mIGludGVyZXN0IHRoYXQgeW91
IGRldGFpbCB0aGUgZXJyb3IgY29kZTwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNl
LENvdXJpZXIiPkRQOiBub3RlIGFsc28gdGhhdCBzZWN0aW9uIDQuMi41IGluZGljYXRlcyB0aGF0
IGZvciBzdGl0Y2hlZCBMU1BzIEdyYWNlZnVsIGRlbGV0aW9uIGNhbiBiZSB1c2VkIC0gaSBwZXJm
ZWN0bHkgYWdyZWUgLSBidXQgdGhlIHNlcXVlbmNlIHNob3VsZCBiZSBkZXRhaWxlZCBhcyBwYXJ0
IG9mIHRoaXMgc2VjdGlvbiA8L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy
aWVyIj48QlI+Jmd0OyAmZ3Q7IEhvcGUgdGhpcyBoZWxwcyw8QlI+Jmd0OyBBQS0tLSZndDsgJm5i
c3A7U3VyZSBkb2VzLjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBUaGFua3MhPEJSPiZndDs8QlI+
Jmd0OyAtYXJ0aGk8QlI+Jmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0
OyAmZ3Q7IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxCUj4mZ3Q7ICZndDsgJmd0OyBEZSA6
IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzxCUj4mZ3Q7ICZndDsgJmd0OyBbbWFpbHRvOm93bmVy
LWNjYW1wQG9wcy5pZXRmLm9yZ10gRGUgbGEgcGFydCBkZTxCUj4mZ3Q7ICZndDsgJmd0OyBJbnRl
cm5ldC1EcmFmdHNAaWV0Zi5vcmcgRW52b3kmZWFjdXRlOyA6IHZlbmRyZWRpIDE1IGp1aWxsZXQ8
QlI+Jmd0OyAyMDA1IDIxOjUwICZBZ3JhdmU7IDo8QlI+Jmd0OyAmZ3Q7ICZndDsgaS1kLWFubm91
bmNlQGlldGYub3JnIENjIDogY2NhbXBAb3BzLmlldGYub3JnIE9iamV0IDogSS1EPEJSPiZndDsg
Jmd0OyAmZ3Q7IEFDVElPTjpkcmFmdC1pZXRmLWNjYW1wLWxzcC1zdGl0Y2hpbmctMDEudHh0PEJS
PiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlz
IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lPEJSPiZndDsgSW50ZXJuZXQtRHJhZnRzPEJSPiZn
dDsgJmd0OyAmZ3Q7IGRpcmVjdG9yaWVzLjxCUj4mZ3Q7ICZndDsgJmd0OyBUaGlzIGRyYWZ0IGlz
IGEgd29yayBpdGVtIG9mIHRoZSBDb21tb24gQ29udHJvbCBhbmQgTWVhc3VyZW1lbnQ8QlI+Jmd0
OyAmZ3Q7ICZndDsgUGxhbmUgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48QlI+Jmd0OyAmZ3Q7
ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgVGl0bGU6IExhYmVsIFN3aXRjaGVkIFBhdGggU3RpdGNo
aW5nIHdpdGg8QlI+Jmd0OyAmZ3Q7ICZndDsgR2VuZXJhbGl6ZWQgTVBMUyBUcmFmZmljIEVuZ2lu
ZWVyaW5nPEJSPiZndDsgJmd0OyAmZ3Q7IEF1dGhvcihzKTogQS4gQXl5YW5nYXIsIEouIFZhc3Nl
dXI8QlI+Jmd0OyAmZ3Q7ICZndDsgRmlsZW5hbWU6IGRyYWZ0LWlldGYtY2NhbXAtbHNwLXN0aXRj
aGluZy0wMS50eHQ8QlI+Jmd0OyAmZ3Q7ICZndDsgUGFnZXM6IDE5PEJSPiZndDsgJmd0OyAmZ3Q7
IERhdGU6IDIwMDUtNy0xNTxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyBJbiBj
ZXJ0YWluIHNjZW5hcmlvcywgdGhlcmUgbWF5IGJlIGEgbmVlZCB0byBjb21iaW5lIHRvZ2V0aGVy
IHR3bzxCUj4mZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ZGlmZmVyZW50IEdlbmVyYWxpemVk
IE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZzxCUj4mZ3Q7IChHTVBMUykgTGFiZWw8QlI+
Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1N3aXRjaGVkIFBhdGhzIChMU1BzKSBzdWNoIHRo
YXQgaW4gdGhlIGRhdGEgcGxhbmUsIGE8QlI+Jmd0OyBzaW5nbGUgZW5kLXRvLTxCUj4mZ3Q7ICZn
dDsgJmd0OyAmbmJzcDsgJm5ic3A7ZW5kIChlMmUpIExTUCBpcyBhY2hpZXZlZCBhbmQgYWxsIHRy
YWZmaWMgZnJvbSBvbmUgTFNQPEJSPiZndDsgaXMgc3dpdGNoZWQ8QlI+Jmd0OyAmZ3Q7ICZndDsg
Jm5ic3A7ICZuYnNwO29udG8gdGhlIG90aGVyIExTUC4gJm5ic3A7V2Ugd2lsbCByZWZlciB0byB0
aGlzIGFzICZxdW90O0xTUDxCUj4mZ3Q7IHN0aXRjaGluZyZxdW90Oy48QlI+Jmd0OyAmZ3Q7ICZn
dDsgVGhpczxCUj4mZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ZG9jdW1lbnQgY292ZXJzIGNh
c2VzIHdoZXJlOiBhKSB0aGUgbm9kZSBwZXJmb3JtaW5nPEJSPiZndDsgdGhlIHN0aXRjaGluZzxC
Uj4mZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ZG9lcyBub3QgcmVxdWlyZSBjb25maWd1cmF0
aW9uIG9mIGV2ZXJ5IExTUCBwYWlyIHRvIGJlIHN0aXRjaGVkPEJSPiZndDsgJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDt0b2dldGhlciBiKSB0aGUgbm9kZSBwZXJmb3JtaW5nIHRoZSBzdGl0Y2hpbmcg
aXMgbm90PEJSPiZndDsgdGhlIGVncmVzcyBvZjxCUj4mZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5i
c3A7YW55IG9mIHRoZSBMU1BzIGMpIExTUCBzdGl0Y2hpbmcgbm90IG9ubHkgcmVzdWx0cyBpbjxC
Uj4mZ3Q7IGFuIGVuZC10by1lbmQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0xTUCBp
biB0aGUgZGF0YSBwbGFuZSwgYnV0IHRoZXJlIGlzIGFsc28gYTxCUj4mZ3Q7IGNvcnJlc3BvbmRp
bmcgZW5kLXRvLWVuZDxCUj4mZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7TFNQIChSU1ZQIHNl
c3Npb24pIGluIHRoZSBjb250cm9sIHBsYW5lLiAmbmJzcDtJdCBtaWdodCBiZTxCUj4mZ3Q7IHBv
c3NpYmxlIHRvPEJSPiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtjb25maWd1cmUgYSBHTVBM
UyBub2RlIHRvIHN3aXRjaCB0aGUgdHJhZmZpYyBmcm9tIGFuIExTUCBmb3I8QlI+Jmd0OyAmZ3Q7
ICZndDsgd2hpY2ggaXQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2lzIHRoZSBlZ3Jl
c3MsIHRvIGFub3RoZXIgTFNQIGZvciB3aGljaCBpdCBpcyB0aGU8QlI+Jmd0OyBpbmdyZXNzLCB3
aXRob3V0PEJSPiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtyZXF1aXJpbmcgYW55IHNpZ25h
bGluZyBvciByb3V0aW5nIGV4dGVuc2lvbnMgd2hhdHNvZXZlciw8QlI+Jmd0OyAmZ3Q7ICZndDsg
Y29tcGxldGVseTxCUj4mZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7dHJhbnNwYXJlbnQgdG8g
b3RoZXIgbm9kZXMuICZuYnNwO1RoaXMgd2lsbCBhbHNvIHJlc3VsdCBpbjxCUj4mZ3Q7IExTUCBz
dGl0Y2hpbmc8QlI+Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2luIHRoZSBkYXRhIHBsYW5l
LiAmbmJzcDtIb3dldmVyLCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGNvdmVyIHRoaXM8QlI+Jmd0
OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3NjZW5hcmlvIG9mIExTUCBzdGl0Y2hpbmcuPEJSPiZn
dDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURy
YWZ0IGlzOjxCUj4mZ3Q7ICZndDsgJmd0OyA8QSBIUkVGPWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50
ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2NhbXAtbHNwLXN0aXRjPmh0dHA6Ly93d3cuaWV0Zi5v
cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2NhbXAtbHNwLXN0aXRjPC9BPjxCUj4mZ3Q7
ICZndDsgaGluZy0wMS50eHQ8QlI+Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgVG8g
cmVtb3ZlIHlvdXJzZWxmIGZyb20gdGhlIEktRCBBbm5vdW5jZW1lbnQgbGlzdCwgc2VuZCBhPEJS
PiZndDsgbWVzc2FnZSB0bzxCUj4mZ3Q7ICZndDsgJmd0OyBpLWQtYW5ub3VuY2UtcmVxdWVzdEBp
ZXRmLm9yZyB3aXRoIHRoZSB3b3JkIHVuc3Vic2NyaWJlPEJSPiZndDsgaW4gdGhlIGJvZHk8QlI+
Jmd0OyAmZ3Q7ICZndDsgb2YgdGhlIG1lc3NhZ2UuPEJSPiZndDsgJmd0OyAmZ3Q7IFlvdSBjYW4g
YWxzbyB2aXNpdDxCUj4mZ3Q7ICZndDsgJmd0OyA8QSBIUkVGPWh0dHBzOi8vd3d3MS5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL0ktRC1hbm5vdW5jZT5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9JLUQtYW5ub3VuY2U8L0E+PEJSPiZndDsgJmd0OyAmZ3Q7IHRvIGNoYW5n
ZSB5b3VyIHN1YnNjcmlwdGlvbiBzZXR0aW5ncy48QlI+Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAm
Z3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls
YWJsZSBieSBhbm9ueW1vdXMgRlRQLjxCUj4mZ3Q7IExvZ2luIHdpdGggdGhlPEJSPiZndDsgJmd0
OyAmZ3Q7IHVzZXJuYW1lICZxdW90O2Fub255bW91cyZxdW90OyBhbmQgYSBwYXNzd29yZCBvZiB5
b3VyIGUtbWFpbCBhZGRyZXNzLiBBZnRlcjxCUj4mZ3Q7ICZndDsgJmd0OyBsb2dnaW5nIGluLCB0
eXBlICZxdW90O2NkIGludGVybmV0LWRyYWZ0cyZxdW90OyBhbmQgdGhlbjxCUj4mZ3Q7ICZndDsg
Jmd0OyAmcXVvdDtnZXQgZHJhZnQtaWV0Zi1jY2FtcC1sc3Atc3RpdGNoaW5nLTAxLnR4dCZxdW90
Oy48QlI+Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgQSBsaXN0IG9mIEludGVybmV0
LURyYWZ0cyBkaXJlY3RvcmllcyBjYW4gYmUgZm91bmQgaW48QlI+Jmd0OyAmZ3Q7ICZndDsgPEEg
SFJFRj1odHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sPmh0dHA6Ly93d3cuaWV0Zi5vcmcv
c2hhZG93Lmh0bWw8L0E+IG9yPEJSPiZndDsgJmd0OyAmZ3Q7IDxBIEhSRUY9ZnRwOi8vZnRwLmll
dGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ+ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNo
YWRvdy1zaXRlcy50eHQ8L0E+PEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7PEJS
PiZndDsgJmd0OyAmZ3Q7IEludGVybmV0LURyYWZ0cyBjYW4gYWxzbyBiZSBvYnRhaW5lZCBieSBl
LW1haWwuPEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IFNlbmQgYSBtZXNzYWdl
IHRvOjxCUj4mZ3Q7ICZndDsgJmd0OyBtYWlsc2VydkBpZXRmLm9yZy48QlI+Jmd0OyAmZ3Q7ICZn
dDsgSW4gdGhlIGJvZHkgdHlwZTo8QlI+Jmd0OyAmZ3Q7ICZndDsgJnF1b3Q7RklMRSAvaW50ZXJu
ZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2NhbXAtbHNwLXN0aXRjaGluZy0wMS50eHQmcXVvdDsuPEJS
PiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IE5PVEU6VGhlIG1haWwgc2VydmVyIGF0
IGlldGYub3JnIGNhbiByZXR1cm4gdGhlIGRvY3VtZW50IGluPEJSPiZndDsgJmd0OyAmZ3Q7IE1J
TUUtZW5jb2RlZCBmb3JtIGJ5IHVzaW5nIHRoZSAmcXVvdDttcGFjayZxdW90OyB1dGlsaXR5LiAm
bmJzcDtUbyB1c2UgdGhpczxCUj4mZ3Q7ICZndDsgJmd0OyBmZWF0dXJlLCBpbnNlcnQgdGhlIGNv
bW1hbmQgJnF1b3Q7RU5DT0RJTkcgbWltZSZxdW90OyBiZWZvcmUgdGhlICZxdW90O0ZJTEUmcXVv
dDs8QlI+Jmd0OyAmZ3Q7ICZndDsgY29tbWFuZC4gJm5ic3A7VG8gZGVjb2RlIHRoZSByZXNwb25z
ZShzKSwgeW91IHdpbGwgbmVlZCAmcXVvdDttdW5wYWNrJnF1b3Q7IG9yPEJSPiZndDsgJmd0OyAm
Z3Q7IGEgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXIuICZuYnNwO0RpZmZlcmVudCBNSU1FLWNv
bXBsaWFudCBtYWlsPEJSPiZndDsgJmd0OyAmZ3Q7IHJlYWRlcnM8QlI+Jmd0OyAmZ3Q7ICZndDsg
ZXhoaWJpdCBkaWZmZXJlbnQgYmVoYXZpb3IsIGVzcGVjaWFsbHkgd2hlbiBkZWFsaW5nIHdpdGg8
QlI+Jmd0OyAmZ3Q7ICZndDsgJnF1b3Q7bXVsdGlwYXJ0JnF1b3Q7IE1JTUUgbWVzc2FnZXMgKGku
ZS4gZG9jdW1lbnRzIHdoaWNoIGhhdmUgYmVlbiBzcGxpdDxCUj4mZ3Q7ICZndDsgJmd0OyB1cCBp
bnRvIG11bHRpcGxlIG1lc3NhZ2VzKSwgc28gY2hlY2sgeW91ciBsb2NhbCBkb2N1bWVudGF0aW9u
IG9uPEJSPiZndDsgJmd0OyAmZ3Q7IGhvdyB0byBtYW5pcHVsYXRlIHRoZXNlIG1lc3NhZ2VzLjxC
Uj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyBCZWxv
dyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVh
ZGVyPEJSPiZndDsgJmd0OyAmZ3Q7IGltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0
cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YgdGhlPEJSPiZndDsgJmd0OyAmZ3Q7IEludGVybmV0
LURyYWZ0LjxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OzwvRk9OVD48L1A+



Envelope-to: [e-mail]
Delivery-date: Fri, 29 Jul 2005 15:27:29 +0000
Message-ID: <[e-mail]>
Date: Sat, 30 Jul 2005 00:24:14 +0900
From: Kohei Shiomoto <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.7) Gecko/20050414
MIME-Version: 1.0
To: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>
CC: [e-mail], Richard Rabbat <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-01.txt
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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 : [e-mail]=20
>>[mailto:[e-mail]] De la part de=20
>>[e-mail]
>>Envoy=EF=BF=BD : mardi 21 juin 2005 21:50
>>=EF=BF=BD : [e-mail]
>>Cc : [e-mail]
>>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 [e-mail] 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:
>>	[e-mail].
>>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 [phone]    Fax [phone]





Envelope-to: [e-mail]
Delivery-date: Fri, 29 Jul 2005 09:20:51 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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
Message-ID: <[e-mail]>
Thread-Topic: ARE: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Thread-Index: AcWTmolU8tLIPi2FQB6cHsE87A63/AAgyNng
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>
Cc: "JP Vasseur" <[e-mail]>, <[e-mail]>, <[e-mail]>

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:[e-mail]]=20
> Envoy=E9 : jeudi 28 juillet 2005 19:34
> =C0 : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : JP Vasseur; [e-mail]; [e-mail]
> 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 : [e-mail]
> > > [mailto:[e-mail]] De la part de=20
> > > [e-mail] Envoy=E9 : vendredi 15 avril 2005=20
> 21:34 =C0 :=20
> > > [e-mail] Cc : [e-mail] 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
> > > [e-mail] 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:
> > > 	[e-mail].
> > > 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



Envelope-to: [e-mail]
Delivery-date: Fri, 29 Jul 2005 09:08:40 +0000
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: quoted-printable
From: JP Vasseur <[e-mail]>
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 <[e-mail]>

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 : [e-mail]
>> [mailto:[e-mail]] De la part de
>> [e-mail]
>> Envoy=E9 : vendredi 15 juillet 2005 21:50
>> =C0 : [e-mail]
>> Cc : [e-mail]
>> 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 [e-mail] 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:
>>     [e-mail].
>> 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.
>>
>



Envelope-to: [e-mail]
Delivery-date: Fri, 29 Jul 2005 09:05:51 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Date: Fri, 29 Jul 2005 11:02:17 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Thread-Index: AcWTj8tKH7/XEuqLSBuSqDAy1UCmmAAiq39A
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

Hi Arthi,

Please see inline=20

> -----Message d'origine-----
> De : Arthi Ayyangar [mailto:[e-mail]]=20
> Envoy=E9 : jeudi 28 juillet 2005 18:17
> =C0 : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [e-mail]; [e-mail]
> 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 : [e-mail]
> > > [mailto:[e-mail]] De la part de=20
> > > [e-mail] Envoy=E9 : vendredi 15 juillet=20
> 2005 21:50 =C0 :=20
> > > [e-mail] Cc : [e-mail] 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
> > > [e-mail] 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:
> > > 	[e-mail].
> > > 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



Envelope-to: [e-mail]
Delivery-date: Fri, 29 Jul 2005 07:33:39 +0000
From: "Adrian Farrel" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Proposed liaison to SG15 on RFC 4139
Date: Fri, 29 Jul 2005 08:32:54 +0100
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>

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 




Envelope-to: [e-mail]
Delivery-date: Fri, 29 Jul 2005 07:33:27 +0000
From: "Adrian Farrel" <[e-mail]>
To: [e-mail]
Reply-To: [e-mail]
Subject: New CCAMP RFC
Date: Fri, 29 Jul 2005 08:31:24 +0100
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>

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

Adrian
 ----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
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:    [e-mail],
>                     [e-mail], [e-mail],
>                     [e-mail], [e-mail]
>         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 [e-mail].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [e-mail]. 
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [e-mail] with the message body
> help: ways_to_get_rfcs.  For example: 
>
>         To: [e-mail]
>         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 [e-mail].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution. 
>
> Submissions for Requests for Comments should be sent to
> [e-mail].  Please consult RFC 2223, Instructions to RFC
> Authors, for further information. 
>
>
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
 




Envelope-to: [e-mail]
Delivery-date: Fri, 29 Jul 2005 01:20:15 +0000
Message-ID: <[e-mail]>
Date: Fri, 29 Jul 2005 10:17:44 +0900
From: "K. Miyazaki" <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-otani-ccamp-interas-gmpls-te-03.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
> 




Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 22:55:03 +0000
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: Adrian Farrel <[e-mail]>, [e-mail], [e-mail], Arthi Ayyangar <[e-mail]>
Content-Transfer-Encoding: quoted-printable
From: JP Vasseur <[e-mail]>
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 <[e-mail]>

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
>



Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 19:20:58 +0000
Date: Thu, 28 Jul 2005 12:18:49 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: Adrian Farrel <[e-mail]>
cc: "'Jean Philippe Vasseur'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Early chair review of draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE

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



Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 17:40:16 +0000
Date: Thu, 28 Jul 2005 10:39:23 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>
cc: JP Vasseur <[e-mail]>, [e-mail], [e-mail]
Subject: Re: ARE: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> > "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



Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 17:34:49 +0000
Date: Thu, 28 Jul 2005 10:33:36 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>
cc: JP Vasseur <[e-mail]>, [e-mail], [e-mail]
Subject: Re: ARE: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE

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 : [e-mail]
> > [mailto:[e-mail]] De la part de
> > [e-mail]
> > Envoy=E9 : vendredi 15 avril 2005 21:34
> > =C0 : [e-mail]
> > Cc : [e-mail]
> > 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 [e-mail] 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:
> > =[e-mail].
> > 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.
> >
>



Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 17:04:15 +0000
Date: Thu, 28 Jul 2005 10:03:18 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: Igor Bryskin <[e-mail]>
cc: [e-mail], Igor Bryskin <[e-mail]>, [e-mail]
Subject: Re: LSP stitching questions for discussion
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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" <[e-mail]>
> Sent by: [e-mail]
> 07/20/2005 13:25 AST
>
> To: "Arthi Ayyangar" <[e-mail]>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: <[e-mail]> 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: [e-mail]
> To: Arthi Ayyangar
> Cc: Igor Bryskin ; [e-mail]
> 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



Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 16:57:13 +0000
Date: Thu, 28 Jul 2005 09:55:48 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>
cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-01.txt 
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE

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 : [e-mail]
> > [mailto:[e-mail]] De la part de
> > [e-mail]
> > Envoy=E9 : mardi 19 juillet 2005 21:50
> > =C0 : [e-mail]
> > Cc : [e-mail]
> > 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 [e-mail] 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:
> > =[e-mail].
> > 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.
> >
>



Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 16:18:10 +0000
Date: Thu, 28 Jul 2005 09:16:56 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: LE ROUX Jean-Louis RD-CORE-LAN <[e-mail]>
cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE

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 : [e-mail]
> > [mailto:[e-mail]] De la part de
> > [e-mail]
> > Envoy=E9 : vendredi 15 juillet 2005 21:50
> > =C0 : [e-mail]
> > Cc : [e-mail]
> > 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 [e-mail] 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:
> > =[e-mail].
> > 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.
> >
>



Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 15:50:27 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-01.txt 
Date: Thu, 28 Jul 2005 17:48:10 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-ietf-ccamp-gmpls-addressing-01.txt 
Thread-Index: AcV2m77Ol7fv6cWXQFmcF4CWX3tWXQc7fv6g
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Richard Rabbat" <[e-mail]>
Cc: <[e-mail]>

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 : [e-mail]=20
> [mailto:[e-mail]] De la part de=20
> [e-mail]
> Envoy=E9 : mardi 21 juin 2005 21:50
> =C0 : [e-mail]
> Cc : [e-mail]
> 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 [e-mail] 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:
> 	[e-mail].
> 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



Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 13:56:02 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: ARE: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Date: Thu, 28 Jul 2005 15:53:03 +0200
Message-ID: <[e-mail]>
Thread-Topic: ARE: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Thread-Index: AcVB80eYS2kUvd3iTW2jR3Dz9+WeLRRgvNLQ
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "JP Vasseur" <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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 : [e-mail]=20
> [mailto:[e-mail]] De la part de=20
> [e-mail]
> Envoy=E9 : vendredi 15 avril 2005 21:34
> =C0 : [e-mail]
> Cc : [e-mail]
> 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 [e-mail] 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:
> 	[e-mail].
> 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



Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 11:40:22 +0000
Message-ID: <[e-mail]>
Date: Thu, 28 Jul 2005 13:38:52 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
MIME-Version: 1.0
To: "Ali Sajassi (sajassi)" <[e-mail]>
CC:  [e-mail]
Subject: Re: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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:* [e-mail]
>>>    [mailto:[e-mail]]
>>>    *Sent:* Tuesday, July 26, 2005 4:21 PM
>>>    *To:* Ali Sajassi (sajassi)
>>>    *Cc:* CHO, JAI HYUNG; Heiles Juergen; [e-mail]; 
>>
>>[e-mail]
>>
>>>    *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\)" <[e-mail]>*
>>>    Sent by: [e-mail]
>>>    07/25/2005 16:13 MST
>>>
>>>    To: "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen"
>>>    <[e-mail]>, <[e-mail]>
>>>    cc: <[e-mail]>
>>>    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" <[e-mail]>
>>>     > ?? ??: 2005-07-25 ?? 6:44:34
>>>     > ?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles
>>>     > Juergen" <[e-mail]>, "[e-mail]"
>>>     > <[e-mail]>
>>>     > ??: "[e-mail]" <[e-mail]>
>>>     > ??: 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
>>>     >
>>>     >
>>>     >
>>>     >
>>>     >
>>>     > > -----Original Message-----
>>>     > > From: CHO, JAI HYUNG [mailto:[e-mail]]
>>>     > > Sent: Saturday, July 23, 2005 6:19 AM
>>>     > > To: Heiles Juergen; [e-mail]
>>>     > > Cc: [e-mail]
>>>     > > 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" <[e-mail]>
>>>     > > ?? ??: 2005-07-22 ?? 10:23:43
>>>     > > ?? ??: "Loa Andersson" <[e-mail]>, 
>>
>>"[e-mail]"
>>
>>>     > > <[e-mail]>
>>>     > > ??: "[e-mail]" <[e-mail]>, "[e-mail]"
>>>     > > <[e-mail]>
>>>     > > ??: 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
>>>     > >
>>>     > >
>>>     > > > -----Original Message-----
>>>     > > > From: [e-mail]
>>>     > > > [mailto:[e-mail]] On Behalf Of 
>>
>>Loa Andersson
>>
>>>     > > > Sent: Friday, July 22, 2005 2:53 PM
>>>     > > > To: [e-mail]
>>>     > > > Cc: [e-mail]; [e-mail]
>>>     > > > 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
>>>     > > >
>>>     > > > [e-mail] 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
>>>     > > > >
>>>     > > > >
>>>     > > > >>-----Original Message-----
>>>     > > > >>From: [e-mail]
>>>     > > [mailto:[e-mail]]On
>>>     > > > >>Behalf Of Par Mattsson
>>>     > > > >>Sent: 22 July 2005 11:42
>>>     > > > >>To: Loa Andersson
>>>     > > > >>Cc: [e-mail]
>>>     > > > >>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:  
>>
>>[phone]
>>
>>>     > > > >>>Isafjordsgatan 22                  mobile: 
>>
>>[phone]
>>
>>>     > > > >>>Kista, Sweden                      email:
>>>     > > [e-mail]
>>>     > > > >>>                                            [e-mail]
>>>     > > > >>>
>>>     > > > >>
>>>     > > > >>
>>>     > > > >>
>>>     > > > >
>>>     > > >
>>>     > > >
>>>     > > > --
>>>     > > > Loa Andersson
>>>     > > >
>>>     > > > Principal Networking Architect
>>>     > > > Acreo AB                           phone:  +46 8 
>>
>>632 77 14
>>
>>>     > > > Isafjordsgatan 22                  mobile: +46 
>>
>>739 81 21 64
>>
>>>     > > > Kista, Sweden                      email:  
>>
>>[e-mail]
>>
>>>     > > >                                             [e-mail]
>>>     > > >
>>>     > >
>>>     > >
>>>     > >
>>>     > >
>>>     >
>>>     >
>>>     >
>>>
>>
>>--
>>Loa Andersson
>>
>>Principal Networking Architect
>>Acreo AB                           phone:  [phone]
>>Isafjordsgatan 22                  mobile: [phone]
>>Kista, Sweden                      email:  [e-mail]
>>                                            [e-mail]
>>
> 
> 


-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 10:42:06 +0000
Reply-To: <[e-mail]>
From: "Itaru Nishioka" <[e-mail]>
To: <[e-mail]>
Subject: RE: draft-otani-ccamp-interas-gmpls-te-03.txt
Date: Thu, 28 Jul 2005 19:48:48 +0900
Organization: nec
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcWN3Lk8oJ25CktfRAW0r7o2p2kiVwFgdx6w
Message-Id: <[e-mail]>

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.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Tomohiro Otani
> Sent: Thursday, July 21, 2005 7:09 PM
> To: [e-mail]
> 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




Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 09:30:13 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-01.txt 
Date: Thu, 28 Jul 2005 11:29:25 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-01.txt 
Thread-Index: AcWMm75CDqtnEDxHRpSUDBa2yZwJWwGt1cgg
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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 : [e-mail]=20
> [mailto:[e-mail]] De la part de=20
> [e-mail]
> Envoy=E9 : mardi 19 juillet 2005 21:50
> =C0 : [e-mail]
> Cc : [e-mail]
> 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 [e-mail] 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:
> 	[e-mail].
> 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



Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 09:00:49 +0000
Message-ID: <[e-mail]>
Date: Thu, 28 Jul 2005 11:00:14 +0200
From: Huub van Helvoort <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To: ccamp <[e-mail]>
Subject: Test - please ignore
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Sorry for this.




Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 08:41:58 +0000
Thread-Topic: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
thread-index: AcWTUFmFeqIRFVuSR82NxoJR0sjwhg==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: "Ali Sajassi \(sajassi\)" <[e-mail]>, "Heiles Juergen" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
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
Message-ID: <852501c59350$598ac2e0$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
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)" <[e-mail]> 
?? ??: 2005-07-27 ?? 12:00:53 
?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen" <[e-mail]>, "[e-mail]" <[e-mail]> 
??: "[e-mail]" <[e-mail]> 
??: 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)" <[e-mail]> 
> ?? ??: 2005-07-26 ?? 8:13:56 
> ?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles 
> Juergen" <[e-mail]>, "[e-mail]" 
> <[e-mail]> 
> ??: "[e-mail]" <[e-mail]> 
> ??: 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" <[e-mail]> 
> > ?? ??: 2005-07-25 ?? 6:44:34 
> > ?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles 
> > Juergen" <[e-mail]>, "[e-mail]" 
> > <[e-mail]> 
> > ??: "[e-mail]" <[e-mail]> 
> > ??: 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 
> >  
> > 
> > 
> > 
> > 
> > > -----Original Message----- 
> > > From: CHO, JAI HYUNG [mailto:[e-mail]] 
> > > Sent: Saturday, July 23, 2005 6:19 AM 
> > > To: Heiles Juergen; [e-mail] 
> > > Cc: [e-mail] 
> > > 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" <[e-mail]> 
> > > ?? ??: 2005-07-22 ?? 10:23:43 
> > > ?? ??: "Loa Andersson" <[e-mail]>, "[e-mail]" 
> > > <[e-mail]> 
> > > ??: "[e-mail]" <[e-mail]>, "[e-mail]" 
> > > <[e-mail]> 
> > > ??: 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 
> > > 
> > > 
> > > > -----Original Message----- 
> > > > From: [e-mail] 
> > > > [mailto:[e-mail]] On Behalf Of Loa Andersson 
> > > > Sent: Friday, July 22, 2005 2:53 PM 
> > > > To: [e-mail] 
> > > > Cc: [e-mail]; [e-mail] 
> > > > 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 
> > > > 
> > > > [e-mail] 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 
> > > > > 
> > > > > 
> > > > >>-----Original Message----- 
> > > > >>From: [e-mail] 
> > > [mailto:[e-mail]]On 
> > > > >>Behalf Of Par Mattsson 
> > > > >>Sent: 22 July 2005 11:42 
> > > > >>To: Loa Andersson 
> > > > >>Cc: [e-mail] 
> > > > >>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:  [phone] 
> > > > >>>Isafjordsgatan 22                  mobile: [phone] 
> > > > >>>Kista, Sweden                      email:  
> > > [e-mail] 
> > > > >>>                                            [e-mail] 
> > > > >>> 
> > > > >> 
> > > > >> 
> > > > >> 
> > > > > 
> > > > 
> > > > 
> > > > -- 
> > > > Loa Andersson 
> > > > 
> > > > Principal Networking Architect 
> > > > Acreo AB                           phone:  [phone] 
> > > > Isafjordsgatan 22                  mobile: [phone] 
> > > > Kista, Sweden                      email:  
> [e-mail] 
> > > >                                             [e-mail] 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> 
> 






Envelope-to: [e-mail]
Delivery-date: Thu, 28 Jul 2005 08:02:32 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Date: Thu, 28 Jul 2005 10:00:25 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Thread-Index: AcWJd4tCECNrgGhpTM+eZPnDSlXsgAJz1TFQ
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, <[e-mail]>

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 : [e-mail]=20
> [mailto:[e-mail]] De la part de=20
> [e-mail]
> Envoy=E9 : vendredi 15 juillet 2005 21:50
> =C0 : [e-mail]
> Cc : [e-mail]
> 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 [e-mail] 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:
> 	[e-mail].
> 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



Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 22:39:41 +0000
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RFC 4139 on Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
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:    [e-mail],
                    [e-mail], [e-mail],
                    [e-mail], [e-mail]
        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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

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

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--OtherAccess--
--NextPart--



Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 20:56:43 +0000
Message-ID: <00f001c592ed$e72f0510$0601a8c0@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Incoming correspondence from the OIF
Date: Wed, 27 Jul 2005 21:57:45 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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: [phone] main / +1.510.608.5916 direct
Fax: [phone]
Email: [e-mail]
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




Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 20:37:45 +0000
Message-ID: <00ca01c592eb$409abde0$0601a8c0@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Lam, Hing-Kam \(Kam\)" <[e-mail]>, "Malcolm Betts" <[e-mail]>, "Stephen Trowbridge" <[e-mail]>, <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: CCAMP Response to your liaison on GMPLS/ASON Lexicography
Date: Wed, 27 Jul 2005 21:39:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 20:02:48 +0000
Message-ID: <009901c592e6$45005430$0601a8c0@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>
Cc: "ccamp" <[e-mail]>
Subject: Re: VCn-xV LSPs terminology
Date: Wed, 27 Jul 2005 20:51:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

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

Thanks,
Adrian
----- Original Message ----- 
From: "Ong, Lyndon" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>; "Wataru Imajuku
<imajuku.wataru" <[e-mail]>
Cc: "Dieter Beller <D.Beller" <[e-mail]>; "ccamp"
<[e-mail]>
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: [e-mail] [mailto:[e-mail]] 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 <[e-mail]> on 27/07/2005 10.00.02

To:    Dieter Beller <[e-mail]>, Diego Caviglia
       <[e-mail]>
cc:    [e-mail]

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:   [phone]
>                       Fax:     [phone]
>
>                       E-mail:  [e-mail]
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone]














Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 17:52:58 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Date: Wed, 27 Jul 2005 10:51:38 -0700
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Thread-Index: AcWSmNMqdEdyNji/QsiAHoAalcOz4wAOQUog
From: "Ali Sajassi \(sajassi\)" <[e-mail]>
To: "Loa Andersson" <[e-mail]>
Cc: <[e-mail]>, "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen" <[e-mail]>, <[e-mail]>, <[e-mail]>

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:* [e-mail]
> >     [mailto:[e-mail]]
> >     *Sent:* Tuesday, July 26, 2005 4:21 PM
> >     *To:* Ali Sajassi (sajassi)
> >     *Cc:* CHO, JAI HYUNG; Heiles Juergen; [e-mail];=20
> [e-mail]
> >     *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\)" <[e-mail]>*
> >     Sent by: [e-mail]
> >     07/25/2005 16:13 MST
> >=20
> >     To: "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen"
> >     <[e-mail]>, <[e-mail]>
> >     cc: <[e-mail]>
> >     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" <[e-mail]>
> >      > ?? ??: 2005-07-25 ?? 6:44:34
> >      > ?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles
> >      > Juergen" <[e-mail]>, "[e-mail]"
> >      > <[e-mail]>
> >      > ??: "[e-mail]" <[e-mail]>
> >      > ??: 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
> >      >
> >      >
> >      >
> >      >
> >      >
> >      > > -----Original Message-----
> >      > > From: CHO, JAI HYUNG [mailto:[e-mail]]
> >      > > Sent: Saturday, July 23, 2005 6:19 AM
> >      > > To: Heiles Juergen; [e-mail]
> >      > > Cc: [e-mail]
> >      > > 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" <[e-mail]>
> >      > > ?? ??: 2005-07-22 ?? 10:23:43
> >      > > ?? ??: "Loa Andersson" <[e-mail]>,=20
> "[e-mail]"
> >      > > <[e-mail]>
> >      > > ??: "[e-mail]" <[e-mail]>, "[e-mail]"
> >      > > <[e-mail]>
> >      > > ??: 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
> >      > >
> >      > >
> >      > > > -----Original Message-----
> >      > > > From: [e-mail]
> >      > > > [mailto:[e-mail]] On Behalf Of=20
> Loa Andersson
> >      > > > Sent: Friday, July 22, 2005 2:53 PM
> >      > > > To: [e-mail]
> >      > > > Cc: [e-mail]; [e-mail]
> >      > > > 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
> >      > > >
> >      > > > [e-mail] 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
> >      > > > >
> >      > > > >
> >      > > > >>-----Original Message-----
> >      > > > >>From: [e-mail]
> >      > > [mailto:[e-mail]]On
> >      > > > >>Behalf Of Par Mattsson
> >      > > > >>Sent: 22 July 2005 11:42
> >      > > > >>To: Loa Andersson
> >      > > > >>Cc: [e-mail]
> >      > > > >>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
> [phone]
> >      > > > >>>Isafjordsgatan 22                  mobile:=20
> [phone]
> >      > > > >>>Kista, Sweden                      email:
> >      > > [e-mail]
> >      > > > >>>                                            [e-mail]
> >      > > > >>>
> >      > > > >>
> >      > > > >>
> >      > > > >>
> >      > > > >
> >      > > >
> >      > > >
> >      > > > --
> >      > > > 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
> [e-mail]
> >      > > >                                             [e-mail]
> >      > > >
> >      > >
> >      > >
> >      > >
> >      > >
> >      >
> >      >
> >      >
> >=20
>=20
>=20
> --
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB                           phone:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                             [e-mail]
>=20



Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 15:42:30 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: VCn-xV LSPs terminology
Date: Wed, 27 Jul 2005 11:41:14 -0400
Message-ID: <[e-mail]>
Thread-Topic: VCn-xV LSPs terminology
Thread-Index: AcWShORY0rNJvxaSS92zwFwRUIfh1wAPG+Eg
From: "Ong, Lyndon" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>, "Wataru Imajuku <imajuku.wataru" <[e-mail]>
Cc: "Dieter Beller <D.Beller" <[e-mail]>, "ccamp" <[e-mail]>

Hi Folks,

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

Cheers,

Lyndon=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 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 <[e-mail]> on 27/07/2005 10.00.02

To:    Dieter Beller <[e-mail]>, Diego Caviglia
       <[e-mail]>
cc:    [e-mail]

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:   [phone]
>                       Fax:     [phone]
>
>                       E-mail:  [e-mail]
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone]











Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 14:01:46 +0000
Message-Id: <[e-mail]>
Date: Wed, 27 Jul 2005 23:01:13 +0900
To: [e-mail]
From: Wataru Imajuku <[e-mail]>
Subject: Re: LCAS and GMPLS
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

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 <[e-mail]>
>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" <[e-mail]>
>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 --------
>Subject: Re: LCAS and GMPLS
>Date: Wed, 27 Jul 2005 13:49:19 +0200
>From: Huub van Helvoort <[e-mail]>
>To: [e-mail]
>CC: Trevor Wilson <[e-mail]>,  Wataru Imajuku 
><[e-mail]>,  [e-mail]
>References: <[e-mail]>
>
>Hello again,
>
>I agree with what Trevor wrote:
>
>>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.
>
>and:
>
>>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.
>
>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.

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone] 




Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 13:18:44 +0000
Message-Id: <[e-mail]>
Date: Wed, 27 Jul 2005 22:17:21 +0900
To: Huub van Helvoort <[e-mail]>, Trevor Wilson <[e-mail]>
From: Wataru Imajuku <[e-mail]>
Subject: Re: VCn-xV LSPs terminology
Cc: ccamp <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

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...

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone] 




Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 11:42:28 +0000
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail], [e-mail]
Subject: AW: LCAS and GMPLS
Date: Wed, 27 Jul 2005 13:41:41 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Trevor,

you're right! Thanks for the clarification,

Michael




-----Urspr=FCngliche Nachricht-----
Von: Trevor Wilson [mailto:[e-mail]]=20
Gesendet: Mittwoch, 27. Juli 2005 13:31
An: Wataru Imajuku; Dueser, Michael; [e-mail]
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: [phone]
       ESN 751 3701
>This is the Way. This is Nortel.
>


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


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=20
descriptor
  includes both transit capability and termination capability of LSPs.

  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.

  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=20
>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=20
>during the IETF next week.
>
>Michael Dueser

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone]=20





Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 11:31:35 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: LCAS and GMPLS
Date: Wed, 27 Jul 2005 12:30:45 +0100
Message-ID: <[e-mail]>
Thread-Topic: LCAS and GMPLS
Thread-Index: AcWSlot9u10xs/HcRcma9seXRr/9NQAArRng
From: "Trevor Wilson" <[e-mail]>
To: "Wataru Imajuku" <[e-mail]>, <[e-mail]>, <[e-mail]>

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: [phone]
       ESN 751 3701
>This is the Way. This is Nortel.=20
>


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


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=20
descriptor
  includes both transit capability and termination capability of LSPs.

  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.

  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=20
>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=20
>during the IETF next week.
>
>Michael Dueser

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone]=20






Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 10:50:56 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: VCn-xV LSPs terminology
Date: Wed, 27 Jul 2005 11:50:04 +0100
Message-ID: <[e-mail]>
Thread-Topic: VCn-xV LSPs terminology
Thread-Index: AcWSlrke3R0gMyHfSzW45vcOAYICPQAAJMiw
From: "Trevor Wilson" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>, "Wataru Imajuku <imajuku.wataru" <[e-mail]>, "Alan Bailey \(Alan Bailey\)" <IMCEAEX-_O=NORTEL_OU=EuropeM01_cn=Recipients_cn=Exchange_cn=[e-mail]>
Cc: "Dieter Beller <D.Beller" <[e-mail]>, "ccamp" <[e-mail]>, "Ludovico Prattico" <[e-mail]>, "Pete Anslow" <[e-mail]>, "Malcolm Betts" <[e-mail]>, "Graham Copley" <[e-mail]>, "Astrid Lozano" <[e-mail]>, "David Martin" <[e-mail]>, "Michael Mayer" <[e-mail]>

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: [phone]
       ESN 751 3701
>This is the Way. This is Nortel.=20
>


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 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 <[e-mail]> on 27/07/2005 10.00.02

To:    Dieter Beller <[e-mail]>, Diego Caviglia
       <[e-mail]>
cc:    [e-mail]

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:   [phone]
>                       Fax:     [phone]
>
>                       E-mail:  [e-mail]
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone]












Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 10:49:38 +0000
Message-ID: <[e-mail]>
Date: Wed, 27 Jul 2005 12:44:51 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
MIME-Version: 1.0
To: "Ali Sajassi (sajassi)" <[e-mail]>
CC: [e-mail], "CHO, JAI HYUNG" <[e-mail]>, Heiles Juergen <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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:* [e-mail]
>     [mailto:[e-mail]]
>     *Sent:* Tuesday, July 26, 2005 4:21 PM
>     *To:* Ali Sajassi (sajassi)
>     *Cc:* CHO, JAI HYUNG; Heiles Juergen; [e-mail]; [e-mail]
>     *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\)" <[e-mail]>*
>     Sent by: [e-mail]
>     07/25/2005 16:13 MST
> 
>     To: "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen"
>     <[e-mail]>, <[e-mail]>
>     cc: <[e-mail]>
>     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" <[e-mail]>
>      > ?? ??: 2005-07-25 ?? 6:44:34
>      > ?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles
>      > Juergen" <[e-mail]>, "[e-mail]"
>      > <[e-mail]>
>      > ??: "[e-mail]" <[e-mail]>
>      > ??: 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
>      >
>      >
>      >
>      >
>      >
>      > > -----Original Message-----
>      > > From: CHO, JAI HYUNG [mailto:[e-mail]]
>      > > Sent: Saturday, July 23, 2005 6:19 AM
>      > > To: Heiles Juergen; [e-mail]
>      > > Cc: [e-mail]
>      > > 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" <[e-mail]>
>      > > ?? ??: 2005-07-22 ?? 10:23:43
>      > > ?? ??: "Loa Andersson" <[e-mail]>, "[e-mail]"
>      > > <[e-mail]>
>      > > ??: "[e-mail]" <[e-mail]>, "[e-mail]"
>      > > <[e-mail]>
>      > > ??: 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
>      > >
>      > >
>      > > > -----Original Message-----
>      > > > From: [e-mail]
>      > > > [mailto:[e-mail]] On Behalf Of Loa Andersson
>      > > > Sent: Friday, July 22, 2005 2:53 PM
>      > > > To: [e-mail]
>      > > > Cc: [e-mail]; [e-mail]
>      > > > 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
>      > > >
>      > > > [e-mail] 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
>      > > > >
>      > > > >
>      > > > >>-----Original Message-----
>      > > > >>From: [e-mail]
>      > > [mailto:[e-mail]]On
>      > > > >>Behalf Of Par Mattsson
>      > > > >>Sent: 22 July 2005 11:42
>      > > > >>To: Loa Andersson
>      > > > >>Cc: [e-mail]
>      > > > >>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:  [phone]
>      > > > >>>Isafjordsgatan 22                  mobile: [phone]
>      > > > >>>Kista, Sweden                      email:
>      > > [e-mail]
>      > > > >>>                                            [e-mail]
>      > > > >>>
>      > > > >>
>      > > > >>
>      > > > >>
>      > > > >
>      > > >
>      > > >
>      > > > --
>      > > > Loa Andersson
>      > > >
>      > > > Principal Networking Architect
>      > > > Acreo AB                           phone:  [phone]
>      > > > Isafjordsgatan 22                  mobile: [phone]
>      > > > Kista, Sweden                      email:  [e-mail]
>      > > >                                             [e-mail]
>      > > >
>      > >
>      > >
>      > >
>      > >
>      >
>      >
>      >
> 


-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 08:25:23 +0000
Sensitivity: 
Subject: Re: VCn-xV LSPs terminology
To: "Wataru Imajuku <imajuku.wataru" <[e-mail]>
Cc: "Dieter Beller <D.Beller" <[e-mail]>, "ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 27 Jul 2005 10:24:45 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

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

Regards

Diego



Wataru Imajuku <[e-mail]> on 27/07/2005 10.00.02

To:    Dieter Beller <[e-mail]>, Diego Caviglia
       <[e-mail]>
cc:    [e-mail]

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:   [phone]
>                       Fax:     [phone]
>
>                       E-mail:  [e-mail]
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone]










Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 08:00:30 +0000
Message-Id: <[e-mail]>
Date: Wed, 27 Jul 2005 17:00:02 +0900
To: Dieter Beller <[e-mail]>, Diego Caviglia <[e-mail]>
From: Wataru Imajuku <[e-mail]>
Subject: Re: VCn-xV LSPs terminology
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

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:   [phone]
>                       Fax:     [phone]
>
>                       E-mail:  [e-mail]
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone] 




Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 07:41:37 +0000
Message-ID: <[e-mail]>
Date: Wed, 27 Jul 2005 09:40:24 +0200
From: Dieter Beller <[e-mail]>
Organization: Alcatel SEL AG, OND Germany
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Diego Caviglia <[e-mail]>
CC: [e-mail]
Subject: Re: VCn-xV LSPs terminology
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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:   [phone]
                       Fax:     [phone]

                       E-mail:  [e-mail]

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




Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 06:57:50 +0000
Sensitivity: 
Subject: VCn-xV LSPs terminology
To: [e-mail]
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 27 Jul 2005 08:57:02 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

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





Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 06:26:21 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59273.E41176C9"
Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Date: Tue, 26 Jul 2005 23:24:47 -0700
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Thread-Index: AcWSOK/zbxRzx3LXQQm+Mbn3ehy40AAOI+2w
From: "Ali Sajassi \(sajassi\)" <[e-mail]>
To: <[e-mail]>
Cc: "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen" <[e-mail]>, <[e-mail]>, <[e-mail]>

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: [e-mail]
[mailto:[e-mail]]=20
	Sent: Tuesday, July 26, 2005 4:21 PM
	To: Ali Sajassi (sajassi)
	Cc: CHO, JAI HYUNG; Heiles Juergen; [e-mail];
[e-mail]
	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\)" <[e-mail]>
	Sent by: [e-mail]
	07/25/2005 16:13 MST
=09
	To: "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen"
<[e-mail]>, <[e-mail]>
	cc: <[e-mail]>
	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" <[e-mail]>
	> ?? ??: 2005-07-25 ?? 6:44:34
	> ?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles
	> Juergen" <[e-mail]>, "[e-mail]"
	> <[e-mail]>
	> ??: "[e-mail]" <[e-mail]>
	> ??: 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
	>
	>
	>
	>
	>
	> > -----Original Message-----
	> > From: CHO, JAI HYUNG [mailto:[e-mail]]
	> > Sent: Saturday, July 23, 2005 6:19 AM
	> > To: Heiles Juergen; [e-mail]
	> > Cc: [e-mail]
	> > 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" <[e-mail]>
	> > ?? ??: 2005-07-22 ?? 10:23:43
	> > ?? ??: "Loa Andersson" <[e-mail]>, "[e-mail]"
	> > <[e-mail]>
	> > ??: "[e-mail]" <[e-mail]>, "[e-mail]"
	> > <[e-mail]>
	> > ??: 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
	> >
	> >
	> > > -----Original Message-----
	> > > From: [e-mail]
	> > > [mailto:[e-mail]] On Behalf Of Loa
Andersson
	> > > Sent: Friday, July 22, 2005 2:53 PM
	> > > To: [e-mail]
	> > > Cc: [e-mail]; [e-mail]
	> > > 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
	> > >
	> > > [e-mail] 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
	> > > >
	> > > >
	> > > >>-----Original Message-----
	> > > >>From: [e-mail]
	> > [mailto:[e-mail]]On
	> > > >>Behalf Of Par Mattsson
	> > > >>Sent: 22 July 2005 11:42
	> > > >>To: Loa Andersson
	> > > >>Cc: [e-mail]
	> > > >>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:  [phone]
14
	> > > >>>Isafjordsgatan 22                  mobile: [phone]
21 64
	> > > >>>Kista, Sweden                      email:
	> > [e-mail]
	> > > >>>                                            [e-mail]
	> > > >>>
	> > > >>
	> > > >>
	> > > >>
	> > > >
	> > >
	> > >
	> > > --
	> > > Loa Andersson
	> > >
	> > > Principal Networking Architect
	> > > Acreo AB                           phone:  [phone]
	> > > Isafjordsgatan 22                  mobile: [phone]
64
	> > > Kista, Sweden                      email:
[e-mail]
	> > >                                             [e-mail]
	> > >
	> >
	> >
	> >
	> >
	>
	>
	>


------_=_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> =
[e-mail]=20
  [mailto:[e-mail]] <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; [e-mail]; [e-mail]<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;[e-mail]&gt;</B></FONT><BR><FONT =
size=3D2>Sent=20
  by: [e-mail]</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;[e-mail]&gt;, "Heiles Juergen"=20
  &lt;[e-mail]&gt;, =
&lt;[e-mail]&gt;</FONT><BR><FONT=20
  size=3D2>cc:</FONT> <FONT =
size=3D2>&lt;[e-mail]&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;[e-mail]&gt;<BR>&gt; ?? ??: =
2005-07-25=20
  ?? 6:44:34<BR>&gt; ?? ??: "CHO, JAI HYUNG" =
&lt;[e-mail]&gt;,=20
  "Heiles<BR>&gt; Juergen" &lt;[e-mail]&gt;,=20
  "[e-mail]"<BR>&gt; &lt;[e-mail]&gt;<BR>&gt; ??: =
"[e-mail]"=20
  &lt;[e-mail]&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:[e-mail]]<BR>&gt; &gt; Sent: Saturday, July 23, =
2005 6:19=20
  AM<BR>&gt; &gt; To: Heiles Juergen; [e-mail]<BR>&gt; &gt; Cc:=20
  [e-mail]<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;[e-mail]&gt;<BR>&gt; &gt; ?? ??: 2005-07-22 ??=20
  10:23:43<BR>&gt; &gt; ?? ??: "Loa Andersson" &lt;[e-mail]&gt;,=20
  "[e-mail]"<BR>&gt; &gt; =
&lt;[e-mail]&gt;<BR>&gt;=20
  &gt; ??: "[e-mail]" &lt;[e-mail]&gt;, =
"[e-mail]"<BR>&gt;=20
  &gt; &lt;[e-mail]&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: [e-mail]<BR>&gt; =
&gt;=20
  &gt; [mailto:[e-mail]] On Behalf Of Loa =
Andersson<BR>&gt; &gt;=20
  &gt; Sent: Friday, July 22, 2005 2:53 PM<BR>&gt; &gt; &gt; To:=20
  [e-mail]<BR>&gt; &gt; &gt; Cc: [e-mail];=20
  [e-mail]<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; [e-mail] 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: [e-mail]<BR>&gt; &gt;=20
  [mailto:[e-mail]]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
  [e-mail]<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;[phone]<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
  [e-mail]<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;[e-mail]<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: [phone]<BR>&gt; &gt; &gt; =
Kista,=20
  Sweden &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
  &nbsp;email: &nbsp;[e-mail]<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
  [e-mail]<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--



Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 04:29:23 +0000
Message-Id: <[e-mail]>
Date: Wed, 27 Jul 2005 13:28:20 +0900
To: [e-mail], [e-mail]
From: Wataru Imajuku <[e-mail]>
Subject: Re: LCAS and GMPLS
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

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 [phone]
FAX [phone] 




Envelope-to: [e-mail]
Delivery-date: Wed, 27 Jul 2005 03:02:48 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Date: Tue, 26 Jul 2005 20:00:53 -0700
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Thread-Index: AcWRp4QlwPC80+CYQx66A8lU64uuxQApt/vg
From: "Ali Sajassi \(sajassi\)" <[e-mail]>
To: "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

=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)" <[e-mail]>=20
> ?? ??: 2005-07-26 ?? 8:13:56=20
> ?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles=20
> Juergen" <[e-mail]>, "[e-mail]"=20
> <[e-mail]>=20
> ??: "[e-mail]" <[e-mail]>=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" <[e-mail]>=20
> > ?? ??: 2005-07-25 ?? 6:44:34=20
> > ?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles=20
> > Juergen" <[e-mail]>, "[e-mail]"=20
> > <[e-mail]>=20
> > ??: "[e-mail]" <[e-mail]>=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:[e-mail]]=20
> > > Sent: Saturday, July 23, 2005 6:19 AM=20
> > > To: Heiles Juergen; [e-mail]=20
> > > Cc: [e-mail]=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" <[e-mail]>=20
> > > ?? ??: 2005-07-22 ?? 10:23:43=20
> > > ?? ??: "Loa Andersson" <[e-mail]>, "[e-mail]"=20
> > > <[e-mail]>=20
> > > ??: "[e-mail]" <[e-mail]>, "[e-mail]"=20
> > > <[e-mail]>=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: [e-mail]=20
> > > > [mailto:[e-mail]] On Behalf Of Loa Andersson=20
> > > > Sent: Friday, July 22, 2005 2:53 PM=20
> > > > To: [e-mail]=20
> > > > Cc: [e-mail]; [e-mail]=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
> > > > [e-mail] 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: [e-mail]=20
> > > [mailto:[e-mail]]On=20
> > > > >>Behalf Of Par Mattsson=20
> > > > >>Sent: 22 July 2005 11:42=20
> > > > >>To: Loa Andersson=20
> > > > >>Cc: [e-mail]=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:  [phone]=20
> > > > >>>Isafjordsgatan 22                  mobile: [phone]=20
> > > > >>>Kista, Sweden                      email: =20
> > > [e-mail]=20
> > > > >>>                                            [e-mail]=20
> > > > >>>=20
> > > > >>=20
> > > > >>=20
> > > > >>=20
> > > > >=20
> > > >=20
> > > >=20
> > > > --=20
> > > > Loa Andersson=20
> > > >=20
> > > > Principal Networking Architect=20
> > > > Acreo AB                           phone:  [phone]=20
> > > > Isafjordsgatan 22                  mobile: [phone]=20
> > > > Kista, Sweden                      email: =20
> [e-mail]=20
> > > >                                             [e-mail]=20
> > > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> >=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Tue, 26 Jul 2005 23:22:05 +0000
To: "Ali Sajassi \(sajassi\)" <[e-mail]>
Cc: "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen" <[e-mail]>, <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Date: Wed, 27 Jul 2005 01:20:45 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmFsaTwvRk9OVD48L1A+PFA+PEZPTlQg
RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnRvIGJlIGNsZWFyIGhlcmUgeW91IGFyZSBoYW5naW5n
IG9uIHVzaW5nIHRoZSB0ZXJtICZxdW90O2V4aXN0aW5nIEV0aGVybmV0IHN3aXRjaGVzJnF1b3Q7
IHdoaWxlIHRoZSBkb2N1bWVudCB0aGF0IGhhcyBiZWVuIGF0IHRoZSBzb3VyY2Ugb2YgdGhlIGRp
c2N1c3Npb24gZG9lcyBub3Qgc3RhdGUgJnF1b3Q7R01QTFMgbXVzdCBiZSBkZXBsb3lhYmxlIG9u
IGV4aXN0aW5nIEV0aGVybmV0IHN3aXRjaGVzJnF1b3Q7IHRoaXMgbWF5IGJlIHRoZSBjYXNlIGJ1
dCB0aGVyZSBhcmUgbGltaXRhdGlvbnMgKGFuZCB0aGVyZSBhcmUgcGVyZmVjdGx5IHdlbGwgdW5k
ZXJzdG9vZCwgZG9uJ3Qgd29ycnkpIGJlc2lkZSB0aGlzIHlvdSBzaG91bGQgYWxzbyB0ZWxsIHVz
IHdoYXQgZG8geW91IGV4YWN0bHkgbWVhbiB3aXRoIHRoZSB0ZXJtICZxdW90O2V4aXN0aW5nJnF1
b3Q7IC0gYnV0IHRoaXMgaXMgYSBzaWRlIGlzc3VlIC08L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9
Ik1vbm9zcGFjZSxDb3VyaWVyIj50aGlzIHNhaWQsIHRoaXMgZG9lcyBOT1QgbWVhbiB0aGF0IGEg
R01QTFMgRXRoZXJuZXQgc3dpdGNoIChlaXRoZXIgZXhpc3Rpbmcgb3IgZXZlbiAmcXVvdDtleHRl
bmRlZCZxdW90Oykgd291bGQgbmVlZCB0byBzdXBwb3J0IGEgbmV3IEV0aGVybmV0IDgwMi4zIGZy
YW1lIGZvcndhcmRpbmcgcGFyYWRpZ20sIHRoZSBkaWZmZXJlbmNlIGlzIHN1YnRsZSBidXQgaGFz
IHRvIGJlIHVuZGVybGluZWQ8L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy
aWVyIj5ub3RlOiB0aGVyZSBpcyBhIHNsb3Qgb2YgMjAgbWludXRlcyBkdXJpbmcgdGhlIG5leHQg
Q0NBTVAgV0cgbWVldGluZyB3aGVyZSB0aGlzIGRvY3VtZW50IGFuZCBhbGwgcmVsYXRlZCBpc3N1
ZXMgd2lsbCBiZSBoZWF2aWx5IGRpc2N1c3NlZCAuLi4gc28gaSB3ZWxjb21lIHlvdSB0byBqb2lu
IHRoZSBmZXN0aXZpdGllcyA7LSk8L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxD
b3VyaWVyIj50aGFua3MsPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmll
ciI+LSBkaW1pdHJpLjwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi
PiZuYnNwOyA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTI+PEI+JnF1b3Q7QWxpIFNhamFzc2kg
XChzYWphc3NpXCkmcXVvdDsgJmx0O3NhamFzc2lAY2lzY28uY29tJmd0OzwvQj48L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9Mj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9Mj4wNy8yNS8yMDA1IDE2OjEzIE1TVDwvRk9OVD48QlI+PEJSPiA8Rk9OVCBT
SVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+JnF1b3Q7Q0hPLCBKQUkgSFlVTkcmcXVvdDsg
Jmx0O2phaWh5dW5nQGV0cmkucmUua3ImZ3Q7LCAmcXVvdDtIZWlsZXMgSnVlcmdlbiZxdW90OyAm
bHQ7anVlcmdlbi5oZWlsZXNAc2llbWVucy5jb20mZ3Q7LCAmbHQ7cGVyQGRlZmVyby5zZSZndDs8
L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+Y2M6PC9GT05UPiA8Rk9OVCBTSVpFPTI+Jmx0O2NjYW1w
QG9wcy5pZXRmLm9yZyZndDs8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+YmNjOjwvRk9OVD4gPEJS
PiA8Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5SRTogRnJhbWVmb3Jt
YXQgaW4gYSBsMmNzIGdtcGxzIHJudmlyb25tZW50IC0gSXNzdWVzIHcvIEdNUExTIEV0aGVybmV0
PC9GT05UPjxCUj4gPEJSPjxCUj48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi
PkphaWh5dW5nLDxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5J
dCBzZWVtcyB0byBtZSB0aGF0IHlvdXIgcHJpbWFyeSBvYmplY3RpdmUgaXMgdG8gdXNlIHRoZSBl
eGlzdGluZzxCUj5FdGhlcm5ldCBzd2l0Y2hlcyB3aXRoIG5ldyBjb250cm9sIHBsYW5lIChHTVBM
UykgdG8gc2V0dXAgVEUgcGF0aHMgZm9yPEJSPmRpZmZlcmVudCBhcHBsaWNhdGlvbnMuIEFuZCB5
b3UgbWVudGlvbmVkIHRocmVlIGFwcHJvYWNoZXMgZm9yIGRvaW5nPEJSPnRoaXMgaW4geW91ciBl
bWFpbC4gSG93ZXZlciwgYWxsIHRocmVlIG9mIHRoZW0gaGF2ZSBpc3N1ZXMgYW5kIGFyZSBub3Q8
QlI+dmlhYmxlLiBMZXRzIGdvIG92ZXIgdGhlbSAuLi48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNF
PSJNb25vc3BhY2UsQ291cmllciI+Jmd0OzxCUj4mZ3Q7IEluIGJlbG93IG1haWwsIEkgZGlzY3Vz
c2VkIGFib3V0IHRocmVlIHByb3Bvc2VkIGFwcHJvYWNoZXMuPEJSPiZndDs8QlI+Jmd0OzxCUj4m
Z3Q7IDEuIHVzaW5nIFZMQU4gdGFnIGFzIGl0IGlzIGZvciBMMiBsYWJlbCBlbmNvZGluZy48QlI+
PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+QXMgeW91IGtub3cgdGhp
cyBhcHByb2FjaCBoYXMgc2NhbGFiaWxpdHkgaXNzdWUgYW5kIHlvdSBhcmUgbGltaXRlZCB0bzxC
Uj40SyBzZXJ2aWNlcyBpbiB0aGUgbmV0d29yayBhbmQgaWYgeW91IHRyeSB0byB1c2UgdGhlIHVw
Y29taW5nIElFRUU8QlI+ODAyLjFhZCBzdGFuZGFyZCB0byBtYWtlIFZMQU5zLCBpbnRlcmZhY2Ug
c3BlY2lmaWMsIHRoZW4geW91IHdpbGwgbmVlZDxCUj5uZXcgc3dpdGNoZXMgYW5kIG5vdCBleGlz
dGluZyBFdGhlcm5ldCBzd2l0Y2hlcy4gRXZlbiBpZiB5b3UgdXNlIHRoZXNlPEJSPm5ld2VyIHN3
aXRjaGVzLCB5b3Ugd2lsbCBzdGlsbCBiZSBsaW1pdGVkIHRvIDRLIHNlcnZpY2VzIHBlciBpbnRl
cmZhY2U8QlI+YW5kIGl0IHdvdWxkIGRlZmVhdCB0aGUgb2JqZWN0aXZlIG9mIHVzaW5nIGV4aXN0
aW5nIHN3aXRjaGVzLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy
Ij4mZ3Q7PEJSPiZndDsgMi4gZGVmaW5pbmcgbmV3IHByb3RvY29sIElEIChUUElEKSBhbmQgYm9y
cm93IFZMQU4gdGFnIGZvcm1hdCw8QlI+Jmd0OyA/b3IgZXh0ZW5kZWQgVkxBTiB0YWcgdG8gaW1w
bGVtZW50IGxhYmVsIHN3YXBwaW5nLjxCUj4mZ3Q7PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0i
TW9ub3NwYWNlLENvdXJpZXIiPlRoaXMgYXBwcm9hY2ggcmVxdWlyZXMgbmV3IGRhdGEgcGxhbmUg
ZnVuY3Rpb25hbGl0eSB0byBiZSBpbXBsZW1lbnRlZDxCUj4od2hpY2ggZGVmZWF0cyB0aGUgb2Jq
ZWN0aXZlIG9mIHVzaW5nIGV4aXN0aW5nIHN3aXRjaGVzKS48QlI+PC9GT05UPjxCUj48Rk9OVCBG
QUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OyAzLiB1c2UgbG93ZXIgMyBieXRlcyBvZiBNQUMg
YWRkcmVzcyBmb3IgTDIgbGFiZWwgZW5jb2RpbmcuPEJSPiZndDs8QlI+PC9GT05UPjxCUj48Rk9O
VCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VGhpcyBhcHByb2FjaCBoYXMgc2V2ZXJhbCBpc3N1
ZXM6PEJSPjEpIGhvdyBkb2VzIE1BQyBhZGRyZXNzZXMgZ2V0IGRpc3RyaWJ1dGVkIGFtb25nIHRo
ZSBicmlkZ2VzID8gSG93IGRvZXM8QlI+dGhpcyBkaXN0cmlidXRpb24gd29ya3MgZHVyaW5nIGEg
bGluayBvciBub2RlIGZhaWx1cmUgPyBIb3cgZG9lcyBpdDxCUj5yZWNvdmVyIGZyb20gYSBsaW5r
IG9yIG5vZGUgZmFpbHVyZSA/PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENv
dXJpZXIiPjIpIFdpbGwgeW91IGFzc2lnbiBhIHNlcGFyYXRlIHByb3ZpZGVyIE1BQyBmb3IgZWFj
aCBjdXN0b21lciBNQUMuIElmIHNvLDxCUj50aGVuIGhvdyBkbyB5b3UgYWRkcmVzcyBNQUMgc2Nh
bGFiaWxpdHkuIElmIG5vdCwgdGhlbiBob3cgZG8geW91IHRha2U8QlI+Y2FyZSBvZiAxLXRvLU4g
bWFwcGluZyBiZXR3ZWVuIHByb3ZpZGVyIE1BQyBhZGRyZXNzIGFuZCBjdXN0b21lciBNQUM8QlI+
YWRkcmVzc2VzIGFuZCBob3cgZG8geW91IGhhbmRsZSBtdWx0aXBvaW50IGNvbm5lY3Rpb25zLjxC
Uj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4zKSBob3cgZG8gaGFu
ZGxlIGN1c3RvbWVyIEZDUyByZXRlbnRpb24gd2hlbiBkb2luZyB0aGlzIE1BQyB0cmFuc2xhdGlv
bjxCUj5zdHVmZiA/PzxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy
Ij4mZ3Q7PEJSPiZndDsgODAyLjFRIGJyaWRnZSBmb3J3YXJkcyBFdGhlcm5ldCBmcmFtZXMgdXNp
bmcgdHdvIGRhdGFwbGFuZSB0YWJsZXM8QlI+Jmd0OyAtIE1BQyBmb3J3YXJkaW5nIHRhYmxlIGFu
ZCBWTEFOIGZvcndhcmRpbmcgdGFibGUuPEJSPiZndDsgQnJpZGdlIGNvbnRyb2wgcHJvdG9jb2xz
LCBzdWNoIGFzIEdBUlAsIEdWUlAsIEdNUlAsPEJSPiZndDsgbWFuaXB1bGF0ZSBvbmUgb2YgdGhl
IHR3byBkYXRhcGxhbmUgZW50aXRpZXMuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3Nw
YWNlLENvdXJpZXIiPlRoaXMgaXMgbm90IGNvcnJlY3QuIEJyaWRnZXMgZG9uJ3QgaGF2ZSBkaWZm
ZXJlbnQgZGF0YWJhc2VzIGZvciBNQUM8QlI+Zm9yd2FyZGluZyBhbmQgVkxBTiBmb3J3YXJkaW5n
LiBUaGV5IGhhdmUgZmlsdGVyaW5nIGRhdGViYXNlKHMpIHdpdGg8QlI+Y29ycmVzcG9uZGluZyBJ
RHMgKEZJRHMpLiBWTEFOIElEcyBnZXQgbWFwcGVkIHRvIEZJRHMgYmFzZWQgb24gb3BlcmF0aW9u
PEJSPm1vZGUgKElWTCB2ZXJzdXMgU1ZMKS4gVGhlbiBvbmNlIGEgZmlsdGVyaW5nIGRhdGFiYXNl
IGlzIGlkZW50aWZpZWQsPEJSPnRoZW4gYSBNQUMgYWRkcmVzcyBsb29rdXAgaXMgcGVyZm9ybWVk
IGZvciBmb3J3YXJkaW5nLiBCcmlkZ2UgY29udHJvbDxCUj5wcm90b2NvbHMgdXNlIGEgZGVzaWdu
YXRlZCBNQUMgYWRkcmVzc2VkIGFuZCBiYXNlZCBvbiB0aGVzZSBNQUM8QlI+YWRkcmVzc2VkLCB0
aGUgYnJpZGdlIGtub3dzIGhvdyB0byBwcm9jZXNzIHRoZSBmcmFtZS48QlI+PC9GT05UPjxCUj48
Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OzxCUj4mZ3Q7IFNpbWlsYXJseSwgb3B0
aW9uIDEgYW5kIDMgYXJlIGFib3V0IHdoaWNoIG9uZSBvZiB0d288QlI+Jmd0OyBkYXRhcGxhbmUg
ZW50aXRpZXM8QlI+Jmd0OyBHTVBMUyBwcm90b2NvbCBzaG91bGQgY29udHJvbCBvbiBiZWhhbGYg
b2YgYnJpZGdlIGNvbnRyb2wgcHJvdG9jb2xzLjxCUj4mZ3Q7IFRoZSB0d28gcHJvcG9zYWxzIGRv
IG5vdCBpbnRlbmQgdG8gbW9kaWZ5IGJyaWRnZSBiZWhhdmlvcjxCUj4mZ3Q7IHNlcmlvdXNseSwg
c3VjaCBhcyBNQUMgbGVhcm5pbmcsIGFnaW5nLCBmaWx0ZXJpbmcuPEJSPiZndDsgVGhlcmVmb3Jl
LCB0aGUgYXBwcm9hY2hlcyAxIGFuZCAzIGFyZSBpbiB0aGUgc2NvcGUgb2YgQ0NBTVAuPEJSPjwv
Rk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPklmIHRoYXQncyB0aGUgaW50
ZW50aW9uLCB5b3UgbWF5IGZpbmQgb3V0IHNvb24geW91IGdldCBtb3JlIHRoYW4gd2hhdDxCUj55
b3UgYXNrZWQgZm9yIDotKTxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy
aWVyIj4mZ3Q7PEJSPiZndDsgKCUgbm90ZSBob3dldmVyLCBJIHdvdWxkIHJlZ2FyZCBpbXBsZW1l
bnRpbmcgbGFiZWwgc3dhcHBpbmc8QlI+Jmd0OyBmdW5jdGlvbiBpcyBhY2NlcHRhYmxlIGNoYW5n
ZSBjb25zaWRlcmluZyB0aGUgSW50ZXJuYWwgU3VibGF5ZXI8QlI+Jmd0OyBkZXNpZ24gb2YgODAy
LjFEIGJyaWRnZS4pPEJSPiZndDs8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2Us
Q291cmllciI+VGhlIG9ubHkgd2F5IG9mIGRvaW5nIHRoaXMgaXMgdXNpbmcgVklEIHRyYW5zbGF0
aW9uIHRhYmxlIHNwZWNpZmllZCBpbjxCUj5JRUVFIDgwMi4xYWQgd2hpY2ggcmVxdWlyZXMgbmV3
IGRhdGEtcGxhbmUgZnVuY3Rpb25hbGl0eSBhbmQgdGh1czxCUj5leGlzdGluZyBicmlkZ2VzIGNh
bm5vdCBiZSB1c2VkICEhPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJp
ZXIiPkFsc28gaWYgZ29pbmcgdGhlIHJvdXRlIG9mIHRhZyBzd2FwcGluZywgeW91IG1heSBjb25z
aWRlciB1c2luZyBJRUVFPEJSPjgwMi4xYWguIEFzIHRoZSBlZGl0b3Igb2YgLjFhaCwgSSBjYW4g
Z28gb3ZlciB0aGUgZGV0YWlscyB3aGVuIEkgZ2V0IGE8QlI+Y2hhbmNlLjxCUj48L0ZPTlQ+PEJS
PjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7PEJSPiZndDsgSG93ZXZlciwgb3B0
aW9uIDIgaXMgYWJvdXQgd2hhdCBUUElEIGNvZGUgd2Ugd2lsbDxCUj4mZ3Q7IGNob29zZSB0byBp
bXBsZW1lbnQgbmV3IHN3aXRjaGluZyBmdW5jdGlvbi48QlI+Jmd0OyBUaGUgc3dpdGNoIG9mIHRo
aXMgaW1wbGVtZW50YXRpb24gc2hvdWxkIGhhdmUgbmV3IGhhcmR3YXJlPEJSPiZndDsgZGVzaWdu
IGluIGFkZGl0aW9uIHRvIG5vcm1hbCBicmlkZSBoYXJkd2FyZS48QlI+Jmd0OyBJIHRoaW5rIHN1
Y2ggcHJvcG9zYWwgYXMgb3B0aW9uIDIgaXMgb3V0IG9mIENDQU1QIHNjb3BlLjxCUj48L0ZPTlQ+
PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5ZZXMuPEJSPjwvRk9OVD48QlI+PEZP
TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZndDs8QlI+Jmd0OyBPdmVyYWxsIG9iamVjdGl2
ZSBpcyBpbXByb3Zpbmcgc2NhbGFiaWxpdHksIHRyYWZmaWMgZW5naW5lZXJpbmcgKFRFKTxCUj4m
Z3Q7IGNoYXJhY3RlcmlzdGljcyBvZiA4MDIuMSBicmlkZ2UgdGhhdCBpdCBjYW4gYmUgcmVsaWFi
bGUsIG1hbmFnZWFibGU8QlI+Jmd0OyBlbm91Z2ggdG8gcmVwbGFjZSBzb21lIGNvcmUgcm91dGVy
cy48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+RWFzaWVyIHNh
aWQgdGhhbiBkb25lIDotKTxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy
aWVyIj4mZ3Q7IFRoZSBzd2l0Y2hpbmcgdGVjaG5pcXVlIHlvdSBtZW50aW9uZWQgYWJvdmUsIHN1
Y2ggYXM8QlI+Jmd0OyBFdGhlcm5ldCBvdmVyIE1QTFMgYXMgZGVmaW5lZCBieSBQV0UzIGFuZCBM
MlZQTiw8QlI+Jmd0OyBhcmUgYWxsIGFjdHVhbGx5IHJvdXRlciBiYXNlZCB0ZWNobm9sb2d5LCBo
b3dldmVyIHRoaXM8QlI+Jmd0OyB3b3JrIGlzIGJhc2VkIG9uIHNpbXBsZSBicmlkZ2UgYXJjaGl0
ZWN0dXJlLjxCUj4mZ3Q7IENvc3QtZWZmZWN0aXZlbmVzcyBpcyB0aGUga2V5IGRpZmZlcmVudGlh
dG9yLjxCUj4mZ3Q7PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi
PlRoZSBkZXZpbHMgYXJlIGluIHRoZSBkZXRhaWxzIGFuZCBvbmNlIHlvdSB3b3JrZWQgb3V0IHRo
ZSBkZXRhaWxzLCB5b3U8QlI+d2lsbCBzZWUgdGhlIGlzc3Vlcy48QlI+PC9GT05UPjxCUj48Rk9O
VCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OzxCUj4mZ3Q7IEluIGFjY2VzcyBvciBlbnRl
cnByaXNlIG5ldHdvcmssIGNhcGFiaWxpdHkgb2YgcHJvdmlkaW5nIGVuZC10by1lbmQ8QlI+Jmd0
OyBMMi1MU1Agd2lsbCBlbmFibGUgc2VydmljZSBwcm92aWRlcnMgcG9saWNpbmcsIG1lYXN1cmlu
ZywgY2hhcmdpbmc8QlI+Jmd0OyBhcHBsaWNhdGlvbiBmbG93cyB1c2luZyBFdGhlcm5ldCBiYXNl
ZCBuZXR3b3JrLiBUaGlzIHdpbGwgZXZlbnR1YWxseTxCUj4mZ3Q7IGltcHJvdmUgaW5jb21lIHN0
cnVjdHVyZSBhbmQgaW50cm9kdWNlIG5ldyBzZXNzaW9uIGJhc2VkIGNvbW1lcmNpYWw8QlI+Jmd0
OyBzZXJ2aWNlLiBJIGhhdmUgYmVlbiBkaXNjdXNzaW5nIHRoaXMgYXNwZWN0IGluIG1haWwgdGhy
ZWFkIG9mPEJSPiZndDsgdGl0bGUgJ0VuZC10by1lbmQgTDItTFNQJy4gJm5ic3A7UGxlYXNlIHJl
YWQgdGhlIG1haWwgdGhyZWFkIGFuZCBjb21tZW50PEJSPiZndDsgb24gdGhlIGRpc2N1c3Npb24u
PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7ICZndDtZb3UgbWVudGlvbmVkIHRvIHVzZSB0aGUgTUFD
IGFkZHJlc3Mgb3IgcGFydCBvZiBpdCBhcyBhIGxhYmVsLjxCUj4mZ3Q7ICZndDtUaGUgVFJJTEwg
d29ya2luZyBncm91cCBpcyBkZWZpbmluZyBzaG9ydGVzdCBwYXRoIHJvdXRpbmc8QlI+Jmd0OyBm
b3IgRXRoZXJuZXQuPEJSPiZndDsgJmd0O0hvdyB3b3VsZCB0aGlzIGZpdCB0b2dldGhlcj88QlI+
Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgVFJJTEwgZW1wbG95cyBuZXcgZW5jYXBzdWxhdGlvbiBsYXll
ciBvdXRzaWRlIG9mIEV0aGVybmV0IGZyYW1lcy48QlI+Jmd0OyBIb3dldmVyIGluIG15IHByb3Bv
c2FsIG9mIG9wdGlvbi0zLCBJIHNpbXBseSB1c2UgdGhlIEV0aGVybmV0IGhlYWRlcjxCUj4mZ3Q7
IHRvIGVuY29kZSBHTVBMUyBsYWJlbC48QlI+Jmd0OzxCUj4mZ3Q7IFRoZSBvdmVyYWxsIGZvcm1h
dCBvZiByYnJpZGdlIGlzPEJSPiZndDsgW0V0aGVybmV0XVtyLXRhZ11bRXRoZXJuZXRdWyBkYXRh
Li5dPEJSPiZndDsgSXQgaXMgbm90IExTUCBiYXNlZCB0ZWNobm9sb2d5IGJ1dCBhIGNvbm5lY3Rp
b25sZXNzIHJvdXRpbmcgYnJpZGdlLjxCUj4mZ3Q7IFRUTCBjb3VudCBpcyB2ZXJ5IGltcG9ydGFu
dCBpbiByYnJpZGdlIGJlY2F1c2UgZnJhbWVzIGFyZSByb3V0ZWQ8QlI+Jmd0OyBob3AtYnktaG9w
IGFuZCBpdCBtYXkgbG9vcC48QlI+Jmd0OzxCUj4mZ3Q7IFdoZXJlYXMgaW4gb3B0aW9uLTMgYWJv
dmUsIEV0aGVybmV0IGZyYW1lcyB0aGF0IGhhdmUgY2VydGFpbjxCUj4mZ3Q7IE9VSSBwcmVmaXgg
aW4gTUFDIGFkZHJlc3MgYXJlIGZvcndhcmRlZCB2aWEgYSBwYXRoIHRoYXQ8QlI+Jmd0OyBHTVBM
UyBwcm90b2NvbCBoYXMgY29uZmlndXJlZCBvbiBNQUMgZm9yd2FyZGluZyB0YWJsZS48QlI+Jmd0
OzxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5Ib3cgZG9lcyB0
aGUgcmVkdW5kYW5jeSB3b3JrIGluIGhlcmUuIEFyZSB5b3UgdXNpbmcgYnJpZGdlIHByb3RvY29s
IGluPEJSPmNvbmp1bmN0aW9uIHdpdGggR01QTFMgcHJvdG9jb2wuIElmIHlvdSBkbywgdGhlbiB0
aGVyZSBhcmUgYnVuY2ggb2Y8QlI+aXNzdWVzLiBJZiB5b3UgZG9uJ3QsIHRoZW4gd2hhdCBpcyBp
dCB1c2VkIGFuZCBob3cgZG9lcyBpdCBpbnRlcmFjdCB3aXRoPEJSPmJyaWRnaW5nIHByb3RvY29s
cyA/PzxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4tQWxpPEJS
PjwvRk9OVD48QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7PEJSPiZn
dDsgVGhhbmtzPEJSPiZndDs8QlI+Jmd0OyBKYWloeXVuZzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0
OzxCUj4mZ3Q7IC0tLS0tPz8gPz8/LS0tLS08QlI+Jmd0OyA/PyA/PzogJnF1b3Q7SGVpbGVzIEp1
ZXJnZW4mcXVvdDsgJmx0O2p1ZXJnZW4uaGVpbGVzQHNpZW1lbnMuY29tJmd0OzxCUj4mZ3Q7ID8/
ID8/OiAyMDA1LTA3LTI1ID8/IDY6NDQ6MzQ8QlI+Jmd0OyA/PyA/PzogJnF1b3Q7Q0hPLCBKQUkg
SFlVTkcmcXVvdDsgJmx0O2phaWh5dW5nQGV0cmkucmUua3ImZ3Q7LCAmcXVvdDtIZWlsZXM8QlI+
Jmd0OyBKdWVyZ2VuJnF1b3Q7ICZsdDtqdWVyZ2VuLmhlaWxlc0BzaWVtZW5zLmNvbSZndDssICZx
dW90O3BlckBkZWZlcm8uc2UmcXVvdDs8QlI+Jmd0OyAmbHQ7cGVyQGRlZmVyby5zZSZndDs8QlI+
Jmd0OyA/PzogJnF1b3Q7Y2NhbXBAb3BzLmlldGYub3JnJnF1b3Q7ICZsdDtjY2FtcEBvcHMuaWV0
Zi5vcmcmZ3Q7PEJSPiZndDsgPz86IFJFOiBGcmFtZWZvcm1hdCBpbiBhIGwyY3MgZ21wbHMgcm52
aXJvbm1lbnQuPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7
PEJSPiZndDsgRGVhciBKYWloeXVuZyw8QlI+Jmd0OzxCUj4mZ3Q7IHlvdSBtZW50aW9uIHNldmVy
YWwgb3B0aW9ucyB0aGF0IGNvdWxkIGJlIHVzZWQgYXMgYSBsYWJlbC48QlI+Jmd0OyBNb3N0IG9m
IHRoZW0gaGF2ZSBzdHJvbmcgaW1wYWN0cyBvbiB0aGUgZGF0YSBwbGFuZSBhbmQ8QlI+Jmd0OyBp
bnRyb2R1Y2UgbmV3IGxheWVyIG5ldHdvcmtzLiBJcyB0aGlzIGluIHRoZSBzY29wZSBvZiBDQ0FN
UD88QlI+Jmd0OyBXaGF0IGlzIHRoZSBnb2FsLCB0byBpbnRyb2R1Y2UgYSBjb250cm9sIHBsYW5l
IGZvciBhIGV4aXN0aW5nPEJSPiZndDsgTDIgdGVjaG5vbG9neSBvciBpbnRyb2R1Y2UgYSBuZXcg
TDIgdGVjaG5vbG9neT8gV2hhdCB3b3VsZCBiZTxCUj4mZ3Q7IHRoZSBiZW5lZml0IG9mIHN1Y2gg
YSBuZXcgTDIgY28gc3dpdGNoaW5nIHRlY2hub2xvZ3kgY29tcGFyZWQ8QlI+Jmd0OyB0byBFdGhl
cm5ldCBvdmVyIE1QTFMgYXMgZGVmaW5lZCBieSBQV0UzIGFuZCBMMlZQTj88QlI+Jmd0OyBZb3Ug
bWVudGlvbmVkIHRvIHVzZSB0aGUgTUFDIGFkZHJlc3Mgb3IgcGFydCBvZiBpdCBhcyBhPEJSPiZn
dDsgbGFiZWwuIFRoZSBUUklMTCB3b3JraW5nIGdyb3VwIGlzIGRlZmluaW5nIHNob3J0ZXN0IHBh
dGg8QlI+Jmd0OyByb3V0aW5nIGZvciBFdGhlcm5ldC4gSG93IHdvdWxkIHRoaXMgZml0IHRvZ2V0
aGVyPzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBSZWdhcmRzPEJSPiZndDs8QlI+Jmd0OyBKdWVy
Z2VuPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7ICZndDsg
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+Jmd0OyAmZ3Q7IEZyb206IENITywgSkFJIEhZ
VU5HIFttYWlsdG86amFpaHl1bmdAZXRyaS5yZS5rcl08QlI+Jmd0OyAmZ3Q7IFNlbnQ6IFNhdHVy
ZGF5LCBKdWx5IDIzLCAyMDA1IDY6MTkgQU08QlI+Jmd0OyAmZ3Q7IFRvOiBIZWlsZXMgSnVlcmdl
bjsgcGVyQGRlZmVyby5zZTxCUj4mZ3Q7ICZndDsgQ2M6IGNjYW1wQG9wcy5pZXRmLm9yZzxCUj4m
Z3Q7ICZndDsgU3ViamVjdDogUkU6IEZyYW1lZm9ybWF0IGluIGEgbDJjcyBnbXBscyBybnZpcm9u
bWVudC48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgRGVhciBKdWVyZ2Vu
LCBQYXIgYW5kIGFsbCw8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBUaGUgcHJvcG9zZWQgZnJh
bWV3b3JrIG9mIEwyU0Mgd2FzIG5vdCBpbnRlbmRlZCB0byBzdWdnZXN0PEJSPiZndDsgJmd0OyBh
bnkgc3BlY2lmaWMgc29sdXRpb24uIEl0IGlzIHN0aWxsIGFuIG9wZW4gcXVlc3Rpb24uPEJSPiZn
dDsgJmd0OyBBcyBBZHJpYW4gbm90ZWQsIGl0IG9ubHkgYWltcyB0byBwcmVzZW50IHJlcXVpcmVt
ZW50czxCUj4mZ3Q7ICZndDsgYXMgaW4gc2NlbmFyaW9zIHRoYXQgbWF5IGRyaXZlIHBlb3BsZSB0
b3dhcmQgbmV4dCBzdGVwIGluIG1hbnk8QlI+Jmd0OyAmZ3Q7IHZpYWJsZSBzb2x1dGlvbnMuPEJS
PiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgSW4gZmFjdCwgdGhlcmUgYXJlIG90aGVyIG9wdGlvbnMg
d2UgbWF5IGFsc28gY29uc2lkZXIgZm9yIEwyPEJSPiZndDsgJmd0OyBsYWJlbCBlbmNvZGluZy48
QlI+Jmd0OyAmZ3Q7IElFRUUgODAyLjEgRXRoZXJuZXQgYnJpZGdlcyBmb3J3YXJkIGZyYW1lcyBi
YXNlZCBvbiA0OGJpdHMgb2Y8QlI+Jmd0OyAmZ3Q7IE1BQyBhZGRyZXNzLDxCUj4mZ3Q7ICZndDsg
YW5kIGFkZGl0aW9uYWxseSB1c2luZyBWTEFOIHRhZy48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0
OyBXaGVuIHRoZSBwdXJwb3NlIG9mIEdNUExTIGNvbnRyb2wgb3ZlciBFdGhlcm5ldCBpcyBub3Qg
dG88QlI+Jmd0OyAmZ3Q7IGNyZWF0ZSBuZXcgZGF0YXBsYW5lPEJSPiZndDsgJmd0OyBidXQgdG8g
dXRpbGl6ZSBJRUVFIDgwMi4xIGJyaWRnZSBhcmNoaXRlY3R1cmUsIHdlIG1heTxCUj4mZ3Q7IGNv
bnNpZGVyIHVzaW5nPEJSPiZndDsgJmd0OyBvbmUgb2YgdGhlIHR3byBmb3J3YXJkaW5nIG1ldGhv
ZHMsIE1BQyBmb3J3YXJkaW5nIG9yIFZMQU48QlI+Jmd0OyBmb3J3YXJkaW5nLjxCUj4mZ3Q7ICZn
dDsgKGFuZCBwZXJoYXBzIGFueSBvdGhlciBjb21iaW5hdGlvbiBvZiBmaWVsZHMgaW4gTUFDLCBi
dXQgSSdsbDxCUj4mZ3Q7ICZndDsgbm90IGRpc2N1c3MgaXQpPEJSPiZndDsgJmd0OzxCUj4mZ3Q7
ICZndDsgVXNlIG9mIFZMQU4gSUQgZm9yIGxhYmVsIGVuY29kaW5nIG1heSBhdXRvbWF0ZSBWTEFO
IGNvbmZpZ3VyYXRpb248QlI+Jmd0OyAmZ3Q7IHVzaW5nIElQIHByb3RvY29scy4gSG93ZXZlciwg
R01QTFMgcHJvdG9jb2wgY2Fubm90IHVzZSB0aGU8QlI+Jmd0OyAmZ3Q7IGZpZWxkIGV4Y2x1c2l2
ZWx5PEJSPiZndDsgJmd0OyBiZWNhdXNlIHB1YmxpYy9wcml2YXRlIG9wZXJhdG9ycyBhbHJlYWR5
IHVzZSBWTEFOIGZvciB2YXJpb3VzPEJSPiZndDsgJmd0OyBwdXJwb3NlLjxCUj4mZ3Q7ICZndDsg
VGhlcmUgaXMgYSBwb3RlbnRpYWwgY29uZmxpY3Qgd2l0aCBleGlzdGluZyB1c2Ugb2YgVkxBTiBh
bmQ8QlI+Jmd0OyAmZ3Q7IEdNUExTIHVzZSBvZiBWTEFOIGxhYmVsLjxCUj4mZ3Q7ICZndDsgRnVy
dGhlcm1vcmUsIHNjYWxhYmlsaXR5IG9mIFZMQU4gSUQgaGFzIGJlZW4gZnJlcXVlbnRseSBub3Rl
ZDxCUj4mZ3Q7ICZndDsgYXMgd2Vha25lc3M8QlI+Jmd0OyAmZ3Q7IGJlY2F1c2UgdGhlIHNpemUg
b2YgVkxBTiBJRCBpcyBhdCBtb3N0IDQwOTYgKDEyYml0KS48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsg
Jmd0OyBUaGUgc2NhbGFiaWxpdHkgbWF5IGJlIGltcHJvdmVkIGlmIHRoZSBzY29wZSBvZiBWTEFO
IGxhYmVsIGlzPEJSPiZndDsgJmd0OyBjb25maW5lZCB0bzxCUj4mZ3Q7ICZndDsgbGluay1sb2Nh
bCwgYW5kIHNvbWUgYWRkaXRpb25hbCBzd2FwcGluZyBmdW5jdGlvbiBvZiBWTEFOIElEPEJSPiZn
dDsgJmd0OyBpcyBpbnRyb2R1Y2VkIGluPEJSPiZndDsgJmd0OyBJbnRlcm5hbCBTdWJsYXllciBb
ODAyLjFEXSBvZiBHTVBMUyBpbXBsZW1lbnRlZCBzd2l0Y2guPEJSPiZndDsgJmd0OyBIb3dldmVy
LCB0aGlzIHdpbGwgb25seSBiZSBlZmZlY3RpdmUgd2hlbiB0aGUgY29uZmlndXJhdGlvbjxCUj4m
Z3Q7ICZndDsgb2YgbmV0d29yazxCUj4mZ3Q7ICZndDsgaXMgbWVzaCBzdHJ1Y3R1cmUgdGhhdCBt
dWx0aXBsZSBMU1AgcGF0aHMgZXhpc3QuIElmIHRoZTxCUj4mZ3Q7ICZndDsgY29uZmlndXJhdGlv
biBvZiBuZXR3b3JrPEJSPiZndDsgJmd0OyBpcyBzdGFyIG9yIHRyZWUgc2hhcGUsIGFzIG5vcm1h
bCBjb25maWd1cmF0aW9uIG9mIGFjY2VzcyBuZXR3b3JrLDxCUj4mZ3Q7ICZndDsgTFNQcyBjb25j
ZW50cmF0ZSBpbiByb290IG5vZGUgYW5kIHRvdGFsIG51bWJlciBvZjxCUj4mZ3Q7ICZndDsgTFNQ
cyB0aGF0IHRoZSBuZXR3b3JrIGNhbiBob2xkIHN0aWxsIGJlIGxpbWl0ZWQgYnkgYXZhaWxhYmxl
PEJSPiZndDsgJmd0OyBsYWJlbCBzcGFjZTxCUj4mZ3Q7ICZndDsgYXQgYSBmZXcgcm9vdCBsaW5r
cy48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBGb3IgdGhlc2UgcmVhc29ucywgSSBkbyBub3Qg
dGhpbmsgYW55IGZvcm0gb2YgVkxBTiBJRCBsYWJlbCBpczxCUj4mZ3Q7ICZndDsgYW4gYXBwcm9w
cmlhdGUgY2hvaWNlIGZvciBsYXllci0yIGxhYmVsIGVuY29kaW5nLjxCUj4mZ3Q7ICZndDs8QlI+
Jmd0OyAmZ3Q7IFRoZXJlIGFyZSBzb21lIG90aGVyIHByb3Bvc2FscyBhc3N1bWluZyBuZXcgYXNz
aWdubWVudCBvZiBFdGhlcm5ldDxCUj4mZ3Q7ICZndDsgTGVuZ3RoL1R5cGUgdmFsdWUgKGUuZy4g
bmV3IFRQSUQgaW4gVkxBTiB0YWcpIGFuZCByZS1kZWZpbml0aW9uIG9mPEJSPiZndDsgJmd0OyBp
bmZvcm1hdGlvbiBmaWVsZHMgcGxhY2VkIGJldHdlZW4gODAyLjMgTUFDIGhlYWRlciBhbmQgSVAg
cGFja2V0LjxCUj4mZ3Q7ICZndDsgSW4gdGhpcyBjYXNlLCBvbmx5IHRoZSBmb3JtYXQgb2YgVkxB
TiB0YWcgb3IgZXh0ZW5kZWQgVkxBTiB0YWc8QlI+Jmd0OyAmZ3Q7IGlzIGJvcnJvd2VkLCBob3dl
dmVyLCBpbnNpZGUgdGhlIHN3aXRjaGluZyBoYXJkd2FyZSwgdGhlPEJSPiZndDsgJmd0OyBmaWx0
ZXIgYW5kIHJlbGF5LDxCUj4mZ3Q7ICZndDsgZXRjLiBhcmUgdG90YWxseSBkaWZmZXJlbnQgbmV3
IGRhdGFwbGFuZSBzd2l0Y2guPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgSSBkbyBub3Qgc2Vl
IHN1Y2ggYXBwcm9hY2ggaXMgYSBHTVBMUyBpbXBsZW1lbnRhdGlvbiBmb3IgRXRoZXJuZXQ8QlI+
Jmd0OyAmZ3Q7IGJlY2F1c2UgdGhlIGNvcmUgc3dpdGNoaW5nIHRlY2huaXF1ZSBpcyBub3QgODAy
LjEgRXRoZXJuZXQ8QlI+Jmd0OyAmZ3Q7IGJyaWRnZSBhdCBhbGwuPEJSPiZndDsgJmd0OzxCUj4m
Z3Q7ICZndDsgVGhlIG90aGVyIG9wdGlvbiB3ZSBtYXkgY29uc2lkZXIgaXMgdXNpbmcgTUFDIGFk
ZHJlc3MgZmlsZWQ8QlI+Jmd0OyBhcyBiZWxvdy48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OzxC
Uj4mZ3Q7ICZndDsgKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0t
LS0tKzxCUj4mZ3Q7ICZndDsgfCAxYnl0ZSB8IDJieXRlIHwgM2J5dGUgfCA0Ynl0ZSB8IDVieXRl
IHwgNmJ5dGUgfDxCUj4mZ3Q7ICZndDsgKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0r
LS0tLS0tLSstLS0tLS0tKzxCUj4mZ3Q7ICZndDsgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxCUj4mZ3Q7ICZndDsgfCAmbmJzcDtPVUkgUHJlZml4ICg9
R01QTFMpICZuYnNwO3wgJm5ic3A7IERBLWxhYmVsICgyNGJpdCkgJm5ic3A7ICZuYnNwO3w8QlI+
Jmd0OyAmZ3Q7ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LSs8QlI+Jmd0OyAmZ3Q7IHwgJm5ic3A7T1VJIFByZWZpeCAoPUdNUExTKSAmbmJzcDt8ICZuYnNw
OyBTQS1sYWJlbCAoMjRiaXQpICZuYnNwOyAmbmJzcDt8PEJSPiZndDsgJmd0OyArLS0tLS0tLS0t
LS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rPEJSPiZndDsgJmd0OyB8IExl
bmd0aC9UeXBlICZuYnNwOyB8PEJSPiZndDsgJmd0OyArLS0tLS0tLS0tLS0tLS0tKzxCUj4mZ3Q7
ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBJRUVFIGlzIGRlc2lnbmF0ZWQgYnkgdGhl
IElTTyBDb3VuY2lsIHRvIGFjdCBhcyB0aGU8QlI+Jmd0OyAmZ3Q7IHJlZ2lzdHJhdGlvbiBhdXRo
b3JpdHk8QlI+Jmd0OyAmZ3Q7IGZvciB0aGUgaGlnaGVyIHRocmVlLW9jdGV0IG9mIE9VSSBudW1i
ZXIgaW4gdGhlIE1BQyBhZGRyZXNzPEJSPiZndDsgJmd0OyB0byBiZSB1c2VkIGJ5IG1hbnVmYWN0
dXJlci4gRXRoZXJuZXQgbWFudWZhY3R1cmVyIG1heSBnZW5lcmF0ZTxCUj4mZ3Q7ICZndDsgZ2xv
YmFsIHVuaXF1ZSBNQUMgYWRkcmVzcyB1c2luZyB0aGUgT1VJIHByZWZpeCBhbmQgYWRkcmVzcyBi
bG9jayBvZjxCUj4mZ3Q7ICZndDsgbG93ZXIgdGhyZWUtb2N0ZXQgKDI0Yml0KS4gVGFraW5nIGFk
dmFudGFnZSBvZiB0aGU8QlI+Jmd0OyBhZGRyZXNzaW5nIHNjaGVtZSw8QlI+Jmd0OyAmZ3Q7IEdN
UExTIG1heSB1c2UgdGhlIGxvd2VyIHRocmVlLW9jdGV0IGV4Y2x1c2l2ZWx5IGlmIGEgdW5pcXVl
PEJSPiZndDsgJmd0OyBPVUkgbnVtYmVyPEJSPiZndDsgJmd0OyBpcyByZXNlcnZlZCBmb3IgdGhl
IHByb3RvY29sLiBXaXRoIHRoaXMgbGFiZWxpbmcgc2NoZW1lLCBHTVBMUyB3aWxsPEJSPiZndDsg
Jmd0OyBjb250cm9sIE1BQyBmb3J3YXJkaW5nIGVudHJ5LCBub3QgVkxBTiB0YWJsZS48QlI+Jmd0
OyAmZ3Q7PEJSPiZndDsgJmd0OyBBbGwgRXRoZXJuZXQgZnJhbWVzIGNvbnRyb2xsZWQgYnkgR01Q
TFMgd2lsbCBoYXZlIGlkZW50aWNhbDxCUj4mZ3Q7ICZndDsgT1VJIG51bWJlcjxCUj4mZ3Q7ICZn
dDsgdGhhdCB0aGV5IGNhbiBlYXNpbHkgYmUgZGlzdGluZ3Vpc2hlZCBmcm9tIG90aGVyIEV0aGVy
bmV0IGZyYW1lcy48QlI+Jmd0OyAmZ3Q7IEluIHByaW5jaXBsZSwgdGhlIGxhYmVsIGxvb2t1cCBo
YXJkd2FyZSBpcyBpZGVudGljYWwgdG8gTUFDIGxvb2t1cDxCUj4mZ3Q7ICZndDsgaGFyZHdhcmUg
aW4gdGhpcyBsYWJlbGluZyBzY2hlbWUuIFRoZXJlZm9yZSBHTVBMUyBpbXBsZW1lbnRlZDxCUj4m
Z3Q7ICZndDsgc3dpdGNoIG1heSBzdGlsbCBmdW5jdGlvbiBhcyBub3JtYWwgRXRoZXJuZXQgYnJp
ZGdlIHRvIHRoZSBmcmFtZXM8QlI+Jmd0OyAmZ3Q7IHRoYXQgT1VJIG51bWJlciBpcyBub3QgR01Q
TFMuIFRoaXMgYWxzbyBmYWNpbGl0YXRlcyBHTVBMUzxCUj4mZ3Q7IGltcGxlbWVudGVkPEJSPiZn
dDsgJmd0OyBzd2l0Y2hlcyBiZWluZyBkZXBsb3llZCBpbiBvcGVyYXRpbmcgRXRoZXJuZXQgd2l0
aCBtaW5pbXVtPEJSPiZndDsgJmd0OyBzZXJ2aWNlIGRpc3J1cHRpb24uPEJSPiZndDsgJmd0OzxC
Uj4mZ3Q7ICZndDsgTm90ZSBhbHNvIHRoYXQgYWJvdmUgcHJvcG9zZWQgbGFiZWwgZW5jb2Rpbmcg
bWV0aG9kIGlzIHRyYW5zcGFyZW50PEJSPiZndDsgJmd0OyB0byB0aGUgdXNlIG9mIEV0aGVybmV0
IExlbmd0aC9UeXBlIGZpZWxkLiBFbmQtdXNlciBkZXZpY2UgbWF5IHVzZTxCUj4mZ3Q7ICZndDsg
dGhlIExlbmd0aC9UeXBlIGZpZWxkIGFzIGRlZmluZWQgaW4gSUVFRSA4MDIuMyBwcm90b2NvbC48
QlI+Jmd0OyAmZ3Q7IEl0IGFsc28gYWxsb3dzIG5ldHdvcmsgb3BlcmF0b3JzIGNvbmZpZ3VyZSBW
TEFOIGZvciB0aGVpciBvd248QlI+Jmd0OyAmZ3Q7IHB1cnBvc2UuPEJSPiZndDsgJmd0OyBXaGVu
IElFRUUgODAyLjFwIGlzIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCBMMi1MU1AsIHRoZSBwcmlv
cml0eTxCUj4mZ3Q7ICZndDsgZmllbGQgb2YgVkxBTiB0YWcgY2FuIGFsc28gYmUgdXNlZCBmb3Ig
aW1wb3NpbmcgY29uc2lzdGVudCBURTxCUj4mZ3Q7ICZndDsgcG9saWN5IGluPEJSPiZndDsgJmd0
OyBsZWdhY3kgc3dpdGNoZXMgYW5kIEdNUExTIHN3aXRjaGVzLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0
OyAmZ3Q7IEFueSB3YXksIG15IGNvbmNsdXNpb24gaXMsIHRoZXJlIGFyZSBvdGhlciBvcHRpb25z
IHdlIG1heSBjb25zaWRlciw8QlI+Jmd0OyAmZ3Q7IGFuZCB0aGlzIGlzc3VlIGlzIHN0aWxsIG9w
ZW4gdG8gZGlzY3Vzcy48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBUaGFua3MsPEJSPiZndDsg
Jmd0OzxCUj4mZ3Q7ICZndDsgU2luY2VyZWx5LDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IEph
aWh5dW5nPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0
OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IC0tLS0tPz8gPz8/LS0tLS08QlI+Jmd0OyAmZ3Q7
ID8/ID8/OiAmcXVvdDtIZWlsZXMgSnVlcmdlbiZxdW90OyAmbHQ7anVlcmdlbi5oZWlsZXNAc2ll
bWVucy5jb20mZ3Q7PEJSPiZndDsgJmd0OyA/PyA/PzogMjAwNS0wNy0yMiA/PyAxMDoyMzo0MzxC
Uj4mZ3Q7ICZndDsgPz8gPz86ICZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsgJmx0O2xvYUBwaS5z
ZSZndDssICZxdW90O3JpY2hhcmQuc3BlbmNlckBidC5jb20mcXVvdDs8QlI+Jmd0OyAmZ3Q7ICZs
dDtyaWNoYXJkLnNwZW5jZXJAYnQuY29tJmd0OzxCUj4mZ3Q7ICZndDsgPz86ICZxdW90O3BlckBk
ZWZlcm8uc2UmcXVvdDsgJmx0O3BlckBkZWZlcm8uc2UmZ3Q7LCAmcXVvdDtjY2FtcEBvcHMuaWV0
Zi5vcmcmcXVvdDs8QlI+Jmd0OyAmZ3Q7ICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PEJSPiZn
dDsgJmd0OyA/PzogUkU6IEZyYW1lZm9ybWF0IGluIGEgbDJjcyBnbXBscyBybnZpcm9ubWVudC48
QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZn
dDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IExvYSw8QlI+Jmd0OyAmZ3Q7PEJSPiZn
dDsgJmd0OyBJIGludGVycHJldCB0aGUgSUQgYXMgYSBwcm9wb3NhbCB0byB1c2UgR01QTFMgZm9y
IFZMQU4gc2V0dXAuPEJSPiZndDsgJmd0OyBTbyBHTVBMUyBhbmQgVkxBTiB0byBub3QgY29tcGV0
ZS4gVGhlIFZMQU4gaXMgYXQgdGhlIGRhdGE8QlI+Jmd0OyAmZ3Q7IHBsYW5lIGFuZCBHTVBMUyBh
dCB0aGUgY29udHJvbCBwbGFuZS4gVGhlIHF1ZXN0aW9uIGlzIGhvdyBhbmQ8QlI+Jmd0OyAmZ3Q7
IHNob3VsZCBkaWZmZXJlbnQgY29udHJvbCBwbGFuZSB0ZWNobmlxdWVzIGxpa2UgR01QTFMgYW5k
PEJSPiZndDsgJmd0OyAoR1ZSUCBhbmQgU1RCKSB3b3JrIHRvZ2V0aGVyPzxCUj4mZ3Q7ICZndDs8
QlI+Jmd0OyAmZ3Q7IFJlZ2FyZHM8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBKdWVyZ2VuPEJS
PiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS08QlI+Jmd0OyAmZ3Q7ICZndDsgRnJvbTogb3duZXItY2NhbXBAb3BzLmlldGYu
b3JnPEJSPiZndDsgJmd0OyAmZ3Q7IFttYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXSBP
biBCZWhhbGYgT2YgTG9hIEFuZGVyc3NvbjxCUj4mZ3Q7ICZndDsgJmd0OyBTZW50OiBGcmlkYXks
IEp1bHkgMjIsIDIwMDUgMjo1MyBQTTxCUj4mZ3Q7ICZndDsgJmd0OyBUbzogcmljaGFyZC5zcGVu
Y2VyQGJ0LmNvbTxCUj4mZ3Q7ICZndDsgJmd0OyBDYzogcGVyQGRlZmVyby5zZTsgY2NhbXBAb3Bz
LmlldGYub3JnPEJSPiZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBGcmFtZWZvcm1hdCBpbiBh
IGwyY3MgZ21wbHMgcm52aXJvbm1lbnQuPEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAm
Z3Q7IFJpY2hhcmQsPEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IEkgYWdyZWUg
dG8gbW9zdCBvZiB0aGlzLiBTaW5jZSB3ZSBoYXZlIGRvdWJ0cyBhYm91dCB0aGUgdmlhYmlsaXR5
PEJSPiZndDsgJmd0OyAmZ3Q7IG9mIHRha2luZyBHTVBMUyBhbGwgdGhlIHdheSB0byBlbmQtdXNl
ciBvciBlbnRlcnByaXNlIEkgdGhpbmsgaXQ8QlI+Jmd0OyAmZ3Q7ICZndDsgd291bGQgYmUgZ29v
ZCwgZnJvbSBhIHdnIHBlcnNwZWN0aXZlLCBpZiB3ZSBhZ3JlZWQgdG8gc29sdmUgdGhlPEJSPiZn
dDsgJmd0OyAmZ3Q7IGNvcmUgbmV0d29yayBwcm9ibGVtcyBmaXJzdC48QlI+Jmd0OyAmZ3Q7ICZn
dDs8QlI+Jmd0OyAmZ3Q7ICZndDsgRG8geW91IGhhdmUgYW55IGNvbW1lbnQgb24gdGhlIHJlcXVp
cmVtZW50IHRvIHJ1biBib3RoIFZMQU5zIGFuZDxCUj4mZ3Q7ICZndDsgJmd0OyBHTVBMUyBvbiB0
aGUgc2FtZSBzd2l0Y2g/PEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IC9Mb2E8
QlI+Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgcmljaGFyZC5zcGVuY2VyQGJ0LmNv
bSB3cm90ZTo8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBSZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Ig
bm90IGEgc3dpdGNoIGlzIGRpcmVjdGx5IGNvbm5lY3RlZDxCUj4mZ3Q7ICZndDsgJmd0OyAmbmJz
cDsmZ3Q7IHRvIGhvc3RzLCBpdCBtdXN0IGJlIGFibGUgdG8gZm9yd2FyZCBwYWNrZXRzIHVzaW5n
IHRoZTxCUj4mZ3Q7ICZndDsgJmd0OyBjb25uZWN0aW9ubGVzczxCUj4mZ3Q7ICZndDsgJmd0OyAm
bmJzcDsmZ3Q7IEV0aGVybmV0IGRhdGEgcGxhbmUuIFRoaXMgaXMgZHVlIHRvIHRoZSBmdW5kYW1l
bnRhbDxCUj4mZ3Q7ICZndDsgJmd0OyByZXF1aXJlbWVudCB0aGF0PEJSPiZndDsgJmd0OyAmZ3Q7
ICZuYnNwOyZndDsgZm9yIEdNUExTIHN3aXRjaGVzIHRvIGJlIGFibGUgdG8gZXhjaGFuZ2UgY29u
dHJvbDxCUj4mZ3Q7ICZndDsgaW5mb3JtYXRpb24gd2l0aDxCUj4mZ3Q7ICZndDsgJmd0OyAmbmJz
cDsmZ3Q7IGVhY2ggb3RoZXIsIGEgZGF0YSBwbGFuZSBmb3IgY29udHJvbCB0cmFmZmljIG11c3Qg
YmUgcHJlc2VudC48QlI+Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7Jmd0OyBUaGlzIGlzIGFraW4gdG8g
dXNpbmcgdGhlIElQIGRhdGEgcGxhbmUgZm9yIE1QTFM8QlI+Jmd0OyAmZ3Q7IHNpZ25hbGxpbmcg
aW4gYW48QlI+Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7Jmd0OyBJUC9NUExTIG5ldHdvcmsuIEFuIGFs
dGVybmF0aXZlIHdvdWxkIGJlIHRvIHVzZSBhIHN0YXRpYzxCUj4mZ3Q7ICZndDsgcmVzZXJ2ZWQ8
QlI+Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7Jmd0OyBMMi1MU1AgZm9yIGNvbnRyb2wgdHJhZmZpYyBp
biB0aGUgc2FtZSB3YXkgdGhhdCByZXNlcnZlZDxCUj4mZ3Q7ICZndDsgVlBJL1ZDSXM8QlI+Jmd0
OyAmZ3Q7ICZndDsgJm5ic3A7Jmd0OyBhcmUgdXNlZCBmb3IgUE5OSSBzaWduYWxsaW5nIGluIEFU
TS48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJlZ2FyZGlu
ZyBjb25uZWN0aW5nIGhvc3RzIHRvIEdNUExTIHN3aXRjaGVzLCBJPEJSPiZndDsgcGVyc29uYWxs
eSBkb24ndDxCUj4mZ3Q7ICZndDsgJmd0OyAmbmJzcDsmZ3Q7IHRoaW5rIGV4dGVuZGluZyBMMi1M
U1BzIGludG8gdGhlIGVudGVycHJpc2UvaG9tZSBuZXR3b3JrIGlzPEJSPiZndDsgJmd0OyAmZ3Q7
ICZuYnNwOyZndDsgY29tbWVyY2lhbGx5IHZpYWJsZS4gSG93ZXZlciwgaWYgeW91IGRvIHdhbnQg
dG8gdXNlPEJSPiZndDsgJmd0OyBHTVBMUyBzd2l0Y2hlczxCUj4mZ3Q7ICZndDsgJmd0OyAmbmJz
cDsmZ3Q7IGluIHRoZSBob21lL2VudGVycHJpc2UgbmV0d29yayBhbmQgZm9yIHNvbWUgcmVhc29u
PEJSPiZndDsgZG9uJ3Qgd2FudCB0bzxCUj4mZ3Q7ICZndDsgJmd0OyAmbmJzcDsmZ3Q7IGV4dGVu
ZCBMMi1MU1BzIGRvd24gdG8gdGhlIGhvc3QgdGhlbiB5b3Ugd2lsbCBub3QgYmU8QlI+Jmd0OyBw
ZXJmb3JtaW5nPEJSPiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyZndDsgbm9ybWFsIEV0aGVybmV0IE1h
YyBhZGRyZXNzIHN3aXRjaGluZyBhbnl3YXkuIEluc3RlYWQgeW91IHdpbGw8QlI+Jmd0OyAmZ3Q7
ICZndDsgJm5ic3A7Jmd0OyBuZWVkIHNvbWUga2luZCBvZiBwb2xpY3kgb24gdGhlIHN3aXRjaCB0
aGF0IG1hcHM8QlI+Jmd0OyBjb25uZWN0aW9ubGVzczwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9u
b3NwYWNlLENvdXJpZXIiPiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyZndDsgRXRoZXJuZXQgcGFja2V0
cyAoZS5nLiBiYXNlZCBvbiBNQUMgc3JjL2Rlc3QsIDgwMi4xcCwgPC9GT05UPjxCUj48Rk9OVCBG
QUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OyBWTEFOKSB0byBhPEJSPiZndDsgJmd0OyAmZ3Q7
ICZuYnNwOyZndDsgTDItTFNQLiBUaGlzIGlzIGJlY2F1c2UgbXVsdGlwbGUgTDItTFNQcyB0byB0
aGUgc2FtZTxCUj4mZ3Q7IGRlc3RpbmF0aW9uPEJSPiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyZndDsg
KGUuZy4gYSBnYXRld2F5IHJvdXRlcikgbWF5IGV4aXN0IGZvciBkaWZmZXJlbnQgc2VydmljZXMv
Zmxvd3M8QlI+Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7Jmd0OyAoZS5nLiB2aWRlbyBkb3dubG9hZCwg
Vm9JUCBjYWxsLCBldGMuKS48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0
OyAmZ3Q7IFJlZ2FyZHMsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsgUmljaGFyZDxCUj4mZ3Q7ICZn
dDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0
OyZndDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0
O0Zyb206IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzxCUj4mZ3Q7ICZndDsgW21haWx0bzpvd25l
ci1jY2FtcEBvcHMuaWV0Zi5vcmddT248QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDtCZWhhbGYg
T2YgUGFyIE1hdHRzc29uPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7U2VudDogMjIgSnVseSAy
MDA1IDExOjQyPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7VG86IExvYSBBbmRlcnNzb248QlI+
Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDtDYzogY2NhbXBAb3BzLmlldGYub3JnPEJSPiZndDsgJmd0
OyAmZ3Q7ICZndDsmZ3Q7U3ViamVjdDogUmU6IEZyYW1lZm9ybWF0IGluIGEgbDJjcyBnbXBscyBy
bnZpcm9ubWVudC48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsg
Jmd0OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0
OyZndDsmZ3Q7UGVyIGFuZCBEaW1pdHJpLDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8
QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7SSB3b3VsZCBsaWtlIHRvIGNvbWUgZG93biBz
dHJvbmdlciB0aGFuIHRoYXQsIGZvciBtZSBpdCBpczxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0
OyZndDthIHZlcnkgc3Ryb25nIHJlcXVpcmVtZW50IHRoYXQgdGhlIHNhbWUgc3dpdGNoIGNhbiBo
YW5kbGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Ym90aCBWTEFOcyBhbmQgR01QTHMg
dHJhZmljIGNvcnJlY3RseS4gSSBjYW4ndCBkc2VlIGhvdyB0aGF0PEJSPiZndDsgJmd0OyAmZ3Q7
ICZndDsmZ3Q7Jmd0O2NvdWxkIGJlIGRvbmUgaWYgdXNpbmcgdGhlIFZMQU4gdHBpZCB0byBpbmRp
Y2F0ZSBHTVBMUzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDt0cmFmZmljLjxCUj4mZ3Q7
ICZndDsgJmd0OyAmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0O0lmIHlvdSBldmVy
IHdhbnQgdGhhdCBzYW1lIHN3aXRjaCB0byBoYW5kbGUgdHJhZmZpYyBmb3IgYTxCUj4mZ3Q7ICZn
dDsgZGlyZWN0bHk8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDtjb25uZWN0ZWQgJm5ic3A7aG9z
dCAobm90IHRvIHVuY29tbWVuKSB5b3Ugd291bGQgd2FudCB0aGF0IHRvPEJSPiZndDsgJmd0OyB1
c2Ugbm9ybWFsPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ZXRoZXJuZXQgbWFjYWRkcmVzcyBz
d2l0Y2hpbmcuIFNvIG9mIGNvdXJzZSB5b3UgZG8gbm90IHdhbnQ8QlI+Jmd0OyAmZ3Q7ICZndDsg
dG8gaGF2ZSB0bzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0O2Nob29zZSBiZXR3ZWVuIHZsYW4g
YW5kIGdtcGxzLCB5b3Ugd291bGQgd2FudCBib3RoIGF0IHRoZTxCUj4mZ3Q7ICZndDsgc2FtZSB0
aW1lLjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0
Oy9wZXI8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZn
dDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsm
Z3Q7L0xvYTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsg
Jmd0OyZndDsmZ3Q7UGFyIE1hdHRzc29uIHdyb3RlOjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0
OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDtoaSBwYXIsIG9uZSBv
ZiB0aGUgcG9zc2liaWxpdGllcyB0aGF0IGhhcyBiZWVuIGNvbnNpZGVyZWQ8QlI+Jmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDt0byBjb3BlIHdpdGg8QlI+
Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0
OyZndDt0aGlzIHJlcXVpcmVtZW50IGlzIHRvIHVzZSBhIGRlZGljYXRlZCBUUElEIGZvciB0aGU8
QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDtFdGhl
cm5ldCBsYWJlbGVkPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7
ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ZnJhbWVzOyB0aGlzIHdvdWxkIGFsbG93IGRpZmZlcmVudGlh
dGVkIHByb2Nlc3Npbmcgd2l0aDxCUj4mZ3Q7ICZndDsgJmd0OyBub24tbGFiZWxlZDxCUj4mZ3Q7
ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O2ZyYW1lc3RoYW5rcy48QlI+Jmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7
PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDtUaGF0IHNlZW1zIHRvIG1ha2UgbW9y
ZSBzZW5jZS4gSWYgdGhhdCBmcmFtZSBpcyB0byBiZTxCUj4mZ3Q7ICZndDsgc2l6ZWQgbGlrZSBh
PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs4MDIuMXE8QlI+Jmd0OyAmZ3Q7ICZn
dDsgJmd0OyZndDsmZ3Q7Jmd0O2ZyYW1lLiBUaGVyZSBpcyBub3QgdGhhdCBtdWNoIHNwYWNlIGxl
ZnQgdG8gYSBsYWJlbC4gT3IgaXM8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8QlI+Jmd0OyAm
Z3Q7ICZndDsgJmd0OyZndDt0aGUgZGVtYW5kIHRvPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7
PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDt1c2UganVtYm9mcmFtZXMgPzxCUj4m
Z3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7SGFzIHRoZXJlIGJlZW4gYW55IGRpc2N1c3Np
b24gb24gbGFiZWxzdGFja2luZywgYW5kPEJSPiZndDsgJmd0OyAmZ3Q7IG1haW5seSB3aGVyZSB0
bzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7cGxhY2U8QlI+Jmd0OyAmZ3Q7ICZn
dDsgJmd0OyZndDsmZ3Q7Jmd0O3RoZSBpbmZvcm1hdGlvbj88QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0
OyZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7UmVnYXJkcy48
QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0O1BlcjxCUj4mZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jmd0OyZndDsmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8QlI+Jmd0
OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZn
dDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsm
Z3Q7Jmd0Oy0tPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0O0xvYSBBbmRlcnNzb248QlI+
Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0
O1ByaW5jaXBhbCBOZXR3b3JraW5nIEFyY2hpdGVjdDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0
OyZndDtBY3JlbyBBQiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcGhvbmU6ICZu
YnNwOys0NiA4IDYzMiA3NyAxNDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDtJc2Fmam9y
ZHNnYXRhbiAyMiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO21vYmlsZTogKzQ2IDczOSA4MSAyMSA2NDxCUj4mZ3Q7ICZndDsgJmd0
OyAmZ3Q7Jmd0OyZndDtLaXN0YSwgU3dlZGVuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtlbWFpbDo8QlI+
Jmd0OyAmZ3Q7IGxvYS5hbmRlcnNzb25AYWNyZW8uc2U8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZn
dDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvYUBwaS5zZTxC
Uj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8
QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8QlI+
Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OzxC
Uj4mZ3Q7ICZndDsgJmd0OyAtLTxCUj4mZ3Q7ICZndDsgJmd0OyBMb2EgQW5kZXJzc29uPEJSPiZn
dDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IFByaW5jaXBhbCBOZXR3b3JraW5nIEFyY2hp
dGVjdDxCUj4mZ3Q7ICZndDsgJmd0OyBBY3JlbyBBQiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgcGhvbmU6ICZuYnNwOys0NiA4IDYzMiA3NyAxNDxCUj4mZ3Q7ICZndDsgJmd0OyBJ
c2Fmam9yZHNnYXRhbiAyMiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwO21vYmlsZTogKzQ2IDczOSA4MSAyMSA2NDxCUj4mZ3Q7ICZn
dDsgJmd0OyBLaXN0YSwgU3dlZGVuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtlbWFpbDogJm5ic3A7bG9h
LmFuZGVyc3NvbkBhY3Jlby5zZTxCUj4mZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbG9hQHBpLnNlPEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsg
Jmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OzxCUj4mZ3Q7PEJSPiZn
dDs8QlI+Jmd0OzwvRk9OVD48L1A+



Envelope-to: [e-mail]
Delivery-date: Tue, 26 Jul 2005 17:03:45 +0000
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: GMPLS VCAT and LAGR
Date: Tue, 26 Jul 2005 19:02:22 +0200
MIME-Version: 1.0
Content-Type: text/plain

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




Envelope-to: [e-mail]
Delivery-date: Tue, 26 Jul 2005 14:45:08 +0000
Message-ID: <021401c591f0$cba2cd70$a3919ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Online agenda
Date: Tue, 26 Jul 2005 15:25:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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

Will be updated as slides reach me.

Cheers,
Adrian



Envelope-to: [e-mail]
Delivery-date: Tue, 26 Jul 2005 08:44:42 +0000
Sensitivity: 
Subject: RE: Moving LSP ownership between control plane and management plane
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Tue, 26 Jul 2005 10:43:01 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

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" <[e-mail]> on 25/07/2005
18.18.11

To:    "Diego Caviglia" <[e-mail]>
cc:    "ccamp" <[e-mail]>

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-----
From: [e-mail] [mailto:[e-mail]] On
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 <[e-mail]>@ops.ietf.org on 20/07/2005 11.03.00

Sent by:    [e-mail]


To:    Adrian Farrel <[e-mail]>
cc:    [e-mail], Neil Harrison <[e-mail]>, Dino
       Bramanti <[e-mail]>

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).
>
>
>

















Envelope-to: [e-mail]
Delivery-date: Tue, 26 Jul 2005 06:02:23 +0000
Thread-Topic: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
thread-index: AcWRp4QlwPC80+CYQx66A8lU64uuxQ==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: "Ali Sajassi \(sajassi\)" <[e-mail]>, "Heiles Juergen" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
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
Message-ID: <58c001c591a7$842d1480$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
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)" <[e-mail]> 
?? ??: 2005-07-26 ?? 8:13:56 
?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen" <[e-mail]>, "[e-mail]" <[e-mail]> 
??: "[e-mail]" <[e-mail]> 
??: 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" <[e-mail]> 
> ?? ??: 2005-07-25 ?? 6:44:34 
> ?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles 
> Juergen" <[e-mail]>, "[e-mail]" 
> <[e-mail]> 
> ??: "[e-mail]" <[e-mail]> 
> ??: 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 
>  
> 
> 
> 
> 
> > -----Original Message----- 
> > From: CHO, JAI HYUNG [mailto:[e-mail]] 
> > Sent: Saturday, July 23, 2005 6:19 AM 
> > To: Heiles Juergen; [e-mail] 
> > Cc: [e-mail] 
> > 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" <[e-mail]> 
> > ?? ??: 2005-07-22 ?? 10:23:43 
> > ?? ??: "Loa Andersson" <[e-mail]>, "[e-mail]" 
> > <[e-mail]> 
> > ??: "[e-mail]" <[e-mail]>, "[e-mail]" 
> > <[e-mail]> 
> > ??: 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 
> > 
> > 
> > > -----Original Message----- 
> > > From: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of Loa Andersson 
> > > Sent: Friday, July 22, 2005 2:53 PM 
> > > To: [e-mail] 
> > > Cc: [e-mail]; [e-mail] 
> > > 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 
> > > 
> > > [e-mail] 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 
> > > > 
> > > > 
> > > >>-----Original Message----- 
> > > >>From: [e-mail] 
> > [mailto:[e-mail]]On 
> > > >>Behalf Of Par Mattsson 
> > > >>Sent: 22 July 2005 11:42 
> > > >>To: Loa Andersson 
> > > >>Cc: [e-mail] 
> > > >>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:  [phone] 
> > > >>>Isafjordsgatan 22                  mobile: [phone] 
> > > >>>Kista, Sweden                      email:  
> > [e-mail] 
> > > >>>                                            [e-mail] 
> > > >>> 
> > > >> 
> > > >> 
> > > >> 
> > > > 
> > > 
> > > 
> > > -- 
> > > Loa Andersson 
> > > 
> > > Principal Networking Architect 
> > > Acreo AB                           phone:  [phone] 
> > > Isafjordsgatan 22                  mobile: [phone] 
> > > Kista, Sweden                      email:  [e-mail] 
> > >                                             [e-mail] 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 






Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 23:15:18 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Date: Mon, 25 Jul 2005 16:13:56 -0700
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment - Issues w/ GMPLS Ethernet
Thread-Index: AcWRDY8OHVZh5WBvSbOBxtrHtj5d+wAWDnaA
From: "Ali Sajassi \(sajassi\)" <[e-mail]>
To: "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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" <[e-mail]>=20
> ?? ??: 2005-07-25 ?? 6:44:34=20
> ?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles=20
> Juergen" <[e-mail]>, "[e-mail]"=20
> <[e-mail]>=20
> ??: "[e-mail]" <[e-mail]>=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:[e-mail]]=20
> > Sent: Saturday, July 23, 2005 6:19 AM=20
> > To: Heiles Juergen; [e-mail]=20
> > Cc: [e-mail]=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" <[e-mail]>=20
> > ?? ??: 2005-07-22 ?? 10:23:43=20
> > ?? ??: "Loa Andersson" <[e-mail]>, "[e-mail]"=20
> > <[e-mail]>=20
> > ??: "[e-mail]" <[e-mail]>, "[e-mail]"=20
> > <[e-mail]>=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: [e-mail]=20
> > > [mailto:[e-mail]] On Behalf Of Loa Andersson=20
> > > Sent: Friday, July 22, 2005 2:53 PM=20
> > > To: [e-mail]=20
> > > Cc: [e-mail]; [e-mail]=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
> > > [e-mail] 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: [e-mail]=20
> > [mailto:[e-mail]]On=20
> > > >>Behalf Of Par Mattsson=20
> > > >>Sent: 22 July 2005 11:42=20
> > > >>To: Loa Andersson=20
> > > >>Cc: [e-mail]=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:  [phone]=20
> > > >>>Isafjordsgatan 22                  mobile: [phone]=20
> > > >>>Kista, Sweden                      email: =20
> > [e-mail]=20
> > > >>>                                            [e-mail]=20
> > > >>>=20
> > > >>=20
> > > >>=20
> > > >>=20
> > > >=20
> > >=20
> > >=20
> > > --=20
> > > Loa Andersson=20
> > >=20
> > > Principal Networking Architect=20
> > > Acreo AB                           phone:  [phone]=20
> > > Isafjordsgatan 22                  mobile: [phone]=20
> > > Kista, Sweden                      email:  [e-mail]=20
> > >                                             [e-mail]=20
> > >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 21:38:37 +0000
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
From: [e-mail]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
MIME-Version: 1.0
Date: Mon, 25 Jul 2005 23:37:01 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

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.





Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 19:13:14 +0000
To: Loa Andersson <[e-mail]>
Cc: [e-mail], =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: Re: dimitris question on VLAN vs label (L2SC)
Date: Mon, 25 Jul 2005 21:11:53 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmxvYSA8L0ZPTlQ+PC9QPjxQPjxGT05U
IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4tIG9rIC0ganVzdCB3YW50ZWQgdG8gYmUgc3VyZSB0
aGF0IHRoaXMgcmVxdWlyZW1lbnQgaXMgY29ycmVjdGx5IHVuZGVyc3Rvb2Q8L0ZPTlQ+PC9QPjxQ
PjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj50aGFua3MsPC9GT05UPjwvUD48UD48Rk9O
VCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+LSBkaW1pdHJpLjwvRk9OVD48QlI+PEJSPjxGT05U
IFNJWkU9Mj48Qj5Mb2EgQW5kZXJzc29uICZsdDtsb2FAcGkuc2UmZ3Q7PC9CPjwvRk9OVD48QlI+
PEZPTlQgU0laRT0yPjA3LzI1LzIwMDUgMTU6MDYgWkUyPC9GT05UPjxCUj48QlI+IDxGT05UIFNJ
WkU9Mj5Ubzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5EaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxD
QVRFTEBBTENBVEVMPC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmNjOjwvRk9OVD4gPEZPTlQgU0la
RT0yPlAmYXVtbDtyIE1hdHRzc29uICZsdDtwZXJAZGVmZXJvLnNlJmd0OywgY2NhbXBAb3BzLmll
dGYub3JnPC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0la
RT0yPlN1YmplY3Q6PC9GT05UPiA8Rk9OVCBTSVpFPTI+ZGltaXRyaXMgcXVlc3Rpb24gb24gVkxB
TiB2cyBsYWJlbCAoTDJTQyk8L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD48Rk9OVCBGQUNFPSJN
b25vc3BhY2UsQ291cmllciI+RGltaXRyaSw8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25v
c3BhY2UsQ291cmllciI+dGhlIHNpbXBsZSBhbnN3ZXIgaXMgdGhhdCBJIG5lZWQgbXkgVkxBTnMs
IHRoZXkgZ2l2ZSBtZSBhPEJSPmdvb2QsIHVuZGVyc3Rvb2QgYW5kIHJlbGlhYmxlIHNlcnZpY2Us
IGV2ZW4gd2hlbiBJIGNhbiBzZXQgdXA8QlI+TFNQIHRocm91Z2ggYW4gRXRoZXJuZXQgbmV0d29y
ay48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+QXMgSSBzZWUg
aXQgVkxBTnNkIGFuZCBMU1BzIGlzIG5vdCB0aGUgc2FtZSwgaWYgd2UgdXNlIHRoZTxCUj5WTEFO
IHRvIGVuY2Fwc3VsYXRlIExTUHMgd2UgZ2V0IGludG8gYSBwcm9ibGVtIG9mIGRpc3Rpbmd1aXNo
aW5nPEJSPmJldHdlZW4gYSBWTEFOIGFuZCBhbiBMU1AuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFD
RT0iTW9ub3NwYWNlLENvdXJpZXIiPlZMQU4gaXMgYSBzY2FyY2UgcmVzb3VyY2UsIDIwNDggcGVy
IG5ldHdvcmsgKHllYWggLSBrbm93IEkgY2FuPEJSPmluY3JlYXNlIGl0IGJ5IG1hbmFnaW5nIHRo
ZSBWTEFOIGJ1ZGdldCBjYXJlZnVsbHksIGJ1dCBpdCBpczxCUj5raW5kIG9mIGF3a3dhcmQpLiBJ
IHRoaW5rIHdlIHNob3VsZCBhaW0gZm9yIHNvbWV0aGluZyBsaWtlIDIwMDA8QlI+bGFiZWxzIHBl
ciBsaW5rIChJIHdvdWxkbid0IG9iamVjdCBpZiB3ZSBjYW4gZG8gYmV0dGVyKS48QlI+PC9GT05U
PjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SSdkIGFsc28gc2F5IHRoYXQgdGhl
IHRoZSBFdGhlcm5ldCBuZXR3b3JrIG5lZWRzIHRvIGJlIGFibGU8QlI+dG8gaGFuZGxlIGFsbCB0
eXBlcyBvZiB0cmFmZmljLCBnbXBscywgdGFnZ2VkIGFuZCB1bnRhZ2dlZDxCUj5vdmVyIHRoZSBz
YW1lIHN3dGljaC4gRG9uJ3Qgc2VlIHRoYXQgYSBpbnRlcmZhY2Ugc2VwYXJhdGlvbiB3b3VsZDxC
Uj5oZWxwIHNpbmNlIFZMQU4gYXJlIHBlciBwbGF0Zm9ybS48QlI+PC9GT05UPjxCUj48Rk9OVCBG
QUNFPSJNb25vc3BhY2UsQ291cmllciI+RGlkIEkgYW5zd2VyIHlvdXIgcXVlc3Rpb25zPzxCUj48
L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4vTG9hPEJSPjwvRk9OVD48
QlI+PEJSPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+RGltaXRyaS5QYXBhZGlt
aXRyaW91QGFsY2F0ZWwuYmUgd3JvdGU6PEJSPiZndDsgbG9hLDxCUj4mZ3Q7PEJSPiZndDsgZHVy
aW5nIHRoZSBkaXNjdXNzaW9uIGxvb3Agb25lIG9mIHRoZSBwb3NzaWJpbGl0aWVzIHRoYXQgY2Ft
ZSBvdXQ8QlI+Jmd0OyBjb25zaXN0ZWQgaW4gdXNpbmcgYSBkZWRpY2F0ZWQgVFBJRCB2YWx1ZSAo
ZGlmZmVyZW50IGZyb20gdGhlIHZhbHVlPEJSPiZndDsgMHg4MTAwIHVzZWQgaW4gLjFxKSwgdGhh
dCB3b3VsZCBwcmVjZWRlIHRoZSBlbmNvZGVkIHZhbHVlIGFzIHBhcnQgb2YgdGhlPEJSPiZndDsg
VENJPEJSPiZndDs8QlI+Jmd0OyB3b3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkgeW91ciBzcGVjaWZp
YyBjb25jZXJuID8gaSB3b3VsZCBsaWtlIGFsc28gdG88QlI+Jmd0OyBwb2ludCBvdXQgdGhhdCB0
aGVyZSBhcmUgc2V2ZXJhbCBjYXNlcyBoZXJlPEJSPiZndDs8QlI+Jmd0OyAxLiBib3RoIHR5cGUg
b2YgdHJhZmZpYyBvbiB0aGUgc2FtZSBzd2l0Y2ggYnV0IG5vdCBuZWNlc3NhcmlseSBvbiB0aGU8
QlI+Jmd0OyBzYW1lIGludGVyZmFjZTxCUj4mZ3Q7PEJSPiZndDsgMi4gYm90aCB0eXBlIG9mIHRy
YWZmaWMgb24gdGhlIHNhbWUgaW50ZXJmYWNlPEJSPiZndDs8QlI+Jmd0OyB3aXRoIHRoZSBmb2xs
b3dpbmcgdmFyaWFudDxCUj4mZ3Q7PEJSPiZndDsgMmEuIGludGVyZmFjZSBtdXN0IGFjY29tbW9k
YXRlIGFueSB0eXBlIG9mIHRyYWZmaWMgKHVuLS90YWdnZWQgYW5kIGxhYmVsZWQpPEJSPiZndDs8
QlI+Jmd0OyAyYi4gaW50ZXJmYWNlIG11c3QgYWNjb21tb2RhdGUgdGFnZ2VkIGFuZCBsYWJlbGVk
IHR5cGUgb2YgdHJhZmZpYyBvbmx5PEJSPiZndDs8QlI+Jmd0OyB0aGFua3MsPEJSPiZndDs8QlI+
Jmd0OyAtIGRpbWl0cmkuPEJSPiZndDs8QlI+Jmd0OyAqTG9hIEFuZGVyc3NvbiAmbHQ7bG9hQHBp
LnNlJmd0Oyo8QlI+Jmd0OyBTZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8QlI+Jmd0
OyAwNy8yMi8yMDA1IDEyOjA0IFpFMjxCUj4mZ3Q7PEJSPiZndDsgVG86IFAmYXVtbDtyIE1hdHRz
c29uICZsdDtwZXJAZGVmZXJvLnNlJmd0OzxCUj4mZ3Q7IGNjOiBjY2FtcEBvcHMuaWV0Zi5vcmc8
QlI+Jmd0OyBiY2M6PEJSPiZndDsgU3ViamVjdDogUmU6IEZyYW1lZm9ybWF0IGluIGEgbDJjcyBn
bXBscyBybnZpcm9ubWVudC48QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgUGVyIGFuZCBEaW1pdHJp
LDxCUj4mZ3Q7PEJSPiZndDsgSSB3b3VsZCBsaWtlIHRvIGNvbWUgZG93biBzdHJvbmdlciB0aGFu
IHRoYXQsIGZvciBtZSBpdCBpczxCUj4mZ3Q7IGEgdmVyeSBzdHJvbmcgcmVxdWlyZW1lbnQgdGhh
dCB0aGUgc2FtZSBzd2l0Y2ggY2FuIGhhbmRsZTxCUj4mZ3Q7IGJvdGggVkxBTnMgYW5kIEdNUExz
IHRyYWZpYyBjb3JyZWN0bHkuIEkgY2FuJ3QgZHNlZSBob3cgdGhhdDxCUj4mZ3Q7IGNvdWxkIGJl
IGRvbmUgaWYgdXNpbmcgdGhlIFZMQU4gdHBpZCB0byBpbmRpY2F0ZSBHTVBMUzxCUj4mZ3Q7IHRy
YWZmaWMuPEJSPiZndDs8QlI+Jmd0OyAvTG9hPEJSPiZndDs8QlI+Jmd0OyBQJmF1bWw7ciBNYXR0
c3NvbiB3cm90ZTo8QlI+Jmd0OyAmbmJzcDsmZ3Q7Jmd0O2hpIHBhciwgb25lIG9mIHRoZSBwb3Nz
aWJpbGl0aWVzIHRoYXQgaGFzIGJlZW4gY29uc2lkZXJlZCB0byBjb3BlIHdpdGg8QlI+Jmd0OyAm
bmJzcDsmZ3Q7Jmd0O3RoaXMgcmVxdWlyZW1lbnQgaXMgdG8gdXNlIGEgZGVkaWNhdGVkIFRQSUQg
Zm9yIHRoZSBFdGhlcm5ldCBsYWJlbGVkPEJSPiZndDsgJm5ic3A7Jmd0OyZndDtmcmFtZXM7IHRo
aXMgd291bGQgYWxsb3cgZGlmZmVyZW50aWF0ZWQgcHJvY2Vzc2luZyB3aXRoIG5vbi1sYWJlbGVk
PEJSPiZndDsgJm5ic3A7Jmd0OyZndDtmcmFtZXN0aGFua3MuPEJSPiZndDsgJm5ic3A7Jmd0OzxC
Uj4mZ3Q7ICZuYnNwOyZndDs8QlI+Jmd0OyAmbmJzcDsmZ3Q7IFRoYXQgc2VlbXMgdG8gbWFrZSBt
b3JlIHNlbmNlLiBJZiB0aGF0IGZyYW1lIGlzIHRvIGJlIHNpemVkIGxpa2UgYSA4MDIuMXE8QlI+
Jmd0OyAmbmJzcDsmZ3Q7IGZyYW1lLiBUaGVyZSBpcyBub3QgdGhhdCBtdWNoIHNwYWNlIGxlZnQg
dG8gYSBsYWJlbC4gT3IgaXMgdGhlIGRlbWFuZCB0bzxCUj4mZ3Q7ICZuYnNwOyZndDsgdXNlIGp1
bWJvZnJhbWVzID88QlI+Jmd0OyAmbmJzcDsmZ3Q7IEhhcyB0aGVyZSBiZWVuIGFueSBkaXNjdXNz
aW9uIG9uIGxhYmVsc3RhY2tpbmcsIGFuZCBtYWlubHkgd2hlcmUgdG8gcGxhY2U8QlI+Jmd0OyAm
bmJzcDsmZ3Q7IHRoZSBpbmZvcm1hdGlvbj88QlI+Jmd0OyAmbmJzcDsmZ3Q7PEJSPiZndDsgJm5i
c3A7Jmd0OyBSZWdhcmRzLjxCUj4mZ3Q7ICZuYnNwOyZndDsgUGVyPEJSPiZndDsgJm5ic3A7Jmd0
OzxCUj4mZ3Q7ICZuYnNwOyZndDs8QlI+Jmd0OyAmbmJzcDsmZ3Q7PEJSPiZndDs8QlI+Jmd0OzxC
Uj4mZ3Q7IC0tPEJSPiZndDsgTG9hIEFuZGVyc3NvbjxCUj4mZ3Q7PEJSPiZndDsgUHJpbmNpcGFs
IE5ldHdvcmtpbmcgQXJjaGl0ZWN0PEJSPiZndDsgQWNyZW8gQUIgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IHBob25lOiAmbmJzcDsrNDYgOCA2MzIgNzcgMTQ8QlI+Jmd0OyBJc2Fm
am9yZHNnYXRhbiAyMiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwO21vYmlsZTogKzQ2IDczOSA4MSAyMSA2NDxCUj4mZ3Q7IEtpc3Rh
LCBTd2VkZW4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2VtYWlsOiAmbmJzcDtsb2EuYW5kZXJzc29uQGFj
cmVvLnNlPEJSPiZndDs8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsb2FA
cGkuc2U8QlI+PC9GT05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0t
PEJSPkxvYSBBbmRlcnNzb248QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291
cmllciI+UHJpbmNpcGFsIE5ldHdvcmtpbmcgQXJjaGl0ZWN0PEJSPkFjcmVvIEFCICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwaG9uZTogJm5ic3A7KzQ2IDggNjMyIDc3IDE0PEJS
PklzYWZqb3Jkc2dhdGFuIDIyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bW9iaWxlOiArNDYgNzM5IDgxIDIxIDY0PEJSPktpc3Rh
LCBTd2VkZW4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2VtYWlsOiAmbmJzcDtsb2EuYW5kZXJzc29uQGFj
cmVvLnNlPC9GT05UPjwvUD48VUw+PFVMPjxVTD48VUw+PFVMPjxVTD48VUw+PFVMPjxVTD48VUw+
PFVMPjxVTD48VUw+PFVMPjxVTD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+bG9hQHBp
LnNlPC9GT05UPjwvVUw+



Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 16:18:43 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Moving LSP ownership between control plane and management plane
Date: Mon, 25 Jul 2005 18:18:11 +0200
Message-ID: <[e-mail]>
Thread-Topic: Moving LSP ownership between control plane and management plane
Thread-Index: AcWNDydF04j4tl/eRIW5sP2WNO2RbQEIyTNA
From: "MEURIC Julien RD-CORE-LAN" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>
Cc: "ccamp" <[e-mail]>

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-----
From: [e-mail] [mailto:[e-mail]] On
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 <[e-mail]>@ops.ietf.org on 20/07/2005 11.03.00

Sent by:    [e-mail]


To:    Adrian Farrel <[e-mail]>
cc:    [e-mail], Neil Harrison <[e-mail]>, Dino
       Bramanti <[e-mail]>

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).
>
>
>











Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 15:46:21 +0000
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 16:44:55 +0100
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
Thread-Index: AcWQ/aViET2i5RVMS6exO5FlWh/ssgAAKGwg
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Heiles Juergen
> Sent: 25 July 2005 10:45
> To: CHO, JAI HYUNG; Heiles Juergen; [e-mail]
> Cc: [e-mail]
> 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
> > -----Original Message-----
> > From: CHO, JAI HYUNG [mailto:[e-mail]]=20
> > Sent: Saturday, July 23, 2005 6:19 AM
> > To: Heiles Juergen; [e-mail]
> > Cc: [e-mail]
> > 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" <[e-mail]>=20
> > ?? ??: 2005-07-22 ?? 10:23:43=20
> > ?? ??: "Loa Andersson" <[e-mail]>, "[e-mail]"=20
> > <[e-mail]>=20
> > ??: "[e-mail]" <[e-mail]>, "[e-mail]"=20
> > <[e-mail]>=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: [e-mail]=20
> > > [mailto:[e-mail]] On Behalf Of Loa Andersson=20
> > > Sent: Friday, July 22, 2005 2:53 PM=20
> > > To: [e-mail]=20
> > > Cc: [e-mail]; [e-mail]=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
> > > [e-mail] 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: [e-mail]=20
> > [mailto:[e-mail]]On=20
> > > >>Behalf Of Par Mattsson=20
> > > >>Sent: 22 July 2005 11:42=20
> > > >>To: Loa Andersson=20
> > > >>Cc: [e-mail]=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:  [phone]=20
> > > >>>Isafjordsgatan 22                  mobile: [phone]=20
> > > >>>Kista, Sweden                      email: =20
> > [e-mail]=20
> > > >>>                                            [e-mail]=20
> > > >>>=20
> > > >>=20
> > > >>=20
> > > >>=20
> > > >=20
> > >=20
> > >=20
> > > --=20
> > > Loa Andersson=20
> > >=20
> > > Principal Networking Architect=20
> > > Acreo AB                           phone:  [phone]=20
> > > Isafjordsgatan 22                  mobile: [phone]=20
> > > Kista, Sweden                      email:  [e-mail]=20
> > >                                             [e-mail]=20
> > >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 14:37:03 +0000
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
thread-index: AcWRJlni+Pe0SQFSTtCL57vT0szvAQ==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: "Heiles Juergen" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
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
Message-ID: <024101c59126$59e76990$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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" <[e-mail]> 
?? ??: 2005-07-25 ?? 9:32:40 
?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen" <[e-mail]>, "[e-mail]" <[e-mail]> 
??: "[e-mail]" <[e-mail]> 
??: 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 



> -----Original Message----- 
> From: CHO, JAI HYUNG [mailto:[e-mail]] 
> Sent: Monday, July 25, 2005 1:40 PM 
> To: Heiles Juergen; [e-mail] 
> Cc: [e-mail] 
> 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? 



> 

.. 






Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 13:10:44 +0000
Message-ID: <[e-mail]>
Date: Mon, 25 Jul 2005 15:06:54 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
MIME-Version: 1.0
To:  [e-mail]
CC: =?ISO-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>,  [e-mail]
Subject: dimitris question on VLAN vs label (L2SC)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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



[e-mail] 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 <[e-mail]>*
> Sent by: [e-mail]
> 07/22/2005 12:04 ZE2
> 
> To: Pär Mattsson <[e-mail]>
> cc: [e-mail]
> 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:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
> 
>                                                                                           [e-mail]


-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 12:33:22 +0000
Message-ID: <[e-mail]>
From: Heiles Juergen <[e-mail]>
To: "CHO, JAI HYUNG" <[e-mail]>, Heiles Juergen <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 14:32:40 +0200
MIME-Version: 1.0
Content-Type: text/plain

Dear Jaihyung,

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

Regards

Juergen



> -----Original Message-----
> From: CHO, JAI HYUNG [mailto:[e-mail]] 
> Sent: Monday, July 25, 2005 1:40 PM
> To: Heiles Juergen; [e-mail]
> Cc: [e-mail]
> 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?



>

...



Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 11:58:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Mon, 25 Jul 2005 12:56:27 +0100
Message-ID: <[e-mail]>
Thread-Topic: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Thread-Index: AcWPqwVLppO1DKV4Sju5p0rdnFh0zwBYqxMA
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

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

> -----Original Message-----
> From: Tom Petch [mailto:[e-mail]]=20
> Sent: 23 July 2005 16:58
> To: Harrison,N,Neil,IKM1 R
> Cc: [e-mail]
> 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: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>;=20
> <[e-mail]>; <[e-mail]>;=20
> <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>
> 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



Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 11:39:32 +0000
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
thread-index: AcWRDY8OHVZh5WBvSbOBxtrHtj5d+w==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: "Heiles Juergen" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
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
Message-ID: <4e95c01c5910d$8f111170$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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" <[e-mail]> 
?? ??: 2005-07-25 ?? 6:44:34 
?? ??: "CHO, JAI HYUNG" <[e-mail]>, "Heiles Juergen" <[e-mail]>, "[e-mail]" <[e-mail]> 
??: "[e-mail]" <[e-mail]> 
??: 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 
 




> -----Original Message----- 
> From: CHO, JAI HYUNG [mailto:[e-mail]] 
> Sent: Saturday, July 23, 2005 6:19 AM 
> To: Heiles Juergen; [e-mail] 
> Cc: [e-mail] 
> 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" <[e-mail]> 
> ?? ??: 2005-07-22 ?? 10:23:43 
> ?? ??: "Loa Andersson" <[e-mail]>, "[e-mail]" 
> <[e-mail]> 
> ??: "[e-mail]" <[e-mail]>, "[e-mail]" 
> <[e-mail]> 
> ??: 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 
> 
> 
> > -----Original Message----- 
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Loa Andersson 
> > Sent: Friday, July 22, 2005 2:53 PM 
> > To: [e-mail] 
> > Cc: [e-mail]; [e-mail] 
> > 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 
> > 
> > [e-mail] 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 
> > > 
> > > 
> > >>-----Original Message----- 
> > >>From: [e-mail] 
> [mailto:[e-mail]]On 
> > >>Behalf Of Par Mattsson 
> > >>Sent: 22 July 2005 11:42 
> > >>To: Loa Andersson 
> > >>Cc: [e-mail] 
> > >>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:  [phone] 
> > >>>Isafjordsgatan 22                  mobile: [phone] 
> > >>>Kista, Sweden                      email:  
> [e-mail] 
> > >>>                                            [e-mail] 
> > >>> 
> > >> 
> > >> 
> > >> 
> > > 
> > 
> > 
> > -- 
> > Loa Andersson 
> > 
> > Principal Networking Architect 
> > Acreo AB                           phone:  [phone] 
> > Isafjordsgatan 22                  mobile: [phone] 
> > Kista, Sweden                      email:  [e-mail] 
> >                                             [e-mail] 
> > 
> 
> 
> 
> 






Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 10:13:32 +0000
Thread-Topic: End-to-end L2-LSP
thread-index: AcWRAaPmSrrXoDteQTejc8QSKAORQQ==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
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
Message-ID: <4e13c01c59101$a3eb7880$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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" <[e-mail]> 
?? ??: 2005-07-21 ?? 11:59:07 
?? ??: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]> 
??: 
??: 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 




-----?? ???----- 
?? ??: "[e-mail]" <[e-mail]> 
?? ??: 2005-07-21 ?? 12:09:56 
?? ??: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]> 
??: 
??: 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 

> -----Original Message----- 
> From: CHO, JAI HYUNG [mailto:[e-mail]] 
> Sent: 14 July 2005 04:24 
> To: Spencer,R,Richard,XDE73 R; [e-mail] 
> 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 :       [phone] 
> oversea: [phone] 
> fax:         [phone] 
> 
> 
> 
> 
> -----?? ???----- 
> ?? ??: "[e-mail]" <[e-mail]> 
> ?? ??: 2005-07-14 ?? 1:10:30 
> ?? ??: "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]> 
> ??: 
> ??: 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 
> 
> > -----Original Message----- 
> > From: CHO, JAI HYUNG [mailto:[e-mail]] 
> > Sent: 13 July 2005 15:14 
> > To: Spencer,R,Richard,XDE73 R; [e-mail] 
> > 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 
> >  
> > 
> > ============================================ 
> > 
> >  
> > 
> > -----?? ???----- 
> > ?? ??: "[e-mail]" <[e-mail]> 
> > ?? ??: 2005-07-13 ?? 8:53:13 
> > ?? ??: "[e-mail]" <[e-mail]>, 
> > "[e-mail]" <[e-mail]> 
> > ??: 
> > ??: 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 
> > 
> > > -----Original Message----- 
> > > From: CHO, JAI HYUNG [mailto:[e-mail]] 
> > > Sent: 12 July 2005 09:21 
> > > To: Spencer,R,Richard,XDE73 R; [e-mail] 
> > > 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 
> > > 
> > > > -----Original Message----- 
> > > > From: [e-mail] 
> > [mailto:[e-mail]]On 
> > > > Behalf Of CHO, JAI HYUNG 
> > > > Sent: 12 July 2005 01:10 
> > > > To: [e-mail] 
> > > > 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 :       [phone] 
> > > > oversea: [phone] 
> > > > fax:         [phone] 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 










Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 10:06:30 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Mon, 25 Jul 2005 11:06:07 +0100
Message-ID: <[e-mail]>
Thread-Topic: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Thread-Index: AcWPjVr8JAiKMqpSRTGCmwFxlvJM3QBcYn1w
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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



Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 10:00:02 +0000
Sensitivity: 
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
To: "<richard.spencer" <[e-mail]>
Cc: "<jaihyung" <[e-mail]>, "<ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Mon, 25 Jul 2005 11:59:27 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

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



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

Sent by:    [e-mail]


To:    <[e-mail]>
cc:    <[e-mail]>

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

> -----Original Message-----
> From: CHO, JAI HYUNG [mailto:[e-mail]]
> Sent: 23 July 2005 05:39
> To: Spencer,R,Richard,XDE73 R
> Cc: [e-mail]
> 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
>
>
> -----?? ???-----
> ?? ??: "[e-mail]" <[e-mail]>
> ?? ??: 2005-07-22 ?? 8:44:08
> ?? ??: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> ??: "[e-mail]" <[e-mail]>
> ??: 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
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On
> > Behalf Of Par Mattsson
> > Sent: 22 July 2005 11:42
> > To: Loa Andersson
> > Cc: [e-mail]
> > 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:  [phone]
> > > Isafjordsgatan 22                  mobile: [phone]
> > > Kista, Sweden                      email:  [e-mail]
> > >                                             [e-mail]
> > >
> >
> >
> >
>
>
>
>
>









Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 09:55:06 +0000
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 10:54:36 +0100
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
Thread-Index: AcWPQGv1s5h7skVjT2KlrNODX+ABpABrRlWQ
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

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

> -----Original Message-----
> From: CHO, JAI HYUNG [mailto:[e-mail]]
> Sent: 23 July 2005 05:39
> To: Spencer,R,Richard,XDE73 R
> Cc: [e-mail]
> 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
> ?? ??: "[e-mail]" <[e-mail]>=20
> ?? ??: 2005-07-22 ?? 8:44:08=20
> ?? ??: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>=20
> ??: "[e-mail]" <[e-mail]>=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: [e-mail] [mailto:[e-mail]]On=20
> > Behalf Of Par Mattsson=20
> > Sent: 22 July 2005 11:42=20
> > To: Loa Andersson=20
> > Cc: [e-mail]=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:  [phone]=20
> > > Isafjordsgatan 22                  mobile: [phone]=20
> > > Kista, Sweden                      email:  [e-mail]=20
> > >                                             [e-mail]=20
> > >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 09:45:36 +0000
Message-ID: <[e-mail]>
From: Heiles Juergen <[e-mail]>
To: "CHO, JAI HYUNG" <[e-mail]>, Heiles Juergen <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 11:44:34 +0200
MIME-Version: 1.0
Content-Type: text/plain

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
  




> -----Original Message-----
> From: CHO, JAI HYUNG [mailto:[e-mail]] 
> Sent: Saturday, July 23, 2005 6:19 AM
> To: Heiles Juergen; [e-mail]
> Cc: [e-mail]
> 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" <[e-mail]> 
> ?? ??: 2005-07-22 ?? 10:23:43 
> ?? ??: "Loa Andersson" <[e-mail]>, "[e-mail]" 
> <[e-mail]> 
> ??: "[e-mail]" <[e-mail]>, "[e-mail]" 
> <[e-mail]> 
> ??: 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 
> 
> 
> > -----Original Message----- 
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Loa Andersson 
> > Sent: Friday, July 22, 2005 2:53 PM 
> > To: [e-mail] 
> > Cc: [e-mail]; [e-mail] 
> > 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 
> > 
> > [e-mail] 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 
> > > 
> > > 
> > >>-----Original Message----- 
> > >>From: [e-mail] 
> [mailto:[e-mail]]On 
> > >>Behalf Of Par Mattsson 
> > >>Sent: 22 July 2005 11:42 
> > >>To: Loa Andersson 
> > >>Cc: [e-mail] 
> > >>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:  [phone] 
> > >>>Isafjordsgatan 22                  mobile: [phone] 
> > >>>Kista, Sweden                      email:  
> [e-mail] 
> > >>>                                            [e-mail] 
> > >>> 
> > >> 
> > >> 
> > >> 
> > > 
> > 
> > 
> > -- 
> > Loa Andersson 
> > 
> > Principal Networking Architect 
> > Acreo AB                           phone:  [phone] 
> > Isafjordsgatan 22                  mobile: [phone] 
> > Kista, Sweden                      email:  [e-mail] 
> >                                             [e-mail] 
> > 
> 
> 
> 
> 



Envelope-to: [e-mail]
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: [e-mail]
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Mon, 25 Jul 2005 11:14:45 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

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





Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 08:56:38 +0000
Message-ID: <[e-mail]>
Date: Mon, 25 Jul 2005 04:55:31 -0400
From: Bijan Jabbari <[e-mail]>
To: [e-mail], [e-mail]
Cc: Igor Bryskin <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.3)

  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 <[e-mail]>:

> 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 <[e-mail]>
>> 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
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Adrian Farrel [mailto:[e-mail]] Sent: 23 July 2005 00:08
>>>>> To: Harrison,N,Neil,IKM1 R
>>>>> Cc: [e-mail]
>>>>> 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 .
>>
>
>






Envelope-to: [e-mail]
Delivery-date: Mon, 25 Jul 2005 07:23:06 +0000
Message-ID: <[e-mail]>
From: Heiles Juergen <[e-mail]>
To: [e-mail], Heiles Juergen <[e-mail]>
Cc: Loa Andersson <[e-mail]>, Par Mattsson <[e-mail]>, [e-mail]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Mon, 25 Jul 2005 09:20:19 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C590E9.501C479C"

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: [e-mail] =
[mailto:[e-mail]]=20
Sent: Friday, July 22, 2005 4:03 PM
To: Heiles Juergen
Cc: Loa Andersson; Par Mattsson; [e-mail]
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 <[e-mail]>
Sent by: [e-mail]
07/22/2005 15:17 ZE2

To: Loa Andersson <[e-mail]>, P=E4r Mattsson <[e-mail]>
cc: [e-mail]
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




> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: Friday, July 22, 2005 12:05 PM
> To: P=E4r Mattsson
> Cc: [e-mail]
> 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:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                             [e-mail]
>


------_=_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> [e-mail] 
  [mailto:[e-mail]] <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; [e-mail]<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;[e-mail]&gt;</B></FONT><BR><FONT size=2>Sent by: 
  [e-mail]</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;[e-mail]&gt;, Pär Mattsson &lt;[e-mail]&gt;</FONT><BR><FONT 
  size=2>cc:</FONT> <FONT size=2>[e-mail]</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: 
  [e-mail]<BR>&gt; [mailto:[e-mail]] On Behalf 
  Of Loa Andersson<BR>&gt; Sent: Friday, July 22, 2005 12:05 PM<BR>&gt; To: Pär 
  Mattsson<BR>&gt; Cc: [e-mail]<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;[phone]<BR>&gt; Isafjordsgatan 22 &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;mobile: [phone]<BR>&gt; Kista, 
  Sweden &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp;email: &nbsp;[e-mail]<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
  &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 
[e-mail]<BR>&gt;</FONT></P></BLOCKQUOTE></BODY></HTML>

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



Envelope-to: [e-mail]
Delivery-date: Sun, 24 Jul 2005 23:30:30 +0000
Message-ID: <[e-mail]>
Date: Mon, 25 Jul 2005 08:28:35 +0900
From: Tomohiro Otani <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: Kenichi Nagami <[e-mail]>
Cc: [e-mail]
Subject: Re: GMPLS OSPF-TE MIB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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
>
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Sun, 24 Jul 2005 16:31:59 +0000
Message-ID: <[e-mail]>
Date: Sun, 24 Jul 2005 18:30:48 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC:  [e-mail],  [e-mail],  [e-mail],  [e-mail]
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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 <[e-mail]>
> 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
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Adrian Farrel [mailto:[e-mail]] 
>>>>Sent: 23 July 2005 00:08
>>>>To: Harrison,N,Neil,IKM1 R
>>>>Cc: [e-mail]
>>>>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 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Sun, 24 Jul 2005 15:07:35 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5xnt/2kpwuIPap+8Z5dc7hsTz55H00sc7MHWI/zlh9AL8hZGuj2EhnwS8a5PN7rnzU6gWGnGLEKg04IgB/C0ZexS6bkQeKEsYFxrzRM5xP2HIIbI8BegDFXYZlDBQJ9SZ0poI6b1gt9azwRUcFm28B/mnnYZIMJM6P3cAcSIxPM=  ;
Message-ID: <[e-mail]>
Date: Sun, 24 Jul 2005 08:05:32 -0700 (PDT)
From: Igor Bryskin <[e-mail]>
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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 <[e-mail]>
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
> >> 
> >> 
> >>
> >>-----Original Message-----
> >>From: Adrian Farrel [mailto:[e-mail]] 
> >>Sent: 23 July 2005 00:08
> >>To: Harrison,N,Neil,IKM1 R
> >>Cc: [e-mail]
> >>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 



Envelope-to: [e-mail]
Delivery-date: Sun, 24 Jul 2005 03:36:30 +0000
Message-ID: <[e-mail]>
Date: Sat, 23 Jul 2005 20:33:45 -0700
From: Arun Satyanarayana <[e-mail]>
Organization: Cisco Systems
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: [e-mail], Adrian Farrel <[e-mail]>, Kireeti Kompella <[e-mail]>
CC: Lou Berger <[e-mail]>, Dimitri Papadimitriou <[e-mail]>, Reshad Rahman <[e-mail]>, Anca Zamfir <[e-mail]>, Junaid Israr <[e-mail]>, "Arun Satyanarayana (asatyana)" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-03.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
==============================================================
[e-mail] 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 
> [e-mail] 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:
> 	[e-mail].
> 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.



Envelope-to: [e-mail]
Delivery-date: Sat, 23 Jul 2005 17:22:33 +0000
Message-ID: <014a01c58fa2$82e2c220$0601a8c0@pc6>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Sat, 23 Jul 2005 17:58:27 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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: <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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





Envelope-to: [e-mail]
Delivery-date: Sat, 23 Jul 2005 16:44:59 +0000
Message-ID: <[e-mail]>
Date: Sat, 23 Jul 2005 18:43:18 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC:  [e-mail],  [e-mail],  [e-mail]
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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
>> 
>> 
>>
>>-----Original Message-----
>>From: Adrian Farrel [mailto:[e-mail]] 
>>Sent: 23 July 2005 00:08
>>To: Harrison,N,Neil,IKM1 R
>>Cc: [e-mail]
>>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 
>  
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Sat, 23 Jul 2005 13:50:45 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1eKRLLtEVAw96DvLBpgepSNsC+ukFMe1zsbMKf9T3+X8BEBOGGhCwNSFwkDrcSScPO+CAw1YhnNJWeai/cJKfH5TNl7l1QYtJ43hTk3jMZU6JkQ4ub/8vRpR2EO7QQKUmOp/olKFRT7xgyDSq5sr8PAi7aEcCJrJUZY62KiunCc=  ;
Message-ID: <[e-mail]>
Date: Sat, 23 Jul 2005 06:49:31 -0700 (PDT)
From: Igor Bryskin <[e-mail]>
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
To: [e-mail], [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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
>  
>  
> 
> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: 23 July 2005 00:08
> To: Harrison,N,Neil,IKM1 R
> Cc: [e-mail]
> 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 
 



Envelope-to: [e-mail]
Delivery-date: Sat, 23 Jul 2005 12:16:58 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58F80.310DD9EA"
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Sat, 23 Jul 2005 13:15:19 +0100
Message-ID: <[e-mail]>
Thread-Topic: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Thread-Index: AcWPEfcioWKblWAORniGMXaBuv1+cgAX+5xA
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

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:[e-mail]]=20
Sent: 23 July 2005 00:08
To: Harrison,N,Neil,IKM1 R
Cc: [e-mail]
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:[e-mail]] <BR><B>Sent:</B> 23 July 2005 =
00:08<BR><B>To:</B>=20
  Harrison,N,Neil,IKM1 R<BR><B>Cc:</B> =
[e-mail]<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--



Envelope-to: [e-mail]
Delivery-date: Sat, 23 Jul 2005 12:16:51 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Sat, 23 Jul 2005 13:15:18 +0100
Message-ID: <[e-mail]>
Thread-Topic: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Thread-Index: AcWO6PXwNV9J9GsyTyywah8dc4SA0QAESRbgAAQtiVAAB5V/cAAVQatg
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

> > > 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



Envelope-to: [e-mail]
Delivery-date: Sat, 23 Jul 2005 10:34:23 +0000
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Sat, 23 Jul 2005 12:32:19 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPm5laWwgLSB0byBiZSBwZXJmZWN0bHkg
Y2xlYXIgLSA8L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5kdXJp
bmcgbGFzdCByb3VuZCBvZiBkaXNjdXNzaW9uIHNvbWUgaW5kaXZpZHVhbHMgc3RhcnRlZCBzcGVh
a2luZyB1c2luZyBhdXRob3JpdGF0aXZlIGFuZCBpbXBlcnNvbmFsIGFyZ3VtZW50cyBzdWNoIGFz
ICZxdW90O0V0aGVybmV0IGJlbG9uZ3MgdG8gYW5vdGhlciBTRE8gaS5lLiB0aGUgSUVFRSZxdW90
OzwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnRoZSBEVCBhbmQg
bW9zdCBwZW9wbGUgZGlzY3Vzc2luZyB0aGlzIHRocmVhZCBhcmUgcGVyZmVjdGx5IGF3YXJlIG9m
IHRoaXMgKHNlZSBzZWN0aW9uIDcuMSkgYW5kIGFsbCB3aGF0IGl0IGltcGxpZXM7IG5vdywgc3Vj
aCBlbGVtZW50IG1heSBiZSAocG90ZW50aWFsbHkpIGludGVyZmVyaW5nIGluIHRoZSBwcmVzZW50
IGRpc2N1c3Npb24gYnV0IHRoaXMgaXMgc2ltcGx5IGEgZmFjdCBmb3Igd2hpY2ggdGhlIENDQU1Q
IFdHIChpZmYgYSBjb25zZW5zdXMgaXMgZm91bmQpIGhhcyB0byBjb3BlIHdpdGg7IHRoZSBwcm9i
bGVtIHN0YXRlbWVudCBkb2N1bWVudCBoYXMgdHJpZWQgdG8gYmUgYXMgZXhwbGljaXQgYXMgcG9z
c2libGUgd2l0aCB0aGF0IHJlc3BlY3Q7IHRoaXMgc2VjdGlvbiA3LjEgc2F5cyB0aGF0IElFRUUg
d2lsbCBiZSBjb25zdWx0ZWQgYW5kIGl0cyBmZWVkYmFjayB3aWxsIGJlIGNvbnNpZGVyZWQgaWZm
IENDQU1QIGZpbmRzIGVub3VnaCBpbnRlcmVzdCBpbiBzdGFydGluZyBhIHdvcmtpbmcgaXRlbSBv
biBHTVBMUyAoSVApIGNvbnRyb2wgcGxhbmUgZm9yIEV0aGVybmV0IChiYXNlZCBvbiB0aGUgcHJv
cG9zZWQgc2NlbmFyaW9zKSBzbyBhcyB0byBzdGFydCB3b3JraW5nIG9uIHRoZSByZXF1aXJlbWVu
dHMgKGxpc3RlZCBpbiB0aGlzIGRvY3VtZW50KSBhcyBwYXJ0IG9mIHRoZSBDQ0FNUCBXRyBlZmZv
cnQgKiBidXQgd2UgYXJlIG5vdCB0aGF0IGZhciB5ZXQgKjwvRk9OVD48L1A+PFA+PEZPTlQgRkFD
RT0iTW9ub3NwYWNlLENvdXJpZXIiPmhvd2V2ZXIsIHRoaXMgYXJndW1lbnQgY2FuIG5vdCBiZSB1
c2VkIGFzIHRoZSBjb3JuZXJzdG9uZSBpbiB0aGUgcHJlc2VudCBzdGFnZSBvZiBkZWNpc2lvbiBw
cm9jZXNzIHdoaWNoIGlzIHNpbXBseSB3aGV0aGVyIENDQU1QIFdHIHdhbnRzIHRvIHdvcmsgb3Ig
bm90IG9uIGEgR01QTFMgKElQKSBjb250cm9sIHBsYW5lIGZvciBFdGhlcm5ldDsgc28sIGl0IGlz
IGluYXBwcm9wcmlhdGUgdG8gYXJndWUgZnJvbSB0aGUgQ0NBTVAgcGVyc3BlY3RpdmUgYnkgbWFr
aW5nIHVzZSBvZiB0aGUgcG90ZW50aWFsIHJlYWN0aW9uKHMpIG9mIHRoZSBJRUVFLCBpbiBwYXJ0
aWN1bGFyLCBrbm93aW5nIHRoZXJlIGlzIG5vIGludGVudGlvbiB0byBpbml0aWF0ZSBhIHdvcmsg
aXRlbSBvbiBFdGhlcm5ldCBkYXRhIHBsYW5lICZuYnNwOzwvRk9OVD48QlI+PEJSPjxGT05UIFNJ
WkU9Mj48Qj4mbHQ7bmVpbC4yLmhhcnJpc29uQGJ0LmNvbSZndDs8L0I+PC9GT05UPjxCUj48Rk9O
VCBTSVpFPTI+U2VudCBieTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTI+MDcvMjIvMjAwNSAyMToxMTwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86
PC9GT05UPiA8Rk9OVCBTSVpFPTI+RGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxD
QVRFTCwgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7PC9GT05UPjxCUj4gPEZPTlQgU0laRT0y
PmNjOjwvRk9OVD4gPEZPTlQgU0laRT0yPiZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PC9GT05U
PjxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1YmplY3Q6
PC9GT05UPiA8Rk9OVCBTSVpFPTI+UkU6IEZyYW1lZm9ybWF0IGluIGEgbDJjcyBnbXBscyBybnZp
cm9ubWVudC48L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD5EaW1pdHJpLCZuYnNwOyA8QlI+PEJS
PldoYXQgZG8geW91IG1lYW4gYnkgJ2ludGVyZmVycmluZyBlbGVtZW50cycuLi4uLnRoaXMgc291
bmRzIGxpa2Ugc29tZSAnYmVoaW5kIGNsb3NlZCBkb29ycyBzZWN0JyBhdCB3b3JrLiZuYnNwOyBJ
IHRob3VnaHQgQWRyaWFuJ3MgcG9zdCB3YXMgKGFzIHVzdWFsKSBwbGFpbi9jbGVhciBhcyB0byBp
bnRlbnQuPEJSPjxCUj5yZWdhcmRzLCBOZWlsPEJSPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
PEJSPjxCPkZyb206PC9CPiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci1j
Y2FtcEBvcHMuaWV0Zi5vcmddIDxCPk9uIEJlaGFsZiBPZiA8L0I+RGltaXRyaS5QYXBhZGltaXRy
aW91QGFsY2F0ZWwuYmU8QlI+PEI+U2VudDo8L0I+IDIyIEp1bHkgMjAwNSAxNjo1MTxCUj48Qj5U
bzo8L0I+IEFkcmlhbiBGYXJyZWw8QlI+PEI+Q2M6PC9CPiBEaW1pdHJpLlBhcGFkaW1pdHJpb3VA
YWxjYXRlbC5iZTsgY2NhbXBAb3BzLmlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogRnJh
bWVmb3JtYXQgaW4gYSBsMmNzIGdtcGxzIHJudmlyb25tZW50LjxCUj48QlI+PEJSPjxCUj48Rk9O
VCBTSVpFPTQ+YWRyaWFuIC0gb2sgbXVjaCB0aGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uIC0g
PC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00Pmkgd2FudGVkIHRvIGJlIHN1cmUgdGhhdCB0aGUg
d29ya2luZyBncm91cCBjb25zZW5zdXMgaXMgZ29pbmcgdG8gYmUgdGhlIGVsZW1lbnQgb2YgZGVj
aXNpb24gZm9yIHB1dHRpbmcgdGhpcyBpdGVtIGluIHRoZSB3b3JraW5nIGxpc3QgLSBhbmQgd2Ug
d29uJ3QgaGF2ZSBvdGhlciBpbnRlcmZlcmluZyBlbGVtZW50cyBpbiB0aGUgZGVjaXNpb24gcHJv
Y2VzcyAtIDwvRk9OVD48QlI+PEJSPjxCPiZxdW90O0FkcmlhbiBGYXJyZWwmcXVvdDsgJmx0O2Fk
cmlhbkBvbGRkb2cuY28udWsmZ3Q7PC9CPjxCUj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0
Zi5vcmc8QlI+MDcvMjIvMjAwNSAxNjowODxCUj5QbGVhc2UgcmVzcG9uZCB0byAmcXVvdDtBZHJp
YW4gRmFycmVsJnF1b3Q7PEJSPjxCUj5Ubzo8Rk9OVCBTSVpFPTQ+IDwvRk9OVD5EaW1pdHJpIFBB
UEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMPEJSPmNjOjxGT05UIFNJWkU9ND4gPC9GT05U
PiZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PEJSPmJjYzo8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48
QlI+U3ViamVjdDo8Rk9OVCBTSVpFPTQ+IDwvRk9OVD5SZTogRnJhbWVmb3JtYXQgaW4gYSBsMmNz
IGdtcGxzIHJudmlyb25tZW50LjxCUj48QlI+PEJSPjxGT05UIFNJWkU9ND5EaW1pdHJpLDwvRk9O
VD48QlI+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IHdoYXQgZG8geW91IEVYQUNUTFkgbWVhbiB3aXRo
IHRoZSBmb2xsb3dpbmcgc2VudGVuY2U8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7PC9GT05U
PjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmcXVvdDtUaGlzIHF1ZXN0aW9uIGlzIG9uZSB3ZSBtdXN0
IGNvbWUgdG8gYXMgc29vbiBhcyB3ZSBhcmUgY29uZmlkZW50IHRoYXQ8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND50aGU8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IHJlcXVpcmVtZW50cyBuZWVk
IHRvIGJlIGFkZHJlc3NlZCBhdCBhbGwuJnF1b3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgcGxlYXNlIGNsYXJpZnkgLSBidHcgd2hvIGlz
ICZxdW90O3dlJnF1b3Q7IGluIHRoaXMgY29udGV4dCA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpF
PTQ+JnF1b3Q7V2UmcXVvdDsgbWVhbnMgJnF1b3Q7dGhlIENDQU1QIHdvcmtpbmcgZ3JvdXAmcXVv
dDs8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyB0aGlzIHNlbnRlbmNlIHJlYWRzIHRv
IG1lIGFzICZxdW90O0NDQU1QIGhhcyBub3QgeWV0IGNvbW1pdHRlZCB0byB3b3JrIG9uPC9GT05U
PjxCUj48Rk9OVCBTSVpFPTQ+dGhpczwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgdG9waWMm
cXVvdDsgaXMgbXkgcmVhZGluZyBjb3JyZWN0ID8gb3IgZG8geW91IG1lYW4gc29tZXRoaW5nIGVs
c2Ugd2l0aCB0aGlzIDwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND5Zb3VyIHJlYWRpbmcgaXMg
ZXhhY3RseSBjb3JyZWN0IGFzIHN0YXRlZC48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5JIHJlZmVy
IHlvdSB0byB5b3VyIGVtYWlsIHRvIHRoZSBsaXN0IG9uIDE5dGggSnVseS4gWW91IGFza2VkLi4u
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAtIGlmIHllcywgaXMgdGhlIGludGVyZXN0IGlu
IEdNUExTIGZvciBFdGhlcm5ldCBpbi0vb3V0LXNpZGUgdGhlPC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQ+Jmd0OyAmbmJzcDsgQ0NBTVAgV0cgY29tbXVuaXR5IHN0cm9uZyBlbm91Z2ggdG8gY29uc2lk
ZXIgdGhlIGNvcnIuIEdNUExTPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmbmJzcDsgc2ln
bmFsaW5nIGFuZCByb3V0aW5nIHJlcXVpcmVtZW50cyAoc2Vjb25kIHBhcnQgb2YgdGhlIGRvY3Vt
ZW50KTwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJm5ic3A7IGFzIHBhcnQgb2YgdGhlIEND
QU1QIFdHIGVmZm9ydCA/PC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PlRodXMsIHRoZSBwdXJw
b3NlIG9mIHRoZSBJLUQgd2FzIHRvIGNyeXN0YWxpemUgdGhlIGF1dGhvcnMnIHRob3VnaHRzIG9u
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+R01QTFMgY29udHJvbCBvZiBFdGhlcm5ldCBzd2l0Y2hp
bmcgYW5kIHRvIGluaXRpYXRlIGRpc2N1c3Npb24gb24gd2hldGhlcjwvRk9OVD48QlI+PEZPTlQg
U0laRT00PnRoZSBwcm9wb3NlZCBkZXBsb3ltZW50IG1vZGVscyBhcmUgcmVhbGlzdGljIGFuZCBk
ZXNpcmFibGUuIEZvbGxvd2luZyBhPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+cG9zaXRpdmUgYW5z
d2VyIGFuZCBhc3N1bWluZyBzdXBwb3J0IChieSBDQ0FNUCkgZm9yIHRoZSBkb2luZyB0aGUgd29y
ayAoaW48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5DQ0FNUCkgYWxsIHRoYXQgcmVtYWlucyBpcyB0
byBhZGQgdGhlIHdvcmsgdG8gdGhlIGNoYXJ0ZXIgKHNlZSBwcmV2aW91czwvRk9OVD48QlI+PEZP
TlQgU0laRT00PmNoYXJ0ZXIgZGlzY3Vzc2lvbnMpIGFuZCBnZXQgb24gd2l0aCBpdC48L0ZPTlQ+
PEJSPjxCUj48Rk9OVCBTSVpFPTQ+VGhhbmtzLDwvRk9OVD48QlI+PEZPTlQgU0laRT00PkFkcmlh
bjwvRk9OVD48QlI+PC9QPg==



Envelope-to: [e-mail]
Delivery-date: Sat, 23 Jul 2005 04:37:47 +0000
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
thread-index: AcWPQGv1s5h7skVjT2KlrNODX+ABpA==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
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
Message-ID: <4280a01c58f40$6bf849c0$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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
 

-----?? ???----- 
?? ??: "[e-mail]" <[e-mail]> 
?? ??: 2005-07-22 ?? 8:44:08 
?? ??: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]> 
??: "[e-mail]" <[e-mail]> 
??: 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 

> -----Original Message----- 
> From: [e-mail] [mailto:[e-mail]]On 
> Behalf Of Par Mattsson 
> Sent: 22 July 2005 11:42 
> To: Loa Andersson 
> Cc: [e-mail] 
> 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:  [phone] 
> > Isafjordsgatan 22                  mobile: [phone] 
> > Kista, Sweden                      email:  [e-mail] 
> >                                             [e-mail] 
> > 
> 
> 
> 







Envelope-to: [e-mail]
Delivery-date: Sat, 23 Jul 2005 04:20:01 +0000
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
thread-index: AcWPPbTjX+0i5VMGS12b9FL9kHYtdQ==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: "Heiles Juergen" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
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
Message-ID: <427a201c58f3d$b4e59910$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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" <[e-mail]> 
?? ??: 2005-07-22 ?? 10:23:43 
?? ??: "Loa Andersson" <[e-mail]>, "[e-mail]" <[e-mail]> 
??: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]> 
??: 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 


> -----Original Message----- 
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Loa Andersson 
> Sent: Friday, July 22, 2005 2:53 PM 
> To: [e-mail] 
> Cc: [e-mail]; [e-mail] 
> 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 
> 
> [e-mail] 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 
> > 
> > 
> >>-----Original Message----- 
> >>From: [e-mail] [mailto:[e-mail]]On 
> >>Behalf Of Par Mattsson 
> >>Sent: 22 July 2005 11:42 
> >>To: Loa Andersson 
> >>Cc: [e-mail] 
> >>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:  [phone] 
> >>>Isafjordsgatan 22                  mobile: [phone] 
> >>>Kista, Sweden                      email:  [e-mail] 
> >>>                                            [e-mail] 
> >>> 
> >> 
> >> 
> >> 
> > 
> 
> 
> -- 
> Loa Andersson 
> 
> Principal Networking Architect 
> Acreo AB                           phone:  [phone] 
> Isafjordsgatan 22                  mobile: [phone] 
> Kista, Sweden                      email:  [e-mail] 
>                                             [e-mail] 
> 







Envelope-to: [e-mail]
Delivery-date: Sat, 23 Jul 2005 01:58:17 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Fri, 22 Jul 2005 18:55:51 -0700
Message-ID: <[e-mail]>
Thread-Topic: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Thread-Index: AcWO6PXwNV9J9GsyTyywah8dc4SA0QAESRbgAAQtiVAAB5V/cA==
From: "Drake, John E" <[e-mail]>
To: "Drake, John E" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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.





Envelope-to: [e-mail]
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
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA403315037@zrtphxm2>
Thread-Topic: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Thread-Index: AcWPEjVr/Qfq0W46QTOtTRYscPoclQAB4g/gAACM/WA=
From: "Don Fedyk" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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: [e-mail] 
>[mailto:[e-mail]] 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>




Envelope-to: [e-mail]
Delivery-date: Sat, 23 Jul 2005 00:03:56 +0000
Message-ID: <01f801c58f1a$2adaa120$b7849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Sat, 23 Jul 2005 01:04:18 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F1_01C58F22.73B35600"

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

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: 22 July 2005 19:13
> To: Spencer,R,Richard,XDE73 R; [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]
> 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: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>
> 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
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On
> > Behalf Of Heiles Juergen
> > Sent: 22 July 2005 14:17
> > To: Loa Andersson; P=E4r Mattsson
> > Cc: [e-mail]
> > 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
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Loa Andersson
> > > Sent: Friday, July 22, 2005 12:05 PM
> > > To: P=E4r Mattsson
> > > Cc: [e-mail]
> > > 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:  [phone]
> > > Isafjordsgatan 22                  mobile: [phone]
> > > Kista, Sweden                      email:  [e-mail]
> > >                                             [e-mail]
> > >
> >
> >
>=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:[e-mail]]<BR>&gt; Sent: 22 July =
2005=20
19:13<BR>&gt; To: Spencer,R,Richard,XDE73 R; </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>;=20
</FONT><A href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier size=3D2>;<BR>&gt; =
</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT face=3DCourier size=3D2>&gt; =
Cc: </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</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:[e-mail]"><FONT =
face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;<BR>&gt;=20
To: &lt;</FONT><A href=3D"mailto:[e-mail]"><FONT =
face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;;=20
&lt;</FONT><A href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier size=3D2>&gt;; =
&lt;</FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;<BR>&gt; Cc:=20
&lt;</FONT><A href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>=20
[mailto:[e-mail]]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:[e-mail]"><FONT=20
face=3DCourier size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</FONT></A><BR><FONT face=3DCourier =
size=3D2>&gt;=20
&gt; &gt; [mailto:[e-mail]] 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:[e-mail]"><FONT=20
face=3DCourier size=3D2>[e-mail]</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; [phone]<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: [phone]<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:[e-mail]"><FONT =
face=3DCourier=20
size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</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--




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 23:43:46 +0000
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Sat, 23 Jul 2005 00:42:33 +0100
Message-ID: <[e-mail]>
Thread-Topic: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Thread-Index: AcWO6LXPpMoDbQdjRGKKAn7jG/1uNgAKDu4A
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: 22 July 2005 19:13
> To: Spencer,R,Richard,XDE73 R; [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]
> 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: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>
> 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
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On
> > Behalf Of Heiles Juergen
> > Sent: 22 July 2005 14:17
> > To: Loa Andersson; P=E4r Mattsson
> > Cc: [e-mail]
> > 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
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Loa Andersson
> > > Sent: Friday, July 22, 2005 12:05 PM
> > > To: P=E4r Mattsson
> > > Cc: [e-mail]
> > > 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:  [phone]
> > > Isafjordsgatan 22                  mobile: [phone]
> > > Kista, Sweden                      email:  [e-mail]
> > >                                             [e-mail]
> > >
> >
> >
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 23:23:08 +0000
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
From: [e-mail]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
MIME-Version: 1.0
Date: Sat, 23 Jul 2005 01:21:55 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

[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."





Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 23:08:50 +0000
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Sat, 23 Jul 2005 01:03:11 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPm5laWwgLSA8L0ZPTlQ+PC9QPjxQPjxG
T05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj50aGUgaW50cm9kdWN0aW9uIG9mIHRoZSBkb2N1
bWVudCB1bmRlciBkaXNjdXNzaW9uIHByb3ZpZGVzIGEgY2xlYXIgZGVzY3JpcHRpb24gb24gdGhl
IHBvc2l0aW9uaW5nIG9mIHRoaXMgd29yayB3cnQgdG8gUFcvTVBMUyA8L0ZPTlQ+PC9QPjxQPjxG
T05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5zbyBpIGRvIG5vIG5lY2Vzc2FyaWx5IGZvbGxv
dyB5b3VyIGFyZ3VtZW50cyAoaWYgYW55KSB3aGVuIHlvdSBhcmUgZGlncmVzc2luZyBvbiBQVy9N
UExTIDwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9Mj48Qj4mbHQ7bmVpbC4yLmhhcnJpc29uQGJ0
LmNvbSZndDs8L0I+PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+MDcvMjIvMjAwNSAyMjoyMjwvRk9O
VD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+Jmx0O0Jlbi5N
YWNrLUNyYW5lQHRlbGxhYnMuY29tJmd0OywgJmx0O2licnlza2luQG1vdmF6LmNvbSZndDssIERp
bWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUw8L0ZPTlQ+PEJSPiA8Rk9OVCBT
SVpFPTI+Y2M6PC9GT05UPiA8Rk9OVCBTSVpFPTI+Jmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7
LCAmbHQ7cGVyQGRlZmVyby5zZSZndDssICZsdDtsb2FAcGkuc2UmZ3Q7LCAmbHQ7Y2NhbXBAb3Bz
LmlldGYub3JnJmd0OzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxG
T05UIFNJWkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZPTlQgU0laRT0yPlJFOiBGcmFtZWZvcm1hdCBp
biBhIGwyY3MgZ21wbHMgcm52aXJvbm1lbnQuPC9GT05UPjxCUj4gPEJSPjxCUj48L1A+PFA+QW5k
IG1lIHRvbyBCZW4vSWdvci4mbmJzcDsgQnV0IGdvIGxvb2sgYXQgTVBMUyB3aGVuIGZvbGtzIERJ
RCBkZWZpbmUgYSBkYXRhLXBsYW5lIGhlcmUuLi4uZG9uJ3QgYW55b25lIGRhcmUgdGVsbCBtZSAn
dGhpcyBpcyBnb29kJyAob3IgdGhlIFBXIHN0dWZmIGl0IHNwYXduZWQpIGJlY2F1c2UgSSBrbm93
IG90aGVyd2lzZS48QlI+PEJSPnJlcWFyZHMsIE5laWw8QlI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08QlI+PEI+RnJvbTo8L0I+IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93
bmVyLWNjYW1wQG9wcy5pZXRmLm9yZ10gPEI+T24gQmVoYWxmIE9mIDwvQj5NYWNrLUNyYW5lLCBU
LiBCZW5qYW1pbjxCUj48Qj5TZW50OjwvQj4gMjIgSnVseSAyMDA1IDE5OjI1PEJSPjxCPlRvOjwv
Qj4gSWdvciBCcnlza2luOyBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZTxCUj48Qj5D
Yzo8L0I+IEFkcmlhbiBGYXJyZWw7IFAmYXVtbDtyIE1hdHRzc29uOyBMb2EgQW5kZXJzc29uOyBj
Y2FtcEBvcHMuaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFJFOiBGcmFtZWZvcm1hdCBpbiBh
IGwyY3MgZ21wbHMgcm52aXJvbm1lbnQuPEJSPjxCUj48QlI+SWdvciw8QlI+PEJSPkksIHRvbywg
YW0gYmFmZmxlZCBieSB0aGUgbm90aW9uIG9mIHJlcXVpcmVtZW50cyBmb3IgY29udHJvbCBvZiBh
biB1bnNwZWNpZmllZCBkYXRhIHBsYW5lLjxCUj48QlI+UmVnYXJkcyw8QlI+QmVuPEJSPjxIUiBX
SURUSD0iOTklIiBTSVpFPSI0IiBBTElHTj0ibGVmdCI+PEZPTlQgQ09MT1I9QkxBQ0s+PEJSPjxC
PkZyb206PC9CPiBJZ29yIEJyeXNraW4gW21haWx0bzppYnJ5c2tpbkBtb3Zhei5jb21dIDxCUj48
Qj5TZW50OjwvQj4gRnJpZGF5LCBKdWx5IDIyLCAyMDA1IDEyOjIwIFBNPEJSPjxCPlRvOjwvQj4g
RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmU8QlI+PEI+Q2M6PC9CPiBNYWNrLUNyYW5l
LCBULiBCZW5qYW1pbjsgQWRyaWFuIEZhcnJlbDsgUCZhdW1sO3IgTWF0dHNzb247IExvYSBBbmRl
cnNzb247IGNjYW1wQG9wcy5pZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IEZyYW1lZm9y
bWF0IGluIGEgbDJjcyBnbXBscyBybnZpcm9ubWVudC48QlI+PEJSPkRpbWl0cmksPEJSPjxCUj5U
aGUgcXVlc3Rpb24gaXMgc2ltcGxlOiBpcyBpdCBwb3NzaWJsZSB0b2RheSB0byBzdGF0aWNhbGx5
IHByb3Zpc2lvbiBMMkxTUHMgdGhhdCBjb3VsZCwgc2F5LCZuYnNwO3N1cHBvcnQgZTJlIFFvUz8g
SWYgbm90LCBtYXkgYmUgaXQgaXMgdG8gZWFybHkgdG8gZGlzY3VzcyBhc3BlY3RzIG9mIGR5bmFt
aWMgcHJvdmlzaW9uaW5nIG9mIHN1Y2ggTFNQcz8gSXMgaXQgcG9zc2libGUvcmVhc29uYWJsZSwg
aW4geW91ciBvcGluaW9uLCB0byAmcXVvdDs8L0ZPTlQ+PEZPTlQgU0laRT00PmRldGFpbCBob3cg
Zm9yd2FyZGluZyBpbmZvcm1hdGlvbiBjYW4gYmUgZXhjaGFuZ2VkIHZpYSB0aGUgY29udHJvbCBw
bGFuZSAoYW5kIHRoZW4gaW5zdGFsbGVkKSZxdW90OyB3aXRob3V0Jm5ic3A7aGF2aW5nIGluIG1p
bmQgJnF1b3Q7YSBzcGVjaWZpYyBmb3J3YXJkaW5nIGJlaGF2aW9yJnF1b3Q7PzwvRk9OVD48QlI+
PEZPTlQgU0laRT00PkhvdyBkbyB5b3Uga25vdyB3aGljaCBmb3J3YXJkaW5nIGluZm9ybWF0aW9u
IGlzIG5lZWRlZCBmb3IgdGhlIGZvcndhcmRpbmcgbm9ib2R5IGhhcyBkZWZpbmVkIHlldD88L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND5UaGUgb3RoZXIgcXVlc3Rpb24gaXMmbmJzcDtkbyB3ZSBuZWVk
IGF0IGFsbCBlMmUgUW9TLCByb3V0ZSBjb250cm9sLCBmYXN0IHJlY292ZXJ5PyBTb3VuZHMgbGlr
ZSBleGNpdGluZyBpZGVhLCBidXQgZG9lcyBhbGwgdGhhdCBjb21tZXJjaWFsbHkgbWFrZSBzZW5z
ZT8gU28sIEkgZ3Vlc3MsIHdlIG5lZWQgdHdvIHRoaW5ncyZuYnNwO2JlZm9yZSB3ZSBjYW4mbmJz
cDttb3ZlIGZvcndhcmQ6PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+YSkgdmFsaWRhdGlvbiBvZiB0
aGUgaWRlYSBieSB0aGUgcHJvdmlkZXJzOzwvRk9OVD48QlI+PEZPTlQgU0laRT00PmIpIGRlZmlu
aXRpb24gb2YgdGhlIGRhdGEgcGxhbmUgYmVoYXZpb3I7PC9GT05UPjxCUj48QlI+PEZPTlQgU0la
RT00Pklnb3I8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t
LS0tIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PjxCPkZyb206PC9CPiA8L0ZPTlQ+PEZPTlQgU0la
RT00IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86RGltaXRyaS5QYXBhZGltaXRyaW91QGFs
Y2F0ZWwuYmU+RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmU8L0E+PC9VPjwvRk9OVD48
Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PjxCPlRvOjwv
Qj4gPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOmlicnlz
a2luQG1vdmF6LmNvbT5JZ29yIEJyeXNraW48L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTQgQ09M
T1I9QkxBQ0s+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PjxCPkNjOjwvQj4gPC9GT05UPjxGT05U
IFNJWkU9NCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOkJlbi5NYWNrLUNyYW5lQHRlbGxh
YnMuY29tPk1hY2stQ3JhbmUsIFQuIEJlbmphbWluPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0laRT00
IENPTE9SPUJMQUNLPiA7IDwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxVRT48VT48QSBIUkVG
PW1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPkFkcmlhbiBGYXJyZWw8L0E+PC9VPjwvRk9OVD48
Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDsgPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVF
PjxVPjxBIEhSRUY9bWFpbHRvOnBlckBkZWZlcm8uc2U+UCZhdW1sO3IgTWF0dHNzb248L0E+PC9V
PjwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDsgPC9GT05UPjxGT05UIFNJWkU9NCBD
T0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOmxvYUBwaS5zZT5Mb2EgQW5kZXJzc29uPC9BPjwv
VT48L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMQUNLPiA7IDwvRk9OVD48Rk9OVCBTSVpFPTQg
Q09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpjY2FtcEBvcHMuaWV0Zi5vcmc+Y2NhbXBAb3Bz
LmlldGYub3JnPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMQUNLPiA8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND48Qj5TZW50OjwvQj4gRnJpZGF5LCBKdWx5IDIyLCAyMDA1IDEyOjIx
IFBNPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+PEI+U3ViamVjdDo8L0I+IFJlOiBGcmFtZWZvcm1h
dCBpbiBhIGwyY3MgZ21wbHMgcm52aXJvbm1lbnQuPC9GT05UPjxCUj48QlI+PEJSPjxGT05UIFNJ
WkU9ND5pZ29yIC0gaSBhbSBub3Qgc3VyZSB3aGljaCBwb2ludCB0aGV5IGV4YWN0bHkgaGF2ZSAt
IHRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gZGV0YWlsIGhvdyBmb3J3YXJkaW5n
IGluZm9ybWF0aW9uIGNhbiBiZSBleGNoYW5nZWQgdmlhIHRoZSBjb250cm9sIHBsYW5lIChhbmQg
dGhlbiBpbnN0YWxsZWQpIG5vdCB0byBkZWZpbmUgYSBzcGVjaWZpYyBmb3J3YXJkaW5nIGJlaGF2
aW91cjwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND50aGFua3MsPC9GT05UPjxCUj48QlI+PEZP
TlQgU0laRT00Pi0gZGltaXRyaS48L0ZPTlQ+PEJSPjxCUj48Qj4mcXVvdDtJZ29yIEJyeXNraW4m
cXVvdDsgJmx0OzwvQj48Rk9OVCBDT0xPUj1CTFVFPjxCPjxVPjxBIEhSRUY9bWFpbHRvOmlicnlz
a2luQG1vdmF6LmNvbT5pYnJ5c2tpbkBtb3Zhei5jb208L0E+PC9VPjwvQj48L0ZPTlQ+PEZPTlQg
Q09MT1I9QkxBQ0s+PEI+Jmd0OzwvQj48QlI+U2VudCBieTogPC9GT05UPjxGT05UIENPTE9SPUJM
VUU+PFU+PEEgSFJFRj1tYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnPm93bmVyLWNjYW1w
QG9wcy5pZXRmLm9yZzwvQT48L1U+PC9GT05UPjxGT05UIENPTE9SPUJMQUNLPjxCUj4wNy8yMi8y
MDA1IDExOjEwIEFTVDxCUj48QlI+VG86PC9GT05UPjxGT05UIFNJWkU9ND4gPC9GT05UPiZxdW90
O01hY2stQ3JhbmUsIFQuIEJlbmphbWluJnF1b3Q7ICZsdDs8Rk9OVCBDT0xPUj1CTFVFPjxVPjxB
IEhSRUY9bWFpbHRvOkJlbi5NYWNrLUNyYW5lQHRlbGxhYnMuY29tPkJlbi5NYWNrLUNyYW5lQHRl
bGxhYnMuY29tPC9BPjwvVT48L0ZPTlQ+PEZPTlQgQ09MT1I9QkxBQ0s+Jmd0OywgJnF1b3Q7QWRy
aWFuIEZhcnJlbCZxdW90OyAmbHQ7PC9GT05UPjxGT05UIENPTE9SPUJMVUU+PFU+PEEgSFJFRj1t
YWlsdG86YWRyaWFuQG9sZGRvZy5jby51az5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9BPjwvVT48L0ZP
TlQ+PEZPTlQgQ09MT1I9QkxBQ0s+Jmd0OywgUCZhdW1sO3IgTWF0dHNzb24gJmx0OzwvRk9OVD48
Rk9OVCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOnBlckBkZWZlcm8uc2U+cGVyQGRlZmVy
by5zZTwvQT48L1U+PC9GT05UPjxGT05UIENPTE9SPUJMQUNLPiZndDssICZxdW90O0xvYSBBbmRl
cnNzb24mcXVvdDsgJmx0OzwvRk9OVD48Rk9OVCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRv
OmxvYUBwaS5zZT5sb2FAcGkuc2U8L0E+PC9VPjwvRk9OVD48Rk9OVCBDT0xPUj1CTEFDSz4mZ3Q7
PEJSPmNjOjwvRk9OVD48Rk9OVCBTSVpFPTQ+IDwvRk9OVD4mbHQ7PEZPTlQgQ09MT1I9QkxVRT48
VT48QSBIUkVGPW1haWx0bzpjY2FtcEBvcHMuaWV0Zi5vcmc+Y2NhbXBAb3BzLmlldGYub3JnPC9B
PjwvVT48L0ZPTlQ+PEZPTlQgQ09MT1I9QkxBQ0s+Jmd0OzxCUj5iY2M6PC9GT05UPjxGT05UIFNJ
WkU9ND4gPC9GT05UPjxCUj5TdWJqZWN0OjxGT05UIFNJWkU9ND4gPC9GT05UPlJlOiBGcmFtZWZv
cm1hdCBpbiBhIGwyY3MgZ21wbHMgcm52aXJvbm1lbnQuPEJSPjxCUj48QlI+PEZPTlQgU0laRT00
PkhpLDwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND5JIHRoaW5rIEJlbiBhbmQgSnVlcmdlbiBo
YXZlIGEgcG9pbnQgaGVyZS4gVGhlcmUgaXMgbm90aGluZyB0aGF0IGNvdWxkIGJlIGR5bmFtaWNh
bGx5IHByb3Zpc2lvbmVkIHRoYXQgY291bGQgbm90IGJlIGFsc28gcHJvdmlzaW9uZWQgYnkgbWFu
YWdlbWVudC4gSW4gb3RoZXIgd29yZHMgZGF0YSBwbGFuZSBpcyB0aGUgS2luZyBoZXJlLiBXZSBu
ZWVkIGRhdGEgcGxhbmUgc3RhbmRhcmQocykgb24gaG93IHdlIGVuY29kZSBhIGxhYmVsLCB3aGV0
aGVyIHdlIG5lZWQgYSBsYWJlbCBzdGFjayBvciBub3QsIGhvdyB0aGUgbGFiZWxlZCB0cmFmZmlj
IGlzIHN1cHBvc2VkIHRvIGJlJm5ic3A7dHJlYXRlZCwgaG93IGxhYmVsZWQgdHJhZmZpYyBjby1l
eGlzdCB3aXRoIG5vbi1sYWJlbCB0cmFmZmljLCBldGMuIFRoaXMgaXMgc29tZXRoaW5nIHRoYXQg
bm90IGZvciBDQ0FNUCB0byBkZWZpbmUuIFRha2UgZm9yIGV4YW1wbGUgVERNIG5ldHdvcmtzLiBH
TVBMUyBvbmx5IHByb3ZpZGVzIGEgd2F5IHRvIGR5bmFtaWNhbGx5IHByb3Zpc2lvbiBHLjcwNyBu
ZXR3b3Jrcy4gSGVuY2UgdGhlcmUgaXMgYSBuZWVkIGluIHBhcmFsbGVsIHN0YW5kYXJkaXphdGlv
biBhY3Rpdml0aWVzIGluIElUVS4gT25seSBhZnRlciB0aGF0IHdlIGNhbiBkaXNjdXNzIGhvdyBh
bGwgdGhhdCBjb3VsZCBiZSBkeW5hbWljYWxseSBwcm92aXNpb25lZCwgdGhhdCBpcyB0aGUgYXNw
ZWN0cyBvZiBjb250cm9sIHBsYW5lLiA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+SWdvcjwv
Rk9OVD48QlI+PEZPTlQgU0laRT01Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9GT05U
PjxCUj48Rk9OVCBTSVpFPTU+PEI+RnJvbTo8L0I+IDwvRk9OVD48Rk9OVCBTSVpFPTUgQ09MT1I9
QkxVRT48VT48QSBIUkVGPW1haWx0bzpCZW4uTWFjay1DcmFuZUB0ZWxsYWJzLmNvbT5NYWNrLUNy
YW5lLCBULiBCZW5qYW1pbjwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NSBDT0xPUj1CTEFDSz4g
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+PEI+VG86PC9CPiA8L0ZPTlQ+PEZPTlQgU0laRT01IENP
TE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az5BZHJpYW4gRmFy
cmVsPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0laRT01IENPTE9SPUJMQUNLPiA7IDwvRk9OVD48Rk9O
VCBTSVpFPTUgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpwZXJAZGVmZXJvLnNlPlAmYXVt
bDtyIE1hdHRzc29uPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0laRT01IENPTE9SPUJMQUNLPiA7IDwv
Rk9OVD48Rk9OVCBTSVpFPTUgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpsb2FAcGkuc2U+
TG9hIEFuZGVyc3NvbjwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NSBDT0xPUj1CTEFDSz4gPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTU+PEI+Q2M6PC9CPiA8L0ZPTlQ+PEZPTlQgU0laRT01IENPTE9S
PUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86Y2NhbXBAb3BzLmlldGYub3JnPmNjYW1wQG9wcy5pZXRm
Lm9yZzwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NSBDT0xPUj1CTEFDSz4gPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTU+PEI+U2VudDo8L0I+IEZyaWRheSwgSnVseSAyMiwgMjAwNSAxMDoyMyBBTTwv
Rk9OVD48QlI+PEZPTlQgU0laRT01PjxCPlN1YmplY3Q6PC9CPiBSRTogRnJhbWVmb3JtYXQgaW4g
YSBsMmNzIGdtcGxzIHJudmlyb25tZW50LjwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND5IaSw8
L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+SSB0aGluayBKdWVyZ2VuIGhhcyByYWlzZWQgYW4g
aW1wb3J0YW50IHF1ZXN0aW9uLiZuYnNwOyBIb3cgZnJhbWVzIGFyZSBsYWJlbGVkIChhbmQgdGhl
IHJlbGF0ZWQgZGF0YSBwbGFuZSBmb3J3YXJkaW5nIGJlaGF2aW9yKSBpcyBub3QgZGVmaW5lZCBi
eSB0aGUgY29udHJvbCBwbGFuZS4mbmJzcDsgVGhlIGNvbnRyb2wgcGxhbmUgc2VydmVzIHRvIHBy
b3Zpc2lvbiB0aGUgZGF0YSBwbGFuZSwgbm90IGRlZmluZSBpdC4mbmJzcDsgSW4gdGhlIGZyYW1l
d29yayBkcmFmdCBpdCBpcyBub3QgY2xlYXIgd2hhdCBkYXRhIHBsYW5lIHN0YW5kYXJkcyBhcmUg
Y292ZXJlZCBieSB0aGUgc3RhdGVkIGNvbnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzLiZuYnNwOyBT
b21lIHJlZmVyZW5jZXMgc2hvdWxkIGJlIHN1cHBsaWVkLiZuYnNwOyBJbiBhbnkgY2FzZSwgdGhl
IGxhYmVsaW5nIGFuZCBmb3J3YXJkaW5nIGJlaGF2aW9yIHNob3VsZCBiZSBkZWZpbmVkJm5ic3A7
YnkgdGhlc2UgcmVmZXJlbmNlZCBzdGFuZGFyZHMsIG5vdCZuYnNwO2J5IEdNUExTLjwvRk9OVD48
QlI+PEJSPjxGT05UIFNJWkU9ND4oSSBhbSBhc3N1bWluZyBkZWZpbml0aW9uIG9mIG5ldyBkYXRh
IHBsYW5lIHN0YW5kYXJkcyBpcyBvdXQgb2Ygc2NvcGUgZm9yIENDQU1QLik8L0ZPTlQ+PEJSPjxC
Uj48Rk9OVCBTSVpFPTQ+UmVnYXJkcyw8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5CZW48L0ZPTlQ+
PEJSPjxIUiBXSURUSD0iOTklIiBTSVpFPSI4IiBBTElHTj0ibGVmdCI+PEZPTlQgQ09MT1I9QkxB
Q0s+PEJSPjwvRk9OVD48Rk9OVCBTSVpFPTQ+PEI+RnJvbTo8L0I+IG93bmVyLWNjYW1wQG9wcy5p
ZXRmLm9yZyBbbWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZ10gPEI+T24gQmVoYWxmIE9m
IDwvQj5BZHJpYW4gRmFycmVsPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+PEI+U2VudDo8L0I+IEZy
aWRheSwgSnVseSAyMiwgMjAwNSA4OjM3IEFNPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+PEI+VG86
PC9CPiBQJmF1bWw7ciBNYXR0c3NvbjsgTG9hIEFuZGVyc3NvbjwvRk9OVD48QlI+PEZPTlQgU0la
RT00PjxCPkNjOjwvQj4gY2NhbXBAb3BzLmlldGYub3JnPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
PEI+U3ViamVjdDo8L0I+IFJlOiBGcmFtZWZvcm1hdCBpbiBhIGwyY3MgZ21wbHMgcm52aXJvbm1l
bnQuPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PkhpLDwvRk9OVD48QlI+PEJSPjxGT05UIFNJ
WkU9ND5JdCBpcyBhbHdheXMgcmVmcmVzaGluZyBob3cgZW5naW5lZXJzIGp1bXAgc3RyYWlnaHQg
dG8gYSBkaXNjdXNzaW9uIG9mIHRoZSBzb2x1dGlvbiA6LSk8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBT
SVpFPTQ+UGVyaGFwcyB3ZSBjYW4gYXNzdW1lIHRoYXQgdGhlIGZyYW1ld29yayBkcmFmdCBpcyBh
IGdvb2QgcmVwcmVzZW50YXRpb24gb2YgdGhlIHByb2JsZW0gc3BhY2UsIGFuZCB0aGF0IHdlIGFy
ZSByZWFkeSB0byBzdGFydCBkaXNjdXNzaW5nIHRoZSBzb2x1dGlvbnMuPC9GT05UPjxCUj48QlI+
PEZPTlQgU0laRT00Pk9uZSAocGVyaGFwcyB0aGUgb25seT8pIHNpZ25pZmljYW50IHF1ZXN0aW9u
IHRvIGFuc3dlciBpcyBob3cgdGhlIGZyYW1lcyB3aWxsIGJlIGxhYmVsbGVkLiBUaGlzIHF1ZXN0
aW9uIGlzIG9uZSB3ZSBtdXN0IGNvbWUgdG8gYXMgc29vbiBhcyB3ZSBhcmUgY29uZmlkZW50IHRo
YXQgdGhlIHJlcXVpcmVtZW50cyBuZWVkIHRvIGJlIGFkZHJlc3NlZCBhdCBhbGwuPC9GT05UPjxC
Uj48QlI+PEZPTlQgU0laRT00PkFzIGhhcyBiZWVuIHBvaW50ZWQgb3V0LCB0aGVyZSBhcmUgc2V2
ZXJhbCBwb3NzaWJpbGl0aWVzIGFuZCB0byBwaWNrIGZyb20gdGhlc2Ugd2UgbmVlZCB0byB1bmRl
cnN0YW5kOjwvRk9OVD48QlI+PEZPTlQgU0laRT00PjEuIERvIHdlIG5lZWQgdG8gc3VwcG9ydCBl
eHBsaWNpdCBsYWJlbCBzdGFja2luZz88L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mbmJzcDsmbmJz
cDsgTm90ZSB0aGF0IHRoaXMgaXMgbm90IHN1cHBvcnRlZCBpbiBURE0sIExTQyBvciBGU0MuPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+Mi4gRG8gd2UgbmVlZCB0byBiZSBhYmxlIHRvIGNvbnRyb2wg
KHBlcmhhcHMgdGhyb3VnaCBhbjwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZuYnNwOyZuYnNwOyZu
YnNwO2V4dGVybmFsIHNpZ25hbGluZyBjb250cm9sbGVyKSBleGlzdGluZyBoYXJkd2FyZSBhbmQg
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jm5ic3A7Jm5ic3A7IGluc3RhbGwgTFNQcyB0aHJvdWdo
IGV4aXN0aW5nIG5ldHdvcmtzPzwvRk9OVD48QlI+PEZPTlQgU0laRT00PjMuIERvIHdlIG5lZWQg
dG8gc3VwcG9ydCBleGlzdGluZyBmdW5jdGlvbiBzaW11bHRhbmVvdXMgdG88L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mbmJzcDsmbmJzcDsgdGhlIHN1cHBvcnQgb2YgR01QTFMgTDIgTFNQcz88L0ZP
TlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+SSB0aGluayB0aGF0IGZyb20gYSBjaGFpcidzIHBlcnNw
ZWN0aXZlIEkgY2FuIGdpdmUgc29tZSBsaW1pdGVkIGd1aWRhbmNlLjwvRk9OVD48QlI+PEJSPjxG
T05UIFNJWkU9ND5BLiBUaGVzZSBxdWVzdGlvbnMgbXVzdCBiZSByYWlzZWQgYW5kIGFuc3dlcmVk
IGluIHRoZSBmcmFtZXdvcmsgSS1EPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Qi4gVGhlIGFuc3dl
ciB0byBxdWVzdGlvbiAzIGlzICZxdW90O3llcyZxdW90Oy4gVGhpcyBtZWFucyB0aGF0IHRoZSB1
c2Ugb2YgbGFiZWxzPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jm5ic3A7Jm5ic3A7IG11c3Qgbm90
IHNpZ25pZmljYW50bHkgZGVwbGV0ZSBhbnkgbmFtZXNwYWNlIHVzZWQgdG8gc3VwcG9ydCBvdGhl
cjwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZuYnNwOyZuYnNwOyBmdW5jdGlvbi48L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND5DLiBDQ0FNUCBpcyBjaGFydGVyZWQgdG8gbG9vayBhdCB0aGUgY29udHJv
bCBvZiB0cmFuc3BvcnQgbmV0d29ya3MuIFRoaXM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mbmJz
cDsmbmJzcDsmbmJzcDtpbmNsdWRlcyBNZXRybywgYnV0IEkgYW0gdW5zdXJlIGFib3V0IENhbXB1
cy4gSXQgZG9lcyBub3QmbmJzcDtjb3ZlciA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mbmJzcDsm
bmJzcDsgc2lnbmFsaW5nIHRvIHRoZSBkZXNrdG9wLjwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9
ND5UaGFua3MsPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+QWRyaWFuPC9GT05UPjxCUj48QlI+PEZP
TlQgU0laRT00Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+RnJvbTogJnF1b3Q7UCZhdW1sO3IgTWF0dHNzb24mcXVvdDsgJmx0OzwvRk9OVD48Rk9O
VCBTSVpFPTQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpwZXJAZGVmZXJvLnNlPnBlckBk
ZWZlcm8uc2U8L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+Jmd0OzwvRk9O
VD48QlI+PEZPTlQgU0laRT00PlRvOiAmcXVvdDtMb2EgQW5kZXJzc29uJnF1b3Q7ICZsdDs8L0ZP
TlQ+PEZPTlQgU0laRT00IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86bG9hQHBpLnNlPmxv
YUBwaS5zZTwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTEFDSz4mZ3Q7PC9GT05U
PjxCUj48Rk9OVCBTSVpFPTQ+Q2M6ICZsdDs8L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMVUU+
PFU+PEEgSFJFRj1tYWlsdG86Y2NhbXBAb3BzLmlldGYub3JnPmNjYW1wQG9wcy5pZXRmLm9yZzwv
QT48L1U+PC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTEFDSz4mZ3Q7PC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+U2VudDogRnJpZGF5LCBKdWx5IDIyLCAyMDA1IDExOjQxIEFNPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+U3ViamVjdDogUmU6IEZyYW1lZm9ybWF0IGluIGEgbDJjcyBnbXBscyBybnZp
cm9ubWVudC48L0ZPTlQ+PEJSPjxCUj48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBQZXIgYW5k
IERpbWl0cmksPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7PC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyAmZ3Q7IEkgd291bGQgbGlrZSB0byBjb21lIGRvd24gc3Ryb25nZXIgdGhh
biB0aGF0LCBmb3IgbWUgaXQgaXM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgYSB2
ZXJ5IHN0cm9uZyByZXF1aXJlbWVudCB0aGF0IHRoZSBzYW1lIHN3aXRjaCBjYW4gaGFuZGxlPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IGJvdGggVkxBTnMgYW5kIEdNUExzIHRyYWZp
YyBjb3JyZWN0bHkuIEkgY2FuJ3QgZHNlZSBob3cgdGhhdDwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZndDsgJmd0OyBjb3VsZCBiZSBkb25lIGlmIHVzaW5nIHRoZSBWTEFOIHRwaWQgdG8gaW5kaWNh
dGUgR01QTFM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgdHJhZmZpYy48L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgSWYgeW91
IGV2ZXIgd2FudCB0aGF0IHNhbWUgc3dpdGNoIHRvIGhhbmRsZSB0cmFmZmljIGZvciBhIGRpcmVj
dGx5PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBjb25uZWN0ZWQmbmJzcDsgaG9zdCAobm90
IHRvIHVuY29tbWVuKSB5b3Ugd291bGQgd2FudCB0aGF0IHRvIHVzZSBub3JtYWw8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND4mZ3Q7IGV0aGVybmV0IG1hY2FkZHJlc3Mgc3dpdGNoaW5nLiBTbyBvZiBj
b3Vyc2UgeW91IGRvIG5vdCB3YW50IHRvIGhhdmUgdG88L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4m
Z3Q7IGNob29zZSBiZXR3ZWVuIHZsYW4gYW5kIGdtcGxzLCB5b3Ugd291bGQgd2FudCBib3RoIGF0
IHRoZSBzYW1lIHRpbWUuPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyA8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mZ3Q7IC9wZXI8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IDwvRk9OVD48
QlI+PEZPTlQgU0laRT00PiZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7PC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IC9Mb2E8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7ICZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgUCZhdW1sO3IgTWF0
dHNzb24gd3JvdGU6PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZndDtoaSBw
YXIsIG9uZSBvZiB0aGUgcG9zc2liaWxpdGllcyB0aGF0IGhhcyBiZWVuIGNvbnNpZGVyZWQgdG8g
Y29wZSB3aXRoPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZndDt0aGlzIHJl
cXVpcmVtZW50IGlzIHRvIHVzZSBhIGRlZGljYXRlZCBUUElEIGZvciB0aGUgRXRoZXJuZXQgbGFi
ZWxlZDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsmZ3Q7ZnJhbWVzOyB0aGlz
IHdvdWxkIGFsbG93IGRpZmZlcmVudGlhdGVkIHByb2Nlc3Npbmcgd2l0aCBub24tbGFiZWxlZDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsmZ3Q7ZnJhbWVzdGhhbmtzLjwvRk9O
VD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4m
Z3Q7ICZndDsmZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBUaGF0IHNl
ZW1zIHRvIG1ha2UgbW9yZSBzZW5jZS4gSWYgdGhhdCBmcmFtZSBpcyB0byBiZSBzaXplZCBsaWtl
IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgODAyLjFxPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBmcmFtZS4gVGhlcmUgaXMgbm90IHRoYXQgbXVjaCBz
cGFjZSBsZWZ0IHRvIGEgbGFiZWwuIE9yIGlzIHRoZSBkZW1hbmQgdG88L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IHVzZSBqdW1ib2ZyYW1lcyA/PC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBIYXMgdGhlcmUgYmVlbiBhbnkgZGlzY3Vzc2lvbiBvbiBsYWJl
bHN0YWNraW5nLCBhbmQgbWFpbmx5IHdoZXJlIHRvPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyAmZ3Q7Jmd0OyBwbGFjZTwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgdGhl
IGluZm9ybWF0aW9uPzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDs8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IFJlZ2FyZHMuPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBQZXI8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsm
Z3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OzwvRk9OVD48QlI+PEZPTlQg
U0laRT00PiZndDsgJmd0OyZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDs8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7
ICZndDsgLS08L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgTG9hIEFuZGVyc3Nvbjwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZn
dDsgJmd0OyBQcmluY2lwYWwgTmV0d29ya2luZyBBcmNoaXRlY3Q8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDsgQWNyZW8gQUImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgcGhvbmU6Jm5ic3A7ICs0NiA4IDYzMiA3NyAxNDwvRk9OVD48QlI+PEZPTlQgU0la
RT00PiZndDsgJmd0OyBJc2Fmam9yZHNnYXRhbiAyMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBtb2JpbGU6ICs0NiA3MzkgODEgMjEgNjQ8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mZ3Q7ICZndDsgS2lzdGEsIFN3ZWRlbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbWFpbDombmJz
cDsgPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOmxvYS5h
bmRlcnNzb25AYWNyZW8uc2U+bG9hLmFuZGVyc3NvbkBhY3Jlby5zZTwvQT48L1U+PC9GT05UPjxG
T05UIENPTE9SPUJMQUNLPjxCUj48L0ZPTlQ+PEZPTlQgU0laRT00PiZndDsgJmd0OyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJM
VUU+PFU+PEEgSFJFRj1tYWlsdG86bG9hQHBpLnNlPmxvYUBwaS5zZTwvQT48L1U+PC9GT05UPjxG
T05UIENPTE9SPUJMQUNLPjxCUj48L0ZPTlQ+PEZPTlQgU0laRT00PiZndDsgJmd0OzwvRk9OVD48
QlI+PEZPTlQgU0laRT00PiZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyA8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgPC9GT05U
PjxCUj48QlI+PEZPTlQgU0laRT01Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PTwvRk9OVD48QlI+PEZPTlQgU0laRT01PlRoZSBpbmZv
cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBwcml2aWxlZ2VkPC9GT05U
PjxCUj48Rk9OVCBTSVpFPTU+YW5kIGNvbmZpZGVudGlhbCBhbmQgcHJvdGVjdGVkIGZyb20gZGlz
Y2xvc3VyZS4gSWYgdGhlIHJlYWRlcjwvRk9OVD48QlI+PEZPTlQgU0laRT01Pm9mIHRoaXMgbWVz
c2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgb3IgYW4gZW1wbG95ZWU8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9NT5vciBhZ2VudCByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0aGlz
IG1lc3NhZ2UgdG8gdGhlPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+aW50ZW5kZWQgcmVjaXBpZW50
LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSByZXByb2R1Y3Rpb24sPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTU+ZGlzc2VtaW5hdGlvbiBvciBkaXN0cmlidXRpb24gb2YgdGhpcyBjb21t
dW5pY2F0aW9uIGlzIHN0cmljdGx5PC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+cHJvaGliaXRlZC4g
SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLDwvRk9OVD48
QlI+PEZPTlQgU0laRT01PnBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgcmVwbHlpbmcg
dG8gdGhlIG1lc3NhZ2UgYW5kPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+ZGVsZXRpbmcgaXQgZnJv
bSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuIFRlbGxhYnM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
NT49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT08L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi
Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PTwvRk9OVD48QlI+PEZPTlQgU0laRT00IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5UaGUg
aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgcHJpdmlsZWdlZDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5hbmQgY29uZmlk
ZW50aWFsIGFuZCBwcm90ZWN0ZWQgZnJvbSBkaXNjbG9zdXJlLiBJZiB0aGUgcmVhZGVyPC9GT05U
PjxCUj48Rk9OVCBTSVpFPTQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPm9mIHRoaXMgbWVzc2Fn
ZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgb3IgYW4gZW1wbG95ZWU8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9NCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+b3IgYWdlbnQgcmVzcG9uc2li
bGUgZm9yIGRlbGl2ZXJpbmcgdGhpcyBtZXNzYWdlIHRvIHRoZTwvRk9OVD48QlI+PEZPTlQgU0la
RT00IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5pbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUg
aGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHJlcHJvZHVjdGlvbiw8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9NCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+ZGlzc2VtaW5hdGlvbiBvciBkaXN0cmlidXRp
b24gb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5PC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2Vp
dmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciw8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NCBG
QUNFPSJNb25vc3BhY2UsQ291cmllciI+cGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBy
ZXBseWluZyB0byB0aGUgbWVzc2FnZSBhbmQ8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NCBGQUNFPSJN
b25vc3BhY2UsQ291cmllciI+ZGVsZXRpbmcgaXQgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5
b3UuIFRlbGxhYnM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NCBGQUNFPSJNb25vc3BhY2UsQ291cmll
ciI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PC9GT05UPjxCUj48L1A+



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 23:07:53 +0000
Message-ID: <01c401c58f12$4c80cd20$b7849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Sat, 23 Jul 2005 00:07:39 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BD_01C58F1A.8A0CE630"

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--




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 22:20:48 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Fri, 22 Jul 2005 15:18:35 -0700
Message-ID: <[e-mail]>
Thread-Topic: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Thread-Index: AcWO6PXwNV9J9GsyTyywah8dc4SA0QAESRbgAAQtiVA=
From: "Drake, John E" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, July 22, 2005 2:22 PM
> To: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> 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
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Adrian Farrel
> > Sent: 22 July 2005 19:13
> > To: Spencer,R,Richard,XDE73 R; [e-mail];
> > [e-mail]; [e-mail]
> > Cc: [e-mail]
> > 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: <[e-mail]>
> > To: <[e-mail]>; <[e-mail]>; <[e-mail]>
> > Cc: <[e-mail]>
> > 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
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]On
> > > Behalf Of Heiles Juergen
> > > Sent: 22 July 2005 14:17
> > > To: Loa Andersson; P=E4r Mattsson
> > > Cc: [e-mail]
> > > 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
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > [mailto:[e-mail]] On
> > > > Behalf Of Loa Andersson
> > > > Sent: Friday, July 22, 2005 12:05 PM
> > > > To: P=E4r Mattsson
> > > > Cc: [e-mail]
> > > > 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:  [phone]
> > > > Isafjordsgatan 22                  mobile: [phone]
> > > > Kista, Sweden                      email:  =
[e-mail]
> > > >                                             [e-mail]
> > > >
> > >
> > >
> >
> >
> >
> >
> >




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 21:23:58 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Fri, 22 Jul 2005 22:22:13 +0100
Message-ID: <[e-mail]>
Thread-Topic: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Thread-Index: AcWO6PXwNV9J9GsyTyywah8dc4SA0QAESRbg
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

> 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

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: 22 July 2005 19:13
> To: Spencer,R,Richard,XDE73 R; [e-mail];=20
> [e-mail]; [e-mail]
> Cc: [e-mail]
> 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: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>
> 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
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On
> > Behalf Of Heiles Juergen
> > Sent: 22 July 2005 14:17
> > To: Loa Andersson; P=E4r Mattsson
> > Cc: [e-mail]
> > 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
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [e-mail]
> [mailto:[e-mail]] On
> > > Behalf Of Loa Andersson
> > > Sent: Friday, July 22, 2005 12:05 PM
> > > To: P=E4r Mattsson
> > > Cc: [e-mail]
> > > 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:  [phone]
> > > Isafjordsgatan 22                  mobile: [phone]
> > > Kista, Sweden                      email:  [e-mail]
> > >                                             [e-mail]
> > >
> >
> >
>=20
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 21:23:52 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58F03.6D2AEF23"
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 22:22:12 +0100
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
Thread-Index: AcWO4Z/sn5bUTdc8RiiIwKwSk2UxnAACGn2QAAWRjkA=
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Mack-Crane, T. Benjamin
Sent: 22 July 2005 19:25
To: Igor Bryskin; [e-mail]
Cc: Adrian Farrel; P=E4r Mattsson; Loa Andersson; [e-mail]
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:[e-mail]]=20
Sent: Friday, July 22, 2005 12:20 PM
To: [e-mail]
Cc: Mack-Crane, T. Benjamin; Adrian Farrel; P=E4r Mattsson; Loa =
Andersson; [e-mail]
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: [e-mail]=20
To: Igor Bryskin <mailto:[e-mail]> =20
Cc: Mack-Crane, T. Benjamin <mailto:[e-mail]>  ; =
Adrian  <mailto:[e-mail]> Farrel ; P=E4r  =
<mailto:[e-mail]> Mattsson ; Loa  <mailto:[e-mail]> Andersson ; =
[e-mail]=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" <[e-mail]>
Sent by: [e-mail]
07/22/2005 11:10 AST

To: "Mack-Crane, T. Benjamin" <[e-mail]>, "Adrian =
Farrel" <[e-mail]>, P=E4r Mattsson <[e-mail]>, "Loa =
Andersson" <[e-mail]>
cc: <[e-mail]>
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:[e-mail]> Benjamin=20
To: Adrian Farrel <mailto:[e-mail]>  ; P=E4r Mattsson =
<mailto:[e-mail]>  ; Loa  <mailto:[e-mail]> Andersson=20
Cc: [e-mail]=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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Adrian Farrel
Sent: Friday, July 22, 2005 8:37 AM
To: P=E4r Mattsson; Loa Andersson
Cc: [e-mail]
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" <[e-mail]>
To: "Loa Andersson" <[e-mail]>
Cc: <[e-mail]>
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:  [phone]
> > Isafjordsgatan 22                  mobile: [phone]
> > Kista, Sweden                      email:  [e-mail]
> >                                             [e-mail]
> >
>=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
  [e-mail] [mailto:[e-mail]] <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; [e-mail]<BR><B>Cc:</B> Adrian =
Farrel;=20
  P=E4r Mattsson; Loa Andersson; [e-mail]<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:[e-mail]] <BR><B>Sent:</B> Friday, July 22, 2005 =
12:20=20
    PM<BR><B>To:</B> [e-mail]<BR><B>Cc:</B> =
Mack-Crane,=20
    T. Benjamin; Adrian Farrel; P=E4r Mattsson; Loa Andersson;=20
    [e-mail]<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=[e-mail]=20
      =
href=3D"mailto:[e-mail]">Dimitri.Papadimitriou@al=
catel.be</A>=20
      </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
      href=3D"mailto:[e-mail]">Igor Bryskin</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A=20
      title=[e-mail]=20
      href=3D"mailto:[e-mail]">Mack-Crane, T. =
Benjamin</A> ; <A=20
      title=[e-mail] =
href=3D"mailto:[e-mail]">Adrian=20
      Farrel</A> ; <A title=[e-mail] =
href=3D"mailto:[e-mail]">P=E4r=20
      Mattsson</A> ; <A title=[e-mail] href=3D"mailto:[e-mail]">Loa=20
      Andersson</A> ; <A title=[e-mail]=20
      href=3D"mailto:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</A>&gt;</B></FONT><=
BR><FONT=20
      size=3D2>Sent by: <A=20
      =
href=3D"mailto:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</A>=
&gt;,=20
      "Adrian Farrel" &lt;<A=20
      href=3D"mailto:[e-mail]">[e-mail]</A>&gt;, =
P=E4r=20
      Mattsson &lt;<A =
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;, "Loa=20
      Andersson" &lt;<A=20
      href=3D"mailto:[e-mail]">[e-mail]</A>&gt;</FONT><BR><FONT=20
      size=3D2>cc:</FONT> <FONT size=3D2>&lt;<A=20
      =
href=3D"mailto:[e-mail]">[e-mail]</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:[e-mail]">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:[e-mail]">Adrian =
Farrel</A></U></FONT><FONT=20
      color=3Dblack size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A =

      href=3D"mailto:[e-mail]">P=E4r Mattsson</A></U></FONT><FONT =
color=3Dblack=20
      size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A =
href=3D"mailto:[e-mail]">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:[e-mail]">[e-mail]</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> [e-mail]=20
      [mailto:[e-mail]] <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
      [e-mail]<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:[e-mail]">[e-mail]</A></U></FONT><FONT=20
      color=3Dblack>&gt;<BR>To: "Loa Andersson" &lt;</FONT><FONT =
color=3Dblue><U><A=20
      href=3D"mailto:[e-mail]">[e-mail]</A></U></FONT><FONT=20
      color=3Dblack>&gt;<BR>Cc: &lt;</FONT><FONT color=3Dblue><U><A=20
      =
href=3D"mailto:[e-mail]">[e-mail]</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; [phone]<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: [phone]<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:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</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--



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 20:13:51 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58EF9.93F9EBAA"
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 21:11:43 +0100
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
Thread-Index: AcWO1Vz5WDl4NyiSSoqZJ6lj4ozrFAAG4CmA
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: 22 July 2005 16:51
To: Adrian Farrel
Cc: [e-mail]; [e-mail]
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" <[e-mail]>
Sent by: [e-mail]
07/22/2005 16:08
Please respond to "Adrian Farrel"

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: <[e-mail]>
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
  [e-mail] [mailto:[e-mail]] <B>On =
Behalf Of=20
  </B>[e-mail]<BR><B>Sent:</B> 22 July 2005=20
  16:51<BR><B>To:</B> Adrian Farrel<BR><B>Cc:</B>=20
  [e-mail]; =
[e-mail]<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;[e-mail]&gt;</B></FONT><BR><FONT size=3D2>Sent by:=20
  [e-mail]</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;[e-mail]&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--



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 20:13:43 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58EF9.9504EFFA"
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 21:11:44 +0100
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
Thread-Index: AcWOz77GfzcCsQC6StanOHm687rebgAF3z2A
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Igor Bryskin
Sent: 22 July 2005 16:11
To: Mack-Crane, T. Benjamin; Adrian Farrel; P=E4r Mattsson; Loa =
Andersson
Cc: [e-mail]
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:[e-mail]> =20
To: Adrian Farrel <mailto:[e-mail]>  ; P=E4r Mattsson =
<mailto:[e-mail]>  ; Loa Andersson <mailto:[e-mail]> =20
Cc: [e-mail]=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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Adrian Farrel
Sent: Friday, July 22, 2005 8:37 AM
To: P=E4r Mattsson; Loa Andersson
Cc: [e-mail]
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:[e-mail]> [e-mail]>
To: "Loa Andersson" < <mailto:[e-mail]> [e-mail]>
Cc: < <mailto:[e-mail]> [e-mail]>
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:  [phone]
> > Isafjordsgatan 22                  mobile: [phone]
> > Kista, Sweden                      email:   =
<mailto:[e-mail]> [e-mail]
> >                                              <mailto:[e-mail]> =
[e-mail]
> >
>=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
  [e-mail] [mailto:[e-mail]] <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
  [e-mail]<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=[e-mail]=20
    href=3D"mailto:[e-mail]">Mack-Crane, T. =
Benjamin</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
    href=3D"mailto:[e-mail]">Adrian Farrel</A> ; <A =
title=[e-mail]=20
    href=3D"mailto:[e-mail]">P=E4r Mattsson</A> ; <A =
title=[e-mail]=20
    href=3D"mailto:[e-mail]">Loa Andersson</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
    href=3D"mailto:[e-mail]">[e-mail]</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> [e-mail] =

      [mailto:[e-mail]] <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
      [e-mail]<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:[e-mail]"><FONT face=3DCourier=20
      size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
      size=3D2>[e-mail]</FONT></A><FONT face=3DCourier =
size=3D2>&gt;</FONT></DIV>
      <DIV><FONT face=3DCourier size=3D2>Cc: &lt;</FONT><A=20
      href=3D"mailto:[e-mail]"><FONT face=3DCourier=20
      size=3D2>[e-mail]</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; [phone]<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: [phone]<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:[e-mail]"><FONT=20
      face=3DCourier size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
      size=3D2>[e-mail]</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--



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 20:13:42 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 21:11:45 +0100
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
Thread-Index: AcWO0JK8kM7ppvqMRQihwOQp5MS+/AAGG3NA
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 19:02:18 +0000
To: "Mack-Crane, T. Benjamin" <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>, <[e-mail]>, "Adrian Farrel" <[e-mail]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>, "Loa Andersson" <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 21:01:02 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmFjdHVhbGx5IGkgZG9uJ3QgdGhpbmsg
eW91IGhhdmUgZnVsbHkgdW5kZXJzdG9vZCB0aGUgcHVycG9zZSBvZiB0aGlzIGRvY3VtZW50PC9G
T05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+c28gaSByZXBlYXQgYXNz
dW1pbmcgdGhlcmUgaXMgbm8gb3IgdW5kZWZpbmVkIGRhdGEgcGxhbmUgZGVmaW5pdGlvbiBpcyBu
b3QgY29ycmVjdCB3aGF0IHdlIGFyZSBkaXNjdXNzaW5nIGlzIHRoZSByb2xlIG9mIHRoZSBHTVBM
UyBjb250cm9sIHBsYW5lIGluIGV4Y2hhbmdpbmcgdGhlIHJlcXVpcmVkIGZvcndhcmRpbmcgaW5m
b3JtYXRpb24gZWxlbWVudHMsIHRoZSBxdWVzdGlvbiBpcyB0aHVzIHRvIGlkZW50aWZ5IHdoaWNo
IGRhdGEgcGxhbmUgYmVoYXZpb3VyIHdlIHdvdWxkIGxpa2UgR01QTFMgdG8gY292ZXIgaW4gb3Jk
ZXIgdG8gYWRkcmVzcyB0aGUgc3RyaW5nZW50IHJlcXVpcmVtZW50cyBhbmQgdGhlIHNjZW5hcmlv
cyB0aGF0IGhhdmUgYmVlbiBwcm9kdWNlZCBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgLSA8L0ZP
TlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj50byBiZSBldmVuIGNsZWFy
ZXI6IHRoZSBkZWZpbml0aW9uIG9mIGFueSBkYXRhIHBsYW5lIGJlaGF2aW91ciBpcyBvdXRzaWRl
IG9mIHRoZSBzY29wZSBvZiB0aGUgRFQgY2hhcnRlciBhbmQgdGhlIGRvY3VtZW50IGl0IHByb2R1
Y2VkIC08QlI+PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+PEI+JnF1b3Q7TWFjay1DcmFuZSwgVC4g
QmVuamFtaW4mcXVvdDsgJmx0O0Jlbi5NYWNrLUNyYW5lQHRlbGxhYnMuY29tJmd0OzwvQj48L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9Mj4wNy8yMi8yMDA1IDEzOjI1IEVTVDwvRk9OVD48QlI+PEJSPiA8
Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+JnF1b3Q7SWdvciBCcnlza2luJnF1
b3Q7ICZsdDtpYnJ5c2tpbkBtb3Zhei5jb20mZ3Q7LCBEaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUv
QUxDQVRFTEBBTENBVEVMPC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmNjOjwvRk9OVD4gPEZPTlQg
U0laRT0yPiZxdW90O0FkcmlhbiBGYXJyZWwmcXVvdDsgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsm
Z3Q7LCBQJmF1bWw7ciBNYXR0c3NvbiAmbHQ7cGVyQGRlZmVyby5zZSZndDssICZxdW90O0xvYSBB
bmRlcnNzb24mcXVvdDsgJmx0O2xvYUBwaS5zZSZndDssICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcm
Z3Q7PC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0y
PlN1YmplY3Q6PC9GT05UPiA8Rk9OVCBTSVpFPTI+UkU6IEZyYW1lZm9ybWF0IGluIGEgbDJjcyBn
bXBscyBybnZpcm9ubWVudC48L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD5JZ29yLDxCUj48QlI+
SSwgdG9vLCBhbSBiYWZmbGVkIGJ5IHRoZSBub3Rpb24gb2YgcmVxdWlyZW1lbnRzIGZvciBjb250
cm9sIG9mIGFuIHVuc3BlY2lmaWVkIGRhdGEgcGxhbmUuPEJSPjxCUj5SZWdhcmRzLDxCUj5CZW48
QlI+PEhSIFdJRFRIPSI5OSUiIFNJWkU9IjQiIEFMSUdOPSJsZWZ0Ij48Rk9OVCBDT0xPUj1CTEFD
Sz48QlI+PEI+RnJvbTo8L0I+IElnb3IgQnJ5c2tpbiBbbWFpbHRvOmlicnlza2luQG1vdmF6LmNv
bV0gPEJSPjxCPlNlbnQ6PC9CPiBGcmlkYXksIEp1bHkgMjIsIDIwMDUgMTI6MjAgUE08QlI+PEI+
VG86PC9CPiBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZTxCUj48Qj5DYzo8L0I+IE1h
Y2stQ3JhbmUsIFQuIEJlbmphbWluOyBBZHJpYW4gRmFycmVsOyBQJmF1bWw7ciBNYXR0c3Nvbjsg
TG9hIEFuZGVyc3NvbjsgY2NhbXBAb3BzLmlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBSZTog
RnJhbWVmb3JtYXQgaW4gYSBsMmNzIGdtcGxzIHJudmlyb25tZW50LjxCUj48QlI+RGltaXRyaSw8
QlI+PEJSPlRoZSBxdWVzdGlvbiBpcyBzaW1wbGU6IGlzIGl0IHBvc3NpYmxlIHRvZGF5IHRvIHN0
YXRpY2FsbHkgcHJvdmlzaW9uIEwyTFNQcyB0aGF0IGNvdWxkLCBzYXksJm5ic3A7c3VwcG9ydCBl
MmUgUW9TPyBJZiBub3QsIG1heSBiZSBpdCBpcyB0byBlYXJseSB0byBkaXNjdXNzIGFzcGVjdHMg
b2YgZHluYW1pYyBwcm92aXNpb25pbmcgb2Ygc3VjaCBMU1BzPyBJcyBpdCBwb3NzaWJsZS9yZWFz
b25hYmxlLCBpbiB5b3VyIG9waW5pb24sIHRvICZxdW90OzwvRk9OVD48Rk9OVCBTSVpFPTQ+ZGV0
YWlsIGhvdyBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGNhbiBiZSBleGNoYW5nZWQgdmlhIHRoZSBj
b250cm9sIHBsYW5lIChhbmQgdGhlbiBpbnN0YWxsZWQpJnF1b3Q7IHdpdGhvdXQmbmJzcDtoYXZp
bmcgaW4gbWluZCAmcXVvdDthIHNwZWNpZmljIGZvcndhcmRpbmcgYmVoYXZpb3ImcXVvdDs/PC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+SG93IGRvIHlvdSBrbm93IHdoaWNoIGZvcndhcmRpbmcgaW5m
b3JtYXRpb24gaXMgbmVlZGVkIGZvciB0aGUgZm9yd2FyZGluZyBub2JvZHkgaGFzIGRlZmluZWQg
eWV0PzwvRk9OVD48QlI+PEZPTlQgU0laRT00PlRoZSBvdGhlciBxdWVzdGlvbiBpcyZuYnNwO2Rv
IHdlIG5lZWQgYXQgYWxsIGUyZSBRb1MsIHJvdXRlIGNvbnRyb2wsIGZhc3QgcmVjb3Zlcnk/IFNv
dW5kcyBsaWtlIGV4Y2l0aW5nIGlkZWEsIGJ1dCBkb2VzIGFsbCB0aGF0IGNvbW1lcmNpYWxseSBt
YWtlIHNlbnNlPyBTbywgSSBndWVzcywgd2UgbmVlZCB0d28gdGhpbmdzJm5ic3A7YmVmb3JlIHdl
IGNhbiZuYnNwO21vdmUgZm9yd2FyZDo8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5hKSB2YWxpZGF0
aW9uIG9mIHRoZSBpZGVhIGJ5IHRoZSBwcm92aWRlcnM7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
YikgZGVmaW5pdGlvbiBvZiB0aGUgZGF0YSBwbGFuZSBiZWhhdmlvcjs8L0ZPTlQ+PEJSPjxCUj48
Rk9OVCBTSVpFPTQ+SWdvcjwvRk9OVD48QlI+PEZPTlQgU0laRT00Pi0tLS0tIE9yaWdpbmFsIE1l
c3NhZ2UgLS0tLS0gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+PEI+RnJvbTo8L0I+IDwvRk9OVD48
Rk9OVCBTSVpFPTQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpEaW1pdHJpLlBhcGFkaW1p
dHJpb3VAYWxjYXRlbC5iZT5EaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZTwvQT48L1U+
PC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTEFDSz4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
PEI+VG86PC9CPiA8L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWls
dG86aWJyeXNraW5AbW92YXouY29tPklnb3IgQnJ5c2tpbjwvQT48L1U+PC9GT05UPjxGT05UIFNJ
WkU9NCBDT0xPUj1CTEFDSz4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+PEI+Q2M6PC9CPiA8L0ZP
TlQ+PEZPTlQgU0laRT00IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86QmVuLk1hY2stQ3Jh
bmVAdGVsbGFicy5jb20+TWFjay1DcmFuZSwgVC4gQmVuamFtaW48L0E+PC9VPjwvRk9OVD48Rk9O
VCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDsgPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVFPjxV
PjxBIEhSRUY9bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+QWRyaWFuIEZhcnJlbDwvQT48L1U+
PC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTEFDSz4gOyA8L0ZPTlQ+PEZPTlQgU0laRT00IENP
TE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86cGVyQGRlZmVyby5zZT5QJmF1bWw7ciBNYXR0c3Nv
bjwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTEFDSz4gOyA8L0ZPTlQ+PEZPTlQg
U0laRT00IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86bG9hQHBpLnNlPkxvYSBBbmRlcnNz
b248L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDsgPC9GT05UPjxGT05U
IFNJWkU9NCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOmNjYW1wQG9wcy5pZXRmLm9yZz5j
Y2FtcEBvcHMuaWV0Zi5vcmc8L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+
IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PjxCPlNlbnQ6PC9CPiBGcmlkYXksIEp1bHkgMjIsIDIw
MDUgMTI6MjEgUE08L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND48Qj5TdWJqZWN0OjwvQj4gUmU6IEZy
YW1lZm9ybWF0IGluIGEgbDJjcyBnbXBscyBybnZpcm9ubWVudC48L0ZPTlQ+PEJSPjxCUj48QlI+
PEZPTlQgU0laRT00Pmlnb3IgLSBpIGFtIG5vdCBzdXJlIHdoaWNoIHBvaW50IHRoZXkgZXhhY3Rs
eSBoYXZlIC0gdGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudCBpcyB0byBkZXRhaWwgaG93IGZv
cndhcmRpbmcgaW5mb3JtYXRpb24gY2FuIGJlIGV4Y2hhbmdlZCB2aWEgdGhlIGNvbnRyb2wgcGxh
bmUgKGFuZCB0aGVuIGluc3RhbGxlZCkgbm90IHRvIGRlZmluZSBhIHNwZWNpZmljIGZvcndhcmRp
bmcgYmVoYXZpb3VyPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PnRoYW5rcyw8L0ZPTlQ+PEJS
PjxCUj48Rk9OVCBTSVpFPTQ+LSBkaW1pdHJpLjwvRk9OVD48QlI+PEJSPjxCPiZxdW90O0lnb3Ig
QnJ5c2tpbiZxdW90OyAmbHQ7PC9CPjxGT05UIENPTE9SPUJMVUU+PEI+PFU+PEEgSFJFRj1tYWls
dG86aWJyeXNraW5AbW92YXouY29tPmlicnlza2luQG1vdmF6LmNvbTwvQT48L1U+PC9CPjwvRk9O
VD48Rk9OVCBDT0xPUj1CTEFDSz48Qj4mZ3Q7PC9CPjxCUj5TZW50IGJ5OiA8L0ZPTlQ+PEZPTlQg
Q09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc+b3du
ZXItY2NhbXBAb3BzLmlldGYub3JnPC9BPjwvVT48L0ZPTlQ+PEZPTlQgQ09MT1I9QkxBQ0s+PEJS
PjA3LzIyLzIwMDUgMTE6MTAgQVNUPEJSPjxCUj5Ubzo8L0ZPTlQ+PEZPTlQgU0laRT00PiA8L0ZP
TlQ+JnF1b3Q7TWFjay1DcmFuZSwgVC4gQmVuamFtaW4mcXVvdDsgJmx0OzxGT05UIENPTE9SPUJM
VUU+PFU+PEEgSFJFRj1tYWlsdG86QmVuLk1hY2stQ3JhbmVAdGVsbGFicy5jb20+QmVuLk1hY2st
Q3JhbmVAdGVsbGFicy5jb208L0E+PC9VPjwvRk9OVD48Rk9OVCBDT0xPUj1CTEFDSz4mZ3Q7LCAm
cXVvdDtBZHJpYW4gRmFycmVsJnF1b3Q7ICZsdDs8L0ZPTlQ+PEZPTlQgQ09MT1I9QkxVRT48VT48
QSBIUkVGPW1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPmFkcmlhbkBvbGRkb2cuY28udWs8L0E+
PC9VPjwvRk9OVD48Rk9OVCBDT0xPUj1CTEFDSz4mZ3Q7LCBQJmF1bWw7ciBNYXR0c3NvbiAmbHQ7
PC9GT05UPjxGT05UIENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86cGVyQGRlZmVyby5zZT5w
ZXJAZGVmZXJvLnNlPC9BPjwvVT48L0ZPTlQ+PEZPTlQgQ09MT1I9QkxBQ0s+Jmd0OywgJnF1b3Q7
TG9hIEFuZGVyc3NvbiZxdW90OyAmbHQ7PC9GT05UPjxGT05UIENPTE9SPUJMVUU+PFU+PEEgSFJF
Rj1tYWlsdG86bG9hQHBpLnNlPmxvYUBwaS5zZTwvQT48L1U+PC9GT05UPjxGT05UIENPTE9SPUJM
QUNLPiZndDs8QlI+Y2M6PC9GT05UPjxGT05UIFNJWkU9ND4gPC9GT05UPiZsdDs8Rk9OVCBDT0xP
Uj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOmNjYW1wQG9wcy5pZXRmLm9yZz5jY2FtcEBvcHMuaWV0
Zi5vcmc8L0E+PC9VPjwvRk9OVD48Rk9OVCBDT0xPUj1CTEFDSz4mZ3Q7PEJSPmJjYzo8L0ZPTlQ+
PEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPlN1YmplY3Q6PEZPTlQgU0laRT00PiA8L0ZPTlQ+UmU6
IEZyYW1lZm9ybWF0IGluIGEgbDJjcyBnbXBscyBybnZpcm9ubWVudC48QlI+PEJSPjxCUj48Rk9O
VCBTSVpFPTQ+SGksPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PkkgdGhpbmsgQmVuIGFuZCBK
dWVyZ2VuIGhhdmUgYSBwb2ludCBoZXJlLiBUaGVyZSBpcyBub3RoaW5nIHRoYXQgY291bGQgYmUg
ZHluYW1pY2FsbHkgcHJvdmlzaW9uZWQgdGhhdCBjb3VsZCBub3QgYmUgYWxzbyBwcm92aXNpb25l
ZCBieSBtYW5hZ2VtZW50LiBJbiBvdGhlciB3b3JkcyBkYXRhIHBsYW5lIGlzIHRoZSBLaW5nIGhl
cmUuIFdlIG5lZWQgZGF0YSBwbGFuZSBzdGFuZGFyZChzKSBvbiBob3cgd2UgZW5jb2RlIGEgbGFi
ZWwsIHdoZXRoZXIgd2UgbmVlZCBhIGxhYmVsIHN0YWNrIG9yIG5vdCwgaG93IHRoZSBsYWJlbGVk
IHRyYWZmaWMgaXMgc3VwcG9zZWQgdG8gYmUmbmJzcDt0cmVhdGVkLCBob3cgbGFiZWxlZCB0cmFm
ZmljIGNvLWV4aXN0IHdpdGggbm9uLWxhYmVsIHRyYWZmaWMsIGV0Yy4gVGhpcyBpcyBzb21ldGhp
bmcgdGhhdCBub3QgZm9yIENDQU1QIHRvIGRlZmluZS4gVGFrZSBmb3IgZXhhbXBsZSBURE0gbmV0
d29ya3MuIEdNUExTIG9ubHkgcHJvdmlkZXMgYSB3YXkgdG8gZHluYW1pY2FsbHkgcHJvdmlzaW9u
IEcuNzA3IG5ldHdvcmtzLiBIZW5jZSB0aGVyZSBpcyBhIG5lZWQgaW4gcGFyYWxsZWwgc3RhbmRh
cmRpemF0aW9uIGFjdGl2aXRpZXMgaW4gSVRVLiBPbmx5IGFmdGVyIHRoYXQgd2UgY2FuIGRpc2N1
c3MgaG93IGFsbCB0aGF0IGNvdWxkIGJlIGR5bmFtaWNhbGx5IHByb3Zpc2lvbmVkLCB0aGF0IGlz
IHRoZSBhc3BlY3RzIG9mIGNvbnRyb2wgcGxhbmUuIDwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9
ND5JZ29yPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t
LSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT48Qj5Gcm9tOjwvQj4gPC9GT05UPjxGT05UIFNJWkU9
NSBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOkJlbi5NYWNrLUNyYW5lQHRlbGxhYnMuY29t
Pk1hY2stQ3JhbmUsIFQuIEJlbmphbWluPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0laRT01IENPTE9S
PUJMQUNLPiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT48Qj5Ubzo8L0I+IDwvRk9OVD48Rk9OVCBT
SVpFPTUgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPkFk
cmlhbiBGYXJyZWw8L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTUgQ09MT1I9QkxBQ0s+IDsgPC9G
T05UPjxGT05UIFNJWkU9NSBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOnBlckBkZWZlcm8u
c2U+UCZhdW1sO3IgTWF0dHNzb248L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTUgQ09MT1I9QkxB
Q0s+IDsgPC9GT05UPjxGT05UIFNJWkU9NSBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOmxv
YUBwaS5zZT5Mb2EgQW5kZXJzc29uPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0laRT01IENPTE9SPUJM
QUNLPiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT48Qj5DYzo8L0I+IDwvRk9OVD48Rk9OVCBTSVpF
PTUgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpjY2FtcEBvcHMuaWV0Zi5vcmc+Y2NhbXBA
b3BzLmlldGYub3JnPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0laRT01IENPTE9SPUJMQUNLPiA8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9NT48Qj5TZW50OjwvQj4gRnJpZGF5LCBKdWx5IDIyLCAyMDA1IDEw
OjIzIEFNPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+PEI+U3ViamVjdDo8L0I+IFJFOiBGcmFtZWZv
cm1hdCBpbiBhIGwyY3MgZ21wbHMgcm52aXJvbm1lbnQuPC9GT05UPjxCUj48QlI+PEZPTlQgU0la
RT00PkhpLDwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND5JIHRoaW5rIEp1ZXJnZW4gaGFzIHJh
aXNlZCBhbiBpbXBvcnRhbnQgcXVlc3Rpb24uJm5ic3A7IEhvdyBmcmFtZXMgYXJlIGxhYmVsZWQg
KGFuZCB0aGUgcmVsYXRlZCBkYXRhIHBsYW5lIGZvcndhcmRpbmcgYmVoYXZpb3IpIGlzIG5vdCBk
ZWZpbmVkIGJ5IHRoZSBjb250cm9sIHBsYW5lLiZuYnNwOyBUaGUgY29udHJvbCBwbGFuZSBzZXJ2
ZXMgdG8gcHJvdmlzaW9uIHRoZSBkYXRhIHBsYW5lLCBub3QgZGVmaW5lIGl0LiZuYnNwOyBJbiB0
aGUgZnJhbWV3b3JrIGRyYWZ0IGl0IGlzIG5vdCBjbGVhciB3aGF0IGRhdGEgcGxhbmUgc3RhbmRh
cmRzIGFyZSBjb3ZlcmVkIGJ5IHRoZSBzdGF0ZWQgY29udHJvbCBwbGFuZSByZXF1aXJlbWVudHMu
Jm5ic3A7IFNvbWUgcmVmZXJlbmNlcyBzaG91bGQgYmUgc3VwcGxpZWQuJm5ic3A7IEluIGFueSBj
YXNlLCB0aGUgbGFiZWxpbmcgYW5kIGZvcndhcmRpbmcgYmVoYXZpb3Igc2hvdWxkIGJlIGRlZmlu
ZWQmbmJzcDtieSB0aGVzZSByZWZlcmVuY2VkIHN0YW5kYXJkcywgbm90Jm5ic3A7YnkgR01QTFMu
PC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PihJIGFtIGFzc3VtaW5nIGRlZmluaXRpb24gb2Yg
bmV3IGRhdGEgcGxhbmUgc3RhbmRhcmRzIGlzIG91dCBvZiBzY29wZSBmb3IgQ0NBTVAuKTwvRk9O
VD48QlI+PEJSPjxGT05UIFNJWkU9ND5SZWdhcmRzLDwvRk9OVD48QlI+PEZPTlQgU0laRT00PkJl
bjwvRk9OVD48QlI+PEhSIFdJRFRIPSI5OSUiIFNJWkU9IjgiIEFMSUdOPSJsZWZ0Ij48Rk9OVCBD
T0xPUj1CTEFDSz48QlI+PC9GT05UPjxGT05UIFNJWkU9ND48Qj5Gcm9tOjwvQj4gb3duZXItY2Nh
bXBAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXSA8Qj5PbiBC
ZWhhbGYgT2YgPC9CPkFkcmlhbiBGYXJyZWw8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND48Qj5TZW50
OjwvQj4gRnJpZGF5LCBKdWx5IDIyLCAyMDA1IDg6MzcgQU08L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND48Qj5Ubzo8L0I+IFAmYXVtbDtyIE1hdHRzc29uOyBMb2EgQW5kZXJzc29uPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+PEI+Q2M6PC9CPiBjY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND48Qj5TdWJqZWN0OjwvQj4gUmU6IEZyYW1lZm9ybWF0IGluIGEgbDJjcyBnbXBscyBy
bnZpcm9ubWVudC48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+SGksPC9GT05UPjxCUj48QlI+
PEZPTlQgU0laRT00Pkl0IGlzIGFsd2F5cyByZWZyZXNoaW5nIGhvdyBlbmdpbmVlcnMganVtcCBz
dHJhaWdodCB0byBhIGRpc2N1c3Npb24gb2YgdGhlIHNvbHV0aW9uIDotKTwvRk9OVD48QlI+PEJS
PjxGT05UIFNJWkU9ND5QZXJoYXBzIHdlIGNhbiBhc3N1bWUgdGhhdCB0aGUgZnJhbWV3b3JrIGRy
YWZ0IGlzIGEgZ29vZCByZXByZXNlbnRhdGlvbiBvZiB0aGUgcHJvYmxlbSBzcGFjZSwgYW5kIHRo
YXQgd2UgYXJlIHJlYWR5IHRvIHN0YXJ0IGRpc2N1c3NpbmcgdGhlIHNvbHV0aW9ucy48L0ZPTlQ+
PEJSPjxCUj48Rk9OVCBTSVpFPTQ+T25lIChwZXJoYXBzIHRoZSBvbmx5Pykgc2lnbmlmaWNhbnQg
cXVlc3Rpb24gdG8gYW5zd2VyIGlzIGhvdyB0aGUgZnJhbWVzIHdpbGwgYmUgbGFiZWxsZWQuIFRo
aXMgcXVlc3Rpb24gaXMgb25lIHdlIG11c3QgY29tZSB0byBhcyBzb29uIGFzIHdlIGFyZSBjb25m
aWRlbnQgdGhhdCB0aGUgcmVxdWlyZW1lbnRzIG5lZWQgdG8gYmUgYWRkcmVzc2VkIGF0IGFsbC48
L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+QXMgaGFzIGJlZW4gcG9pbnRlZCBvdXQsIHRoZXJl
IGFyZSBzZXZlcmFsIHBvc3NpYmlsaXRpZXMgYW5kIHRvIHBpY2sgZnJvbSB0aGVzZSB3ZSBuZWVk
IHRvIHVuZGVyc3RhbmQ6PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+MS4gRG8gd2UgbmVlZCB0byBz
dXBwb3J0IGV4cGxpY2l0IGxhYmVsIHN0YWNraW5nPzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZu
YnNwOyZuYnNwOyBOb3RlIHRoYXQgdGhpcyBpcyBub3Qgc3VwcG9ydGVkIGluIFRETSwgTFNDIG9y
IEZTQy48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4yLiBEbyB3ZSBuZWVkIHRvIGJlIGFibGUgdG8g
Y29udHJvbCAocGVyaGFwcyB0aHJvdWdoIGFuPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jm5ic3A7
Jm5ic3A7Jm5ic3A7ZXh0ZXJuYWwgc2lnbmFsaW5nIGNvbnRyb2xsZXIpIGV4aXN0aW5nIGhhcmR3
YXJlIGFuZCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mbmJzcDsmbmJzcDsgaW5zdGFsbCBMU1Bz
IHRocm91Z2ggZXhpc3RpbmcgbmV0d29ya3M/PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+My4gRG8g
d2UgbmVlZCB0byBzdXBwb3J0IGV4aXN0aW5nIGZ1bmN0aW9uIHNpbXVsdGFuZW91cyB0bzwvRk9O
VD48QlI+PEZPTlQgU0laRT00PiZuYnNwOyZuYnNwOyB0aGUgc3VwcG9ydCBvZiBHTVBMUyBMMiBM
U1BzPzwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND5JIHRoaW5rIHRoYXQgZnJvbSBhIGNoYWly
J3MgcGVyc3BlY3RpdmUgSSBjYW4gZ2l2ZSBzb21lIGxpbWl0ZWQgZ3VpZGFuY2UuPC9GT05UPjxC
Uj48QlI+PEZPTlQgU0laRT00PkEuIFRoZXNlIHF1ZXN0aW9ucyBtdXN0IGJlIHJhaXNlZCBhbmQg
YW5zd2VyZWQgaW4gdGhlIGZyYW1ld29yayBJLUQ8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5CLiBU
aGUgYW5zd2VyIHRvIHF1ZXN0aW9uIDMgaXMgJnF1b3Q7eWVzJnF1b3Q7LiBUaGlzIG1lYW5zIHRo
YXQgdGhlIHVzZSBvZiBsYWJlbHM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mbmJzcDsmbmJzcDsg
bXVzdCBub3Qgc2lnbmlmaWNhbnRseSBkZXBsZXRlIGFueSBuYW1lc3BhY2UgdXNlZCB0byBzdXBw
b3J0IG90aGVyPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jm5ic3A7Jm5ic3A7IGZ1bmN0aW9uLjwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PkMuIENDQU1QIGlzIGNoYXJ0ZXJlZCB0byBsb29rIGF0IHRo
ZSBjb250cm9sIG9mIHRyYW5zcG9ydCBuZXR3b3Jrcy4gVGhpczwvRk9OVD48QlI+PEZPTlQgU0la
RT00PiZuYnNwOyZuYnNwOyZuYnNwO2luY2x1ZGVzIE1ldHJvLCBidXQgSSBhbSB1bnN1cmUgYWJv
dXQgQ2FtcHVzLiBJdCBkb2VzIG5vdCZuYnNwO2NvdmVyIDwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZuYnNwOyZuYnNwOyBzaWduYWxpbmcgdG8gdGhlIGRlc2t0b3AuPC9GT05UPjxCUj48QlI+PEZP
TlQgU0laRT00PlRoYW5rcyw8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5BZHJpYW48L0ZPTlQ+PEJS
PjxCUj48Rk9OVCBTSVpFPTQ+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND5Gcm9tOiAmcXVvdDtQJmF1bWw7ciBNYXR0c3NvbiZxdW90OyAmbHQ7PC9G
T05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOnBlckBkZWZlcm8u
c2U+cGVyQGRlZmVyby5zZTwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTEFDSz4m
Z3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+VG86ICZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsg
Jmx0OzwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpsb2FA
cGkuc2U+bG9hQHBpLnNlPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMQUNLPiZn
dDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5DYzogJmx0OzwvRk9OVD48Rk9OVCBTSVpFPTQgQ09M
T1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpjY2FtcEBvcHMuaWV0Zi5vcmc+Y2NhbXBAb3BzLmll
dGYub3JnPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMQUNLPiZndDs8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND5TZW50OiBGcmlkYXksIEp1bHkgMjIsIDIwMDUgMTE6NDEgQU08L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND5TdWJqZWN0OiBSZTogRnJhbWVmb3JtYXQgaW4gYSBsMmNzIGdt
cGxzIHJudmlyb25tZW50LjwvRk9OVD48QlI+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7
IFBlciBhbmQgRGltaXRyaSw8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDs8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgSSB3b3VsZCBsaWtlIHRvIGNvbWUgZG93biBzdHJv
bmdlciB0aGFuIHRoYXQsIGZvciBtZSBpdCBpczwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsg
Jmd0OyBhIHZlcnkgc3Ryb25nIHJlcXVpcmVtZW50IHRoYXQgdGhlIHNhbWUgc3dpdGNoIGNhbiBo
YW5kbGU8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgYm90aCBWTEFOcyBhbmQgR01Q
THMgdHJhZmljIGNvcnJlY3RseS4gSSBjYW4ndCBkc2VlIGhvdyB0aGF0PC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyAmZ3Q7IGNvdWxkIGJlIGRvbmUgaWYgdXNpbmcgdGhlIFZMQU4gdHBpZCB0
byBpbmRpY2F0ZSBHTVBMUzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyB0cmFmZmlj
LjwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyBJZiB5b3UgZXZlciB3YW50IHRoYXQgc2FtZSBzd2l0Y2ggdG8gaGFuZGxlIHRyYWZmaWMgZm9y
IGEgZGlyZWN0bHk8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IGNvbm5lY3RlZCZuYnNwOyBo
b3N0IChub3QgdG8gdW5jb21tZW4pIHlvdSB3b3VsZCB3YW50IHRoYXQgdG8gdXNlIG5vcm1hbDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgZXRoZXJuZXQgbWFjYWRkcmVzcyBzd2l0Y2hpbmcu
IFNvIG9mIGNvdXJzZSB5b3UgZG8gbm90IHdhbnQgdG8gaGF2ZSB0bzwvRk9OVD48QlI+PEZPTlQg
U0laRT00PiZndDsgY2hvb3NlIGJldHdlZW4gdmxhbiBhbmQgZ21wbHMsIHlvdSB3b3VsZCB3YW50
IGJvdGggYXQgdGhlIHNhbWUgdGltZS48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IDwvRk9O
VD48QlI+PEZPTlQgU0laRT00PiZndDsgL3BlcjwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsg
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7
ICZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgL0xvYTwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiZndDsgJmd0OzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBQJmF1
bWw7ciBNYXR0c3NvbiB3cm90ZTo8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7
Jmd0O2hpIHBhciwgb25lIG9mIHRoZSBwb3NzaWJpbGl0aWVzIHRoYXQgaGFzIGJlZW4gY29uc2lk
ZXJlZCB0byBjb3BlIHdpdGg8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0
O3RoaXMgcmVxdWlyZW1lbnQgaXMgdG8gdXNlIGEgZGVkaWNhdGVkIFRQSUQgZm9yIHRoZSBFdGhl
cm5ldCBsYWJlbGVkPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZndDtmcmFt
ZXM7IHRoaXMgd291bGQgYWxsb3cgZGlmZmVyZW50aWF0ZWQgcHJvY2Vzc2luZyB3aXRoIG5vbi1s
YWJlbGVkPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZndDtmcmFtZXN0aGFu
a3MuPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OzwvRk9OVD48QlI+PEZPTlQg
U0laRT00PiZndDsgJmd0OyZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7
IFRoYXQgc2VlbXMgdG8gbWFrZSBtb3JlIHNlbmNlLiBJZiB0aGF0IGZyYW1lIGlzIHRvIGJlIHNp
emVkIGxpa2UgYTwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgODAyLjFxPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBmcmFtZS4gVGhlcmUgaXMgbm90IHRo
YXQgbXVjaCBzcGFjZSBsZWZ0IHRvIGEgbGFiZWwuIE9yIGlzIHRoZSBkZW1hbmQgdG88L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IHVzZSBqdW1ib2ZyYW1lcyA/PC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBIYXMgdGhlcmUgYmVlbiBhbnkgZGlzY3Vzc2lv
biBvbiBsYWJlbHN0YWNraW5nLCBhbmQgbWFpbmx5IHdoZXJlIHRvPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBwbGFjZTwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0
OyZndDsgdGhlIGluZm9ybWF0aW9uPzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZn
dDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IFJlZ2FyZHMuPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBQZXI8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4m
Z3Q7ICZndDsmZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OzwvRk9OVD48
QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7
ICZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDsgLS08L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgTG9hIEFu
ZGVyc3NvbjwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OzwvRk9OVD48QlI+PEZPTlQg
U0laRT00PiZndDsgJmd0OyBQcmluY2lwYWwgTmV0d29ya2luZyBBcmNoaXRlY3Q8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgQWNyZW8gQUImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgcGhvbmU6Jm5ic3A7ICs0NiA4IDYzMiA3NyAxNDwvRk9OVD48QlI+
PEZPTlQgU0laRT00PiZndDsgJmd0OyBJc2Fmam9yZHNnYXRhbiAyMiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtb2JpbGU6ICs0NiA3MzkgODEgMjEgNjQ8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgS2lzdGEsIFN3ZWRlbiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBl
bWFpbDombmJzcDsgPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFp
bHRvOmxvYS5hbmRlcnNzb25AYWNyZW8uc2U+bG9hLmFuZGVyc3NvbkBhY3Jlby5zZTwvQT48L1U+
PC9GT05UPjxGT05UIENPTE9SPUJMQUNLPjxCUj48L0ZPTlQ+PEZPTlQgU0laRT00PiZndDsgJmd0
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+PEZPTlQgU0laRT00
IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86bG9hQHBpLnNlPmxvYUBwaS5zZTwvQT48L1U+
PC9GT05UPjxGT05UIENPTE9SPUJMQUNLPjxCUj48L0ZPTlQ+PEZPTlQgU0laRT00PiZndDsgJmd0
OzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZn
dDsgPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT01Pj09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvRk9OVD48QlI+PEZPTlQgU0laRT01
PlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBwcml2aWxl
Z2VkPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+YW5kIGNvbmZpZGVudGlhbCBhbmQgcHJvdGVjdGVk
IGZyb20gZGlzY2xvc3VyZS4gSWYgdGhlIHJlYWRlcjwvRk9OVD48QlI+PEZPTlQgU0laRT01Pm9m
IHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgb3IgYW4gZW1wbG95
ZWU8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT5vciBhZ2VudCByZXNwb25zaWJsZSBmb3IgZGVsaXZl
cmluZyB0aGlzIG1lc3NhZ2UgdG8gdGhlPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+aW50ZW5kZWQg
cmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSByZXByb2R1Y3Rpb24s
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+ZGlzc2VtaW5hdGlvbiBvciBkaXN0cmlidXRpb24gb2Yg
dGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5PC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+cHJv
aGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y
LDwvRk9OVD48QlI+PEZPTlQgU0laRT01PnBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkg
cmVwbHlpbmcgdG8gdGhlIG1lc3NhZ2UgYW5kPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+ZGVsZXRp
bmcgaXQgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuIFRlbGxhYnM8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9NT49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT08L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQgRkFDRT0iTW9ub3NwYWNl
LENvdXJpZXIiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PTwvRk9OVD48QlI+PEZPTlQgU0laRT00IEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy
aWVyIj5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgcHJp
dmlsZWdlZDwvRk9OVD48QlI+PEZPTlQgU0laRT00IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5h
bmQgY29uZmlkZW50aWFsIGFuZCBwcm90ZWN0ZWQgZnJvbSBkaXNjbG9zdXJlLiBJZiB0aGUgcmVh
ZGVyPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPm9mIHRo
aXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgb3IgYW4gZW1wbG95ZWU8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+b3IgYWdlbnQg
cmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdGhpcyBtZXNzYWdlIHRvIHRoZTwvRk9OVD48QlI+
PEZPTlQgU0laRT00IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5pbnRlbmRlZCByZWNpcGllbnQs
IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHJlcHJvZHVjdGlvbiw8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9NCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+ZGlzc2VtaW5hdGlvbiBvciBk
aXN0cmlidXRpb24gb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5PC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnByb2hpYml0ZWQuIElmIHlvdSBo
YXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciw8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9NCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+cGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlh
dGVseSBieSByZXBseWluZyB0byB0aGUgbWVzc2FnZSBhbmQ8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
NCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+ZGVsZXRpbmcgaXQgZnJvbSB5b3VyIGNvbXB1dGVy
LiBUaGFuayB5b3UuIFRlbGxhYnM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NCBGQUNFPSJNb25vc3Bh
Y2UsQ291cmllciI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PC9GT05UPjxCUj48L1A+



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 18:28:24 +0000
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, "Adrian Farrel" <[e-mail]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>, "Loa Andersson" <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 20:27:34 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmlnb3IgPEJSPjxCUj4mZ3Q7IFRoZSBx
dWVzdGlvbiBpcyBzaW1wbGU6IGlzIGl0IHBvc3NpYmxlIHRvZGF5IHRvIHN0YXRpY2FsbHkgcHJv
dmlzaW9uIEwyTFNQcyB0aGF0IGNvdWxkLCBzYXksJm5ic3A7c3VwcG9ydCBlMmUgUW9TPzwvRk9O
VD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPltkcF0gaSBzdWdnZXN0IHlv
dSB0YWtlIGEgbG9vayBhdCB0aGUgcHJvcG9zZWQgc2NlbmFyaW9zIG9mIHRoaXMgZG9jdW1lbnQ8
L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7IElmIG5vdCwg
bWF5IGJlIGl0IGlzIHRvIGVhcmx5IHRvIGRpc2N1c3MgYXNwZWN0cyBvZiBkeW5hbWljIHByb3Zp
c2lvbmluZyBvZiBzdWNoIExTUHM/IDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNl
LENvdXJpZXIiPiZndDsgSXMgaXQgcG9zc2libGUvcmVhc29uYWJsZSwgaW4geW91ciBvcGluaW9u
LCB0byAmcXVvdDtkZXRhaWwgaG93IGZvcndhcmRpbmcgaW5mb3JtYXRpb24gY2FuIGJlIGV4Y2hh
bmdlZCB2aWEgdGhlIDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi
PiZndDsgY29udHJvbCBwbGFuZSAoYW5kIHRoZW4gaW5zdGFsbGVkKSZxdW90OyB3aXRob3V0Jm5i
c3A7aGF2aW5nIGluIG1pbmQgJnF1b3Q7YSBzcGVjaWZpYyBmb3J3YXJkaW5nIGJlaGF2aW9yJnF1
b3Q7PzwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPltkcF0gaSBk
b24ndCB0aGluayBhbnlvbmUgaGFzIHNhaWQgdGhlIGNvbnRyYXJ5IGJ1dCBpIGRvbid0IHRoaXMg
bWVhbnMgZGVmaW5lIGEgbmV3IGZvcndhcmRpbmcgYmVoYXZpb3VyPC9GT05UPjwvUD48UD48Rk9O
VCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OyBIb3cgZG8geW91IGtub3cgd2hpY2ggZm9y
d2FyZGluZyBpbmZvcm1hdGlvbiBpcyBuZWVkZWQgZm9yIHRoZSBmb3J3YXJkaW5nIG5vYm9keSBo
YXMgZGVmaW5lZCB5ZXQ/PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmll
ciI+Jmd0OyBUaGUgb3RoZXIgcXVlc3Rpb24gaXMmbmJzcDtkbyB3ZSBuZWVkIGF0IGFsbCBlMmUg
UW9TLCByb3V0ZSBjb250cm9sLCBmYXN0IHJlY292ZXJ5PyA8L0ZPTlQ+PC9QPjxQPjxGT05UIEZB
Q0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5bZHBdIHdoZXJlIGluIHRoZSBkb2N1bWVudCBpdCBoYXMg
YmVlbiBtZW50aW9uZWQgZTJlIFFvUyBvciBzb21ldGhpbmcgYXJvdW5kIGVuZC10by1lbmQgYmVo
YXZpb3VyIGJ1dCBwcm9iYWJseSBpIHNob3VsZCBpIGFzayB3aGF0IHlvdSBtZWFuIHdpdGggJnF1
b3Q7ZW5kLXRvLWVuZCZxdW90OyBoZXJlIDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3Nw
YWNlLENvdXJpZXIiPiZndDsgU291bmRzIGxpa2UgZXhjaXRpbmcgaWRlYSwgYnV0IGRvZXMgYWxs
IHRoYXQgY29tbWVyY2lhbGx5IG1ha2Ugc2Vuc2U/IDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0i
TW9ub3NwYWNlLENvdXJpZXIiPiZndDsgU28sIEkgZ3Vlc3MsIHdlIG5lZWQgdHdvIHRoaW5ncyZu
YnNwO2JlZm9yZSB3ZSBjYW4mbmJzcDttb3ZlIGZvcndhcmQ6PEJSPiZndDsgYSkgdmFsaWRhdGlv
biBvZiB0aGUgaWRlYSBieSB0aGUgcHJvdmlkZXJzOzwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0i
TW9ub3NwYWNlLENvdXJpZXIiPltkcF0gaW5kZWVkLCB3ZSBkZWZpbml0ZWx5IG5lZWQgZmVlZGJh
Y2sgZnJvbSB0aGUgdXNlciBjb21tdW5pdHkgYnV0IGFsc28ga2VlcCB0aGlzIGRpc2N1c3Npb24g
aW4gdGhlIGlldGYgY29udGV4dCAoZnlpOiAxLzMgb2YgdGhlIERUIGlzIGNvbnN0aXR1ZWQgYnkg
aW5kaXZpZHVhbHMgcGFydCBvZiB0aGUgdXNlciBjb21tdW5pdHkpPC9GT05UPjwvUD48UD48Rk9O
VCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OyBiKSBkZWZpbml0aW9uIG9mIHRoZSBkYXRh
IHBsYW5lIGJlaGF2aW9yOzwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJp
ZXIiPltkcF0gd2UgZG8gbm90IG5lZWQgYSBkZWZpbml0aW9uIG9mIHRoZSBkYXRhIHBsYW5lIGJl
aGF2aW91ciB3ZSBkbyBuZWVkIHRvIGlkZW50aWZ5IHRoZSByZWxldmFudCBiZWhhdmlvdXIgZm9y
IHdoaWNoIEdNUExTIGNvbnRyb2wgcGxhbmUgd2lsbCBiZSB1c2VkIGZvciBleGNoYW5naW5nIHRo
ZSBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIDxCUj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4tLS0t
LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PjxCPkZyb206
PC9CPiA8L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86RGlt
aXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmU+RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0
ZWwuYmU8L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDwvRk9OVD48QlI+
PEZPTlQgU0laRT00PjxCPlRvOjwvQj4gPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVFPjxV
PjxBIEhSRUY9bWFpbHRvOmlicnlza2luQG1vdmF6LmNvbT5JZ29yIEJyeXNraW48L0E+PC9VPjwv
Rk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PjxC
PkNjOjwvQj4gPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRv
OkJlbi5NYWNrLUNyYW5lQHRlbGxhYnMuY29tPk1hY2stQ3JhbmUsIFQuIEJlbmphbWluPC9BPjwv
VT48L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMQUNLPiA7IDwvRk9OVD48Rk9OVCBTSVpFPTQg
Q09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPkFkcmlhbiBG
YXJyZWw8L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDsgPC9GT05UPjxG
T05UIFNJWkU9NCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOnBlckBkZWZlcm8uc2U+UCZh
dW1sO3IgTWF0dHNzb248L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDsg
PC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOmxvYUBwaS5z
ZT5Mb2EgQW5kZXJzc29uPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMQUNLPiA7
IDwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpjY2FtcEBv
cHMuaWV0Zi5vcmc+Y2NhbXBAb3BzLmlldGYub3JnPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0laRT00
IENPTE9SPUJMQUNLPiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND48Qj5TZW50OjwvQj4gRnJpZGF5
LCBKdWx5IDIyLCAyMDA1IDEyOjIxIFBNPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+PEI+U3ViamVj
dDo8L0I+IFJlOiBGcmFtZWZvcm1hdCBpbiBhIGwyY3MgZ21wbHMgcm52aXJvbm1lbnQuPC9GT05U
PjxCUj48QlI+PEJSPjxGT05UIFNJWkU9ND5pZ29yIC0gaSBhbSBub3Qgc3VyZSB3aGljaCBwb2lu
dCB0aGV5IGV4YWN0bHkgaGF2ZSAtIHRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8g
ZGV0YWlsIGhvdyBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGNhbiBiZSBleGNoYW5nZWQgdmlhIHRo
ZSBjb250cm9sIHBsYW5lIChhbmQgdGhlbiBpbnN0YWxsZWQpIG5vdCB0byBkZWZpbmUgYSBzcGVj
aWZpYyBmb3J3YXJkaW5nIGJlaGF2aW91cjwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND50aGFu
a3MsPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00Pi0gZGltaXRyaS48L0ZPTlQ+PEJSPjxCUj48
Qj4mcXVvdDtJZ29yIEJyeXNraW4mcXVvdDsgJmx0OzwvQj48Rk9OVCBDT0xPUj1CTFVFPjxCPjxV
PjxBIEhSRUY9bWFpbHRvOmlicnlza2luQG1vdmF6LmNvbT5pYnJ5c2tpbkBtb3Zhei5jb208L0E+
PC9VPjwvQj48L0ZPTlQ+PEZPTlQgQ09MT1I9QkxBQ0s+PEI+Jmd0OzwvQj48QlI+U2VudCBieTog
PC9GT05UPjxGT05UIENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86b3duZXItY2NhbXBAb3Bz
LmlldGYub3JnPm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvQT48L1U+PC9GT05UPjxGT05UIENP
TE9SPUJMQUNLPjxCUj4wNy8yMi8yMDA1IDExOjEwIEFTVDxCUj48QlI+VG86PC9GT05UPjxGT05U
IFNJWkU9ND4gPC9GT05UPiZxdW90O01hY2stQ3JhbmUsIFQuIEJlbmphbWluJnF1b3Q7ICZsdDs8
Rk9OVCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOkJlbi5NYWNrLUNyYW5lQHRlbGxhYnMu
Y29tPkJlbi5NYWNrLUNyYW5lQHRlbGxhYnMuY29tPC9BPjwvVT48L0ZPTlQ+PEZPTlQgQ09MT1I9
QkxBQ0s+Jmd0OywgJnF1b3Q7QWRyaWFuIEZhcnJlbCZxdW90OyAmbHQ7PC9GT05UPjxGT05UIENP
TE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az5hZHJpYW5Ab2xk
ZG9nLmNvLnVrPC9BPjwvVT48L0ZPTlQ+PEZPTlQgQ09MT1I9QkxBQ0s+Jmd0OywgUCZhdW1sO3Ig
TWF0dHNzb24gJmx0OzwvRk9OVD48Rk9OVCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOnBl
ckBkZWZlcm8uc2U+cGVyQGRlZmVyby5zZTwvQT48L1U+PC9GT05UPjxGT05UIENPTE9SPUJMQUNL
PiZndDssICZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsgJmx0OzwvRk9OVD48Rk9OVCBDT0xPUj1C
TFVFPjxVPjxBIEhSRUY9bWFpbHRvOmxvYUBwaS5zZT5sb2FAcGkuc2U8L0E+PC9VPjwvRk9OVD48
Rk9OVCBDT0xPUj1CTEFDSz4mZ3Q7PEJSPmNjOjwvRk9OVD48Rk9OVCBTSVpFPTQ+IDwvRk9OVD4m
bHQ7PEZPTlQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpjY2FtcEBvcHMuaWV0Zi5vcmc+
Y2NhbXBAb3BzLmlldGYub3JnPC9BPjwvVT48L0ZPTlQ+PEZPTlQgQ09MT1I9QkxBQ0s+Jmd0OzxC
Uj5iY2M6PC9GT05UPjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj5TdWJqZWN0OjxGT05UIFNJWkU9
ND4gPC9GT05UPlJlOiBGcmFtZWZvcm1hdCBpbiBhIGwyY3MgZ21wbHMgcm52aXJvbm1lbnQuPEJS
PjxCUj48QlI+PEZPTlQgU0laRT00PkhpLDwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND5JIHRo
aW5rIEJlbiBhbmQgSnVlcmdlbiBoYXZlIGEgcG9pbnQgaGVyZS4gVGhlcmUgaXMgbm90aGluZyB0
aGF0IGNvdWxkIGJlIGR5bmFtaWNhbGx5IHByb3Zpc2lvbmVkIHRoYXQgY291bGQgbm90IGJlIGFs
c28gcHJvdmlzaW9uZWQgYnkgbWFuYWdlbWVudC4gSW4gb3RoZXIgd29yZHMgZGF0YSBwbGFuZSBp
cyB0aGUgS2luZyBoZXJlLiBXZSBuZWVkIGRhdGEgcGxhbmUgc3RhbmRhcmQocykgb24gaG93IHdl
IGVuY29kZSBhIGxhYmVsLCB3aGV0aGVyIHdlIG5lZWQgYSBsYWJlbCBzdGFjayBvciBub3QsIGhv
dyB0aGUgbGFiZWxlZCB0cmFmZmljIGlzIHN1cHBvc2VkIHRvIGJlJm5ic3A7dHJlYXRlZCwgaG93
IGxhYmVsZWQgdHJhZmZpYyBjby1leGlzdCB3aXRoIG5vbi1sYWJlbCB0cmFmZmljLCBldGMuIFRo
aXMgaXMgc29tZXRoaW5nIHRoYXQgbm90IGZvciBDQ0FNUCB0byBkZWZpbmUuIFRha2UgZm9yIGV4
YW1wbGUgVERNIG5ldHdvcmtzLiBHTVBMUyBvbmx5IHByb3ZpZGVzIGEgd2F5IHRvIGR5bmFtaWNh
bGx5IHByb3Zpc2lvbiBHLjcwNyBuZXR3b3Jrcy4gSGVuY2UgdGhlcmUgaXMgYSBuZWVkIGluIHBh
cmFsbGVsIHN0YW5kYXJkaXphdGlvbiBhY3Rpdml0aWVzIGluIElUVS4gT25seSBhZnRlciB0aGF0
IHdlIGNhbiBkaXNjdXNzIGhvdyBhbGwgdGhhdCBjb3VsZCBiZSBkeW5hbWljYWxseSBwcm92aXNp
b25lZCwgdGhhdCBpcyB0aGUgYXNwZWN0cyBvZiBjb250cm9sIHBsYW5lLiA8L0ZPTlQ+PEJSPjxC
Uj48Rk9OVCBTSVpFPTQ+SWdvcjwvRk9OVD48QlI+PEZPTlQgU0laRT01Pi0tLS0tIE9yaWdpbmFs
IE1lc3NhZ2UgLS0tLS0gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+PEI+RnJvbTo8L0I+IDwvRk9O
VD48Rk9OVCBTSVpFPTUgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpCZW4uTWFjay1DcmFu
ZUB0ZWxsYWJzLmNvbT5NYWNrLUNyYW5lLCBULiBCZW5qYW1pbjwvQT48L1U+PC9GT05UPjxGT05U
IFNJWkU9NSBDT0xPUj1CTEFDSz4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+PEI+VG86PC9CPiA8
L0ZPTlQ+PEZPTlQgU0laRT01IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86YWRyaWFuQG9s
ZGRvZy5jby51az5BZHJpYW4gRmFycmVsPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0laRT01IENPTE9S
PUJMQUNLPiA7IDwvRk9OVD48Rk9OVCBTSVpFPTUgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0
bzpwZXJAZGVmZXJvLnNlPlAmYXVtbDtyIE1hdHRzc29uPC9BPjwvVT48L0ZPTlQ+PEZPTlQgU0la
RT01IENPTE9SPUJMQUNLPiA7IDwvRk9OVD48Rk9OVCBTSVpFPTUgQ09MT1I9QkxVRT48VT48QSBI
UkVGPW1haWx0bzpsb2FAcGkuc2U+TG9hIEFuZGVyc3NvbjwvQT48L1U+PC9GT05UPjxGT05UIFNJ
WkU9NSBDT0xPUj1CTEFDSz4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+PEI+Q2M6PC9CPiA8L0ZP
TlQ+PEZPTlQgU0laRT01IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86Y2NhbXBAb3BzLmll
dGYub3JnPmNjYW1wQG9wcy5pZXRmLm9yZzwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NSBDT0xP
Uj1CTEFDSz4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+PEI+U2VudDo8L0I+IEZyaWRheSwgSnVs
eSAyMiwgMjAwNSAxMDoyMyBBTTwvRk9OVD48QlI+PEZPTlQgU0laRT01PjxCPlN1YmplY3Q6PC9C
PiBSRTogRnJhbWVmb3JtYXQgaW4gYSBsMmNzIGdtcGxzIHJudmlyb25tZW50LjwvRk9OVD48QlI+
PEJSPjxGT05UIFNJWkU9ND5IaSw8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+SSB0aGluayBK
dWVyZ2VuIGhhcyByYWlzZWQgYW4gaW1wb3J0YW50IHF1ZXN0aW9uLiZuYnNwOyBIb3cgZnJhbWVz
IGFyZSBsYWJlbGVkIChhbmQgdGhlIHJlbGF0ZWQgZGF0YSBwbGFuZSBmb3J3YXJkaW5nIGJlaGF2
aW9yKSBpcyBub3QgZGVmaW5lZCBieSB0aGUgY29udHJvbCBwbGFuZS4mbmJzcDsgVGhlIGNvbnRy
b2wgcGxhbmUgc2VydmVzIHRvIHByb3Zpc2lvbiB0aGUgZGF0YSBwbGFuZSwgbm90IGRlZmluZSBp
dC4mbmJzcDsgSW4gdGhlIGZyYW1ld29yayBkcmFmdCBpdCBpcyBub3QgY2xlYXIgd2hhdCBkYXRh
IHBsYW5lIHN0YW5kYXJkcyBhcmUgY292ZXJlZCBieSB0aGUgc3RhdGVkIGNvbnRyb2wgcGxhbmUg
cmVxdWlyZW1lbnRzLiZuYnNwOyBTb21lIHJlZmVyZW5jZXMgc2hvdWxkIGJlIHN1cHBsaWVkLiZu
YnNwOyBJbiBhbnkgY2FzZSwgdGhlIGxhYmVsaW5nIGFuZCBmb3J3YXJkaW5nIGJlaGF2aW9yIHNo
b3VsZCBiZSBkZWZpbmVkJm5ic3A7YnkgdGhlc2UgcmVmZXJlbmNlZCBzdGFuZGFyZHMsIG5vdCZu
YnNwO2J5IEdNUExTLjwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND4oSSBhbSBhc3N1bWluZyBk
ZWZpbml0aW9uIG9mIG5ldyBkYXRhIHBsYW5lIHN0YW5kYXJkcyBpcyBvdXQgb2Ygc2NvcGUgZm9y
IENDQU1QLik8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+UmVnYXJkcyw8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND5CZW48L0ZPTlQ+PEJSPjxIUiBXSURUSD0iOTklIiBTSVpFPSI4IiBBTElHTj0i
bGVmdCI+PEZPTlQgQ09MT1I9QkxBQ0s+PEJSPjwvRk9OVD48Rk9OVCBTSVpFPTQ+PEI+RnJvbTo8
L0I+IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRm
Lm9yZ10gPEI+T24gQmVoYWxmIE9mIDwvQj5BZHJpYW4gRmFycmVsPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+PEI+U2VudDo8L0I+IEZyaWRheSwgSnVseSAyMiwgMjAwNSA4OjM3IEFNPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+PEI+VG86PC9CPiBQJmF1bWw7ciBNYXR0c3NvbjsgTG9hIEFuZGVyc3Nv
bjwvRk9OVD48QlI+PEZPTlQgU0laRT00PjxCPkNjOjwvQj4gY2NhbXBAb3BzLmlldGYub3JnPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+PEI+U3ViamVjdDo8L0I+IFJlOiBGcmFtZWZvcm1hdCBpbiBh
IGwyY3MgZ21wbHMgcm52aXJvbm1lbnQuPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PkhpLDwv
Rk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND5JdCBpcyBhbHdheXMgcmVmcmVzaGluZyBob3cgZW5n
aW5lZXJzIGp1bXAgc3RyYWlnaHQgdG8gYSBkaXNjdXNzaW9uIG9mIHRoZSBzb2x1dGlvbiA6LSk8
L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+UGVyaGFwcyB3ZSBjYW4gYXNzdW1lIHRoYXQgdGhl
IGZyYW1ld29yayBkcmFmdCBpcyBhIGdvb2QgcmVwcmVzZW50YXRpb24gb2YgdGhlIHByb2JsZW0g
c3BhY2UsIGFuZCB0aGF0IHdlIGFyZSByZWFkeSB0byBzdGFydCBkaXNjdXNzaW5nIHRoZSBzb2x1
dGlvbnMuPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00Pk9uZSAocGVyaGFwcyB0aGUgb25seT8p
IHNpZ25pZmljYW50IHF1ZXN0aW9uIHRvIGFuc3dlciBpcyBob3cgdGhlIGZyYW1lcyB3aWxsIGJl
IGxhYmVsbGVkLiBUaGlzIHF1ZXN0aW9uIGlzIG9uZSB3ZSBtdXN0IGNvbWUgdG8gYXMgc29vbiBh
cyB3ZSBhcmUgY29uZmlkZW50IHRoYXQgdGhlIHJlcXVpcmVtZW50cyBuZWVkIHRvIGJlIGFkZHJl
c3NlZCBhdCBhbGwuPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PkFzIGhhcyBiZWVuIHBvaW50
ZWQgb3V0LCB0aGVyZSBhcmUgc2V2ZXJhbCBwb3NzaWJpbGl0aWVzIGFuZCB0byBwaWNrIGZyb20g
dGhlc2Ugd2UgbmVlZCB0byB1bmRlcnN0YW5kOjwvRk9OVD48QlI+PEZPTlQgU0laRT00PjEuIERv
IHdlIG5lZWQgdG8gc3VwcG9ydCBleHBsaWNpdCBsYWJlbCBzdGFja2luZz88L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mbmJzcDsmbmJzcDsgTm90ZSB0aGF0IHRoaXMgaXMgbm90IHN1cHBvcnRlZCBp
biBURE0sIExTQyBvciBGU0MuPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Mi4gRG8gd2UgbmVlZCB0
byBiZSBhYmxlIHRvIGNvbnRyb2wgKHBlcmhhcHMgdGhyb3VnaCBhbjwvRk9OVD48QlI+PEZPTlQg
U0laRT00PiZuYnNwOyZuYnNwOyZuYnNwO2V4dGVybmFsIHNpZ25hbGluZyBjb250cm9sbGVyKSBl
eGlzdGluZyBoYXJkd2FyZSBhbmQgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jm5ic3A7Jm5ic3A7
IGluc3RhbGwgTFNQcyB0aHJvdWdoIGV4aXN0aW5nIG5ldHdvcmtzPzwvRk9OVD48QlI+PEZPTlQg
U0laRT00PjMuIERvIHdlIG5lZWQgdG8gc3VwcG9ydCBleGlzdGluZyBmdW5jdGlvbiBzaW11bHRh
bmVvdXMgdG88L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mbmJzcDsmbmJzcDsgdGhlIHN1cHBvcnQg
b2YgR01QTFMgTDIgTFNQcz88L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+SSB0aGluayB0aGF0
IGZyb20gYSBjaGFpcidzIHBlcnNwZWN0aXZlIEkgY2FuIGdpdmUgc29tZSBsaW1pdGVkIGd1aWRh
bmNlLjwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND5BLiBUaGVzZSBxdWVzdGlvbnMgbXVzdCBi
ZSByYWlzZWQgYW5kIGFuc3dlcmVkIGluIHRoZSBmcmFtZXdvcmsgSS1EPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Qi4gVGhlIGFuc3dlciB0byBxdWVzdGlvbiAzIGlzICZxdW90O3llcyZxdW90Oy4g
VGhpcyBtZWFucyB0aGF0IHRoZSB1c2Ugb2YgbGFiZWxzPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jm5ic3A7Jm5ic3A7IG11c3Qgbm90IHNpZ25pZmljYW50bHkgZGVwbGV0ZSBhbnkgbmFtZXNwYWNl
IHVzZWQgdG8gc3VwcG9ydCBvdGhlcjwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZuYnNwOyZuYnNw
OyBmdW5jdGlvbi48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5DLiBDQ0FNUCBpcyBjaGFydGVyZWQg
dG8gbG9vayBhdCB0aGUgY29udHJvbCBvZiB0cmFuc3BvcnQgbmV0d29ya3MuIFRoaXM8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mbmJzcDsmbmJzcDsmbmJzcDtpbmNsdWRlcyBNZXRybywgYnV0IEkg
YW0gdW5zdXJlIGFib3V0IENhbXB1cy4gSXQgZG9lcyBub3QmbmJzcDtjb3ZlciA8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND4mbmJzcDsmbmJzcDsgc2lnbmFsaW5nIHRvIHRoZSBkZXNrdG9wLjwvRk9O
VD48QlI+PEJSPjxGT05UIFNJWkU9ND5UaGFua3MsPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+QWRy
aWFuPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t
LS0gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+RnJvbTogJnF1b3Q7UCZhdW1sO3IgTWF0dHNzb24m
cXVvdDsgJmx0OzwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0
bzpwZXJAZGVmZXJvLnNlPnBlckBkZWZlcm8uc2U8L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTQg
Q09MT1I9QkxBQ0s+Jmd0OzwvRk9OVD48QlI+PEZPTlQgU0laRT00PlRvOiAmcXVvdDtMb2EgQW5k
ZXJzc29uJnF1b3Q7ICZsdDs8L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMVUU+PFU+PEEgSFJF
Rj1tYWlsdG86bG9hQHBpLnNlPmxvYUBwaS5zZTwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NCBD
T0xPUj1CTEFDSz4mZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Q2M6ICZsdDs8L0ZPTlQ+PEZP
TlQgU0laRT00IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86Y2NhbXBAb3BzLmlldGYub3Jn
PmNjYW1wQG9wcy5pZXRmLm9yZzwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTEFD
Sz4mZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+U2VudDogRnJpZGF5LCBKdWx5IDIyLCAyMDA1
IDExOjQxIEFNPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+U3ViamVjdDogUmU6IEZyYW1lZm9ybWF0
IGluIGEgbDJjcyBnbXBscyBybnZpcm9ubWVudC48L0ZPTlQ+PEJSPjxCUj48QlI+PEZPTlQgU0la
RT00PiZndDsgJmd0OyBQZXIgYW5kIERpbWl0cmksPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyAmZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IEkgd291bGQgbGlrZSB0byBj
b21lIGRvd24gc3Ryb25nZXIgdGhhbiB0aGF0LCBmb3IgbWUgaXQgaXM8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7ICZndDsgYSB2ZXJ5IHN0cm9uZyByZXF1aXJlbWVudCB0aGF0IHRoZSBzYW1l
IHN3aXRjaCBjYW4gaGFuZGxlPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IGJvdGgg
VkxBTnMgYW5kIEdNUExzIHRyYWZpYyBjb3JyZWN0bHkuIEkgY2FuJ3QgZHNlZSBob3cgdGhhdDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBjb3VsZCBiZSBkb25lIGlmIHVzaW5nIHRo
ZSBWTEFOIHRwaWQgdG8gaW5kaWNhdGUgR01QTFM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7
ICZndDsgdHJhZmZpYy48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IDwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiZndDsgSWYgeW91IGV2ZXIgd2FudCB0aGF0IHNhbWUgc3dpdGNoIHRvIGhhbmRs
ZSB0cmFmZmljIGZvciBhIGRpcmVjdGx5PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBjb25u
ZWN0ZWQmbmJzcDsgaG9zdCAobm90IHRvIHVuY29tbWVuKSB5b3Ugd291bGQgd2FudCB0aGF0IHRv
IHVzZSBub3JtYWw8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IGV0aGVybmV0IG1hY2FkZHJl
c3Mgc3dpdGNoaW5nLiBTbyBvZiBjb3Vyc2UgeW91IGRvIG5vdCB3YW50IHRvIGhhdmUgdG88L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IGNob29zZSBiZXR3ZWVuIHZsYW4gYW5kIGdtcGxzLCB5
b3Ugd291bGQgd2FudCBib3RoIGF0IHRoZSBzYW1lIHRpbWUuPC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQ+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IC9wZXI8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyAmZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IC9Mb2E8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4m
Z3Q7ICZndDsgUCZhdW1sO3IgTWF0dHNzb24gd3JvdGU6PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyAmZ3Q7Jmd0OyZndDtoaSBwYXIsIG9uZSBvZiB0aGUgcG9zc2liaWxpdGllcyB0aGF0IGhh
cyBiZWVuIGNvbnNpZGVyZWQgdG8gY29wZSB3aXRoPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyAmZ3Q7Jmd0OyZndDt0aGlzIHJlcXVpcmVtZW50IGlzIHRvIHVzZSBhIGRlZGljYXRlZCBUUElE
IGZvciB0aGUgRXRoZXJuZXQgbGFiZWxlZDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0
OyZndDsmZ3Q7ZnJhbWVzOyB0aGlzIHdvdWxkIGFsbG93IGRpZmZlcmVudGlhdGVkIHByb2Nlc3Np
bmcgd2l0aCBub24tbGFiZWxlZDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsm
Z3Q7ZnJhbWVzdGhhbmtzLjwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDs8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyAmZ3Q7Jmd0OyBUaGF0IHNlZW1zIHRvIG1ha2UgbW9yZSBzZW5jZS4gSWYgdGhhdCBmcmFt
ZSBpcyB0byBiZSBzaXplZCBsaWtlIGE8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsm
Z3Q7IDgwMi4xcTwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgZnJhbWUuIFRo
ZXJlIGlzIG5vdCB0aGF0IG11Y2ggc3BhY2UgbGVmdCB0byBhIGxhYmVsLiBPciBpcyB0aGUgZGVt
YW5kIHRvPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyB1c2UganVtYm9mcmFt
ZXMgPzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgSGFzIHRoZXJlIGJlZW4g
YW55IGRpc2N1c3Npb24gb24gbGFiZWxzdGFja2luZywgYW5kIG1haW5seSB3aGVyZSB0bzwvRk9O
VD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgcGxhY2U8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDsmZ3Q7IHRoZSBpbmZvcm1hdGlvbj88L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7ICZndDsmZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBSZWdh
cmRzLjwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgUGVyPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0
OyZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7PC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyAmZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7PC9GT05U
PjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IC0tPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyAmZ3Q7IExvYSBBbmRlcnNzb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDs8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgUHJpbmNpcGFsIE5ldHdvcmtpbmcgQXJjaGl0
ZWN0PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IEFjcmVvIEFCJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBob25lOiZuYnNwOyArNDYgOCA2MzIgNzcg
MTQ8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgSXNhZmpvcmRzZ2F0YW4gMjImbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbW9iaWxlOiArNDYgNzM5
IDgxIDIxIDY0PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IEtpc3RhLCBTd2VkZW4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgZW1haWw6Jm5ic3A7IDwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxVRT48
VT48QSBIUkVGPW1haWx0bzpsb2EuYW5kZXJzc29uQGFjcmVvLnNlPmxvYS5hbmRlcnNzb25AYWNy
ZW8uc2U8L0E+PC9VPjwvRk9OVD48Rk9OVCBDT0xPUj1CTEFDSz48QlI+PC9GT05UPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05U
PjxGT05UIFNJWkU9NCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOmxvYUBwaS5zZT5sb2FA
cGkuc2U8L0E+PC9VPjwvRk9OVD48Rk9OVCBDT0xPUj1CTEFDSz48QlI+PC9GT05UPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IDwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyA8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mZ3Q7IDwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9NT49PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9NT5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBt
YXkgYmUgcHJpdmlsZWdlZDwvRk9OVD48QlI+PEZPTlQgU0laRT01PmFuZCBjb25maWRlbnRpYWwg
YW5kIHByb3RlY3RlZCBmcm9tIGRpc2Nsb3N1cmUuIElmIHRoZSByZWFkZXI8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9NT5vZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs
IG9yIGFuIGVtcGxveWVlPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+b3IgYWdlbnQgcmVzcG9uc2li
bGUgZm9yIGRlbGl2ZXJpbmcgdGhpcyBtZXNzYWdlIHRvIHRoZTwvRk9OVD48QlI+PEZPTlQgU0la
RT01PmludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkg
cmVwcm9kdWN0aW9uLDwvRk9OVD48QlI+PEZPTlQgU0laRT01PmRpc3NlbWluYXRpb24gb3IgZGlz
dHJpYnV0aW9uIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseTwvRk9OVD48QlI+PEZP
TlQgU0laRT01PnByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNh
dGlvbiBpbiBlcnJvciw8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT5wbGVhc2Ugbm90aWZ5IHVzIGlt
bWVkaWF0ZWx5IGJ5IHJlcGx5aW5nIHRvIHRoZSBtZXNzYWdlIGFuZDwvRk9OVD48QlI+PEZPTlQg
U0laRT01PmRlbGV0aW5nIGl0IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91LiBUZWxsYWJz
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9GT05UPjxCUj48L1A+



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 18:27:45 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58EEA.DBC1A8EF"
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 13:25:06 -0500
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
Thread-Index: AcWO4Z/sn5bUTdc8RiiIwKwSk2UxnAACGn2Q
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>, "Loa Andersson" <[e-mail]>, <[e-mail]>

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:[e-mail]]=20
	Sent: Friday, July 22, 2005 12:20 PM
	To: [e-mail]
	Cc: Mack-Crane, T. Benjamin; Adrian Farrel; P=E4r Mattsson; Loa Andersson;=
 [e-mail]
	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: [e-mail]=20
		To: Igor Bryskin <mailto:[e-mail]> =20
		Cc: Mack-Crane, T. Benjamin <mailto:[e-mail]>  ; Adrian=
 Farrel <mailto:[e-mail]>  ; P=E4r Mattsson <mailto:per@defero.s=
e>  ; Loa Andersson <mailto:[e-mail]>  ; [e-mail]=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" <[e-mail]>
		Sent by: [e-mail]
		07/22/2005 11:10 AST
	=09
		To: "Mack-Crane, T. Benjamin" <[e-mail]>, "Adrian Farre=
l" <[e-mail]>, P=E4r Mattsson <[e-mail]>, "Loa Andersson" <=
[e-mail]>
		cc: <[e-mail]>
		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:[e-mail]> =20
		To: Adrian Farrel <mailto:[e-mail]>  ; P=E4r Mattsson <mailto:=
[e-mail]>  ; Loa Andersson <mailto:[e-mail]> =20
		Cc: [e-mail]=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: [e-mail] [mailto:[e-mail]] On Behal=
f Of Adrian Farrel
		Sent: Friday, July 22, 2005 8:37 AM
		To: P=E4r Mattsson; Loa Andersson
		Cc: [e-mail]
		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" <[e-mail]>
		To: "Loa Andersson" <[e-mail]>
		Cc: <[e-mail]>
		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:  [phone]
		> > Isafjordsgatan 22                  mobile: [phone]
		> > Kista, Sweden                      email:  [e-mail]
		> >                                             [e-mail]
		> >
		>=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
  [e-mail]<BR><B>Cc:</B> Mack-Crane, T. Benjamin; A=
drian=20
  Farrel; P=E4r Mattsson; Loa Andersson; [e-mail]<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=[e-mail]=20
    href=3D"mailto:[e-mail]">Dimitri.Papadimitriou@=
alcatel.be</A>=20
    </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=[e-mail]=
m=20
    href=3D"mailto:[e-mail]">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:[e-mail]">Mack-Crane, T. Benjamin</A> =
; <A=20
    title=[e-mail] href=3D"mailto:[e-mail]">Adrian=20
    Farrel</A> ; <A title=[e-mail] href=3D"mailto:[e-mail]">P=
=E4r=20
    Mattsson</A> ; <A title=[e-mail] href=3D"mailto:[e-mail]">Loa Ander=
sson</A>=20
    ; <A title=[e-mail]=20
    href=3D"mailto:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</A>&gt;</B></FONT=
><BR><FONT=20
    size=3D2>Sent by: <A=20
    href=3D"mailto:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</=
A>&gt;,=20
    "Adrian Farrel" &lt;<A=20
    href=3D"mailto:[e-mail]">[e-mail]</A>&gt;, P=E4r =
Mattsson=20
    &lt;<A href=3D"mailto:[e-mail]">[e-mail]</A>&gt;, "Loa Anders=
son"=20
    &lt;<A href=3D"mailto:[e-mail]">[e-mail]</A>&gt;</FONT><BR><FONT=20
    size=3D2>cc:</FONT> <FONT size=3D2>&lt;<A=20
    href=3D"mailto:[e-mail]">[e-mail]</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:[e-mail]">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:[e-mail]">Adrian Farrel</A></U></FONT><FONT=20
    color=3Dblack size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A=20
    href=3D"mailto:[e-mail]">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:[e-mail]">[e-mail]</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> [e-mail]=20
    [mailto:[e-mail]] <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> [e-mail]<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:[e-mail]">[e-mail]</A></U></FONT><FONT=20
    color=3Dblack>&gt;<BR>To: "Loa Andersson" &lt;</FONT><FONT color=3Dblue=
><U><A=20
    href=3D"mailto:[e-mail]">[e-mail]</A></U></FONT><FONT=20
    color=3Dblack>&gt;<BR>Cc: &lt;</FONT><FONT color=3Dblue><U><A=20
    href=3D"mailto:[e-mail]">[e-mail]</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; [phone]<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: [phone]<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:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</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--



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 18:12:35 +0000
Message-ID: <001901c58ee9$0be728f0$b7849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
Date: Fri, 22 Jul 2005 19:13:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

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: <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Heiles Juergen
> Sent: 22 July 2005 14:17
> To: Loa Andersson; Pär Mattsson
> Cc: [e-mail]
> 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
>
>
>
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Loa Andersson
> > Sent: Friday, July 22, 2005 12:05 PM
> > To: Pär Mattsson
> > Cc: [e-mail]
> > 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:  [phone]
> > Isafjordsgatan 22                  mobile: [phone]
> > Kista, Sweden                      email:  [e-mail]
> >                                             [e-mail]
> >
>
>






Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 17:21:21 +0000
Message-ID: <017f01c58ee1$a1afdc90$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>
Cc: "Mack-Crane, T. Benjamin" <[e-mail]>, "Adrian Farrel" <[e-mail]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>, "Loa Andersson" <[e-mail]>, <[e-mail]>
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 13:19:53 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_017C_01C58EC0.0C02EAF0"

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: [e-mail]=20
  To: Igor Bryskin=20
  Cc: Mack-Crane, T. Benjamin ; Adrian Farrel ; P=E4r Mattsson ; Loa =
Andersson ; [e-mail]=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" <[e-mail]>
  Sent by: [e-mail]
  07/22/2005 11:10 AST

  To: "Mack-Crane, T. Benjamin" <[e-mail]>, "Adrian =
Farrel" <[e-mail]>, P=E4r Mattsson <[e-mail]>, "Loa =
Andersson" <[e-mail]>
  cc: <[e-mail]>
  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: [e-mail]=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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Adrian Farrel
  Sent: Friday, July 22, 2005 8:37 AM
  To: P=E4r Mattsson; Loa Andersson
  Cc: [e-mail]
  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" <[e-mail]>
  To: "Loa Andersson" <[e-mail]>
  Cc: <[e-mail]>
  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:  [phone]
  > > Isafjordsgatan 22                  mobile: [phone]
  > > Kista, Sweden                      email:  [e-mail]
  > >                                             [e-mail]
  > >
  >=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=[e-mail]=20
  =
href=3D"mailto:[e-mail]">Dimitri.Papadimitriou@al=
catel.be</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Igor Bryskin</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Mack-Crane, T. Benjamin</A> =
; <A=20
  title=[e-mail] href=3D"mailto:[e-mail]">Adrian =
Farrel</A>=20
  ; <A title=[e-mail] href=3D"mailto:[e-mail]">P=E4r =
Mattsson</A> ; <A=20
  title=[e-mail] href=3D"mailto:[e-mail]">Loa Andersson</A> ; <A=20
  title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</A>&gt;</B></FONT><=
BR><FONT=20
  size=3D2>Sent by: <A=20
  =
href=3D"mailto:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</A>=
&gt;,=20
  "Adrian Farrel" &lt;<A=20
  href=3D"mailto:[e-mail]">[e-mail]</A>&gt;, P=E4r =
Mattsson=20
  &lt;<A href=3D"mailto:[e-mail]">[e-mail]</A>&gt;, "Loa =
Andersson"=20
  &lt;<A href=3D"mailto:[e-mail]">[e-mail]</A>&gt;</FONT><BR><FONT=20
  size=3D2>cc:</FONT> <FONT size=3D2>&lt;<A=20
  =
href=3D"mailto:[e-mail]">[e-mail]</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:[e-mail]">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:[e-mail]">Adrian Farrel</A></U></FONT><FONT=20
  color=3Dblack size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A=20
  href=3D"mailto:[e-mail]">P=E4r Mattsson</A></U></FONT><FONT =
color=3Dblack=20
  size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A =
href=3D"mailto:[e-mail]">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:[e-mail]">[e-mail]</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> [e-mail]=20
  [mailto:[e-mail]] <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> =
[e-mail]<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:[e-mail]">[e-mail]</A></U></FONT><FONT=20
  color=3Dblack>&gt;<BR>To: "Loa Andersson" &lt;</FONT><FONT =
color=3Dblue><U><A=20
  href=3D"mailto:[e-mail]">[e-mail]</A></U></FONT><FONT =
color=3Dblack>&gt;<BR>Cc:=20
  &lt;</FONT><FONT color=3Dblue><U><A=20
  =
href=3D"mailto:[e-mail]">[e-mail]</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; [phone]<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: [phone]<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:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</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--




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 16:23:38 +0000
To: "Igor Bryskin" <[e-mail]>
Cc: "Mack-Crane, T. Benjamin" <[e-mail]>, "Adrian Farrel" <[e-mail]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>, "Loa Andersson" <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 18:21:14 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmlnb3IgLSBpIGFtIG5vdCBzdXJlIHdo
aWNoIHBvaW50IHRoZXkgZXhhY3RseSBoYXZlIC0gdGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVu
dCBpcyB0byBkZXRhaWwgaG93IGZvcndhcmRpbmcgaW5mb3JtYXRpb24gY2FuIGJlIGV4Y2hhbmdl
ZCB2aWEgdGhlIGNvbnRyb2wgcGxhbmUgKGFuZCB0aGVuIGluc3RhbGxlZCkgbm90IHRvIGRlZmlu
ZSBhIHNwZWNpZmljIGZvcndhcmRpbmcgYmVoYXZpb3VyPC9GT05UPjwvUD48UD48Rk9OVCBGQUNF
PSJNb25vc3BhY2UsQ291cmllciI+dGhhbmtzLDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9u
b3NwYWNlLENvdXJpZXIiPi0gZGltaXRyaS48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTI+PEI+
JnF1b3Q7SWdvciBCcnlza2luJnF1b3Q7ICZsdDtpYnJ5c2tpbkBtb3Zhei5jb20mZ3Q7PC9CPjwv
Rk9OVD48QlI+PEZPTlQgU0laRT0yPlNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwv
Rk9OVD48QlI+PEZPTlQgU0laRT0yPjA3LzIyLzIwMDUgMTE6MTAgQVNUPC9GT05UPjxCUj48QlI+
IDxGT05UIFNJWkU9Mj5Ubzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj4mcXVvdDtNYWNrLUNyYW5lLCBU
LiBCZW5qYW1pbiZxdW90OyAmbHQ7QmVuLk1hY2stQ3JhbmVAdGVsbGFicy5jb20mZ3Q7LCAmcXVv
dDtBZHJpYW4gRmFycmVsJnF1b3Q7ICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OywgUCZhdW1s
O3IgTWF0dHNzb24gJmx0O3BlckBkZWZlcm8uc2UmZ3Q7LCAmcXVvdDtMb2EgQW5kZXJzc29uJnF1
b3Q7ICZsdDtsb2FAcGkuc2UmZ3Q7PC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmNjOjwvRk9OVD4g
PEZPTlQgU0laRT0yPiZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PC9GT05UPjxCUj4gPEZPTlQg
U0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1YmplY3Q6PC9GT05UPiA8Rk9O
VCBTSVpFPTI+UmU6IEZyYW1lZm9ybWF0IGluIGEgbDJjcyBnbXBscyBybnZpcm9ubWVudC48L0ZP
TlQ+PEJSPiA8QlI+PEJSPjwvUD48UD5IaSw8QlI+PEJSPkkgdGhpbmsgQmVuIGFuZCBKdWVyZ2Vu
IGhhdmUgYSBwb2ludCBoZXJlLiBUaGVyZSBpcyBub3RoaW5nIHRoYXQgY291bGQgYmUgZHluYW1p
Y2FsbHkgcHJvdmlzaW9uZWQgdGhhdCBjb3VsZCBub3QgYmUgYWxzbyBwcm92aXNpb25lZCBieSBt
YW5hZ2VtZW50LiBJbiBvdGhlciB3b3JkcyBkYXRhIHBsYW5lIGlzIHRoZSBLaW5nIGhlcmUuIFdl
IG5lZWQgZGF0YSBwbGFuZSBzdGFuZGFyZChzKSBvbiBob3cgd2UgZW5jb2RlIGEgbGFiZWwsIHdo
ZXRoZXIgd2UgbmVlZCBhIGxhYmVsIHN0YWNrIG9yIG5vdCwgaG93IHRoZSBsYWJlbGVkIHRyYWZm
aWMgaXMgc3VwcG9zZWQgdG8gYmUmbmJzcDt0cmVhdGVkLCBob3cgbGFiZWxlZCB0cmFmZmljIGNv
LWV4aXN0IHdpdGggbm9uLWxhYmVsIHRyYWZmaWMsIGV0Yy4gVGhpcyBpcyBzb21ldGhpbmcgdGhh
dCBub3QgZm9yIENDQU1QIHRvIGRlZmluZS4gVGFrZSBmb3IgZXhhbXBsZSBURE0gbmV0d29ya3Mu
IEdNUExTIG9ubHkgcHJvdmlkZXMgYSB3YXkgdG8gZHluYW1pY2FsbHkgcHJvdmlzaW9uIEcuNzA3
IG5ldHdvcmtzLiBIZW5jZSB0aGVyZSBpcyBhIG5lZWQgaW4gcGFyYWxsZWwgc3RhbmRhcmRpemF0
aW9uIGFjdGl2aXRpZXMgaW4gSVRVLiBPbmx5IGFmdGVyIHRoYXQgd2UgY2FuIGRpc2N1c3MgaG93
IGFsbCB0aGF0IGNvdWxkIGJlIGR5bmFtaWNhbGx5IHByb3Zpc2lvbmVkLCB0aGF0IGlzIHRoZSBh
c3BlY3RzIG9mIGNvbnRyb2wgcGxhbmUuIDxCUj48QlI+SWdvcjxCUj48Rk9OVCBTSVpFPTQ+LS0t
LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND48Qj5Gcm9t
OjwvQj4gPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOkJl
bi5NYWNrLUNyYW5lQHRlbGxhYnMuY29tPk1hY2stQ3JhbmUsIFQuIEJlbmphbWluPC9BPjwvVT48
L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMQUNLPiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND48
Qj5Ubzo8L0I+IDwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0
bzphZHJpYW5Ab2xkZG9nLmNvLnVrPkFkcmlhbiBGYXJyZWw8L0E+PC9VPjwvRk9OVD48Rk9OVCBT
SVpFPTQgQ09MT1I9QkxBQ0s+IDsgPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVFPjxVPjxB
IEhSRUY9bWFpbHRvOnBlckBkZWZlcm8uc2U+UCZhdW1sO3IgTWF0dHNzb248L0E+PC9VPjwvRk9O
VD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDsgPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1C
TFVFPjxVPjxBIEhSRUY9bWFpbHRvOmxvYUBwaS5zZT5Mb2EgQW5kZXJzc29uPC9BPjwvVT48L0ZP
TlQ+PEZPTlQgU0laRT00IENPTE9SPUJMQUNLPiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND48Qj5D
Yzo8L0I+IDwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpj
Y2FtcEBvcHMuaWV0Zi5vcmc+Y2NhbXBAb3BzLmlldGYub3JnPC9BPjwvVT48L0ZPTlQ+PEZPTlQg
U0laRT00IENPTE9SPUJMQUNLPiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND48Qj5TZW50OjwvQj4g
RnJpZGF5LCBKdWx5IDIyLCAyMDA1IDEwOjIzIEFNPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+PEI+
U3ViamVjdDo8L0I+IFJFOiBGcmFtZWZvcm1hdCBpbiBhIGwyY3MgZ21wbHMgcm52aXJvbm1lbnQu
PC9GT05UPjxCUj48QlI+SGksPEJSPjxCUj5JIHRoaW5rIEp1ZXJnZW4gaGFzIHJhaXNlZCBhbiBp
bXBvcnRhbnQgcXVlc3Rpb24uJm5ic3A7IEhvdyBmcmFtZXMgYXJlIGxhYmVsZWQgKGFuZCB0aGUg
cmVsYXRlZCBkYXRhIHBsYW5lIGZvcndhcmRpbmcgYmVoYXZpb3IpIGlzIG5vdCBkZWZpbmVkIGJ5
IHRoZSBjb250cm9sIHBsYW5lLiZuYnNwOyBUaGUgY29udHJvbCBwbGFuZSBzZXJ2ZXMgdG8gcHJv
dmlzaW9uIHRoZSBkYXRhIHBsYW5lLCBub3QgZGVmaW5lIGl0LiZuYnNwOyBJbiB0aGUgZnJhbWV3
b3JrIGRyYWZ0IGl0IGlzIG5vdCBjbGVhciB3aGF0IGRhdGEgcGxhbmUgc3RhbmRhcmRzIGFyZSBj
b3ZlcmVkIGJ5IHRoZSBzdGF0ZWQgY29udHJvbCBwbGFuZSByZXF1aXJlbWVudHMuJm5ic3A7IFNv
bWUgcmVmZXJlbmNlcyBzaG91bGQgYmUgc3VwcGxpZWQuJm5ic3A7IEluIGFueSBjYXNlLCB0aGUg
bGFiZWxpbmcgYW5kIGZvcndhcmRpbmcgYmVoYXZpb3Igc2hvdWxkIGJlIGRlZmluZWQmbmJzcDti
eSB0aGVzZSByZWZlcmVuY2VkIHN0YW5kYXJkcywgbm90Jm5ic3A7YnkgR01QTFMuPEJSPjxCUj4o
SSBhbSBhc3N1bWluZyBkZWZpbml0aW9uIG9mIG5ldyBkYXRhIHBsYW5lIHN0YW5kYXJkcyBpcyBv
dXQgb2Ygc2NvcGUgZm9yIENDQU1QLik8QlI+PEJSPlJlZ2FyZHMsPEJSPkJlbjxCUj48SFIgV0lE
VEg9Ijk5JSIgU0laRT0iNCIgQUxJR049ImxlZnQiPjxGT05UIENPTE9SPUJMQUNLPjxCUj48Qj5G
cm9tOjwvQj4gb3duZXItY2NhbXBAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItY2NhbXBAb3Bz
LmlldGYub3JnXSA8Qj5PbiBCZWhhbGYgT2YgPC9CPkFkcmlhbiBGYXJyZWw8QlI+PEI+U2VudDo8
L0I+IEZyaWRheSwgSnVseSAyMiwgMjAwNSA4OjM3IEFNPEJSPjxCPlRvOjwvQj4gUCZhdW1sO3Ig
TWF0dHNzb247IExvYSBBbmRlcnNzb248QlI+PEI+Q2M6PC9CPiBjY2FtcEBvcHMuaWV0Zi5vcmc8
QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBGcmFtZWZvcm1hdCBpbiBhIGwyY3MgZ21wbHMgcm52aXJv
bm1lbnQuPEJSPjxCUj5IaSw8QlI+PEJSPkl0IGlzIGFsd2F5cyByZWZyZXNoaW5nIGhvdyBlbmdp
bmVlcnMganVtcCBzdHJhaWdodCB0byBhIGRpc2N1c3Npb24gb2YgdGhlIHNvbHV0aW9uIDotKTxC
Uj48QlI+UGVyaGFwcyB3ZSBjYW4gYXNzdW1lIHRoYXQgdGhlIGZyYW1ld29yayBkcmFmdCBpcyBh
IGdvb2QgcmVwcmVzZW50YXRpb24gb2YgdGhlIHByb2JsZW0gc3BhY2UsIGFuZCB0aGF0IHdlIGFy
ZSByZWFkeSB0byBzdGFydCBkaXNjdXNzaW5nIHRoZSBzb2x1dGlvbnMuPEJSPjxCUj5PbmUgKHBl
cmhhcHMgdGhlIG9ubHk/KSBzaWduaWZpY2FudCBxdWVzdGlvbiB0byBhbnN3ZXIgaXMgaG93IHRo
ZSBmcmFtZXMgd2lsbCBiZSBsYWJlbGxlZC4gVGhpcyBxdWVzdGlvbiBpcyBvbmUgd2UgbXVzdCBj
b21lIHRvIGFzIHNvb24gYXMgd2UgYXJlIGNvbmZpZGVudCB0aGF0IHRoZSByZXF1aXJlbWVudHMg
bmVlZCB0byBiZSBhZGRyZXNzZWQgYXQgYWxsLjxCUj48QlI+QXMgaGFzIGJlZW4gcG9pbnRlZCBv
dXQsIHRoZXJlIGFyZSBzZXZlcmFsIHBvc3NpYmlsaXRpZXMgYW5kIHRvIHBpY2sgZnJvbSB0aGVz
ZSB3ZSBuZWVkIHRvIHVuZGVyc3RhbmQ6PEJSPjEuIERvIHdlIG5lZWQgdG8gc3VwcG9ydCBleHBs
aWNpdCBsYWJlbCBzdGFja2luZz88QlI+Jm5ic3A7Jm5ic3A7IE5vdGUgdGhhdCB0aGlzIGlzIG5v
dCBzdXBwb3J0ZWQgaW4gVERNLCBMU0Mgb3IgRlNDLjxCUj4yLiBEbyB3ZSBuZWVkIHRvIGJlIGFi
bGUgdG8gY29udHJvbCAocGVyaGFwcyB0aHJvdWdoIGFuPEJSPiZuYnNwOyZuYnNwOyZuYnNwO2V4
dGVybmFsIHNpZ25hbGluZyBjb250cm9sbGVyKSBleGlzdGluZyBoYXJkd2FyZSBhbmQgPEJSPiZu
YnNwOyZuYnNwOyBpbnN0YWxsIExTUHMgdGhyb3VnaCBleGlzdGluZyBuZXR3b3Jrcz88QlI+My4g
RG8gd2UgbmVlZCB0byBzdXBwb3J0IGV4aXN0aW5nIGZ1bmN0aW9uIHNpbXVsdGFuZW91cyB0bzxC
Uj4mbmJzcDsmbmJzcDsgdGhlIHN1cHBvcnQgb2YgR01QTFMgTDIgTFNQcz88QlI+PEJSPkkgdGhp
bmsgdGhhdCBmcm9tIGEgY2hhaXIncyBwZXJzcGVjdGl2ZSBJIGNhbiBnaXZlIHNvbWUgbGltaXRl
ZCBndWlkYW5jZS48QlI+PEJSPkEuIFRoZXNlIHF1ZXN0aW9ucyBtdXN0IGJlIHJhaXNlZCBhbmQg
YW5zd2VyZWQgaW4gdGhlIGZyYW1ld29yayBJLUQ8QlI+Qi4gVGhlIGFuc3dlciB0byBxdWVzdGlv
biAzIGlzICZxdW90O3llcyZxdW90Oy4gVGhpcyBtZWFucyB0aGF0IHRoZSB1c2Ugb2YgbGFiZWxz
PEJSPiZuYnNwOyZuYnNwOyBtdXN0IG5vdCBzaWduaWZpY2FudGx5IGRlcGxldGUgYW55IG5hbWVz
cGFjZSB1c2VkIHRvIHN1cHBvcnQgb3RoZXI8QlI+Jm5ic3A7Jm5ic3A7IGZ1bmN0aW9uLjxCUj5D
LiBDQ0FNUCBpcyBjaGFydGVyZWQgdG8gbG9vayBhdCB0aGUgY29udHJvbCBvZiB0cmFuc3BvcnQg
bmV0d29ya3MuIFRoaXM8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7aW5jbHVkZXMgTWV0cm8sIGJ1dCBJ
IGFtIHVuc3VyZSBhYm91dCBDYW1wdXMuIEl0IGRvZXMgbm90Jm5ic3A7Y292ZXIgPEJSPiZuYnNw
OyZuYnNwOyBzaWduYWxpbmcgdG8gdGhlIGRlc2t0b3AuPEJSPjxCUj5UaGFua3MsPEJSPkFkcmlh
bjxCUj48QlI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8QlI+RnJvbTogJnF1b3Q7UCZh
dW1sO3IgTWF0dHNzb24mcXVvdDsgJmx0OzwvRk9OVD48Rk9OVCBDT0xPUj1CTFVFPjxVPjxBIEhS
RUY9bWFpbHRvOnBlckBkZWZlcm8uc2U+cGVyQGRlZmVyby5zZTwvQT48L1U+PC9GT05UPjxGT05U
IENPTE9SPUJMQUNLPiZndDs8QlI+VG86ICZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsgJmx0Ozwv
Rk9OVD48Rk9OVCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOmxvYUBwaS5zZT5sb2FAcGku
c2U8L0E+PC9VPjwvRk9OVD48Rk9OVCBDT0xPUj1CTEFDSz4mZ3Q7PEJSPkNjOiAmbHQ7PC9GT05U
PjxGT05UIENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86Y2NhbXBAb3BzLmlldGYub3JnPmNj
YW1wQG9wcy5pZXRmLm9yZzwvQT48L1U+PC9GT05UPjxGT05UIENPTE9SPUJMQUNLPiZndDs8QlI+
U2VudDogRnJpZGF5LCBKdWx5IDIyLCAyMDA1IDExOjQxIEFNPEJSPlN1YmplY3Q6IFJlOiBGcmFt
ZWZvcm1hdCBpbiBhIGwyY3MgZ21wbHMgcm52aXJvbm1lbnQuPEJSPjxCUj48QlI+Jmd0OyAmZ3Q7
IFBlciBhbmQgRGltaXRyaSw8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBJIHdvdWxkIGxpa2Ug
dG8gY29tZSBkb3duIHN0cm9uZ2VyIHRoYW4gdGhhdCwgZm9yIG1lIGl0IGlzPEJSPiZndDsgJmd0
OyBhIHZlcnkgc3Ryb25nIHJlcXVpcmVtZW50IHRoYXQgdGhlIHNhbWUgc3dpdGNoIGNhbiBoYW5k
bGU8QlI+Jmd0OyAmZ3Q7IGJvdGggVkxBTnMgYW5kIEdNUExzIHRyYWZpYyBjb3JyZWN0bHkuIEkg
Y2FuJ3QgZHNlZSBob3cgdGhhdDxCUj4mZ3Q7ICZndDsgY291bGQgYmUgZG9uZSBpZiB1c2luZyB0
aGUgVkxBTiB0cGlkIHRvIGluZGljYXRlIEdNUExTPEJSPiZndDsgJmd0OyB0cmFmZmljLjxCUj4m
Z3Q7IDxCUj4mZ3Q7IElmIHlvdSBldmVyIHdhbnQgdGhhdCBzYW1lIHN3aXRjaCB0byBoYW5kbGUg
dHJhZmZpYyBmb3IgYSBkaXJlY3RseTxCUj4mZ3Q7IGNvbm5lY3RlZCZuYnNwOyBob3N0IChub3Qg
dG8gdW5jb21tZW4pIHlvdSB3b3VsZCB3YW50IHRoYXQgdG8gdXNlIG5vcm1hbDxCUj4mZ3Q7IGV0
aGVybmV0IG1hY2FkZHJlc3Mgc3dpdGNoaW5nLiBTbyBvZiBjb3Vyc2UgeW91IGRvIG5vdCB3YW50
IHRvIGhhdmUgdG88QlI+Jmd0OyBjaG9vc2UgYmV0d2VlbiB2bGFuIGFuZCBnbXBscywgeW91IHdv
dWxkIHdhbnQgYm90aCBhdCB0aGUgc2FtZSB0aW1lLjxCUj4mZ3Q7IDxCUj4mZ3Q7IC9wZXI8QlI+
Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAvTG9hPEJSPiZndDsgJmd0
OzxCUj4mZ3Q7ICZndDsgUCZhdW1sO3IgTWF0dHNzb24gd3JvdGU6PEJSPiZndDsgJmd0OyZndDsm
Z3Q7aGkgcGFyLCBvbmUgb2YgdGhlIHBvc3NpYmlsaXRpZXMgdGhhdCBoYXMgYmVlbiBjb25zaWRl
cmVkIHRvIGNvcGUgd2l0aDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0O3RoaXMgcmVxdWlyZW1lbnQgaXMg
dG8gdXNlIGEgZGVkaWNhdGVkIFRQSUQgZm9yIHRoZSBFdGhlcm5ldCBsYWJlbGVkPEJSPiZndDsg
Jmd0OyZndDsmZ3Q7ZnJhbWVzOyB0aGlzIHdvdWxkIGFsbG93IGRpZmZlcmVudGlhdGVkIHByb2Nl
c3Npbmcgd2l0aCBub24tbGFiZWxlZDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0O2ZyYW1lc3RoYW5rcy48
QlI+Jmd0OyAmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDsgVGhhdCBz
ZWVtcyB0byBtYWtlIG1vcmUgc2VuY2UuIElmIHRoYXQgZnJhbWUgaXMgdG8gYmUgc2l6ZWQgbGlr
ZSBhPEJSPiZndDsgJmd0OyZndDsgODAyLjFxPEJSPiZndDsgJmd0OyZndDsgZnJhbWUuIFRoZXJl
IGlzIG5vdCB0aGF0IG11Y2ggc3BhY2UgbGVmdCB0byBhIGxhYmVsLiBPciBpcyB0aGUgZGVtYW5k
IHRvPEJSPiZndDsgJmd0OyZndDsgdXNlIGp1bWJvZnJhbWVzID88QlI+Jmd0OyAmZ3Q7Jmd0OyBI
YXMgdGhlcmUgYmVlbiBhbnkgZGlzY3Vzc2lvbiBvbiBsYWJlbHN0YWNraW5nLCBhbmQgbWFpbmx5
IHdoZXJlIHRvPEJSPiZndDsgJmd0OyZndDsgcGxhY2U8QlI+Jmd0OyAmZ3Q7Jmd0OyB0aGUgaW5m
b3JtYXRpb24/PEJSPiZndDsgJmd0OyZndDs8QlI+Jmd0OyAmZ3Q7Jmd0OyBSZWdhcmRzLjxCUj4m
Z3Q7ICZndDsmZ3Q7IFBlcjxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDs8QlI+Jmd0
OyAmZ3Q7Jmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAtLTxCUj4m
Z3Q7ICZndDsgTG9hIEFuZGVyc3NvbjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFByaW5jaXBh
bCBOZXR3b3JraW5nIEFyY2hpdGVjdDxCUj4mZ3Q7ICZndDsgQWNyZW8gQUImbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGhvbmU6Jm5ic3A7ICs0NiA4IDYzMiA3NyAx
NDxCUj4mZ3Q7ICZndDsgSXNhZmpvcmRzZ2F0YW4gMjImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgbW9iaWxlOiArNDYgNzM5IDgxIDIxIDY0PEJSPiZndDsgJmd0
OyBLaXN0YSwgU3dlZGVuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVtYWlsOiZuYnNwOyA8L0ZPTlQ+PEZPTlQgQ09M
T1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpsb2EuYW5kZXJzc29uQGFjcmVvLnNlPmxvYS5hbmRl
cnNzb25AYWNyZW8uc2U8L0E+PC9VPjwvRk9OVD48Rk9OVCBDT0xPUj1CTEFDSz48QlI+Jmd0OyAm
Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD48Rk9OVCBDT0xP
Uj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOmxvYUBwaS5zZT5sb2FAcGkuc2U8L0E+PC9VPjwvRk9O
VD48Rk9OVCBDT0xPUj1CTEFDSz48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgPEJSPiZndDsgPEJSPiZn
dDsgPEJSPiZndDsgPEJSPjxCUj48L0ZPTlQ+PEZPTlQgU0laRT00IEZBQ0U9Ik1vbm9zcGFjZSxD
b3VyaWVyIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT08L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NCBGQUNFPSJNb25vc3BhY2UsQ291cmll
ciI+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIHByaXZp
bGVnZWQ8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+YW5k
IGNvbmZpZGVudGlhbCBhbmQgcHJvdGVjdGVkIGZyb20gZGlzY2xvc3VyZS4gSWYgdGhlIHJlYWRl
cjwvRk9OVD48QlI+PEZPTlQgU0laRT00IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5vZiB0aGlz
IG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9yIGFuIGVtcGxveWVlPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPm9yIGFnZW50IHJl
c3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRoaXMgbWVzc2FnZSB0byB0aGU8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9NCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+aW50ZW5kZWQgcmVjaXBpZW50LCB5
b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSByZXByb2R1Y3Rpb24sPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmRpc3NlbWluYXRpb24gb3IgZGlz
dHJpYnV0aW9uIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseTwvRk9OVD48QlI+PEZP
TlQgU0laRT00IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5wcm9oaWJpdGVkLiBJZiB5b3UgaGF2
ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRl
bHkgYnkgcmVwbHlpbmcgdG8gdGhlIG1lc3NhZ2UgYW5kPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQg
RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmRlbGV0aW5nIGl0IGZyb20geW91ciBjb21wdXRlci4g
VGhhbmsgeW91LiBUZWxsYWJzPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQgRkFDRT0iTW9ub3NwYWNl
LENvdXJpZXIiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PTwvRk9OVD48QlI+PC9QPg==



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 15:52:16 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 17:51:08 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmFkcmlhbiAtIG9rIG11Y2ggdGhhbmtz
IGZvciB0aGUgY2xhcmlmaWNhdGlvbiAtIDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3Nw
YWNlLENvdXJpZXIiPmkgd2FudGVkIHRvIGJlIHN1cmUgdGhhdCB0aGUgd29ya2luZyBncm91cCBj
b25zZW5zdXMgaXMgZ29pbmcgdG8gYmUgdGhlIGVsZW1lbnQgb2YgZGVjaXNpb24gZm9yIHB1dHRp
bmcgdGhpcyBpdGVtIGluIHRoZSB3b3JraW5nIGxpc3QgLSBhbmQgd2Ugd29uJ3QgaGF2ZSBvdGhl
ciBpbnRlcmZlcmluZyBlbGVtZW50cyBpbiB0aGUgZGVjaXNpb24gcHJvY2VzcyAtIDwvRk9OVD48
QlI+PEJSPjxGT05UIFNJWkU9Mj48Qj4mcXVvdDtBZHJpYW4gRmFycmVsJnF1b3Q7ICZsdDthZHJp
YW5Ab2xkZG9nLmNvLnVrJmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj5TZW50IGJ5OiBv
d25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj4wNy8yMi8yMDA1
IDE2OjA4PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+UGxlYXNlIHJlc3BvbmQgdG8gJnF1b3Q7QWRy
aWFuIEZhcnJlbCZxdW90OzwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8
Rk9OVCBTSVpFPTI+RGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTDwvRk9O
VD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj4mbHQ7Y2NhbXBAb3Bz
LmlldGYub3JnJmd0OzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxG
T05UIFNJWkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZPTlQgU0laRT0yPlJlOiBGcmFtZWZvcm1hdCBp
biBhIGwyY3MgZ21wbHMgcm52aXJvbm1lbnQuPC9GT05UPjxCUj4gPEJSPjxCUj48L1A+PFA+PEZP
TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkRpbWl0cmksPEJSPjwvRk9OVD48QlI+PEZPTlQg
RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZndDsgd2hhdCBkbyB5b3UgRVhBQ1RMWSBtZWFuIHdp
dGggdGhlIGZvbGxvd2luZyBzZW50ZW5jZTxCUj4mZ3Q7PEJSPiZndDsgJnF1b3Q7VGhpcyBxdWVz
dGlvbiBpcyBvbmUgd2UgbXVzdCBjb21lIHRvIGFzIHNvb24gYXMgd2UgYXJlIGNvbmZpZGVudCB0
aGF0PEJSPnRoZTxCUj4mZ3Q7IHJlcXVpcmVtZW50cyBuZWVkIHRvIGJlIGFkZHJlc3NlZCBhdCBh
bGwuJnF1b3Q7PEJSPiZndDs8QlI+Jmd0OyBwbGVhc2UgY2xhcmlmeSAtIGJ0dyB3aG8gaXMgJnF1
b3Q7d2UmcXVvdDsgaW4gdGhpcyBjb250ZXh0ID88QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJN
b25vc3BhY2UsQ291cmllciI+JnF1b3Q7V2UmcXVvdDsgbWVhbnMgJnF1b3Q7dGhlIENDQU1QIHdv
cmtpbmcgZ3JvdXAmcXVvdDs8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291
cmllciI+Jmd0OyB0aGlzIHNlbnRlbmNlIHJlYWRzIHRvIG1lIGFzICZxdW90O0NDQU1QIGhhcyBu
b3QgeWV0IGNvbW1pdHRlZCB0byB3b3JrIG9uPEJSPnRoaXM8QlI+Jmd0OyB0b3BpYyZxdW90OyBp
cyBteSByZWFkaW5nIGNvcnJlY3QgPyBvciBkbyB5b3UgbWVhbiBzb21ldGhpbmcgZWxzZSB3aXRo
IHRoaXMgPzxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5Zb3Vy
IHJlYWRpbmcgaXMgZXhhY3RseSBjb3JyZWN0IGFzIHN0YXRlZC48QlI+SSByZWZlciB5b3UgdG8g
eW91ciBlbWFpbCB0byB0aGUgbGlzdCBvbiAxOXRoIEp1bHkuIFlvdSBhc2tlZC4uLjxCUj4mZ3Q7
IC0gaWYgeWVzLCBpcyB0aGUgaW50ZXJlc3QgaW4gR01QTFMgZm9yIEV0aGVybmV0IGluLS9vdXQt
c2lkZSB0aGU8QlI+Jmd0OyAmbmJzcDsgQ0NBTVAgV0cgY29tbXVuaXR5IHN0cm9uZyBlbm91Z2gg
dG8gY29uc2lkZXIgdGhlIGNvcnIuIEdNUExTPEJSPiZndDsgJm5ic3A7IHNpZ25hbGluZyBhbmQg
cm91dGluZyByZXF1aXJlbWVudHMgKHNlY29uZCBwYXJ0IG9mIHRoZSBkb2N1bWVudCk8QlI+Jmd0
OyAmbmJzcDsgYXMgcGFydCBvZiB0aGUgQ0NBTVAgV0cgZWZmb3J0ID88QlI+PC9GT05UPjxCUj48
Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VGh1cywgdGhlIHB1cnBvc2Ugb2YgdGhlIEkt
RCB3YXMgdG8gY3J5c3RhbGl6ZSB0aGUgYXV0aG9ycycgdGhvdWdodHMgb248QlI+R01QTFMgY29u
dHJvbCBvZiBFdGhlcm5ldCBzd2l0Y2hpbmcgYW5kIHRvIGluaXRpYXRlIGRpc2N1c3Npb24gb24g
d2hldGhlcjxCUj50aGUgcHJvcG9zZWQgZGVwbG95bWVudCBtb2RlbHMgYXJlIHJlYWxpc3RpYyBh
bmQgZGVzaXJhYmxlLiBGb2xsb3dpbmcgYTxCUj5wb3NpdGl2ZSBhbnN3ZXIgYW5kIGFzc3VtaW5n
IHN1cHBvcnQgKGJ5IENDQU1QKSBmb3IgdGhlIGRvaW5nIHRoZSB3b3JrIChpbjxCUj5DQ0FNUCkg
YWxsIHRoYXQgcmVtYWlucyBpcyB0byBhZGQgdGhlIHdvcmsgdG8gdGhlIGNoYXJ0ZXIgKHNlZSBw
cmV2aW91czxCUj5jaGFydGVyIGRpc2N1c3Npb25zKSBhbmQgZ2V0IG9uIHdpdGggaXQuPEJSPjwv
Rk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlRoYW5rcyw8QlI+QWRyaWFu
PEJSPjwvRk9OVD48L1A+



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 15:35:37 +0000
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 16:33:59 +0100
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
Thread-Index: AcWOv97Qnu365RxCQfqdrvWhC7nQtAAAIniQ
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Heiles Juergen
> Sent: 22 July 2005 14:17
> To: Loa Andersson; P=E4r Mattsson
> Cc: [e-mail]
> 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
> > -----Original Message-----
> > From: [e-mail]=20
> > [mailto:[e-mail]] On Behalf Of Loa Andersson
> > Sent: Friday, July 22, 2005 12:05 PM
> > To: P=E4r Mattsson
> > Cc: [e-mail]
> > 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:  [phone]
> > Isafjordsgatan 22                  mobile: [phone]
> > Kista, Sweden                      email:  [e-mail]
> >                                             [e-mail]
> >=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 15:18:06 +0000
Message-ID: <1a5a01c58ed0$c2ed71d0$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 16:08:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 15:17:58 +0000
Message-ID: <1a5b01c58ed0$c42ccfa0$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Mack-Crane, T. Benjamin" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 16:18:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 15:11:55 +0000
Message-ID: <014201c58ecf$81096c20$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Mack-Crane, T. Benjamin" <[e-mail]>, "Adrian Farrel" <[e-mail]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>, "Loa Andersson" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 11:10:31 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_013F_01C58EAD.F99BA260"

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: [e-mail]=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: [e-mail] [mailto:[e-mail]] On =
Behalf Of Adrian Farrel
    Sent: Friday, July 22, 2005 8:37 AM
    To: P=E4r Mattsson; Loa Andersson
    Cc: [e-mail]
    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" <[e-mail]>
    To: "Loa Andersson" <[e-mail]>
    Cc: <[e-mail]>
    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:  [phone]
    > > Isafjordsgatan 22                  mobile: [phone]
    > > Kista, Sweden                      email:  =
[e-mail]
    > >                                             [e-mail]
    > >
    >=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=[e-mail]=20
  href=3D"mailto:[e-mail]">Mack-Crane, T. Benjamin</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Adrian Farrel</A> ; <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">P=E4r Mattsson</A> ; <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Loa Andersson</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</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> [e-mail]=20
    [mailto:[e-mail]] <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> =
[e-mail]<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:[e-mail]"><FONT face=3DCourier=20
    size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier =
size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
    size=3D2>[e-mail]</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; [phone]<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: [phone]<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:[e-mail]"><FONT=20
    face=3DCourier size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
    size=3D2>[e-mail]</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--




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 15:01:10 +0000
Message-ID: <[e-mail]>
Date: Fri, 22 Jul 2005 16:57:09 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
MIME-Version: 1.0
To: Heiles Juergen <[e-mail]>
CC:  [e-mail],  [e-mail],  [e-mail]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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
>  
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Loa Andersson
>>Sent: Friday, July 22, 2005 2:53 PM
>>To: [e-mail]
>>Cc: [e-mail]; [e-mail]
>>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
>>
>>[e-mail] 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
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail] [mailto:[e-mail]]On
>>>>Behalf Of Pär Mattsson
>>>>Sent: 22 July 2005 11:42
>>>>To: Loa Andersson
>>>>Cc: [e-mail]
>>>>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:  [phone]
>>>>>Isafjordsgatan 22                  mobile: [phone]
>>>>>Kista, Sweden                      email:  [e-mail]
>>>>>                                           [e-mail]
>>>>>
>>>>
>>>>
>>>>
>>
>>-- 
>>Loa Andersson
>>
>>Principal Networking Architect
>>Acreo AB                           phone:  [phone]
>>Isafjordsgatan 22                  mobile: [phone]
>>Kista, Sweden                      email:  [e-mail]
>>                                            [e-mail]
>>
> 
> 
> 


-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 14:26:03 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58EC9.2CDB7192"
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 09:23:59 -0500
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
Thread-Index: AcWOwsSnwxhnILPySYOqhzXS5kDp+wABSG7w
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>, "Loa Andersson" <[e-mail]>
Cc: <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On Behalf=
 Of Adrian Farrel
	Sent: Friday, July 22, 2005 8:37 AM
	To: P=E4r Mattsson; Loa Andersson
	Cc: [e-mail]
	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" <[e-mail] <mailto:[e-mail]> >
	To: "Loa Andersson" <[e-mail] <mailto:[e-mail]> >
	Cc: <[e-mail] <mailto:[e-mail]> >
	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:  [phone]
	> > Isafjordsgatan 22                  mobile: [phone]
	> > Kista, Sweden                      email:  [e-mail] <mai=
lto:[e-mail]>=20
	> >                                             [e-mail] <mailto:loa@pi.s=
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> [e-mail]=20
  [mailto:[e-mail]] <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> [e-mail]<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:[e-mail]"><FONT face=3DCourier=20
  size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
  size=3D2>[e-mail]</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; [phone]<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: [phone]<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:[e-mail]"><FONT face=
=3DCourier=20
  size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
  size=3D2>[e-mail]</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--



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 14:20:46 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>, "Loa Andersson" <[e-mail]>, <[e-mail]>
From: [e-mail]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
MIME-Version: 1.0
Date: Fri, 22 Jul 2005 16:19:35 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

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.






Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 14:05:03 +0000
To: Heiles Juergen <[e-mail]>
Cc: Loa Andersson <[e-mail]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 16:03:13 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmhpIGp1ZXJnZW4sPC9GT05UPjwvUD48
UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+aWYgd2VsbCB1bmRlcnN0YW5kIHlvdXIg
cG9pbnQgb2YgdmlldywgeW91IHdvdWxkIGJlIGluIGZhdm9yIG9mIHNldHRpbmcgdXAgcGF0aCB3
aXRob3V0IGludHJvZHVjaW5nIGFueSBzcGVjaWZpYyBpbmRpY2F0aW9uIGluIHRoZSBkYXRhIHBs
YW5lIEV0aGVybmV0IGZyYW1lIGZsb3c8L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFj
ZSxDb3VyaWVyIj5tb3JlIHByZWNpc2VseSwgb25jZSB0aGUgJnF1b3Q7bG9naWNhbCBwYXRoJnF1
b3Q7IGlzIHNldHVwIHVzaW5nIHRoZSBjb250cm9sIHBsYW5lLCB0aGUgZm9yd2FyZGluZyBiZWhh
dmlvdXIgd291bGQgcmVtYWluIHVuY2hhbmdlZCBmcm9tIGxlZ2FjeSBFdGhlcm5ldCBiZWhhdmlv
dXIgKGkuZSBNQUMgYWRkcmVzcyBsZWFybmluZyBhbmQgZm9yd2FyZGluZyBiYXNlZCBvbiBNQUMg
REEpIGluIHRoaXMgY2FzZSwgdGhlIGNvbnRyb2wgcGxhbmUgZnVuY3Rpb24gcmVwbGFjZXMgdGhl
IFZMQU4gaWQgY29uZmlndXJhdGlvbiBwZXJmb3JtZWQgdG9kYXkgbWFudWFsbHkgb24gYSBwZXIg
aW50ZXJmYWNlIGJhc2lzID8gLSBwbGVhc2UgY29uZmlybTwvRk9OVD48L1A+PFA+PEZPTlQgRkFD
RT0iTW9ub3NwYWNlLENvdXJpZXIiPm5vdywgaSB3b3VsZCBpbnRlcmVzdGVkIHRvIGtub3cgd2hh
dCBpbiB5b3VyIHZpZXcgd291bGQgYmUgdGhlIHJvbGUgb2YgODAyLjFkIGFuZCByZWxhdGVkIGlu
IHRoaXMgY29udGV4dCAoYWxzbyB0aGVyZSBhcmUgc2V2ZXJhbCBsZXZlbHMgb2YgaW50ZXJhY3Rp
b24gcG9zc2libGUgaGVyZSk8L0ZPTlQ+PC9QPjxQPjxCUj48Rk9OVCBTSVpFPTI+PEI+IEhlaWxl
cyBKdWVyZ2VuICZsdDtqdWVyZ2VuLmhlaWxlc0BzaWVtZW5zLmNvbSZndDs8L0I+PC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTI+U2VudCBieTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTI+MDcvMjIvMjAwNSAxNToxNyBaRTI8L0ZPTlQ+PEJSPjxCUj4gPEZPTlQg
U0laRT0yPlRvOjwvRk9OVD4gPEZPTlQgU0laRT0yPkxvYSBBbmRlcnNzb24gJmx0O2xvYUBwaS5z
ZSZndDssIFAmYXVtbDtyIE1hdHRzc29uICZsdDtwZXJAZGVmZXJvLnNlJmd0OzwvRk9OVD48QlI+
IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5jY2FtcEBvcHMuaWV0Zi5vcmc8
L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+YmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBTSVpFPTI+U3Vi
amVjdDo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5SRTogRnJhbWVmb3JtYXQgaW4gYSBsMmNzIGdtcGxz
IHJudmlyb25tZW50LjwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9z
cGFjZSxDb3VyaWVyIj5HTVBMUyBmb3IgU09ORVQvU0RIIGhhcyBubyBpbXBhY3Qgb24gdGhlIFNP
TkVUL1NESCBkYXRhIHBsYW5lLiBJdCBpbnRyb2R1Y2VzIGEgY29udHJvbCBwbGFuZSBmb3IgY29u
bmVjdGlvbiBzZXR1cCBpbnN0ZWFkIG9mIGEgbmV0d29yayBtYW5hZ2VtZW50IGJhc2VkIGNvbm5l
Y3Rpb24gc2V0dXAuIEdNUExTIGZvciBFdGhlcm5ldCBjYW4gd29yayBpbiB0aGUgc2FtZSB3YXku
IEV0aGVybmV0IGFzIHN1Y2ggaXMgY2wsIGJ1dCBWTEFOcyBhcmUgc2V0dXAgYW5kIEdNUExTIGNh
biBwcm92aWRlIGEgY29udHJvbCBwbGFuZSBmb3IgVkxBTiBzZXR1cC4gVGhlIEV0aGVybmV0IGRh
dGEgcGxhbmUgaXMgbm90IGNoYW5nZWQgYW5kIE1BQyBhZGRyZXNzIGxlYXJuaW5nIGFuZCBmb3J3
YXJkaW5nIGlzIHN0aWxsIGJlIGRvbmUgd2l0aGluIGEgVkxBTi4gU28gbm8gY2hhbmdlIHRvIHRo
ZSBFdGhlcm5ldCBkYXRhIHBsYW5lLiBObyBHTVBMUyB0cmFmZmljIGlzIGludHJvZHVjZWQsIGl0
IGlzIHN0aWxsIFZMQU4gdHJhZmZpYy48QlI+SW50cm9kdWNpbmcgYSBkZWRpY2F0ZWQgR01QTFMg
bGFiZWwgZm9yIEV0aGVybmV0IChHTVBMUyB0cmFmZmljKSBnb2VzIGJleW9uZCBHTVBMUyBhcyBh
IGNvbnRyb2wgcGxhbmUgdGVjaG5pcXVlLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9z
cGFjZSxDb3VyaWVyIj5SZWdhcmRzPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNl
LENvdXJpZXIiPkp1ZXJnZW48QlI+PC9GT05UPjxCUj48QlI+PEJSPjxCUj48Rk9OVCBGQUNFPSJN
b25vc3BhY2UsQ291cmllciI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7
IEZyb206IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzxCUj4mZ3Q7IFttYWlsdG86b3duZXItY2Nh
bXBAb3BzLmlldGYub3JnXSBPbiBCZWhhbGYgT2YgTG9hIEFuZGVyc3NvbjxCUj4mZ3Q7IFNlbnQ6
IEZyaWRheSwgSnVseSAyMiwgMjAwNSAxMjowNSBQTTxCUj4mZ3Q7IFRvOiBQJmF1bWw7ciBNYXR0
c3NvbjxCUj4mZ3Q7IENjOiBjY2FtcEBvcHMuaWV0Zi5vcmc8QlI+Jmd0OyBTdWJqZWN0OiBSZTog
RnJhbWVmb3JtYXQgaW4gYSBsMmNzIGdtcGxzIHJudmlyb25tZW50LjxCUj4mZ3Q7PEJSPiZndDsg
UGVyIGFuZCBEaW1pdHJpLDxCUj4mZ3Q7PEJSPiZndDsgSSB3b3VsZCBsaWtlIHRvIGNvbWUgZG93
biBzdHJvbmdlciB0aGFuIHRoYXQsIGZvciBtZSBpdCBpczxCUj4mZ3Q7IGEgdmVyeSBzdHJvbmcg
cmVxdWlyZW1lbnQgdGhhdCB0aGUgc2FtZSBzd2l0Y2ggY2FuIGhhbmRsZTxCUj4mZ3Q7IGJvdGgg
VkxBTnMgYW5kIEdNUExzIHRyYWZpYyBjb3JyZWN0bHkuIEkgY2FuJ3QgZHNlZSBob3cgdGhhdDxC
Uj4mZ3Q7IGNvdWxkIGJlIGRvbmUgaWYgdXNpbmcgdGhlIFZMQU4gdHBpZCB0byBpbmRpY2F0ZSBH
TVBMUzxCUj4mZ3Q7IHRyYWZmaWMuPEJSPiZndDs8QlI+Jmd0OyAvTG9hPEJSPiZndDs8QlI+Jmd0
OyBQJmF1bWw7ciBNYXR0c3NvbiB3cm90ZTo8QlI+Jmd0OyAmZ3Q7Jmd0O2hpIHBhciwgb25lIG9m
IHRoZSBwb3NzaWJpbGl0aWVzIHRoYXQgaGFzIGJlZW4gY29uc2lkZXJlZDxCUj4mZ3Q7IHRvIGNv
cGUgd2l0aDxCUj4mZ3Q7ICZndDsmZ3Q7dGhpcyByZXF1aXJlbWVudCBpcyB0byB1c2UgYSBkZWRp
Y2F0ZWQgVFBJRCBmb3IgdGhlIEV0aGVybmV0IGxhYmVsZWQ8QlI+Jmd0OyAmZ3Q7Jmd0O2ZyYW1l
czsgdGhpcyB3b3VsZCBhbGxvdyBkaWZmZXJlbnRpYXRlZCBwcm9jZXNzaW5nIHdpdGggbm9uLWxh
YmVsZWQ8QlI+Jmd0OyAmZ3Q7Jmd0O2ZyYW1lc3RoYW5rcy48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsg
Jmd0OzxCUj4mZ3Q7ICZndDsgVGhhdCBzZWVtcyB0byBtYWtlIG1vcmUgc2VuY2UuIElmIHRoYXQg
ZnJhbWUgaXMgdG8gYmUgc2l6ZWQ8QlI+Jmd0OyBsaWtlIGEgODAyLjFxPEJSPiZndDsgJmd0OyBm
cmFtZS4gVGhlcmUgaXMgbm90IHRoYXQgbXVjaCBzcGFjZSBsZWZ0IHRvIGEgbGFiZWwuIE9yIGlz
PEJSPiZndDsgdGhlIGRlbWFuZCB0bzxCUj4mZ3Q7ICZndDsgdXNlIGp1bWJvZnJhbWVzID88QlI+
Jmd0OyAmZ3Q7IEhhcyB0aGVyZSBiZWVuIGFueSBkaXNjdXNzaW9uIG9uIGxhYmVsc3RhY2tpbmcs
IGFuZCBtYWlubHk8QlI+Jmd0OyB3aGVyZSB0byBwbGFjZTxCUj4mZ3Q7ICZndDsgdGhlIGluZm9y
bWF0aW9uPzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFJlZ2FyZHMuPEJSPiZndDsgJmd0OyBQ
ZXI8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OzxCUj4mZ3Q7
PEJSPiZndDsgLS08QlI+Jmd0OyBMb2EgQW5kZXJzc29uPEJSPiZndDs8QlI+Jmd0OyBQcmluY2lw
YWwgTmV0d29ya2luZyBBcmNoaXRlY3Q8QlI+Jmd0OyBBY3JlbyBBQiAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgcGhvbmU6ICZuYnNwOys0NiA4IDYzMiA3NyAxNDxCUj4mZ3Q7IElz
YWZqb3Jkc2dhdGFuIDIyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7bW9iaWxlOiArNDYgNzM5IDgxIDIxIDY0PEJSPiZndDsgS2lz
dGEsIFN3ZWRlbiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZW1haWw6ICZuYnNwO2xvYS5hbmRlcnNzb25A
YWNyZW8uc2U8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
bG9hQHBpLnNlPEJSPiZndDs8L0ZPTlQ+PC9QPg==



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 13:38:59 +0000
Message-ID: <193401c58ec2$de6863b0$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>, "Loa Andersson" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 14:37:03 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_191C_01C58ECA.D361FF00"

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" <[e-mail]>
To: "Loa Andersson" <[e-mail]>
Cc: <[e-mail]>
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:  [phone]
> > Isafjordsgatan 22                  mobile: [phone]
> > Kista, Sweden                      email:  [e-mail]
> >                                             [e-mail]
> >
>=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:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier =
size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</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; [phone]<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: [phone]<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:[e-mail]"><FONT =
face=3DCourier=20
size=3D2>[e-mail]</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:[e-mail]"><FONT face=3DCourier=20
size=3D2>[e-mail]</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--




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 13:24:42 +0000
Message-ID: <[e-mail]>
From: Heiles Juergen <[e-mail]>
To: Loa Andersson <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 15:23:43 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

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

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: Friday, July 22, 2005 2:53 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> 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
> [e-mail] 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
> >>-----Original Message-----
> >>From: [e-mail] [mailto:[e-mail]]On
> >>Behalf Of P=E4r Mattsson
> >>Sent: 22 July 2005 11:42
> >>To: Loa Andersson
> >>Cc: [e-mail]
> >>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:  [phone]
> >>>Isafjordsgatan 22                  mobile: [phone]
> >>>Kista, Sweden                      email:  [e-mail]
> >>>                                            [e-mail]
> >>>
> >>
> >>
> >>
> >=20
>=20
>=20
> --=20
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB                           phone:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                             [e-mail]
>=20



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 13:24:34 +0000
To: Loa Andersson <[e-mail]>
Cc: =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 15:24:10 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmxvYSwgPC9GT05UPjwvUD48UD48Rk9O
VCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+ZHVyaW5nIHRoZSBkaXNjdXNzaW9uIGxvb3Agb25l
IG9mIHRoZSBwb3NzaWJpbGl0aWVzIHRoYXQgY2FtZSBvdXQgY29uc2lzdGVkIGluIHVzaW5nIGEg
ZGVkaWNhdGVkIFRQSUQgdmFsdWUgKGRpZmZlcmVudCBmcm9tIHRoZSB2YWx1ZSAweDgxMDAgdXNl
ZCBpbiAuMXEpLCB0aGF0IHdvdWxkIHByZWNlZGUgdGhlIGVuY29kZWQgdmFsdWUgYXMgcGFydCBv
ZiB0aGUgVENJIDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPndv
dWxkIHlvdSBwbGVhc2UgY2xhcmlmeSB5b3VyIHNwZWNpZmljIGNvbmNlcm4gPyBpIHdvdWxkIGxp
a2UgYWxzbyB0byBwb2ludCBvdXQgdGhhdCB0aGVyZSBhcmUgc2V2ZXJhbCBjYXNlcyBoZXJlPC9G
T05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+MS4gYm90aCB0eXBlIG9m
IHRyYWZmaWMgb24gdGhlIHNhbWUgc3dpdGNoIGJ1dCBub3QgbmVjZXNzYXJpbHkgb24gdGhlIHNh
bWUgaW50ZXJmYWNlPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+
Mi4gYm90aCB0eXBlIG9mIHRyYWZmaWMgb24gdGhlIHNhbWUgaW50ZXJmYWNlIDwvRk9OVD48L1A+
PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPndpdGggdGhlIGZvbGxvd2luZyB2YXJp
YW50PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+MmEuIGludGVy
ZmFjZSBtdXN0IGFjY29tbW9kYXRlIGFueSB0eXBlIG9mIHRyYWZmaWMgKHVuLS90YWdnZWQgYW5k
IGxhYmVsZWQpPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+MmIu
IGludGVyZmFjZSBtdXN0IGFjY29tbW9kYXRlIHRhZ2dlZCBhbmQgbGFiZWxlZCB0eXBlIG9mIHRy
YWZmaWMgb25seTwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnRo
YW5rcyw8L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4tIGRpbWl0
cmkuPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT0yPjxCPkxvYSBBbmRlcnNzb24gJmx0O2xvYUBw
aS5zZSZndDs8L0I+PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+U2VudCBieTogb3duZXItY2NhbXBA
b3BzLmlldGYub3JnPC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+MDcvMjIvMjAwNSAxMjowNCBaRTI8
L0ZPTlQ+PEJSPjxCUj4gPEZPTlQgU0laRT0yPlRvOjwvRk9OVD4gPEZPTlQgU0laRT0yPlAmYXVt
bDtyIE1hdHRzc29uICZsdDtwZXJAZGVmZXJvLnNlJmd0OzwvRk9OVD48QlI+IDxGT05UIFNJWkU9
Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPiA8
Rk9OVCBTSVpFPTI+YmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+
IDxGT05UIFNJWkU9Mj5SZTogRnJhbWVmb3JtYXQgaW4gYSBsMmNzIGdtcGxzIHJudmlyb25tZW50
LjwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy
Ij5QZXIgYW5kIERpbWl0cmksPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENv
dXJpZXIiPkkgd291bGQgbGlrZSB0byBjb21lIGRvd24gc3Ryb25nZXIgdGhhbiB0aGF0LCBmb3Ig
bWUgaXQgaXM8QlI+YSB2ZXJ5IHN0cm9uZyByZXF1aXJlbWVudCB0aGF0IHRoZSBzYW1lIHN3aXRj
aCBjYW4gaGFuZGxlPEJSPmJvdGggVkxBTnMgYW5kIEdNUExzIHRyYWZpYyBjb3JyZWN0bHkuIEkg
Y2FuJ3QgZHNlZSBob3cgdGhhdDxCUj5jb3VsZCBiZSBkb25lIGlmIHVzaW5nIHRoZSBWTEFOIHRw
aWQgdG8gaW5kaWNhdGUgR01QTFM8QlI+dHJhZmZpYy48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNF
PSJNb25vc3BhY2UsQ291cmllciI+L0xvYTxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9z
cGFjZSxDb3VyaWVyIj5QJmF1bWw7ciBNYXR0c3NvbiB3cm90ZTo8QlI+Jmd0OyZndDtoaSBwYXIs
IG9uZSBvZiB0aGUgcG9zc2liaWxpdGllcyB0aGF0IGhhcyBiZWVuIGNvbnNpZGVyZWQgdG8gY29w
ZSB3aXRoPEJSPiZndDsmZ3Q7dGhpcyByZXF1aXJlbWVudCBpcyB0byB1c2UgYSBkZWRpY2F0ZWQg
VFBJRCBmb3IgdGhlIEV0aGVybmV0IGxhYmVsZWQ8QlI+Jmd0OyZndDtmcmFtZXM7IHRoaXMgd291
bGQgYWxsb3cgZGlmZmVyZW50aWF0ZWQgcHJvY2Vzc2luZyB3aXRoIG5vbi1sYWJlbGVkPEJSPiZn
dDsmZ3Q7ZnJhbWVzdGhhbmtzLjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBUaGF0IHNlZW1zIHRv
IG1ha2UgbW9yZSBzZW5jZS4gSWYgdGhhdCBmcmFtZSBpcyB0byBiZSBzaXplZCBsaWtlIGEgODAy
LjFxPEJSPiZndDsgZnJhbWUuIFRoZXJlIGlzIG5vdCB0aGF0IG11Y2ggc3BhY2UgbGVmdCB0byBh
IGxhYmVsLiBPciBpcyB0aGUgZGVtYW5kIHRvPEJSPiZndDsgdXNlIGp1bWJvZnJhbWVzID88QlI+
Jmd0OyBIYXMgdGhlcmUgYmVlbiBhbnkgZGlzY3Vzc2lvbiBvbiBsYWJlbHN0YWNraW5nLCBhbmQg
bWFpbmx5IHdoZXJlIHRvIHBsYWNlPEJSPiZndDsgdGhlIGluZm9ybWF0aW9uPzxCUj4mZ3Q7PEJS
PiZndDsgUmVnYXJkcy48QlI+Jmd0OyBQZXI8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+PC9G
T05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0tPEJSPkxvYSBBbmRl
cnNzb248QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+UHJpbmNp
cGFsIE5ldHdvcmtpbmcgQXJjaGl0ZWN0PEJSPkFjcmVvIEFCICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBwaG9uZTogJm5ic3A7KzQ2IDggNjMyIDc3IDE0PEJSPklzYWZqb3Jkc2dh
dGFuIDIyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7bW9iaWxlOiArNDYgNzM5IDgxIDIxIDY0PEJSPktpc3RhLCBTd2VkZW4gJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO2VtYWlsOiAmbmJzcDtsb2EuYW5kZXJzc29uQGFjcmVvLnNlPC9GT05U
PjwvUD48VUw+PFVMPjxVTD48VUw+PFVMPjxVTD48VUw+PFVMPjxVTD48VUw+PFVMPjxVTD48VUw+
PFVMPjxVTD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+bG9hQHBpLnNlPEJSPjwvRk9O
VD48L1VMPg==



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 13:18:21 +0000
Message-ID: <[e-mail]>
From: Heiles Juergen <[e-mail]>
To: Loa Andersson <[e-mail]>, =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>
Cc: [e-mail]
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 15:17:19 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: Friday, July 22, 2005 12:05 PM
> To: P=E4r Mattsson
> Cc: [e-mail]
> 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:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                             [e-mail]
>=20



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 12:57:45 +0000
Message-ID: <[e-mail]>
Date: Fri, 22 Jul 2005 14:53:28 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
MIME-Version: 1.0
To:  [e-mail]
CC:  [e-mail],  [e-mail]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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

[e-mail] 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
> 
> 
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]On
>>Behalf Of Pär Mattsson
>>Sent: 22 July 2005 11:42
>>To: Loa Andersson
>>Cc: [e-mail]
>>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:  [phone]
>>>Isafjordsgatan 22                  mobile: [phone]
>>>Kista, Sweden                      email:  [e-mail]
>>>                                            [e-mail]
>>>
>>
>>
>>
> 


-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 11:46:19 +0000
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 12:44:08 +0100
Message-ID: <[e-mail]>
Thread-Topic: Frameformat in a l2cs gmpls rnvironment.
Thread-Index: AcWOqjL1VwqIq2haR4mlmgcOF+B70gAA1pkg
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of P=E4r Mattsson
> Sent: 22 July 2005 11:42
> To: Loa Andersson
> Cc: [e-mail]
> 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:  [phone]
> > Isafjordsgatan 22                  mobile: [phone]
> > Kista, Sweden                      email:  [e-mail]
> >                                             [e-mail]
> >
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 10:43:18 +0000
Message-ID: <[e-mail]>
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?= <[e-mail]>
To: "Loa Andersson" <[e-mail]>
Cc: [e-mail]
User-Agent: SquirrelMail/1.4.0
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1

> 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:  [phone]
> Isafjordsgatan 22                  mobile: [phone]
> Kista, Sweden                      email:  [e-mail]
>                                             [e-mail]
>




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 10:28:24 +0000
To: =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: Re:Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 12:27:37 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+Jm5ic3A7PEJSPjxCUj48Rk9OVCBTSVpFPTI+PEI+UCZhdW1sO3IgTWF0dHNzb24gJmx0O3Bl
ckBkZWZlcm8uc2UmZ3Q7PC9CPjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPlNlbnQgYnk6IG93bmVy
LWNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjA3LzIyLzIwMDUgMTE6
NTQgWkUyPC9GT05UPjxCUj48QlI+IDxGT05UIFNJWkU9Mj5Ubzo8L0ZPTlQ+IDxGT05UIFNJWkU9
Mj5jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+Y2M6PC9GT05UPiA8
QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5TdWJqZWN0Ojwv
Rk9OVD4gPEZPTlQgU0laRT0yPlJlOlJlOiBGcmFtZWZvcm1hdCBpbiBhIGwyY3MgZ21wbHMgcm52
aXJvbm1lbnQuPC9GT05UPjxCUj4gPEJSPjxCUj48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNl
LENvdXJpZXIiPiZndDsmZ3Q7IGhpIHBhciwgb25lIG9mIHRoZSBwb3NzaWJpbGl0aWVzIHRoYXQg
aGFzIGJlZW4gY29uc2lkZXJlZCB0byBjb3BlIHdpdGg8QlI+Jmd0OyZndDsgdGhpcyByZXF1aXJl
bWVudCBpcyB0byB1c2UgYSBkZWRpY2F0ZWQgVFBJRCBmb3IgdGhlIEV0aGVybmV0IGxhYmVsZWQ8
QlI+Jmd0OyZndDsgZnJhbWVzOyB0aGlzIHdvdWxkIGFsbG93IGRpZmZlcmVudGlhdGVkIHByb2Nl
c3Npbmcgd2l0aCBub24tbGFiZWxlZDxCUj4mZ3Q7Jmd0OyBmcmFtZXN0aGFua3MuPEJSPjwvRk9O
VD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZndDsgVGhhdCBzZWVtcyB0byBt
YWtlIG1vcmUgc2VuY2UuIElmIHRoYXQgZnJhbWUgaXMgdG8gYmUgc2l6ZWQgbGlrZSBhIDgwMi4x
cTxCUj4mZ3Q7IGZyYW1lLiBUaGVyZSBpcyBub3QgdGhhdCBtdWNoIHNwYWNlIGxlZnQgdG8gYSBs
YWJlbC4gT3IgaXMgdGhlIGRlbWFuZCB0bzxCUj4mZ3Q7IHVzZSBqdW1ib2ZyYW1lcyA/PC9GT05U
PjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OyBIYXMgdGhlcmUgYmVl
biBhbnkgZGlzY3Vzc2lvbiBvbiBsYWJlbHN0YWNraW5nLCBhbmQgbWFpbmx5IHdoZXJlIHRvIHBs
YWNlPEJSPiZndDsgdGhlIGluZm9ybWF0aW9uPzxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1v
bm9zcGFjZSxDb3VyaWVyIj48QlI+dGhlcmUgYXJlIHNldmVyYWwgcG9zc2liaWxpdGllcyBoZXJl
IC0gb25lIG9mIHRoZW0gY29uc2lzdHMgaW4gZW5jb2RpbmcgdGhlIGxhYmVsIHZhbHVlIGFzIHBh
cnQgb2YgdGhlIFRDSSAtPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmll
ciI+YWxzbyB0aGUgY3VycmVudCBkb2N1bWVudCBkb2VzIG5vdCBkaXNjdXNzIGFueSBzcGVjaWZp
YyAmcXVvdDtzdGFja2luZyZxdW90OyBvZiBzdWNoIHZhbHVlcyAod2Ugc2hvdWxkIHB1dCB0aGlz
IG9uIHRoZSBvcGVuIGRpc2N1c3Npb24gcG9pbnQpPC9GT05UPjwvUD4=



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 10:25:22 +0000
Message-ID: <[e-mail]>
Date: Fri, 22 Jul 2005 12:04:53 +0200
From: Loa Andersson <[e-mail]>
Organization: Acreo AB
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>
CC:  [e-mail]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 09:55:38 +0000
Message-ID: <[e-mail]>
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?= <[e-mail]>
To: [e-mail]
User-Agent: SquirrelMail/1.4.0
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1

> 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




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 09:46:35 +0000
To: =?iso-8859-1?Q?P=E4r_Mattsson?= <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: Re: Frameformat in a l2cs gmpls rnvironment.
Date: Fri, 22 Jul 2005 11:45:34 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmhpIHBhciwgPC9GT05UPjwvUD48UD48
Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+b25lIG9mIHRoZSBwb3NzaWJpbGl0aWVzIHRo
YXQgaGFzIGJlZW4gY29uc2lkZXJlZCB0byBjb3BlIHdpdGggdGhpcyByZXF1aXJlbWVudCBpcyB0
byB1c2UgYSBkZWRpY2F0ZWQgVFBJRCBmb3IgdGhlIEV0aGVybmV0IGxhYmVsZWQgZnJhbWVzOyB0
aGlzIHdvdWxkIGFsbG93IGRpZmZlcmVudGlhdGVkIHByb2Nlc3Npbmcgd2l0aCBub24tbGFiZWxl
ZCBmcmFtZXM8L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj50aGFu
a3MsPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+LSBkaW1pdHJp
LjwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9Mj48Qj5QJmF1bWw7ciBNYXR0c3NvbiAmbHQ7cGVy
QGRlZmVyby5zZSZndDs8L0I+PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+U2VudCBieTogb3duZXIt
Y2NhbXBAb3BzLmlldGYub3JnPC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+MDcvMjIvMjAwNSAxMToz
NiBaRTI8L0ZPTlQ+PEJSPjxCUj4gPEZPTlQgU0laRT0yPlRvOjwvRk9OVD4gPEZPTlQgU0laRT0y
PmNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+IDxC
Uj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1YmplY3Q6PC9G
T05UPiA8Rk9OVCBTSVpFPTI+RnJhbWVmb3JtYXQgaW4gYSBsMmNzIGdtcGxzIHJudmlyb25tZW50
LjwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy
Ij5IaSBhbGwuPEJSPkFmdGVyIHJlYWRpbmcgdGhlIGRyYWZ0PEJSPihkcmFmdC1wYXBhZGltaXRy
aW91LWNjYW1wLWdtcGxzLWV0aGVybmV0LWZyYW1ld29yay0wMC50eHQpIGFuZCB0aGlua2luZzxC
Uj5mb3IgYXdoaWxlIG9uIGRpZmZlcmVudCB3YXlzIHRvIGltcGxlbWVudGluZyB0aGlzLCBpIHdh
cyB3b25kZXJpbmcgd2hhdDxCUj5hbHRlcm5hdGl2ZXMgdGhlcmUgaXMgZm9yIHRoZSBmcmFtZm9y
bWF0IGZvciB0aGlzLiBJIHVuZGVyc3RhbmQgdGhhdCBvbmU8QlI+b3B0aW9uIGlzIHVzaW5nIFRQ
SUQ9ODEwMCwgYnV0IHdoYXQgYmVjYW1lIG9mIHRoZSBsb2thbCBzaWduaWZpY2FudCBsYWJlbCw8
QlI+YW5kIHRoYXQgYWxsIHN3aXRjaGVzIHNob3VsZCBiZSBhYmxlIHRvIHN3aXRjaCBjdXJyZW50
IGV0aGVybmV0IGZvcm1hdCBhdDxCUj50aGUgc2FtZSB0aW1lLiBIb3cgdG8gZGlzdGluZ3Vpc2gg
YmV0d2VlbiBHTVBMUyBhbmQgVkxBTiA/PEJSPkRvIGFueWJvZHkgaGF2ZSBhbnkgY29tbWVudCBv
biB0aGlzID88QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+UmVn
YXJkcy48QlI+UGVyPC9GT05UPjwvUD4=



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 09:39:00 +0000
Message-ID: <[e-mail]>
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?= <[e-mail]>
To: [e-mail]
User-Agent: SquirrelMail/1.4.0
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1

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



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 04:25:02 +0000
Message-ID: <[e-mail]>
Date: Fri, 22 Jul 2005 13:22:57 +0900
From: Tomohiro Otani <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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




[e-mail] 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 <[e-mail]>*
>Sent by: [e-mail]
>07/19/2005 09:48 ZE9
>
>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>cc: [e-mail]
>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.
>
>
>
>
>[e-mail] 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 ?
> >
> >
> >
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 01:25:02 +0000
Date: Fri, 22 Jul 2005 10:23:38 +0900
From: Kenji Kumaki <[e-mail]>
To: [e-mail]
Subject: draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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 <[e-mail]>





Envelope-to: [e-mail]
Delivery-date: Fri, 22 Jul 2005 00:30:05 +0000
From: [e-mail]
Message-Type: Multiple Part
MIME-Version: 1.0
Message-ID: <"MNXA011275l1181022U*/C=JP/ADMD=gmax000/PRMD=gmax000/O=KOI/OU=gmax000/S=Sagara/G=Kazuhiko-crl/"@MHS>
Content-Type: text/plain; charset="us-ascii"
To: <[e-mail]>
Date: Fri, 22 Jul 2005 09:26:45 +0900
Subject: Re:draft-otani-ccamp-interas-gmpls-te-03.txt (support)
Content-Transfer-Encoding: 7bit

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.




Envelope-to: [e-mail]
Delivery-date: Thu, 21 Jul 2005 14:59:17 +0000
Thread-Topic: End-to-end L2-LSP
thread-index: AcWOBL6WoZ1LxoiyQ2CfXbLdUjivyA==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
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
Message-ID: <377fd01c58e04$be9b0150$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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 

 
 

-----?? ???----- 
?? ??: "[e-mail]" <[e-mail]> 
?? ??: 2005-07-21 ?? 12:09:56 
?? ??: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]> 
??: 
??: 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 

> -----Original Message----- 
> From: CHO, JAI HYUNG [mailto:[e-mail]] 
> Sent: 14 July 2005 04:24 
> To: Spencer,R,Richard,XDE73 R; [e-mail] 
> 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 :       [phone] 
> oversea: [phone] 
> fax:         [phone] 
> 
> 
> 
> 
> -----?? ???----- 
> ?? ??: "[e-mail]" <[e-mail]> 
> ?? ??: 2005-07-14 ?? 1:10:30 
> ?? ??: "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]> 
> ??: 
> ??: 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 
> 
> > -----Original Message----- 
> > From: CHO, JAI HYUNG [mailto:[e-mail]] 
> > Sent: 13 July 2005 15:14 
> > To: Spencer,R,Richard,XDE73 R; [e-mail] 
> > 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 
> >  
> > 
> > ============================================ 
> > 
> >  
> > 
> > -----?? ???----- 
> > ?? ??: "[e-mail]" <[e-mail]> 
> > ?? ??: 2005-07-13 ?? 8:53:13 
> > ?? ??: "[e-mail]" <[e-mail]>, 
> > "[e-mail]" <[e-mail]> 
> > ??: 
> > ??: 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 
> > 
> > > -----Original Message----- 
> > > From: CHO, JAI HYUNG [mailto:[e-mail]] 
> > > Sent: 12 July 2005 09:21 
> > > To: Spencer,R,Richard,XDE73 R; [e-mail] 
> > > 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 
> > > 
> > > > -----Original Message----- 
> > > > From: [e-mail] 
> > [mailto:[e-mail]]On 
> > > > Behalf Of CHO, JAI HYUNG 
> > > > Sent: 12 July 2005 01:10 
> > > > To: [e-mail] 
> > > > 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 :       [phone] 
> > > > oversea: [phone] 
> > > > fax:         [phone] 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 






Envelope-to: [e-mail]
Delivery-date: Thu, 21 Jul 2005 11:35:13 +0000
Message-ID: <164701c58de8$60c5ec00$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Tom Petch" <[e-mail]>, <[e-mail]>
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Thu, 21 Jul 2005 12:27:01 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

OK
Understood.

A
----- Original Message ----- 
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
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" <[e-mail]>
> To: "Tom Petch" <[e-mail]>; <[e-mail]>
> 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" <[e-mail]>
> > To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
> > 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" <[e-mail]>
> > > To: <[e-mail]>
> > > Cc: "'Kireeti Kompella'" <[e-mail]>; <[e-mail]>;
"Bill
> > Fenner"
> > > <[e-mail]>; "Scott Bradner" <[e-mail]>
> > > 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
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
>
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 21 Jul 2005 10:11:00 +0000
Message-ID: <[e-mail]>
Date: Thu, 21 Jul 2005 19:09:11 +0900
From: Tomohiro Otani <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: [e-mail]
Subject: draft-otani-ccamp-interas-gmpls-te-03.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Thu, 21 Jul 2005 00:31:57 +0000
Message-ID: <[e-mail]>
Date: Thu, 21 Jul 2005 09:30:10 +0900
From: Kohei Shiomoto <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.7) Gecko/20050414
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: I-D ACTION:draft-oki-ccamp-gmpls-ip-interworking-06.txt]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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: [e-mail]
Reply-To: [e-mail]
To: [e-mail]

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
[e-mail] 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:
	[e-mail].
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 [phone]    Fax [phone]




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 20:45:00 +0000
Message-ID: <030501c58d63$5464d460$0601a8c0@pc6>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Wed, 20 Jul 2005 21:41:51 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<inline>
Tom Petch
----- Original Message -----
From: "Adrian Farrel" <[e-mail]>
To: "Tom Petch" <[e-mail]>; <[e-mail]>
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" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
> 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" <[e-mail]>
> > To: <[e-mail]>
> > Cc: "'Kireeti Kompella'" <[e-mail]>; <[e-mail]>; "Bill
> Fenner"
> > <[e-mail]>; "Scott Bradner" <[e-mail]>
> > 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
> > >
> > >
> >
> >
> >
> >
>




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 19:51:57 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 19:16:05 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MdnaU2ljFs7PgYpVIAhMmTTgkBIU25FifH6Q6DQOWxEG3AlU0LA4sH1ygSm8PYhqBN0CSIEaA5bYrD8xK5eZtAjLCzKPe3qZaG0iilsltOGTiprSA95qfjZ8lovSgNLSjNYUhpc7l8VwMOLkRu/NTsdUKou/jk088eHq5vimg10=  ;
Message-ID: <[e-mail]>
Date: Wed, 20 Jul 2005 12:15:46 -0700 (PDT)
From: Igor Bryskin <[e-mail]>
Subject: Re: LSP stitching questions for discussion
To: [e-mail], Igor Bryskin <[e-mail]>
Cc: [e-mail], Arthi Ayyangar <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-499060946-1121886946=:94207"
Content-Transfer-Encoding: 8bit

--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" <[e-mail]>
Sent by: [e-mail]
07/20/2005 13:25 AST

To: "Arthi Ayyangar" <[e-mail]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: <[e-mail]>
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: [e-mail] 
To: Arthi Ayyangar 
Cc: Igor Bryskin ; [e-mail] 
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;[e-mail]&gt;</B><BR>Sent by: [e-mail]<BR>07/20/2005 13:25 AST<BR><BR>To:<FONT size=4> </FONT>"Arthi Ayyangar" &lt;[e-mail]&gt;, Dimitri
 PAPADIMITRIOU/BE/ALCATEL@ALCATEL<BR>cc:<FONT size=4> </FONT>&lt;[e-mail]&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:[e-mail]">[e-mail]</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:[e-mail]">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:[e-mail]">Igor Bryskin</A></U></FONT><FONT color=black size=5> ; </FONT><FONT color=blue size=5><U><A href="mailto:[e-mail]">[e-mail]</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--



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 19:08:22 +0000
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: Re: LSP stitching questions for discussion
Date: Wed, 20 Jul 2005 21:08:01 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+aWdvciAtIGluLWxpbmUgPEJSPjxCUj48QlI+PEZPTlQgU0laRT00Pml0IGlzICZxdW90O25v
JnF1b3Q7IHRvIGFsbCB0aGUgYmVsb3cgYSksIGIpIGFuZCBjKSAtIGFzIGxvZ2ljYWwgY29uc2Vx
dWVuY2Ugb2YgdGhlIGN1cnJlbnQgR01QTFMgYXJjaGl0ZWN0dXJlPC9GT05UPjxCUj48QlI+PEJS
PjxCUj48Rk9OVCBTSVpFPTQ+bm90ZTogdG8gY2xhcmlmeSBvbmUgb2YgbXkgbm90ZSBoZXJlIGJl
bG93ICh3aGVyZSBpdCBzZWVtcyB5b3Ugd2VyZSBub3QgaW4gYWdyZWVtZW50KSBhYm91dCBQU0Mg
TFNQIGJhbmR3aWR0aCBhbmQgc2VnbWVudCBzdGl0Y2hpbmcgaS5lLiBsYXJnZXIgYmFuZHdpZHRo
IHJlc2VydmF0aW9uIGZvciB0aGUgc2VnbWVudCB0aGFuIGZvciB0aGUgZW5kLXRvLWVuZCBMU1Ag
ZG9lcyBub3QgbWVhbiBkaWZmZXJlbnQgUFNDIGxldmVsIChub3RlOiBQU0MtMSwgLTIsIC0zIGFu
ZCAtNCBhcmUgbm90ICZxdW90O2xheWVycyZxdW90OyB0aGV5IHNob3VsZCBzaW1wbHkgYmUgcmVm
ZXJyZWQgdG8gYXMgbGV2ZWxzIGJ1dCB0aGlzIGlzIGFub3RoZXIgZGlzY3Vzc2lvbikgc28gaSB3
YW50ZWQgdG8gY2xhcmlmeSB0aGF0IHRoZSBkZWZhdWx0IGFkbWlzc2lvbiBjb250cm9sIHJ1bGVz
IGZvciB0aGUgcGFja2V0IGNhc2UgLSB3aXRoaW4gdGhlIHNhbWUgUFNDIGxldmVsIC0gY291bGQg
YmUgcmVsYXhlZCBjb21wYXJlZCB0byB0aGUgb3RoZXIgc3dpdGNoaW5nIHRlY2hub2xvZ2llcyB3
aXRob3V0IHN0cmV0Y2hpbmcgdGhlIHN0aXRjaGluZyBjb25jZXB0PC9GT05UPjxCUj48QlI+PEZP
TlQgU0laRT00PklCJmd0OyZndDsgTXkgcXVlc3Rpb24gYykgd2FzOjwvRk9OVD48QlI+PEZPTlQg
U0laRT00PmMpIElzIGl0IHBvc3NpYmxlIChzaG91bGQgd2UgYWxsb3cpIHRvIHN0aXRjaCZuYnNw
OyZuYnNwO1BTQzEgZTJlIExTUCBieSBhJm5ic3A7UFNDMiBMU1Agc2VnbWVudCA8L0ZPTlQ+PEJS
PjxCUj48Rk9OVCBTSVpFPTQ+SWYgeW91IHNheSBOTyB0byB0aGlzIHF1ZXN0aW9uLCB0aGFuIHRo
ZSBhbnN3ZXIgY29udHJhZGljdHMgdG8gd2hhdCB5b3Ugc2FpZCBhYm92ZSBpbiB5b3VyIG5vdGUu
PC9GT05UPjxCUj48L1A+PFA+W2RwXSBvayAtIGxhc3QgdHJ5IGZvciBhbiBlbmQtdG8tZW5kIFBT
Qy0xIExTUCBvZiAyTUIgeW91IGNvdWxkIG1ha2UgdXNlIG9mIGEgUFNDLTEgc2VnbWVudCBvZiA0
TUIgPC9QPjxQPjxCUj5Zb3UgYXJlIHJpZ2h0OiB3aGV0aGVyIFBTQzEgYW5kIFBTQzIgYXJlIHNl
cGFyYXRlIG5ldHdvcmsgbGF5ZXJzIG9yIG5vdCBpcyBhIHRvcGljIG9mIGEgc2VwYXJhdGUgKHBh
aW5mdWwgOj0pKSBkaXNjdXNzaW9uLiBIb3dldmVyLCBJIGp1c3Qgd2FudGVkIHRvIHBvaW50IG91
dCBoZXJlIHRoYXQgYSBQU0MyIExTUCBpcyBhIHByb3Zpc2lvbmVkIGFzIHN1Y2ggZm9yIGEgcmVh
c29uOiZuYnNwO2l0IGlzIG1lYW50IHRvICpuZXN0KiBQU0MxIExTUHMgcmF0aGVyIHRoYW4gdG8g
c3RpdGNoIHRoZW0uIEZyb20gdGhlIFZOVCBtYW5hZ2VtZW50IHBvaW50IG9mIHZpZXcgUFNDMiBh
bmQgUFNDMSBhcmUgc2VwYXJhdGUgdG9wb2xvZ2ljYWwgbGF5ZXJzLiB0aGF0IGlzIFBTQzIgcHJv
ZHVjZXMgdG9wb2xvZ3kgZm9yIFBTQzEsIGp1c3QgbGlrZSBWQzQgcHJvZHVjZXMgdG9wb2xvZ3kg
Zm9yIFZDMTIuPEJSPlRoZSBvbmx5IGRpZmZlcmVuY2UgaXMgdGhhdCBpbiB0aGUgbGF0dGVyIGNh
c2UgdGhpcyByZWxhdGlvbnNoaXAgaXMgZm9yY2VkIGJ5IHRoZSBoYXJkd2FyZSwgYW5kIGluIHRo
ZSBmb3JtZXIgY2FzZSBpcyBub3QgKGp1c3QgbG9naWNhbCkuIFRha2UgZm9yIGV4YW1wbGUgQyBh
bmQgQysrIHByb2dyYW1taW5nLiBDZXJ0YWluIHRoaW5ncyB5b3Ugc2ltcGx5IGZvcmNlZCBub3Qg
dG8gZG8gaW4gQysrLCB3aGVyZWFzIGluIEMgeW91IGNvdWxkIGJ1dCBzaG91bGRuJ3QuPEJSPjxC
Uj5TZWUgeW91IGluIFBhcmlzLjxCUj5JZ29yPEJSPjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj48
QlI+PEJSPjxCUj48Qj4mcXVvdDtJZ29yIEJyeXNraW4mcXVvdDsgJmx0O2licnlza2luQG1vdmF6
LmNvbSZndDs8L0I+PEJSPlNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzxCUj4wNy8y
MC8yMDA1IDEzOjI1IEFTVDxCUj48QlI+VG86PEZPTlQgU0laRT00PiA8L0ZPTlQ+JnF1b3Q7QXJ0
aGkgQXl5YW5nYXImcXVvdDsgJmx0O2FydGhpQGp1bmlwZXIubmV0Jmd0OywgRGltaXRyaSBQQVBB
RElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTDxCUj5jYzo8Rk9OVCBTSVpFPTQ+IDwvRk9OVD4m
bHQ7Y2NhbXBAb3BzLmlldGYub3JnJmd0OzxCUj5iY2M6PEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJS
PlN1YmplY3Q6PEZPTlQgU0laRT00PiA8L0ZPTlQ+UmU6IExTUCBzdGl0Y2hpbmcgcXVlc3Rpb25z
IGZvciBkaXNjdXNzaW9uPEJSPjxCUj48QlI+PEZPTlQgU0laRT00PkRpbWl0cmksPC9GT05UPjxC
Uj48QlI+PEZPTlQgU0laRT00Pkl0IHNlZW1zIHRvIG1lIHRoYXQgSSBtb3N0bHkgYWdyZWUoPyEp
IHdpdGggd2hhdCB5b3Ugd3JvdGUgaW4gdGhpcyBtYWlsLiBJJ2Qgc3RpbGwgd2FudCB0byBjb25m
aXJtIHlvdXIgdmlld3MmbmJzcDsgb24gdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6PC9GT05UPjxC
Uj48QlI+PEJSPjxGT05UIFNJWkU9ND5hKSBJcyBpdCBwb3NzaWJsZSAoc2hvdWxkIHdlIGFsbG93
KSB0byBzdGl0Y2gmbmJzcDsgUFNDMSBlMmUgTFNQIGJ5IGEgTFNDIExTUCBzZWdtZW50ID8gPC9G
T05UPjxCUj48QlI+PEZPTlQgU0laRT00PmIpIElzIGl0IHBvc3NpYmxlIChzaG91bGQgd2UgYWxs
b3cpIHRvIHN0aXRjaCZuYnNwOyZuYnNwO1ZDMTIgZTJlIExTUCBieSBhJm5ic3A7VkM0IExTUCBz
ZWdtZW50ID8gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+YykgSXMgaXQgcG9zc2libGUgKHNob3Vs
ZCB3ZSBhbGxvdykgdG8gc3RpdGNoJm5ic3A7Jm5ic3A7UFNDMSBlMmUgTFNQIGJ5IGEmbmJzcDtQ
U0MyIExTUCBzZWdtZW50ID88L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+TXkgYW5zd2VycyBh
cmUgTk8gdG8gYWxsIHRocmVlIHF1ZXN0aW9ucy4gWW91IGNhbiBzdGljdGggUFNDMSB3aXRoIFBT
QzEsIFZDMTIgd2l0aCBWQzEyLCBldGMuIEluIGFsbCBvdGhlciBjYXNlcyB5b3UgbmVlZCwgZmly
c3QsIHRvIHNldHVwIGEgaGllcmFyY2hpY2FsIExTUCAoSC1MU1ApICh3aGV0aGVyIGl0IGlzIEZB
LUxTUCAoc2luZ2xlIGRvbWFpbikgb3Igbm90Jm5ic3A7KG11bHRpLWRvbWFpbikpIGluIG9yZGVy
IHRvIGNyZWF0ZSBhIGRhdGEgbGluayBvZiB0aGUgZTJlIExTUCBzd2l0Y2hpbmcgY2FwYWJpbGl0
eSBhbmQgb25seSBhZnRlciB0aGF0IHlvdSBjYW4gYWxzbyZuYnNwO3VzZSBhIHN0aXRjaGluZyBz
ZWdtZW50IG9uIHRvcCBvZiAmbmJzcDt0aGlzIEgtTFNQKS48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBT
SVpFPTQ+U2VlIGFsc28gaW4tbGluZS48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+SWdvcjwv
Rk9OVD48QlI+PEJSPjxCUj48Rk9OVCBTSVpFPTU+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t
LSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT48Qj5Gcm9tOjwvQj4gPC9GT05UPjxGT05UIFNJWkU9
NSBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNh
dGVsLmJlPkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlPC9BPjwvVT48L0ZPTlQ+PEZP
TlQgU0laRT01IENPTE9SPUJMQUNLPiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT48Qj5Ubzo8L0I+
IDwvRk9OVD48Rk9OVCBTSVpFPTUgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzphcnRoaUBq
dW5pcGVyLm5ldD5BcnRoaSBBeXlhbmdhcjwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NSBDT0xP
Uj1CTEFDSz4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+PEI+Q2M6PC9CPiA8L0ZPTlQ+PEZPTlQg
U0laRT01IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86aWJyeXNraW5AbW92YXouY29tPkln
b3IgQnJ5c2tpbjwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NSBDT0xPUj1CTEFDSz4gOyA8L0ZP
TlQ+PEZPTlQgU0laRT01IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86Y2NhbXBAb3BzLmll
dGYub3JnPmNjYW1wQG9wcy5pZXRmLm9yZzwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NSBDT0xP
Uj1CTEFDSz4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+PEI+U2VudDo8L0I+IFdlZG5lc2RheSwg
SnVseSAyMCwgMjAwNSA0OjQ2IEFNPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+PEI+U3ViamVjdDo8
L0I+IFJlOiBMU1Agc3RpdGNoaW5nIHF1ZXN0aW9ucyBmb3IgZGlzY3Vzc2lvbjwvRk9OVD48QlI+
PEJSPjxGT05UIFNJWkU9NT5hcnRoaSwgPC9GT05UPjxCUj48QlI+PEJSPjxCUj48Rk9OVCBTSVpF
PTU+Zmlyc3QgYSByZWNhcDogdGhpcyBpdGVtIG9uIHN0aXRjaGluZyB3YXMgaW5pdGlhdGVkIGlu
IG9yZGVyIHRvIGFsbG93IHBlciAmcXVvdDtkb21haW4mcXVvdDsgY29udHJvbCBvZiBlbmQtdG8t
ZW5kIChjb250aWd1b3VzKSBMU1AsIGFzIHBhcnQgb2YgYSBzZXBhcmF0ZSBkb2N1bWVudCwgYW5k
IG5vdCB0byBleHRlbmQgaXRzIHNjb3BlICh1bmR1bHksIGluIHRoaXMgY2FzZSwgc2VlIGJlbG93
KSBidXQgbWFpbmx5IGluIG9yZGVyIHRvIGhhdmUgdGhlIHNldCBvZiBhbGwgcmVsYXRlZCBwcm90
b2NvbCBtZWNoYW5pc21zIHdpdGhpbiBhIHNwZWNpZmljIGRvY3VtZW50IC08L0ZPTlQ+PEJSPjxC
Uj48QlI+PEJSPjxGT05UIFNJWkU9NT5mcm9tIHRoaXMgaW5pdGlhbCB3b3JraW5nIGFzc3VtcHRp
b24sIGl0IGlzIGNsZWFyIHRoYXQgdGhlIHNlZ21lbnQgbXVzdCBoYXZlIHRoZSBwcm9wZXJ0aWVz
IG9mIHRoZSBpbmNvbWluZyBlbmQtdG8tZW5kIExTUCB3aGljaCBhcmUgZGV0ZXJtaW5lZCBhbW9u
ZyBvdGhlciBieSBpdHMgc3dpdGNoaW5nIHR5cGUgZS5nLiBQU0MtMyBvciBURE0sIHRoZSBmaXJz
dCByZXF1aXJlbWVudCBvZiBMU1Agc3RpdGNoaW5nIGlzIGNvbnRpZ3VpdHkgb2YgdGhlIGVuZC10
by1lbmQgTFNQIGF0IHRoZSBkYXRhIHBsYW5lIGxldmVsIChhZnRlciBzdGl0Y2hpbmcgb3BlcmF0
aW9uKSAtIGFuZCB0aGlzIGJ5IGRlZmluaXRpb24gb2YgdGhlIGluaXRpYWwgd29ya2luZyBhc3N1
bXB0aW9uIC08L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTU+SUImZ3Q7Jmd0OyBBZ3JlZTwvRk9O
VD48QlI+PEJSPjxGT05UIFNJWkU9NT5ub3RlOiB0aGUgb25seSBsYXRpdHVkZSB3aGljaCBpcyBs
ZWZ0IChmb3IgYSBnaXZlbiBzd2l0Y2hpbmcgdHlwZSBlLmcuIFBTQy0yKSBpcyBkdWUgdG8gdGhl
IHByb3BlcnRpZXMgb2YgcGFja2V0IChQU0MpIG5ldHdvcmtzIHRoYXQgYWxsb3dzIHlvdSBzdGl0
Y2ggYSBzZWdtZW50IGhhdmluZyBhIGxhcmdlciBNYXggUmVzZXJ2YWJsZSBCYW5kd2lkdGggYW5k
IFVucmVzZXJ2ZWQgQmFuZHdpZHRoICh3ZSB3b3VsZCBoYXZlIGVxdWl2YWxlbnQgbGF0aXR1ZGUg
Zm9yIG90aGVyIGF0dHJpYnV0ZXMgYnV0IHRoaXMgaXMgYSBsb2NhbCBwb2xpY3kgZGVjaXNpb24g
LSB3aGljaCBhdCB0aGUgZW5kIGlzIHRoZSBzb2xlIHB1cnBvc2Ugb2YgdGhpcyBhcHByb2FjaCk8
L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTU+SUImZ3Q7Jmd0OyBEaXNhZ3JlZS4gQ29uY2VwdHVh
bGx5IFBDUzEgYW5kIFBTQzIgYXJlIGRpZmZlcmVudCBsYXllcnMgYW5kIHRoZSBsYXR0ZXIgY2Fu
bm90IHN0aXRjaCB0aGUgZm9ybWVyLCBqdXN0IGxpa2UgaW4gY2FzZSBWQzEyIGFuZCBWQzQuIFlv
dSBzaG91bGQgbmVzdCBQU0MxIHdpdGhpbiBQU0MyIGluc3RlYWQuPC9GT05UPjxCUj48QlI+PEJS
PjxCUj48Rk9OVCBTSVpFPTU+SGVyZSBhcmUgc29tZSBvZiB0aGUgcXVlc3Rpb25zIHJlbGF0ZWQg
dG8gTFNQIHN0aXRjaGluZyB0byBzdGFydCBhPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+ZGlzY3Vz
c2lvbiBvbiB0aGUgdXNhZ2Ugb2YgTFNQIHN0aXRjaGluZy48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBT
SVpFPTU+Jmd0OzEpIEFyZSB0aGUgY29udHJvbCBwbGFuZSBzaWduYWxpbmcgcHJvY2VkdXJlcyBm
b3IgTFNQIHN0aXRjaGluZyBhczwvRk9OVD48QlI+PEZPTlQgU0laRT01PiZndDtkZXNjcmliZWQg
aW4gdGhpcyBJRCwgKGV4cGxpY2l0IHJlcXVlc3QgZm9yIExTUCBzdGl0Y2hpbmcgb248L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9NT4mZ3Q7TFNQIHNlZ21lbnQsIGRpZmZlcmVudCBsYWJlbCBhbGxvY2F0
aW9uIHJ1bGVzOyBldGMpIFJFUVVJUkVEIHRvIHN0aXRjaDwvRk9OVD48QlI+PEZPTlQgU0laRT01
PiZndDtwYWNrZXQgTFNQcyBpbiBkYXRhIHBsYW5lIDwvRk9OVD48QlI+PEJSPjxCUj48Rk9OVCBT
SVpFPTU+LSZndDsgeWVzIChiZXNpZGUgbWFudWFsIGNvbmZpZyBvcGVyYXRpb24pPC9GT05UPjxC
Uj48QlI+PEZPTlQgU0laRT01PklCJmd0OyZndDsgQWdyZWU8L0ZPTlQ+PEJSPjxCUj48QlI+PEZP
TlQgU0laRT01PiZndDsyKSBBcmUgdGhlIGNvbnRyb2wgcGxhbmUgc2lnbmFsaW5nIHByb2NlZHVy
ZXMgZm9yIExTUCBzdGl0Y2hpbmcgYXM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT4mZ3Q7ZGVzY3Jp
YmVkIGluIHRoaXMgSUQsIChleHBsaWNpdCByZXF1ZXN0IGZvciBMU1Agc3RpdGNoaW5nIG9uPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTU+Jmd0O0xTUCBzZWdtZW50LCBkaWZmZXJlbnQgbGFiZWwgYWxs
b2NhdGlvbiBydWxlczsgZXRjKSBSRVFVSVJFRCB0byBzdGl0Y2g8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9NT4mZ3Q7bm9uLXBhY2tldCBMU1BzIGluIGRhdGEgcGxhbmUgPzwvRk9OVD48QlI+PEJSPjxC
Uj48Rk9OVCBTSVpFPTU+LSZndDsgeWVzIChiZXNpZGUgbWFudWFsIGNvbmZpZyBvcGVyYXRpb24p
PC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT01PklCJmd0OyZndDsgQWdyZWU8L0ZPTlQ+PEJSPjxC
Uj48QlI+PEZPTlQgU0laRT01PiZndDszKSBJZiBhbiBlMmUgTFNQIGNyb3NzZXMgYSByZWdpb24g
Ym91bmRhcnkgKGJhc2VkIG9uIGRpZmZlcmVudCBURTwvRk9OVD48QlI+PEZPTlQgU0laRT01PiZn
dDtsaW5rIHN3aXRjaGluZyBjYXBhYmlsaXRpZXMpLCB0aGVuIGNhbiBJIHVzZSBMU1Agc3RpdGNo
aW5nIDwvRk9OVD48QlI+PEZPTlQgU0laRT01PiZndDthKSBjb250cm9sIHBsYW5lIHByb2NlZHVy
ZXMgZm9yIHBhY2tldCBMU1BzPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+Jmd0O2IpIGRhdGEgcGxh
bmUgcHJvY2VkdXJlcyBmb3IgcGFja2V0IExTUHM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT4mZ3Q7
YykgY29udHJvbCBwbGFuZSBwcm9jZWR1cmVzIGZvciBub24tcGFja2V0IExTUHM8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9NT4mZ3Q7ZCkgZGF0YSBwbGFuZSBwcm9jZWR1cmVzIGZvciBub24tcGFja2V0
IExTUHM8L0ZPTlQ+PEJSPjxCUj48QlI+PEZPTlQgU0laRT01Pi0mZ3Q7IG5vLCB3aGVuIGNyb3Nz
aW5nIGEgcmVnaW9uIGJvdW5kYXJ5LCB5b3Ugc2ltcGx5IHVzZSBhIGRvY3VtZW50IG5hbWVkICZx
dW90O2RyYWZ0LW1wbHMtbHNwLWhpZXJhcmNoeS0wOC50eHQmcXVvdDsgd2hpY2ggaXMgaW4gdGhl
IFJGQyBFZGl0b3IgcXVldWUsIGJ1dCB0aGlzIGRvZXMgbm90IHByZXZlbnQgZnJvbSBjcmVhdGlu
ZyBhbiBMU1Agc2VnbWVudCBvbiB0b3Agb2YgYW4gRkEtTFNQIChzZWUgYmVsb3cpPC9GT05UPjxC
Uj48QlI+PEZPTlQgU0laRT01PklCJmd0OyZndDsgQWdyZWUgd2l0aCB0aGUgY2F2aWF0IHRoYXQg
aXQgc2hvdWxkIGJlIEgtTFNQIGluc3RlYWQgb2YgRkEtTFNQIHRvIGNvdmVyIHNpbmdsZSBhbmQg
bXVsdGktZG9tYWluIHNjZW5hcmlvczwvRk9OVD48QlI+PEJSPjxCUj48Rk9OVCBTSVpFPTU+Jmd0
OzQpIElmIHRoZSBzd2l0Y2hpbmcgdHlwZSBvZiBhbiBlMmUgTFNQIGlzIGRpZmZlcmVudCBmcm9t
IHRoYXQgb2YgYW4gTFNQPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+Jmd0O3NlZ21lbnQsIGNhbiBJ
IHVzZSBMU1Agc3RpdGNoaW5nIDwvRk9OVD48QlI+PEZPTlQgU0laRT01PiZndDthKSBjb250cm9s
IHBsYW5lIHByb2NlZHVyZXMgZm9yIHBhY2tldCBMU1BzPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+
Jmd0O2IpIGRhdGEgcGxhbmUgcHJvY2VkdXJlcyBmb3IgcGFja2V0IExTUHM8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9NT4mZ3Q7YykgY29udHJvbCBwbGFuZSBwcm9jZWR1cmVzIGZvciBub24tcGFja2V0
IExTUHM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT4mZ3Q7ZCkgZGF0YSBwbGFuZSBwcm9jZWR1cmVz
IGZvciBub24tcGFja2V0IExTUHM8L0ZPTlQ+PEJSPjxCUj48QlI+PEZPTlQgU0laRT01Pi0mZ3Q7
IG5vLCBpbiB0aGlzIGNhc2UgcHJvZ3Jlc3Npb24gb2YgdGhlIGVuZC10by1lbmQgTFNQIGVzdGFi
bGlzaG1lbnQsIGltcGxpZXMgdGhhdCB0aGUgTFNQIHNlZ21lbnQgbXVzdCBmdWxmaWwgYSBzZXQg
b2YgY29uc3RyYWludHMgY2FycmllZCBhcyBwYXJ0IG9mIHRoZSBpbmNvbWluZyBlbmQtdG8tZW5k
IExTUCByZXF1ZXN0LCBpbiB0aGlzIGNhc2Ugb25lIGhhcyB0byBjcmVhdGUgYW4gTFNQIHNlZ21l
bnQgKHdpdGggYSBzd2l0Y2hpbmcgdHlwZSBlcXVhbCB0byB0aGUgaW5jb21pbmcgZW5kLXRvLWVu
ZCBMU1Agc3dpdGNoaW5nIHR5cGUpIG92ZXIgdGhhdCBGQSAoaS5lLiByZWZlcnJlZCBoZXJlIGFi
b3ZlIHRvIHRoZSBMU1Agc2VnbWVudCB3aXRoIGEgZGlmZmVyZW50IFN3aXRjaGluZyBUeXBlKTwv
Rk9OVD48QlI+PEJSPjxCUj48Rk9OVCBTSVpFPTU+SUImZ3Q7Jmd0OyBBZ3JlZSB3aXRoIHRoZSBj
YXZpYXQgdGhhdCBpdCBzaG91bGQgYmUgSC1MU1AgaW5zdGVhZCBvZiBGQS1MU1AgdG8gY292ZXIg
c2luZ2xlIGFuZCBtdWx0aS1kb21haW4gc2NlbmFyaW9zPC9GT05UPjxCUj48QlI+PEZPTlQgU0la
RT00PkNoZWVycyw8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+SWdvcjwvRk9OVD48QlI+PEJS
PjxGT05UIFNJWkU9NT4mZ3Q7Tm90ZSB0aGF0IGFsdGhvdWdoIDMpIGFuZCA0KSBhcHBlYXIgdG8g
YmUgdGhlIHNhbWUsIHRoZSByZWFzb24gSSBoYXZlPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+Jmd0
O3RoZW0gYXMgZGlmZmVyZW50IHF1ZXN0aW9ucyBpcyB0aGF0IGluIG9uZSBjYXNlIHRoZSBURSBs
aW5rIHN3aXRjaGluZzwvRk9OVD48QlI+PEZPTlQgU0laRT01PiZndDtjYXBhYmlsaXR5IGlzIGV4
YW1pbmVkIGFuZCBpbiB0aGUgb3RoZXIgY2FzZSB0aGUgR2VuZXJhbGl6ZWQgTGFiZWwgUmVxdWVz
dDwvRk9OVD48QlI+PEZPTlQgU0laRT01PiZndDtpcyBleGFtaW5lZC48L0ZPTlQ+PEJSPjxCUj48
QlI+PEJSPjxGT05UIFNJWkU9NT4tJmd0OyB3aGF0IGl0IGFwcGVhcnMgdG8gbWUgaXMgdGhhdCB0
aGlzIGRpc2N1c3Npb24gbWl4ZXMgdGhlIGlzc3VlIG9mIHRoZSBvcGVyYXRpb24gZGVzY3JpYmlu
ZyB0aGUgc3RpdGNoaW5nIG9wZXJhdGlvbnMgYXQgdGhlIGRvbWFpbiBib3VuZGFyaWVzIGZyb20g
dGhlIExTUCBzZWdtZW50IGNyZWF0aW9uIGl0c2VsZiBpLmUuIGFuIExTUCBzZWdtZW50IGNhbiBp
bmRlZWQgYmUgYW4gRkEgbGluayBpbmhlcml0ZWQgZnJvbSB0aGUgY3JlYXRpb24gb2YgYW4gKGlu
dHJhLWRvbWFpbikgRkEtTFNQIC0gPC9GT05UPjwvUD4=



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 19:01:16 +0000
Message-ID: <013d01c58d5d$54912340$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>
Cc: "Arthi Ayyangar" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: LSP stitching questions for discussion
Date: Wed, 20 Jul 2005 15:00:43 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_013A_01C58D3B.CD519570"

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" <[e-mail]>
  Sent by: [e-mail]
  07/20/2005 13:25 AST

  To: "Arthi Ayyangar" <[e-mail]>, Dimitri =
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
  cc: <[e-mail]>
  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: [e-mail]=20
  To: Arthi Ayyangar=20
  Cc: Igor Bryskin ; [e-mail]=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;[e-mail]&gt;</B></FONT><BR><FONT size=3D2>Sent by:=20
  [e-mail]</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;[e-mail]&gt;, Dimitri=20
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL</FONT><BR><FONT size=3D2>cc:</FONT> =
<FONT=20
  size=3D2>&lt;[e-mail]&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:[e-mail]">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:[e-mail]">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:[e-mail]">Igor Bryskin</A></U></FONT><FONT =
color=3Dblack=20
  size=3D4> ; </FONT><FONT color=3Dblue size=3D4><U><A=20
  =
href=3D"mailto:[e-mail]">[e-mail]</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--




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 18:34:31 +0000
To: "Igor Bryskin" <[e-mail]>
Cc: "Arthi Ayyangar" <[e-mail]>, <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: Re: LSP stitching questions for discussion
Date: Wed, 20 Jul 2005 20:33:07 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmlnb3IgLSA8L0ZPTlQ+PC9QPjxQPiZu
YnNwOzwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+aXQgaXMgJnF1b3Q7bm8m
cXVvdDsgdG8gYWxsIHRoZSBiZWxvdyBhKSwgYikgYW5kIGMpIC0gYXMgbG9naWNhbCBjb25zZXF1
ZW5jZSBvZiB0aGUgY3VycmVudCBHTVBMUyBhcmNoaXRlY3R1cmU8L0ZPTlQ+PC9QPjxQPiZuYnNw
OzwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+bm90ZTogdG8gY2xhcmlmeSBv
bmUgb2YgbXkgbm90ZSBoZXJlIGJlbG93ICh3aGVyZSBpdCBzZWVtcyB5b3Ugd2VyZSBub3QgaW4g
YWdyZWVtZW50KSBhYm91dCBQU0MgTFNQIGJhbmR3aWR0aCBhbmQgc2VnbWVudCBzdGl0Y2hpbmcg
aS5lLiBsYXJnZXIgYmFuZHdpZHRoIHJlc2VydmF0aW9uIGZvciB0aGUgc2VnbWVudCB0aGFuIGZv
ciB0aGUgZW5kLXRvLWVuZCBMU1AgZG9lcyBub3QgbWVhbiBkaWZmZXJlbnQgUFNDIGxldmVsIChu
b3RlOiBQU0MtMSwgLTIsIC0zIGFuZCAtNCBhcmUgbm90ICZxdW90O2xheWVycyZxdW90OyB0aGV5
IHNob3VsZCBzaW1wbHkgYmUgcmVmZXJyZWQgdG8gYXMgbGV2ZWxzIGJ1dCB0aGlzIGlzIGFub3Ro
ZXIgZGlzY3Vzc2lvbikgc28gaSB3YW50ZWQgdG8gY2xhcmlmeSB0aGF0IHRoZSBkZWZhdWx0IGFk
bWlzc2lvbiBjb250cm9sIHJ1bGVzIGZvciB0aGUgcGFja2V0IGNhc2UgLSB3aXRoaW4gdGhlIHNh
bWUgUFNDIGxldmVsIC0gY291bGQgYmUgcmVsYXhlZCBjb21wYXJlZCB0byB0aGUgb3RoZXIgc3dp
dGNoaW5nIHRlY2hub2xvZ2llcyB3aXRob3V0IHN0cmV0Y2hpbmcgdGhlIHN0aXRjaGluZyBjb25j
ZXB0PC9GT05UPjxCUj48QlI+PC9QPjxQPjxGT05UIFNJWkU9Mj48Qj4mcXVvdDtJZ29yIEJyeXNr
aW4mcXVvdDsgJmx0O2licnlza2luQG1vdmF6LmNvbSZndDs8L0I+PC9GT05UPjxCUj48Rk9OVCBT
SVpFPTI+U2VudCBieTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTI+MDcvMjAvMjAwNSAxMzoyNSBBU1Q8L0ZPTlQ+PEJSPjxCUj4gPEZPTlQgU0laRT0yPlRv
OjwvRk9OVD4gPEZPTlQgU0laRT0yPiZxdW90O0FydGhpIEF5eWFuZ2FyJnF1b3Q7ICZsdDthcnRo
aUBqdW5pcGVyLm5ldCZndDssIERpbWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FU
RUw8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+Y2M6PC9GT05UPiA8Rk9OVCBTSVpFPTI+Jmx0O2Nj
YW1wQG9wcy5pZXRmLm9yZyZndDs8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+YmNjOjwvRk9OVD4g
PEJSPiA8Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5SZTogTFNQIHN0
aXRjaGluZyBxdWVzdGlvbnMgZm9yIGRpc2N1c3Npb248L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48
UD5EaW1pdHJpLDxCUj48QlI+SXQgc2VlbXMgdG8gbWUgdGhhdCBJIG1vc3RseSBhZ3JlZSg/ISkg
d2l0aCB3aGF0IHlvdSB3cm90ZSBpbiB0aGlzIG1haWwuIEknZCBzdGlsbCB3YW50IHRvIGNvbmZp
cm0geW91ciB2aWV3cyZuYnNwOyBvbiB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczo8QlI+PEJSPjxC
Uj5hKSBJcyBpdCBwb3NzaWJsZSAoc2hvdWxkIHdlIGFsbG93KSB0byBzdGl0Y2gmbmJzcDsgUFND
MSBlMmUgTFNQIGJ5IGEgTFNDIExTUCBzZWdtZW50ID8gPEJSPjxCUj5iKSBJcyBpdCBwb3NzaWJs
ZSAoc2hvdWxkIHdlIGFsbG93KSB0byBzdGl0Y2gmbmJzcDsmbmJzcDtWQzEyIGUyZSBMU1AgYnkg
YSZuYnNwO1ZDNCBMU1Agc2VnbWVudCA/IDxCUj5jKSBJcyBpdCBwb3NzaWJsZSAoc2hvdWxkIHdl
IGFsbG93KSB0byBzdGl0Y2gmbmJzcDsmbmJzcDtQU0MxIGUyZSBMU1AgYnkgYSZuYnNwO1BTQzIg
TFNQIHNlZ21lbnQgPzxCUj48QlI+TXkgYW5zd2VycyBhcmUgTk8gdG8gYWxsIHRocmVlIHF1ZXN0
aW9ucy4gWW91IGNhbiBzdGljdGggUFNDMSB3aXRoIFBTQzEsIFZDMTIgd2l0aCBWQzEyLCBldGMu
IEluIGFsbCBvdGhlciBjYXNlcyB5b3UgbmVlZCwgZmlyc3QsIHRvIHNldHVwIGEgaGllcmFyY2hp
Y2FsIExTUCAoSC1MU1ApICh3aGV0aGVyIGl0IGlzIEZBLUxTUCAoc2luZ2xlIGRvbWFpbikgb3Ig
bm90Jm5ic3A7KG11bHRpLWRvbWFpbikpIGluIG9yZGVyIHRvIGNyZWF0ZSBhIGRhdGEgbGluayBv
ZiB0aGUgZTJlIExTUCBzd2l0Y2hpbmcgY2FwYWJpbGl0eSBhbmQgb25seSBhZnRlciB0aGF0IHlv
dSBjYW4gYWxzbyZuYnNwO3VzZSBhIHN0aXRjaGluZyBzZWdtZW50IG9uIHRvcCBvZiAmbmJzcDt0
aGlzIEgtTFNQKS48QlI+PEJSPlNlZSBhbHNvIGluLWxpbmUuPEJSPjxCUj5JZ29yPEJSPjxCUj48
QlI+PEZPTlQgU0laRT00Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+PEI+RnJvbTo8L0I+IDwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxVRT48
VT48QSBIUkVGPW1haWx0bzpEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZT5EaW1pdHJp
LlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZTwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9NCBDT0xP
Uj1CTEFDSz4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+PEI+VG86PC9CPiA8L0ZPTlQ+PEZPTlQg
U0laRT00IENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86YXJ0aGlAanVuaXBlci5uZXQ+QXJ0
aGkgQXl5YW5nYXI8L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDwvRk9O
VD48QlI+PEZPTlQgU0laRT00PjxCPkNjOjwvQj4gPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1C
TFVFPjxVPjxBIEhSRUY9bWFpbHRvOmlicnlza2luQG1vdmF6LmNvbT5JZ29yIEJyeXNraW48L0E+
PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDsgPC9GT05UPjxGT05UIFNJWkU9
NCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOmNjYW1wQG9wcy5pZXRmLm9yZz5jY2FtcEBv
cHMuaWV0Zi5vcmc8L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IDwvRk9O
VD48QlI+PEZPTlQgU0laRT00PjxCPlNlbnQ6PC9CPiBXZWRuZXNkYXksIEp1bHkgMjAsIDIwMDUg
NDo0NiBBTTwvRk9OVD48QlI+PEZPTlQgU0laRT00PjxCPlN1YmplY3Q6PC9CPiBSZTogTFNQIHN0
aXRjaGluZyBxdWVzdGlvbnMgZm9yIGRpc2N1c3Npb248L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpF
PTQ+YXJ0aGksIDwvRk9OVD48QlI+PEJSPjxCUj48QlI+PEZPTlQgU0laRT00PmZpcnN0IGEgcmVj
YXA6IHRoaXMgaXRlbSBvbiBzdGl0Y2hpbmcgd2FzIGluaXRpYXRlZCBpbiBvcmRlciB0byBhbGxv
dyBwZXIgJnF1b3Q7ZG9tYWluJnF1b3Q7IGNvbnRyb2wgb2YgZW5kLXRvLWVuZCAoY29udGlndW91
cykgTFNQLCBhcyBwYXJ0IG9mIGEgc2VwYXJhdGUgZG9jdW1lbnQsIGFuZCBub3QgdG8gZXh0ZW5k
IGl0cyBzY29wZSAodW5kdWx5LCBpbiB0aGlzIGNhc2UsIHNlZSBiZWxvdykgYnV0IG1haW5seSBp
biBvcmRlciB0byBoYXZlIHRoZSBzZXQgb2YgYWxsIHJlbGF0ZWQgcHJvdG9jb2wgbWVjaGFuaXNt
cyB3aXRoaW4gYSBzcGVjaWZpYyBkb2N1bWVudCAtPC9GT05UPjxCUj48QlI+PEJSPjxCUj48Rk9O
VCBTSVpFPTQ+ZnJvbSB0aGlzIGluaXRpYWwgd29ya2luZyBhc3N1bXB0aW9uLCBpdCBpcyBjbGVh
ciB0aGF0IHRoZSBzZWdtZW50IG11c3QgaGF2ZSB0aGUgcHJvcGVydGllcyBvZiB0aGUgaW5jb21p
bmcgZW5kLXRvLWVuZCBMU1Agd2hpY2ggYXJlIGRldGVybWluZWQgYW1vbmcgb3RoZXIgYnkgaXRz
IHN3aXRjaGluZyB0eXBlIGUuZy4gUFNDLTMgb3IgVERNLCB0aGUgZmlyc3QgcmVxdWlyZW1lbnQg
b2YgTFNQIHN0aXRjaGluZyBpcyBjb250aWd1aXR5IG9mIHRoZSBlbmQtdG8tZW5kIExTUCBhdCB0
aGUgZGF0YSBwbGFuZSBsZXZlbCAoYWZ0ZXIgc3RpdGNoaW5nIG9wZXJhdGlvbikgLSBhbmQgdGhp
cyBieSBkZWZpbml0aW9uIG9mIHRoZSBpbml0aWFsIHdvcmtpbmcgYXNzdW1wdGlvbiAtPC9GT05U
PjxCUj48QlI+PEZPTlQgU0laRT00PklCJmd0OyZndDsgQWdyZWU8L0ZPTlQ+PEJSPjxCUj48Rk9O
VCBTSVpFPTQ+bm90ZTogdGhlIG9ubHkgbGF0aXR1ZGUgd2hpY2ggaXMgbGVmdCAoZm9yIGEgZ2l2
ZW4gc3dpdGNoaW5nIHR5cGUgZS5nLiBQU0MtMikgaXMgZHVlIHRvIHRoZSBwcm9wZXJ0aWVzIG9m
IHBhY2tldCAoUFNDKSBuZXR3b3JrcyB0aGF0IGFsbG93cyB5b3Ugc3RpdGNoIGEgc2VnbWVudCBo
YXZpbmcgYSBsYXJnZXIgTWF4IFJlc2VydmFibGUgQmFuZHdpZHRoIGFuZCBVbnJlc2VydmVkIEJh
bmR3aWR0aCAod2Ugd291bGQgaGF2ZSBlcXVpdmFsZW50IGxhdGl0dWRlIGZvciBvdGhlciBhdHRy
aWJ1dGVzIGJ1dCB0aGlzIGlzIGEgbG9jYWwgcG9saWN5IGRlY2lzaW9uIC0gd2hpY2ggYXQgdGhl
IGVuZCBpcyB0aGUgc29sZSBwdXJwb3NlIG9mIHRoaXMgYXBwcm9hY2gpPC9GT05UPjxCUj48QlI+
PEZPTlQgU0laRT00PklCJmd0OyZndDsgRGlzYWdyZWUuIENvbmNlcHR1YWxseSBQQ1MxIGFuZCBQ
U0MyIGFyZSBkaWZmZXJlbnQgbGF5ZXJzIGFuZCB0aGUgbGF0dGVyIGNhbm5vdCBzdGl0Y2ggdGhl
IGZvcm1lciwganVzdCBsaWtlIGluIGNhc2UgVkMxMiBhbmQgVkM0LiBZb3Ugc2hvdWxkIG5lc3Qg
UFNDMSB3aXRoaW4gUFNDMiBpbnN0ZWFkLjwvRk9OVD48QlI+PEJSPjxCUj48QlI+PEZPTlQgU0la
RT00PkhlcmUgYXJlIHNvbWUgb2YgdGhlIHF1ZXN0aW9ucyByZWxhdGVkIHRvIExTUCBzdGl0Y2hp
bmcgdG8gc3RhcnQgYTwvRk9OVD48QlI+PEZPTlQgU0laRT00PmRpc2N1c3Npb24gb24gdGhlIHVz
YWdlIG9mIExTUCBzdGl0Y2hpbmcuPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PiZndDsxKSBB
cmUgdGhlIGNvbnRyb2wgcGxhbmUgc2lnbmFsaW5nIHByb2NlZHVyZXMgZm9yIExTUCBzdGl0Y2hp
bmcgYXM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ZGVzY3JpYmVkIGluIHRoaXMgSUQsIChl
eHBsaWNpdCByZXF1ZXN0IGZvciBMU1Agc3RpdGNoaW5nIG9uPC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQ+Jmd0O0xTUCBzZWdtZW50LCBkaWZmZXJlbnQgbGFiZWwgYWxsb2NhdGlvbiBydWxlczsgZXRj
KSBSRVFVSVJFRCB0byBzdGl0Y2g8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7cGFja2V0IExT
UHMgaW4gZGF0YSBwbGFuZSA/PC9GT05UPjxCUj48QlI+PEJSPjxGT05UIFNJWkU9ND4tJmd0OyB5
ZXMgKGJlc2lkZSBtYW51YWwgY29uZmlnIG9wZXJhdGlvbik8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBT
SVpFPTQ+SUImZ3Q7Jmd0OyBBZ3JlZTwvRk9OVD48QlI+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OzIpIEFyZSB0aGUgY29udHJvbCBwbGFuZSBzaWduYWxpbmcgcHJvY2VkdXJlcyBmb3IgTFNQIHN0
aXRjaGluZyBhczwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDtkZXNjcmliZWQgaW4gdGhpcyBJ
RCwgKGV4cGxpY2l0IHJlcXVlc3QgZm9yIExTUCBzdGl0Y2hpbmcgb248L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7TFNQIHNlZ21lbnQsIGRpZmZlcmVudCBsYWJlbCBhbGxvY2F0aW9uIHJ1bGVz
OyBldGMpIFJFUVVJUkVEIHRvIHN0aXRjaDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDtub24t
cGFja2V0IExTUHMgaW4gZGF0YSBwbGFuZSA/PC9GT05UPjxCUj48QlI+PEJSPjxGT05UIFNJWkU9
ND4tJmd0OyB5ZXMgKGJlc2lkZSBtYW51YWwgY29uZmlnIG9wZXJhdGlvbik8L0ZPTlQ+PEJSPjxC
Uj48Rk9OVCBTSVpFPTQ+SUImZ3Q7Jmd0OyBBZ3JlZTwvRk9OVD48QlI+PEJSPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OzMpIElmIGFuIGUyZSBMU1AgY3Jvc3NlcyBhIHJlZ2lvbiBib3VuZGFyeSAoYmFz
ZWQgb24gZGlmZmVyZW50IFRFPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0O2xpbmsgc3dpdGNo
aW5nIGNhcGFiaWxpdGllcyksIHRoZW4gY2FuIEkgdXNlIExTUCBzdGl0Y2hpbmcgLTwvRk9OVD48
QlI+PEZPTlQgU0laRT00PiZndDthKSBjb250cm9sIHBsYW5lIHByb2NlZHVyZXMgZm9yIHBhY2tl
dCBMU1BzPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0O2IpIGRhdGEgcGxhbmUgcHJvY2VkdXJl
cyBmb3IgcGFja2V0IExTUHM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7YykgY29udHJvbCBw
bGFuZSBwcm9jZWR1cmVzIGZvciBub24tcGFja2V0IExTUHM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7ZCkgZGF0YSBwbGFuZSBwcm9jZWR1cmVzIGZvciBub24tcGFja2V0IExTUHM8L0ZPTlQ+
PEJSPjxCUj48QlI+PEZPTlQgU0laRT00Pi0mZ3Q7IG5vLCB3aGVuIGNyb3NzaW5nIGEgcmVnaW9u
IGJvdW5kYXJ5LCB5b3Ugc2ltcGx5IHVzZSBhIGRvY3VtZW50IG5hbWVkICZxdW90O2RyYWZ0LW1w
bHMtbHNwLWhpZXJhcmNoeS0wOC50eHQmcXVvdDsgd2hpY2ggaXMgaW4gdGhlIFJGQyBFZGl0b3Ig
cXVldWUsIGJ1dCB0aGlzIGRvZXMgbm90IHByZXZlbnQgZnJvbSBjcmVhdGluZyBhbiBMU1Agc2Vn
bWVudCBvbiB0b3Agb2YgYW4gRkEtTFNQIChzZWUgYmVsb3cpPC9GT05UPjxCUj48QlI+PEZPTlQg
U0laRT00PklCJmd0OyZndDsgQWdyZWUgd2l0aCB0aGUgY2F2aWF0IHRoYXQgaXQgc2hvdWxkIGJl
IEgtTFNQIGluc3RlYWQgb2YgRkEtTFNQIHRvIGNvdmVyIHNpbmdsZSBhbmQgbXVsdGktZG9tYWlu
IHNjZW5hcmlvczwvRk9OVD48QlI+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OzQpIElmIHRoZSBz
d2l0Y2hpbmcgdHlwZSBvZiBhbiBlMmUgTFNQIGlzIGRpZmZlcmVudCBmcm9tIHRoYXQgb2YgYW4g
TFNQPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0O3NlZ21lbnQsIGNhbiBJIHVzZSBMU1Agc3Rp
dGNoaW5nIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDthKSBjb250cm9sIHBsYW5lIHByb2Nl
ZHVyZXMgZm9yIHBhY2tldCBMU1BzPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0O2IpIGRhdGEg
cGxhbmUgcHJvY2VkdXJlcyBmb3IgcGFja2V0IExTUHM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4m
Z3Q7YykgY29udHJvbCBwbGFuZSBwcm9jZWR1cmVzIGZvciBub24tcGFja2V0IExTUHM8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ZCkgZGF0YSBwbGFuZSBwcm9jZWR1cmVzIGZvciBub24tcGFj
a2V0IExTUHM8L0ZPTlQ+PEJSPjxCUj48QlI+PEZPTlQgU0laRT00Pi0mZ3Q7IG5vLCBpbiB0aGlz
IGNhc2UgcHJvZ3Jlc3Npb24gb2YgdGhlIGVuZC10by1lbmQgTFNQIGVzdGFibGlzaG1lbnQsIGlt
cGxpZXMgdGhhdCB0aGUgTFNQIHNlZ21lbnQgbXVzdCBmdWxmaWwgYSBzZXQgb2YgY29uc3RyYWlu
dHMgY2FycmllZCBhcyBwYXJ0IG9mIHRoZSBpbmNvbWluZyBlbmQtdG8tZW5kIExTUCByZXF1ZXN0
LCBpbiB0aGlzIGNhc2Ugb25lIGhhcyB0byBjcmVhdGUgYW4gTFNQIHNlZ21lbnQgKHdpdGggYSBz
d2l0Y2hpbmcgdHlwZSBlcXVhbCB0byB0aGUgaW5jb21pbmcgZW5kLXRvLWVuZCBMU1Agc3dpdGNo
aW5nIHR5cGUpIG92ZXIgdGhhdCBGQSAoaS5lLiByZWZlcnJlZCBoZXJlIGFib3ZlIHRvIHRoZSBM
U1Agc2VnbWVudCB3aXRoIGEgZGlmZmVyZW50IFN3aXRjaGluZyBUeXBlKTwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+SUImZ3Q7Jmd0OyBBZ3JlZSB3
aXRoIHRoZSBjYXZpYXQgdGhhdCBpdCBzaG91bGQgYmUgSC1MU1AgaW5zdGVhZCBvZiBGQS1MU1Ag
dG8gY292ZXIgc2luZ2xlIGFuZCBtdWx0aS1kb21haW4gc2NlbmFyaW9zPC9GT05UPjxCUj48QlI+
Q2hlZXJzLDxCUj48QlI+SWdvcjxCUj48QlI+PEZPTlQgU0laRT00PiZndDtOb3RlIHRoYXQgYWx0
aG91Z2ggMykgYW5kIDQpIGFwcGVhciB0byBiZSB0aGUgc2FtZSwgdGhlIHJlYXNvbiBJIGhhdmU8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7dGhlbSBhcyBkaWZmZXJlbnQgcXVlc3Rpb25zIGlz
IHRoYXQgaW4gb25lIGNhc2UgdGhlIFRFIGxpbmsgc3dpdGNoaW5nPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0O2NhcGFiaWxpdHkgaXMgZXhhbWluZWQgYW5kIGluIHRoZSBvdGhlciBjYXNlIHRo
ZSBHZW5lcmFsaXplZCBMYWJlbCBSZXF1ZXN0PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0O2lz
IGV4YW1pbmVkLjwvRk9OVD48QlI+PEJSPjxCUj48QlI+PEZPTlQgU0laRT00Pi0mZ3Q7IHdoYXQg
aXQgYXBwZWFycyB0byBtZSBpcyB0aGF0IHRoaXMgZGlzY3Vzc2lvbiBtaXhlcyB0aGUgaXNzdWUg
b2YgdGhlIG9wZXJhdGlvbiBkZXNjcmliaW5nIHRoZSBzdGl0Y2hpbmcgb3BlcmF0aW9ucyBhdCB0
aGUgZG9tYWluIGJvdW5kYXJpZXMgZnJvbSB0aGUgTFNQIHNlZ21lbnQgY3JlYXRpb24gaXRzZWxm
IGkuZS4gYW4gTFNQIHNlZ21lbnQgY2FuIGluZGVlZCBiZSBhbiBGQSBsaW5rIGluaGVyaXRlZCBm
cm9tIHRoZSBjcmVhdGlvbiBvZiBhbiAoaW50cmEtZG9tYWluKSBGQS1MU1AgLSA8L0ZPTlQ+PC9Q
Pg==



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 18:19:12 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fGPZubv8Y3uwT5SE0F//pveBtaHtXUnQzoXBovOI7+BZUCJe0GIMMYsWeHrGA0jUFYKDyH+yfmd/8uBt0n6zCLx6QB76CnGi91Thigp8ksrz0mQC1f4fo8tOfdAvIx8mNq+HqL/rbvi29uQ0o6yLYSn3kR4pnKYDKBP/Hqd7wYQ=  ;
Message-ID: <[e-mail]>
Date: Wed, 20 Jul 2005 11:18:37 -0700 (PDT)
From: Igor Bryskin <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
To: Arthi Ayyangar <[e-mail]>, Igor Bryskin <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-512571639-1121883517=:99174"
Content-Transfer-Encoding: 8bit

--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 <[e-mail]> 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
> > > > [e-mail] 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:
> > > > [e-mail].
> > > > 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;[e-mail]&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" <[e-mail]><BR>&gt; To: "Igor Bryskin" <[e-mail]><BR>&gt; Cc: <[e-mail]>; <[e-mail]>;<BR>&gt; <[e-mail]><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: <[e-mail]><BR>&gt; &gt; &gt; To: <[e-mail]><BR>&gt; &gt; &gt; Cc: <[e-mail]><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; [e-mail] 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; [e-mail].<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--



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 17:47:34 +0000
Message-ID: <00de01c58d53$06b9f7a0$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Stephen Shew" <[e-mail]>, <[e-mail]>
Subject: Re: 
Date: Wed, 20 Jul 2005 13:46:58 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, July 20, 2005 5:54 AM



Adrian, see comment below.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, July 19, 2005 10:02
> To: George Newsome
> Cc: [e-mail]
> 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




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 17:26:27 +0000
Message-ID: <00be01c58d50$00f56730$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: LSP stitching questions for discussion
Date: Wed, 20 Jul 2005 13:25:19 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BB_01C58D2E.79B452C0"

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: [e-mail]=20
  To: Arthi Ayyangar=20
  Cc: Igor Bryskin ; [e-mail]=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=[e-mail]=20
  =
href=3D"mailto:[e-mail]">Dimitri.Papadimitriou@al=
catel.be</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Arthi Ayyangar</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Igor Bryskin</A> ; <A=20
  title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</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--




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 15:40:08 +0000
Sensitivity: 
Subject: RE: Moving LSP ownership between control plane and management plane
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
From: "Dino Bramanti" <[e-mail]>
Date: Wed, 20 Jul 2005 17:39:41 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

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.





Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 15:10:30 +0000
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: End-to-end L2-LSP
Date: Wed, 20 Jul 2005 16:09:56 +0100
Message-ID: <[e-mail]>
Thread-Topic: End-to-end L2-LSP
Thread-Index: AcWII4lsKzFN0JPAQs66qP37pnL8MAFB1CaQ
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>

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

> -----Original Message-----
> From: CHO, JAI HYUNG [mailto:[e-mail]]
> Sent: 14 July 2005 04:24
> To: Spencer,R,Richard,XDE73 R; [e-mail]
> 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 :       [phone]
> oversea: [phone]
> fax:         [phone]=20
>=20
>=20
>=20
>=20
> -----?? ???-----=20
> ?? ??: "[e-mail]" <[e-mail]>=20
> ?? ??: 2005-07-14 ?? 1:10:30=20
> ?? ??: "[e-mail]" <[e-mail]>,=20
> "[e-mail]" <[e-mail]>=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:[e-mail]]=20
> > Sent: 13 July 2005 15:14=20
> > To: Spencer,R,Richard,XDE73 R; [e-mail]=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
> > ?? ??: "[e-mail]" <[e-mail]>=20
> > ?? ??: 2005-07-13 ?? 8:53:13=20
> > ?? ??: "[e-mail]" <[e-mail]>,=20
> > "[e-mail]" <[e-mail]>=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:[e-mail]]=20
> > > Sent: 12 July 2005 09:21=20
> > > To: Spencer,R,Richard,XDE73 R; [e-mail]=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: [e-mail]=20
> > [mailto:[e-mail]]On=20
> > > > Behalf Of CHO, JAI HYUNG=20
> > > > Sent: 12 July 2005 01:10=20
> > > > To: [e-mail]=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 :       [phone]=20
> > > > oversea: [phone]=20
> > > > fax:         [phone]=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 14:50:19 +0000
Sensitivity: 
Subject: RE: Moving LSP ownership between control plane and management plane
To: [e-mail]
Cc: "<ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 20 Jul 2005 16:48:14 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

In line

Regards

Diego



"Stephen Shew" <[e-mail]> on 20/07/2005 14.25.18

To:    "Diego Caviglia" <[e-mail]>
cc:    <[e-mail]>

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
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Diego Caviglia
> > Sent: Wednesday, July 20, 2005 05:44
> > To: [e-mail]
> > 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>
>
>
>
>
>
>
>
>









Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 14:50:11 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 12:26:45 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE:  Moving LSP ownership between control plane and management plane
Date: Wed, 20 Jul 2005 08:25:18 -0400
Message-ID: <[e-mail]>
Thread-Topic:  Moving LSP ownership between control plane and management plane
Thread-Index: AcWNHrYFsDY/8jdvSoOTo+HceyEd8QABafkw
From: "Stephen Shew" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>
Cc: <[e-mail]>

See below.

> -----Original Message-----
> From: Diego Caviglia [mailto:[e-mail]]=20
> Sent: Wednesday, July 20, 2005 07:33
> To: Shew, Stephen [CAR:QT30:EXCH]
> Cc: [e-mail]
> Subject: Re:
>=20
>=20
>=20
> Hi Stephen,
>             my answers in line.
>=20
> Regards
>=20
> Diego
>=20
>=20
>=20
> "Stephen Shew" <[e-mail]>@ops.ietf.org on 20/07/2005 12.22.49
>=20
> Sent by:    [e-mail]
>=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
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On=20
> > Behalf Of Diego Caviglia
> > Sent: Wednesday, July 20, 2005 05:44
> > To: [e-mail]
> > 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



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 11:39:45 +0000
Message-ID: <154801c58d1f$f063c4a0$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>, <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>, <[e-mail]>
Subject: Re: LSP stitching questions for discussion
Date: Wed, 20 Jul 2005 12:28:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 11:32:43 +0000
Sensitivity: 
Subject: Re:
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 20 Jul 2005 13:32:40 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Stephen,
            my answers in line.

Regards

Diego



"Stephen Shew" <[e-mail]>@ops.ietf.org on 20/07/2005 12.22.49

Sent by:    [e-mail]


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


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Diego Caviglia
> Sent: Wednesday, July 20, 2005 05:44
> To: [e-mail]
> 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>









Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 11:25:10 +0000
To: "Diego Caviglia" <[e-mail]>
Cc: "Dimitri.Papadimitriou" <[e-mail]>, "ccamp" <[e-mail]>, "gnewsome" <[e-mail]>, "adrian" <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Moving LSP ownership between control plane and management plane
Date: Wed, 20 Jul 2005 13:23:42 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmRpZWdvIDwvRk9OVD48L1A+PFA+PEZP
TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmFzIHBhcnQgb2YgdGhlIG1vdGl2YXRpb24gc2Vj
dGlvbiBvZiB0aGlzIGRvY3VtZW50IGl0IHdvdWxkIGJlIGluZGVlZCBpbnRlcmVzdGluZyB0byBi
ZSBtdWNoIG1vcmUgZXhwbGljaXQgYWJvdXQgdGhlIENQLSZndDtNUCBoYW5kb3ZlciBwdXJwb3Nl
KHMpIGJlZm9yZSBwcm9ncmVzc2luZyBvbiB0aGlzIHBhcnQgb2YgdGhlIG1lY2hhbmlzbTwvRk9O
VD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0gZC48L0ZPTlQ+PEJSPjxC
Uj48Rk9OVCBTSVpFPTI+PEI+JnF1b3Q7RGllZ28gQ2F2aWdsaWEmcXVvdDsgJmx0O0RpZWdvLkNh
dmlnbGlhQG1hcmNvbmkuY29tJmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj5TZW50IGJ5
OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj4wNy8yMC8y
MDA1IDExOjM3IFpFMjwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9O
VCBTSVpFPTI+RGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTDwvRk9OVD48
QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj4mcXVvdDtjY2FtcCZxdW90
OyAmbHQ7Y2NhbXBAb3BzLmlldGYub3JnJmd0OywgJnF1b3Q7Z25ld3NvbWUmcXVvdDsgJmx0O2du
ZXdzb21lQGllZWUub3JnJmd0OywgJnF1b3Q7YWRyaWFuJnF1b3Q7ICZsdDthZHJpYW5Ab2xkZG9n
LmNvLnVrJmd0OzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxGT05U
IFNJWkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZPTlQgU0laRT0yPlJFOiBNb3ZpbmcgTFNQIG93bmVy
c2hpcCBiZXR3ZWVuIGNvbnRyb2wgcGxhbmUgYW5kIG1hbmFnZW1lbnQgcGxhbmU8L0ZPTlQ+PEJS
PiA8QlI+PEJSPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+RGltaXRyaSw8
QlI+eWVzIG9mIGNvdXJzZSB0aGUgbWFpbiBhcHBsaWNhdGlvbiBpcyBNUC0tJmd0O0NQIHRoZSBD
UC0tJmd0O01QIGlzIGp1c3Q8L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy
Ij5mb3Igc2ltbWV0cnk7LSkpPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENv
dXJpZXIiPkRpZWdvPEJSPjwvRk9OVD48QlI+PEJSPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2Us
Q291cmllciI+RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUgb24gMjAvMDcvMjAwNSAx
MS4zMC4zNTxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5Ubzog
Jm5ic3A7ICZuYnNwOyZxdW90O0RpZWdvIENhdmlnbGlhJnF1b3Q7ICZsdDtEaWVnby5DYXZpZ2xp
YUBtYXJjb25pLmNvbSZndDs8QlI+Y2M6ICZuYnNwOyAmbmJzcDtjY2FtcEBvcHMuaWV0Zi5vcmcs
IGduZXdzb21lQGllZWUub3JnLCBhZHJpYW5Ab2xkZG9nLmNvLnVrPEJSPjwvRk9OVD48QlI+PEZP
TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlN1YmplY3Q6ICZuYnNwOyAmbmJzcDtSRTogTW92
aW5nIExTUCBvd25lcnNoaXAgYmV0d2VlbiBjb250cm9sIHBsYW5lIGFuZCBtYW5hZ2VtZW50PEJS
PnBsYW5lPC9GT05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmRpZWdv
IC08QlI+PC9GT05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZxdW90
O015IGJhc2ljIHF1ZXN0aW9uIGlzOiBkbyBzb21lb25lIHRoaW5rIHRoYXQgaGF2aW5nIGEgbWVj
aGFuaXNtIHRvIG1vdmU8QlI+TVAvQ1AgY3JlYXRlZCBMU1AgdW5kZXIgdGhlIENQL01QIGRvbWFp
biBpcyB1c2VsZXNzPyZxdW90OzxCUj48L0ZPTlQ+PEJSPjxCUj48QlI+PEJSPjxCUj48Rk9OVCBG
QUNFPSJNb25vc3BhY2UsQ291cmllciI+bm8gLTxCUj48L0ZPTlQ+PEJSPjxCUj48QlI+PEJSPjxC
Uj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+aW4gcGFydC4gdGhlIE1QLSZndDtDUCBo
YW5kb3ZlciBpcyBhIGtleSBtZWNoYW5pc20gZm9yIG1pZ3JhdGlvbiB0b3dhcmQgR01QTFM8QlI+
Q1A8QlI+PC9GT05UPjxCUj48QlI+PEJSPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENv
dXJpZXIiPi1kaW1pdHJpLjxCUj48L0ZPTlQ+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxC
Uj48QlI+PEJSPjxCUj48L1A+



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 10:29:30 +0000
Message-ID: <146101c58d16$384833a0$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Tom Petch" <[e-mail]>, <[e-mail]>
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Wed, 20 Jul 2005 10:54:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Tom,

I don't think it is CCAMP's role to correct the English of another SDO :-)

Thanks,
Adrian
----- Original Message ----- 
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
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" <[e-mail]>
> To: <[e-mail]>
> Cc: "'Kireeti Kompella'" <[e-mail]>; <[e-mail]>; "Bill
Fenner"
> <[e-mail]>; "Scott Bradner" <[e-mail]>
> 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
> >
> >
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 10:29:24 +0000
Message-ID: <145201c58d16$30300ee0$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Scott Brim \(sbrim\)" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Wed, 20 Jul 2005 10:45:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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)" <[e-mail]>
To: <[e-mail]>
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 :-)






Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 10:29:16 +0000
Message-ID: <145f01c58d16$318b0b00$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "Thomas D. Nadeau" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Re: no more milestones?
Date: Wed, 20 Jul 2005 10:49:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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
>  >
>
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 10:23:32 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: 
Date: Wed, 20 Jul 2005 06:22:49 -0400
Message-ID: <[e-mail]>
Thread-Index: AcWNFPrDLlo2GHD0TOCErNAWoJnGlQ==
From: "Stephen Shew" <[e-mail]>
To: "\"ccamp\" <ccamp" <[e-mail]>

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


> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Diego Caviglia
> Sent: Wednesday, July 20, 2005 05:44
> To: [e-mail]
> 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



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 09:54:35 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: 
Date: Wed, 20 Jul 2005 05:54:07 -0400
Message-ID: <[e-mail]>
Thread-Index: AcWNEPgdeHoo0tewQNGL9l/vVMgTtQ==
From: "Stephen Shew" <[e-mail]>
To: <[e-mail]>

Adrian, see comment below.

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, July 19, 2005 10:02
> To: George Newsome
> Cc: [e-mail]
> 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



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 09:44:43 +0000
Sensitivity: 
Subject: RE: Moving LSP ownership between control plane and management plane
To: [e-mail]
Cc: "\"\"Dimitri.Papadimitriou\" <Dimitri.Papadimitriou\"" <[e-mail]>, ""ccamp" <ccamp" <[e-mail]>, ""gnewsome" <gnewsome" <[e-mail]>, ""adrian" <adrian" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 20 Jul 2005 11:44:13 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

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: [phone]
   Email: [e-mail]


   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: [e-mail]

   Nicola Ciulli
   NextWorks
   Corso Italia 116
   56125 Pisa, Italy
   Email: [e-mail]


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-
   [e-mail].


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]

=





Envelope-to: [e-mail]
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" <[e-mail]>
Cc: "ccamp" <[e-mail]>, "gnewsome" <[e-mail]>, "adrian" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 20 Jul 2005 11:37:09 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Dimitri,
         yes of course the main application is MP-->CP the CP-->MP is just
for simmetry;-))

Diego



[e-mail] on 20/07/2005 11.30.35

To:    "Diego Caviglia" <[e-mail]>
cc:    [e-mail], [e-mail], [e-mail]

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.















Envelope-to: [e-mail]
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" <[e-mail]>
Cc: "Adrian Farrel <adrian" <[e-mail]>, "ccamp" <[e-mail]>, "Neil Harrison <neil.2.harrison" <[e-mail]>, "Dino Bramanti <Dino.Bramanti" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 20 Jul 2005 11:32:04 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

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 <[e-mail]>@ops.ietf.org on 20/07/2005 11.03.00

Sent by:    [e-mail]


To:    Adrian Farrel <[e-mail]>
cc:    [e-mail], Neil Harrison <[e-mail]>, Dino
       Bramanti <[e-mail]>

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).
>
>
>










Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 09:31:22 +0000
To: "Diego Caviglia" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Moving LSP ownership between control plane and management plane
Date: Wed, 20 Jul 2005 11:30:35 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmRpZWdvIC08QlI+PEJSPjxCUj4mcXVv
dDtNeSBiYXNpYyBxdWVzdGlvbiBpczogZG8gc29tZW9uZSB0aGluayB0aGF0IGhhdmluZyBhIG1l
Y2hhbmlzbSB0byBtb3ZlPEJSPk1QL0NQIGNyZWF0ZWQgTFNQIHVuZGVyIHRoZSBDUC9NUCBkb21h
aW4gaXMgdXNlbGVzcz8mcXVvdDs8L0ZPTlQ+PC9QPjxQPiZuYnNwOzwvUD48UD48Rk9OVCBGQUNF
PSJNb25vc3BhY2UsQ291cmllciI+bm8gLSA8L0ZPTlQ+PC9QPjxQPiZuYnNwOzwvUD48UD48Rk9O
VCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+aW4gcGFydC4gdGhlIE1QLSZndDtDUCBoYW5kb3Zl
ciBpcyBhIGtleSBtZWNoYW5pc20gZm9yIG1pZ3JhdGlvbiB0b3dhcmQgR01QTFMgQ1A8L0ZPTlQ+
PC9QPjxQPiZuYnNwOzwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+LWRpbWl0
cmkuPEJSPjwvRk9OVD48QlI+PEJSPjxCUj48QlI+PEJSPjwvUD4=



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 09:04:12 +0000
Message-ID: <[e-mail]>
Date: Wed, 20 Jul 2005 05:03:00 -0400
From: George Newsome <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
Cc: [e-mail], Neil Harrison <[e-mail]>, Dino Bramanti <[e-mail]>
Subject: Re: Moving LSP ownership between control plane and management plane
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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).
> 
> 
> 




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 08:56:52 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Moving LSP ownership between control plane and management plane
Date: Wed, 20 Jul 2005 09:56:04 +0100
Message-ID: <[e-mail]>
Thread-Topic: Moving LSP ownership between control plane and management plane
Thread-Index: AcWM/9UjPIT0x57mRMyOU2Wlm2MZtQABrR8A
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>

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

> -----Original Message-----
> From: Diego Caviglia [mailto:[e-mail]]
> 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
> <[e-mail]>@ops.ietf.org on 19/07/2005 23.36.27
>=20
> Sent by:    [e-mail]
>=20
>=20
> To:    <[e-mail]>, <[e-mail]>
> cc:    <[e-mail]>
>=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
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of George Newsome
> > Sent: 19 July 2005 12:44
> > To: Adrian Farrel
> > Cc: [e-mail]
> > 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



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 08:47:44 +0000
To: Arthi Ayyangar <[e-mail]>
Cc: Igor Bryskin <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: Re: LSP stitching questions for discussion
Date: Wed, 20 Jul 2005 10:46:49 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmFydGhpLCA8L0ZPTlQ+PC9QPjxQPiZu
YnNwOzwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Zmlyc3QgYSByZWNhcDog
dGhpcyBpdGVtIG9uIHN0aXRjaGluZyB3YXMgaW5pdGlhdGVkIGluIG9yZGVyIHRvIGFsbG93IHBl
ciAmcXVvdDtkb21haW4mcXVvdDsgY29udHJvbCBvZiBlbmQtdG8tZW5kIChjb250aWd1b3VzKSBM
U1AsIGFzIHBhcnQgb2YgYSBzZXBhcmF0ZSBkb2N1bWVudCwgYW5kIG5vdCB0byBleHRlbmQgaXRz
IHNjb3BlICh1bmR1bHksIGluIHRoaXMgY2FzZSwgc2VlIGJlbG93KSBidXQgbWFpbmx5IGluIG9y
ZGVyIHRvIGhhdmUgdGhlIHNldCBvZiBhbGwgcmVsYXRlZCBwcm90b2NvbCBtZWNoYW5pc21zIHdp
dGhpbiBhIHNwZWNpZmljIGRvY3VtZW50IC08L0ZPTlQ+PC9QPjxQPiZuYnNwOzwvUD48UD48Rk9O
VCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+ZnJvbSB0aGlzIGluaXRpYWwgd29ya2luZyBhc3N1
bXB0aW9uLCBpdCBpcyBjbGVhciB0aGF0IHRoZSBzZWdtZW50IG11c3QgaGF2ZSB0aGUgcHJvcGVy
dGllcyBvZiB0aGUgaW5jb21pbmcgZW5kLXRvLWVuZCBMU1Agd2hpY2ggYXJlIGRldGVybWluZWQg
YW1vbmcgb3RoZXIgYnkgaXRzIHN3aXRjaGluZyB0eXBlIGUuZy4gUFNDLTMgb3IgVERNLCB0aGUg
Zmlyc3QgcmVxdWlyZW1lbnQgb2YgTFNQIHN0aXRjaGluZyBpcyBjb250aWd1aXR5IG9mIHRoZSBl
bmQtdG8tZW5kIExTUCBhdCB0aGUgZGF0YSBwbGFuZSBsZXZlbCAoYWZ0ZXIgc3RpdGNoaW5nIG9w
ZXJhdGlvbikgLSBhbmQgdGhpcyBieSBkZWZpbml0aW9uIG9mIHRoZSBpbml0aWFsIHdvcmtpbmcg
YXNzdW1wdGlvbiAtPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+
bm90ZTogdGhlIG9ubHkgbGF0aXR1ZGUgd2hpY2ggaXMgbGVmdCAoZm9yIGEgZ2l2ZW4gc3dpdGNo
aW5nIHR5cGUgZS5nLiBQU0MtMikgaXMgZHVlIHRvIHRoZSBwcm9wZXJ0aWVzIG9mIHBhY2tldCAo
UFNDKSBuZXR3b3JrcyB0aGF0IGFsbG93cyB5b3Ugc3RpdGNoIGEgc2VnbWVudCBoYXZpbmcgYSBs
YXJnZXIgTWF4IFJlc2VydmFibGUgQmFuZHdpZHRoIGFuZCBVbnJlc2VydmVkIEJhbmR3aWR0aCAo
d2Ugd291bGQgaGF2ZSBlcXVpdmFsZW50IGxhdGl0dWRlIGZvciBvdGhlciBhdHRyaWJ1dGVzIGJ1
dCB0aGlzIGlzIGEgbG9jYWwgcG9saWN5IGRlY2lzaW9uIC0gd2hpY2ggYXQgdGhlIGVuZCBpcyB0
aGUgc29sZSBwdXJwb3NlIG9mIHRoaXMgYXBwcm9hY2gpPC9GT05UPjwvUD48UD48Rk9OVCBGQUNF
PSJNb25vc3BhY2UsQ291cmllciI+PEJSPjxCUj5IZXJlIGFyZSBzb21lIG9mIHRoZSBxdWVzdGlv
bnMgcmVsYXRlZCB0byBMU1Agc3RpdGNoaW5nIHRvIHN0YXJ0IGE8QlI+ZGlzY3Vzc2lvbiBvbiB0
aGUgdXNhZ2Ugb2YgTFNQIHN0aXRjaGluZy48QlI+PEJSPiZndDsxKSBBcmUgdGhlIGNvbnRyb2wg
cGxhbmUgc2lnbmFsaW5nIHByb2NlZHVyZXMgZm9yIExTUCBzdGl0Y2hpbmcgYXM8QlI+Jmd0O2Rl
c2NyaWJlZCBpbiB0aGlzIElELCAoZXhwbGljaXQgcmVxdWVzdCBmb3IgTFNQIHN0aXRjaGluZyBv
bjxCUj4mZ3Q7TFNQIHNlZ21lbnQsIGRpZmZlcmVudCBsYWJlbCBhbGxvY2F0aW9uIHJ1bGVzOyBl
dGMpIFJFUVVJUkVEIHRvIHN0aXRjaDxCUj4mZ3Q7cGFja2V0IExTUHMgaW4gZGF0YSBwbGFuZSA/
PEJSPjwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0mZ3Q7IHll
cyAoYmVzaWRlIG1hbnVhbCBjb25maWcgb3BlcmF0aW9uKTwvRk9OVD48L1A+PFA+PEZPTlQgRkFD
RT0iTW9ub3NwYWNlLENvdXJpZXIiPjxCUj4mZ3Q7MikgQXJlIHRoZSBjb250cm9sIHBsYW5lIHNp
Z25hbGluZyBwcm9jZWR1cmVzIGZvciBMU1Agc3RpdGNoaW5nIGFzPEJSPiZndDtkZXNjcmliZWQg
aW4gdGhpcyBJRCwgKGV4cGxpY2l0IHJlcXVlc3QgZm9yIExTUCBzdGl0Y2hpbmcgb248QlI+Jmd0
O0xTUCBzZWdtZW50LCBkaWZmZXJlbnQgbGFiZWwgYWxsb2NhdGlvbiBydWxlczsgZXRjKSBSRVFV
SVJFRCB0byBzdGl0Y2g8QlI+Jmd0O25vbi1wYWNrZXQgTFNQcyBpbiBkYXRhIHBsYW5lID88QlI+
PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+LSZndDsgeWVzIChi
ZXNpZGUgbWFudWFsIGNvbmZpZyBvcGVyYXRpb24pPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJN
b25vc3BhY2UsQ291cmllciI+PEJSPiZndDszKSBJZiBhbiBlMmUgTFNQIGNyb3NzZXMgYSByZWdp
b24gYm91bmRhcnkgKGJhc2VkIG9uIGRpZmZlcmVudCBURTxCUj4mZ3Q7bGluayBzd2l0Y2hpbmcg
Y2FwYWJpbGl0aWVzKSwgdGhlbiBjYW4gSSB1c2UgTFNQIHN0aXRjaGluZyAtPEJSPiZndDthKSBj
b250cm9sIHBsYW5lIHByb2NlZHVyZXMgZm9yIHBhY2tldCBMU1BzPEJSPiZndDtiKSBkYXRhIHBs
YW5lIHByb2NlZHVyZXMgZm9yIHBhY2tldCBMU1BzPEJSPiZndDtjKSBjb250cm9sIHBsYW5lIHBy
b2NlZHVyZXMgZm9yIG5vbi1wYWNrZXQgTFNQczxCUj4mZ3Q7ZCkgZGF0YSBwbGFuZSBwcm9jZWR1
cmVzIGZvciBub24tcGFja2V0IExTUHM8QlI+PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25v
c3BhY2UsQ291cmllciI+LSZndDsgbm8sIHdoZW4gY3Jvc3NpbmcgYSByZWdpb24gYm91bmRhcnks
IHlvdSBzaW1wbHkgdXNlIGEgZG9jdW1lbnQgbmFtZWQgJnF1b3Q7ZHJhZnQtbXBscy1sc3AtaGll
cmFyY2h5LTA4LnR4dCZxdW90OyB3aGljaCBpcyBpbiB0aGUgUkZDIEVkaXRvciBxdWV1ZSwgYnV0
IHRoaXMgZG9lcyBub3QgcHJldmVudCBmcm9tIGNyZWF0aW5nIGFuIExTUCBzZWdtZW50IG9uIHRv
cCBvZiBhbiBGQS1MU1AgKHNlZSBiZWxvdyk8L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9z
cGFjZSxDb3VyaWVyIj48QlI+Jmd0OzQpIElmIHRoZSBzd2l0Y2hpbmcgdHlwZSBvZiBhbiBlMmUg
TFNQIGlzIGRpZmZlcmVudCBmcm9tIHRoYXQgb2YgYW4gTFNQPEJSPiZndDtzZWdtZW50LCBjYW4g
SSB1c2UgTFNQIHN0aXRjaGluZyAtPEJSPiZndDthKSBjb250cm9sIHBsYW5lIHByb2NlZHVyZXMg
Zm9yIHBhY2tldCBMU1BzPEJSPiZndDtiKSBkYXRhIHBsYW5lIHByb2NlZHVyZXMgZm9yIHBhY2tl
dCBMU1BzPEJSPiZndDtjKSBjb250cm9sIHBsYW5lIHByb2NlZHVyZXMgZm9yIG5vbi1wYWNrZXQg
TFNQczxCUj4mZ3Q7ZCkgZGF0YSBwbGFuZSBwcm9jZWR1cmVzIGZvciBub24tcGFja2V0IExTUHM8
QlI+PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+LSZndDsgbm8s
IGluIHRoaXMgY2FzZSBwcm9ncmVzc2lvbiBvZiB0aGUgZW5kLXRvLWVuZCBMU1AgZXN0YWJsaXNo
bWVudCwgaW1wbGllcyB0aGF0IHRoZSBMU1Agc2VnbWVudCBtdXN0IGZ1bGZpbCBhIHNldCBvZiBj
b25zdHJhaW50cyBjYXJyaWVkIGFzIHBhcnQgb2YgdGhlIGluY29taW5nIGVuZC10by1lbmQgTFNQ
IHJlcXVlc3QsIGluIHRoaXMgY2FzZSBvbmUgaGFzIHRvIGNyZWF0ZSBhbiBMU1Agc2VnbWVudCAo
d2l0aCBhIHN3aXRjaGluZyB0eXBlIGVxdWFsIHRvIHRoZSBpbmNvbWluZyBlbmQtdG8tZW5kIExT
UCBzd2l0Y2hpbmcgdHlwZSkgb3ZlciB0aGF0IEZBIChpLmUuIHJlZmVycmVkIGhlcmUgYWJvdmUg
dG8gdGhlIExTUCBzZWdtZW50IHdpdGggYSBkaWZmZXJlbnQgU3dpdGNoaW5nIFR5cGUpPC9GT05U
PjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+PEJSPiZndDtOb3RlIHRoYXQg
YWx0aG91Z2ggMykgYW5kIDQpIGFwcGVhciB0byBiZSB0aGUgc2FtZSwgdGhlIHJlYXNvbiBJIGhh
dmU8QlI+Jmd0O3RoZW0gYXMgZGlmZmVyZW50IHF1ZXN0aW9ucyBpcyB0aGF0IGluIG9uZSBjYXNl
IHRoZSBURSBsaW5rIHN3aXRjaGluZzxCUj4mZ3Q7Y2FwYWJpbGl0eSBpcyBleGFtaW5lZCBhbmQg
aW4gdGhlIG90aGVyIGNhc2UgdGhlIEdlbmVyYWxpemVkIExhYmVsIFJlcXVlc3Q8QlI+Jmd0O2lz
IGV4YW1pbmVkLjxCUj48QlI+PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291
cmllciI+LSZndDsgd2hhdCBpdCBhcHBlYXJzIHRvIG1lIGlzIHRoYXQgdGhpcyBkaXNjdXNzaW9u
IG1peGVzIHRoZSBpc3N1ZSBvZiB0aGUgb3BlcmF0aW9uIGRlc2NyaWJpbmcgdGhlIHN0aXRjaGlu
ZyBvcGVyYXRpb25zIGF0IHRoZSBkb21haW4gYm91bmRhcmllcyBmcm9tIHRoZSBMU1Agc2VnbWVu
dCBjcmVhdGlvbiBpdHNlbGYgaS5lLiBhbiBMU1Agc2VnbWVudCBjYW4gaW5kZWVkIGJlIGFuIEZB
IGxpbmsgaW5oZXJpdGVkIGZyb20gdGhlIGNyZWF0aW9uIG9mIGFuIChpbnRyYS1kb21haW4pIEZB
LUxTUCAtIDwvRk9OVD48L1A+



Envelope-to: [e-mail]
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" <[e-mail]>
Cc: "Adrian Farrel <adrian" <[e-mail]>, "ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 20 Jul 2005 10:13:55 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

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 <[e-mail]>@ops.ietf.org on 19/07/2005 13.44.29

Sent by:    [e-mail]


To:    Adrian Farrel <[e-mail]>
cc:    [e-mail]

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).











Envelope-to: [e-mail]
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" <[e-mail]>
Cc: "<gnewsome" <[e-mail]>, "<adrian" <[e-mail]>, "<ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 20 Jul 2005 09:51:43 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

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



<[e-mail]>@ops.ietf.org on 19/07/2005 23.36.27

Sent by:    [e-mail]


To:    <[e-mail]>, <[e-mail]>
cc:    <[e-mail]>

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of George Newsome
> Sent: 19 July 2005 12:44
> To: Adrian Farrel
> Cc: [e-mail]
> 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).
>
>
>
>









Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 07:16:13 +0000
Sensitivity: 
Subject: Re: Moving LSP ownership between control plane and management plane
To: [e-mail]
Message-ID: <[e-mail]>
From: "Dino Bramanti" <[e-mail]>
Date: Wed, 20 Jul 2005 09:15:56 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

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).









Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 06:43:12 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58CF6.0EC950A5"
Subject: TR : I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-01.txt 
Date: Wed, 20 Jul 2005 08:41:28 +0200
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-leroux-ccamp-gmpls-mrn-eval-01.txt 
Thread-Index: AcWM86smKmrBtpT6Sbiy7zzQIn40xQAAAfMw
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>

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--



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 01:50:45 +0000
Message-ID: <[e-mail]>
Date: Wed, 20 Jul 2005 10:50:51 +0900
From: Tomohiro Otani <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-00
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Hi Dimitri,

Ok, I understand what you said. We need more feedback about this.

Regards,

tomo





[e-mail] 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 <[e-mail]>*
>Sent by: [e-mail]
>07/19/2005 09:48 ZE9
>
>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>cc: [e-mail]
>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.
>
>
>
>
>[e-mail] 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 ?
> >
> >
> >
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Jul 2005 00:22:29 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Tue, 19 Jul 2005 19:19:50 -0500
Message-ID: <[e-mail]>
Thread-Topic: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Thread-Index: AcWMXShS3XIKS6HkT1SIyh9DjwERlgAXG04A
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, "Scott Bradner" <[e-mail]>

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

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, July 19, 2005 6:59 AM
> To: [e-mail]
> Cc: 'Kireeti Kompella'; [e-mail]; 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



Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 23:21:53 +0000
Date: Tue, 19 Jul 2005 16:21:30 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: Igor Bryskin <[e-mail]>
cc: [e-mail]
Subject: LSP stitching questions for discussion
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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



Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 23:08:22 +0000
Date: Tue, 19 Jul 2005 16:07:49 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: Igor Bryskin <[e-mail]>
cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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" <[e-mail]>
> To: "Igor Bryskin" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>;
> <[e-mail]>
> 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: <[e-mail]>
> > > To: <[e-mail]>
> > > Cc: <[e-mail]>
> > > 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
> > > > [e-mail] 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:
> > > > [e-mail].
> > > > 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.
> > > >
> > >
> >
>



Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 22:57:31 +0000
To: Tomohiro Otani <[e-mail]>
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: Re: http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-00
Date: Wed, 20 Jul 2005 00:56:09 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmhpLCA8L0ZPTlQ+PC9QPjxQPjxGT05U
IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5pIHdvdWxkIHNheSB0aGF0IDEpIHNob3VsZCBiZSBj
b25zaWRlcmVkIGlmZiB0aGVyZSBoYXZlIGJlZW4gc2V2ZXJhbCBpZGVudGlmaWVkIG1pc2JlaGF2
aW91ciBkZXRlY3RlZCBhbmQgaW5jb25zaXN0ZW5jaWVzIG9ic2VydmVkIHN1Y2ggdGhhdCBhIHNl
dCBvZiBwcmVzY3JpcHRpdmUgZ3VpZGVsaW5lcyBoYXZlIHRvIGJlIHB1dCB0b2dldGhlciAoYnV0
IHRoaXMgd291bGQgdHJhbnNsYXRlIHNvbWUgJnF1b3Q7Y29tbW9uJnF1b3Q7IG1pcy1pbnRlcnBy
ZXRhdGlvbiBvZiB0aGUgc2V0IG9mIGRvY3VtZW50cyB3ZSBjdXJyZW50bHkgaGF2ZSkgPC9GT05U
PjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+aWYgdGhpcyBpcyBub3QgdGhl
IGNhc2UsIHRoZW4gYmVzaWRlIHNvbWUgYmFzZSBkZXNjcmlwdGlvbi9jbGFyaWZpY2F0aW9uLCBp
IGRvbid0IHNlZSBob3cgd2UgY291bGQgdHVybiB0aGlzIGludG8gMikgb3IgMykgd2l0aG91dCBv
YnRhaW5pbmcgYSBsYXJnZXIgc2FtcGxlIG9mIENTUEYvcm91dGluZyBwcmFjdGljZXMgLSB0aGUg
ZGlmZmVyZW5jZSBiZXR3ZWVuIDIpIGFuZCAzKSBiZWluZyB0aGF0IGluIHRoZSBmb3JtZXIgY2Fz
ZSwgaW5mb3JtYXRpb24gZ2F0aGVyZWQgaXMgcHJvY2Vzc2VkIHRvIGRlc2NyaWJlIHByYWN0aWNl
cyBhbmQgZGV2aXNlIG9wZXJhdGlvbmFsIGd1aWRlbGluZXMgd2hpbGUgaW4gdGhlIGxhdHRlciB0
aGUgZG9jdW1lbnQgYXBwZWFycyBhcyBhIGNvbGxlY3Rpb24gb2YgcHJhY3RpY2VzIGZyb20gaW5k
aXZpZHVhbCBwcmFjdGljZXM8L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy
aWVyIj5pbiBhbnkgY2FzZSwgYW5kIGluIG9yZGVyIHRvIHByb2dyZXNzIC0gd2UgbmVlZCBtb3Jl
IGZlZWRiYWNrIC08L0ZPTlQ+PC9QPjxQPiZuYnNwOzwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3Bh
Y2UsQ291cmllciI+dGhhbmtzLDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENv
dXJpZXIiPi1kaW1pdHJpLjwvRk9OVD48L1A+PFA+PEJSPjxGT05UIFNJWkU9Mj48Qj5Ub21vaGly
byBPdGFuaSAmbHQ7b3RhbmlAa2RkaWxhYnMuanAmZ3Q7PC9CPjwvRk9OVD48QlI+PEZPTlQgU0la
RT0yPlNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+PEZPTlQgU0la
RT0yPjA3LzE5LzIwMDUgMDk6NDggWkU5PC9GT05UPjxCUj48QlI+IDxGT05UIFNJWkU9Mj5Ubzo8
L0ZPTlQ+IDxGT05UIFNJWkU9Mj5EaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENB
VEVMPC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmNjOjwvRk9OVD4gPEZPTlQgU0laRT0yPmNjYW1w
QG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxG
T05UIFNJWkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZPTlQgU0laRT0yPlJlOiA8QSBIUkVGPWh0dHA6
Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW90YW5pLWNjYW1wLWdtcGxzLWNz
cGYtY29uc3RyYWludHMtMDA+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh
ZnQtb3RhbmktY2NhbXAtZ21wbHMtY3NwZi1jb25zdHJhaW50cy0wMDwvQT48L0ZPTlQ+PEJSPiA8
QlI+PEJSPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SGkgRGltaXRyaSw8
QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+UGVyIG91ciBpbml0
aWFsIGRpc2N1c3Npb24sIHdlIHdvdWxkIGxpa2UgdG8gZm9ybXVsYXRlPEJSPnRoZSB1bmlmaWVk
IHZpZXcgb24gQ1NQRiBjb25zaWRlcmF0aW9uLCBhbmQgd2Ugc2ltcGx5PEJSPnRob3VnaHQgaXQg
aXMgQkNQLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5Db25z
aWRlcmluZyBtb3JlIGRlZXBseSwgb3VyIGRyYWZ0IGRvZXMgbm90IGRlZmluZSB0aGU8QlI+cHJv
dG9jb2wgaXRzZWxmIGJ1dCB0aGUgcHJvdG9jb2wgcmVsYXRlZCBzcGVjaWZpY2F0aW9uPEJSPjwv
Rk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkluIHRoYXQgc2Vuc2UsIHlv
dSBhcmUgcmlnaHQsIGl0IGlzIHByZXNjcmlwdGl2ZSBtb3JlPEJSPnRoYW4gZGVzY3JpcHRpdmUg
Zm9yIGd1aWRpbmcgb3BlcmF0aW9ucy4gTW9yZW92ZXIsIEkgY2FtZTxCUj51cCBteSBtaW5kIHRo
YXQgaXQgbWF5IGJlIG1vcmUgc3RhbmRhcmQgdHJhY2sgdGhhbiBpbmZvcm1hdGlvbmFsLjxCUj5C
dXQgSSBhbSBub3Qgc3VyZS4gV2hhdCdzIHlvdXIgdGhvdWdodCBvbiB0aGlzID88QlI+PC9GT05U
PjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+V2l0aCBiZXN0IHJlZ2FyZHMsPEJS
PjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnRvbW88QlI+PC9GT05U
PjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+UFM6IFdlIHBvc3RlZCAwMSB2ZXJz
aW9uLjxCUj48L0ZPTlQ+PEJSPjxCUj48QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy
aWVyIj5EaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZSB3cm90ZTo8QlI+PC9GT05UPjxC
Uj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0O2F1dGhvcnMsIGlzIHRoZSBwdXJw
b3NlIG9mIHRoZSBhYm92ZSBtZW50aW9uZWQgZHJhZnQ6PEJSPiZndDs8QlI+Jmd0OyAxLiBwcmVz
Y3JpcHRpdmUgKGV2ZW4gaWYgaW5mb3JtYXRpb25hbCk8QlI+Jmd0OzxCUj4mZ3Q7IDIuIGRlc2Ny
aXB0aXZlIGZvciBndWlkaW5nIG9wZXJhdGlvbnMgKEJDUCk8QlI+Jmd0OzxCUj4mZ3Q7IDMuIGlu
Zm9ybWF0aXZlIChzdXJ2ZXktbGlrZSk8QlI+Jmd0OzxCUj4mZ3Q7ZnJvbSB3aGF0IGkgcmVhZCwg
aXQgaXMgbW9yZSAxIGxpa2UgLSBpcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3QgPzxCUj4mZ3Q7
PEJSPiZndDs8QlI+Jmd0OzxCUj48L0ZPTlQ+PC9QPg==



Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 21:37:52 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Moving LSP ownership between control plane and management plane
Date: Tue, 19 Jul 2005 22:36:27 +0100
Message-ID: <[e-mail]>
Thread-Topic: Moving LSP ownership between control plane and management plane
Thread-Index: AcWMV6fjxUeSjrtZR7+MDzCUlMc0GQACZr5Q
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On=20
> Behalf Of George Newsome
> Sent: 19 July 2005 12:44
> To: Adrian Farrel
> Cc: [e-mail]
> 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



Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 19:51:04 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-04.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 19:50:56 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-01.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 19:31:44 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Tue, 19 Jul 2005 15:30:44 -0400
Message-ID: <[e-mail]>
Thread-Topic: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Thread-Index: AcWMmFsziUnUgjpdQwiSfQ/jbIa2KQ==
From: "Scott Brim \(sbrim\)" <[e-mail]>
To: <[e-mail]>

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 :-)



Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 19:21:18 +0000
Message-ID: <011d01c58c8e$57a1e6c0$0601a8c0@pc6>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: Re: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Tue, 19 Jul 2005 20:18:16 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>; <[e-mail]>; "Bill Fenner"
<[e-mail]>; "Scott Bradner" <[e-mail]>
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
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 18:43:29 +0000
Date: Tue, 19 Jul 2005 11:41:39 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: Adrian Farrel <[e-mail]>
cc: [e-mail], Igor Bryskin <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> 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



Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 16:57:29 +0000
Message-Id: <6.0.0.20.2.20050720013441.03d8b600@129.60.5.226>
Date: Wed, 20 Jul 2005 01:58:21 +0900
To: <[e-mail]>
From: "[e-mail]" <[e-mail]>
Subject: Re: no more milestones?
Cc: "Thomas D. Nadeau" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

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
 >






Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 14:51:24 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-03.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 14:24:57 +0000
Message-ID: <00b201c58c6d$96e0dc90$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Date: Tue, 19 Jul 2005 10:24:35 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>;
<[e-mail]>
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: <[e-mail]>
> > To: <[e-mail]>
> > Cc: <[e-mail]>
> > 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
> > > [e-mail] 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:
> > > [e-mail].
> > > 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.
> > >
> >
>




Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 14:14:01 +0000
Message-ID: <0e6c01c58c6c$66d02200$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Thomas D. Nadeau" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Re: no more milestones?
Date: Tue, 19 Jul 2005 15:15:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 14:03:37 +0000
Message-ID: <0e5301c58c6a$f1d1d5d0$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "George Newsome" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Moving LSP ownership between control plane and management plane
Date: Tue, 19 Jul 2005 15:02:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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).




Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 13:50:02 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Thomas D. Nadeau" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
From: [e-mail]
Subject: Re: no more milestones?
MIME-Version: 1.0
Date: Tue, 19 Jul 2005 15:49:05 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

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







Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 13:37:26 +0000
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: Feedback on draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt
Date: Tue, 19 Jul 2005 15:36:19 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

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: [e-mail]
Delivery-date: Tue, 19 Jul 2005 12:35:51 +0000
Date: Tue, 19 Jul 2005 21:35:28 +0900 (JST)
From: Kenichi Nagami <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
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




Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 12:26:43 +0000
Message-ID: <0df301c58c5d$5e1a5b80$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: Proposed response to ITU-T SG15 Questions 12 and 14 on ASON Lexicography
Date: Tue, 19 Jul 2005 12:59:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 11:47:14 +0000
Message-ID: <[e-mail]>
Date: Tue, 19 Jul 2005 07:44:29 -0400
From: George Newsome <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
Cc: [e-mail]
Subject: Re: Moving LSP ownership between control plane and management plane
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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).





Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 08:39:11 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58C3D.1688A89B"
Subject: TR :  I-D ACTION:draft-leroux-ccamp-ctrl-saturation-01.txt 
Date: Tue, 19 Jul 2005 10:37:23 +0200
Message-ID: <[e-mail]>
Thread-Topic:  I-D ACTION:draft-leroux-ccamp-ctrl-saturation-01.txt 
Thread-Index: AcWMOqCIJ1enawf0Ry2TRvWFIUEtPAAAEfbg
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>

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--



Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 08:39:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: no more milestones?
Date: Tue, 19 Jul 2005 09:36:18 +0100
Message-ID: <[e-mail]>
Thread-Topic: no more milestones?
Thread-Index: AcWL2gpHx44PAcioRP6bjKbT0RZ4CwAUdAwQ
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>

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



Envelope-to: [e-mail]
Delivery-date: Tue, 19 Jul 2005 00:48:54 +0000
Message-ID: <[e-mail]>
Date: Tue, 19 Jul 2005 09:48:32 +0900
From: Tomohiro Otani <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-00
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

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.




[e-mail] 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 ?
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 21:47:50 +0000
Message-ID: <008101c58be2$5082b420$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Date: Mon, 18 Jul 2005 17:47:37 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Arthi,

----- Original Message ----- 
From: "Arthi Ayyangar" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>;
<[e-mail]>
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: <[e-mail]>
> > To: <[e-mail]>
> > Cc: <[e-mail]>
> > 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
> > > [e-mail] 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:
> > > [e-mail].
> > > 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.
> > >
> >
>




Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 21:40:36 +0000
Message-ID: <0d5e01c58be1$966ebf70$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Moving LSP ownership between control plane and management plane
Date: Mon, 18 Jul 2005 22:40:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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: <[e-mail]>
To: <[e-mail]>
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
> [e-mail] 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:
> [e-mail].
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>




Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 21:40:29 +0000
Message-ID: <0d5c01c58be1$8ca4cc00$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>, <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>, <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Date: Mon, 18 Jul 2005 22:23:17 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

[[e-mail] and [e-mail] 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




Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 20:49:54 +0000
Message-ID: <0cf601c58bda$60c2fcd0$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Thomas D. Nadeau" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Re: no more milestones?
Date: Mon, 18 Jul 2005 21:40:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 20:49:46 +0000
Message-ID: <0cf701c58bda$6c49bb70$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Thomas D. Nadeau" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Re: no more milestones?
Date: Mon, 18 Jul 2005 21:47:09 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 19:23:00 +0000
MIME-Version: 1.0
To: "Thomas D. Nadeau" <[e-mail]>
Cc: [e-mail], "Adrian Farrel" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
From: [e-mail]
Subject: Re: no more milestones?
Date: Mon, 18 Jul 2005 21:20:39 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnRvbSAtIDwvRk9OVD48L1A+PFA+PEZP
TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPml0IHNlZW1zIHRvIG1lIHRvIGJlIHRoZSByaWdo
dCB0aW1lIHRvIHdyYXAgdXAgYW5kIGxvb2sgYWZ0ZXIgdGhlIGJhc2Ugb3BlcmF0aW9uIG1lY2hh
bmlzbXMgdG8gYmUgcHV0IGluIHBsYWNlIGZvciB0aGUgZmlyc3QgcGhhc2Ugb2YgYmFzZSBHTVBM
UyBkZXBsb3ltZW50IGFzIHdlbGwgLSBhbmQgbGVhdmUgdGhlIG1vcmUgYWR2YW5jZWQgbWVjaGFu
aXNtcyB0byAmbmJzcDsmcXVvdDtDQ0FNUC1JTkcmcXVvdDsgbGlrZS1XRyhzKSBhcyBpbmRpY2F0
ZWQgaW4gYSBwcmV2aW91cyBlLW1haWwgLTwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3Nw
YWNlLENvdXJpZXIiPml0IGlzIGluZGVlZCBkaWZmaWN1bHQgdG8gdW5kZXJzdGFuZCB3aHkgdGhp
cyBpcyBub3QgY291cGxlZCB0byB0aGUgYmFzZSBwcm90b2NvbCBkZXZlbG9wbWVudCBhcyBNSUJz
IGFyZSBvdGhlcndpc2UgR01QTFMgd2lsbCBhcHBlYXIgbGlrZSBhIHdvbmRlcmZ1bCBhbmQgcG93
ZXJmdWwgdG9vbGJveCBkZXZlbG9wZWQgYnkgdGhlIElFVEYgYnV0IHdpdGhvdXQgdGhlIGFwcHJv
cHJpYXRlIHVzZXIgbWFudWFsIDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENv
dXJpZXIiPmkgd291bGQgbmV2ZXJ0aGVsZXNzIGFkZCB3ZSBoYXZlIGFsc28gYSBzdHJvbmcgbmVl
ZCBmb3IgbW9yZSBvcGVyYXRpb25hbCBmZWVkYmFjayBvdGhlcndpc2UgdGhlIHVzZXIgbWFudWFs
IHdpbGwgdHJlYXQgbW9yZSBhYm91dCAmcXVvdDtob3cgZGV2ZWxvcG1lbnQgY29tbXVuaXR5IHNl
ZXMgbmV0d29yayBvcGVyYXRpb25zJnF1b3Q7IHJhdGhlciB0aGFuIHByYWN0aWNlICZxdW90O3do
aWNoIG1lY2hhbmlzbXMgZGV2ZWxvcG1lbnQgY29tbXVuaXR5IGhhcyB0byBjb25zaWRlciB0byBt
ZWV0IHVzZXIgY29tbXVuaXR5IG5lZWRzJnF1b3Q7IC4uLiBhIHdheSB0byBhY2hpZXZlIHRoaXMg
aXMgd291bGQgYmUgdG8gJnF1b3Q7aW52aXRlJnF1b3Q7IHRoZSBicm9hZCB1c2VyIGNvbW11bml0
eSB0byBleHByZXNzIHRoZWlyIHZpZXdzIGFuZCBjb25jZXJucyBpbiB0ZXJtcyBvZiBHTVBMUyBk
ZXBsb3ltZW50IHRoaXMgbWF5IHRha2UgdGhlIGZvcm0gb2YgYSBzdXJ2ZXkgPzwvRk9OVD48QlI+
PEJSPjxGT05UIFNJWkU9Mj48Qj4mcXVvdDtUaG9tYXMgRC4gTmFkZWF1JnF1b3Q7ICZsdDt0bmFk
ZWF1QGNpc2NvLmNvbSZndDs8L0I+PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+U2VudCBieTogb3du
ZXItY2NhbXBAb3BzLmlldGYub3JnPC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+MDcvMTgvMjAwNSAw
OTowNiBBU1Q8L0ZPTlQ+PEJSPjxCUj4gPEZPTlQgU0laRT0yPlRvOjwvRk9OVD4gPEZPTlQgU0la
RT0yPkRpbWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUw8L0ZPTlQ+PEJSPiA8
Rk9OVCBTSVpFPTI+Y2M6PC9GT05UPiA8Rk9OVCBTSVpFPTI+JnF1b3Q7QWRyaWFuIEZhcnJlbCZx
dW90OyAmbHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDssICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcm
Z3Q7LCAmbHQ7emluaW5AcHNnLmNvbSZndDssICZxdW90O0JpbGwgRmVubmVyJnF1b3Q7ICZsdDtm
ZW5uZXJAcmVzZWFyY2guYXR0LmNvbSZndDs8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+YmNjOjwv
Rk9OVD4gPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZPTlQgU0laRT0yPlJlOiBu
byBtb3JlIG1pbGVzdG9uZXM/PC9GT05UPjxCUj4gPEJSPjxCUj48L1A+PFA+PEZPTlQgRkFDRT0i
TW9ub3NwYWNlLENvdXJpZXIiPk9uIEp1bCAxOCwgMjAwNSwgYXQgOTowMCBBTSwgRGltaXRyaS5Q
YXBhZGltaXRyaW91QGFsY2F0ZWwuYmUgd3JvdGU6PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0i
TW9ub3NwYWNlLENvdXJpZXIiPiZndDs8QlI+Jmd0OyBoaSBhZHJpYW48QlI+Jmd0OzxCUj4mZ3Q7
PEJSPiZndDsmZ3Q7IEkgd291bGQgbGlrZSB0byBzZWU6PEJSPiZndDsmZ3Q7IC0gYSByZWZpbmVt
ZW50IG9mIHRoZSBjaGFydGVyIHRvIGZvY3VzIHRoZSBuZXh0IHdvcmsgaXRlbXM8QlI+Jmd0OyZn
dDsgLSBhIHllYXIncyB3b3J0aCBvZiBtaWxlc3RvbmVzIHRvIGVuc3VyZSB3ZSBzdGF5IGZvY3Vz
ZWQuPEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IE9uIHRoZSBvdGhlciBoYW5kLCB3ZSBzaG91bGQg
YWltIHRvIGNsb3NlIGRvd24gQ0NBTVAgYW5kIG1vdmUgdGhlPEJSPiZndDsmZ3Q7IHdvcmsgdG88
QlI+Jmd0OyZndDsgb3RoZXIgb3IgbmV3IHdvcmtpbmcgZ3JvdXBzLjxCUj4mZ3Q7Jmd0OzxCUj4m
Z3Q7PEJSPiZndDsgY291cGxpbmcgYm90aCBzZW50ZW5jZXMgZG9lcyBpdCBtZWFuIGluIHlvdXIg
dmlldzxCUj4mZ3Q7PEJSPiZndDsgMSkgZGVmaW5lIHNldmVyYWwgc2hvcnQtdGVybSBtaWxlc3Rv
bmVzIGZvciByZWZpbmluZyB0b3BpY3MgdGhhdDxCUj4mZ3Q7IGhhdmUgYmVlbjxCUj4mZ3Q7IGFs
cmVhZHkgaW5pdGlhdGVkIGFuZCByZXF1aXJlcyBmdXJ0aGVyIHdlbGwgc2NvcGVkIGF0dGVudGlv
bjxCUj4mZ3Q7PEJSPiZndDsgMikgKGJyYW5kKSBuZXcgdG9waWNzIHNob3VsZCB0YXJnZXQgbmV3
IHdvcmtpbmcgZ3JvdXBzIC0gYXMgYWxyZWFkeTxCUj4mZ3Q7IGluaXRpYXRlZCB3aXRoIEwxVlBO
IGZvciBpbnN0LiAtIG9yIGV4aXN0aW5nIHdvcmtpbmcgZ3JvdXBzPEJSPiZndDs8QlI+Jmd0OyBu
ZXZlcnRoZWxlc3MsIGkgZG8gbm90IHNlZSB3aHkgdGhpcyBhdXRvbWF0aWNhbGx5IG1lYW5zIEND
QU1QIGNhbiBub3Q8QlI+Jmd0OyByZW1haW4gdGhlIGZvY2FsIHBvaW50IGNvbmNlcm5pbmcgKmJh
c2UqIEdNUExTIHNpZ25hbGluZyBhbmQgcm91dGluZzxCUj4mZ3Q7IHByb3RvY29sczxCUj48L0ZP
TlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5JIGFncmVlLiBUaGVyZSBhcmUg
Zm9yIGluc3RhbmNlLCBvcHMvbWFuYWdlbWVudC1yZWxhdGVkIGl0ZW1zPEJSPmZvciAmcXVvdDti
YXNlJnF1b3Q7IENDQU1QIGl0ZW1zIHRoYXQgbmVlZCB0byBiZSB3b3JrZWQgb24uICZuYnNwO1Ro
ZSBxdWVzdGlvbjxCUj5mb3IgbWUgaXMgd2h5IGNhbid0IHdlIGNvbnRpbnVlIHRvIHdvcmsgb24g
dGhlc2U/ICZuYnNwO0kgdGhvdWdodDxCUj50aGVzZSB0aGluZ3Mgd2VyZSBhdXRvbWF0aWMgY2hh
cnRlcmVkIGl0ZW1zLCBhbmQgdGh1cyBzaG91bGQ8QlI+YmUgb25nb2luZyB3b3JrIGl0ZW1zLjxC
Uj48L0ZPTlQ+PC9QPjxVTD48VUw+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0tVG9t
PEJSPjwvRk9OVD48QlI+PC9VTD48L1VMPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy
Ij4mZ3Q7PEJSPiZndDsgdGhhbmtzLDxCUj4mZ3Q7IC0gZGltaXRyaS48QlI+Jmd0OzwvRk9OVD48
L1A+



Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 19:20:35 +0000
Date: Mon, 18 Jul 2005 12:20:01 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: Igor Bryskin <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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: [e-mail]
>   To: Igor Bryskin
>   Cc: [e-mail] ; [e-mail] ; [e-mail]
>   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" <[e-mail]>
>   Sent by: [e-mail]
>   07/17/2005 13:18 AST
>
>   To: <[e-mail]>, <[e-mail]>
>   cc: <[e-mail]>
>   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: <[e-mail]>
>   To: <[e-mail]>
>   Cc: <[e-mail]>
>   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
>   > [e-mail] 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:
>   > [e-mail].
>   > 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.
>   >
>
>



Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 18:57:41 +0000
Date: Mon, 18 Jul 2005 11:57:25 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: [e-mail]
cc: Igor Bryskin <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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: <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> 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
> > [e-mail] 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:
> > [e-mail].
> > 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.
> >
>
>
>



Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 18:54:44 +0000
Date: Mon, 18 Jul 2005 11:51:57 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: Igor Bryskin <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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: <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> 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
> > [e-mail] 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:
> > [e-mail].
> > 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.
> >
>



Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 13:39:19 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: no more milestones?
Date: Mon, 18 Jul 2005 14:38:24 +0100
Message-ID: <[e-mail]>
Thread-Topic: no more milestones?
Thread-Index: AcWLmZCTngIVoU7eRLuFwIKw0PlWPgAAK92A
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>

Thomas D. Nadeau Sent: 18 July 2005 14:06
> On Jul 18, 2005, at 9:00 AM, [e-mail] 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



Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 13:06:36 +0000
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
Content-Transfer-Encoding: 7bit
From: "Thomas D. Nadeau" <[e-mail]>
Subject: Re: no more milestones?
Date: Mon, 18 Jul 2005 09:06:07 -0400
To: [e-mail]

On Jul 18, 2005, at 9:00 AM, [e-mail] 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.
>



Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 13:01:35 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, "Thomas D. Nadeau" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
From: [e-mail]
Subject: Re: no more milestones?
MIME-Version: 1.0
Date: Mon, 18 Jul 2005 15:00:51 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

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.





Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 12:07:55 +0000
Message-ID: <0c5101c58b91$a8869c00$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "Thomas D. Nadeau" <[e-mail]>
Cc: <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Re: no more milestones?
Date: Mon, 18 Jul 2005 13:07:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
To: <[e-mail]>
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




Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 12:07:48 +0000
Message-ID: <007b01c58b91$1b931530$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Date: Mon, 18 Jul 2005 08:06:19 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01C58B6F.94415EF0"

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: [e-mail]=20
  To: Igor Bryskin=20
  Cc: [e-mail] ; [e-mail] ; =
[e-mail]=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" <[e-mail]>
  Sent by: [e-mail]
  07/17/2005 13:18 AST

  To: <[e-mail]>, <[e-mail]>
  cc: <[e-mail]>
  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: <[e-mail]>
  To: <[e-mail]>
  Cc: <[e-mail]>
  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
  > [e-mail] 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:
  > [e-mail].
  > 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=[e-mail]=20
  =
href=3D"mailto:[e-mail]">Dimitri.Papadimitriou@al=
catel.be</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">Igor Bryskin</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> ; <A=20
  title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> =
; <A=20
  title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</A>&gt;</B></FONT><=
BR><FONT=20
  size=3D2>Sent by: <A=20
  =
href=3D"mailto:[e-mail]">[e-mail]</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:[e-mail]">[e-mail]</A>&gt;, =
&lt;<A=20
  =
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;=
</FONT><BR><FONT=20
  size=3D2>cc:</FONT> <FONT size=3D2>&lt;<A=20
  =
href=3D"mailto:[e-mail]">[e-mail]</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;[e-mail]&gt;<BR>To: =
&lt;[e-mail]&gt;<BR>Cc:=20
  &lt;[e-mail]&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
  [e-mail] 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; [e-mail].<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--




Envelope-to: [e-mail]
Delivery-date: Mon, 18 Jul 2005 08:15:14 +0000
Date: Mon, 18 Jul 2005 09:11:56 +0000
To: "Ccamp" <[e-mail]>
From: "Kireeti" <[e-mail]>
Subject: Re:
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------xsxuvegyuekptxkkwapv"

----------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--




Envelope-to: [e-mail]
Delivery-date: Sun, 17 Jul 2005 20:37:52 +0000
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt
Date: Sun, 17 Jul 2005 22:36:06 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmlnb3IgLSBzZWUgaW4tbGluZTwvRk9O
VD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmJlc2lkZSB0aGlzIGkgd2Vs
Y29tZSB0aGUgc2VyaW91cyByZS13cml0aW5nIGVmZm9ydCBwcm92aWRlZCBieSB0aGUgYXV0aG9y
cyBjb21wYXJlZCB0byB0aGUgcHJldmlvdXMgdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50PC9GT05U
PjxCUj48QlI+PEZPTlQgU0laRT0yPjxCPiZxdW90O0lnb3IgQnJ5c2tpbiZxdW90OyAmbHQ7aWJy
eXNraW5AbW92YXouY29tJmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj5TZW50IGJ5OiBv
d25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj4wNy8xNy8yMDA1
IDEzOjE4IEFTVDwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBT
SVpFPTI+Jmx0O2ktZC1hbm5vdW5jZUBpZXRmLm9yZyZndDssICZsdDtJbnRlcm5ldC1EcmFmdHNA
aWV0Zi5vcmcmZ3Q7PC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmNjOjwvRk9OVD4gPEZPTlQgU0la
RT0yPiZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmJj
Yzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1YmplY3Q6PC9GT05UPiA8Rk9OVCBTSVpFPTI+
UmU6IEktRCBBQ1RJT046ZHJhZnQtaWV0Zi1jY2FtcC1sc3Atc3RpdGNoaW5nLTAxLnR4dDwvRk9O
VD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5BcnRo
aSAmYW1wOyZhbXA7IEpQLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy
aWVyIj5JIGhhdmUgYSBjb3VwbGUgb2YgcXVlc3Rpb25zLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZB
Q0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4xLiBXaHkgYXJlIHNheWluZyB0aGF0IExTUCBTdGl0Y2hp
bmcgaXMgYSBwcml2YXRlIGNhc2Ugb2YgTFNQIEhpZXJhcmNoeT8gPC9GT05UPjwvUD48UD48Rk9O
VCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+W2RwXSBwdXJwb3NlIGlzIGltaG8gb24gdGhlIGNv
bnRyb2wgcGxhbmUgbWVjaGFuaXNtIGFuZCBmcm9tIHRoaXMgcGVyc3BlY3RpdmUgb25seSBwb2lu
dCA0KSByZW1haW5zIC0gdGhlIGVmZmVjdCBvZiBoYXZpbmcgYSAmcXVvdDtsb2dpY2FsJnF1b3Q7
IFRFIGxpbmsgLTwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPklN
TyB0aGVyZSBpcyBtb3JlIGRpZmZlcmVuY2VzIHRoYW4gc2ltaWxhcml0aWVzOjxCUj5UaGUgZGlm
ZmVyZW5jZXMgYXJlOjxCUj4xKSBJbiBjYXNlIG9mIEgtTFNQIHRoZXJlIGlzIGEgZGF0YSBwbGFu
ZSBhZGphY2VuY3ksIHdoaWxlIGluIGNhc2Ugb2YgUy1MU1A8QlI+dGhlcmUgaXMgbm9uZSAoYXMg
eW91IGNvcnJlY3RseSBwb2ludGVkIG91dCk7PEJSPjIpIEluIGNhc2Ugb2YgSC1MU1AgdGhlcmUg
aXMgYW4gYWRhcHRhdGlvbiBpbiBkYXRhIHBsYW5lIChsYWJlbCBwdXNoL3BvcCBmb3I8QlI+UFND
KSwgd2hpbGUgaW4gY2FzZSBvZiBTLUxTUCB0aGVyZSBpcyBub25lIC0ganVzdCBzaW1wbGUgY3Jv
c3MtY29ubmVjdGluZzxCUj4oIGxhYmVsIHN3YXApIGFzIGluIGNhc2Ugb2YgdHdvICZxdW90O25h
dGl2ZSAmcXVvdDsgZTJlIExTUCBhZGphY2VudCBzZWdtZW50cyA7PEJSPjMpIEgtTFNQIGNvdWxk
IGJlIHVzZWQgYnkgbWFueSBlMmUgTFNQcywgd2hpbGUgUy1MU1AgY291bGQgYmUgdXNlZCBieTxC
Uj5leGFjdGx5IG9uZSBlMmUgTFNQPEJSPjQpIFNpZ25hbGluZyBpcyBkaWZmZXJlbnQgLSB0aGVy
ZSBpcyBubyBsYWJlbCBuZWdvdGlhdGlvbiBpbiBzdGl0Y2hpbmc8QlI+NSkgSC1MU1AgaXMgdXNl
ZCBhcyBhICZxdW90O3RydWUmcXVvdDsgZGF0YSBsaW5rLCBzcGVjaWZpY2FsbHkgdGhlcmUgaXMg
YSByZXNvdXJjZTxCUj5hbGxvY2F0aW9uIG9uIHRoZSBILUxTUCBlZGdlcywgd2hpbGUgaW4gY2Fz
ZSBvZiBTLUxTUCB0aGVyZSBpcyBub25lPEJSPjYpIEZyb20gTUxOIHBvaW50IG9mIHZpZXcsIEgt
TFNQIGlzIGNyZWF0ZWQgaW4gYSBzZXJ2ZXIgKGxvd2VyKSBsYXllciwgd2hpbGU8QlI+dGhlIFMt
TFNQIGlzIGNyZWF0ZWQgaW4gdGhlIGNsaWVudCAoc2FtZSBhcyBlMmUgTFNQKSBsYXllci48QlI+
PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VGhlcmUgYXJlIHR3byBz
aW1pbGFyaXRpZXMgdGhhdCBJIGNhbiB0aGluayBvZjo8QlI+MSkgVGhlcmUgaXMgYSBzaWduYWxp
bmcgYW5kIHBvc3NpYmx5IHJvdXRpbmcgKHNlZSBiZWxvdykgYWRqYWNlbmNpZXMgYmV0d2VlbjxC
Uj50aGUgZW5kczs8QlI+MikgQm90aCBILUxTUCBhbmQgUy1MU1AgY291bGQgYmUgYWR2ZXJ0aXNl
ZCBhcyBzZXBhcmF0ZSBURSBsaW5rcyBvciBhcyBURTxCUj5idW5kbGVzPEJSPjxCUj5JIHdvdWxk
IHJlY29tbWVuZCB0byBkZWRpY2F0ZSBhIHBhcmFncmFwaCBhbmQgZW5saXN0IHRoZXJlIHNpbWls
YXJpdGllcyBhbmQ8QlI+ZGlmZmVyZW5jaWVzPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25v
c3BhY2UsQ291cmllciI+W2RwXSBpIHdvdWxkIHNpbXBseSByZWNvbW1lbmQgdG8gc3RhdGUgd2hh
dCBhbiBMU1Agc2VnbWVudCBpcyAoYXMgc3RhdGVkLCB0aGlzIGNvbXBhcmlzb24gaGFzIGJlZW4g
dXNlZCB0byBzaG93IGRpZmZlcmVuY2VzIGluIHRlcm1zIG9mIGNvbnRyb2wgcGxhbmUgcHJvY2Vz
c2luZyBhbmQga2VlcGluZyBpdCBhdCB0aGF0IGxldmVsIGlzIHNlbnNpYmxlKSBhbmQgbm90IGVt
YmFyayB0aGlzIGRvY3VtZW50IGludG8gdGVybXMgYW5kIGNvbXBsZXggY29tcGFyaXNvbnMgdGhh
dCBhcmUgYXQgdGhlIGVuZCBvZiBubyByZWFsIGhlbHA8QlI+PEJSPjIuIFdoeSBhcmUgeW91IHNh
eWluZyB0aGF0IGEgVEUgTGluayBiYXNlZCBvbiBTLUxTUCBjYW4gYmUgdXNlZCBmb3IgZXhhY3Rs
eTxCUj5vbmUgZTJlIExTUD8gUGFyYWxsZWwgUy1MU1BzIGNvdWxkIGJlIGFkdmVydGlzZWQgYXMg
YSBzaW5nbGUgVEUgbGluazxCUj4oYnVuZGxlLCBzZWUgYWJvdmUpIGFuZCBoZW5jZSBjYW4gYWNj
b21hZGF0ZSBzZXZlcmFsIGUyZSBMU1BzLjwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3Nw
YWNlLENvdXJpZXIiPltkcF0gaSB0aGluayB0aGUgcHVycG9zZSBpcyB0byBzYXkgdGhhdCBhICZx
dW90O3RyaWdnZXJlZCZxdW90OyBMU1Agc2VnbWVudCBjYW4gYmUgdXNlZCBieSBhIHNpbmdsZSBl
bmQtdG8tZW5kIExTUCBjb21wYXJlZCB0byB0aGUgc2l0dWF0aW9uIG9jY3VycmluZyB3aXRoIEZB
LCB3aGVyZSB0aGUgdHJpZ2dlcmVkIEZBLUxTUCBjYW4gdGhlbiBjYXJyeSBtdWx0aXBsZSBuZXN0
ZWQgTFNQczxCUj48QlI+My4gWW91IGFyZSBzYXlpbmcgdGhhdCBTLUxTUCBkb2VzIG5vdCBoYXZl
IGEgcm91dGluZyBwZWVyaW5nLiBBY3R1YWxseSwgaW48QlI+dGhpcyByZXNwZWN0IGl0IGlzIG5v
IGRpZmZlcmVudCBmcm9tIEgtTFNQOiBpZiBpdCBpcyBhZHZlcnRpc2VkIGFzIGEgVEUgbGluazxC
Uj5pbnRvIHRoZSBzYW1lIFRFIGRvbWFpbiAmbmJzcDt0aGF0IHdhcyB1c2VkIGZvciBTLUxTUCBj
cmVhdGlvbiAodW5saWtlbHkgSU1PPEJSPnNjZW5hcmlvKSB0aGFuIGl0IGRvZXMgbm90IHJlcXVp
cmUgdGhlIHJvdXRpbmcgYWRqYWNlbmN5IChpbiBvdGhlciB3b3JkcywgaXQ8QlI+aXMgYW4gRkEg
YWNjb3JkaW5nIHRvIExTUC1ISUVSIGRlZmluaXRpb24pLCBvdGhlcndpc2UsIGl0IElTICZuYnNw
O05PVCBhbmQgRkEgYW5kPEJSPmRvZXMgcmVxdWlyZSB0aGUgZGlyZWN0IHJvdXRpbmcgcGVlcmlu
ZyBpbiB0aGUgZG9tYWluIGl0IGlzIGFkdmVydGlzZWQgdG88QlI+bWFrZSBpdCB1c2VmdWwgYXMg
YSBURSBsaW5rIGluIHRoaXMgZG9tYWluPEJSPjwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9u
b3NwYWNlLENvdXJpZXIiPltkcF0gYWdhaW4gdGhlIGRvY3VtZW50IGNvcnJlY3RseSBzdGF0ZXMg
dGhhdCBhIHJvdXRpbmcgYWRqLiBpcyBub3QgZ29pbmcgdG8gYmUgZXN0YWJsaXNoZWQgb24gdGhl
IExTUCBzZWdtZW50IDwvRk9OVD48L1A+PFA+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3Vy
aWVyIj5DaGVlcnMsPEJSPklnb3I8QlI+PC9GT05UPjxCUj48QlI+PEJSPjxGT05UIEZBQ0U9Ik1v
bm9zcGFjZSxDb3VyaWVyIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPEJSPkZyb206ICZs
dDtJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcmZ3Q7PEJSPlRvOiAmbHQ7aS1kLWFubm91bmNlQGll
dGYub3JnJmd0OzxCUj5DYzogJmx0O2NjYW1wQG9wcy5pZXRmLm9yZyZndDs8QlI+U2VudDogRnJp
ZGF5LCBKdWx5IDE1LCAyMDA1IDM6NTAgUE08QlI+U3ViamVjdDogSS1EIEFDVElPTjpkcmFmdC1p
ZXRmLWNjYW1wLWxzcC1zdGl0Y2hpbmctMDEudHh0PEJSPjwvRk9OVD48QlI+PEJSPjxGT05UIEZB
Q0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls
YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0czxCUj5kaXJlY3Rvcmllcy48QlI+
Jmd0OyBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21tb24gQ29udHJvbCBhbmQg
TWVhc3VyZW1lbnQgUGxhbmU8QlI+V29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48QlI+Jmd0OzxC
Uj4mZ3Q7IFRpdGxlIDogTGFiZWwgU3dpdGNoZWQgUGF0aCBTdGl0Y2hpbmcgd2l0aCBHZW5lcmFs
aXplZCBNUExTIFRyYWZmaWM8QlI+RW5naW5lZXJpbmc8QlI+Jmd0OyBBdXRob3IocykgOiBBLiBB
eXlhbmdhciwgSi4gVmFzc2V1cjxCUj4mZ3Q7IEZpbGVuYW1lIDogZHJhZnQtaWV0Zi1jY2FtcC1s
c3Atc3RpdGNoaW5nLTAxLnR4dDxCUj4mZ3Q7IFBhZ2VzIDogMTk8QlI+Jmd0OyBEYXRlIDogMjAw
NS03LTE1PEJSPiZndDs8QlI+Jmd0OyBJbiBjZXJ0YWluIHNjZW5hcmlvcywgdGhlcmUgbWF5IGJl
IGEgbmVlZCB0byBjb21iaW5lIHRvZ2V0aGVyIHR3bzxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDtkaWZm
ZXJlbnQgR2VuZXJhbGl6ZWQgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChHTVBMUykg
TGFiZWw8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7U3dpdGNoZWQgUGF0aHMgKExTUHMpIHN1Y2ggdGhh
dCBpbiB0aGUgZGF0YSBwbGFuZSwgYSBzaW5nbGUgZW5kLXRvLTxCUj4mZ3Q7ICZuYnNwOyAmbmJz
cDtlbmQgKGUyZSkgTFNQIGlzIGFjaGlldmVkIGFuZCBhbGwgdHJhZmZpYyBmcm9tIG9uZSBMU1Ag
aXMgc3dpdGNoZWQ8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7b250byB0aGUgb3RoZXIgTFNQLiAmbmJz
cDtXZSB3aWxsIHJlZmVyIHRvIHRoaXMgYXMgJnF1b3Q7TFNQIHN0aXRjaGluZyZxdW90Oy4gJm5i
c3A7VGhpczxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDtkb2N1bWVudCBjb3ZlcnMgY2FzZXMgd2hlcmU6
IGEpIHRoZSBub2RlIHBlcmZvcm1pbmcgdGhlIHN0aXRjaGluZzxCUj4mZ3Q7ICZuYnNwOyAmbmJz
cDtkb2VzIG5vdCByZXF1aXJlIGNvbmZpZ3VyYXRpb24gb2YgZXZlcnkgTFNQIHBhaXIgdG8gYmUg
c3RpdGNoZWQ8QlI+Jmd0OyAmbmJzcDsgJm5ic3A7dG9nZXRoZXIgYikgdGhlIG5vZGUgcGVyZm9y
bWluZyB0aGUgc3RpdGNoaW5nIGlzIG5vdCB0aGUgZWdyZXNzIG9mPEJSPiZndDsgJm5ic3A7ICZu
YnNwO2FueSBvZiB0aGUgTFNQcyBjKSBMU1Agc3RpdGNoaW5nIG5vdCBvbmx5IHJlc3VsdHMgaW4g
YW4gZW5kLXRvLWVuZDxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDtMU1AgaW4gdGhlIGRhdGEgcGxhbmUs
IGJ1dCB0aGVyZSBpcyBhbHNvIGEgY29ycmVzcG9uZGluZyBlbmQtdG8tZW5kPEJSPiZndDsgJm5i
c3A7ICZuYnNwO0xTUCAoUlNWUCBzZXNzaW9uKSBpbiB0aGUgY29udHJvbCBwbGFuZS4gJm5ic3A7
SXQgbWlnaHQgYmUgcG9zc2libGUgdG88QlI+Jmd0OyAmbmJzcDsgJm5ic3A7Y29uZmlndXJlIGEg
R01QTFMgbm9kZSB0byBzd2l0Y2ggdGhlIHRyYWZmaWMgZnJvbSBhbiBMU1AgZm9yIHdoaWNoIGl0
PEJSPiZndDsgJm5ic3A7ICZuYnNwO2lzIHRoZSBlZ3Jlc3MsIHRvIGFub3RoZXIgTFNQIGZvciB3
aGljaCBpdCBpcyB0aGUgaW5ncmVzcywgd2l0aG91dDxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDtyZXF1
aXJpbmcgYW55IHNpZ25hbGluZyBvciByb3V0aW5nIGV4dGVuc2lvbnMgd2hhdHNvZXZlciwgY29t
cGxldGVseTxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDt0cmFuc3BhcmVudCB0byBvdGhlciBub2Rlcy4g
Jm5ic3A7VGhpcyB3aWxsIGFsc28gcmVzdWx0IGluIExTUCBzdGl0Y2hpbmc8QlI+Jmd0OyAmbmJz
cDsgJm5ic3A7aW4gdGhlIGRhdGEgcGxhbmUuICZuYnNwO0hvd2V2ZXIsIHRoaXMgZG9jdW1lbnQg
ZG9lcyBub3QgY292ZXIgdGhpczxCUj4mZ3Q7ICZuYnNwOyAmbmJzcDtzY2VuYXJpbyBvZiBMU1Ag
c3RpdGNoaW5nLjxCUj4mZ3Q7PEJSPiZndDsgQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQg
aXM6PEJSPiZndDsgPEEgSFJFRj1odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k
cmFmdC1pZXRmLWNjYW1wLWxzcC1zdGl0Y2hpbmctMDEudHh0Pmh0dHA6Ly93d3cuaWV0Zi5vcmcv
aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2NhbXAtbHNwLXN0aXRjaGluZy0wMS50eHQ8L0E+
PEJSPiZndDs8QlI+Jmd0OyBUbyByZW1vdmUgeW91cnNlbGYgZnJvbSB0aGUgSS1EIEFubm91bmNl
bWVudCBsaXN0LCBzZW5kIGEgbWVzc2FnZSB0bzxCUj4mZ3Q7IGktZC1hbm5vdW5jZS1yZXF1ZXN0
QGlldGYub3JnIHdpdGggdGhlIHdvcmQgdW5zdWJzY3JpYmUgaW4gdGhlIGJvZHkgb2YgdGhlPEJS
Pm1lc3NhZ2UuPEJSPiZndDsgWW91IGNhbiBhbHNvIHZpc2l0IDxBIEhSRUY9aHR0cHM6Ly93d3cx
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vSS1ELWFubm91bmNlPmh0dHBzOi8vd3d3MS5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL0ktRC1hbm5vdW5jZTwvQT48QlI+Jmd0OyB0byBjaGFuZ2Ug
eW91ciBzdWJzY3JpcHRpb24gc2V0dGluZ3MuPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7IEludGVy
bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUC4gTG9naW4gd2l0
aCB0aGU8QlI+dXNlcm5hbWU8QlI+Jmd0OyAmcXVvdDthbm9ueW1vdXMmcXVvdDsgYW5kIGEgcGFz
c3dvcmQgb2YgeW91ciBlLW1haWwgYWRkcmVzcy4gQWZ0ZXIgbG9nZ2luZyBpbiw8QlI+Jmd0OyB0
eXBlICZxdW90O2NkIGludGVybmV0LWRyYWZ0cyZxdW90OyBhbmQgdGhlbjxCUj4mZ3Q7ICZxdW90
O2dldCBkcmFmdC1pZXRmLWNjYW1wLWxzcC1zdGl0Y2hpbmctMDEudHh0JnF1b3Q7LjxCUj4mZ3Q7
PEJSPiZndDsgQSBsaXN0IG9mIEludGVybmV0LURyYWZ0cyBkaXJlY3RvcmllcyBjYW4gYmUgZm91
bmQgaW48QlI+Jmd0OyA8QSBIUkVGPWh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWw+aHR0
cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbDwvQT48QlI+Jmd0OyBvciA8QSBIUkVGPWZ0cDov
L2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PmZ0cDovL2Z0cC5pZXRmLm9yZy9p
ZXRmLzFzaGFkb3ctc2l0ZXMudHh0PC9BPjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBJbnRlcm5l
dC1EcmFmdHMgY2FuIGFsc28gYmUgb2J0YWluZWQgYnkgZS1tYWlsLjxCUj4mZ3Q7PEJSPiZndDsg
U2VuZCBhIG1lc3NhZ2UgdG86PEJSPiZndDsgbWFpbHNlcnZAaWV0Zi5vcmcuPEJSPiZndDsgSW4g
dGhlIGJvZHkgdHlwZTo8QlI+Jmd0OyAmcXVvdDtGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt
aWV0Zi1jY2FtcC1sc3Atc3RpdGNoaW5nLTAxLnR4dCZxdW90Oy48QlI+Jmd0OzxCUj4mZ3Q7IE5P
VEU6IFRoZSBtYWlsIHNlcnZlciBhdCBpZXRmLm9yZyBjYW4gcmV0dXJuIHRoZSBkb2N1bWVudCBp
bjxCUj4mZ3Q7IE1JTUUtZW5jb2RlZCBmb3JtIGJ5IHVzaW5nIHRoZSAmcXVvdDttcGFjayZxdW90
OyB1dGlsaXR5LiAmbmJzcDtUbyB1c2UgdGhpczxCUj4mZ3Q7IGZlYXR1cmUsIGluc2VydCB0aGUg
Y29tbWFuZCAmcXVvdDtFTkNPRElORyBtaW1lJnF1b3Q7IGJlZm9yZSB0aGUgJnF1b3Q7RklMRSZx
dW90OzxCUj4mZ3Q7IGNvbW1hbmQuICZuYnNwO1RvIGRlY29kZSB0aGUgcmVzcG9uc2UocyksIHlv
dSB3aWxsIG5lZWQgJnF1b3Q7bXVucGFjayZxdW90OyBvcjxCUj4mZ3Q7IGEgTUlNRS1jb21wbGlh
bnQgbWFpbCByZWFkZXIuICZuYnNwO0RpZmZlcmVudCBNSU1FLWNvbXBsaWFudCBtYWlsIHJlYWRl
cnM8QlI+Jmd0OyBleGhpYml0IGRpZmZlcmVudCBiZWhhdmlvciwgZXNwZWNpYWxseSB3aGVuIGRl
YWxpbmcgd2l0aDxCUj4mZ3Q7ICZxdW90O211bHRpcGFydCZxdW90OyBNSU1FIG1lc3NhZ2VzIChp
LmUuIGRvY3VtZW50cyB3aGljaCBoYXZlIGJlZW4gc3BsaXQ8QlI+Jmd0OyB1cCBpbnRvIG11bHRp
cGxlIG1lc3NhZ2VzKSwgc28gY2hlY2sgeW91ciBsb2NhbCBkb2N1bWVudGF0aW9uIG9uPEJSPiZn
dDsgaG93IHRvIG1hbmlwdWxhdGUgdGhlc2UgbWVzc2FnZXMuPEJSPiZndDs8QlI+Jmd0OzxCUj4m
Z3Q7IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQg
bWFpbCByZWFkZXI8QlI+Jmd0OyBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJp
ZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZTxCUj4mZ3Q7IEludGVybmV0LURyYWZ0LjxCUj4m
Z3Q7PEJSPjwvRk9OVD48L1A+



Envelope-to: [e-mail]
Delivery-date: Sun, 17 Jul 2005 17:21:28 +0000
Message-ID: <001301c58af3$8a644400$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Date: Sun, 17 Jul 2005 13:18:24 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
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
> [e-mail] 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:
> [e-mail].
> 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.
>




Envelope-to: [e-mail]
Delivery-date: Fri, 15 Jul 2005 19:51:24 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Envelope-to: [e-mail]
Delivery-date: Fri, 15 Jul 2005 16:22:15 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: End-to-end L2-LSP
Date: Fri, 15 Jul 2005 17:20:56 +0100
Message-ID: <[e-mail]>
Thread-Topic: End-to-end L2-LSP
Thread-Index: AcWII4lsKzFN0JPAQs66qP37pnL8MABM3i8w
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

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



> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of CHO, JAI HYUNG
> Sent: 14 July 2005 04:24
> To: Spencer,R,Richard,XGH5 R; [e-mail]
> 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 :       [phone]
> oversea: [phone]
> fax:         [phone]=20
>=20
>=20
>=20
>=20
> -----?? ???-----=20
> ?? ??: "[e-mail]" <[e-mail]>=20
> ?? ??: 2005-07-14 ?? 1:10:30=20
> ?? ??: "[e-mail]" <[e-mail]>,=20
> "[e-mail]" <[e-mail]>=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-----
> > From: CHO, JAI HYUNG [mailto:[e-mail]]=20
> > Sent: 13 July 2005 15:14=20
> > To: Spencer,R,Richard,XDE73 R; [e-mail]=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
> > -----?? ???-----
> > ?? ??: "[e-mail]" <[e-mail]>=20
> > ?? ??: 2005-07-13 ?? 8:53:13=20
> > ?? ??: "[e-mail]" <[e-mail]>,=20
> > "[e-mail]" <[e-mail]>=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
> > > -----Original Message-----
> > > From: CHO, JAI HYUNG [mailto:[e-mail]]=20
> > > Sent: 12 July 2005 09:21=20
> > > To: Spencer,R,Richard,XDE73 R; [e-mail]=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
> > > > -----Original Message-----
> > > > From: [e-mail]=20
> > [mailto:[e-mail]]On
> > > > Behalf Of CHO, JAI HYUNG
> > > > Sent: 12 July 2005 01:10=20
> > > > To: [e-mail]=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 :       [phone]=20
> > > > oversea: [phone]=20
> > > > fax:         [phone]=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Fri, 15 Jul 2005 14:00:47 +0000
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail], [e-mail]
From: [e-mail]
Subject: Re: Draft agenda for Paris
Date: Fri, 15 Jul 2005 15:58:41 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

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.





Envelope-to: [e-mail]
Delivery-date: Fri, 15 Jul 2005 09:19:19 +0000
To: [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-cspf-constraints-00
Date: Fri, 15 Jul 2005 11:15:42 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmF1dGhvcnMsIGlzIHRoZSBwdXJwb3Nl
IG9mIHRoZSBhYm92ZSBtZW50aW9uZWQgZHJhZnQ6PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJN
b25vc3BhY2UsQ291cmllciI+Jm5ic3A7MS4gcHJlc2NyaXB0aXZlIChldmVuIGlmIGluZm9ybWF0
aW9uYWwpPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jm5ic3A7
Mi4gZGVzY3JpcHRpdmUgZm9yIGd1aWRpbmcgb3BlcmF0aW9ucyAoQkNQKTwvRk9OVD48L1A+PFA+
PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZuYnNwOzMuIGluZm9ybWF0aXZlIChzdXJ2
ZXktbGlrZSk8QlI+PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+
ZnJvbSB3aGF0IGkgcmVhZCwgaXQgaXMgbW9yZSAxIGxpa2UgLSBpcyBteSB1bmRlcnN0YW5kaW5n
IGNvcnJlY3QgPzwvRk9OVD48L1A+



Envelope-to: [e-mail]
Delivery-date: Fri, 15 Jul 2005 00:52:51 +0000
Mime-Version: 1.0 (Apple Message framework v733)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: [e-mail]
From: "Thomas D. Nadeau" <[e-mail]>
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





Envelope-to: [e-mail]
Delivery-date: Thu, 14 Jul 2005 23:52:38 +0000
Message-ID: <[e-mail]>
Date: Fri, 15 Jul 2005 08:52:19 +0900
From: Tomohiro Otani <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: [e-mail]
Subject: GMPLS OSPF-TE MIB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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: [phone]
FAX: [phone]
E-mail: [e-mail]
------------------------------------





Envelope-to: [e-mail]
Delivery-date: Thu, 14 Jul 2005 18:52:13 +0000
Message-ID: <067701c588a5$45c7f1c0$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Draft agenda for Paris
Date: Thu, 14 Jul 2005 19:53:01 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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]




Envelope-to: [e-mail]
Delivery-date: Thu, 14 Jul 2005 08:46:44 +0000
Date: Thu, 14 Jul 2005 09:43:37 +0000
To: "Ccamp" <[e-mail]>
From: "Kireeti" <[e-mail]>
Subject: Re:
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------vmfswhkcqaueuwndugfu"

----------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--




Envelope-to: [e-mail]
Delivery-date: Thu, 14 Jul 2005 03:25:08 +0000
Thread-Topic: End-to-end L2-LSP
thread-index: AcWII4lsKzFN0JPAQs66qP37pnL8MA==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
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
Message-ID: <6b78301c58823$896e5770$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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 :       [phone]
oversea: [phone]
fax:         [phone] 




-----?? ???----- 
?? ??: "[e-mail]" <[e-mail]> 
?? ??: 2005-07-14 ?? 1:10:30 
?? ??: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]> 
??: 
??: 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 

> -----Original Message----- 
> From: CHO, JAI HYUNG [mailto:[e-mail]] 
> Sent: 13 July 2005 15:14 
> To: Spencer,R,Richard,XDE73 R; [e-mail] 
> 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 
>  
> 
> ============================================ 
> 
>  
> 
> -----?? ???----- 
> ?? ??: "[e-mail]" <[e-mail]> 
> ?? ??: 2005-07-13 ?? 8:53:13 
> ?? ??: "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]> 
> ??: 
> ??: 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 
> 
> > -----Original Message----- 
> > From: CHO, JAI HYUNG [mailto:[e-mail]] 
> > Sent: 12 July 2005 09:21 
> > To: Spencer,R,Richard,XDE73 R; [e-mail] 
> > 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 
> > 
> > > -----Original Message----- 
> > > From: [e-mail] 
> [mailto:[e-mail]]On 
> > > Behalf Of CHO, JAI HYUNG 
> > > Sent: 12 July 2005 01:10 
> > > To: [e-mail] 
> > > 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 :       [phone] 
> > > oversea: [phone] 
> > > fax:         [phone] 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 






Envelope-to: [e-mail]
Delivery-date: Wed, 13 Jul 2005 16:11:35 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: End-to-end L2-LSP
Date: Wed, 13 Jul 2005 17:10:30 +0100
Message-ID: <[e-mail]>
Thread-Topic: End-to-end L2-LSP
Thread-Index: AcWHtSqnmWn31nu6RQGbw8KrVOPrAAAApXPg
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>

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

> -----Original Message-----
> From: CHO, JAI HYUNG [mailto:[e-mail]]
> Sent: 13 July 2005 15:14
> To: Spencer,R,Richard,XDE73 R; [e-mail]
> 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
> ?? ??: "[e-mail]" <[e-mail]>=20
> ?? ??: 2005-07-13 ?? 8:53:13=20
> ?? ??: "[e-mail]" <[e-mail]>,=20
> "[e-mail]" <[e-mail]>=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:[e-mail]]=20
> > Sent: 12 July 2005 09:21=20
> > To: Spencer,R,Richard,XDE73 R; [e-mail]=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: [e-mail]=20
> [mailto:[e-mail]]On=20
> > > Behalf Of CHO, JAI HYUNG=20
> > > Sent: 12 July 2005 01:10=20
> > > To: [e-mail]=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 :       [phone]=20
> > > oversea: [phone]=20
> > > fax:         [phone]=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Wed, 13 Jul 2005 14:14:55 +0000
Thread-Topic: End-to-end L2-LSP
thread-index: AcWHtSqnmWn31nu6RQGbw8KrVOPrAA==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
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
Message-ID: <66fc801c587b5$2aac6a60$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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
 

============================================ 

 

-----?? ???----- 
?? ??: "[e-mail]" <[e-mail]> 
?? ??: 2005-07-13 ?? 8:53:13 
?? ??: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]> 
??: 
??: 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 

> -----Original Message----- 
> From: CHO, JAI HYUNG [mailto:[e-mail]] 
> Sent: 12 July 2005 09:21 
> To: Spencer,R,Richard,XDE73 R; [e-mail] 
> 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 
> 
> > -----Original Message----- 
> > From: [e-mail] [mailto:[e-mail]]On 
> > Behalf Of CHO, JAI HYUNG 
> > Sent: 12 July 2005 01:10 
> > To: [e-mail] 
> > 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 :       [phone] 
> > oversea: [phone] 
> > fax:         [phone] 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 






Envelope-to: [e-mail]
Delivery-date: Wed, 13 Jul 2005 11:54:55 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: End-to-end L2-LSP
Date: Wed, 13 Jul 2005 12:53:13 +0100
Message-ID: <[e-mail]>
Thread-Topic: End-to-end L2-LSP
Thread-Index: AcWGupx0aJ5M4xC7Qua/KqFHq7pK5gA5Uvlg
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>

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

> -----Original Message-----
> From: CHO, JAI HYUNG [mailto:[e-mail]]
> Sent: 12 July 2005 09:21
> To: Spencer,R,Richard,XDE73 R; [e-mail]
> 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: [e-mail] [mailto:[e-mail]]On=20
> > Behalf Of CHO, JAI HYUNG=20
> > Sent: 12 July 2005 01:10=20
> > To: [e-mail]=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 :       [phone]=20
> > oversea: [phone]=20
> > fax:         [phone]=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Wed, 13 Jul 2005 09:18:39 +0000
Date: Wed, 13 Jul 2005 10:15:39 +0000
To: "Ccamp" <[e-mail]>
From: "Kireeti" <[e-mail]>
Subject: Re:
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------muscriekmblqemuwjvvd"

----------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--




Envelope-to: [e-mail]
Delivery-date: Tue, 12 Jul 2005 11:39:07 +0000
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt
Date: Tue, 12 Jul 2005 13:37:22 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

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 !





Envelope-to: [e-mail]
Delivery-date: Tue, 12 Jul 2005 08:20:23 +0000
Thread-Topic: End-to-end L2-LSP
thread-index: AcWGupx0aJ5M4xC7Qua/KqFHq7pK5g==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
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
Message-ID: <59e7801c586ba$9c768820$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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 

> -----Original Message----- 
> From: [e-mail] [mailto:[e-mail]]On 
> Behalf Of CHO, JAI HYUNG 
> Sent: 12 July 2005 01:10 
> To: [e-mail] 
> 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 :       [phone] 
> oversea: [phone] 
> fax:         [phone] 
> 
> 
> 
> 
> 
> 
> 






Envelope-to: [e-mail]
Delivery-date: Tue, 12 Jul 2005 07:11:21 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: End-to-end L2-LSP
Date: Tue, 12 Jul 2005 08:09:49 +0100
Message-ID: <[e-mail]>
Thread-Topic: End-to-end L2-LSP
Thread-Index: AcWGdfoCa9xYocg7QG24RMC4LxgzWgAN3Lyw
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of CHO, JAI HYUNG
> Sent: 12 July 2005 01:10
> To: [e-mail]
> 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 :       [phone]
> oversea: [phone]
> fax:         [phone]=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20



Envelope-to: [e-mail]
Delivery-date: Tue, 12 Jul 2005 00:11:08 +0000
Thread-Topic: End-to-end L2-LSP
thread-index: AcWGdfoCa9xYocg7QG24RMC4LxgzWg==
Reply-To: "CHO, JAI HYUNG" <[e-mail]>
From: "CHO, JAI HYUNG" <[e-mail]>
To: <[e-mail]>
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
Message-ID: <5262301c58675$fa047960$8310fe81@email1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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 :       [phone]
oversea: [phone]
fax:         [phone] 








Envelope-to: [e-mail]
Delivery-date: Mon, 11 Jul 2005 22:36:52 +0000
Message-ID: <004201c58669$3d073de0$d6849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Provisional scheduling for Paris
Date: Mon, 11 Jul 2005 23:30:19 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

CCAMP has been *provisionally* scheduled for Wednesday at 2pm

We cannot guarantee that this slot will be held.

Cheers,
Adrian



Envelope-to: [e-mail]
Delivery-date: Mon, 11 Jul 2005 21:22:37 +0000
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt
Date: Mon, 11 Jul 2005 23:21:28 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

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: [e-mail]
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
[e-mail] 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:
      [e-mail].
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce






Envelope-to: [e-mail]
Delivery-date: Mon, 11 Jul 2005 16:44:17 +0000
Message-ID: <071701c58637$d390c290$db849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, "Scott Bradner" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "Hiroshi Ohta" <[e-mail]>
Subject: Response to your liaison on the SG15 OTNT Standardization Work Plan
Date: Mon, 11 Jul 2005 17:27:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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




Envelope-to: [e-mail]
Delivery-date: Thu, 07 Jul 2005 19:51:36 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-04.txt 
Message-Id: <[e-mail]>
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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--



Envelope-to: [e-mail]
Delivery-date: Thu, 07 Jul 2005 06:07:48 +0000
Message-ID: <01d201c582b9$83531cf0$86600337@AOFR06585>
From: "Fabien Verhaeghe" <[e-mail]>
To: <[e-mail]>
Subject: LMP TestStatusSuccess local_link_Id field
Date: Thu, 7 Jul 2005 08:02:52 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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






Envelope-to: [e-mail]
Delivery-date: Wed, 06 Jul 2005 22:01:41 +0000
Message-ID: <046901c58275$a62208c0$db849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Inter-domain Framework Last Call ended
Date: Wed, 6 Jul 2005 22:48:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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