RE: Draft status updated on alternate CCAMP web page

["Yumiko Kawashima" <[e-mail]>]

Hello Adrian,

I agree with Richard and Lyndon.
I hope that this BCP draft will be discussed in Minneapolis and will be
conductive to solve the interoperability issues.

Best Regards,
Yumiko

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Ong, Lyndon
Sent: Sunday, February 27, 2005 3:08 AM
To: Richard Rabbat; Adrian Farrel; [e-mail]
Subject: RE: Draft status updated on alternate CCAMP web page

Hi Adrian,

Just to support Richard on this, there are quite a few people
that have been involved in this draft and are very interested
in its progress, as it represents results from a lot of
interoperability testing of the GMPLS specifications.

Cheers,

Lyndon

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Richard Rabbat
Sent: Thursday, February 24, 2005 10:52 AM
To: 'Adrian Farrel'; [e-mail]
Subject: RE: Draft status updated on alternate CCAMP web page


Adrian,
Can you add
http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-addressing-00
.txt
to your draft tracker?

We sent out email about it and have received feedback off-list. We're
planning on discussing this draft in Minneapolis and would love to have more
on-list discussions. As you can see from the list of contributors, there is
enormous interest in this draft and we hope it serves as a basis for
thoughtful discussions.
Best,
Richard, Rajiv and Kohei.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Monday, February 21, 2005 10:35 AM
> To: Adrian Farrel; [e-mail]
> Subject: Re: Draft status updated on alternate CCAMP web page
> 
> 
> So, I can't type.
> Want to make something of it?
> http://www.olddog.co.uk/ccamp-drafts.htm
> 
> (Thanks Jean-Louis)
> 
> Adrian
> 
> ----- Original Message ----- 
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, February 21, 2005 12:32 PM
> Subject: Draft status updated on alternate CCAMP web page
> 
> 
> > I have updated http://www.oldog.co.uk/ccamp-drafts.htm to 
> indicate the
> > current status of all CCAMP drafts. I have yet to update the section
> that
> > covers personal drafts related to CCAMP.
> >
> > Adrian
> >
> >
> >
> >
> 
> 
> 








Envelope-to: [e-mail]
Delivery-date: Mon, 28 Feb 2005 11:34:45 +0000
Message-Id: <[e-mail]>
From: "Yumiko Kawashima" <[e-mail]>
To: <[e-mail]>
Subject: RE: Draft status updated on alternate CCAMP web page
Date: Mon, 28 Feb 2005 20:32:23 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcUao0RWyex9+4BqSGOPchJWB+xp3QBipo4QAFXZTQA=

Hello Adrian,

I agree with Richard and Lyndon.
I hope that this BCP draft will be discussed in Minneapolis and will be
conductive to solve the interoperability issues.

Best Regards,
Yumiko

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Ong, Lyndon
Sent: Sunday, February 27, 2005 3:08 AM
To: Richard Rabbat; Adrian Farrel; [e-mail]
Subject: RE: Draft status updated on alternate CCAMP web page

Hi Adrian,

Just to support Richard on this, there are quite a few people
that have been involved in this draft and are very interested
in its progress, as it represents results from a lot of
interoperability testing of the GMPLS specifications.

Cheers,

Lyndon

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Richard Rabbat
Sent: Thursday, February 24, 2005 10:52 AM
To: 'Adrian Farrel'; [e-mail]
Subject: RE: Draft status updated on alternate CCAMP web page


Adrian,
Can you add
http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-addressing-00
.txt
to your draft tracker?

We sent out email about it and have received feedback off-list. We're
planning on discussing this draft in Minneapolis and would love to have more
on-list discussions. As you can see from the list of contributors, there is
enormous interest in this draft and we hope it serves as a basis for
thoughtful discussions.
Best,
Richard, Rajiv and Kohei.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Monday, February 21, 2005 10:35 AM
> To: Adrian Farrel; [e-mail]
> Subject: Re: Draft status updated on alternate CCAMP web page
> 
> 
> So, I can't type.
> Want to make something of it?
> http://www.olddog.co.uk/ccamp-drafts.htm
> 
> (Thanks Jean-Louis)
> 
> Adrian
> 
> ----- Original Message ----- 
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, February 21, 2005 12:32 PM
> Subject: Draft status updated on alternate CCAMP web page
> 
> 
> > I have updated http://www.oldog.co.uk/ccamp-drafts.htm to 
> indicate the
> > current status of all CCAMP drafts. I have yet to update the section
> that
> > covers personal drafts related to CCAMP.
> >
> > Adrian
> >
> >
> >
> >
> 
> 
> 







Envelope-to: [e-mail]
Delivery-date: Mon, 28 Feb 2005 00:06:49 +0000
Date: Sun, 27 Feb 2005 16:04:03 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Tomonori TAKEDA <[e-mail]>
cc: Igor Bryskin <[e-mail]>, [e-mail], [e-mail]
Subject: Re: What is happenning to CCAMP WG recharter ?
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 23 Feb 2005, Tomonori TAKEDA wrote:

> The same question arises to me. I thought we had good amount of discussion
> about new charter items. Is there any open issue?

It's on the ADs' plate.

Alex?  Bill?

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Sat, 26 Feb 2005 18:09:10 +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: Draft status updated on alternate CCAMP web page
Date: Sat, 26 Feb 2005 13:07:38 -0500
Message-ID: <[e-mail]>
Thread-Topic: Draft status updated on alternate CCAMP web page
Thread-Index: AcUao0RWyex9+4BqSGOPchJWB+xp3QBipo4Q
From: "Ong, Lyndon" <[e-mail]>
To: "Richard Rabbat" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>

Hi Adrian,

Just to support Richard on this, there are quite a few people
that have been involved in this draft and are very interested
in its progress, as it represents results from a lot of
interoperability testing of the GMPLS specifications.

Cheers,

Lyndon

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Richard Rabbat
Sent: Thursday, February 24, 2005 10:52 AM
To: 'Adrian Farrel'; [e-mail]
Subject: RE: Draft status updated on alternate CCAMP web page


Adrian,
Can you add
http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-addressing=
-00
.txt
to your draft tracker?

We sent out email about it and have received feedback off-list. We're
planning on discussing this draft in Minneapolis and would love to have =
more
on-list discussions. As you can see from the list of contributors, there =
is
enormous interest in this draft and we hope it serves as a basis for
thoughtful discussions.
Best,
Richard, Rajiv and Kohei.

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Monday, February 21, 2005 10:35 AM
> To: Adrian Farrel; [e-mail]
> Subject: Re: Draft status updated on alternate CCAMP web page
>=20
>=20
> So, I can't type.
> Want to make something of it?
> http://www.olddog.co.uk/ccamp-drafts.htm
>=20
> (Thanks Jean-Louis)
>=20
> Adrian
>=20
> ----- Original Message -----=20
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, February 21, 2005 12:32 PM
> Subject: Draft status updated on alternate CCAMP web page
>=20
>=20
> > I have updated http://www.oldog.co.uk/ccamp-drafts.htm to=20
> indicate the
> > current status of all CCAMP drafts. I have yet to update the section
> that
> > covers personal drafts related to CCAMP.
> >
> > Adrian
> >
> >
> >
> >
>=20
>=20
>=20





Envelope-to: [e-mail]
Delivery-date: Sat, 26 Feb 2005 14:00:38 +0000
Message-ID: <121101c51c0a$b6b5ddf0$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>
Subject: GMPLS/ASON Lexicography
Date: Sat, 26 Feb 2005 13:54:28 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

A new version of draft-bryskin-ccamp-gmpls-ason-lexicography was submitted
in the middle of this month but has gone AWOL. Hopefully the Secretariat
will dig it up and publish it soon.

In the mean time, and in order that you can get a chance to review it,
please see http://www.olddog.co.uk/missing.htm

Comments on the list or at the meeting.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 26 Feb 2005 08:59:44 +0000
Message-Id: <[e-mail]>
Date: Sat, 26 Feb 2005 17:58:15 +0900
To: [e-mail], [e-mail]
From: Tomonori TAKEDA <[e-mail]>
Subject: Updates of L1VPN IDs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

FYI -

We have updated two IDs related to L1VPNs.

o L1VPN framework ID
http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-03.txt
- Changes
    - Clarification on business cases/deployment scenarios (section 4.3)
    - Clarification on differences between L1VPNs and L2/L3 VPNs (section 3.1.2)
    - Edits
- Status and next steps
    - We think the draft is almost complete. If there is any comment, 
please let us know.

o L1VPN applicability analysis ID
http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-02.txt
- Changes
    - Signaling mechanisms (nesting/stitching and shuffling) (sections 6.2 and 6.3)
    - Edits
- Status and next steps
    - We think the draft is getting stable now. New revisions are expected 
as the work on protocols progresses.

I would appreciate your comments and feedbacks.

Best regards,

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: [phone]




Envelope-to: [e-mail]
Delivery-date: Sat, 26 Feb 2005 07:27:49 +0000
Date: Sat, 26 Feb 2005 16:24:57 +0900
From: Kenji Kumaki <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Subject: Re: Draft status updated on alternate CCAMP web page
Cc: <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Adrian and all,

I didn't find the following draft at your web.
http://www.ietf.org/internet-drafts/draft-kumaki-ccamp-mpls-gmpls-interworking-00.txt

Could you add this I-D?

Thanks,
Kenji

On Mon, 21 Feb 2005 12:32:04 -0000
"Adrian Farrel" <[e-mail]> wrote:

> I have updated http://www.oldog.co.uk/ccamp-drafts.htm to indicate the
> current status of all CCAMP drafts. I have yet to update the section that
> covers personal drafts related to CCAMP.
> 
> Adrian
> 

-- 
Kenji Kumaki <[e-mail]>





Envelope-to: [e-mail]
Delivery-date: Fri, 25 Feb 2005 05:41:17 +0000
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail], [e-mail], [e-mail]
Subject: MPLS/GMPLS Change Process
Reply-To: [e-mail]
Date: Thu, 24 Feb 2005 21:39:47 -0800
From: Bill Fenner <[e-mail]>
Versions: dmail (linux) 2.6d/makemail 2.10

We expect to talk about the MPLS/GMPLS Change Process at the
Routing Area meeting in Minneapolis.  The main changes from the
-00 version are the addition of the preliminary process which
doesn't require an I-D and additional mentions of where liaisons
fit in the process.

Let's please discuss this on the routing-discussion list, instead
of trying to use both ccamp and mpls lists.

  Bill


----- Begin forwarded message:

From: [e-mail]
Subject: I-D ACTION:draft-andersson-rtg-gmpls-change-01.txt
Date: Tue, 22 Feb 2005 15:50:01 -0500
To: [e-mail]
Reply-to: [e-mail]


	Title		: MPLS and GMPLS Change Process
	Author(s)	: L. Andersson, et al.
	Filename	: draft-andersson-rtg-gmpls-change-01.txt
	Pages		: 23
	Date		: 2005-2-22
	
The MPLS and GMPLS protocol suites have become quite popular for a
   growing number of applications and deployment scenarios.  One result
   of this popularity is a large number of suggestions for modifications
   and extensions.

   The IETF needs to be flexible and responsive in how it handles these
   suggestions, and has a responsiblity to supervise the growth and
   evolution of MPLS and GMPLS protocols.

   This memo describes the process through which individuals, working
   groups and external standards bodies can influence the development of
   the MPLS and GMPLS standards.  This process means that extensions and
   changes to protocols specified by these working groups can only be
   made through the IETF, the body that created the (G)MPLS
   ((Generalized) Multiprotocol Label Switching) technologies.  When
   possible, existing liaison relationships are used.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls-change-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-andersson-rtg-gmpls-change-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-andersson-rtg-gmpls-change-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.

[Don't know how to fetch mail-server a3]
_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce


----- End forwarded message:



Envelope-to: [e-mail]
Delivery-date: Thu, 24 Feb 2005 18:58:45 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: Draft status updated on alternate CCAMP web page
Date: Thu, 24 Feb 2005 10:51:46 -0800
Message-ID: <003b01c51aa1$e408b580$483ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Adrian,
Can you add
http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-addressing=
-00
.txt
to your draft tracker?

We sent out email about it and have received feedback off-list. We're
planning on discussing this draft in Minneapolis and would love to have =
more
on-list discussions. As you can see from the list of contributors, there =
is
enormous interest in this draft and we hope it serves as a basis for
thoughtful discussions.
Best,
Richard, Rajiv and Kohei.

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Monday, February 21, 2005 10:35 AM
> To: Adrian Farrel; [e-mail]
> Subject: Re: Draft status updated on alternate CCAMP web page
>=20
>=20
> So, I can't type.
> Want to make something of it?
> http://www.olddog.co.uk/ccamp-drafts.htm
>=20
> (Thanks Jean-Louis)
>=20
> Adrian
>=20
> ----- Original Message -----=20
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, February 21, 2005 12:32 PM
> Subject: Draft status updated on alternate CCAMP web page
>=20
>=20
> > I have updated http://www.oldog.co.uk/ccamp-drafts.htm to=20
> indicate the
> > current status of all CCAMP drafts. I have yet to update the section
> that
> > covers personal drafts related to CCAMP.
> >
> > Adrian
> >
> >
> >
> >
>=20
>=20
>=20




Envelope-to: [e-mail]
Delivery-date: Wed, 23 Feb 2005 20:34:33 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-sdhsonet-control-05.txt
Date: Wed, 23 Feb 2005 15:33:13 -0500

--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		: Framework for GMPLS-based Control of SDH/SONET Networks
	Author(s)	: G. Bernstein, et al.
	Filename	: draft-ietf-ccamp-sdhsonet-control-05.txt
	Pages		: 31
	Date		: 2005-2-23
	
Generalized MPLS (GMPLS) is a suite of protocol extensions to MPLS
   (Multi-Protocol Label Switching) to make it generally applicable, to
   include - for example - control of non packet-based switching, and
   particularly, optical switching.  One consideration is to use GMPLS
   protocols to upgrade the control plane of optical transport networks.
   This document illustrates this process by describing those extensions
   to GMPLS protocols that are aimed at controlling Synchronous Digital
   Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks.
   SDH/SONET networks make good examples of this process for a variety
   of reasons.  This document high-lights extensions to GMPLS-related
   routing protocols to disseminate information needed in transport path
   computation and network operations, together with (G)MPLS protocol
   extensions required for the provisioning of transport circuits. New
   capabilities that an GMPLS control plane would bring to SDH/SONET
   networks, such as new restoration methods and multi-layer circuit
   establishment, are also discussed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-05.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-sdhsonet-control-05.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-sdhsonet-control-05.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-sdhsonet-control-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-sdhsonet-control-05.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, 23 Feb 2005 12:28:43 +0000
Message-Id: <[e-mail]>
Date: Wed, 23 Feb 2005 21:27:40 +0900
To: Igor Bryskin <[e-mail]>, [e-mail], [e-mail]
From: Tomonori TAKEDA <[e-mail]>
Subject: Re: What is happenning to CCAMP WG recharter ?
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

The same question arises to me. I thought we had good amount of discussion 
about new charter items. Is there any open issue?

At 11:30 05/02/22 -0800, Igor Bryskin wrote:
>Hi,
>  <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
>I wonder what is happening to the CCAMP WG recharter that was discussed in 
>Washington? I thought we had a good discussion and defined the process and 
>goals reasonably clearly, however, it does look to me that nothing 
>happened so far. Am I missing something?
>
>Thanks,
>Igor
>Do you Yahoo!?
>Yahoo! Search presents - 
><http://us.rd.yahoo.com/evt=30648/*http://movies.yahoo.com/movies/feature/jibjabinaugural.html>Jib 
>Jab's 'Second Term'
>
>
>Do you Yahoo!?
>All your favorites on one personal page $BK
(B<http://my.yahoo.com>Try My Yahoo!

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: [phone]




Envelope-to: [e-mail]
Delivery-date: Wed, 23 Feb 2005 11:18:01 +0000
Message-ID: <0daf01c51999$7d7e3140$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Thomas D. Nadeau" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Drafts ready for WG last call
Date: Wed, 23 Feb 2005 11:11:32 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I am not Kireeti.
Nevertheless, a reminder (polite) is unlikely to do any harm.

Adrian
----- Original Message ----- 
From: "Thomas D. Nadeau" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, February 22, 2005 8:37 PM
Subject: Re: Drafts ready for WG last call


>
> Are we to assume that you will start the WG LC on
> these drafts automatically after the meeting, or do we
> need to set alarms in our diaries to bug you?  *)
>
> --Tom
>
> > Hi,
> >
> > There are a bunch of drafts ready for WG last call.
> > I don't think we should start the call until after we have met in
> > Minneapolis, but since there are quite a few in the list, I though it
> > reasonable to give you a heads-up so you can start to look at them and
> > send your comments to the mailing list.
> >
> > They are (in no particular order):
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib
> > -06.txt
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib
> > -08.txt
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib
> > -07.txt
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-04.txt
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-
> > route-03.txt
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-
> > e2e-signaling-02.txt
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-
> > recovery-01.txt
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-
> > framework-01.txt
> >
> > A couple of these may still be waiting for the Secretariat, but should
> > appear very soon.
> >
> > Cheers,
> > Adrian
> >
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 23 Feb 2005 11:16:47 +0000
Message-ID: <0da701c51999$0fdd76f0$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: lmp linkcorrelation error code
Date: Tue, 22 Feb 2005 20:18:00 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Fab,

Someone else with an implementation may care to comment (since our aim is
interoperable implementations).

Adrian


> But which one 0x01 or 0x02? Both (seems a bit contradictory)?
>
> Section 12.6.3 list the error case but I don't see which one corresponds
to
> a "wrong interface mapping".
> TE Link object and datalink object are negotiable object and interface
Ids
> are inside those objects.
> But I don't think we can considere interface (or TE link) Id as
negotiable?
>
> What do you think?
>
> Thanks
> Fab
>
>
>
> The TE
> > Fab,
> >
> > See section 13.15.
> >
> >        0x01 =Unacceptable non-negotiable LINK_SUMMARY parameters. 0x02
> >        =Renegotiate LINK_SUMMARY parameters.
> >
> > Cheers,
> > Adrian
> > ----- Original Message -----
> > From: <[e-mail]>
> > To: <[e-mail]>
> > Sent: Tuesday, February 22, 2005 7:25 AM
> > Subject: lmp linkcorrelation error code
> >
> >
> >> Hi,
> >>
> >> In draft-ietf-ccamp-lmp-10 section 4 about link corelation states
that
> >> a "LinkSummaryNack message MUST be transmitted, indicating which
> > interface
> >> mapping and/or which properties are not accepted"
> >>
> >> In case of wrong interface mapping which error code should be encoded
> >> in the linkSummaryNack?
> >>
> >> Thanks
> >> Fab
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 23 Feb 2005 01:31:59 +0000
Date: Wed, 23 Feb 2005 09:31:13 +0800
From: harishm 70229 <[e-mail]>
Subject: Re: lmp linkcorrelation error code
To: [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline

0x08 for INVALID_DATA_LINK object and the DATA_LINK object in the Nack message can have correct interface mapping.


----- Original Message -----
From: [e-mail]
Date: Tuesday, February 22, 2005 3:25 pm
Subject: lmp linkcorrelation error code

> Hi,
> 
> In draft-ietf-ccamp-lmp-10 section 4 about link corelation states that
> a "LinkSummaryNack message MUST be transmitted, indicating which 
> interfacemapping and/or which properties are not accepted"
> 
> In case of wrong interface mapping which error code should be 
> encoded in
> the linkSummaryNack?
> 
> Thanks
> Fab
> 
> 
> 
> 
> 




Envelope-to: [e-mail]
Delivery-date: Tue, 22 Feb 2005 20:38:14 +0000
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: <[e-mail]>
From: "Thomas D. Nadeau" <[e-mail]>
Subject: Re: Drafts ready for WG last call
Date: Tue, 22 Feb 2005 15:37:10 -0500
To: "Adrian Farrel" <[e-mail]>

	Are we to assume that you will start the WG LC on
these drafts automatically after the meeting, or do we
need to set alarms in our diaries to bug you?  *)

	--Tom

> Hi,
>
> There are a bunch of drafts ready for WG last call.
> I don't think we should start the call until after we have met in
> Minneapolis, but since there are quite a few in the list, I though it
> reasonable to give you a heads-up so you can start to look at them and
> send your comments to the mailing list.
>
> They are (in no particular order):
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib 
> -06.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib 
> -08.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib 
> -07.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-04.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude- 
> route-03.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery- 
> e2e-signaling-02.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment- 
> recovery-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain- 
> framework-01.txt
>
> A couple of these may still be waiting for the Secretariat, but should
> appear very soon.
>
> Cheers,
> Adrian
>



Envelope-to: [e-mail]
Delivery-date: Tue, 22 Feb 2005 19:33:00 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=b3Y9f7PSXVAwaEfWKvzwTh+GSBO0SIDk4EpkDeeWUCPll2q9PgKsRh4h8Ce6R1GdyuyWefZ+Ukptln4U5biKeZByUTER0M3ySIwLVnThIpRG8SiNYK0UV8V0jXpLG0vFyuUDnC377fMkzKotUoLnr9Ygf0O/QNTsESc/YzsMQ48=  ;
Message-ID: <[e-mail]>
Date: Tue, 22 Feb 2005 11:30:54 -0800 (PST)
From: Igor Bryskin <[e-mail]>
Subject: What is happenning to CCAMP WG recharter ?
To: [e-mail], [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-957558131-1109100654=:355"

--0-957558131-1109100654=:355
Content-Type: text/plain; charset=us-ascii


Hi,

 

I wonder what is happening to the CCAMP WG recharter that was discussed in Washington? I thought we had a good discussion and defined the process and goals reasonably clearly, however, it does look to me that nothing happened so far. Am I missing something?

 

Thanks,

Igor


---------------------------------
Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term'

		
---------------------------------
Do you Yahoo!?
 All your favorites on one personal page – Try My Yahoo!
--0-957558131-1109100654=:355
Content-Type: text/html; charset=us-ascii

<DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman" size=3>Hi,</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT size=3><FONT face="Times New Roman">&nbsp;<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman" size=3>I wonder what is happening to the CCAMP WG recharter that was discussed in Washington? I thought we had a good discussion and defined the process and goals reasonably clearly, however, it does look to me that nothing happened so far. Am I missing something?</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT size=3><FONT face="Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman" size=3>Thanks,</FONT></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT face="Times New Roman" size=3>Igor</FONT></P>
<P>
<HR SIZE=1>
Do you Yahoo!?<BR>Yahoo! Search presents - <A href="http://us.rd.yahoo.com/evt=30648/*http://movies.yahoo.com/movies/feature/jibjabinaugural.html">Jib Jab's 'Second Term'</A></BLOCKQUOTE></DIV><p>
		<hr size=1>Do you Yahoo!?<br> 
All your favorites on one personal page – <a href="http://my.yahoo.com">Try My Yahoo!</a>
--0-957558131-1109100654=:355--



Envelope-to: [e-mail]
Delivery-date: Tue, 22 Feb 2005 09:45:24 +0000
Message-ID: <[e-mail]>
Date: Tue, 22 Feb 2005 10:44:48 +0100 (CET)
Subject: Re: lmp linkcorrelation error code
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Thanks Adrian,

But which one 0x01 or 0x02? Both (seems a bit contradictory)?

Section 12.6.3 list the error case but I don't see which one corresponds to
a "wrong interface mapping".
TE Link object and datalink object are negotiable object and interface Ids
are inside those objects.
But I don't think we can considere interface (or TE link) Id as negotiable?

What do you think?

Thanks
Fab



The TE
> Fab,
>
> See section 13.15.
>
>        0x01 =Unacceptable non-negotiable LINK_SUMMARY parameters. 0x02
>        =Renegotiate LINK_SUMMARY parameters.
>
> Cheers,
> Adrian
> ----- Original Message -----
> From: <[e-mail]>
> To: <[e-mail]>
> Sent: Tuesday, February 22, 2005 7:25 AM
> Subject: lmp linkcorrelation error code
>
>
>> Hi,
>>
>> In draft-ietf-ccamp-lmp-10 section 4 about link corelation states that
>> a "LinkSummaryNack message MUST be transmitted, indicating which
> interface
>> mapping and/or which properties are not accepted"
>>
>> In case of wrong interface mapping which error code should be encoded
>> in the linkSummaryNack?
>>
>> Thanks
>> Fab






Envelope-to: [e-mail]
Delivery-date: Tue, 22 Feb 2005 09:16:05 +0000
Message-ID: <0c4e01c518bf$1b8442c0$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: lmp linkcorrelation error code
Date: Tue, 22 Feb 2005 08:21:11 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Fab,

See section 13.15.

        0x01 =Unacceptable non-negotiable LINK_SUMMARY parameters.
        0x02 =Renegotiate LINK_SUMMARY parameters.

Cheers,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, February 22, 2005 7:25 AM
Subject: lmp linkcorrelation error code


> Hi,
>
> In draft-ietf-ccamp-lmp-10 section 4 about link corelation states that
> a "LinkSummaryNack message MUST be transmitted, indicating which
interface
> mapping and/or which properties are not accepted"
>
> In case of wrong interface mapping which error code should be encoded in
> the linkSummaryNack?
>
> Thanks
> Fab
>
>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 22 Feb 2005 07:27:54 +0000
Message-ID: <[e-mail]>
Date: Tue, 22 Feb 2005 08:25:53 +0100 (CET)
Subject: lmp linkcorrelation error code
From: <[e-mail]>
To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,

In draft-ietf-ccamp-lmp-10 section 4 about link corelation states that
a "LinkSummaryNack message MUST be transmitted, indicating which interface
mapping and/or which properties are not accepted"

In case of wrong interface mapping which error code should be encoded in
the linkSummaryNack?

Thanks
Fab






Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2005 20:28:21 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-07.txt
Date: Mon, 21 Feb 2005 15:28:12 -0500

--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 Multiprotocol Label Switching (GMPLS) 
			  Label Switching Router (LSR) Management Information Base
	Author(s)	: T. Nadeau, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-lsr-mib-07.txt
	Pages		: 40
	Date		: 2005-2-21
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects to configure and/or
monitor a Generalized Multiprotocol Label Switching (GMPLS) Label
Switching Router (LSRs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-07.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-lsr-mib-07.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-lsr-mib-07.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-lsr-mib-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-lsr-mib-07.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: Mon, 21 Feb 2005 20:27:46 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-ason-03.txt
Date: Mon, 21 Feb 2005 15:27:32 -0500

--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-03.txt
	Pages		: 40
	Date		: 2005-2-21
	
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-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-gmpls-rsvp-te-ason-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-gmpls-rsvp-te-ason-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-gmpls-rsvp-te-ason-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-rsvp-te-ason-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: Mon, 21 Feb 2005 20:27:38 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-01.txt
Date: Mon, 21 Feb 2005 15:26:10 -0500

--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-01.txt
	Pages		: 19
	Date		: 2005-2-21
	
This document provides a framework for establishing and controlling
   Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   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-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-framework-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-framework-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-framework-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-framework-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: Mon, 21 Feb 2005 20:27:31 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-crankback-04.txt
Date: Mon, 21 Feb 2005 15:26:53 -0500

--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		: Crankback Signaling Extensions for MPLS and GMPLS Signaling
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-crankback-04.txt
	Pages		: 34
	Date		: 2005-2-21
	
In a distributed, constraint-based routing environment, the
   information used to compute a path may be out of date. This means
   that Multiprotocol Label Switching (MPLS) and Generalized MPLS
   (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
   requests may be blocked by links or nodes without sufficient
   resources. Crankback is a scheme whereby setup failure information is
   returned from the point of failure to allow new setup attempts to be
   made avoiding the blocked resources. Crankback can also be applied to
   LSP restoration to indicate the location of the failed link or node.
   This document specifies crankback signaling extensions for use in
   MPLS signaling using RSVP-TE as defined in 'RSVP-TE: Extensions to
   RSVP for LSP Tunnels', RFC3209, and GMPLS signaling as defined in
   'Generalized Multi-Protocol Label Switching (GMPLS) Signaling
   Functional Description', RFC3473. These extensions mean that the LSP
   setup request can be retried on an alternate path that detours around
   blocked links or nodes. This offers significant improvements in the
   successful setup and recovery ratios for LSPs, especially in
   situations where a large number of setup requests are triggered at
   the same time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-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-crankback-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-crankback-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-crankback-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-crankback-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: Mon, 21 Feb 2005 20:27:22 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-01.txt
Date: Mon, 21 Feb 2005 15:27:03 -0500

--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, R. Rahman
	Filename	: draft-ietf-ccamp-rsvp-restart-ext-01.txt
	Pages		: 20
	Date		: 2005-2-21
	
This document describes extensions to the RSVP Graceful Restart
   mechanisms defined in [RFC3473].  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 [RFC3209], and extensions for
   state recovery on nodal faults defined in [RFC3473].  With the
   presented extensions the restarting node can recover all previously
   transmitted Path state including the ERO 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
   [RFC2961], to reduce the number of messages exchanged during the
   Recovery Phase when the restarting node has recovered signaling state
   locally for one or more LSP's.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-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-rsvp-restart-ext-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-rsvp-restart-ext-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-rsvp-restart-ext-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-rsvp-restart-ext-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: Mon, 21 Feb 2005 20:27:15 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-transport-lmp-01.txt
Date: Mon, 21 Feb 2005 15:26:29 -0500

--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 Transport Network View of LMP
	Author(s)	: D. Fedyk, et al.
	Filename	: draft-ietf-ccamp-transport-lmp-01.txt
	Pages		: 17
	Date		: 2005-2-21
	
The Link Management Protocol (LMP) has been developed as part of the 
   Generalized MPLS (GMPLS) protocol suite to manage Traffic 
   Engineering (TE) resources and links. The GMPLS control plane 
   (routing and signaling) uses TE links for establishing Label 
   Switched Paths (LSPs). This memo describes the relationship of the 
   LMP procedures to 'discovery' as defined in the International 
   Telecommunication Union (ITU-T), and on-going ITU-T work. This 
   document provides an overview of LMP in the context of the ITU-T 
   Automatically Switched Optical Networks (ASON) and transport network 
   terminology and relates it to the ITU-T discovery work to promote a 
   common understanding for progressing the work of IETF and ITU-T.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-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-transport-lmp-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-transport-lmp-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-transport-lmp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-transport-lmp-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: Mon, 21 Feb 2005 18:36:39 +0000
Message-ID: <0ac001c51844$68d242a0$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>, <[e-mail]>
Subject: Re: Draft status updated on alternate CCAMP web page
Date: Mon, 21 Feb 2005 18:34:52 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

So, I can't type.
Want to make something of it?
http://www.olddog.co.uk/ccamp-drafts.htm

(Thanks Jean-Louis)

Adrian

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Monday, February 21, 2005 12:32 PM
Subject: Draft status updated on alternate CCAMP web page


> I have updated http://www.oldog.co.uk/ccamp-drafts.htm to indicate the
> current status of all CCAMP drafts. I have yet to update the section
that
> covers personal drafts related to CCAMP.
>
> Adrian
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2005 18:30:58 +0000
Message-ID: <0aa401c51843$6a63fba0$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Drafts ready for WG last call
Date: Mon, 21 Feb 2005 14:40:46 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

There are a bunch of drafts ready for WG last call.
I don't think we should start the call until after we have met in
Minneapolis, but since there are quite a few in the list, I though it
reasonable to give you a heads-up so you can start to look at them and
send your comments to the mailing list.

They are (in no particular order):

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-08.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-segment-recovery-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-01.txt

A couple of these may still be waiting for the Secretariat, but should
appear very soon.

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2005 16:57:51 +0000
Message-Id: <[e-mail]>
From: "Zafar Ali" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Mon, 21 Feb 2005 11:56:16 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01C5180C.5AE15C40"
Thread-Index: AcUYIRXhqNyS9MmMQtGzwc3QHXgOhQAEVypA

This is a multi-part message in MIME format.

------=_NextPart_000_006F_01C5180C.5AE15C40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Adrian, 
 
This time it's crystal clear on what you were referring to in your comments.
Please see my reply in-line. 
 
Thanks
 
Regards... Zafar


  _____  

From: Adrian Farrel [mailto:[e-mail]] 
Sent: Monday, February 21, 2005 7:19 AM
To: Zafar Ali; [e-mail]
Subject: Re: Summary [was: RE: Starting a discussion on graceful shutdown]


Hi,
 
Thanks for answers. Snipped down to just one point.
 
> > > > Does it matter whether it is the control plane or the data  
> > > > plane that will be taken out of service?
> > >
> > > Yes, if data plane is going OOS, we are loosing traffic and 
> > > motivation behind mb4b to reduce traffic hit is lost.
> > 
> > Let me rephrase the question.
> > If I know that the control plane is going OOS and I want to 
> > continue to be able to manage my LSPs I will want to move 
> > them to LSRs that will continue to have an active control 
> > plane. The data plane through the impacted LSRs may continue 
> > to be active (and therefore could continue to carry traffic).
> 
> I am not sure if I understood your comment completely. However, 
> the ID mentions about Grace Period and Removal of data plane 
> associated with the LSP under mb4b. 
 
I'll try again.
The draft talks about cases where the data plane is going to be removed. No
problem there.
I am asking about cases where we know that the control plane is going to be
removed, but where we know that the data plane is going to stay up.
Examples include:
- going to take the software components down (perhaps for upgrade)
- going to remove the control plane CPU (to replace it, dust it, or fit nerw
tires)
- going to take down the control channel (e.g. decommission the OSC laser) 
 

Yes, most certainly, this is one of the motivations behind this draft. In
fact the -00 version of the ID had following statement in the Introduction
section. 
 
"a Service Provider may desire to gracefully (temporarily or definitely)
remove a TE Link, a group of TE Links or an entire node for administrative
reasons such as link maintenance or LSR software/hardware upgrade. "
 
The revised version of the ID (-01), already in draft queue have this as one
of the main requirements. 
 
"   - Graceful shutdown mechanisms are applicable to removal a TE 
   resource (e.g., link, a group of TE Links or an entire node). Trigger 
   for the graceful shutdown event is a local matter at the node 
   initiating the graceful shutdown. Typically graceful shutdown is 
   triggered for administrative reasons, such as link maintenance or 
   software/hardware upgrade at a node.  "

 
 
In these cases, we have put a lot of effort into GMPLS to ensure that the
LSP is capable of continuing to exist even when the control plane is down. 
 

Certainly, but as you know these are for unplanned outages, aka graceful
restart (GR) mechanisms. This ID talks about planned outages: Graceful
Shutdown (GS), like to one you mentioned above. 

 
I am asking whether we want to give the ingress due warning that the LSP is
about to enter this state (i.e. data plane up, but control plane
disconnected). The reason why the ingress might be interested is that, once
in this state, the LSP is not fully manageable.
 
An option is to provide an error value that says "Data plane OK, but control
plane about to go away". This would allow the ingress to re-route (mb4b) if
it cared. 
 

The ID assumes that Graceful Shutdown mechanisms are agnostic to control vs.
data plan reasons for the planned outage. IMO we don't need specific codes
for one vs. the other failure. Do you or anyone else feels that we need to
have different cause code for the data vs. control plane failures (for e.g.,
some admin reasons).   

 
So the question for you and the WG is: Is this an important case?  
 

Yes, as mentioned above. 

 
 Does the ingress ever care about this loss of control plane connectivity? 

Yes, for the reasons you listed above, e.g., software upgrades. 

 
 
Cheers,
Adrian


------=_NextPart_000_006F_01C5180C.5AE15C40
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.1491" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D907592816-21022005><FONT =
face=3DArial=20
color=3D#000080 size=3D2>Hi Adrian, </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D907592816-21022005><FONT =
face=3DArial=20
color=3D#000080 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D907592816-21022005><FONT =
face=3DArial=20
color=3D#000080 size=3D2>This time it's crystal clear on what you were =
referring to=20
in your comments. Please see my reply in-line. </FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#000080 size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial color=3D#000080 =
size=3D2>Thanks</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial color=3D#000080 =
size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial color=3D#000080 size=3D2>Regards... =

Zafar</FONT><BR></DIV>
<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> Adrian Farrel=20
  [mailto:[e-mail]] <BR><B>Sent:</B> Monday, February 21, =
2005 7:19=20
  AM<BR><B>To:</B> Zafar Ali; [e-mail]<BR><B>Subject:</B> Re: =
Summary=20
  [was: RE: Starting a discussion on graceful =
shutdown]<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>Thanks for answers. Snipped down to =
just one=20
  point.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; &gt; &gt; &gt; Does it matter =
whether it=20
  is the control plane or the data&nbsp; <BR>&gt; &gt; &gt; &gt; plane =
that will=20
  be taken out of service?<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Yes, if =
data=20
  plane is going OOS, we are loosing traffic and <BR>&gt; &gt; &gt;=20
  motivation&nbsp;behind mb4b to reduce traffic hit is lost.<BR>&gt; =
&gt;=20
  <BR>&gt; &gt; Let me rephrase the question.<BR>&gt; &gt; If I know =
that the=20
  control plane is going OOS and I want to <BR>&gt; &gt; continue to be =
able to=20
  manage my LSPs I will want to move <BR>&gt; &gt; them to LSRs that =
will=20
  continue to have an active control <BR>&gt; &gt; plane. The data plane =
through=20
  the impacted LSRs may continue <BR>&gt; &gt; to be active (and =
therefore could=20
  continue to carry traffic).<BR>&gt; <BR>&gt; I am not sure if I =
understood=20
  your comment completely. However, <BR>&gt; the ID mentions about Grace =
Period=20
  and Removal of data plane </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>&gt; associated with the LSP under =
mb4b.=20
  </FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>I'll try again.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>The draft talks about cases where =
the data=20
  plane is going to be removed. No problem there.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>I am asking about cases where we =
know that the=20
  control plane is going to be removed, but where we know that the data =
plane is=20
  going to stay up.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>Examples include:</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>- going to take the software =
components down=20
  (perhaps for upgrade)</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2>- going to remove the control plane =
CPU (to=20
  replace it, dust it, or fit nerw tires)</FONT></DIV>
  <DIV><FONT face=3DCourier><FONT size=3D2>- going to take down the =
control channel=20
  (e.g. decommission the OSC laser)<SPAN =
class=3D907592816-21022005><FONT=20
  face=3DArial color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=3DCourier><FONT size=3D2><SPAN=20
  =
class=3D907592816-21022005></SPAN></FONT></FONT>&nbsp;</DIV></BLOCKQUOTE>=

<DIV dir=3Dltr><FONT color=3D#000080><FONT><SPAN =
class=3D907592816-21022005>Yes, most=20
certainly, this is one of the motivations behind this draft. In fact=20
t</SPAN></FONT><FONT><SPAN class=3D907592816-21022005>he -00 version of =
the ID had=20
following statement in the Introduction section. =
</SPAN></FONT></FONT></DIV>
<DIV dir=3Dltr><FONT><FONT color=3D#000080><SPAN=20
class=3D907592816-21022005></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT><SPAN class=3D907592816-21022005><FONT =
color=3D#000080>"<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3>a Service Provider may desire to gracefully (temporarily or =
definitely)=20
remove a TE Link, a group of TE Links or an entire node for =
administrative=20
reasons such as link maintenance or <STRONG>LSR software/hardware=20
upgrade</STRONG>. "</FONT></SPAN></FONT></SPAN></FONT></DIV>
<DIV dir=3Dltr><FONT><FONT color=3D#000080><SPAN=20
class=3D907592816-21022005></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT><FONT color=3D#000080><SPAN =
class=3D907592816-21022005>The=20
revised version of the ID (-01), already in draft queue have this as one =
of the=20
main requirements. </SPAN></FONT></FONT></DIV>
<DIV dir=3Dltr><FONT><FONT color=3D#000080><SPAN=20
class=3D907592816-21022005></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT><SPAN class=3D907592816-21022005><FONT=20
color=3D#000080>"&nbsp;&nbsp; - Graceful shutdown mechanisms are =
applicable to=20
removal a TE <BR>&nbsp;&nbsp; resource (e.g., link, a group of TE Links =
or an=20
entire node). Trigger <BR>&nbsp;&nbsp; for the graceful shutdown event =
is a=20
local matter at the node <BR>&nbsp;&nbsp; initiating the graceful =
shutdown.=20
Typically graceful shutdown is <BR>&nbsp;&nbsp; triggered for =
administrative=20
reasons, such as </FONT><FONT color=3D#000080><STRONG>link maintenance =
or=20
<BR>&nbsp;&nbsp; software/hardware upgrade at a node.</STRONG>&nbsp;=20
"</FONT></SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DCourier><FONT size=3D2><SPAN=20
  class=3D907592816-21022005>&nbsp;</SPAN></FONT></FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier><FONT size=3D2>In these cases, we have put a =
lot of=20
  effort into GMPLS to ensure that the LSP is capable of continuing to =
exist=20
  even when the control plane is down.<SPAN =
class=3D907592816-21022005><FONT=20
  face=3DArial color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=3DCourier><FONT size=3D2><SPAN=20
  =
class=3D907592816-21022005></SPAN></FONT></FONT>&nbsp;</DIV></BLOCKQUOTE>=

<DIV dir=3Dltr><FONT><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D907592816-21022005><FONT color=3D#000080>Certainly, but as you =
know these=20
are for unplanned outages, aka graceful restart (GR) mechanisms. This ID =
talks=20
about planned outages: Graceful Shutdown (GS), like to one you mentioned =

above.</FONT> </SPAN></FONT></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier size=3D2>I am asking whether we want to give =
the ingress=20
  due warning that the LSP&nbsp;is about to enter this state (i.e. data =
plane=20
  up, but control plane disconnected). The reason why the ingress might =
be=20
  interested is that, once in this state, the LSP is not fully=20
  manageable.</FONT></DIV>
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DCourier><FONT size=3D2>An option is to provide an =
error value=20
  that says "Data plane OK, but control plane about to go away". This =
would=20
  allow the ingress to re-route (mb4b) if it cared.<SPAN=20
  class=3D907592816-21022005><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=3DCourier><FONT size=3D2><SPAN=20
  =
class=3D907592816-21022005></SPAN></FONT></FONT>&nbsp;</DIV></BLOCKQUOTE>=

<DIV dir=3Dltr><FONT face=3DCourier><FONT size=3D2><SPAN=20
class=3D907592816-21022005><FONT face=3DArial color=3D#0000ff><FONT =
color=3D#000080>The=20
ID assumes that&nbsp;Graceful Shutdown mechanisms are =
agnostic&nbsp;</FONT><FONT=20
face=3D"Times New Roman" color=3D#000000 size=3D3><FONT face=3DArial =
color=3D#000080=20
size=3D2>to control vs. data plan reasons for the planned outage. IMO we =
don't=20
need specific codes for one vs. the other failure. Do you or anyone else =
feels=20
that we need to have different cause code for the data vs. control plane =

failures (for e.g., some admin reasons).=20
</FONT>&nbsp;</FONT></FONT>&nbsp;</SPAN></FONT></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT face=3DCourier>So the question for you and =
the WG=20
  is:&nbsp;</FONT><FONT face=3DCourier>Is this an important =
case?&nbsp;<SPAN=20
  class=3D907592816-21022005><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT face=3DCourier><SPAN=20
  =
class=3D907592816-21022005></SPAN></FONT></FONT>&nbsp;</DIV></BLOCKQUOTE>=

<DIV dir=3Dltr><FONT size=3D2><FONT face=3DCourier><SPAN=20
class=3D907592816-21022005><FONT color=3D#000080>Yes, as mentioned =
above.</FONT>=20
</SPAN></FONT></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><FONT size=3D2><FONT face=3DCourier><SPAN=20
  class=3D907592816-21022005></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT face=3DCourier><SPAN=20
  class=3D907592816-21022005>&nbsp;</SPAN>Does the ingress ever care =
about this=20
  loss of control plane connectivity?</FONT><FONT face=3DArial =
color=3D#0000ff><SPAN=20
  =
class=3D907592816-21022005>&nbsp;</SPAN></FONT></FONT></DIV></BLOCKQUOTE>=

<DIV dir=3Dltr><FONT size=3D2><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D907592816-21022005><FONT color=3D#000080>Yes, for the reasons =
you listed=20
above, e.g., software upgrades.</FONT> </SPAN></FONT></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><FONT size=3D2><FONT face=3DArial color=3D#0000ff><SPAN=20
  class=3D907592816-21022005>&nbsp;</SPAN></FONT></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></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_006F_01C5180C.5AE15C40--



Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2005 15:03:26 +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: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Date: Mon, 21 Feb 2005 15:02:29 -0000
Message-ID: <[e-mail]>
Thread-Topic: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Thread-Index: AcUVU+m/zYLdKuDuRwSPXntuZCpGdQCrIMaw
From: "Philip Crocker" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

Adrian,

Thanks for your comments and explanation.  If you can clarify the =
"required" text in section 1 as we discussed below that would be great.

Regards,
Phil

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: 18 February 2005 00:50
To: Philip Crocker
Cc: [e-mail]; [e-mail]
Subject: Re: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.


Phil

> > > 1)  Firstly the question.  In section 1 (the 4th
> > > paragraph), the text
> > > indicates that SONET / SDH extensions to link verification and =
link
> > > property correlation require both section 3 and section 4 (Trace
> > > Monitoring).  However, it seems to me that the extensions =
described
> > > in section 3 alone are enough to perform link verification and =
link
> > > property correlation for SONET / SDH links.  Specifically, though
> > > the TraceMonitor<xx> and TraceMismatch messages defined in section
> > > 4 can be used to perform an external verification of SONET / SDH
> > > links, it is not clear why these messages are necessary in =
addition
> > > to the LMP link verification procedure (as extended by section 3).
> > > Could you please explain this?
> >
> > It is slightly unclear what you are asking.
> > Note that the Trace object is defined in section 4 and is
> > required for J0, J1 and J2 Test procedures as decribed in
> > section 3. Thus, both sections 3 and 4 are necessary for the
> > new link verification procedures.
> >
> > It is possible that you are baulking at "This requires a new
> > trace monitoring function that is also discussed in this
> > document." "Requires" may be slightly too strong.

> [PJC]
> I agree that the <Trace> object defined in section 4 is
> required by section 3.

OK. Sounded like you were saying that it seemed to you that the =
extensions
described in section 3 alone are enough to perform link verification and
link property correlation for SONET / SDH links.

> However, section 1 says that the 'trace monitoring function'
> is required by LMP SONET / SDH specific link verification
> and link correlation.  I understand 'trace monitoring function'
> to refer to the new TraceMonitor messages (and not just the
> Trace object), and hence my confusion.

Yup. As I say, "required" is too strong.

> If as you imply, the only part of section 4 required
> for LMP SONET / SDH specific link verification and
> link correlation is the Trace object, then I would
> recommend the text in section 1 be changed to reduce
> confusion.

We will try to catch this in authors' 48 hours.

> In any case, I remain unsure of the background and
> proposed uses of the TraceMonitor and other messages
> defined in section 4 - can you help here?

The motivation for trace monitoring is unchanged from overhead =
monitoring
in TDM. The purpose of the messages in LMP is to allow LMP control of =
this
feature. The net result is better fault management.

> Assuming there are valid reasons for this function I think
> we should beef up the introductory text in section 1 to
> describe them.

The ship has sailed; and besides, if you come to this draft with a
reasonable understanding of TDM (which you should given section 2) this =
is
not an issue.

> > > 2)  Secondly, I have a minor comment on section 4.  I
> > > understand from
> > > section 4.1.1 that a TraceMonitor message should contain a single
> > > <TRACE> object.  However, section 4.1.2 can be read to imply that =
a
> > > TraceMonitor message can contain more than one <TRACE> object.  =
Can
> > > I suggest the following replacement text for section 4.1.2?
> > >
> > >   The TraceMonitorAck message (Message Type TBA by IANA) is used =
to
> > >   acknowledge receipt of the TraceMonitor message and indicate =
that
> > >   the TRACE object in the TraceMonitor message have been received
> > >   and processed correctly (i.e. no Trace Mismatch).
> >
> > There is absolutely nothing wrong with the existing text.
> > "All of the TRACE Objects in the TraceMonitor message" is
> > perfectly fine when there is only one such object allowed.
> > Leaving the text as it is reduces any changes should the
> > number of Test objects on a TraceMonitor ever be increased.
>
>[PJC]
> I agree there's nothing strictly wrong with the existing text,

Good.

> but it's misleading to have one part of the document state
> there is exactly one object, and then have another referring
> to multiple objects.

I'm sorry you were mislead.

> I would vote to remove all ambiguity and change the text.

We don't vote :-)

> Yes, I agree that if the number is increased in the future,
> the wording has to be changed, but I believe the improved
> clarity makes it worth it.  However, this isn't an important issue
> and I don't feel strongly about this.

Excellent.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2005 14:27:00 +0000
Message-ID: <0a5501c51821$3b9c8cf0$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Zafar Ali" <[e-mail]>, <[e-mail]>
Subject: Re: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Mon, 21 Feb 2005 12:18:57 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A16_01C5180F.849F36D0"

This is a multi-part message in MIME format.

------=_NextPart_000_0A16_01C5180F.849F36D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for answers. Snipped down to just one point.

> > > > Does it matter whether it is the control plane or the data =20
> > > > plane that will be taken out of service?
> > >
> > > Yes, if data plane is going OOS, we are loosing traffic and=20
> > > motivation behind mb4b to reduce traffic hit is lost.
> >=20
> > Let me rephrase the question.
> > If I know that the control plane is going OOS and I want to=20
> > continue to be able to manage my LSPs I will want to move=20
> > them to LSRs that will continue to have an active control=20
> > plane. The data plane through the impacted LSRs may continue=20
> > to be active (and therefore could continue to carry traffic).
>=20
> I am not sure if I understood your comment completely. However,=20
> the ID mentions about Grace Period and Removal of data plane=20
> associated with the LSP under mb4b.=20

I'll try again.
The draft talks about cases where the data plane is going to be removed. =
No problem there.
I am asking about cases where we know that the control plane is going to =
be removed, but where we know that the data plane is going to stay up.
Examples include:
- going to take the software components down (perhaps for upgrade)
- going to remove the control plane CPU (to replace it, dust it, or fit =
nerw tires)
- going to take down the control channel (e.g. decommission the OSC =
laser)

In these cases, we have put a lot of effort into GMPLS to ensure that =
the LSP is capable of continuing to exist even when the control plane is =
down.

I am asking whether we want to give the ingress due warning that the LSP =
is about to enter this state (i.e. data plane up, but control plane =
disconnected). The reason why the ingress might be interested is that, =
once in this state, the LSP is not fully manageable.

An option is to provide an error value that says "Data plane OK, but =
control plane about to go away". This would allow the ingress to =
re-route (mb4b) if it cared.

So the question for you and the WG is: Is this an important case? Does =
the ingress ever care about this loss of control plane connectivity?

Cheers,
Adrian
------=_NextPart_000_0A16_01C5180F.849F36D0
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>Thanks for answers. Snipped down to =
just one=20
point.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; &gt; &gt; &gt; Does it matter =
whether it is=20
the control plane or the data&nbsp; <BR>&gt; &gt; &gt; &gt; plane that =
will be=20
taken out of service?<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Yes, if data =
plane is=20
going OOS, we are loosing traffic and <BR>&gt; &gt; &gt; =
motivation&nbsp;behind=20
mb4b to reduce traffic hit is lost.<BR>&gt; &gt; <BR>&gt; &gt; Let me =
rephrase=20
the question.<BR>&gt; &gt; If I know that the control plane is going OOS =
and I=20
want to <BR>&gt; &gt; continue to be able to manage my LSPs I will want =
to move=20
<BR>&gt; &gt; them to LSRs that will continue to have an active control =
<BR>&gt;=20
&gt; plane. The data plane through the impacted LSRs may continue =
<BR>&gt; &gt;=20
to be active (and therefore could continue to carry traffic).<BR>&gt; =
<BR>&gt; I=20
am not sure if I understood your comment completely. However, <BR>&gt; =
the ID=20
mentions about Grace Period and Removal of data plane </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; associated with the LSP under =
mb4b.=20
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I'll try again.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>The draft talks about cases where the =
data plane=20
is going to be removed. No problem there.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I am asking about cases where we know =
that the=20
control plane is going to be removed, but where we know that the data =
plane is=20
going to stay up.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Examples include:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- going to take the software =
components down=20
(perhaps for upgrade)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- going to remove the control plane =
CPU (to=20
replace it, dust it, or fit nerw tires)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- going to take down the control =
channel (e.g.=20
decommission the OSC laser)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>In these cases, we have put a lot of =
effort into=20
GMPLS to ensure that the LSP is capable of continuing to exist even when =
the=20
control plane is down.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I am asking whether we want to give =
the ingress=20
due warning that the LSP&nbsp;is about to enter this state (i.e. data =
plane up,=20
but control plane disconnected). The reason why the ingress might be =
interested=20
is that, once in this state, the LSP is not fully =
manageable.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>An option is to provide an error =
value that says=20
"Data plane OK, but control plane about to go away". This would allow =
the=20
ingress to re-route (mb4b) if it cared.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>So the question for you and the WG=20
is:&nbsp;</FONT><FONT face=3DCourier size=3D2>Is this an important case? =
Does the=20
ingress ever care about this loss of control plane =
connectivity?</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></BODY></HTML>

------=_NextPart_000_0A16_01C5180F.849F36D0--




Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2005 14:26:55 +0000
Message-ID: <0a5901c51821$3f934290$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Draft status updated on alternate CCAMP web page
Date: Mon, 21 Feb 2005 12:32:04 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I have updated http://www.oldog.co.uk/ccamp-drafts.htm to indicate the
current status of all CCAMP drafts. I have yet to update the section that
covers personal drafts related to CCAMP.

Adrian




Envelope-to: [e-mail]
Delivery-date: Sun, 20 Feb 2005 20:22:21 +0000
From: "Zafar Ali" <[e-mail]>
To: "'Richard Rabbat'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Sun, 20 Feb 2005 12:16:10 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcUVQUjli6cNgiFNQYaSxBRzxIFP9QBw7Hqg
Message-Id: <[e-mail]>

Dear Richard, 

Please see my reply in-line.

Thanks a lot for your review and detailed comments, 
 
Regards... Zafar
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Richard Rabbat
> Sent: Thursday, February 17, 2005 5:35 PM
> To: 'Zafar Ali'; 'Adrian Farrel'; [e-mail]
> Subject: RE: Summary [was: RE: Starting a discussion on 
> graceful shutdown]
> 
> Hi Zafar,
> First, I'd like to point out that your draft has expired; 
> thought you might want to put a quick version up.

You will see a copy of draft reflecting all comments received thus far petty
soon. 

> Some comments inline and more generally about the draft.
> Thanks a lot,
> Richard.
> --
> - in the text, you say: MAY NOT. This is not defined. 

Good catch, in the new version you will see revised text. 

> 
> - Discussing PCE in this draft seems to be out of place. This 
> draft is sent to ccamp and should not specify what a PCE node 
> has to do.
> 
> - This is especially confusing since you say that a PCE is 
> receiving RSVP Path error messages. This implies somebody 
> sent it to the PCE. But you have defined communication from 
> the node where shutdown occurs to the ingress.
> How does the PCE know about this message?

Via PCC, 

There are places where document lists set of roles that any entity computing
a path should follow, i.e., Ingress node, intermediate nodes performing ERO
extensions or PCE. Certainly specification of (related) PCE-PCC
communication is beyond the scope of this document and in the revision we
have clearly stated that. 

> 
> - You talk in the draft about FRR but FRR does not apply to 
> all types of switching in GMPLS. Please reflect that in your 
> text to say: "In the case of PSC, ..."

Done, 

> 
> - You mention FSC, LSC and PSC. Is it your objective not to 
> address L2SC and TDM?

No, nothing intentional to avoid L2SC, TDM. We have modified the text
accordingly. 

> 
> - I'd also like to ask you how you decommission a bundle? 
> Does the headend of that bundle have the responsibility of 
> telling each headend of each component about the shutdown?

Yes, and ID talks about this. When all component links of the bundle are
being decommissioned, its like graceful shutdown of a TE link. However, if
only a subset of component links are decommissioned, procedure for graceful
shutdown of the component links applies (as listed in section 4.2 of the
last version of the ID). 

> E.g. let's say I'm shutting down a link in a SONET box that 
> has a server-layer circuit (say an STS-3c) that is carrying 
> Ethernet as the client layer. Who tells the Ethernet 
> "headend" about the shutdown?

The box/ node upstream to the link under graceful shutdown. I.e., the box/
node which is using the link under graceful shutdown as an Egress link for
the affected flows. 

> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Zafar Ali
> > Sent: Tuesday, February 15, 2005 10:34 PM
> > To: 'Adrian Farrel'; [e-mail]
> > Subject: Summary [was: RE: Starting a discussion on 
> graceful shutdown]
> > 
> > 
> > Hi Adrian,
> > 
> > Thanks for putting this email together. In the following I 
> have tried 
> > to summarize the discussion we had on this thread and next steps.
> > 
> > Thanks
> > 
> > Regards... Zafar
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Adrian Farrel
> > > Sent: Tuesday, December 07, 2004 10:39 AM
> > > To: [e-mail]
> > > Subject: Starting a discussion on graceful shutdown
> > > 
> > > Hi,
> > > 
> > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace
> > > ful-shutdown-00.txt was discussed at the meeting in 
> Washington DC, 
> > > and one of the questions raised was whether or not we already had 
> > > (multiple!) mechanisms capable of performing the function 
> described 
> > > in the draft.
> > > 
> > > Kireeti quite rightly suggested that we step back and 
> make sure we 
> > > understand the requirements. This is my take on those 
> requirements 
> > > and I would appreciate it if the authors of the draft 
> joined in and 
> > > other people on the list commented.
> > > 
> > > We wish to manage a link that needs to be taken out of service in 
> > > some way (data plane and/or control plane will be disrupted). The 
> > > link concerned has active LSPs and we wish to offer upstream LSRs 
> > > (in particular the ingress) the opportunity to use 
> make-before-break 
> > > to re-route the LSPs.
> > > 
> > > In order to achieve this, we need to communicate to the upstream 
> > > nodes. Should we choose signaling or routing? Are there benefits 
> > > that mean we should use both, or should we limit to just one?
> > 
> > Yes, we need both. 
> > 
> Can you explain to me the justification for both? 
> I don't think there is no need for routing extensions, since 
> the routing protocol will stop advertising decommissioned links. 
> 
> Can you also explain the difference between your method and 
> the available SONET mechanisms for shutting down resources?
> 
> In section 4, you talk about OSPF/ISIS. Do you mean OSPF-TE/ISIS-TE? 
> 
> > > 
> > > There is another aspect to be considered. Should we also 
> attempt to 
> > > protect new path computations from selecting the link 
> that will be 
> > > taken out of service?
> > 
> > Yes,
> 
> There is a balance between (1) telling ingress LSR's vs. (2) 
> ingress LSR's receiving notification through usual updates. 
> Authors need to justify need and advantage for (1).
> > 
> > > 
> > > How should we consider the case of a node (data plane 
> and/or control 
> > > plane) being taken out of service?
> > 
> > Yes,
> > 
> > >Is a node simply a
> > > collection of links?
> > 
> > Yes, during graceful shutdown period. 
> > 
> > > 
> > > If a component link of a bundle is being taken out of 
> service (and 
> > > assuming other component links are available) is this 
> just an issue 
> > > for the adjacent nodes or does it need to be communicated more 
> > > widely?
> > 
> > Let head end do the mb4b,
> > 
> > > If the downstream node decides to
> > > take the component link out of service, how does it inform the 
> > > upstream node?
> > > 
> > > Does it matter whether it is the control plane or the data plane 
> > > that will be taken out of service?
> > 
> > Yes, if data plane is going OOS, we are loosing traffic and 
> motivation 
> > behind mb4b to reduce traffic hit is lost.
> > 
> > > 
> > > Opinions please.
> > > 
> > > I would like to see these issues and their answers 
> captured clearly 
> > > in a requirements section of any draft. Would the authors of 
> > > draft-ali-ccamp-mpls-graceful-shutdown-00.txt
> > > be willing to take that on even though the end result 
> might be that 
> > > procedures other than those they suggest will be selected?
> > 
> > Sure, we plan to revised the ID based on this survey as well as 
> > comments from the WG for the upcoming IETF.
> > 
> > Thanks again Adrian for your suggestion and putting this together. 
> > 
> > Thanks
> > 
> > Regards... Zafar
> > 
> 
> > > 
> > > Adrian
> > > 
> > > 
> > 
> > 
> 




Envelope-to: [e-mail]
Delivery-date: Sun, 20 Feb 2005 17:48:45 +0000
Message-Id: <[e-mail]>
From: "Zafar Ali" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Sun, 20 Feb 2005 12:45:41 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcUVTiFJqbz4BRadRDG9FacuIsESigBp85CA

Dear Adrian, 

Please see my reply in-line. 

Thanks again for your input.

Regards... Zafar

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Thursday, February 17, 2005 4:01 PM
> To: Zafar Ali; [e-mail]
> Subject: Re: Summary [was: RE: Starting a discussion on 
> graceful shutdown]
> 
> Thanks, Zafar.
> 
> Comments in line.
> 
> Adrian
> 
> > > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace
> > > ful-shutdown-00.txt was discussed at the meeting in 
> Washington DC, 
> > > and one of the questions raised was whether or not we already had 
> > > (multiple!) mechanisms capable of performing the function 
> described 
> > > in the draft.
> > >
> > > Kireeti quite rightly suggested that we step back and 
> make sure we 
> > > understand the requirements. This is my take on those 
> requirements 
> > > and I would appreciate it if the authors of the draft 
> joined in and 
> > > other people on the list commented.
> > >
> > > We wish to manage a link that needs to be taken out of service in 
> > > some way (data plane and/or control plane will be disrupted). The 
> > > link concerned has active LSPs and we wish to offer upstream LSRs 
> > > (in particular the ingress) the opportunity to use 
> make-before-break 
> > > to re-route the LSPs.
> > >
> > > In order to achieve this, we need to communicate to the upstream 
> > > nodes. Should we choose signaling or routing? Are there benefits 
> > > that mean we should use both, or should we limit to just one?
> >
> > Yes, we need both.
> 
> Well, I was kind of hoping for a reasoned debate :-)

The reason for me not listing the motivation as I was trying to summarize
the discussion on this thread. Here are the reasons/ requirements for having
complementary mechanism in IGP and RSVP-TE (as we discussed on the list).

- It is required to prevent other network nodes to use network resources
which are about to be shutdown, should new TE LSP be set up. As RSVP
mechanisms only convey the information for the transiting LSPs to the router
along the upstream Path and not to all nodes in the network, indication of
graceful shutdown via IGP flooding is required to discourage a node from
establishing new LSPs through the resources being shut-down.

- Graceful shutdown mechanisms are required to address TE LSPs spanning
multiple domains, as well as intra domain TE LSPs. Here, a domain is defined
as either an IGP area or an Autonomous System. An IGP based solution is not
applicable when dealing with Inter-area and Inter-AS traffic engineering, as
LSA or LSP flooding is restricted to IGP areas/levels. Consequently, RSVP
based mechanisms are required to cope with TE LSPs spanning multiple
domains.

> 
> > > There is another aspect to be considered. Should we also 
> attempt to 
> > > protect new path computations from selecting the link 
> that will be 
> > > taken out of service?
> >
> > Yes,

Please see requirements listed above. 

> >
> > > How should we consider the case of a node (data plane 
> and/or control 
> > > plane) being taken out of service?
> >
> > Yes,
> >
> > >Is a node simply a  collection of links?
> >
> > Yes, during graceful shutdown period.
> 
> So does that mean you would like to advertise the withdrawal 
> of 10,000 links, or the withdrawal of one node. Recall that 
> all link advertisement is associated with the node, so node 
> withdrawal is meaningful.

I think removal of Router Address TLV would suffice. 

> 
> > > If a component link of a bundle is being taken out of 
> service (and 
> > > assuming other component links are available) is this 
> just an issue 
> > > for the adjacent nodes or does it need to be communicated more 
> > > widely?
> >
> > Let head end do the mb4b,
> 
> Presumably this would not be true if the bundle was 
> advertised as having some form of link protection (and the 
> component links provided this protection).

Yes, it is required to co-ordinate graceful shutdown with the protection
available for the TE link or the affected LSP. The draft did list the
following case, 

"When a graceful shutdown operation is performed along the path of a
protected LSP, the PLR MAY trigger Fast Reroute [FRR] for the appropriate
set of affected TE LSPs and forward a Path Error with "Tunnel locally
repaired" sub-code, as per the procedures specified in [MPLS-FRR]". 

When unbundled TE link is protected and maintenance of components within the
protected TE link is possible using means other than graceful shutdown
mechanisms (e.g., by L2), graceful shutdown may be handled by a local
switchover without informing the network of graceful shutdown condition.

In case of bundled TE links, RSVP flows are "pined" to a component link and
removal of that component link does affect the flows using it. Hence removal
of a component link has to be handled at the MPLS layer using means like
mb4b, FRR, path/ segment protection. 

In the case of Path/ segment protection, it is also possible to make use of
protection switchover mechanism (instead of mb4b) but IMO this is a matter
of local choice at the head-end LSR. The job of graceful shutdown mechanism
is to carry information about the graceful shutdown event and specify the
resource under graceful shutdown. 

> 
> > > If the downstream node decides to
> > > take the component link out of service, how does it inform the 
> > > upstream node?
> 
> You missed this one.

At present draft mentions the use of perr with "Local component link
maintenance" flag and assumes a head-end based rerouting/ mb4b. 

> 
> > > Does it matter whether it is the control plane or the data plane 
> > > that will be taken out of service?
> >
> > Yes, if data plane is going OOS, we are loosing traffic and 
> motivation 
> > behind mb4b to reduce traffic hit is lost.
> 
> Let me rephrase the question.
> If I know that the control plane is going OOS and I want to 
> continue to be able to manage my LSPs I will want to move 
> them to LSRs that will continue to have an active control 
> plane. The data plane through the impacted LSRs may continue 
> to be active (and therefore could continue to carry traffic).

I am not sure if I understood your comment completely. However, the ID
mentions about Grace Period and Removal of data plane associated with the
LSP under mb4b. 

> 
> Is this an important case? If so, do we manage it in the same way?
> 
> > > Opinions please.
> > >
> > > I would like to see these issues and their answers 
> captured clearly 
> > > in a requirements section of any draft. Would the authors of 
> > > draft-ali-ccamp-mpls-graceful-shutdown-00.txt
> > > be willing to take that on even though the end result 
> might be that 
> > > procedures other than those they suggest will be selected?
> >
> > Sure, we plan to revised the ID based on this survey as well as 
> > comments from the WG for the upcoming IETF.
> >
> > Thanks again Adrian for your suggestion and putting this together.
> >
> > Thanks
> >
> > Regards... Zafar
> >
> > >
> > > Adrian
> > >
> > >
> >
> >
> 



Envelope-to: [e-mail]
Delivery-date: Sat, 19 Feb 2005 10:06:23 +0000
Message-ID: <089201c5166a$553b20d0$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
Date: Sat, 19 Feb 2005 09:48:59 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Draft revision for boiler-plate and to keep draft alive.

Thanks,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, February 18, 2005 8:20 PM
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-03.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 : Exclude Routes - Extension to RSVP-TE
> Author(s) : A. Farrel, et al.
> Filename : draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
> Pages : 29
> Date : 2005-2-18
>
> The current 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.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-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-te-exclude-route-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-te-exclude-route-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, 19 Feb 2005 02:37:18 +0000
Message-ID: <[e-mail]>
Date: Sat, 19 Feb 2005 03:34:00 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC:  [e-mail], Arthi Ayyangar <[e-mail]>,  [e-mail]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

igor:

Igor Bryskin wrote:
> Dimitri,
> 
> Looks like we are talking different languages.
> 
> The discussion was inititiated by your question: is it worth advertisng
> stitching segments as FAs. 

i was referring to such segment as and edge-to-edge LSP signaled using 
RFC 3473 - i was not under the impression this document intended to 
cover any other case -

> At the same time you keep complaining that I  bring PCE into the discussion. 
> Who in your opinion is the user of such advertising apart from PCE?

what do you mean by "who is the user ?" ... it is imho obvious that the 
only "user" for a LSP segment being part of the stitching operation is 
the end-to-end LSP

> I am saying that segments provisioned by the management plane could be used
> in e2e LSP dynamic provisioning and the only way to make it possible is via
> stitching. You are saying that this is not stitching because in your opinion
> stitching is concerned only with segments dynamically provisioned, and there
> is some other mechanism (which you were not specific about) 

i think this is spelled out as part of RFC 3473

> that makes possible using the statically provisioned segments.

but i do not call this "LSP stitching" as no one did ever rely on this 
mechanism to make use of a statically provisioned subnetwork since at 
the end at the discretion of its owner - the wg is involved into the 
present discussion because we are assuming intermediate nodes (i.e. part 
of the segment) being GMPLS (RFC 3473) capable

> Finally:
> 
> 
>>>IB>> Just to be clear. You mentioned the use of advertised node
>>>capabilities. My point is that these advertisements are useful for path
>>>computation but are of no use for e2e signaling
>>
>>and so just to be clear if they are not useful for e2e signaling what is
>>the purpose of advertising them for this purpose ?
> 
> Comments like these just knock me off. I always believe that any type of
> advertising is being done for the purpose of routing and path computation
> but have zero relevance for signaling. Am I not right ? Consider, for
> instance, the case when all EROs are fully specified by the user. Can I
> signal such LSP? If yes, do I need TED in this case?

obviously this is not the comment i made here - the comment is "if not 
useful for end-to-end multi-domain LSP what is the purpose of this 
advertisement"

> Igor
> 
> 
> ----- Original Message ----- 
> From: "dimitri papadimitriou" <[e-mail]>
> To: "Igor Bryskin" <[e-mail]>
> Cc: <[e-mail]>; "Arthi Ayyangar"
> <[e-mail]>; <[e-mail]>
> Sent: Thursday, February 17, 2005 5:33 PM
> Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
> 
> 
> 
>>igor - see in-line:
>>
>>[snip]
>>
>>
>>>>>Your point/question is very simple, which is what does it give to
>>>>>advertise stitching segments as FAs, is that correct?
>>>>>
>>>>>My answers are very simple either:
>>>>>
>>>>>1) How else are you going to use statically provisioned segments as
> 
> part
> 
>>>>>of dynamically provisioned end-to-end LSPs ?
>>>>
>>>>you ask a different question from the initial issue because advertize a
>>>>TE link was possible today without using stitching, however this issue
>>>>also depends what do you mean by statical provisioning ?
>>>
>>>IB>> I have segments that are provisioned/owned by the management plane
>>
>>exactly - there is no *LSP stitching* anymore - we discuss about control
>>plane operations (the intermediate segment is an entity owned by the
>>control plane)
>>
>>note: by the way, operation you are referring to is supported today
>>(without the procedures described as part of this document because this
>>has nothing to do with stitching)
>>
>>
>>>>>2) How else you can accomplish a transition strategy when some of the
>>>>>nodes that are going to be involved in end-to-end dynamically
> 
> provisioned LSPs
> 
>>>>>do not have proper signaling software?
>>>>
>>>>and i did ask what is the point in applying LSP segment signaling on
>>>>segment that "do not have proper signaling software"
>>>
>>>IB>> The point is that transit nodes of the segments do not participate
> 
> and
> 
>>>hence do not have to support e2e signaling
>>
>>well i think we should then determine the working assumptions here,
>>intermediate nodes part of an LSP segment are GMPLS nodes as any other,
>>otherwise the segment could itself not be setup (stitching is just a way
>>to leave control to the head-end of the segment but there are no
>>specific assumptions made in terms of signaling capabilities for the
>>intermediate nodes, they are assumed to be GMPLS signaling capable nodes
>>as any other)
>>
>>
>>>>>The specific example is using LSRs that
>>>>>do not support p2mp signaling as transit nodes in p2mp LSPs. Your point
>>>>>about advertising of node capabilities is relevant only for routing -
>>>>>the PCE computing p2mp tree may take in consideration the advertised
> 
> node
> 
>>>>>capabilities and assume that stitching segments may be created
>>>>>dynamically if needed.
>>>>
>>>>just to be clear the PCE discussion is completely outside of the present
>>>>discussion - afaik the working group has (still) to provide requirements
>>>>for the PCE wg -
>>>
>>>IB>> Just to be clear. You mentioned the use of advertised node
>>>capabilities. My point is that these advertisements are useful for path
>>>computation but are of no use for e2e signaling
>>
>>and so just to be clear if they are not useful for e2e signaling what is
>>the purpose of advertising them for this purpose ?
>>
>>
>>>>>What if I don't want them to be dynamically created and rather
>>>>>have them pre-provisioned to spead up the process of p2mp tunnel setup
>>>>>and decrease blocking probability?
>>>>
>>>>not sure that compared to the global complexity of computing the tree
>>>>this is going to be a significant improvement, but if you have the
>>>>possibility to determine the bandwidth on the corr. segments i don't see
>>>>here how you decrease the blocking probability (afaik propagation of
>>>>segment related information is equivalent to the corresponding links
>>>>advertisement)
>>>
>>>IB>> Dynamic establishment of the stitching segments may fail
>>
>>not sure to catch your point, if you think a p2p LSP establishment may
>>fail not sure it is wise to start thinking about p2mp LSP establishment
>>- on the other side pre-provisioning of the segment if not guaranteed
>>within certain limits can not guarantee that you would be able to stitch
>>it afterwards (refresh, etc.)
>>
>>
>>>>>3) What if I want to attract certain LSPs  to use pre-provisioned
>>>>>segments even if the overall cost of such LSPs would be higher than if
> 
> they would
> 
>>>>>take paths computed without consideration of these segments, but it is
>>>>>desirable for the LSPs to use the segments anyway. Exanple: the
> 
> segments
> 
>>>>>are provisioned to satisfy wavelength continuity constraint and I don't
> 
> have
> 
>>>>>PCE that can perform path computation with such contraint on path
> 
> segments
> 
>>>>>between points of OEO.
>>>>
>>>>as said above it would desirable to leave PCE aspects outside of the
>>>>picture, but this application is really interesting because on one side
>>>>i thought we had the label set to solve this issue (note: that even if a
>>>>path is pre-computed explicit label control can be used to provision the
>>>>segment between converting points - don't PCEs for this)
>>>
>>>IB>> First, this is just an example of the situation when I want
>>>pre-provisioned segments to be used in e2e LSP provisioning.
>>>Second, satisfying the wavelength continuity constraint takes much more
>>>than just using the label set. You need to have:
>>>a) information about all lambdas in all isles of transparency;
>>
>>this may be the case but once known explicit label control on each link
>>is enough to assume continuity
>>
>>
>>>b) very complex PCE that is capable of computing optimal path(s) that
> 
> use
> 
>>>the same wavelength on all links within each OEO-OEO segments satisfying
> 
> all
> 
>>>other optical constraints.
>>
>>PCE, again PCE, but the computation of such path was possible well
>>before even the term did exist - you mix the computation with the access
>>to the computation result -
>>
>>
>>>It is much simpler to pre-provision such OEO-OEO segments and advertise
> 
> them
> 
>>>as TE links, than a simple PCE would do the job.
>>
>>it is the term "pre-provision" that causes the main issue here, one
>>dimension of the problem is simplified but how many are getting
>>complexified ? and where is the evaluation of this trade-off ?
>>
>>
>>>Igor
>>>
>>>
>>>
>>>>on the other hand is how much possible pre-provisioned segments - so
>>>>overhead - are now going to be advertised if the traffic demand is
>>>>unknown ? and on the other hand, if all traffic matrix is known
>>>>beforehand is there any rationale to create these segments instead of
>>>>directly provisioning
>>>>
>>>>it is interesting to see that you are populating this discussion with
>>>>PCE application - i would be more in favor in leaving the possibility of
>>>>advertising segments once a clear set is being identified rather than
>>>>the other way around
>>>>
>>>>
>>>>
>>>>>Igor
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>----- Original Message ----- 
>>>>>From: "dimitri papadimitriou" <[e-mail]>
>>>>>To: "Igor Bryskin" <[e-mail]>
>>>>>Cc: <[e-mail]>; "Arthi Ayyangar"
>>>>><[e-mail]>; <[e-mail]>
>>>>>Sent: Thursday, February 17, 2005 1:19 PM
>>>>>Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Igor Bryskin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>dimitri, see in line.
>>>>>>>
>>>>>>>----- Original Message ----- 
>>>>>>>From: "dimitri papadimitriou" <[e-mail]>
>>>>>>>To: "Igor Bryskin" <[e-mail]>
>>>>>>>Cc: <[e-mail]>; "Arthi Ayyangar"
>>>>>>><[e-mail]>; <[e-mail]>
>>>>>>>Sent: Thursday, February 17, 2005 11:40 AM
>>>>>>>Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>igor - see in-line
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>Please see my replies (AA--->) inline.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>---------> An LSP segment may be created either by
> 
> configuration
> 
>>>>>or
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>due to arrival of an e2e LSP setup request itself. Similar to
> 
> an
> 
>>>>>FA,
>>>>>
>>>>>
>>>>>
>>>>>>>an
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>LSP segment may or may not be advertised as a TE link. But, if
>>>>>>>>>>>>>>pre-created, it could be advertised, in which case other nodes
>>>
>>>may
>>>
>>>
>>>>>>>>>>>>>>compute a path over it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Why would you want to or not want to advertise an FA ?
>>>>>>>>>>>>>
>>>>>>>>>>>>>i understand the point on pre-created <-> advertised but this
>>>>>>>
>>>>>>>knowledge
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>may be useful for nodes part of the same area (not for nodes
>>>>>
>>>>>external
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>to this area)
>>>>>>>>>>>>
>>>>>>>>>>>>AA -------> Absolutely ...this definitely cannot be advertised
>>>>>
>>>>>outside
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>the area (domain). I think this has been explicitly mentioned.
>>>>>>>>>>>>
>>>>>>>>>>>>so in case a node for inst. advertises three terminating
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>links with PSC-2 (one of these being the LSP segment) then a
>>>>>
>>>>>another
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>node (part of the same area) receiving an incoming multi-area
>>>
>>>PSC-2
>>>
>>>
>>>>>>>LSP
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>request may start making use of this segment to join the next
>>>>>
>>>>>border,
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>therefore advertisement of the LSP segment may create a
> 
> multi-hop
> 
>>>>>>>>>>>>>condition, but now once used relevance of the existence of the
>>>>>>>
>>>>>>>segment
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>is not a useful information (for the area) as there is no
>>>>>
>>>>>possibility
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>to make re-use of it except when the end-to-end LSP is torn
> 
> down
> 
>>>>>>>>>>>>AA----------> I understand your point that once an LSP has been
>>>>>>>
>>>>>>>admitted
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>into an LSP segment it is no longer usable by other nodes in
> 
> that
> 
>>>>>>>area.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>But would you rather stop advertising the link at this point, if
>>>
>>>you
>>>
>>>
>>>>>>>>>>>>were previously advertising it ? Don't you think that is a big
>>>>>
>>>>>hammer
>>>>>
>>>>>
>>>>>
>>>>>>>? E.g.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>how would a head end which has indeed computed a path over that
>>>
>>>LSP
>>>
>>>
>>>>>>>>>>>>segment differentiate this event from an LSP segment down event
>>>>>
>>>>>where
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>the link is deleted from the database ? So, all the document
> 
> says
> 
>>>>>>>today is
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>that you set the unreserved bw on the LSP segment to zero. The
>>>
>>>idea
>>>
>>>
>>>>>is
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>to still let other nodes know that the link exists but is
>>>
>>>unusable.
>>>
>>>
>>>>>It
>>>>>
>>>>>
>>>>>
>>>>>>>is
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>not different from a FA-LSP being consumed...in that case we
> 
> don't
> 
>>>>>>>stop
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>advertising the FA (if we were doing so previously), right ?
>>>>>>>>>>>
>>>>>>>>>>>IB>> Completley agree with Arthi. Besides, several parallel
>>>
>>>stitching
>>>
>>>
>>>>>>>>>>>segments could be advertised as a single bundle - hence, using
> 
> the
> 
>>>>>>>>>>>advertised link by one LSP does not necessarily take away all
>>>
>>>link's
>>>
>>>
>>>>>>>>>>>bandwidth.
>>>>>>>>>>
>>>>>>>>>>you don't understand the question, it is do we have to consider as
>>>>>>>>>>default behavior that a pre-provisioned is to be "advertized"
>>>>>>>>>
>>>>>>>>>IB>> My point was that I do not see any difference in this respect
>>>>>>>
>>>>>>>between
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>the sticthing FA-LSP (the same layer FA-LSP) and FA-LSP created in
>>>
>>>the
>>>
>>>
>>>>>>>lower
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>layer. Besides, what do you mean by the default behaviour? The fact
>>>>>>>
>>>>>>>whether
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>to advertise//remove FA TE link is a policy driven carefully
> 
> thought
> 
>>>>>>>through
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>decision, a dnagerous one that could potentially destabilize the
>>>>>>>
>>>>>>>network.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>I'd say that the default behaviour is "NOT ADVERTISE" in either
> 
> case.
> 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>now beside the fact that there are techniques to do so what would
> 
> be
> 
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>>purpose of it ? and what it the overhead that such advertisement
>>>
>>>would
>>>
>>>
>>>>>>>>>>create - that can be of course decreased by bundling them -
>>>>>>>>>
>>>>>>>>>IB>> The purpose is exactly the same as for any other FA-LSP - add
>>>>>>>>>flexibility in a particular layer.
>>>>>>>>
>>>>>>>>which flexibility are we expecting here, this "segment" can
>>>
>>>accommodate
>>>
>>>
>>>>>>>>exactly one incoming request -
>>>>>>>
>>>>>>>
>>>>>>>IB>> Disagree - the segment could be a component link within a
> 
> bundle.
> 
>>>>>In
>>>>>
>>>>>
>>>>>
>>>>>>>this case stitching FA TE link may accomodate multiple LSPs
>>>>>>>
>>>>>>>additionally only nodes part of the same
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>area can make use of this advertisement -
>>>>>>>
>>>>>>>
>>>>>>>IB>> Who said that sticthing segments must necessarily terminate on
>>>>>
>>>>>domain
>>>>>
>>>>>
>>>>>
>>>>>>>borders? There could be multiple reasons why a network operator could
>>>>>>>pre-provision (dynamically or statically) LSP segments inside his
>>>>>
>>>>>network
>>>>>
>>>>>
>>>>>
>>>>>>>and advertise them (as bundles or individually) as TE links to be
> 
> used
> 
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>>>specific TE purposes.
>>>>>>
>>>>>>it is exactly these purposes that i am looking for
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>so in fact what it would allow
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>is the possibility to avoid creation of a segment if the edge node
>>>>>>>>receiving the request re-orients its request to the head-end for
> 
> this
> 
>>>>>>>>advertisement
>>>>>>>>                      |
>>>>>>>>example:      ----------D----------
>>>>>>>>           |                     |
>>>>>>>>         - A ---- Segment 1 ---- B -
>>>>>>>>           |                     |
>>>>>>>>            ----------C----------
>>>>>>>>                      |
>>>>>>>>
>>>>>>>>you would have a segment between A-B that could be reached from C
> 
> (the
> 
>>>>>>>>node receiving the incoming request) decides to make use of this
>>>
>>>segment
>>>
>>>
>>>>>>>>to reach B (so you would have C-A-B) but if this was the best path
>>>
>>>why
>>>
>>>
>>>>>>>>not creating directly a segment C-A-B, instead of now having one
>>>
>>>segment
>>>
>>>
>>>>>>>>C-A, the pre-provisioned A-B and probably one on top of it C-A-B ?
>>>>>>>
>>>>>>>
>>>>>>>IB>> See my comment above. I might want to use statically provisioned
>>>>>>>segments. I might want to use nodes that do not have proper signaling
>>>>>>>software.
>>>>>>
>>>>>>what does that mean "proper signaling software"
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>For instance, recall the discussions on P2MP and how we want use
> 
> legacy
> 
>>>>>LSRs
>>>>>
>>>>>
>>>>>
>>>>>>>to be part of P2MP tunnels
>>>>>>
>>>>>>but in this case there is a flag telling capabilities of the nodes in
>>>>>>order to allow for dynamically trigger the segment
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>in case of classical FA-LSP it makes sense to advertize the FA link
>>>>>>>>because it represents a lower region LSP (with usually a given ratio
>>>
>>>of
>>>
>>>
>>>>>>>>unreserved bandwidth that makes worth advertizing the FA link) but
> 
> in
> 
>>>>>>>>case of a segment i do have some difficulties to excatly see where
>>>
>>>this
>>>
>>>
>>>>>>>>flexibility would deliver ?
>>>>>>>
>>>>>>>
>>>>>>>IB>> Again, if you imagine that several parallel sticthing segments
> 
> are
> 
>>>>>>>advertised as as single FA, how it would be different from the
>>>
>>>bandwidth
>>>
>>>
>>>>>>>usage point of view compared to advertising lower layer FA ?
>>>>>>
>>>>>>issues are different - FAs are used in manner to preferentially
> 
> attract
> 
>>>>>>over them because - i am still looking for the reason for attracting
>>>>>>over a bundle
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>In fact it would be even more useful, because in case of lower layer
> 
> FA
> 
>>>>>you need also
>>>>>
>>>>>
>>>>>
>>>>>>>to advertise termination/adaptation capabilities, while in case of
>>>>>
>>>>>stitching
>>>>>
>>>>>
>>>>>
>>>>>>>FA no addaptation is required.
>>>>>>
>>>>>>by the way you don't seem to see the issue that i am pointing out, so
>>>>>>probably there is a need to go in more detailed examples before
> 
> drawing
> 
>>>>>>the above confusing conclusion
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Igor
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>thanks,
>>>>>>>>- dimitri.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>thanks,
>>>>>>>>>>- dimitri.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>a more technical point is related to the definition of an FA
> 
> LSP
> 
>>>>>>>which
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>per LSP-Hierarchy mandates crossing LSP region border: the
>>>
>>>head-end
>>>
>>>
>>>>>>>and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>tail-end switching capability represent the SC of the resulting
>>>
>>>TE
>>>
>>>
>>>>>>>link
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>while intermediate node terminates the SC corr. to the
> 
> switching
> 
>>>>>type
>>>>>
>>>>>
>>>>>
>>>>>>>>>of
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a
>>>>>
>>>>>PSC-2
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>capable network with first and last link being [PSC-1,PSC-2]
> 
> and
> 
>>>>>>>>>>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would
>>>
>>>have
>>>
>>>
>>>>>>>now
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>the creation of a [PSC-1,PSC-1] link with first and last link
>>>
>>>being
>>>
>>>
>>>>>>>>>>>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region
>>>
>>>border
>>>
>>>
>>>>>>>>>>>>>crossing anymore - so here the question is about definition and
>>>>>>>>>>>>>detailing the triggers
>>>>>>>>>>>>
>>>>>>>>>>>>AA--------> As far as trigger for setting up an LSP segment is
>>>>>>>>>
>>>>>>>>>concerned,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>I agree that there is no longer the notion of "crossing region
>>>>>>>>>>>>boundaries". I realize that the document doesn't discuss this,
>>>>>>>>>
>>>>>>>>>especially
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>given that we are doing other comparisons with FA LSPs. So, I
> 
> will
> 
>>>>>add
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>this discussion in the next revision. I think in case of LSP
>>>
>>>segment
>>>
>>>
>>>>>>>the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>trigger for LSP segment setup would come from a) successful
>>>>>
>>>>>switching
>>>>>
>>>>>
>>>>>
>>>>>>>>>type
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>and switching capability match and b) some local policy on the
>>>
>>>node
>>>
>>>
>>>>>>>>>which
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>dictates the setting up of an LSP segment.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and
> 
> could
> 
>>>be
>>>
>>>
>>>>>>>>>>>challenged in many ways. FA LSP is, generally speaking, created
> 
> on
> 
>>>a
>>>
>>>
>>>>>>>>>layer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>boundary rather than on region boundary: nothing prevents
> 
> creating
> 
>>>a
>>>
>>>
>>>>>>>VC4
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>FA
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>LSP that starts and stops in the middle of TDM region to carry
>>>>>
>>>>>several
>>>>>
>>>>>
>>>>>
>>>>>>>>>VC12
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>LSPs. Furthermore, stitching FA is a special case of FA when it
> 
> is
> 
>>>>>used
>>>>>
>>>>>
>>>>>
>>>>>>>>>by
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>LSPs of the same layer as one where the FA-LSP was created. As
> 
> for
> 
>>>>>>>>>triggers,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>there could be multiple ones for setting up/tearing down
> 
> stitching
> 
>>>>>>>>>FA-LSPs:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>configuration, receiving setup request for inter-domain LSP,
> 
> other
> 
>>>>>>>>>policies.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>Igor
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>More on a) later.
>>>>>>>>>>>>
>>>>>>>>>>>>thanks,
>>>>>>>>>>>>-arthi
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>.
>>>>>>>>>
>>>>>>>>
>>>>>>>.
>>>>>>>
>>>>>>
>>>>>.
>>>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 18 Feb 2005 20:22:02 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
Date: Fri, 18 Feb 2005 15:20:45 -0500

--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-03.txt
	Pages		: 29
	Date		: 2005-2-18
	
The current 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-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-te-exclude-route-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-te-exclude-route-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-te-exclude-route-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-rsvp-te-exclude-route-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: Fri, 18 Feb 2005 13:54:24 +0000
Message-ID: <005e01c515c0$ff7cf2d0$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, <[e-mail]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Date: Fri, 18 Feb 2005 08:51:50 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dimitri,

Looks like we are talking different languages.

The discussion was inititiated by your question: is it worth advertisng
stitching segments as FAs. At the same time you keep complaining that I
bring PCE into the discussion. Who in your opinion is the user of such
advertising apart from PCE?

I am saying that segments provisioned by the management plane could be used
in e2e LSP dynamic provisioning and the only way to make it possible is via
stitching. You are saying that this is not stitching because in your opinion
stitching is concerned only with segments dynamically provisioned, and there
is some other mechanism (which you were not specific about) that makes
possible using the statically provisioned segments.

Finally:

> > IB>> Just to be clear. You mentioned the use of advertised node
> > capabilities. My point is that these advertisements are useful for path
> > computation but are of no use for e2e signaling
>
> and so just to be clear if they are not useful for e2e signaling what is
> the purpose of advertising them for this purpose ?
>

Comments like these just knock me off. I always believe that any type of
advertising is being done for the purpose of routing and path computation
but have zero relevance for signaling. Am I not right ? Consider, for
instance, the case when all EROs are fully specified by the user. Can I
signal such LSP? If yes, do I need TED in this case?

Igor


----- Original Message ----- 
From: "dimitri papadimitriou" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>; "Arthi Ayyangar"
<[e-mail]>; <[e-mail]>
Sent: Thursday, February 17, 2005 5:33 PM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt


> igor - see in-line:
>
> [snip]
>
> >>>Your point/question is very simple, which is what does it give to
> >>>advertise stitching segments as FAs, is that correct?
> >>>
> >>>My answers are very simple either:
> >>>
> >>>1) How else are you going to use statically provisioned segments as
part
> >>> of dynamically provisioned end-to-end LSPs ?
> >>
> >>you ask a different question from the initial issue because advertize a
> >>TE link was possible today without using stitching, however this issue
> >>also depends what do you mean by statical provisioning ?
> >
> > IB>> I have segments that are provisioned/owned by the management plane
>
> exactly - there is no *LSP stitching* anymore - we discuss about control
> plane operations (the intermediate segment is an entity owned by the
> control plane)
>
> note: by the way, operation you are referring to is supported today
> (without the procedures described as part of this document because this
> has nothing to do with stitching)
>
> >>>2) How else you can accomplish a transition strategy when some of the
> >>> nodes that are going to be involved in end-to-end dynamically
provisioned LSPs
> >>> do not have proper signaling software?
> >>
> >>and i did ask what is the point in applying LSP segment signaling on
> >>segment that "do not have proper signaling software"
> >
> > IB>> The point is that transit nodes of the segments do not participate
and
> > hence do not have to support e2e signaling
>
> well i think we should then determine the working assumptions here,
> intermediate nodes part of an LSP segment are GMPLS nodes as any other,
> otherwise the segment could itself not be setup (stitching is just a way
> to leave control to the head-end of the segment but there are no
> specific assumptions made in terms of signaling capabilities for the
> intermediate nodes, they are assumed to be GMPLS signaling capable nodes
> as any other)
>
> >>>The specific example is using LSRs that
> >>>do not support p2mp signaling as transit nodes in p2mp LSPs. Your point
> >>>about advertising of node capabilities is relevant only for routing -
> >>>the PCE computing p2mp tree may take in consideration the advertised
node
> >>>capabilities and assume that stitching segments may be created
> >>>dynamically if needed.
> >>
> >>just to be clear the PCE discussion is completely outside of the present
> >>discussion - afaik the working group has (still) to provide requirements
> >>for the PCE wg -
> >
> > IB>> Just to be clear. You mentioned the use of advertised node
> > capabilities. My point is that these advertisements are useful for path
> > computation but are of no use for e2e signaling
>
> and so just to be clear if they are not useful for e2e signaling what is
> the purpose of advertising them for this purpose ?
>
> >>>What if I don't want them to be dynamically created and rather
> >>>have them pre-provisioned to spead up the process of p2mp tunnel setup
> >>>and decrease blocking probability?
> >>
> >>not sure that compared to the global complexity of computing the tree
> >>this is going to be a significant improvement, but if you have the
> >>possibility to determine the bandwidth on the corr. segments i don't see
> >>here how you decrease the blocking probability (afaik propagation of
> >>segment related information is equivalent to the corresponding links
> >>advertisement)
> >
> > IB>> Dynamic establishment of the stitching segments may fail
>
> not sure to catch your point, if you think a p2p LSP establishment may
> fail not sure it is wise to start thinking about p2mp LSP establishment
> - on the other side pre-provisioning of the segment if not guaranteed
> within certain limits can not guarantee that you would be able to stitch
> it afterwards (refresh, etc.)
>
> >>>3) What if I want to attract certain LSPs  to use pre-provisioned
> >>> segments even if the overall cost of such LSPs would be higher than if
they would
> >>>take paths computed without consideration of these segments, but it is
> >>>desirable for the LSPs to use the segments anyway. Exanple: the
segments
> >>>are provisioned to satisfy wavelength continuity constraint and I don't
have
> >>>PCE that can perform path computation with such contraint on path
segments
> >>>between points of OEO.
> >>
> >>as said above it would desirable to leave PCE aspects outside of the
> >>picture, but this application is really interesting because on one side
> >>i thought we had the label set to solve this issue (note: that even if a
> >>path is pre-computed explicit label control can be used to provision the
> >>segment between converting points - don't PCEs for this)
> >
> > IB>> First, this is just an example of the situation when I want
> > pre-provisioned segments to be used in e2e LSP provisioning.
> > Second, satisfying the wavelength continuity constraint takes much more
> > than just using the label set. You need to have:
> > a) information about all lambdas in all isles of transparency;
>
> this may be the case but once known explicit label control on each link
> is enough to assume continuity
>
> > b) very complex PCE that is capable of computing optimal path(s) that
use
> > the same wavelength on all links within each OEO-OEO segments satisfying
all
> > other optical constraints.
>
> PCE, again PCE, but the computation of such path was possible well
> before even the term did exist - you mix the computation with the access
> to the computation result -
>
> > It is much simpler to pre-provision such OEO-OEO segments and advertise
them
> > as TE links, than a simple PCE would do the job.
>
> it is the term "pre-provision" that causes the main issue here, one
> dimension of the problem is simplified but how many are getting
> complexified ? and where is the evaluation of this trade-off ?
>
> > Igor
> >
> >
> >>on the other hand is how much possible pre-provisioned segments - so
> >>overhead - are now going to be advertised if the traffic demand is
> >>unknown ? and on the other hand, if all traffic matrix is known
> >>beforehand is there any rationale to create these segments instead of
> >>directly provisioning
> >>
> >>it is interesting to see that you are populating this discussion with
> >>PCE application - i would be more in favor in leaving the possibility of
> >>advertising segments once a clear set is being identified rather than
> >>the other way around
> >>
> >>
> >>>Igor
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>----- Original Message ----- 
> >>>From: "dimitri papadimitriou" <[e-mail]>
> >>>To: "Igor Bryskin" <[e-mail]>
> >>>Cc: <[e-mail]>; "Arthi Ayyangar"
> >>><[e-mail]>; <[e-mail]>
> >>>Sent: Thursday, February 17, 2005 1:19 PM
> >>>Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
> >>>
> >>>
> >>>
> >>>
> >>>>Igor Bryskin wrote:
> >>>>
> >>>>
> >>>>
> >>>>>dimitri, see in line.
> >>>>>
> >>>>>----- Original Message ----- 
> >>>>>From: "dimitri papadimitriou" <[e-mail]>
> >>>>>To: "Igor Bryskin" <[e-mail]>
> >>>>>Cc: <[e-mail]>; "Arthi Ayyangar"
> >>>>><[e-mail]>; <[e-mail]>
> >>>>>Sent: Thursday, February 17, 2005 11:40 AM
> >>>>>Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>igor - see in-line
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>>Please see my replies (AA--->) inline.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>---------> An LSP segment may be created either by
configuration
> >>>
> >>>or
> >>>
> >>>
> >>>>>>>>>>>>due to arrival of an e2e LSP setup request itself. Similar to
an
> >>>
> >>>FA,
> >>>
> >>>
> >>>>>an
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>LSP segment may or may not be advertised as a TE link. But, if
> >>>>>>>>>>>>pre-created, it could be advertised, in which case other nodes
> >
> > may
> >
> >>>>>>>>>>>>compute a path over it.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Why would you want to or not want to advertise an FA ?
> >>>>>>>>>>>
> >>>>>>>>>>>i understand the point on pre-created <-> advertised but this
> >>>>>
> >>>>>knowledge
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>may be useful for nodes part of the same area (not for nodes
> >>>
> >>>external
> >>>
> >>>
> >>>>>>>>>>>to this area)
> >>>>>>>>>>
> >>>>>>>>>>AA -------> Absolutely ...this definitely cannot be advertised
> >>>
> >>>outside
> >>>
> >>>
> >>>>>>>>>>the area (domain). I think this has been explicitly mentioned.
> >>>>>>>>>>
> >>>>>>>>>>so in case a node for inst. advertises three terminating
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>links with PSC-2 (one of these being the LSP segment) then a
> >>>
> >>>another
> >>>
> >>>
> >>>>>>>>>>>node (part of the same area) receiving an incoming multi-area
> >
> > PSC-2
> >
> >>>>>LSP
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>request may start making use of this segment to join the next
> >>>
> >>>border,
> >>>
> >>>
> >>>>>>>>>>>therefore advertisement of the LSP segment may create a
multi-hop
> >>>>>>>>>>>condition, but now once used relevance of the existence of the
> >>>>>
> >>>>>segment
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>is not a useful information (for the area) as there is no
> >>>
> >>>possibility
> >>>
> >>>
> >>>>>>>>>>>to make re-use of it except when the end-to-end LSP is torn
down
> >>>>>>>>>>
> >>>>>>>>>>AA----------> I understand your point that once an LSP has been
> >>>>>
> >>>>>admitted
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>into an LSP segment it is no longer usable by other nodes in
that
> >>>>>
> >>>>>area.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>But would you rather stop advertising the link at this point, if
> >
> > you
> >
> >>>>>>>>>>were previously advertising it ? Don't you think that is a big
> >>>
> >>>hammer
> >>>
> >>>
> >>>>>? E.g.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>how would a head end which has indeed computed a path over that
> >
> > LSP
> >
> >>>>>>>>>>segment differentiate this event from an LSP segment down event
> >>>
> >>>where
> >>>
> >>>
> >>>>>>>>>>the link is deleted from the database ? So, all the document
says
> >>>>>
> >>>>>today is
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>that you set the unreserved bw on the LSP segment to zero. The
> >
> > idea
> >
> >>>is
> >>>
> >>>
> >>>>>>>>>>to still let other nodes know that the link exists but is
> >
> > unusable.
> >
> >>>It
> >>>
> >>>
> >>>>>is
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>not different from a FA-LSP being consumed...in that case we
don't
> >>>>>
> >>>>>stop
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>advertising the FA (if we were doing so previously), right ?
> >>>>>>>>>
> >>>>>>>>>IB>> Completley agree with Arthi. Besides, several parallel
> >
> > stitching
> >
> >>>>>>>>>segments could be advertised as a single bundle - hence, using
the
> >>>>>>>>>advertised link by one LSP does not necessarily take away all
> >
> > link's
> >
> >>>>>>>>>bandwidth.
> >>>>>>>>
> >>>>>>>>you don't understand the question, it is do we have to consider as
> >>>>>>>>default behavior that a pre-provisioned is to be "advertized"
> >>>>>>>
> >>>>>>>IB>> My point was that I do not see any difference in this respect
> >>>>>
> >>>>>between
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>the sticthing FA-LSP (the same layer FA-LSP) and FA-LSP created in
> >
> > the
> >
> >>>>>lower
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>layer. Besides, what do you mean by the default behaviour? The fact
> >>>>>
> >>>>>whether
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>to advertise//remove FA TE link is a policy driven carefully
thought
> >>>>>
> >>>>>through
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>decision, a dnagerous one that could potentially destabilize the
> >>>>>
> >>>>>network.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>I'd say that the default behaviour is "NOT ADVERTISE" in either
case.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>now beside the fact that there are techniques to do so what would
be
> >>>
> >>>the
> >>>
> >>>
> >>>>>>>>purpose of it ? and what it the overhead that such advertisement
> >
> > would
> >
> >>>>>>>>create - that can be of course decreased by bundling them -
> >>>>>>>
> >>>>>>>IB>> The purpose is exactly the same as for any other FA-LSP - add
> >>>>>>>flexibility in a particular layer.
> >>>>>>
> >>>>>>which flexibility are we expecting here, this "segment" can
> >
> > accommodate
> >
> >>>>>>exactly one incoming request -
> >>>>>
> >>>>>
> >>>>>IB>> Disagree - the segment could be a component link within a
bundle.
> >>>
> >>>In
> >>>
> >>>
> >>>>>this case stitching FA TE link may accomodate multiple LSPs
> >>>>>
> >>>>>additionally only nodes part of the same
> >>>>>
> >>>>>
> >>>>>
> >>>>>>area can make use of this advertisement -
> >>>>>
> >>>>>
> >>>>>IB>> Who said that sticthing segments must necessarily terminate on
> >>>
> >>>domain
> >>>
> >>>
> >>>>>borders? There could be multiple reasons why a network operator could
> >>>>>pre-provision (dynamically or statically) LSP segments inside his
> >>>
> >>>network
> >>>
> >>>
> >>>>>and advertise them (as bundles or individually) as TE links to be
used
> >>>
> >>>for
> >>>
> >>>
> >>>>>specific TE purposes.
> >>>>
> >>>>it is exactly these purposes that i am looking for
> >>>>
> >>>>
> >>>>
> >>>>>so in fact what it would allow
> >>>>>
> >>>>>
> >>>>>
> >>>>>>is the possibility to avoid creation of a segment if the edge node
> >>>>>>receiving the request re-orients its request to the head-end for
this
> >>>>>>advertisement
> >>>>>>                       |
> >>>>>>example:      ----------D----------
> >>>>>>            |                     |
> >>>>>>          - A ---- Segment 1 ---- B -
> >>>>>>            |                     |
> >>>>>>             ----------C----------
> >>>>>>                       |
> >>>>>>
> >>>>>>you would have a segment between A-B that could be reached from C
(the
> >>>>>>node receiving the incoming request) decides to make use of this
> >
> > segment
> >
> >>>>>>to reach B (so you would have C-A-B) but if this was the best path
> >
> > why
> >
> >>>>>>not creating directly a segment C-A-B, instead of now having one
> >
> > segment
> >
> >>>>>>C-A, the pre-provisioned A-B and probably one on top of it C-A-B ?
> >>>>>
> >>>>>
> >>>>>IB>> See my comment above. I might want to use statically provisioned
> >>>>>segments. I might want to use nodes that do not have proper signaling
> >>>>>software.
> >>>>
> >>>>what does that mean "proper signaling software"
> >>>>
> >>>>
> >>>>
> >>>>>For instance, recall the discussions on P2MP and how we want use
legacy
> >>>
> >>>LSRs
> >>>
> >>>
> >>>>>to be part of P2MP tunnels
> >>>>
> >>>>but in this case there is a flag telling capabilities of the nodes in
> >>>>order to allow for dynamically trigger the segment
> >>>>
> >>>>
> >>>>
> >>>>>>in case of classical FA-LSP it makes sense to advertize the FA link
> >>>>>>because it represents a lower region LSP (with usually a given ratio
> >
> > of
> >
> >>>>>>unreserved bandwidth that makes worth advertizing the FA link) but
in
> >>>>>>case of a segment i do have some difficulties to excatly see where
> >
> > this
> >
> >>>>>>flexibility would deliver ?
> >>>>>
> >>>>>
> >>>>>IB>> Again, if you imagine that several parallel sticthing segments
are
> >>>>>advertised as as single FA, how it would be different from the
> >
> > bandwidth
> >
> >>>>>usage point of view compared to advertising lower layer FA ?
> >>>>
> >>>>issues are different - FAs are used in manner to preferentially
attract
> >>>>over them because - i am still looking for the reason for attracting
> >>>>over a bundle
> >>>>
> >>>>
> >>>>
> >>>>>In fact it would be even more useful, because in case of lower layer
FA
> >>>
> >>>you need also
> >>>
> >>>
> >>>>>to advertise termination/adaptation capabilities, while in case of
> >>>
> >>>stitching
> >>>
> >>>
> >>>>>FA no addaptation is required.
> >>>>
> >>>>by the way you don't seem to see the issue that i am pointing out, so
> >>>>probably there is a need to go in more detailed examples before
drawing
> >>>>the above confusing conclusion
> >>>>
> >>>>
> >>>>
> >>>>>Igor
> >>>>>
> >>>>>
> >>>>>
> >>>>>>thanks,
> >>>>>>- dimitri.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>thanks,
> >>>>>>>>- dimitri.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>a more technical point is related to the definition of an FA
LSP
> >>>>>
> >>>>>which
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>per LSP-Hierarchy mandates crossing LSP region border: the
> >
> > head-end
> >
> >>>>>and
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>tail-end switching capability represent the SC of the resulting
> >
> > TE
> >
> >>>>>link
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>while intermediate node terminates the SC corr. to the
switching
> >>>
> >>>type
> >>>
> >>>
> >>>>>>>of
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a
> >>>
> >>>PSC-2
> >>>
> >>>
> >>>>>>>>>>>capable network with first and last link being [PSC-1,PSC-2]
and
> >>>>>>>>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would
> >
> > have
> >
> >>>>>now
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>the creation of a [PSC-1,PSC-1] link with first and last link
> >
> > being
> >
> >>>>>>>>>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region
> >
> > border
> >
> >>>>>>>>>>>crossing anymore - so here the question is about definition and
> >>>>>>>>>>>detailing the triggers
> >>>>>>>>>>
> >>>>>>>>>>AA--------> As far as trigger for setting up an LSP segment is
> >>>>>>>
> >>>>>>>concerned,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>I agree that there is no longer the notion of "crossing region
> >>>>>>>>>>boundaries". I realize that the document doesn't discuss this,
> >>>>>>>
> >>>>>>>especially
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>given that we are doing other comparisons with FA LSPs. So, I
will
> >>>
> >>>add
> >>>
> >>>
> >>>>>>>>>>this discussion in the next revision. I think in case of LSP
> >
> > segment
> >
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>trigger for LSP segment setup would come from a) successful
> >>>
> >>>switching
> >>>
> >>>
> >>>>>>>type
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>and switching capability match and b) some local policy on the
> >
> > node
> >
> >>>>>>>which
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>dictates the setting up of an LSP segment.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and
could
> >
> > be
> >
> >>>>>>>>>challenged in many ways. FA LSP is, generally speaking, created
on
> >
> > a
> >
> >>>>>>>layer
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>boundary rather than on region boundary: nothing prevents
creating
> >
> > a
> >
> >>>>>VC4
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>FA
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>LSP that starts and stops in the middle of TDM region to carry
> >>>
> >>>several
> >>>
> >>>
> >>>>>>>VC12
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>LSPs. Furthermore, stitching FA is a special case of FA when it
is
> >>>
> >>>used
> >>>
> >>>
> >>>>>>>by
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>LSPs of the same layer as one where the FA-LSP was created. As
for
> >>>>>>>
> >>>>>>>triggers,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>there could be multiple ones for setting up/tearing down
stitching
> >>>>>>>
> >>>>>>>FA-LSPs:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>configuration, receiving setup request for inter-domain LSP,
other
> >>>>>>>
> >>>>>>>policies.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>Igor
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>More on a) later.
> >>>>>>>>>>
> >>>>>>>>>>thanks,
> >>>>>>>>>>-arthi
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>.
> >>>>>>>
> >>>>>>
> >>>>>.
> >>>>>
> >>>>
> >>>
> >>>.
> >>>
> >
> >
> >
> >
> > .
> >
>




Envelope-to: [e-mail]
Delivery-date: Fri, 18 Feb 2005 00:51:31 +0000
Message-ID: <05e501c51554$19617260$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Philip Crocker" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Date: Fri, 18 Feb 2005 00:49:36 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Phil

> > > 1)  Firstly the question.  In section 1 (the 4th
> > > paragraph), the text
> > > indicates that SONET / SDH extensions to link verification and link
> > > property correlation require both section 3 and section 4 (Trace
> > > Monitoring).  However, it seems to me that the extensions described
> > > in section 3 alone are enough to perform link verification and link
> > > property correlation for SONET / SDH links.  Specifically, though
> > > the TraceMonitor<xx> and TraceMismatch messages defined in section
> > > 4 can be used to perform an external verification of SONET / SDH
> > > links, it is not clear why these messages are necessary in addition
> > > to the LMP link verification procedure (as extended by section 3).
> > > Could you please explain this?
> >
> > It is slightly unclear what you are asking.
> > Note that the Trace object is defined in section 4 and is
> > required for J0, J1 and J2 Test procedures as decribed in
> > section 3. Thus, both sections 3 and 4 are necessary for the
> > new link verification procedures.
> >
> > It is possible that you are baulking at "This requires a new
> > trace monitoring function that is also discussed in this
> > document." "Requires" may be slightly too strong.

> [PJC]
> I agree that the <Trace> object defined in section 4 is
> required by section 3.

OK. Sounded like you were saying that it seemed to you that the extensions
described in section 3 alone are enough to perform link verification and
link property correlation for SONET / SDH links.

> However, section 1 says that the 'trace monitoring function'
> is required by LMP SONET / SDH specific link verification
> and link correlation.  I understand 'trace monitoring function'
> to refer to the new TraceMonitor messages (and not just the
> Trace object), and hence my confusion.

Yup. As I say, "required" is too strong.

> If as you imply, the only part of section 4 required
> for LMP SONET / SDH specific link verification and
> link correlation is the Trace object, then I would
> recommend the text in section 1 be changed to reduce
> confusion.

We will try to catch this in authors' 48 hours.

> In any case, I remain unsure of the background and
> proposed uses of the TraceMonitor and other messages
> defined in section 4 - can you help here?

The motivation for trace monitoring is unchanged from overhead monitoring
in TDM. The purpose of the messages in LMP is to allow LMP control of this
feature. The net result is better fault management.

> Assuming there are valid reasons for this function I think
> we should beef up the introductory text in section 1 to
> describe them.

The ship has sailed; and besides, if you come to this draft with a
reasonable understanding of TDM (which you should given section 2) this is
not an issue.

> > > 2)  Secondly, I have a minor comment on section 4.  I
> > > understand from
> > > section 4.1.1 that a TraceMonitor message should contain a single
> > > <TRACE> object.  However, section 4.1.2 can be read to imply that a
> > > TraceMonitor message can contain more than one <TRACE> object.  Can
> > > I suggest the following replacement text for section 4.1.2?
> > >
> > >   The TraceMonitorAck message (Message Type TBA by IANA) is used to
> > >   acknowledge receipt of the TraceMonitor message and indicate that
> > >   the TRACE object in the TraceMonitor message have been received
> > >   and processed correctly (i.e. no Trace Mismatch).
> >
> > There is absolutely nothing wrong with the existing text.
> > "All of the TRACE Objects in the TraceMonitor message" is
> > perfectly fine when there is only one such object allowed.
> > Leaving the text as it is reduces any changes should the
> > number of Test objects on a TraceMonitor ever be increased.
>
>[PJC]
> I agree there's nothing strictly wrong with the existing text,

Good.

> but it's misleading to have one part of the document state
> there is exactly one object, and then have another referring
> to multiple objects.

I'm sorry you were mislead.

> I would vote to remove all ambiguity and change the text.

We don't vote :-)

> Yes, I agree that if the number is increased in the future,
> the wording has to be changed, but I believe the improved
> clarity makes it worth it.  However, this isn't an important issue
> and I don't feel strongly about this.

Excellent.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 18 Feb 2005 00:07:47 +0000
Message-ID: <052701c5154d$d63fd5e0$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Zafar Ali" <[e-mail]>, <[e-mail]>
Subject: Re: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Thu, 17 Feb 2005 21:01:12 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks, Zafar.

Comments in line.

Adrian

> > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace
> > ful-shutdown-00.txt was discussed at the meeting in
> > Washington DC, and one of the questions raised was whether or
> > not we already had (multiple!) mechanisms capable of
> > performing the function described in the draft.
> >
> > Kireeti quite rightly suggested that we step back and make
> > sure we understand the requirements. This is my take on those
> > requirements and I would appreciate it if the authors of the
> > draft joined in and other people on the list commented.
> >
> > We wish to manage a link that needs to be taken out of
> > service in some way (data plane and/or control plane will be
> > disrupted). The link concerned has active LSPs and we wish to
> > offer upstream LSRs (in particular the ingress) the
> > opportunity to use make-before-break to re-route the LSPs.
> >
> > In order to achieve this, we need to communicate to the
> > upstream nodes. Should we choose signaling or routing? Are
> > there benefits that mean we should use both, or should we
> > limit to just one?
>
> Yes, we need both.

Well, I was kind of hoping for a reasoned debate :-)

> > There is another aspect to be considered. Should we also
> > attempt to protect new path computations from selecting the
> > link that will be taken out of service?
>
> Yes,
>
> > How should we consider the case of a node (data plane and/or
> > control plane) being taken out of service?
>
> Yes,
>
> >Is a node simply a  collection of links?
>
> Yes, during graceful shutdown period.

So does that mean you would like to advertise the withdrawal of 10,000
links, or the withdrawal of one node. Recall that all link advertisement
is associated with the node, so node withdrawal is meaningful.

> > If a component link of a bundle is being taken out of service
> > (and assuming other component links are available) is this
> > just an issue for the adjacent nodes or does it need to be
> > communicated more widely?
>
> Let head end do the mb4b,

Presumably this would not be true if the bundle was advertised as having
some form of link protection (and the ocmponent links provided this
protection).

> > If the downstream node decides to
> > take the component link out of service, how does it inform
> > the upstream node?

You missed this one.

> > Does it matter whether it is the control plane or the data
> > plane that will be taken out of service?
>
> Yes, if data plane is going OOS, we are loosing traffic and motivation
> behind mb4b to reduce traffic hit is lost.

Let me rephrase the question.
If I know that the control plane is going OOS and I want to continue to be
able to manage my LSPs I will want to move them to LSRs that will continue
to have an active control plane. The data plane through the impacted LSRs
may continue to be active (and therefore could continue to carry traffic).

Is this an important case? If so, do we manage it in the same way?

> > Opinions please.
> >
> > I would like to see these issues and their answers captured
> > clearly in a requirements section of any draft. Would the
> > authors of draft-ali-ccamp-mpls-graceful-shutdown-00.txt
> > be willing to take that on even though the end result might
> > be that procedures other than those they suggest will be selected?
>
> Sure, we plan to revised the ID based on this survey as well as comments
> from the WG for the upcoming IETF.
>
> Thanks again Adrian for your suggestion and putting this together.
>
> Thanks
>
> Regards... Zafar
>
> >
> > Adrian
> >
> >
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 22:35:44 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Zafar Ali'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Thu, 17 Feb 2005 14:35:17 -0800
Message-ID: <00c501c51540$f4ac25e0$4b3ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Zafar,
First, I'd like to point out that your draft has expired; thought you =
might
want to put a quick version up.
Some comments inline and more generally about the draft.
Thanks a lot,
Richard.
--
- in the text, you say: MAY NOT. This is not defined.=20

- Discussing PCE in this draft seems to be out of place. This draft is =
sent
to ccamp and should not specify what a PCE node has to do.

- This is especially confusing since you say that a PCE is receiving =
RSVP
Path error messages. This implies somebody sent it to the PCE. But you =
have
defined communication from the node where shutdown occurs to the =
ingress.
How does the PCE know about this message?

- You talk in the draft about FRR but FRR does not apply to all types of
switching in GMPLS. Please reflect that in your text to say: "In the =
case of
PSC, ..."

- You mention FSC, LSC and PSC. Is it your objective not to address L2SC =
and
TDM?

- I'd also like to ask you how you decommission a bundle? Does the =
headend
of that bundle have the responsibility of telling each headend of each
component about the shutdown?
E.g. let's say I'm shutting down a link in a SONET box that has a
server-layer circuit (say an STS-3c) that is carrying Ethernet as the =
client
layer. Who tells the Ethernet "headend" about the shutdown?

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Zafar Ali
> Sent: Tuesday, February 15, 2005 10:34 PM
> To: 'Adrian Farrel'; [e-mail]
> Subject: Summary [was: RE: Starting a discussion on graceful shutdown]
>=20
>=20
> Hi Adrian,=20
>=20
> Thanks for putting this email together. In the following I=20
> have tried to
> summarize the discussion we had on this thread and next steps.=20
>=20
> Thanks
>=20
> Regards... Zafar=20
>=20
> > -----Original Message-----
> > From: [e-mail]=20
> > [mailto:[e-mail]] On Behalf Of Adrian Farrel
> > Sent: Tuesday, December 07, 2004 10:39 AM
> > To: [e-mail]
> > Subject: Starting a discussion on graceful shutdown
> >=20
> > Hi,
> >=20
> > http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace
> > ful-shutdown-00.txt was discussed at the meeting in=20
> > Washington DC, and one of the questions raised was whether or=20
> > not we already had (multiple!) mechanisms capable of=20
> > performing the function described in the draft.
> >=20
> > Kireeti quite rightly suggested that we step back and make=20
> > sure we understand the requirements. This is my take on those=20
> > requirements and I would appreciate it if the authors of the=20
> > draft joined in and other people on the list commented.
> >=20
> > We wish to manage a link that needs to be taken out of=20
> > service in some way (data plane and/or control plane will be=20
> > disrupted). The link concerned has active LSPs and we wish to=20
> > offer upstream LSRs (in particular the ingress) the=20
> > opportunity to use make-before-break to re-route the LSPs.
> >=20
> > In order to achieve this, we need to communicate to the=20
> > upstream nodes. Should we choose signaling or routing? Are=20
> > there benefits that mean we should use both, or should we=20
> > limit to just one?
>=20
> Yes, we need both.=20
>=20
Can you explain to me the justification for both?=20
I don't think there is no need for routing extensions, since the routing
protocol will stop advertising decommissioned links.=20

Can you also explain the difference between your method and the =
available
SONET mechanisms for shutting down resources?

In section 4, you talk about OSPF/ISIS. Do you mean OSPF-TE/ISIS-TE?=20

> >=20
> > There is another aspect to be considered. Should we also=20
> > attempt to protect new path computations from selecting the=20
> > link that will be taken out of service?
>=20
> Yes,=20

There is a balance between (1) telling ingress LSR's vs. (2) ingress =
LSR's
receiving notification through usual updates. Authors need to justify =
need
and advantage for (1).
>=20
> >=20
> > How should we consider the case of a node (data plane and/or=20
> > control plane) being taken out of service?=20
>=20
> Yes,=20
>=20
> >Is a node simply a=20
> > collection of links?
>=20
> Yes, during graceful shutdown period.=20
>=20
> >=20
> > If a component link of a bundle is being taken out of service=20
> > (and assuming other component links are available) is this=20
> > just an issue for the adjacent nodes or does it need to be=20
> > communicated more widely?=20
>=20
> Let head end do the mb4b,=20
>=20
> > If the downstream node decides to=20
> > take the component link out of service, how does it inform=20
> > the upstream node?
> >=20
> > Does it matter whether it is the control plane or the data=20
> > plane that will be taken out of service?
>=20
> Yes, if data plane is going OOS, we are loosing traffic and motivation
> behind mb4b to reduce traffic hit is lost.=20
>=20
> >=20
> > Opinions please.
> >=20
> > I would like to see these issues and their answers captured=20
> > clearly in a requirements section of any draft. Would the=20
> > authors of draft-ali-ccamp-mpls-graceful-shutdown-00.txt
> > be willing to take that on even though the end result might=20
> > be that procedures other than those they suggest will be selected?
>=20
> Sure, we plan to revised the ID based on this survey as well=20
> as comments
> from the WG for the upcoming IETF.=20
>=20
> Thanks again Adrian for your suggestion and putting this together.=20
>=20
> Thanks
>=20
> Regards... Zafar
>=20

> >=20
> > Adrian
> >=20
> >=20
>=20
>=20




Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 22:34:39 +0000
Message-ID: <[e-mail]>
Date: Thu, 17 Feb 2005 23:33:41 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC:  [e-mail], Arthi Ayyangar <[e-mail]>,  [e-mail]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

igor - see in-line:

[snip]

>>>Your point/question is very simple, which is what does it give to
>>>advertise stitching segments as FAs, is that correct?
>>>
>>>My answers are very simple either:
>>>
>>>1) How else are you going to use statically provisioned segments as part
>>> of dynamically provisioned end-to-end LSPs ?
>>
>>you ask a different question from the initial issue because advertize a
>>TE link was possible today without using stitching, however this issue
>>also depends what do you mean by statical provisioning ?
> 
> IB>> I have segments that are provisioned/owned by the management plane

exactly - there is no *LSP stitching* anymore - we discuss about control 
plane operations (the intermediate segment is an entity owned by the 
control plane)

note: by the way, operation you are referring to is supported today 
(without the procedures described as part of this document because this 
has nothing to do with stitching)

>>>2) How else you can accomplish a transition strategy when some of the
>>> nodes that are going to be involved in end-to-end dynamically provisioned LSPs
>>> do not have proper signaling software?
>>
>>and i did ask what is the point in applying LSP segment signaling on
>>segment that "do not have proper signaling software"
> 
> IB>> The point is that transit nodes of the segments do not participate and
> hence do not have to support e2e signaling

well i think we should then determine the working assumptions here, 
intermediate nodes part of an LSP segment are GMPLS nodes as any other, 
otherwise the segment could itself not be setup (stitching is just a way 
to leave control to the head-end of the segment but there are no 
specific assumptions made in terms of signaling capabilities for the 
intermediate nodes, they are assumed to be GMPLS signaling capable nodes 
as any other)

>>>The specific example is using LSRs that
>>>do not support p2mp signaling as transit nodes in p2mp LSPs. Your point
>>>about advertising of node capabilities is relevant only for routing -
>>>the PCE computing p2mp tree may take in consideration the advertised node
>>>capabilities and assume that stitching segments may be created
>>>dynamically if needed.
>>
>>just to be clear the PCE discussion is completely outside of the present
>>discussion - afaik the working group has (still) to provide requirements
>>for the PCE wg -
> 
> IB>> Just to be clear. You mentioned the use of advertised node
> capabilities. My point is that these advertisements are useful for path
> computation but are of no use for e2e signaling

and so just to be clear if they are not useful for e2e signaling what is 
the purpose of advertising them for this purpose ?

>>>What if I don't want them to be dynamically created and rather
>>>have them pre-provisioned to spead up the process of p2mp tunnel setup
>>>and decrease blocking probability?
>>
>>not sure that compared to the global complexity of computing the tree
>>this is going to be a significant improvement, but if you have the
>>possibility to determine the bandwidth on the corr. segments i don't see
>>here how you decrease the blocking probability (afaik propagation of
>>segment related information is equivalent to the corresponding links
>>advertisement)
> 
> IB>> Dynamic establishment of the stitching segments may fail

not sure to catch your point, if you think a p2p LSP establishment may 
fail not sure it is wise to start thinking about p2mp LSP establishment 
- on the other side pre-provisioning of the segment if not guaranteed 
within certain limits can not guarantee that you would be able to stitch 
it afterwards (refresh, etc.)

>>>3) What if I want to attract certain LSPs  to use pre-provisioned
>>> segments even if the overall cost of such LSPs would be higher than if they would
>>>take paths computed without consideration of these segments, but it is
>>>desirable for the LSPs to use the segments anyway. Exanple: the segments
>>>are provisioned to satisfy wavelength continuity constraint and I don't have
>>>PCE that can perform path computation with such contraint on path segments
>>>between points of OEO.
>>
>>as said above it would desirable to leave PCE aspects outside of the
>>picture, but this application is really interesting because on one side
>>i thought we had the label set to solve this issue (note: that even if a
>>path is pre-computed explicit label control can be used to provision the
>>segment between converting points - don't PCEs for this)
> 
> IB>> First, this is just an example of the situation when I want
> pre-provisioned segments to be used in e2e LSP provisioning.
> Second, satisfying the wavelength continuity constraint takes much more
> than just using the label set. You need to have:
> a) information about all lambdas in all isles of transparency;

this may be the case but once known explicit label control on each link 
is enough to assume continuity

> b) very complex PCE that is capable of computing optimal path(s) that use
> the same wavelength on all links within each OEO-OEO segments satisfying all
> other optical constraints.

PCE, again PCE, but the computation of such path was possible well 
before even the term did exist - you mix the computation with the access 
to the computation result -

> It is much simpler to pre-provision such OEO-OEO segments and advertise them
> as TE links, than a simple PCE would do the job.

it is the term "pre-provision" that causes the main issue here, one 
dimension of the problem is simplified but how many are getting 
complexified ? and where is the evaluation of this trade-off ?

> Igor
> 
> 
>>on the other hand is how much possible pre-provisioned segments - so
>>overhead - are now going to be advertised if the traffic demand is
>>unknown ? and on the other hand, if all traffic matrix is known
>>beforehand is there any rationale to create these segments instead of
>>directly provisioning
>>
>>it is interesting to see that you are populating this discussion with
>>PCE application - i would be more in favor in leaving the possibility of
>>advertising segments once a clear set is being identified rather than
>>the other way around
>>
>>
>>>Igor
>>>
>>>
>>>
>>>
>>>
>>>----- Original Message ----- 
>>>From: "dimitri papadimitriou" <[e-mail]>
>>>To: "Igor Bryskin" <[e-mail]>
>>>Cc: <[e-mail]>; "Arthi Ayyangar"
>>><[e-mail]>; <[e-mail]>
>>>Sent: Thursday, February 17, 2005 1:19 PM
>>>Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
>>>
>>>
>>>
>>>
>>>>Igor Bryskin wrote:
>>>>
>>>>
>>>>
>>>>>dimitri, see in line.
>>>>>
>>>>>----- Original Message ----- 
>>>>>From: "dimitri papadimitriou" <[e-mail]>
>>>>>To: "Igor Bryskin" <[e-mail]>
>>>>>Cc: <[e-mail]>; "Arthi Ayyangar"
>>>>><[e-mail]>; <[e-mail]>
>>>>>Sent: Thursday, February 17, 2005 11:40 AM
>>>>>Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>igor - see in-line
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>Please see my replies (AA--->) inline.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>---------> An LSP segment may be created either by configuration
>>>
>>>or
>>>
>>>
>>>>>>>>>>>>due to arrival of an e2e LSP setup request itself. Similar to an
>>>
>>>FA,
>>>
>>>
>>>>>an
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>LSP segment may or may not be advertised as a TE link. But, if
>>>>>>>>>>>>pre-created, it could be advertised, in which case other nodes
> 
> may
> 
>>>>>>>>>>>>compute a path over it.
>>>>>>>>>>>>
>>>>>>>>>>>>Why would you want to or not want to advertise an FA ?
>>>>>>>>>>>
>>>>>>>>>>>i understand the point on pre-created <-> advertised but this
>>>>>
>>>>>knowledge
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>may be useful for nodes part of the same area (not for nodes
>>>
>>>external
>>>
>>>
>>>>>>>>>>>to this area)
>>>>>>>>>>
>>>>>>>>>>AA -------> Absolutely ...this definitely cannot be advertised
>>>
>>>outside
>>>
>>>
>>>>>>>>>>the area (domain). I think this has been explicitly mentioned.
>>>>>>>>>>
>>>>>>>>>>so in case a node for inst. advertises three terminating
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>links with PSC-2 (one of these being the LSP segment) then a
>>>
>>>another
>>>
>>>
>>>>>>>>>>>node (part of the same area) receiving an incoming multi-area
> 
> PSC-2
> 
>>>>>LSP
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>request may start making use of this segment to join the next
>>>
>>>border,
>>>
>>>
>>>>>>>>>>>therefore advertisement of the LSP segment may create a multi-hop
>>>>>>>>>>>condition, but now once used relevance of the existence of the
>>>>>
>>>>>segment
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>is not a useful information (for the area) as there is no
>>>
>>>possibility
>>>
>>>
>>>>>>>>>>>to make re-use of it except when the end-to-end LSP is torn down
>>>>>>>>>>
>>>>>>>>>>AA----------> I understand your point that once an LSP has been
>>>>>
>>>>>admitted
>>>>>
>>>>>
>>>>>
>>>>>>>>>>into an LSP segment it is no longer usable by other nodes in that
>>>>>
>>>>>area.
>>>>>
>>>>>
>>>>>
>>>>>>>>>>But would you rather stop advertising the link at this point, if
> 
> you
> 
>>>>>>>>>>were previously advertising it ? Don't you think that is a big
>>>
>>>hammer
>>>
>>>
>>>>>? E.g.
>>>>>
>>>>>
>>>>>
>>>>>>>>>>how would a head end which has indeed computed a path over that
> 
> LSP
> 
>>>>>>>>>>segment differentiate this event from an LSP segment down event
>>>
>>>where
>>>
>>>
>>>>>>>>>>the link is deleted from the database ? So, all the document says
>>>>>
>>>>>today is
>>>>>
>>>>>
>>>>>
>>>>>>>>>>that you set the unreserved bw on the LSP segment to zero. The
> 
> idea
> 
>>>is
>>>
>>>
>>>>>>>>>>to still let other nodes know that the link exists but is
> 
> unusable.
> 
>>>It
>>>
>>>
>>>>>is
>>>>>
>>>>>
>>>>>
>>>>>>>>>>not different from a FA-LSP being consumed...in that case we don't
>>>>>
>>>>>stop
>>>>>
>>>>>
>>>>>
>>>>>>>>>>advertising the FA (if we were doing so previously), right ?
>>>>>>>>>
>>>>>>>>>IB>> Completley agree with Arthi. Besides, several parallel
> 
> stitching
> 
>>>>>>>>>segments could be advertised as a single bundle - hence, using the
>>>>>>>>>advertised link by one LSP does not necessarily take away all
> 
> link's
> 
>>>>>>>>>bandwidth.
>>>>>>>>
>>>>>>>>you don't understand the question, it is do we have to consider as
>>>>>>>>default behavior that a pre-provisioned is to be "advertized"
>>>>>>>
>>>>>>>IB>> My point was that I do not see any difference in this respect
>>>>>
>>>>>between
>>>>>
>>>>>
>>>>>
>>>>>>>the sticthing FA-LSP (the same layer FA-LSP) and FA-LSP created in
> 
> the
> 
>>>>>lower
>>>>>
>>>>>
>>>>>
>>>>>>>layer. Besides, what do you mean by the default behaviour? The fact
>>>>>
>>>>>whether
>>>>>
>>>>>
>>>>>
>>>>>>>to advertise//remove FA TE link is a policy driven carefully thought
>>>>>
>>>>>through
>>>>>
>>>>>
>>>>>
>>>>>>>decision, a dnagerous one that could potentially destabilize the
>>>>>
>>>>>network.
>>>>>
>>>>>
>>>>>
>>>>>>>I'd say that the default behaviour is "NOT ADVERTISE" in either case.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>now beside the fact that there are techniques to do so what would be
>>>
>>>the
>>>
>>>
>>>>>>>>purpose of it ? and what it the overhead that such advertisement
> 
> would
> 
>>>>>>>>create - that can be of course decreased by bundling them -
>>>>>>>
>>>>>>>IB>> The purpose is exactly the same as for any other FA-LSP - add
>>>>>>>flexibility in a particular layer.
>>>>>>
>>>>>>which flexibility are we expecting here, this "segment" can
> 
> accommodate
> 
>>>>>>exactly one incoming request -
>>>>>
>>>>>
>>>>>IB>> Disagree - the segment could be a component link within a bundle.
>>>
>>>In
>>>
>>>
>>>>>this case stitching FA TE link may accomodate multiple LSPs
>>>>>
>>>>>additionally only nodes part of the same
>>>>>
>>>>>
>>>>>
>>>>>>area can make use of this advertisement -
>>>>>
>>>>>
>>>>>IB>> Who said that sticthing segments must necessarily terminate on
>>>
>>>domain
>>>
>>>
>>>>>borders? There could be multiple reasons why a network operator could
>>>>>pre-provision (dynamically or statically) LSP segments inside his
>>>
>>>network
>>>
>>>
>>>>>and advertise them (as bundles or individually) as TE links to be used
>>>
>>>for
>>>
>>>
>>>>>specific TE purposes.
>>>>
>>>>it is exactly these purposes that i am looking for
>>>>
>>>>
>>>>
>>>>>so in fact what it would allow
>>>>>
>>>>>
>>>>>
>>>>>>is the possibility to avoid creation of a segment if the edge node
>>>>>>receiving the request re-orients its request to the head-end for this
>>>>>>advertisement
>>>>>>                       |
>>>>>>example:      ----------D----------
>>>>>>            |                     |
>>>>>>          - A ---- Segment 1 ---- B -
>>>>>>            |                     |
>>>>>>             ----------C----------
>>>>>>                       |
>>>>>>
>>>>>>you would have a segment between A-B that could be reached from C (the
>>>>>>node receiving the incoming request) decides to make use of this
> 
> segment
> 
>>>>>>to reach B (so you would have C-A-B) but if this was the best path
> 
> why
> 
>>>>>>not creating directly a segment C-A-B, instead of now having one
> 
> segment
> 
>>>>>>C-A, the pre-provisioned A-B and probably one on top of it C-A-B ?
>>>>>
>>>>>
>>>>>IB>> See my comment above. I might want to use statically provisioned
>>>>>segments. I might want to use nodes that do not have proper signaling
>>>>>software.
>>>>
>>>>what does that mean "proper signaling software"
>>>>
>>>>
>>>>
>>>>>For instance, recall the discussions on P2MP and how we want use legacy
>>>
>>>LSRs
>>>
>>>
>>>>>to be part of P2MP tunnels
>>>>
>>>>but in this case there is a flag telling capabilities of the nodes in
>>>>order to allow for dynamically trigger the segment
>>>>
>>>>
>>>>
>>>>>>in case of classical FA-LSP it makes sense to advertize the FA link
>>>>>>because it represents a lower region LSP (with usually a given ratio
> 
> of
> 
>>>>>>unreserved bandwidth that makes worth advertizing the FA link) but in
>>>>>>case of a segment i do have some difficulties to excatly see where
> 
> this
> 
>>>>>>flexibility would deliver ?
>>>>>
>>>>>
>>>>>IB>> Again, if you imagine that several parallel sticthing segments are
>>>>>advertised as as single FA, how it would be different from the
> 
> bandwidth
> 
>>>>>usage point of view compared to advertising lower layer FA ?
>>>>
>>>>issues are different - FAs are used in manner to preferentially attract
>>>>over them because - i am still looking for the reason for attracting
>>>>over a bundle
>>>>
>>>>
>>>>
>>>>>In fact it would be even more useful, because in case of lower layer FA
>>>
>>>you need also
>>>
>>>
>>>>>to advertise termination/adaptation capabilities, while in case of
>>>
>>>stitching
>>>
>>>
>>>>>FA no addaptation is required.
>>>>
>>>>by the way you don't seem to see the issue that i am pointing out, so
>>>>probably there is a need to go in more detailed examples before drawing
>>>>the above confusing conclusion
>>>>
>>>>
>>>>
>>>>>Igor
>>>>>
>>>>>
>>>>>
>>>>>>thanks,
>>>>>>- dimitri.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>thanks,
>>>>>>>>- dimitri.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>a more technical point is related to the definition of an FA LSP
>>>>>
>>>>>which
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>per LSP-Hierarchy mandates crossing LSP region border: the
> 
> head-end
> 
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>tail-end switching capability represent the SC of the resulting
> 
> TE
> 
>>>>>link
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>while intermediate node terminates the SC corr. to the switching
>>>
>>>type
>>>
>>>
>>>>>>>of
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a
>>>
>>>PSC-2
>>>
>>>
>>>>>>>>>>>capable network with first and last link being [PSC-1,PSC-2] and
>>>>>>>>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would
> 
> have
> 
>>>>>now
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>the creation of a [PSC-1,PSC-1] link with first and last link
> 
> being
> 
>>>>>>>>>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region
> 
> border
> 
>>>>>>>>>>>crossing anymore - so here the question is about definition and
>>>>>>>>>>>detailing the triggers
>>>>>>>>>>
>>>>>>>>>>AA--------> As far as trigger for setting up an LSP segment is
>>>>>>>
>>>>>>>concerned,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>I agree that there is no longer the notion of "crossing region
>>>>>>>>>>boundaries". I realize that the document doesn't discuss this,
>>>>>>>
>>>>>>>especially
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>given that we are doing other comparisons with FA LSPs. So, I will
>>>
>>>add
>>>
>>>
>>>>>>>>>>this discussion in the next revision. I think in case of LSP
> 
> segment
> 
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>>trigger for LSP segment setup would come from a) successful
>>>
>>>switching
>>>
>>>
>>>>>>>type
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>and switching capability match and b) some local policy on the
> 
> node
> 
>>>>>>>which
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>dictates the setting up of an LSP segment.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and could
> 
> be
> 
>>>>>>>>>challenged in many ways. FA LSP is, generally speaking, created on
> 
> a
> 
>>>>>>>layer
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>boundary rather than on region boundary: nothing prevents creating
> 
> a
> 
>>>>>VC4
>>>>>
>>>>>
>>>>>
>>>>>>>FA
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>LSP that starts and stops in the middle of TDM region to carry
>>>
>>>several
>>>
>>>
>>>>>>>VC12
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>LSPs. Furthermore, stitching FA is a special case of FA when it is
>>>
>>>used
>>>
>>>
>>>>>>>by
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>LSPs of the same layer as one where the FA-LSP was created. As for
>>>>>>>
>>>>>>>triggers,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>there could be multiple ones for setting up/tearing down stitching
>>>>>>>
>>>>>>>FA-LSPs:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>configuration, receiving setup request for inter-domain LSP, other
>>>>>>>
>>>>>>>policies.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>Igor
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>More on a) later.
>>>>>>>>>>
>>>>>>>>>>thanks,
>>>>>>>>>>-arthi
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>.
>>>>>>>>>
>>>>>>>>
>>>>>>>.
>>>>>>>
>>>>>>
>>>>>.
>>>>>
>>>>
>>>
>>>.
>>>
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 21:44:01 +0000
Message-ID: <000a01c51539$af5f1350$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, <[e-mail]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Date: Thu, 17 Feb 2005 16:43:14 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dimitri,

See my comments in line.

Igor

----- Original Message ----- 
From: "dimitri papadimitriou" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>; "Arthi Ayyangar"
<[e-mail]>; <[e-mail]>
Sent: Thursday, February 17, 2005 3:55 PM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt


> igor,
>
> > For the second time you are saying that I don't see the issue that you
are
> > pointed out and this is beginning to annoy me.
>  >
> > Your point/question is very simple, which is what does it give to
advertise
> > stitching segments as FAs, is that correct?
> >
> > My answers are very simple either:
> >
> > 1) How else are you going to use statically provisioned segments as part
of
> > dynamically provisioned end-to-end LSPs ?
>
> you ask a different question from the initial issue because advertize a
> TE link was possible today without using stitching, however this issue
> also depends what do you mean by statical provisioning ?

IB>> I have segments that are provisioned/owned by the management plane

>
> > 2) How else you can accomplish a transition strategy when some of the
nodes
> > that are going to be involved in end-to-end dynamically provisioned LSPs
do
> > not have proper signaling software?
>
> and i did ask what is the point in applying LSP segment signaling on
> segment that "do not have proper signaling software"

IB>> The point is that transit nodes of the segments do not participate and
hence do not have to support e2e signaling

> > The specific example is using LSRs that
> > do not support p2mp signaling as transit nodes in p2mp LSPs. Your point
> > about advertising of node capabilities is relevant only for routing -
the
> > PCE computing p2mp tree may take in consideration the advertised node
> > capabilities and assume that stitching segments may be created
dynamically
> > if needed.
>
> just to be clear the PCE discussion is completely outside of the present
> discussion - afaik the working group has (still) to provide requirements
> for the PCE wg -

IB>> Just to be clear. You mentioned the use of advertised node
capabilities. My point is that these advertisements are useful for path
computation but are of no use for e2e signaling

>
> > What if I don't want them to be dynamically created and rather
> > have them pre-provisioned to spead up the process of p2mp tunnel setup
and
> > decrease blocking probability?
>
> not sure that compared to the global complexity of computing the tree
> this is going to be a significant improvement, but if you have the
> possibility to determine the bandwidth on the corr. segments i don't see
> here how you decrease the blocking probability (afaik propagation of
> segment related information is equivalent to the corresponding links
> advertisement)

IB>> Dynamic establishment of the stitching segments may fail


> > 3) What if I want to attract certain LSPs  to use pre-provisioned
segments
> > even if the overall cost of such LSPs would be higher than if they would
> > take paths computed without consideration of these segments, but it is
> > desirable for the LSPs to use the segments anyway. Exanple: the segments
are
> > provisioned to satisfy wavelength continuity constraint and I don't have
PCE
> > that can perform path computation with such contraint on path segments
> > between points of OEO.
>
> as said above it would desirable to leave PCE aspects outside of the
> picture, but this application is really interesting because on one side
> i thought we had the label set to solve this issue (note: that even if a
> path is pre-computed explicit label control can be used to provision the
> segment between converting points - don't PCEs for this)

IB>> First, this is just an example of the situation when I want
pre-provisioned segments to be used in e2e LSP provisioning.
 Second, satisfying the wavelength continuity constraint takes much more
than just using the label set. You need to have:
a) information about all lambdas in all isles of transparency;
b) very complex PCE that is capable of computing optimal path(s) that use
the same wavelength on all links within each OEO-OEO segments satisfying all
other optical constraints.

It is much simpler to pre-provision such OEO-OEO segments and advertise them
as TE links, than a simple PCE would do the job.

Igor

> on the other hand is how much possible pre-provisioned segments - so
> overhead - are now going to be advertised if the traffic demand is
> unknown ? and on the other hand, if all traffic matrix is known
> beforehand is there any rationale to create these segments instead of
> directly provisioning
>
> it is interesting to see that you are populating this discussion with
> PCE application - i would be more in favor in leaving the possibility of
> advertising segments once a clear set is being identified rather than
> the other way around
>
> > Igor
> >
> >
> >
> >
> >
> > ----- Original Message ----- 
> > From: "dimitri papadimitriou" <[e-mail]>
> > To: "Igor Bryskin" <[e-mail]>
> > Cc: <[e-mail]>; "Arthi Ayyangar"
> > <[e-mail]>; <[e-mail]>
> > Sent: Thursday, February 17, 2005 1:19 PM
> > Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
> >
> >
> >
> >>
> >>Igor Bryskin wrote:
> >>
> >>
> >>>dimitri, see in line.
> >>>
> >>>----- Original Message ----- 
> >>>From: "dimitri papadimitriou" <[e-mail]>
> >>>To: "Igor Bryskin" <[e-mail]>
> >>>Cc: <[e-mail]>; "Arthi Ayyangar"
> >>><[e-mail]>; <[e-mail]>
> >>>Sent: Thursday, February 17, 2005 11:40 AM
> >>>Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
> >>>
> >>>
> >>>
> >>>
> >>>>igor - see in-line
> >>>>
> >>>>
> >>>>
> >>>>>>>>Please see my replies (AA--->) inline.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>---------> An LSP segment may be created either by configuration
> >
> > or
> >
> >>>>>>>>>>due to arrival of an e2e LSP setup request itself. Similar to an
> >
> > FA,
> >
> >>>an
> >>>
> >>>
> >>>>>>>>>>LSP segment may or may not be advertised as a TE link. But, if
> >>>>>>>>>>pre-created, it could be advertised, in which case other nodes
may
> >>>>>>>>>>compute a path over it.
> >>>>>>>>>>
> >>>>>>>>>>Why would you want to or not want to advertise an FA ?
> >>>>>>>>>
> >>>>>>>>>i understand the point on pre-created <-> advertised but this
> >>>
> >>>knowledge
> >>>
> >>>
> >>>>>>>>>may be useful for nodes part of the same area (not for nodes
> >
> > external
> >
> >>>>>>>>>to this area)
> >>>>>>>>
> >>>>>>>>AA -------> Absolutely ...this definitely cannot be advertised
> >
> > outside
> >
> >>>>>>>>the area (domain). I think this has been explicitly mentioned.
> >>>>>>>>
> >>>>>>>>so in case a node for inst. advertises three terminating
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>links with PSC-2 (one of these being the LSP segment) then a
> >
> > another
> >
> >>>>>>>>>node (part of the same area) receiving an incoming multi-area
PSC-2
> >>>
> >>>LSP
> >>>
> >>>
> >>>>>>>>>request may start making use of this segment to join the next
> >
> > border,
> >
> >>>>>>>>>therefore advertisement of the LSP segment may create a multi-hop
> >>>>>>>>>condition, but now once used relevance of the existence of the
> >>>
> >>>segment
> >>>
> >>>
> >>>>>>>>>is not a useful information (for the area) as there is no
> >
> > possibility
> >
> >>>>>>>>>to make re-use of it except when the end-to-end LSP is torn down
> >>>>>>>>
> >>>>>>>>AA----------> I understand your point that once an LSP has been
> >>>
> >>>admitted
> >>>
> >>>
> >>>>>>>>into an LSP segment it is no longer usable by other nodes in that
> >>>
> >>>area.
> >>>
> >>>
> >>>>>>>>But would you rather stop advertising the link at this point, if
you
> >>>>>>>>were previously advertising it ? Don't you think that is a big
> >
> > hammer
> >
> >>>? E.g.
> >>>
> >>>
> >>>>>>>>how would a head end which has indeed computed a path over that
LSP
> >>>>>>>>segment differentiate this event from an LSP segment down event
> >
> > where
> >
> >>>>>>>>the link is deleted from the database ? So, all the document says
> >>>
> >>>today is
> >>>
> >>>
> >>>>>>>>that you set the unreserved bw on the LSP segment to zero. The
idea
> >
> > is
> >
> >>>>>>>>to still let other nodes know that the link exists but is
unusable.
> >
> > It
> >
> >>>is
> >>>
> >>>
> >>>>>>>>not different from a FA-LSP being consumed...in that case we don't
> >>>
> >>>stop
> >>>
> >>>
> >>>>>>>>advertising the FA (if we were doing so previously), right ?
> >>>>>>>
> >>>>>>>IB>> Completley agree with Arthi. Besides, several parallel
stitching
> >>>>>>>segments could be advertised as a single bundle - hence, using the
> >>>>>>>advertised link by one LSP does not necessarily take away all
link's
> >>>>>>>bandwidth.
> >>>>>>
> >>>>>>you don't understand the question, it is do we have to consider as
> >>>>>>default behavior that a pre-provisioned is to be "advertized"
> >>>>>
> >>>>>IB>> My point was that I do not see any difference in this respect
> >>>
> >>>between
> >>>
> >>>
> >>>>>the sticthing FA-LSP (the same layer FA-LSP) and FA-LSP created in
the
> >>>
> >>>lower
> >>>
> >>>
> >>>>>layer. Besides, what do you mean by the default behaviour? The fact
> >>>
> >>>whether
> >>>
> >>>
> >>>>>to advertise//remove FA TE link is a policy driven carefully thought
> >>>
> >>>through
> >>>
> >>>
> >>>>>decision, a dnagerous one that could potentially destabilize the
> >>>
> >>>network.
> >>>
> >>>
> >>>>>I'd say that the default behaviour is "NOT ADVERTISE" in either case.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>now beside the fact that there are techniques to do so what would be
> >
> > the
> >
> >>>>>>purpose of it ? and what it the overhead that such advertisement
would
> >>>>>>create - that can be of course decreased by bundling them -
> >>>>>
> >>>>>IB>> The purpose is exactly the same as for any other FA-LSP - add
> >>>>>flexibility in a particular layer.
> >>>>
> >>>>which flexibility are we expecting here, this "segment" can
accommodate
> >>>>exactly one incoming request -
> >>>
> >>>
> >>>IB>> Disagree - the segment could be a component link within a bundle.
> >
> > In
> >
> >>>this case stitching FA TE link may accomodate multiple LSPs
> >>>
> >>> additionally only nodes part of the same
> >>>
> >>>
> >>>>area can make use of this advertisement -
> >>>
> >>>
> >>>IB>> Who said that sticthing segments must necessarily terminate on
> >
> > domain
> >
> >>>borders? There could be multiple reasons why a network operator could
> >>>pre-provision (dynamically or statically) LSP segments inside his
> >
> > network
> >
> >>>and advertise them (as bundles or individually) as TE links to be used
> >
> > for
> >
> >>>specific TE purposes.
> >>
> >>it is exactly these purposes that i am looking for
> >>
> >>
> >>>so in fact what it would allow
> >>>
> >>>
> >>>>is the possibility to avoid creation of a segment if the edge node
> >>>>receiving the request re-orients its request to the head-end for this
> >>>>advertisement
> >>>>                        |
> >>>>example:      ----------D----------
> >>>>             |                     |
> >>>>           - A ---- Segment 1 ---- B -
> >>>>             |                     |
> >>>>              ----------C----------
> >>>>                        |
> >>>>
> >>>>you would have a segment between A-B that could be reached from C (the
> >>>>node receiving the incoming request) decides to make use of this
segment
> >>>> to reach B (so you would have C-A-B) but if this was the best path
why
> >>>>not creating directly a segment C-A-B, instead of now having one
segment
> >>>>C-A, the pre-provisioned A-B and probably one on top of it C-A-B ?
> >>>
> >>>
> >>>IB>> See my comment above. I might want to use statically provisioned
> >>>segments. I might want to use nodes that do not have proper signaling
> >>>software.
> >>
> >>what does that mean "proper signaling software"
> >>
> >>
> >>>For instance, recall the discussions on P2MP and how we want use legacy
> >
> > LSRs
> >
> >>>to be part of P2MP tunnels
> >>
> >>but in this case there is a flag telling capabilities of the nodes in
> >>order to allow for dynamically trigger the segment
> >>
> >>
> >>>>in case of classical FA-LSP it makes sense to advertize the FA link
> >>>>because it represents a lower region LSP (with usually a given ratio
of
> >>>>unreserved bandwidth that makes worth advertizing the FA link) but in
> >>>>case of a segment i do have some difficulties to excatly see where
this
> >>>>flexibility would deliver ?
> >>>
> >>>
> >>>IB>> Again, if you imagine that several parallel sticthing segments are
> >>>advertised as as single FA, how it would be different from the
bandwidth
> >>>usage point of view compared to advertising lower layer FA ?
> >>
> >>issues are different - FAs are used in manner to preferentially attract
> >>over them because - i am still looking for the reason for attracting
> >>over a bundle
> >>
> >>
> >>>In fact it would be even more useful, because in case of lower layer FA
> >
> > you need also
> >
> >>>to advertise termination/adaptation capabilities, while in case of
> >
> > stitching
> >
> >>>FA no addaptation is required.
> >>
> >>by the way you don't seem to see the issue that i am pointing out, so
> >>probably there is a need to go in more detailed examples before drawing
> >>the above confusing conclusion
> >>
> >>
> >>>Igor
> >>>
> >>>
> >>>>thanks,
> >>>>- dimitri.
> >>>>
> >>>>
> >>>>
> >>>>>>thanks,
> >>>>>>- dimitri.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>a more technical point is related to the definition of an FA LSP
> >>>
> >>>which
> >>>
> >>>
> >>>>>>>>>per LSP-Hierarchy mandates crossing LSP region border: the
head-end
> >>>
> >>>and
> >>>
> >>>
> >>>>>>>>>tail-end switching capability represent the SC of the resulting
TE
> >>>
> >>>link
> >>>
> >>>
> >>>>>>>>>while intermediate node terminates the SC corr. to the switching
> >
> > type
> >
> >>>>>of
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a
> >
> > PSC-2
> >
> >>>>>>>>>capable network with first and last link being [PSC-1,PSC-2] and
> >>>>>>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would
have
> >>>
> >>>now
> >>>
> >>>
> >>>>>>>>>the creation of a [PSC-1,PSC-1] link with first and last link
being
> >>>>>>>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region
border
> >>>>>>>>>crossing anymore - so here the question is about definition and
> >>>>>>>>>detailing the triggers
> >>>>>>>>
> >>>>>>>>AA--------> As far as trigger for setting up an LSP segment is
> >>>>>
> >>>>>concerned,
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>I agree that there is no longer the notion of "crossing region
> >>>>>>>>boundaries". I realize that the document doesn't discuss this,
> >>>>>
> >>>>>especially
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>given that we are doing other comparisons with FA LSPs. So, I will
> >
> > add
> >
> >>>>>>>>this discussion in the next revision. I think in case of LSP
segment
> >>>
> >>>the
> >>>
> >>>
> >>>>>>>>trigger for LSP segment setup would come from a) successful
> >
> > switching
> >
> >>>>>type
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>and switching capability match and b) some local policy on the
node
> >>>>>
> >>>>>which
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>dictates the setting up of an LSP segment.
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and could
be
> >>>>>>>challenged in many ways. FA LSP is, generally speaking, created on
a
> >>>>>
> >>>>>layer
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>boundary rather than on region boundary: nothing prevents creating
a
> >>>
> >>>VC4
> >>>
> >>>
> >>>>>FA
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>LSP that starts and stops in the middle of TDM region to carry
> >
> > several
> >
> >>>>>VC12
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>LSPs. Furthermore, stitching FA is a special case of FA when it is
> >
> > used
> >
> >>>>>by
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>LSPs of the same layer as one where the FA-LSP was created. As for
> >>>>>
> >>>>>triggers,
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>there could be multiple ones for setting up/tearing down stitching
> >>>>>
> >>>>>FA-LSPs:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>configuration, receiving setup request for inter-domain LSP, other
> >>>>>
> >>>>>policies.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>Igor
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>More on a) later.
> >>>>>>>>
> >>>>>>>>thanks,
> >>>>>>>>-arthi
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>.
> >>>>>>>
> >>>>>>
> >>>>>.
> >>>>>
> >>>>
> >>>
> >>>.
> >>>
> >>
> >
> >
> > .
> >




Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 20:56:44 +0000
Message-ID: <[e-mail]>
Date: Thu, 17 Feb 2005 21:55:38 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC:  [e-mail], Arthi Ayyangar <[e-mail]>,  [e-mail]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

igor,

> For the second time you are saying that I don't see the issue that you are
> pointed out and this is beginning to annoy me.
 >
> Your point/question is very simple, which is what does it give to advertise
> stitching segments as FAs, is that correct?
> 
> My answers are very simple either:
> 
> 1) How else are you going to use statically provisioned segments as part of
> dynamically provisioned end-to-end LSPs ?

you ask a different question from the initial issue because advertize a 
TE link was possible today without using stitching, however this issue 
also depends what do you mean by statical provisioning ?

> 2) How else you can accomplish a transition strategy when some of the nodes
> that are going to be involved in end-to-end dynamically provisioned LSPs do
> not have proper signaling software? 

and i did ask what is the point in applying LSP segment signaling on 
segment that "do not have proper signaling software"

> The specific example is using LSRs that
> do not support p2mp signaling as transit nodes in p2mp LSPs. Your point
> about advertising of node capabilities is relevant only for routing - the
> PCE computing p2mp tree may take in consideration the advertised node
> capabilities and assume that stitching segments may be created dynamically
> if needed. 

just to be clear the PCE discussion is completely outside of the present 
discussion - afaik the working group has (still) to provide requirements 
for the PCE wg -

> What if I don't want them to be dynamically created and rather
> have them pre-provisioned to spead up the process of p2mp tunnel setup and
> decrease blocking probability?

not sure that compared to the global complexity of computing the tree 
this is going to be a significant improvement, but if you have the 
possibility to determine the bandwidth on the corr. segments i don't see 
here how you decrease the blocking probability (afaik propagation of 
segment related information is equivalent to the corresponding links 
advertisement)

> 3) What if I want to attract certain LSPs  to use pre-provisioned segments
> even if the overall cost of such LSPs would be higher than if they would
> take paths computed without consideration of these segments, but it is
> desirable for the LSPs to use the segments anyway. Exanple: the segments are
> provisioned to satisfy wavelength continuity constraint and I don't have PCE
> that can perform path computation with such contraint on path segments
> between points of OEO.

as said above it would desirable to leave PCE aspects outside of the 
picture, but this application is really interesting because on one side 
i thought we had the label set to solve this issue (note: that even if a 
path is pre-computed explicit label control can be used to provision the 
segment between converting points - don't PCEs for this)

on the other hand is how much possible pre-provisioned segments - so 
overhead - are now going to be advertised if the traffic demand is 
unknown ? and on the other hand, if all traffic matrix is known 
beforehand is there any rationale to create these segments instead of 
directly provisioning

it is interesting to see that you are populating this discussion with 
PCE application - i would be more in favor in leaving the possibility of 
advertising segments once a clear set is being identified rather than 
the other way around

> Igor
> 
> 
> 
> 
> 
> ----- Original Message ----- 
> From: "dimitri papadimitriou" <[e-mail]>
> To: "Igor Bryskin" <[e-mail]>
> Cc: <[e-mail]>; "Arthi Ayyangar"
> <[e-mail]>; <[e-mail]>
> Sent: Thursday, February 17, 2005 1:19 PM
> Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
> 
> 
> 
>>
>>Igor Bryskin wrote:
>>
>>
>>>dimitri, see in line.
>>>
>>>----- Original Message ----- 
>>>From: "dimitri papadimitriou" <[e-mail]>
>>>To: "Igor Bryskin" <[e-mail]>
>>>Cc: <[e-mail]>; "Arthi Ayyangar"
>>><[e-mail]>; <[e-mail]>
>>>Sent: Thursday, February 17, 2005 11:40 AM
>>>Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
>>>
>>>
>>>
>>>
>>>>igor - see in-line
>>>>
>>>>
>>>>
>>>>>>>>Please see my replies (AA--->) inline.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>---------> An LSP segment may be created either by configuration
> 
> or
> 
>>>>>>>>>>due to arrival of an e2e LSP setup request itself. Similar to an
> 
> FA,
> 
>>>an
>>>
>>>
>>>>>>>>>>LSP segment may or may not be advertised as a TE link. But, if
>>>>>>>>>>pre-created, it could be advertised, in which case other nodes may
>>>>>>>>>>compute a path over it.
>>>>>>>>>>
>>>>>>>>>>Why would you want to or not want to advertise an FA ?
>>>>>>>>>
>>>>>>>>>i understand the point on pre-created <-> advertised but this
>>>
>>>knowledge
>>>
>>>
>>>>>>>>>may be useful for nodes part of the same area (not for nodes
> 
> external
> 
>>>>>>>>>to this area)
>>>>>>>>
>>>>>>>>AA -------> Absolutely ...this definitely cannot be advertised
> 
> outside
> 
>>>>>>>>the area (domain). I think this has been explicitly mentioned.
>>>>>>>>
>>>>>>>>so in case a node for inst. advertises three terminating
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>links with PSC-2 (one of these being the LSP segment) then a
> 
> another
> 
>>>>>>>>>node (part of the same area) receiving an incoming multi-area PSC-2
>>>
>>>LSP
>>>
>>>
>>>>>>>>>request may start making use of this segment to join the next
> 
> border,
> 
>>>>>>>>>therefore advertisement of the LSP segment may create a multi-hop
>>>>>>>>>condition, but now once used relevance of the existence of the
>>>
>>>segment
>>>
>>>
>>>>>>>>>is not a useful information (for the area) as there is no
> 
> possibility
> 
>>>>>>>>>to make re-use of it except when the end-to-end LSP is torn down
>>>>>>>>
>>>>>>>>AA----------> I understand your point that once an LSP has been
>>>
>>>admitted
>>>
>>>
>>>>>>>>into an LSP segment it is no longer usable by other nodes in that
>>>
>>>area.
>>>
>>>
>>>>>>>>But would you rather stop advertising the link at this point, if you
>>>>>>>>were previously advertising it ? Don't you think that is a big
> 
> hammer
> 
>>>? E.g.
>>>
>>>
>>>>>>>>how would a head end which has indeed computed a path over that LSP
>>>>>>>>segment differentiate this event from an LSP segment down event
> 
> where
> 
>>>>>>>>the link is deleted from the database ? So, all the document says
>>>
>>>today is
>>>
>>>
>>>>>>>>that you set the unreserved bw on the LSP segment to zero. The idea
> 
> is
> 
>>>>>>>>to still let other nodes know that the link exists but is unusable.
> 
> It
> 
>>>is
>>>
>>>
>>>>>>>>not different from a FA-LSP being consumed...in that case we don't
>>>
>>>stop
>>>
>>>
>>>>>>>>advertising the FA (if we were doing so previously), right ?
>>>>>>>
>>>>>>>IB>> Completley agree with Arthi. Besides, several parallel stitching
>>>>>>>segments could be advertised as a single bundle - hence, using the
>>>>>>>advertised link by one LSP does not necessarily take away all link's
>>>>>>>bandwidth.
>>>>>>
>>>>>>you don't understand the question, it is do we have to consider as
>>>>>>default behavior that a pre-provisioned is to be "advertized"
>>>>>
>>>>>IB>> My point was that I do not see any difference in this respect
>>>
>>>between
>>>
>>>
>>>>>the sticthing FA-LSP (the same layer FA-LSP) and FA-LSP created in the
>>>
>>>lower
>>>
>>>
>>>>>layer. Besides, what do you mean by the default behaviour? The fact
>>>
>>>whether
>>>
>>>
>>>>>to advertise//remove FA TE link is a policy driven carefully thought
>>>
>>>through
>>>
>>>
>>>>>decision, a dnagerous one that could potentially destabilize the
>>>
>>>network.
>>>
>>>
>>>>>I'd say that the default behaviour is "NOT ADVERTISE" in either case.
>>>>>
>>>>>
>>>>>
>>>>>>now beside the fact that there are techniques to do so what would be
> 
> the
> 
>>>>>>purpose of it ? and what it the overhead that such advertisement would
>>>>>>create - that can be of course decreased by bundling them -
>>>>>
>>>>>IB>> The purpose is exactly the same as for any other FA-LSP - add
>>>>>flexibility in a particular layer.
>>>>
>>>>which flexibility are we expecting here, this "segment" can accommodate
>>>>exactly one incoming request -
>>>
>>>
>>>IB>> Disagree - the segment could be a component link within a bundle.
> 
> In
> 
>>>this case stitching FA TE link may accomodate multiple LSPs
>>>
>>> additionally only nodes part of the same
>>>
>>>
>>>>area can make use of this advertisement -
>>>
>>>
>>>IB>> Who said that sticthing segments must necessarily terminate on
> 
> domain
> 
>>>borders? There could be multiple reasons why a network operator could
>>>pre-provision (dynamically or statically) LSP segments inside his
> 
> network
> 
>>>and advertise them (as bundles or individually) as TE links to be used
> 
> for
> 
>>>specific TE purposes.
>>
>>it is exactly these purposes that i am looking for
>>
>>
>>>so in fact what it would allow
>>>
>>>
>>>>is the possibility to avoid creation of a segment if the edge node
>>>>receiving the request re-orients its request to the head-end for this
>>>>advertisement
>>>>                        |
>>>>example:      ----------D----------
>>>>             |                     |
>>>>           - A ---- Segment 1 ---- B -
>>>>             |                     |
>>>>              ----------C----------
>>>>                        |
>>>>
>>>>you would have a segment between A-B that could be reached from C (the
>>>>node receiving the incoming request) decides to make use of this segment
>>>> to reach B (so you would have C-A-B) but if this was the best path why
>>>>not creating directly a segment C-A-B, instead of now having one segment
>>>>C-A, the pre-provisioned A-B and probably one on top of it C-A-B ?
>>>
>>>
>>>IB>> See my comment above. I might want to use statically provisioned
>>>segments. I might want to use nodes that do not have proper signaling
>>>software.
>>
>>what does that mean "proper signaling software"
>>
>>
>>>For instance, recall the discussions on P2MP and how we want use legacy
> 
> LSRs
> 
>>>to be part of P2MP tunnels
>>
>>but in this case there is a flag telling capabilities of the nodes in
>>order to allow for dynamically trigger the segment
>>
>>
>>>>in case of classical FA-LSP it makes sense to advertize the FA link
>>>>because it represents a lower region LSP (with usually a given ratio of
>>>>unreserved bandwidth that makes worth advertizing the FA link) but in
>>>>case of a segment i do have some difficulties to excatly see where this
>>>>flexibility would deliver ?
>>>
>>>
>>>IB>> Again, if you imagine that several parallel sticthing segments are
>>>advertised as as single FA, how it would be different from the bandwidth
>>>usage point of view compared to advertising lower layer FA ?
>>
>>issues are different - FAs are used in manner to preferentially attract
>>over them because - i am still looking for the reason for attracting
>>over a bundle
>>
>>
>>>In fact it would be even more useful, because in case of lower layer FA
> 
> you need also
> 
>>>to advertise termination/adaptation capabilities, while in case of
> 
> stitching
> 
>>>FA no addaptation is required.
>>
>>by the way you don't seem to see the issue that i am pointing out, so
>>probably there is a need to go in more detailed examples before drawing
>>the above confusing conclusion
>>
>>
>>>Igor
>>>
>>>
>>>>thanks,
>>>>- dimitri.
>>>>
>>>>
>>>>
>>>>>>thanks,
>>>>>>- dimitri.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>a more technical point is related to the definition of an FA LSP
>>>
>>>which
>>>
>>>
>>>>>>>>>per LSP-Hierarchy mandates crossing LSP region border: the head-end
>>>
>>>and
>>>
>>>
>>>>>>>>>tail-end switching capability represent the SC of the resulting TE
>>>
>>>link
>>>
>>>
>>>>>>>>>while intermediate node terminates the SC corr. to the switching
> 
> type
> 
>>>>>of
>>>>>
>>>>>
>>>>>
>>>>>>>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a
> 
> PSC-2
> 
>>>>>>>>>capable network with first and last link being [PSC-1,PSC-2] and
>>>>>>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would have
>>>
>>>now
>>>
>>>
>>>>>>>>>the creation of a [PSC-1,PSC-1] link with first and last link being
>>>>>>>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border
>>>>>>>>>crossing anymore - so here the question is about definition and
>>>>>>>>>detailing the triggers
>>>>>>>>
>>>>>>>>AA--------> As far as trigger for setting up an LSP segment is
>>>>>
>>>>>concerned,
>>>>>
>>>>>
>>>>>
>>>>>>>>I agree that there is no longer the notion of "crossing region
>>>>>>>>boundaries". I realize that the document doesn't discuss this,
>>>>>
>>>>>especially
>>>>>
>>>>>
>>>>>
>>>>>>>>given that we are doing other comparisons with FA LSPs. So, I will
> 
> add
> 
>>>>>>>>this discussion in the next revision. I think in case of LSP segment
>>>
>>>the
>>>
>>>
>>>>>>>>trigger for LSP segment setup would come from a) successful
> 
> switching
> 
>>>>>type
>>>>>
>>>>>
>>>>>
>>>>>>>>and switching capability match and b) some local policy on the node
>>>>>
>>>>>which
>>>>>
>>>>>
>>>>>
>>>>>>>>dictates the setting up of an LSP segment.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and could be
>>>>>>>challenged in many ways. FA LSP is, generally speaking, created on a
>>>>>
>>>>>layer
>>>>>
>>>>>
>>>>>
>>>>>>>boundary rather than on region boundary: nothing prevents creating a
>>>
>>>VC4
>>>
>>>
>>>>>FA
>>>>>
>>>>>
>>>>>
>>>>>>>LSP that starts and stops in the middle of TDM region to carry
> 
> several
> 
>>>>>VC12
>>>>>
>>>>>
>>>>>
>>>>>>>LSPs. Furthermore, stitching FA is a special case of FA when it is
> 
> used
> 
>>>>>by
>>>>>
>>>>>
>>>>>
>>>>>>>LSPs of the same layer as one where the FA-LSP was created. As for
>>>>>
>>>>>triggers,
>>>>>
>>>>>
>>>>>
>>>>>>>there could be multiple ones for setting up/tearing down stitching
>>>>>
>>>>>FA-LSPs:
>>>>>
>>>>>
>>>>>
>>>>>>>configuration, receiving setup request for inter-domain LSP, other
>>>>>
>>>>>policies.
>>>>>
>>>>>
>>>>>
>>>>>>>Igor
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>More on a) later.
>>>>>>>>
>>>>>>>>thanks,
>>>>>>>>-arthi
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>.
>>>>>>>
>>>>>>
>>>>>.
>>>>>
>>>>
>>>
>>>.
>>>
>>
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 19:39:43 +0000
Message-ID: <001e01c51528$4959bc60$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, <[e-mail]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Date: Thu, 17 Feb 2005 14:38:41 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dimitri,

For the second time you are saying that I don't see the issue that you are
pointed out and this is beginning to annoy me.

Your point/question is very simple, which is what does it give to advertise
stitching segments as FAs, is that correct?

My answers are very simple either:

1) How else are you going to use statically provisioned segments as part of
dynamically provisioned end-to-end LSPs ?
2) How else you can accomplish a transition strategy when some of the nodes
that are going to be involved in end-to-end dynamically provisioned LSPs do
not have proper signaling software? The specific example is using LSRs that
do not support p2mp signaling as transit nodes in p2mp LSPs. Your point
about advertising of node capabilities is relevant only for routing - the
PCE computing p2mp tree may take in consideration the advertised node
capabilities and assume that stitching segments may be created dynamically
if needed. What if I don't want them to be dynamically created and rather
have them pre-provisioned to spead up the process of p2mp tunnel setup and
decrease blocking probability?
3) What if I want to attract certain LSPs  to use pre-provisioned segments
even if the overall cost of such LSPs would be higher than if they would
take paths computed without consideration of these segments, but it is
desirable for the LSPs to use the segments anyway. Exanple: the segments are
provisioned to satisfy wavelength continuity constraint and I don't have PCE
that can perform path computation with such contraint on path segments
between points of OEO.

Igor





----- Original Message ----- 
From: "dimitri papadimitriou" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>; "Arthi Ayyangar"
<[e-mail]>; <[e-mail]>
Sent: Thursday, February 17, 2005 1:19 PM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt


>
>
> Igor Bryskin wrote:
>
> > dimitri, see in line.
> >
> > ----- Original Message ----- 
> > From: "dimitri papadimitriou" <[e-mail]>
> > To: "Igor Bryskin" <[e-mail]>
> > Cc: <[e-mail]>; "Arthi Ayyangar"
> > <[e-mail]>; <[e-mail]>
> > Sent: Thursday, February 17, 2005 11:40 AM
> > Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
> >
> >
> >
> >>igor - see in-line
> >>
> >>
> >>>>>>Please see my replies (AA--->) inline.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>---------> An LSP segment may be created either by configuration
or
> >>>>>>>>due to arrival of an e2e LSP setup request itself. Similar to an
FA,
> >
> > an
> >
> >>>>>>>>LSP segment may or may not be advertised as a TE link. But, if
> >>>>>>>>pre-created, it could be advertised, in which case other nodes may
> >>>>>>>>compute a path over it.
> >>>>>>>>
> >>>>>>>>Why would you want to or not want to advertise an FA ?
> >>>>>>>
> >>>>>>>i understand the point on pre-created <-> advertised but this
> >
> > knowledge
> >
> >>>>>>>may be useful for nodes part of the same area (not for nodes
external
> >>>>>>>to this area)
> >>>>>>
> >>>>>>AA -------> Absolutely ...this definitely cannot be advertised
outside
> >>>>>>the area (domain). I think this has been explicitly mentioned.
> >>>>>>
> >>>>>>so in case a node for inst. advertises three terminating
> >>>>>>
> >>>>>>
> >>>>>>>links with PSC-2 (one of these being the LSP segment) then a
another
> >>>>>>>node (part of the same area) receiving an incoming multi-area PSC-2
> >
> > LSP
> >
> >>>>>>>request may start making use of this segment to join the next
border,
> >>>>>>>therefore advertisement of the LSP segment may create a multi-hop
> >>>>>>>condition, but now once used relevance of the existence of the
> >
> > segment
> >
> >>>>>>>is not a useful information (for the area) as there is no
possibility
> >>>>>>>to make re-use of it except when the end-to-end LSP is torn down
> >>>>>>
> >>>>>>AA----------> I understand your point that once an LSP has been
> >
> > admitted
> >
> >>>>>>into an LSP segment it is no longer usable by other nodes in that
> >
> > area.
> >
> >>>>>>But would you rather stop advertising the link at this point, if you
> >>>>>>were previously advertising it ? Don't you think that is a big
hammer
> >
> > ? E.g.
> >
> >>>>>>how would a head end which has indeed computed a path over that LSP
> >>>>>>segment differentiate this event from an LSP segment down event
where
> >>>>>>the link is deleted from the database ? So, all the document says
> >
> > today is
> >
> >>>>>>that you set the unreserved bw on the LSP segment to zero. The idea
is
> >>>>>>to still let other nodes know that the link exists but is unusable.
It
> >
> > is
> >
> >>>>>>not different from a FA-LSP being consumed...in that case we don't
> >
> > stop
> >
> >>>>>>advertising the FA (if we were doing so previously), right ?
> >>>>>
> >>>>>IB>> Completley agree with Arthi. Besides, several parallel stitching
> >>>>>segments could be advertised as a single bundle - hence, using the
> >>>>>advertised link by one LSP does not necessarily take away all link's
> >>>>>bandwidth.
> >>>>
> >>>>you don't understand the question, it is do we have to consider as
> >>>>default behavior that a pre-provisioned is to be "advertized"
> >>>
> >>>IB>> My point was that I do not see any difference in this respect
> >
> > between
> >
> >>>the sticthing FA-LSP (the same layer FA-LSP) and FA-LSP created in the
> >
> > lower
> >
> >>>layer. Besides, what do you mean by the default behaviour? The fact
> >
> > whether
> >
> >>>to advertise//remove FA TE link is a policy driven carefully thought
> >
> > through
> >
> >>>decision, a dnagerous one that could potentially destabilize the
> >
> > network.
> >
> >>>I'd say that the default behaviour is "NOT ADVERTISE" in either case.
> >>>
> >>>
> >>>>now beside the fact that there are techniques to do so what would be
the
> >>>>purpose of it ? and what it the overhead that such advertisement would
> >>>>create - that can be of course decreased by bundling them -
> >>>
> >>>IB>> The purpose is exactly the same as for any other FA-LSP - add
> >>>flexibility in a particular layer.
> >>
> >>which flexibility are we expecting here, this "segment" can accommodate
> >>exactly one incoming request -
> >
> >
> > IB>> Disagree - the segment could be a component link within a bundle.
In
> > this case stitching FA TE link may accomodate multiple LSPs
> >
> >  additionally only nodes part of the same
> >
> >>area can make use of this advertisement -
> >
> >
> > IB>> Who said that sticthing segments must necessarily terminate on
domain
> > borders? There could be multiple reasons why a network operator could
> > pre-provision (dynamically or statically) LSP segments inside his
network
> > and advertise them (as bundles or individually) as TE links to be used
for
> > specific TE purposes.
>
> it is exactly these purposes that i am looking for
>
> > so in fact what it would allow
> >
> >>is the possibility to avoid creation of a segment if the edge node
> >>receiving the request re-orients its request to the head-end for this
> >>advertisement
> >>                         |
> >>example:      ----------D----------
> >>              |                     |
> >>            - A ---- Segment 1 ---- B -
> >>              |                     |
> >>               ----------C----------
> >>                         |
> >>
> >>you would have a segment between A-B that could be reached from C (the
> >>node receiving the incoming request) decides to make use of this segment
> >>  to reach B (so you would have C-A-B) but if this was the best path why
> >>not creating directly a segment C-A-B, instead of now having one segment
> >>C-A, the pre-provisioned A-B and probably one on top of it C-A-B ?
> >
> >
> > IB>> See my comment above. I might want to use statically provisioned
> > segments. I might want to use nodes that do not have proper signaling
> > software.
>
> what does that mean "proper signaling software"
>
> > For instance, recall the discussions on P2MP and how we want use legacy
LSRs
> > to be part of P2MP tunnels
>
> but in this case there is a flag telling capabilities of the nodes in
> order to allow for dynamically trigger the segment
>
> >>in case of classical FA-LSP it makes sense to advertize the FA link
> >>because it represents a lower region LSP (with usually a given ratio of
> >>unreserved bandwidth that makes worth advertizing the FA link) but in
> >>case of a segment i do have some difficulties to excatly see where this
> >>flexibility would deliver ?
> >
> >
> > IB>> Again, if you imagine that several parallel sticthing segments are
> > advertised as as single FA, how it would be different from the bandwidth
> > usage point of view compared to advertising lower layer FA ?
>
> issues are different - FAs are used in manner to preferentially attract
> over them because - i am still looking for the reason for attracting
> over a bundle
>
> > In fact it would be even more useful, because in case of lower layer FA
you need also
> > to advertise termination/adaptation capabilities, while in case of
stitching
> > FA no addaptation is required.
>
> by the way you don't seem to see the issue that i am pointing out, so
> probably there is a need to go in more detailed examples before drawing
> the above confusing conclusion
>
> > Igor
> >
> >>thanks,
> >>- dimitri.
> >>
> >>
> >>>>thanks,
> >>>>- dimitri.
> >>>>
> >>>>
> >>>>
> >>>>>>>a more technical point is related to the definition of an FA LSP
> >
> > which
> >
> >>>>>>>per LSP-Hierarchy mandates crossing LSP region border: the head-end
> >
> > and
> >
> >>>>>>>tail-end switching capability represent the SC of the resulting TE
> >
> > link
> >
> >>>>>>>while intermediate node terminates the SC corr. to the switching
type
> >>>
> >>>of
> >>>
> >>>
> >>>>>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a
PSC-2
> >>>>>>>capable network with first and last link being [PSC-1,PSC-2] and
> >>>>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would have
> >
> > now
> >
> >>>>>>>the creation of a [PSC-1,PSC-1] link with first and last link being
> >>>>>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border
> >>>>>>>crossing anymore - so here the question is about definition and
> >>>>>>>detailing the triggers
> >>>>>>
> >>>>>>AA--------> As far as trigger for setting up an LSP segment is
> >>>
> >>>concerned,
> >>>
> >>>
> >>>>>>I agree that there is no longer the notion of "crossing region
> >>>>>>boundaries". I realize that the document doesn't discuss this,
> >>>
> >>>especially
> >>>
> >>>
> >>>>>>given that we are doing other comparisons with FA LSPs. So, I will
add
> >>>>>>this discussion in the next revision. I think in case of LSP segment
> >
> > the
> >
> >>>>>>trigger for LSP segment setup would come from a) successful
switching
> >>>
> >>>type
> >>>
> >>>
> >>>>>>and switching capability match and b) some local policy on the node
> >>>
> >>>which
> >>>
> >>>
> >>>>>>dictates the setting up of an LSP segment.
> >>>>>>
> >>>>>
> >>>>>
> >>>>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and could be
> >>>>>challenged in many ways. FA LSP is, generally speaking, created on a
> >>>
> >>>layer
> >>>
> >>>
> >>>>>boundary rather than on region boundary: nothing prevents creating a
> >
> > VC4
> >
> >>>FA
> >>>
> >>>
> >>>>>LSP that starts and stops in the middle of TDM region to carry
several
> >>>
> >>>VC12
> >>>
> >>>
> >>>>>LSPs. Furthermore, stitching FA is a special case of FA when it is
used
> >>>
> >>>by
> >>>
> >>>
> >>>>>LSPs of the same layer as one where the FA-LSP was created. As for
> >>>
> >>>triggers,
> >>>
> >>>
> >>>>>there could be multiple ones for setting up/tearing down stitching
> >>>
> >>>FA-LSPs:
> >>>
> >>>
> >>>>>configuration, receiving setup request for inter-domain LSP, other
> >>>
> >>>policies.
> >>>
> >>>
> >>>>>Igor
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>More on a) later.
> >>>>>>
> >>>>>>thanks,
> >>>>>>-arthi
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>.
> >>>>>
> >>>>
> >>>
> >>>.
> >>>
> >>
> >
> >
> > .
> >
>




Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 18:35:27 +0000
Message-ID: <[e-mail]>
Date: Thu, 17 Feb 2005 19:34:26 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Arthi Ayyangar <[e-mail]>
CC: Igor Bryskin <[e-mail]>,  [e-mail],  [e-mail]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

arthi:

>>>which flexibility are we expecting here, this "segment" can accommodate
>>>exactly one incoming request -
>>
>>IB>> Disagree - the segment could be a component link within a bundle. In
>>this case stitching FA TE link may accomodate multiple LSPs
>>
>> additionally only nodes part of the same
>>
>>>area can make use of this advertisement -
> 
> AA-----> I agree with Igor...one of the reasons you advertise an FA is
> to attract traffic over that FA, note that it is advertised with
> TE metric = (TE metric of FA LSP path - 1) ..... I would think this would
> also be the reason to advertise an LSP segment, IF this is desired. Again,
> note that this decision is completely local to the node originating the
> LSP segment and would be dictated by some policy.

i obviously understand that policy triggers of not such behaviour, the 
issue i point out is one of the case that could be of interest for inst. 
multiple path comp. domains within the same area generate the issue of 
the flooding scope within that area (as the computational domain does 
not scope the flooding) for the purpose being of attracting on specific 
segments how to prevent node within the inner "domain" to make use of 
these segments

this said, in case an advertisement is to be considered rules should 
also be defined in terms of parameters that would require to be inherited

>>IB>> Who said that sticthing segments must necessarily terminate on domain
>>borders? There could be multiple reasons why a network operator could
>>pre-provision (dynamically or statically) LSP segments inside his network
>>and advertise them (as bundles or individually) as TE links to be used for
>>specific TE purposes.
> 
> AA----------> Agreed.
> 
> thanks,
> -arthi
> 
> 
>>IB>> See my comment above. I might want to use statically provisioned
>>segments. I might want to use nodes that do not have proper signaling
>>software.
>>For instance, recall the discussions on P2MP and how we want use legacy LSRs
>>to be part of P2MP tunnels
> 
> AA-------> Absolutely.
> 
> 
>>>in case of classical FA-LSP it makes sense to advertize the FA link
>>>because it represents a lower region LSP (with usually a given ratio of
>>>unreserved bandwidth that makes worth advertizing the FA link) but in
>>>case of a segment i do have some difficulties to excatly see where this
>>>flexibility would deliver ?
>>
>>IB>> Again, if you imagine that several parallel sticthing segments are
>>advertised as as single FA, how it would be different from the bandwidth
>>usage point of view compared to advertising lower layer FA ? In fact it
>>would be even more useful, because in case of lower layer FA you need also
>>to advertise termination/adaptation capabilities, while in case of stitching
>>FA no addaptation is required.
>>
>>Igor
>>
>>>thanks,
>>>- dimitri.
>>>
>>>
>>>>>thanks,
>>>>>- dimitri.
>>>>>
>>>>>
>>>>>
>>>>>>>>a more technical point is related to the definition of an FA LSP
>>
>>which
>>
>>>>>>>>per LSP-Hierarchy mandates crossing LSP region border: the head-end
>>
>>and
>>
>>>>>>>>tail-end switching capability represent the SC of the resulting TE
>>
>>link
>>
>>>>>>>>while intermediate node terminates the SC corr. to the switching type
>>>>
>>>>of
>>>>
>>>>
>>>>>>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a PSC-2
>>>>>>>>capable network with first and last link being [PSC-1,PSC-2] and
>>>>>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would have
>>
>>now
>>
>>>>>>>>the creation of a [PSC-1,PSC-1] link with first and last link being
>>>>>>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border
>>>>>>>>crossing anymore - so here the question is about definition and
>>>>>>>>detailing the triggers
>>>>>>>
>>>>>>>AA--------> As far as trigger for setting up an LSP segment is
>>>>
>>>>concerned,
>>>>
>>>>
>>>>>>>I agree that there is no longer the notion of "crossing region
>>>>>>>boundaries". I realize that the document doesn't discuss this,
>>>>
>>>>especially
>>>>
>>>>
>>>>>>>given that we are doing other comparisons with FA LSPs. So, I will add
>>>>>>>this discussion in the next revision. I think in case of LSP segment
>>
>>the
>>
>>>>>>>trigger for LSP segment setup would come from a) successful switching
>>>>
>>>>type
>>>>
>>>>
>>>>>>>and switching capability match and b) some local policy on the node
>>>>
>>>>which
>>>>
>>>>
>>>>>>>dictates the setting up of an LSP segment.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and could be
>>>>>>challenged in many ways. FA LSP is, generally speaking, created on a
>>>>
>>>>layer
>>>>
>>>>
>>>>>>boundary rather than on region boundary: nothing prevents creating a
>>
>>VC4
>>
>>>>FA
>>>>
>>>>
>>>>>>LSP that starts and stops in the middle of TDM region to carry several
>>>>
>>>>VC12
>>>>
>>>>
>>>>>>LSPs. Furthermore, stitching FA is a special case of FA when it is used
>>>>
>>>>by
>>>>
>>>>
>>>>>>LSPs of the same layer as one where the FA-LSP was created. As for
>>>>
>>>>triggers,
>>>>
>>>>
>>>>>>there could be multiple ones for setting up/tearing down stitching
>>>>
>>>>FA-LSPs:
>>>>
>>>>
>>>>>>configuration, receiving setup request for inter-domain LSP, other
>>>>
>>>>policies.
>>>>
>>>>
>>>>>>Igor
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>More on a) later.
>>>>>>>
>>>>>>>thanks,
>>>>>>>-arthi
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>.
>>>>>>
>>>>>
>>>>
>>>>.
>>>>
>>>
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 18:21:38 +0000
Message-ID: <[e-mail]>
Date: Thu, 17 Feb 2005 19:20:56 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Arthi Ayyangar <[e-mail]>
CC: Igor Bryskin <[e-mail]>,  [e-mail],  [e-mail]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

arthi

Arthi Ayyangar wrote:

> Igor, Dimitri,
> 
> 
>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and could be
>>challenged in many ways. FA LSP is, generally speaking, created on a layer
>>boundary rather than on region boundary: nothing prevents creating a VC4 FA
>>LSP that starts and stops in the middle of TDM region to carry several VC12
>>LSPs. Furthermore, stitching FA is a special case of FA when it is used by
>>LSPs of the same layer as one where the FA-LSP was created. As for triggers,
>>there could be multiple ones for setting up/tearing down stitching FA-LSPs:
>>configuration, receiving setup request for inter-domain LSP, other policies.
> 
> AA>--------> I agree...in fact I also absolutely agree that LSP segment
> end points do NOT have to be domain boundaries. In fact there could be
> other reasons for creating LSP segments spanning a bunch of nodes...one
> application that has also been refered to in the document, say P2MP, for
> preventing legacy LSRs from being in the path of P2MP tunnels.

for this specific point of stitching segments to "tunnel" P2MP branches, 
i thought we would make use of the node capability flags to determine 
the head and tail-end of the segment - is that assumption still being 
considered ?

thanks,
- dimitri.

> thanks,
> -arthi
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 18:20:08 +0000
Message-ID: <[e-mail]>
Date: Thu, 17 Feb 2005 19:19:02 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC:  [e-mail], Arthi Ayyangar <[e-mail]>,  [e-mail]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Igor Bryskin wrote:

> dimitri, see in line.
> 
> ----- Original Message ----- 
> From: "dimitri papadimitriou" <[e-mail]>
> To: "Igor Bryskin" <[e-mail]>
> Cc: <[e-mail]>; "Arthi Ayyangar"
> <[e-mail]>; <[e-mail]>
> Sent: Thursday, February 17, 2005 11:40 AM
> Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
> 
> 
> 
>>igor - see in-line
>>
>>
>>>>>>Please see my replies (AA--->) inline.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>---------> An LSP segment may be created either by configuration or
>>>>>>>>due to arrival of an e2e LSP setup request itself. Similar to an FA,
> 
> an
> 
>>>>>>>>LSP segment may or may not be advertised as a TE link. But, if
>>>>>>>>pre-created, it could be advertised, in which case other nodes may
>>>>>>>>compute a path over it.
>>>>>>>>
>>>>>>>>Why would you want to or not want to advertise an FA ?
>>>>>>>
>>>>>>>i understand the point on pre-created <-> advertised but this
> 
> knowledge
> 
>>>>>>>may be useful for nodes part of the same area (not for nodes external
>>>>>>>to this area)
>>>>>>
>>>>>>AA -------> Absolutely ...this definitely cannot be advertised outside
>>>>>>the area (domain). I think this has been explicitly mentioned.
>>>>>>
>>>>>>so in case a node for inst. advertises three terminating
>>>>>>
>>>>>>
>>>>>>>links with PSC-2 (one of these being the LSP segment) then a another
>>>>>>>node (part of the same area) receiving an incoming multi-area PSC-2
> 
> LSP
> 
>>>>>>>request may start making use of this segment to join the next border,
>>>>>>>therefore advertisement of the LSP segment may create a multi-hop
>>>>>>>condition, but now once used relevance of the existence of the
> 
> segment
> 
>>>>>>>is not a useful information (for the area) as there is no possibility
>>>>>>>to make re-use of it except when the end-to-end LSP is torn down
>>>>>>
>>>>>>AA----------> I understand your point that once an LSP has been
> 
> admitted
> 
>>>>>>into an LSP segment it is no longer usable by other nodes in that
> 
> area.
> 
>>>>>>But would you rather stop advertising the link at this point, if you
>>>>>>were previously advertising it ? Don't you think that is a big hammer
> 
> ? E.g.
> 
>>>>>>how would a head end which has indeed computed a path over that LSP
>>>>>>segment differentiate this event from an LSP segment down event where
>>>>>>the link is deleted from the database ? So, all the document says
> 
> today is
> 
>>>>>>that you set the unreserved bw on the LSP segment to zero. The idea is
>>>>>>to still let other nodes know that the link exists but is unusable. It
> 
> is
> 
>>>>>>not different from a FA-LSP being consumed...in that case we don't
> 
> stop
> 
>>>>>>advertising the FA (if we were doing so previously), right ?
>>>>>
>>>>>IB>> Completley agree with Arthi. Besides, several parallel stitching
>>>>>segments could be advertised as a single bundle - hence, using the
>>>>>advertised link by one LSP does not necessarily take away all link's
>>>>>bandwidth.
>>>>
>>>>you don't understand the question, it is do we have to consider as
>>>>default behavior that a pre-provisioned is to be "advertized"
>>>
>>>IB>> My point was that I do not see any difference in this respect
> 
> between
> 
>>>the sticthing FA-LSP (the same layer FA-LSP) and FA-LSP created in the
> 
> lower
> 
>>>layer. Besides, what do you mean by the default behaviour? The fact
> 
> whether
> 
>>>to advertise//remove FA TE link is a policy driven carefully thought
> 
> through
> 
>>>decision, a dnagerous one that could potentially destabilize the
> 
> network.
> 
>>>I'd say that the default behaviour is "NOT ADVERTISE" in either case.
>>>
>>>
>>>>now beside the fact that there are techniques to do so what would be the
>>>>purpose of it ? and what it the overhead that such advertisement would
>>>>create - that can be of course decreased by bundling them -
>>>
>>>IB>> The purpose is exactly the same as for any other FA-LSP - add
>>>flexibility in a particular layer.
>>
>>which flexibility are we expecting here, this "segment" can accommodate
>>exactly one incoming request -
> 
> 
> IB>> Disagree - the segment could be a component link within a bundle. In
> this case stitching FA TE link may accomodate multiple LSPs
> 
>  additionally only nodes part of the same
> 
>>area can make use of this advertisement -
> 
> 
> IB>> Who said that sticthing segments must necessarily terminate on domain
> borders? There could be multiple reasons why a network operator could
> pre-provision (dynamically or statically) LSP segments inside his network
> and advertise them (as bundles or individually) as TE links to be used for
> specific TE purposes.

it is exactly these purposes that i am looking for

> so in fact what it would allow
> 
>>is the possibility to avoid creation of a segment if the edge node
>>receiving the request re-orients its request to the head-end for this
>>advertisement
>>                         |
>>example:      ----------D----------
>>              |                     |
>>            - A ---- Segment 1 ---- B -
>>              |                     |
>>               ----------C----------
>>                         |
>>
>>you would have a segment between A-B that could be reached from C (the
>>node receiving the incoming request) decides to make use of this segment
>>  to reach B (so you would have C-A-B) but if this was the best path why
>>not creating directly a segment C-A-B, instead of now having one segment
>>C-A, the pre-provisioned A-B and probably one on top of it C-A-B ?
> 
> 
> IB>> See my comment above. I might want to use statically provisioned
> segments. I might want to use nodes that do not have proper signaling
> software.

what does that mean "proper signaling software"

> For instance, recall the discussions on P2MP and how we want use legacy LSRs
> to be part of P2MP tunnels

but in this case there is a flag telling capabilities of the nodes in 
order to allow for dynamically trigger the segment

>>in case of classical FA-LSP it makes sense to advertize the FA link
>>because it represents a lower region LSP (with usually a given ratio of
>>unreserved bandwidth that makes worth advertizing the FA link) but in
>>case of a segment i do have some difficulties to excatly see where this
>>flexibility would deliver ?
> 
> 
> IB>> Again, if you imagine that several parallel sticthing segments are
> advertised as as single FA, how it would be different from the bandwidth
> usage point of view compared to advertising lower layer FA ? 

issues are different - FAs are used in manner to preferentially attract 
over them because - i am still looking for the reason for attracting 
over a bundle

> In fact it would be even more useful, because in case of lower layer FA you need also
> to advertise termination/adaptation capabilities, while in case of stitching
> FA no addaptation is required.

by the way you don't seem to see the issue that i am pointing out, so 
probably there is a need to go in more detailed examples before drawing 
the above confusing conclusion

> Igor
> 
>>thanks,
>>- dimitri.
>>
>>
>>>>thanks,
>>>>- dimitri.
>>>>
>>>>
>>>>
>>>>>>>a more technical point is related to the definition of an FA LSP
> 
> which
> 
>>>>>>>per LSP-Hierarchy mandates crossing LSP region border: the head-end
> 
> and
> 
>>>>>>>tail-end switching capability represent the SC of the resulting TE
> 
> link
> 
>>>>>>>while intermediate node terminates the SC corr. to the switching type
>>>
>>>of
>>>
>>>
>>>>>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a PSC-2
>>>>>>>capable network with first and last link being [PSC-1,PSC-2] and
>>>>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would have
> 
> now
> 
>>>>>>>the creation of a [PSC-1,PSC-1] link with first and last link being
>>>>>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border
>>>>>>>crossing anymore - so here the question is about definition and
>>>>>>>detailing the triggers
>>>>>>
>>>>>>AA--------> As far as trigger for setting up an LSP segment is
>>>
>>>concerned,
>>>
>>>
>>>>>>I agree that there is no longer the notion of "crossing region
>>>>>>boundaries". I realize that the document doesn't discuss this,
>>>
>>>especially
>>>
>>>
>>>>>>given that we are doing other comparisons with FA LSPs. So, I will add
>>>>>>this discussion in the next revision. I think in case of LSP segment
> 
> the
> 
>>>>>>trigger for LSP segment setup would come from a) successful switching
>>>
>>>type
>>>
>>>
>>>>>>and switching capability match and b) some local policy on the node
>>>
>>>which
>>>
>>>
>>>>>>dictates the setting up of an LSP segment.
>>>>>>
>>>>>
>>>>>
>>>>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and could be
>>>>>challenged in many ways. FA LSP is, generally speaking, created on a
>>>
>>>layer
>>>
>>>
>>>>>boundary rather than on region boundary: nothing prevents creating a
> 
> VC4
> 
>>>FA
>>>
>>>
>>>>>LSP that starts and stops in the middle of TDM region to carry several
>>>
>>>VC12
>>>
>>>
>>>>>LSPs. Furthermore, stitching FA is a special case of FA when it is used
>>>
>>>by
>>>
>>>
>>>>>LSPs of the same layer as one where the FA-LSP was created. As for
>>>
>>>triggers,
>>>
>>>
>>>>>there could be multiple ones for setting up/tearing down stitching
>>>
>>>FA-LSPs:
>>>
>>>
>>>>>configuration, receiving setup request for inter-domain LSP, other
>>>
>>>policies.
>>>
>>>
>>>>>Igor
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>More on a) later.
>>>>>>
>>>>>>thanks,
>>>>>>-arthi
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>.
>>>>>
>>>>
>>>
>>>.
>>>
>>
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 17:59:53 +0000
Date: Thu, 17 Feb 2005 09:58:57 -0800 (PST)
From: Arthi Ayyangar <[e-mail]>
To: Igor Bryskin <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Igor, Dimitri,


> > which flexibility are we expecting here, this "segment" can accommodate
> > exactly one incoming request -
>
> IB>> Disagree - the segment could be a component link within a bundle. In
> this case stitching FA TE link may accomodate multiple LSPs
>
>  additionally only nodes part of the same
> > area can make use of this advertisement -
AA-----> I agree with Igor...one of the reasons you advertise an FA is
to attract traffic over that FA, note that it is advertised with
TE metric = (TE metric of FA LSP path - 1) ..... I would think this would
also be the reason to advertise an LSP segment, IF this is desired. Again,
note that this decision is completely local to the node originating the
LSP segment and would be dictated by some policy.

> IB>> Who said that sticthing segments must necessarily terminate on domain
> borders? There could be multiple reasons why a network operator could
> pre-provision (dynamically or statically) LSP segments inside his network
> and advertise them (as bundles or individually) as TE links to be used for
> specific TE purposes.
AA----------> Agreed.

thanks,
-arthi

> IB>> See my comment above. I might want to use statically provisioned
> segments. I might want to use nodes that do not have proper signaling
> software.
> For instance, recall the discussions on P2MP and how we want use legacy LSRs
> to be part of P2MP tunnels
AA-------> Absolutely.

> >
> > in case of classical FA-LSP it makes sense to advertize the FA link
> > because it represents a lower region LSP (with usually a given ratio of
> > unreserved bandwidth that makes worth advertizing the FA link) but in
> > case of a segment i do have some difficulties to excatly see where this
> > flexibility would deliver ?
>
> IB>> Again, if you imagine that several parallel sticthing segments are
> advertised as as single FA, how it would be different from the bandwidth
> usage point of view compared to advertising lower layer FA ? In fact it
> would be even more useful, because in case of lower layer FA you need also
> to advertise termination/adaptation capabilities, while in case of stitching
> FA no addaptation is required.
>
> Igor
> >
> > thanks,
> > - dimitri.
> >
> > >>thanks,
> > >>- dimitri.
> > >>
> > >>
> > >>>>>a more technical point is related to the definition of an FA LSP
> which
> > >>>>>per LSP-Hierarchy mandates crossing LSP region border: the head-end
> and
> > >>>>>tail-end switching capability represent the SC of the resulting TE
> link
> > >>>>>while intermediate node terminates the SC corr. to the switching type
> > >
> > > of
> > >
> > >>>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a PSC-2
> > >>>>>capable network with first and last link being [PSC-1,PSC-2] and
> > >>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would have
> now
> > >>>>>the creation of a [PSC-1,PSC-1] link with first and last link being
> > >>>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border
> > >>>>>crossing anymore - so here the question is about definition and
> > >>>>>detailing the triggers
> > >>>>
> > >>>>AA--------> As far as trigger for setting up an LSP segment is
> > >
> > > concerned,
> > >
> > >>>>I agree that there is no longer the notion of "crossing region
> > >>>>boundaries". I realize that the document doesn't discuss this,
> > >
> > > especially
> > >
> > >>>>given that we are doing other comparisons with FA LSPs. So, I will add
> > >>>>this discussion in the next revision. I think in case of LSP segment
> the
> > >>>>trigger for LSP segment setup would come from a) successful switching
> > >
> > > type
> > >
> > >>>>and switching capability match and b) some local policy on the node
> > >
> > > which
> > >
> > >>>>dictates the setting up of an LSP segment.
> > >>>>
> > >>>
> > >>>
> > >>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and could be
> > >>>challenged in many ways. FA LSP is, generally speaking, created on a
> > >
> > > layer
> > >
> > >>>boundary rather than on region boundary: nothing prevents creating a
> VC4
> > >
> > > FA
> > >
> > >>>LSP that starts and stops in the middle of TDM region to carry several
> > >
> > > VC12
> > >
> > >>>LSPs. Furthermore, stitching FA is a special case of FA when it is used
> > >
> > > by
> > >
> > >>>LSPs of the same layer as one where the FA-LSP was created. As for
> > >
> > > triggers,
> > >
> > >>>there could be multiple ones for setting up/tearing down stitching
> > >
> > > FA-LSPs:
> > >
> > >>>configuration, receiving setup request for inter-domain LSP, other
> > >
> > > policies.
> > >
> > >>>Igor
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>More on a) later.
> > >>>>
> > >>>>thanks,
> > >>>>-arthi
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>.
> > >>>
> > >>
> > >
> > >
> > > .
> > >
> >
>



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 17:50:53 +0000
Date: Thu, 17 Feb 2005 09:49:30 -0800 (PST)
From: Arthi Ayyangar <[e-mail]>
To: Igor Bryskin <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Igor, Dimitri,

> IB>> I have a comment here. LSP-Hierarchy is not a Bible and could be
> challenged in many ways. FA LSP is, generally speaking, created on a layer
> boundary rather than on region boundary: nothing prevents creating a VC4 FA
> LSP that starts and stops in the middle of TDM region to carry several VC12
> LSPs. Furthermore, stitching FA is a special case of FA when it is used by
> LSPs of the same layer as one where the FA-LSP was created. As for triggers,
> there could be multiple ones for setting up/tearing down stitching FA-LSPs:
> configuration, receiving setup request for inter-domain LSP, other policies.
AA>--------> I agree...in fact I also absolutely agree that LSP segment
end points do NOT have to be domain boundaries. In fact there could be
other reasons for creating LSP segments spanning a bunch of nodes...one
application that has also been refered to in the document, say P2MP, for
preventing legacy LSRs from being in the path of P2MP tunnels.


thanks,
-arthi



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 17:39:55 +0000
Message-ID: <000801c51517$9bd69690$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Arthi Ayyangar" <[e-mail]>, <[e-mail]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Date: Thu, 17 Feb 2005 12:39:18 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

dimitri, see in line.

----- Original Message ----- 
From: "dimitri papadimitriou" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: <[e-mail]>; "Arthi Ayyangar"
<[e-mail]>; <[e-mail]>
Sent: Thursday, February 17, 2005 11:40 AM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt


> igor - see in-line
>
> >>>>Please see my replies (AA--->) inline.
> >>>>
> >>>>
> >>>>
> >>>>>>---------> An LSP segment may be created either by configuration or
> >>>>>>due to arrival of an e2e LSP setup request itself. Similar to an FA,
an
> >>>>>>LSP segment may or may not be advertised as a TE link. But, if
> >>>>>>pre-created, it could be advertised, in which case other nodes may
> >>>>>>compute a path over it.
> >>> >>>
> >>>>>>Why would you want to or not want to advertise an FA ?
> >>>>>
> >>>>>i understand the point on pre-created <-> advertised but this
knowledge
> >>>>>may be useful for nodes part of the same area (not for nodes external
> >>>>>to this area)
> >>>>
> >>>>AA -------> Absolutely ...this definitely cannot be advertised outside
> >>>>the area (domain). I think this has been explicitly mentioned.
> >>>>
> >>>>so in case a node for inst. advertises three terminating
> >>>>
> >>>>>links with PSC-2 (one of these being the LSP segment) then a another
> >>>>>node (part of the same area) receiving an incoming multi-area PSC-2
LSP
> >>>>>request may start making use of this segment to join the next border,
> >>>>>therefore advertisement of the LSP segment may create a multi-hop
> >>>>>condition, but now once used relevance of the existence of the
segment
> >>>>>is not a useful information (for the area) as there is no possibility
> >>>>>to make re-use of it except when the end-to-end LSP is torn down
> >>>>
> >>>>AA----------> I understand your point that once an LSP has been
admitted
> >>>>into an LSP segment it is no longer usable by other nodes in that
area.
> >>>>But would you rather stop advertising the link at this point, if you
> >>>>were previously advertising it ? Don't you think that is a big hammer
? E.g.
> >>>>how would a head end which has indeed computed a path over that LSP
> >>>>segment differentiate this event from an LSP segment down event where
> >>>>the link is deleted from the database ? So, all the document says
today is
> >>>>that you set the unreserved bw on the LSP segment to zero. The idea is
> >>>>to still let other nodes know that the link exists but is unusable. It
is
> >>>>not different from a FA-LSP being consumed...in that case we don't
stop
> >>>>advertising the FA (if we were doing so previously), right ?
> >>>
> >>>IB>> Completley agree with Arthi. Besides, several parallel stitching
> >>>segments could be advertised as a single bundle - hence, using the
> >>>advertised link by one LSP does not necessarily take away all link's
> >>>bandwidth.
> >>
> >>you don't understand the question, it is do we have to consider as
> >>default behavior that a pre-provisioned is to be "advertized"
> >
> > IB>> My point was that I do not see any difference in this respect
between
> > the sticthing FA-LSP (the same layer FA-LSP) and FA-LSP created in the
lower
> > layer. Besides, what do you mean by the default behaviour? The fact
whether
> > to advertise//remove FA TE link is a policy driven carefully thought
through
> > decision, a dnagerous one that could potentially destabilize the
network.
> > I'd say that the default behaviour is "NOT ADVERTISE" in either case.
> >
> >>now beside the fact that there are techniques to do so what would be the
> >>purpose of it ? and what it the overhead that such advertisement would
> >>create - that can be of course decreased by bundling them -
> >
> > IB>> The purpose is exactly the same as for any other FA-LSP - add
> > flexibility in a particular layer.
>
> which flexibility are we expecting here, this "segment" can accommodate
> exactly one incoming request -

IB>> Disagree - the segment could be a component link within a bundle. In
this case stitching FA TE link may accomodate multiple LSPs

 additionally only nodes part of the same
> area can make use of this advertisement -

IB>> Who said that sticthing segments must necessarily terminate on domain
borders? There could be multiple reasons why a network operator could
pre-provision (dynamically or statically) LSP segments inside his network
and advertise them (as bundles or individually) as TE links to be used for
specific TE purposes.

so in fact what it would allow
> is the possibility to avoid creation of a segment if the edge node
> receiving the request re-orients its request to the head-end for this
> advertisement
>                          |
> example:      ----------D----------
>               |                     |
>             - A ---- Segment 1 ---- B -
>               |                     |
>                ----------C----------
>                          |
>
> you would have a segment between A-B that could be reached from C (the
> node receiving the incoming request) decides to make use of this segment
>   to reach B (so you would have C-A-B) but if this was the best path why
> not creating directly a segment C-A-B, instead of now having one segment
> C-A, the pre-provisioned A-B and probably one on top of it C-A-B ?

IB>> See my comment above. I might want to use statically provisioned
segments. I might want to use nodes that do not have proper signaling
software.
For instance, recall the discussions on P2MP and how we want use legacy LSRs
to be part of P2MP tunnels

>
> in case of classical FA-LSP it makes sense to advertize the FA link
> because it represents a lower region LSP (with usually a given ratio of
> unreserved bandwidth that makes worth advertizing the FA link) but in
> case of a segment i do have some difficulties to excatly see where this
> flexibility would deliver ?

IB>> Again, if you imagine that several parallel sticthing segments are
advertised as as single FA, how it would be different from the bandwidth
usage point of view compared to advertising lower layer FA ? In fact it
would be even more useful, because in case of lower layer FA you need also
to advertise termination/adaptation capabilities, while in case of stitching
FA no addaptation is required.

Igor
>
> thanks,
> - dimitri.
>
> >>thanks,
> >>- dimitri.
> >>
> >>
> >>>>>a more technical point is related to the definition of an FA LSP
which
> >>>>>per LSP-Hierarchy mandates crossing LSP region border: the head-end
and
> >>>>>tail-end switching capability represent the SC of the resulting TE
link
> >>>>>while intermediate node terminates the SC corr. to the switching type
> >
> > of
> >
> >>>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a PSC-2
> >>>>>capable network with first and last link being [PSC-1,PSC-2] and
> >>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would have
now
> >>>>>the creation of a [PSC-1,PSC-1] link with first and last link being
> >>>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border
> >>>>>crossing anymore - so here the question is about definition and
> >>>>>detailing the triggers
> >>>>
> >>>>AA--------> As far as trigger for setting up an LSP segment is
> >
> > concerned,
> >
> >>>>I agree that there is no longer the notion of "crossing region
> >>>>boundaries". I realize that the document doesn't discuss this,
> >
> > especially
> >
> >>>>given that we are doing other comparisons with FA LSPs. So, I will add
> >>>>this discussion in the next revision. I think in case of LSP segment
the
> >>>>trigger for LSP segment setup would come from a) successful switching
> >
> > type
> >
> >>>>and switching capability match and b) some local policy on the node
> >
> > which
> >
> >>>>dictates the setting up of an LSP segment.
> >>>>
> >>>
> >>>
> >>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and could be
> >>>challenged in many ways. FA LSP is, generally speaking, created on a
> >
> > layer
> >
> >>>boundary rather than on region boundary: nothing prevents creating a
VC4
> >
> > FA
> >
> >>>LSP that starts and stops in the middle of TDM region to carry several
> >
> > VC12
> >
> >>>LSPs. Furthermore, stitching FA is a special case of FA when it is used
> >
> > by
> >
> >>>LSPs of the same layer as one where the FA-LSP was created. As for
> >
> > triggers,
> >
> >>>there could be multiple ones for setting up/tearing down stitching
> >
> > FA-LSPs:
> >
> >>>configuration, receiving setup request for inter-domain LSP, other
> >
> > policies.
> >
> >>>Igor
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>More on a) later.
> >>>>
> >>>>thanks,
> >>>>-arthi
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>.
> >>>
> >>
> >
> >
> > .
> >
>




Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 16:41:21 +0000
Message-ID: <[e-mail]>
Date: Thu, 17 Feb 2005 17:40:21 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC:  [e-mail], Arthi Ayyangar <[e-mail]>,  [e-mail]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

igor - see in-line

>>>>Please see my replies (AA--->) inline.
>>>>
>>>>
>>>>
>>>>>>---------> An LSP segment may be created either by configuration or
>>>>>>due to arrival of an e2e LSP setup request itself. Similar to an FA, an
>>>>>>LSP segment may or may not be advertised as a TE link. But, if
>>>>>>pre-created, it could be advertised, in which case other nodes may 
>>>>>>compute a path over it.
>>> >>>
>>>>>>Why would you want to or not want to advertise an FA ?
>>>>>
>>>>>i understand the point on pre-created <-> advertised but this knowledge
>>>>>may be useful for nodes part of the same area (not for nodes external
>>>>>to this area)
>>>>
>>>>AA -------> Absolutely ...this definitely cannot be advertised outside
>>>>the area (domain). I think this has been explicitly mentioned.
>>>>
>>>>so in case a node for inst. advertises three terminating
>>>>
>>>>>links with PSC-2 (one of these being the LSP segment) then a another
>>>>>node (part of the same area) receiving an incoming multi-area PSC-2 LSP
>>>>>request may start making use of this segment to join the next border,
>>>>>therefore advertisement of the LSP segment may create a multi-hop
>>>>>condition, but now once used relevance of the existence of the segment
>>>>>is not a useful information (for the area) as there is no possibility
>>>>>to make re-use of it except when the end-to-end LSP is torn down
>>>>
>>>>AA----------> I understand your point that once an LSP has been admitted
>>>>into an LSP segment it is no longer usable by other nodes in that area.
>>>>But would you rather stop advertising the link at this point, if you
>>>>were previously advertising it ? Don't you think that is a big hammer ? E.g.
>>>>how would a head end which has indeed computed a path over that LSP
>>>>segment differentiate this event from an LSP segment down event where
>>>>the link is deleted from the database ? So, all the document says today is
>>>>that you set the unreserved bw on the LSP segment to zero. The idea is
>>>>to still let other nodes know that the link exists but is unusable. It is
>>>>not different from a FA-LSP being consumed...in that case we don't stop
>>>>advertising the FA (if we were doing so previously), right ?
>>>
>>>IB>> Completley agree with Arthi. Besides, several parallel stitching
>>>segments could be advertised as a single bundle - hence, using the
>>>advertised link by one LSP does not necessarily take away all link's
>>>bandwidth.
>>
>>you don't understand the question, it is do we have to consider as
>>default behavior that a pre-provisioned is to be "advertized"
> 
> IB>> My point was that I do not see any difference in this respect between
> the sticthing FA-LSP (the same layer FA-LSP) and FA-LSP created in the lower
> layer. Besides, what do you mean by the default behaviour? The fact whether
> to advertise//remove FA TE link is a policy driven carefully thought through
> decision, a dnagerous one that could potentially destabilize the network.
> I'd say that the default behaviour is "NOT ADVERTISE" in either case.
> 
>>now beside the fact that there are techniques to do so what would be the
>>purpose of it ? and what it the overhead that such advertisement would
>>create - that can be of course decreased by bundling them - 
> 
> IB>> The purpose is exactly the same as for any other FA-LSP - add
> flexibility in a particular layer.

which flexibility are we expecting here, this "segment" can accommodate 
exactly one incoming request - additionally only nodes part of the same 
area can make use of this advertisement - so in fact what it would allow 
is the possibility to avoid creation of a segment if the edge node 
receiving the request re-orients its request to the head-end for this 
advertisement
                         |
example:      ----------D----------
              |                     |
            - A ---- Segment 1 ---- B -
              |                     |
               ----------C----------
                         |

you would have a segment between A-B that could be reached from C (the 
node receiving the incoming request) decides to make use of this segment 
  to reach B (so you would have C-A-B) but if this was the best path why 
not creating directly a segment C-A-B, instead of now having one segment 
C-A, the pre-provisioned A-B and probably one on top of it C-A-B ?

in case of classical FA-LSP it makes sense to advertize the FA link 
because it represents a lower region LSP (with usually a given ratio of 
unreserved bandwidth that makes worth advertizing the FA link) but in 
case of a segment i do have some difficulties to excatly see where this 
flexibility would deliver ?

thanks,
- dimitri.

>>thanks,
>>- dimitri.
>>
>>
>>>>>a more technical point is related to the definition of an FA LSP which
>>>>>per LSP-Hierarchy mandates crossing LSP region border: the head-end and
>>>>>tail-end switching capability represent the SC of the resulting TE link
>>>>>while intermediate node terminates the SC corr. to the switching type
> 
> of
> 
>>>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a PSC-2
>>>>>capable network with first and last link being [PSC-1,PSC-2] and
>>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would have now
>>>>>the creation of a [PSC-1,PSC-1] link with first and last link being
>>>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border
>>>>>crossing anymore - so here the question is about definition and
>>>>>detailing the triggers
>>>>
>>>>AA--------> As far as trigger for setting up an LSP segment is
> 
> concerned,
> 
>>>>I agree that there is no longer the notion of "crossing region
>>>>boundaries". I realize that the document doesn't discuss this,
> 
> especially
> 
>>>>given that we are doing other comparisons with FA LSPs. So, I will add
>>>>this discussion in the next revision. I think in case of LSP segment the
>>>>trigger for LSP segment setup would come from a) successful switching
> 
> type
> 
>>>>and switching capability match and b) some local policy on the node
> 
> which
> 
>>>>dictates the setting up of an LSP segment.
>>>>
>>>
>>>
>>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and could be
>>>challenged in many ways. FA LSP is, generally speaking, created on a
> 
> layer
> 
>>>boundary rather than on region boundary: nothing prevents creating a VC4
> 
> FA
> 
>>>LSP that starts and stops in the middle of TDM region to carry several
> 
> VC12
> 
>>>LSPs. Furthermore, stitching FA is a special case of FA when it is used
> 
> by
> 
>>>LSPs of the same layer as one where the FA-LSP was created. As for
> 
> triggers,
> 
>>>there could be multiple ones for setting up/tearing down stitching
> 
> FA-LSPs:
> 
>>>configuration, receiving setup request for inter-domain LSP, other
> 
> policies.
> 
>>>Igor
>>>
>>>
>>>
>>>
>>>
>>>>More on a) later.
>>>>
>>>>thanks,
>>>>-arthi
>>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 15:38:53 +0000
Message-ID: <000801c51506$9e3c82c0$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "Arthi Ayyangar" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Date: Thu, 17 Feb 2005 10:37:41 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dimitri,
see my comment in line.

Igor

----- Original Message ----- 
From: "dimitri papadimitriou" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: "Arthi Ayyangar" <[e-mail]>;
<[e-mail]>; <[e-mail]>
Sent: Thursday, February 17, 2005 8:47 AM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt


> igor - see in-line
>
> Igor Bryskin wrote:
>
> > Dimitri, Arthi,
> > See my comments in line.
> >
> > Igor
> >
> > ----- Original Message ----- 
> > From: "Arthi Ayyangar" <[e-mail]>
> > To: <[e-mail]>; <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Wednesday, February 16, 2005 9:08 PM
> > Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
> >
> >
> >
> >>Hi Dimitri,
> >>
> >>Please see my replies (AA--->) inline.
> >>
> >>
> >>>>---------> An LSP segment may be created either by configuration or
> >
> > due
> >
> >>>>to arrival of an e2e LSP setup request itself. Similar to an FA, an
> >
> > LSP
> >
> >>>>segment may or may not be advertised as a TE link. But, if
> >
> > pre-created, it
> >
> >>>>could be advertised, in which case other nodes may compute a path over
> >
> > it.
> >
> >>>>Why would you want to or not want to advertise an FA ?
> >>>
> >>>i understand the point on pre-created <-> advertised but this knowledge
> >>>may be useful for nodes part of the same area (not for nodes external
to
> >>>this area)
> >>
> >>AA -------> Absolutely ...this definitely cannot be advertised outside
the
> >>area (domain). I think this has been explicitly mentioned.
> >>
> >>so in case a node for inst. advertises three terminating
> >>
> >>>links with PSC-2 (one of these being the LSP segment) then a another
> >>>node (part of the same area) receiving an incoming multi-area PSC-2 LSP
> >>>request may start making use of this segment to join the next border,
> >>>therefore advertisement of the LSP segment may create a multi-hop
> >>>condition, but now once used relevance of the existence of the segment
> >>>is not a useful information (for the area) as there is no possibility
to
> >>>make re-use of it except when the end-to-end LSP is torn down
> >>
> >>AA----------> I understand your point that once an LSP has been admitted
> >>into an LSP segment it is no longer usable by other nodes in that area.
> >>But would you rather stop advertising the link at this point, if you
were
> >>previously advertising it ? Don't you think that is a big hammer ? E.g.
> >>how would a head end which has indeed computed a path over that LSP
> >>segment differentiate this event from an LSP segment down event where
the
> >>link is deleted from the database ? So, all the document says today is
> >>that you set the unreserved bw on the LSP segment to zero. The idea is
to
> >>still let other nodes know that the link exists but is unusable. It is
> >>not different from a FA-LSP being consumed...in that case we don't stop
> >>advertising the FA (if we were doing so previously), right ?
> >
> > IB>> Completley agree with Arthi. Besides, several parallel stitching
> > segments could be advertised as a single bundle - hence, using the
> > advertised link by one LSP does not necessarily take away all link's
> > bandwidth.
>
> you don't understand the question, it is do we have to consider as
> default behavior that a pre-provisioned is to be "advertized"

IB>> My point was that I do not see any difference in this respect between
the sticthing FA-LSP (the same layer FA-LSP) and FA-LSP created in the lower
layer. Besides, what do you mean by the default behaviour? The fact whether
to advertise//remove FA TE link is a policy driven carefully thought through
decision, a dnagerous one that could potentially destabilize the network.
I'd say that the default behaviour is "NOT ADVERTISE" in either case.
>
> now beside the fact that there are techniques to do so what would be the
> purpose of it ? and what it the overhead that such advertisement would
> create - that can be of course decreased by bundling them -
>

IB>> The purpose is exactly the same as for any other FA-LSP - add
flexibility in a particular layer.
Igor

> thanks,
> - dimitri.
>
> >>>a more technical point is related to the definition of an FA LSP which
> >>>per LSP-Hierarchy mandates crossing LSP region border: the head-end and
> >>>tail-end switching capability represent the SC of the resulting TE link
> >>>while intermediate node terminates the SC corr. to the switching type
of
> >>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a PSC-2
> >>>capable network with first and last link being [PSC-1,PSC-2] and
> >>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would have now
> >>>the creation of a [PSC-1,PSC-1] link with first and last link being
> >>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border
> >>>crossing anymore - so here the question is about definition and
> >>>detailing the triggers
> >>
> >>AA--------> As far as trigger for setting up an LSP segment is
concerned,
> >>I agree that there is no longer the notion of "crossing region
> >>boundaries". I realize that the document doesn't discuss this,
especially
> >>given that we are doing other comparisons with FA LSPs. So, I will add
> >>this discussion in the next revision. I think in case of LSP segment the
> >>trigger for LSP segment setup would come from a) successful switching
type
> >>and switching capability match and b) some local policy on the node
which
> >>dictates the setting up of an LSP segment.
> >>
> >
> >
> > IB>> I have a comment here. LSP-Hierarchy is not a Bible and could be
> > challenged in many ways. FA LSP is, generally speaking, created on a
layer
> > boundary rather than on region boundary: nothing prevents creating a VC4
FA
> > LSP that starts and stops in the middle of TDM region to carry several
VC12
> > LSPs. Furthermore, stitching FA is a special case of FA when it is used
by
> > LSPs of the same layer as one where the FA-LSP was created. As for
triggers,
> > there could be multiple ones for setting up/tearing down stitching
FA-LSPs:
> > configuration, receiving setup request for inter-domain LSP, other
policies.
> >
> > Igor
> >
> >
> >
> >
> >>More on a) later.
> >>
> >>thanks,
> >>-arthi
> >>
> >
> >
> >
> >
> > .
> >
>




Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 13: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: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Date: Thu, 17 Feb 2005 13:54:36 -0000
Message-ID: <[e-mail]>
Thread-Topic: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Thread-Index: AcUU6QzqA6R1/gc7QJOsXDXEpXc9WwAAKZ4wAAAUAnA=
From: "Philip Crocker" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

Adrian,

Thanks very much for your comments - please see my replies below, marked =
with [PJC].

Phil.


> -----Original Message-----
> From: Philip Crocker=20
> Sent: 17 February 2005 12:11
> To: Philip Crocker
> Subject: FW: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
>=20
>=20
>=20
> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: 17 February 2005 10:29
> To: Philip Crocker; [e-mail]
> Cc: [e-mail]
> Subject: Re: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
>=20
>=20
> Phil,
> How nice to hear from you.
>=20
> > I have recently been looking in detail at=20
> draft-ietf-ccamp-test-sonet-sdh-04.txt,=20
> > and have a question and a comment on the draft.  I'd really=20
> appreciate it if
> > you could spare the time to look at both these points.
> >
> > 1)  Firstly the question.  In section 1 (the 4th=20
> paragraph), the text
> > indicates that SONET / SDH extensions to link verification and link=20
> > property correlation require both section 3 and section 4 (Trace=20
> > Monitoring).  However, it seems to me that the extensions described
> > in section 3 alone are enough to perform link verification and link
> > property correlation for SONET / SDH links.  Specifically, though=20
> > the TraceMonitor<xx> and TraceMismatch messages defined in section
> > 4 can be used to perform an external verification of SONET / SDH=20
> > links, it is not clear why these messages are necessary in addition
> > to the LMP link verification procedure (as extended by section 3).=20
> > Could you please explain this?
>=20
> It is slightly unclear what you are asking.
> Note that the Trace object is defined in section 4 and is=20
> required for J0, J1 and J2 Test procedures as decribed in=20
> section 3. Thus, both sections 3 and 4 are necessary for the=20
> new link verification procedures.
>=20
> It is possible that you are baulking at "This requires a new=20
> trace monitoring function that is also discussed in this=20
> document." "Requires" may be slightly too strong.

[PJC]
I agree that the <Trace> object defined in section 4 is required by =
section 3.  However, section 1 says that the 'trace monitoring function' =
is required by LMP SONET / SDH specific link verification and link =
correlation.  I understand 'trace monitoring function' to refer to the =
new TraceMonitor messages (and not just the Trace object), and hence my =
confusion.

If as you imply, the only part of section 4 required for LMP SONET / SDH =
specific link verification and link correlation is the Trace object, =
then I would recommend the text in section 1 be changed to reduce =
confusion. =20

In any case, I remain unsure of the background and proposed uses of the =
TraceMonitor and other messages defined in section 4 - can you help =
here?  Assuming there are valid reasons for this function I think we =
should beef up the introductory text in section 1 to describe them.

>=20
>=20
> > 2)  Secondly, I have a minor comment on section 4.  I=20
> understand from
> > section 4.1.1 that a TraceMonitor message should contain a single=20
> > <TRACE> object.  However, section 4.1.2 can be read to imply that a
> > TraceMonitor message can contain more than one <TRACE> object.  Can
> > I suggest the following replacement text for section 4.1.2?
> >
> >   The TraceMonitorAck message (Message Type TBA by IANA) is used to
> >   acknowledge receipt of the TraceMonitor message and indicate that
> >   the TRACE object in the TraceMonitor message have been received=20
> >   and processed correctly (i.e. no Trace Mismatch).
>=20
> There is absolutely nothing wrong with the existing text.=20
> "All of the TRACE Objects in the TraceMonitor message" is=20
> perfectly fine when there is only one such object allowed.=20
> Leaving the text as it is reduces any changes should the=20
> number of Test objects on a TraceMonitor ever be increased.

[PJC]
I agree there's nothing strictly wrong with the existing text, but it's =
misleading to have one part of the document state there is exactly one =
object, and then have another referring to multiple objects.  I would =
vote to remove all ambiguity and change the text.  Yes, I agree that if =
the number is increased in the future, the wording has to be changed, =
but I believe the improved clarity makes it worth it.  However, this =
isn't an important issue and I don't feel strongly about this.

>=20
> Cheers,
> Adrian
>=20



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 13:48:02 +0000
Message-ID: <[e-mail]>
Date: Thu, 17 Feb 2005 14:47:43 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC: Arthi Ayyangar <[e-mail]>,  [e-mail],  [e-mail]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

igor - see in-line

Igor Bryskin wrote:

> Dimitri, Arthi,
> See my comments in line.
> 
> Igor
> 
> ----- Original Message ----- 
> From: "Arthi Ayyangar" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, February 16, 2005 9:08 PM
> Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
> 
> 
> 
>>Hi Dimitri,
>>
>>Please see my replies (AA--->) inline.
>>
>>
>>>>---------> An LSP segment may be created either by configuration or
> 
> due
> 
>>>>to arrival of an e2e LSP setup request itself. Similar to an FA, an
> 
> LSP
> 
>>>>segment may or may not be advertised as a TE link. But, if
> 
> pre-created, it
> 
>>>>could be advertised, in which case other nodes may compute a path over
> 
> it.
> 
>>>>Why would you want to or not want to advertise an FA ?
>>>
>>>i understand the point on pre-created <-> advertised but this knowledge
>>>may be useful for nodes part of the same area (not for nodes external to
>>>this area)
>>
>>AA -------> Absolutely ...this definitely cannot be advertised outside the
>>area (domain). I think this has been explicitly mentioned.
>>
>>so in case a node for inst. advertises three terminating
>>
>>>links with PSC-2 (one of these being the LSP segment) then a another
>>>node (part of the same area) receiving an incoming multi-area PSC-2 LSP
>>>request may start making use of this segment to join the next border,
>>>therefore advertisement of the LSP segment may create a multi-hop
>>>condition, but now once used relevance of the existence of the segment
>>>is not a useful information (for the area) as there is no possibility to
>>>make re-use of it except when the end-to-end LSP is torn down
>>
>>AA----------> I understand your point that once an LSP has been admitted
>>into an LSP segment it is no longer usable by other nodes in that area.
>>But would you rather stop advertising the link at this point, if you were
>>previously advertising it ? Don't you think that is a big hammer ? E.g.
>>how would a head end which has indeed computed a path over that LSP
>>segment differentiate this event from an LSP segment down event where the
>>link is deleted from the database ? So, all the document says today is
>>that you set the unreserved bw on the LSP segment to zero. The idea is to
>>still let other nodes know that the link exists but is unusable. It is
>>not different from a FA-LSP being consumed...in that case we don't stop
>>advertising the FA (if we were doing so previously), right ? 
> 
> IB>> Completley agree with Arthi. Besides, several parallel stitching
> segments could be advertised as a single bundle - hence, using the
> advertised link by one LSP does not necessarily take away all link's
> bandwidth.

you don't understand the question, it is do we have to consider as 
default behavior that a pre-provisioned is to be "advertized"

now beside the fact that there are techniques to do so what would be the 
purpose of it ? and what it the overhead that such advertisement would 
create - that can be of course decreased by bundling them -

thanks,
- dimitri.

>>>a more technical point is related to the definition of an FA LSP which
>>>per LSP-Hierarchy mandates crossing LSP region border: the head-end and
>>>tail-end switching capability represent the SC of the resulting TE link
>>>while intermediate node terminates the SC corr. to the switching type of
>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a PSC-2
>>>capable network with first and last link being [PSC-1,PSC-2] and
>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would have now
>>>the creation of a [PSC-1,PSC-1] link with first and last link being
>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border
>>>crossing anymore - so here the question is about definition and
>>>detailing the triggers
>>
>>AA--------> As far as trigger for setting up an LSP segment is concerned,
>>I agree that there is no longer the notion of "crossing region
>>boundaries". I realize that the document doesn't discuss this, especially
>>given that we are doing other comparisons with FA LSPs. So, I will add
>>this discussion in the next revision. I think in case of LSP segment the
>>trigger for LSP segment setup would come from a) successful switching type
>>and switching capability match and b) some local policy on the node which
>>dictates the setting up of an LSP segment.
>>
> 
> 
> IB>> I have a comment here. LSP-Hierarchy is not a Bible and could be
> challenged in many ways. FA LSP is, generally speaking, created on a layer
> boundary rather than on region boundary: nothing prevents creating a VC4 FA
> LSP that starts and stops in the middle of TDM region to carry several VC12
> LSPs. Furthermore, stitching FA is a special case of FA when it is used by
> LSPs of the same layer as one where the FA-LSP was created. As for triggers,
> there could be multiple ones for setting up/tearing down stitching FA-LSPs:
> configuration, receiving setup request for inter-domain LSP, other policies.
> 
> Igor
> 
> 
> 
> 
>>More on a) later.
>>
>>thanks,
>>-arthi
>>
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 13:36:07 +0000
Message-ID: <000201c514f5$6b272e00$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Arthi Ayyangar" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Date: Thu, 17 Feb 2005 08:32:58 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dimitri, Arthi,
See my comments in line.

Igor

----- Original Message ----- 
From: "Arthi Ayyangar" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, February 16, 2005 9:08 PM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt


> Hi Dimitri,
>
> Please see my replies (AA--->) inline.
>
> > > ---------> An LSP segment may be created either by configuration or
due
> > > to arrival of an e2e LSP setup request itself. Similar to an FA, an
LSP
> > > segment may or may not be advertised as a TE link. But, if
pre-created, it
> > > could be advertised, in which case other nodes may compute a path over
it.
> > > Why would you want to or not want to advertise an FA ?
> >
> > i understand the point on pre-created <-> advertised but this knowledge
> > may be useful for nodes part of the same area (not for nodes external to
> > this area)
> AA -------> Absolutely ...this definitely cannot be advertised outside the
> area (domain). I think this has been explicitly mentioned.
>
> so in case a node for inst. advertises three terminating
> > links with PSC-2 (one of these being the LSP segment) then a another
> > node (part of the same area) receiving an incoming multi-area PSC-2 LSP
> > request may start making use of this segment to join the next border,
> > therefore advertisement of the LSP segment may create a multi-hop
> > condition, but now once used relevance of the existence of the segment
> > is not a useful information (for the area) as there is no possibility to
> > make re-use of it except when the end-to-end LSP is torn down
> AA----------> I understand your point that once an LSP has been admitted
> into an LSP segment it is no longer usable by other nodes in that area.
> But would you rather stop advertising the link at this point, if you were
> previously advertising it ? Don't you think that is a big hammer ? E.g.
> how would a head end which has indeed computed a path over that LSP
> segment differentiate this event from an LSP segment down event where the
> link is deleted from the database ? So, all the document says today is
> that you set the unreserved bw on the LSP segment to zero. The idea is to
> still let other nodes know that the link exists but is unusable. It is
> not different from a FA-LSP being consumed...in that case we don't stop
> advertising the FA (if we were doing so previously), right ?
>

IB>> Completley agree with Arthi. Besides, several parallel stitching
segments could be advertised as a single bundle - hence, using the
advertised link by one LSP does not necessarily take away all link's
bandwidth.


> > a more technical point is related to the definition of an FA LSP which
> > per LSP-Hierarchy mandates crossing LSP region border: the head-end and
> > tail-end switching capability represent the SC of the resulting TE link
> > while intermediate node terminates the SC corr. to the switching type of
> > the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a PSC-2
> > capable network with first and last link being [PSC-1,PSC-2] and
> > [PSC-2,PSC-1], resp.), while in the LSP segment case we would have now
> > the creation of a [PSC-1,PSC-1] link with first and last link being
> > [PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border
> > crossing anymore - so here the question is about definition and
> > detailing the triggers
> AA--------> As far as trigger for setting up an LSP segment is concerned,
> I agree that there is no longer the notion of "crossing region
> boundaries". I realize that the document doesn't discuss this, especially
> given that we are doing other comparisons with FA LSPs. So, I will add
> this discussion in the next revision. I think in case of LSP segment the
> trigger for LSP segment setup would come from a) successful switching type
> and switching capability match and b) some local policy on the node which
> dictates the setting up of an LSP segment.
>

IB>> I have a comment here. LSP-Hierarchy is not a Bible and could be
challenged in many ways. FA LSP is, generally speaking, created on a layer
boundary rather than on region boundary: nothing prevents creating a VC4 FA
LSP that starts and stops in the middle of TDM region to carry several VC12
LSPs. Furthermore, stitching FA is a special case of FA when it is used by
LSPs of the same layer as one where the FA-LSP was created. As for triggers,
there could be multiple ones for setting up/tearing down stitching FA-LSPs:
configuration, receiving setup request for inter-domain LSP, other policies.

Igor



> More on a) later.
>
> thanks,
> -arthi
>




Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 12:07:37 +0000
Message-ID: <049a01c514e9$33dcc8d0$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Philip Crocker" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Date: Thu, 17 Feb 2005 10:28:48 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03BA_01C514DB.77B01930"

This is a multi-part message in MIME format.

------=_NextPart_000_03BA_01C514DB.77B01930
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Phil,
How nice to hear from you.

> I have recently been looking in detail at =
draft-ietf-ccamp-test-sonet-sdh-04.txt,=20
> and have a question and a comment on the draft.  I'd really appreciate =
it if
> you could spare the time to look at both these points.
>
> 1)  Firstly the question.  In section 1 (the 4th paragraph), the text
> indicates that SONET / SDH extensions to link verification and link=20
> property correlation require both section 3 and section 4 (Trace=20
> Monitoring).  However, it seems to me that the extensions described
> in section 3 alone are enough to perform link verification and link
> property correlation for SONET / SDH links.  Specifically, though=20
> the TraceMonitor<xx> and TraceMismatch messages defined in section
> 4 can be used to perform an external verification of SONET / SDH=20
> links, it is not clear why these messages are necessary in addition
> to the LMP link verification procedure (as extended by section 3).=20
> Could you please explain this?

It is slightly unclear what you are asking.
Note that the Trace object is defined in section 4 and is required for =
J0, J1 and J2 Test procedures as decribed in section 3. Thus, both =
sections 3 and 4 are necessary for the new link verification procedures.

It is possible that you are baulking at "This requires a new trace =
monitoring function that is also discussed in this document." "Requires" =
may be slightly too strong.


> 2)  Secondly, I have a minor comment on section 4.  I understand from
> section 4.1.1 that a TraceMonitor message should contain a single=20
> <TRACE> object.  However, section 4.1.2 can be read to imply that a
> TraceMonitor message can contain more than one <TRACE> object.  Can
> I suggest the following replacement text for section 4.1.2?
>
>   The TraceMonitorAck message (Message Type TBA by IANA) is used to
>   acknowledge receipt of the TraceMonitor message and indicate that
>   the TRACE object in the TraceMonitor message have been received=20
>   and processed correctly (i.e. no Trace Mismatch).

There is absolutely nothing wrong with the existing text. "All of the =
TRACE Objects in the TraceMonitor message" is perfectly fine when there =
is only one such object allowed. Leaving the text as it is reduces any =
changes should the number of Test objects on a TraceMonitor ever be =
increased.

Cheers,
Adrian
------=_NextPart_000_03BA_01C514DB.77B01930
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>Phil,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>How nice to hear from =
you.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; I have recently been looking in =
detail at=20
draft-ietf-ccamp-test-sonet-sdh-04.txt, </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; and have a question and a =
comment on the=20
draft.&nbsp; I'd really appreciate it if</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;you could spare the time to =
look at=20
both these points.<BR>&gt;<BR>&gt; 1)&nbsp; Firstly the question.&nbsp; =
In=20
section 1 (the 4th paragraph), the text</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;indicates that SONET / SDH =
extensions=20
to link verification and link </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; property correlation require =
both section 3=20
and section 4 (Trace </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; Monitoring).&nbsp; However, it =
seems to me=20
that the extensions described</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;in section 3 alone are =
enough to=20
perform link verification and link</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; property correlation for SONET / =
SDH=20
links.&nbsp; Specifically, though </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; the TraceMonitor&lt;xx&gt; and =
TraceMismatch=20
messages defined in section</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;4 can be used to perform an =
external=20
verification of SONET / SDH </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; links, it is not clear why these =
messages=20
are necessary in addition</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;to the LMP link =
verification procedure=20
(as extended by section 3).&nbsp;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;Could you please explain=20
this?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>It is slightly unclear what you are=20
asking.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Note that the Trace object is defined =
in section=20
4 and is required for J0, J1 and J2 Test procedures as decribed in =
section 3.=20
Thus, both sections 3 and 4 are necessary for the new link verification=20
procedures.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>It is possible that you are baulking =
at "This=20
requires a new trace monitoring&nbsp;function that is also discussed in =
this=20
document." "Requires" may be slightly too strong.</DIV>
<DIV><BR><BR>&gt; 2)&nbsp; Secondly, I have a minor comment on section =
4.&nbsp;=20
I understand from</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;section 4.1.1 that a =
TraceMonitor=20
message should contain a single </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; &lt;TRACE&gt; object.&nbsp; =
However, section=20
4.1.2 can be read to imply that a</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;TraceMonitor message can =
contain more=20
than one &lt;TRACE&gt; object.&nbsp; Can</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;I suggest the following =
replacement=20
text for section 4.1.2?<BR>&gt;<BR>&gt;&nbsp;&nbsp; The TraceMonitorAck =
message=20
(Message Type TBA by IANA) is used to</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp; &nbsp;acknowledge receipt =
of the=20
TraceMonitor message and indicate that</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;&nbsp; the TRACE object in =
the=20
TraceMonitor message have been received </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;&nbsp;&nbsp; and processed =
correctly (i.e. no=20
Trace Mismatch).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>There is absolutely nothing wrong =
with the=20
existing text. "All of the TRACE Objects in the TraceMonitor message" is =

perfectly fine when there is only one such object allowed. Leaving the =
text as=20
it is reduces any changes should the number of Test objects on a =
TraceMonitor=20
ever be increased.</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></BODY></HTML>

------=_NextPart_000_03BA_01C514DB.77B01930--




Envelope-to: [e-mail]
Delivery-date: Thu, 17 Feb 2005 02:11:08 +0000
Date: Wed, 16 Feb 2005 18:08:37 -0800 (PST)
From: Arthi Ayyangar <[e-mail]>
To: [e-mail], [e-mail]
cc: "[e-mail]" <[e-mail]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Dimitri,

Please see my replies (AA--->) inline.

> > ---------> An LSP segment may be created either by configuration or due
> > to arrival of an e2e LSP setup request itself. Similar to an FA, an LSP
> > segment may or may not be advertised as a TE link. But, if pre-created, it
> > could be advertised, in which case other nodes may compute a path over it.
> > Why would you want to or not want to advertise an FA ?
>
> i understand the point on pre-created <-> advertised but this knowledge
> may be useful for nodes part of the same area (not for nodes external to
> this area)
AA -------> Absolutely ...this definitely cannot be advertised outside the
area (domain). I think this has been explicitly mentioned.

so in case a node for inst. advertises three terminating
> links with PSC-2 (one of these being the LSP segment) then a another
> node (part of the same area) receiving an incoming multi-area PSC-2 LSP
> request may start making use of this segment to join the next border,
> therefore advertisement of the LSP segment may create a multi-hop
> condition, but now once used relevance of the existence of the segment
> is not a useful information (for the area) as there is no possibility to
> make re-use of it except when the end-to-end LSP is torn down
AA----------> I understand your point that once an LSP has been admitted
into an LSP segment it is no longer usable by other nodes in that area.
But would you rather stop advertising the link at this point, if you were
previously advertising it ? Don't you think that is a big hammer ? E.g.
how would a head end which has indeed computed a path over that LSP
segment differentiate this event from an LSP segment down event where the
link is deleted from the database ? So, all the document says today is
that you set the unreserved bw on the LSP segment to zero. The idea is to
still let other nodes know that the link exists but is unusable. It is
not different from a FA-LSP being consumed...in that case we don't stop
advertising the FA (if we were doing so previously), right ?

> a more technical point is related to the definition of an FA LSP which
> per LSP-Hierarchy mandates crossing LSP region border: the head-end and
> tail-end switching capability represent the SC of the resulting TE link
> while intermediate node terminates the SC corr. to the switching type of
> the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a PSC-2
> capable network with first and last link being [PSC-1,PSC-2] and
> [PSC-2,PSC-1], resp.), while in the LSP segment case we would have now
> the creation of a [PSC-1,PSC-1] link with first and last link being
> [PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border
> crossing anymore - so here the question is about definition and
> detailing the triggers
AA--------> As far as trigger for setting up an LSP segment is concerned,
I agree that there is no longer the notion of "crossing region
boundaries". I realize that the document doesn't discuss this, especially
given that we are doing other comparisons with FA LSPs. So, I will add
this discussion in the next revision. I think in case of LSP segment the
trigger for LSP segment setup would come from a) successful switching type
and switching capability match and b) some local policy on the node which
dictates the setting up of an LSP segment.

More on a) later.

thanks,
-arthi



Envelope-to: [e-mail]
Delivery-date: Wed, 16 Feb 2005 17:34:29 +0000
Message-Id: <5.1.0.14.2.20050216122933.01e46d08@10.2.0.68>
Date: Wed, 16 Feb 2005 12:31:44 -0500
To: Arthi Ayyangar <[e-mail]>
From: Alia Atlas <[e-mail]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Cc: "[e-mail]" <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Arthi,

In the draft, you discuss advertising a number of LSP segments as a TE link 
bundle.  At the same time, the egress of the LSP segments needs to be able 
to determine which of those LSP segments was intended - but this is based 
on the IF_ID RSVP_HOP (PHOP) object.  Could you clarify how this would work 
in combination with the link bundle?

Thanks,
Alia




Envelope-to: [e-mail]
Delivery-date: Wed, 16 Feb 2005 12:04:22 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5141F.454CA600"
Subject: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Date: Wed, 16 Feb 2005 12:01:38 -0000
Message-ID: <[e-mail]>
Thread-Topic: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Thread-Index: AcUUH0ZqK2Bi07+sT1mh6ELkObKqTA==
From: "Philip Crocker" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5141F.454CA600
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Jonathan,

I have recently been looking in detail at =
draft-ietf-ccamp-test-sonet-sdh-04.txt, and have a question and a =
comment on the draft.  I'd really appreciate it if you could spare the =
time to look at both these points.

1)  Firstly the question.  In section 1 (the 4th paragraph), the text =
indicates that SONET / SDH extensions to link verification and link =
property correlation require both section 3 and section 4 (Trace =
Monitoring).  However, it seems to me that the extensions described in =
section 3 alone are enough to perform link verification and link =
property correlation for SONET / SDH links.  Specifically, though the =
TraceMonitor<xx> and TraceMismatch messages defined in section 4 can be =
used to perform an external verification of SONET / SDH links, it is not =
clear why these messages are necessary in addition to the LMP link =
verification procedure (as extended by section 3).  Could you please =
explain this?

2)  Secondly, I have a minor comment on section 4.  I understand from =
section 4.1.1 that a TraceMonitor message should contain a single =
<TRACE> object.  However, section 4.1.2 can be read to imply that a =
TraceMonitor message can contain more than one <TRACE> object.  Can I =
suggest the following replacement text for section 4.1.2?

	The TraceMonitorAck message (Message Type TBA by IANA) is used to =
acknowledge receipt of the TraceMonitor message and indicate that the =
TRACE object in the TraceMonitor message have been received and =
processed correctly (i.e. no Trace Mismatch).

Thanks,

Phil Crocker



------_=_NextPart_001_01C5141F.454CA600
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Jonathan,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have recently been looking in detail =
at draft-ietf-ccamp-test-sonet-sdh-04.txt, and have a question and a =
comment on the draft.&nbsp; I'd really appreciate it if you could spare =
the time to look at both these points.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1)&nbsp; Firstly the question.&nbsp; In =
section 1 (the 4th paragraph), the text indicates that SONET / SDH =
extensions to link verification and link property correlation require =
both section 3 and section 4 (Trace Monitoring).&nbsp; However, it seems =
to me that the extensions described in section 3 alone are enough to =
perform link verification and link property correlation for SONET / SDH =
links.&nbsp; Specifically, though the TraceMonitor&lt;xx&gt; and =
TraceMismatch messages defined in section 4 can be used to perform an =
external verification of SONET / SDH links, it is not clear why these =
messages are necessary in addition to the LMP link verification =
procedure (as extended by section 3).&nbsp; Could you please explain =
this?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2)&nbsp; Secondly, I have a minor =
comment on section 4.&nbsp; I understand from section 4.1.1 that a =
TraceMonitor message should contain a single &lt;TRACE&gt; object.&nbsp; =
However, section 4.1.2 can be read to imply that a TraceMonitor message =
can contain more than one &lt;TRACE&gt; object.&nbsp; Can I suggest the =
following replacement text for section 4.1.2?</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">The TraceMonitorAck message (Message =
Type TBA by IANA) is used to acknowledge receipt of the TraceMonitor =
message and indicate that the TRACE object in the TraceMonitor message =
have been received and processed correctly (i.e. no Trace =
Mismatch).</FONT></P>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Phil Crocker</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C5141F.454CA600--



Envelope-to: [e-mail]
Delivery-date: Wed, 16 Feb 2005 06:59:21 +0000
Message-ID: <[e-mail]>
Date: Wed, 16 Feb 2005 07:58:56 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Arthi Ayyangar <[e-mail]>
CC:  [e-mail],  "[e-mail]" <[e-mail]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi arthi, see in-line for some clarifications

Arthi Ayyangar wrote:

> Hi Dimitri,
> 
> Thanks for your comments. Please see my replies inline.
> 
> 
>>- section 3: why a TE link is to be associated to an LSP segment since
>>at the end the segment exists only within the context of the end-to-end
>>that triggers it, i.e. re-use of a segment is anyway not possible once
>>created (unreserved bandwidth set to 0) so why other nodes would need to
>>know about its existence ? other sections in this document do also refer
>>to this but (see for inst. section 5.2) if the network sees the LSP
>>segment as a TE link in their TE databases what does "computation of a
>>path over this TE link." exactly means ?
> 
> ---------> An LSP segment may be created either by configuration or due
> to arrival of an e2e LSP setup request itself. Similar to an FA, an LSP
> segment may or may not be advertised as a TE link. But, if pre-created, it
> could be advertised, in which case other nodes may compute a path over it.
> Why would you want to or not want to advertise an FA ? 

i understand the point on pre-created <-> advertised but this knowledge 
may be useful for nodes part of the same area (not for nodes external to 
this area) so in case a node for inst. advertises three terminating 
links with PSC-2 (one of these being the LSP segment) then a another 
node (part of the same area) receiving an incoming multi-area PSC-2 LSP 
request may start making use of this segment to join the next border, 
therefore advertisement of the LSP segment may create a multi-hop 
condition, but now once used relevance of the existence of the segment 
is not a useful information (for the area) as there is no possibility to 
make re-use of it except when the end-to-end LSP is torn down

a more technical point is related to the definition of an FA LSP which 
per LSP-Hierarchy mandates crossing LSP region border: the head-end and 
tail-end switching capability represent the SC of the resulting TE link 
while intermediate node terminates the SC corr. to the switching type of 
the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a PSC-2 
capable network with first and last link being [PSC-1,PSC-2] and 
[PSC-2,PSC-1], resp.), while in the LSP segment case we would have now 
the creation of a [PSC-1,PSC-1] link with first and last link being 
[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region border 
crossing anymore - so here the question is about definition and 
detailing the triggers

> The same reasons and restrictions apply to the LSP segment as well.
> 
> 
>>- section 4: mentions "Although not adjacent in routing, the end nodes
>>of the LSP segment will have a signaling adjacency and will exchange
>>RSVP messages directly between each other." it would be interesting that
>>you define what you mean by signaling adj. because imho such an adj. is
>>based on the permanent exchange of hello msg
> 
> -------> This terminology (signaling adjacency) itself is borrowed from
> the hierarchy document. The sentence following it, simply tries to
> explain what it really means in the context of this doc. I am okay with
> removing the "signaling adjacency", if it doesn't make sense.

well, in the LSP Hierarchy case, if one wants to maintain resilience 
against channel or software failures for the nested LSPs one needs to 
maintain a signaling adjacency (by exchanging hello messages by which 
the restart and recovery time will be exchanged between the tail and the 
head-end of the FA-LSP), in the present case, such construction could 
also be possible as the penultimate hop for inst. does not know about 
the details concerning the end-to-end LSP since the Path message was 
(during setup phase) sent directly to the LSP segment tail-end

>>- section 4: the main difference between signaling an LSP over an LSP
>>segment instead of over an FA-LSP is that no Labels are allocated and
>>exchanged for the e2e LSP over the LSP segment hop -> therefore there is
>>a specific configuration/usage of the label_request object when
>>signaling the end-to-end LSP (as well as the upstream label for bi-dir
>>LSP) to be detailed here
> 
> ----> Okay.
> 
> 
>>- section 5.1: mentions "Similar to setup, tearing down the LSP segment
>>may also be decided either via local configuration or due to the fact
>>that there is no longer an e2e LSP stitched to the LSP segment." it
>>would be interesting to detail the deletion sequence when initiated from
>>the end-to-end LSP head-/tail-end and stitching head-/tail-end
> 
> -------> Okay.

i am ok for the rest

much thanks,
- dimitri.

> thanks,
> -arthi
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 16 Feb 2005 06:36:43 +0000
Message-Id: <[e-mail]>
From: "Zafar Ali" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Wed, 16 Feb 2005 01:34:26 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcUT8Y8BsnBJEIAuSoSMBw8x8XrPOA==

Hi Adrian, 

Thanks for putting this email together. In the following I have tried to
summarize the discussion we had on this thread and next steps. 

Thanks

Regards... Zafar 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 10:39 AM
> To: [e-mail]
> Subject: Starting a discussion on graceful shutdown
> 
> Hi,
> 
> http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-grace
> ful-shutdown-00.txt was discussed at the meeting in 
> Washington DC, and one of the questions raised was whether or 
> not we already had (multiple!) mechanisms capable of 
> performing the function described in the draft.
> 
> Kireeti quite rightly suggested that we step back and make 
> sure we understand the requirements. This is my take on those 
> requirements and I would appreciate it if the authors of the 
> draft joined in and other people on the list commented.
> 
> We wish to manage a link that needs to be taken out of 
> service in some way (data plane and/or control plane will be 
> disrupted). The link concerned has active LSPs and we wish to 
> offer upstream LSRs (in particular the ingress) the 
> opportunity to use make-before-break to re-route the LSPs.
> 
> In order to achieve this, we need to communicate to the 
> upstream nodes. Should we choose signaling or routing? Are 
> there benefits that mean we should use both, or should we 
> limit to just one?

Yes, we need both. 

> 
> There is another aspect to be considered. Should we also 
> attempt to protect new path computations from selecting the 
> link that will be taken out of service?

Yes, 

> 
> How should we consider the case of a node (data plane and/or 
> control plane) being taken out of service? 

Yes, 

>Is a node simply a 
> collection of links?

Yes, during graceful shutdown period. 

> 
> If a component link of a bundle is being taken out of service 
> (and assuming other component links are available) is this 
> just an issue for the adjacent nodes or does it need to be 
> communicated more widely? 

Let head end do the mb4b, 

> If the downstream node decides to 
> take the component link out of service, how does it inform 
> the upstream node?
> 
> Does it matter whether it is the control plane or the data 
> plane that will be taken out of service?

Yes, if data plane is going OOS, we are loosing traffic and motivation
behind mb4b to reduce traffic hit is lost. 

> 
> Opinions please.
> 
> I would like to see these issues and their answers captured 
> clearly in a requirements section of any draft. Would the 
> authors of draft-ali-ccamp-mpls-graceful-shutdown-00.txt
> be willing to take that on even though the end result might 
> be that procedures other than those they suggest will be selected?

Sure, we plan to revised the ID based on this survey as well as comments
from the WG for the upcoming IETF. 

Thanks again Adrian for your suggestion and putting this together. 

Thanks

Regards... Zafar

> 
> Adrian
> 
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 16 Feb 2005 00:34:36 +0000
Date: Tue, 15 Feb 2005 16:33:30 -0800 (PST)
From: Arthi Ayyangar <[e-mail]>
To: [e-mail], [e-mail]
cc: "[e-mail]" <[e-mail]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Dimitri,

Thanks for your comments. Please see my replies inline.

> - section 3: why a TE link is to be associated to an LSP segment since
> at the end the segment exists only within the context of the end-to-end
> that triggers it, i.e. re-use of a segment is anyway not possible once
> created (unreserved bandwidth set to 0) so why other nodes would need to
> know about its existence ? other sections in this document do also refer
> to this but (see for inst. section 5.2) if the network sees the LSP
> segment as a TE link in their TE databases what does "computation of a
> path over this TE link." exactly means ?
---------> An LSP segment may be created either by configuration or due
to arrival of an e2e LSP setup request itself. Similar to an FA, an LSP
segment may or may not be advertised as a TE link. But, if pre-created, it
could be advertised, in which case other nodes may compute a path over it.
Why would you want to or not want to advertise an FA ? The same reasons
and restrictions apply to the LSP segment as well.

> - section 4: mentions "Although not adjacent in routing, the end nodes
> of the LSP segment will have a signaling adjacency and will exchange
> RSVP messages directly between each other." it would be interesting that
> you define what you mean by signaling adj. because imho such an adj. is
> based on the permanent exchange of hello msg
-------> This terminology (signaling adjacency) itself is borrowed from
the hierarchy document. The sentence following it, simply tries to
explain what it really means in the context of this doc. I am okay with
removing the "signaling adjacency", if it doesn't make sense.

> - section 4: the main difference between signaling an LSP over an LSP
> segment instead of over an FA-LSP is that no Labels are allocated and
> exchanged for the e2e LSP over the LSP segment hop -> therefore there is
> a specific configuration/usage of the label_request object when
> signaling the end-to-end LSP (as well as the upstream label for bi-dir
> LSP) to be detailed here
----> Okay.

> - section 5.1: mentions "Similar to setup, tearing down the LSP segment
> may also be decided either via local configuration or due to the fact
> that there is no longer an e2e LSP stitched to the LSP segment." it
> would be interesting to detail the deletion sequence when initiated from
> the end-to-end LSP head-/tail-end and stitching head-/tail-end
-------> Okay.

thanks,
-arthi




Envelope-to: [e-mail]
Delivery-date: Tue, 15 Feb 2005 23:09:12 +0000
Message-ID: <[e-mail]>
Date: Wed, 16 Feb 2005 00:08:03 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi arthi and jp,

by reading this e-mail, i have several comments:

- section 3: why a TE link is to be associated to an LSP segment since 
at the end the segment exists only within the context of the end-to-end 
that triggers it, i.e. re-use of a segment is anyway not possible once 
created (unreserved bandwidth set to 0) so why other nodes would need to 
know about its existence ? other sections in this document do also refer 
to this but (see for inst. section 5.2) if the network sees the LSP 
segment as a TE link in their TE databases what does "computation of a 
path over this TE link." exactly means ?

- section 4: mentions "Although not adjacent in routing, the end nodes 
of the LSP segment will have a signaling adjacency and will exchange 
RSVP messages directly between each other." it would be interesting that 
you define what you mean by signaling adj. because imho such an adj. is 
based on the permanent exchange of hello msg

- section 4: the main difference between signaling an LSP over an LSP 
segment instead of over an FA-LSP is that no Labels are allocated and
exchanged for the e2e LSP over the LSP segment hop -> therefore there is 
a specific configuration/usage of the label_request object when 
signaling the end-to-end LSP (as well as the upstream label for bi-dir 
LSP) to be detailed here

- section 5.1: mentions "Similar to setup, tearing down the LSP segment 
may also be decided either via local configuration or due to the fact 
that there is no longer an e2e LSP stitched to the LSP segment." it 
would be interesting to detail the deletion sequence when initiated from 
the end-to-end LSP head-/tail-end and stitching head-/tail-end

thanks,
- dimitri.

[e-mail] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: LSP Stitching with Generalized MPLS TE
> 	Author(s)	: A. Ayyangar, J. Vasseur
> 	Filename	: draft-ayyangar-ccamp-lsp-stitching-00.txt
> 	Pages		: 12
> 	Date		: 2005-2-14
> 	
> 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-ayyangar-ccamp-lsp-stitching-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-ayyangar-ccamp-lsp-stitching-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-ayyangar-ccamp-lsp-stitching-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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce



Envelope-to: [e-mail]
Delivery-date: Tue, 15 Feb 2005 17:19:57 +0000
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Correction: RFC 4003 on GMPLS Signaling Procedure for Egress Control
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 15 Feb 2005 09:17:00 -0800

--NextPart


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


        RFC 4003

        Title:      GMPLS Signaling Procedure for Egress Control
        Author(s):  L. Berger
        Status:     Standards Track
        Date:       February 2005
        Mailbox:    [e-mail]
        Pages:      5
        Characters: 10306
        Updates:    3473

        I-D Tag:    draft-ietf-ccamp-gmpls-egress-control-03.txt

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


This document clarifies the procedures for the control of the label
used on an output/downstream interface of the egress node of a Label
Switched Path (LSP).  This control is also known as "Egress Control".
Support for Egress Control is implicit in Generalized Multi-Protocol
Label Switching (GMPLS) Signaling.  This document clarifies the
specification of GMPLS Signaling and does not modify GMPLS signaling
mechanisms and procedures.

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

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  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: rfc4003

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc4003.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: Tue, 15 Feb 2005 14:28:12 +0000
Message-ID: <01d101c5136a$72ca2a40$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: IPR claim in MRN drafts
Date: Tue, 15 Feb 2005 14:23:53 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The working group may wish to be aware of
http://www.ietf.org/ietf/IPR/tellabs-ipr-draft-shiomoto-ccamp-gmpls-mrn-reqs.txt
which claims potential IPR in
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt and
draft-papadimitriou-ccamp-gmpls-mrn-extensions-00.txt

Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 15 Feb 2005 10:56:05 +0000
Message-ID: <009101c5134c$f48de7b0$adcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Berger, Lou" <[e-mail]>, <[e-mail]>
Subject: Fw: RFC 4003 on GMPLS Signaling Procedure for Egress Control
Date: Tue, 15 Feb 2005 10:47:09 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Well done Lou. Thanks.

Adrian

> A new Request for Comments is now available in online RFC libraries.
> 
> 
>         RFC 4003
> 
>         Title:      GMPLS Signaling Procedure for Egress Control
>         Author(s):  L. Berger
>         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4003.txt




Envelope-to: [e-mail]
Delivery-date: Tue, 15 Feb 2005 06:14:11 +0000
Message-Id: <[e-mail]>
To: [e-mail]
From: [e-mail]
Mime-Version: 1.0
Date: Mon, 14 Feb 2005 15:46:35 -0800
Cc: [e-mail], [e-mail]
Subject: RFC 4003 on GMPLS Signaling Procedure for Egress Control
Content-Type: Multipart/Mixed; Boundary=NextPart

--NextPart


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


        RFC 4003

        Title:      GMPLS Signaling Procedure for Egress Control
        Author(s):  L. Berger
        Status:     Standards Track
        Date:       February 2005
        Mailbox:    [e-mail]
        Pages:      5
        Characters: 10306
        Updates:    3473

        I-D Tag:    draft-ietf-enum-webft-01.txt

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


This document clarifies the procedures for the control of the label
used on an output/downstream interface of the egress node of a Label
Switched Path (LSP).  This control is also known as "Egress Control".
Support for Egress Control is implicit in Generalized Multi-Protocol
Label Switching (GMPLS) Signaling.  This document clarifies the
specification of GMPLS Signaling and does not modify GMPLS signaling
mechanisms and procedures.

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

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  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: rfc4003

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

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


--OtherAccess--
--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Mon, 14 Feb 2005 23:51:48 +0000
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RFC 4003 on GMPLS Signaling Procedure for Egress Control
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 14 Feb 2005 15:46:35 -0800

--NextPart


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


        RFC 4003

        Title:      GMPLS Signaling Procedure for Egress Control
        Author(s):  L. Berger
        Status:     Standards Track
        Date:       February 2005
        Mailbox:    [e-mail]
        Pages:      5
        Characters: 10306
        Updates:    3473

        I-D Tag:    draft-ietf-enum-webft-01.txt

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


This document clarifies the procedures for the control of the label
used on an output/downstream interface of the egress node of a Label
Switched Path (LSP).  This control is also known as "Egress Control".
Support for Egress Control is implicit in Generalized Multi-Protocol
Label Switching (GMPLS) Signaling.  This document clarifies the
specification of GMPLS Signaling and does not modify GMPLS signaling
mechanisms and procedures.

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

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  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: rfc4003

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc4003.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: Mon, 14 Feb 2005 10:26:27 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5127F.374A4D10"
Subject: FW: I-D ACTION:draft-davey-ccamp-gmpls-ipv6-if-index-00.txt
Date: Mon, 14 Feb 2005 10:23:24 -0000
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-davey-ccamp-gmpls-ipv6-if-index-00.txt
Thread-Index: AcUPtu0hZyMlBhp+S+ihAgSGbRkdBQCxsduA
From: "Alan Davey" <[e-mail]>
To: <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5127F.374A4D10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

We have submitted the following draft for extensions to GMPLS for IPv6 =
control planes.

All comments are welcome.

Thanks

Alan

------------------------------------
Alan Davey
Data Connection Ltd
Tel:   [phone]      =20
Fax:   [phone]
Email: [e-mail] =20
Web:   http://www.dataconnection.com=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: 10 February 2005 20:45
To: [e-mail]
Subject: I-D ACTION:draft-davey-ccamp-gmpls-ipv6-if-index-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts =
directories.


	Title		: Generalized Multi-Protocol Label Switching (GMPLS) Control=20
			  Channel Separation with an IPv6 Control Plane
	Author(s)	: A. Davey, N. Neate
	Filename	: draft-davey-ccamp-gmpls-ipv6-if-index-00.txt
	Pages		: 5
	Date		: 2005-2-10
=09
This document specifies extensions to GMPLS signalling with control=20
   channel separation, [RFC3471], to use 128-bit IPv6 addresses to=20
   identify routers in an IPv6 control plane.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-davey-ccamp-gmpls-ipv6-if-index=
-00.txt

To remove yourself from the I-D Announcement list, send a message to=20
[e-mail] 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.


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-davey-ccamp-gmpls-ipv6-if-index-00.txt".

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


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-davey-ccamp-gmpls-ipv6-if-index-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 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.

------_=_NextPart_001_01C5127F.374A4D10
Content-Type: application/octet-stream;
	name="ATT31558.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT31558.TXT
Content-Disposition: attachment;
	filename="ATT31558.TXT"

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl
cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNS0yLTEwMTU1NzI4LkktREBpZXRmLm9yZz4NCg0KRU5D
T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRhdmV5LWNjYW1wLWdtcGxz
LWlwdjYtaWYtaW5kZXgtMDAudHh0DQo=

------_=_NextPart_001_01C5127F.374A4D10
Content-Type: application/octet-stream;
	name="draft-davey-ccamp-gmpls-ipv6-if-index-00.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-davey-ccamp-gmpls-ipv6-if-index-00.URL
Content-Disposition: attachment;
	filename="draft-davey-ccamp-gmpls-ipv6-if-index-00.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1kYXZleS1jY2FtcC1nbXBscy1pcHY2LWlmLWluZGV4LTAwLnR4dA0K

------_=_NextPart_001_01C5127F.374A4D10
Content-Type: text/plain;
	name="ATT31559.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT31559.txt
Content-Disposition: attachment;
	filename="ATT31559.txt"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo=

------_=_NextPart_001_01C5127F.374A4D10--



Envelope-to: [e-mail]
Delivery-date: Fri, 11 Feb 2005 22:02:50 +0000
Message-ID: <011201c51085$70964c00$f3cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: GMPLS TE MIB
Date: Fri, 11 Feb 2005 22:02:15 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Why two versions published in quick succession?

First version (07) contains two changes of substance:
- conformance statement fixed up
- tweaks to gmplsTunnelErrorEntry around gmplsTunnelErrorReporterType

Second version (08) fixes page numbering and index issues.

 http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-08.txt

Adrian



Envelope-to: [e-mail]
Delivery-date: Fri, 11 Feb 2005 20:22:14 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-08.txt
Date: Fri, 11 Feb 2005 15:21:00 -0500

--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 Multiprotocol Label Switching (GMPLS) 
			  Traffic Engineering Management Information Base
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-ccamp-gmpls-te-mib-08.txt
	Pages		: 49
	Date		: 2005-2-11
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for Generalized
   Multiprotocol Label Switching (GMPLS) based traffic engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-08.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-te-mib-08.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-te-mib-08.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-te-mib-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-te-mib-08.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, 11 Feb 2005 15:14:40 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5104B.D8DC7886"
Subject: RE: SDH Format
Date: Fri, 11 Feb 2005 09:10:39 -0600
Message-ID: <[e-mail]>
Thread-Topic: SDH Format
Thread-Index: AcUQN25Kz+b9b9gXTkSsFVdbfH9hEAAEG9JA
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5104B.D8DC7886
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I will answer briefly - if you need more info, contact off-line:
=20
Both ETSI and ANSI were developed in parallel, ETSI is based on AU-4,
and ANSI is using both AU-3 (for G.707's VC-3 payloads) and AU-4 (for
G.707's C-4 payloads). ITU's agreement was to use ETSI's SDH name (vs.
ANSI's SONET) and to include both AU-4 and AU-3 structures in Rec. G.707
as "SDH was designed to be universal". And resulting in G.707's rule for
interconnection of the two different types is to use the AU-4 structure
(demultiplexing to either VC-3 or TUG-2 for interconnection). Japan also
uses both the AU-3 and AU-4. Later, ETSI radio applications did define
an AU-3 structure, though I don't know if it is being used.
=20
Deborah

  _____ =20

From: [e-mail] [mailto:[e-mail]]=20
Sent: Friday, February 11, 2005 7:47 AM
To: [e-mail]; Brungard, Deborah A, ALABS;
[e-mail]
Cc: [e-mail]
Subject: SDH Format



You guys are the experts behind this and from some thread on the
internet regarding SDH; I just need your help to explain the differences
between AU-4 and AU-3? American versus European or ETSI?

Jerome Law



------_=_NextPart_001_01C5104B.D8DC7886
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>SDH Format</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D626094214-11022005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I will answer briefly - if you need more info, =
contact=20
off-line:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D626094214-11022005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D626094214-11022005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Both ETSI and ANSI were developed in parallel, =
ETSI is=20
based on AU-4, and ANSI is using both AU-3&nbsp;(for G.707's VC-3 =
payloads) and=20
AU-4 (for G.707's C-4 payloads). ITU's agreement was&nbsp;to use ETSI's =
SDH=20
name&nbsp;(vs. ANSI's SONET) and to include both AU-4 and AU-3 =
structures in=20
Rec. G.707 as "SDH was designed to be universal". And resulting in =
G.707's rule=20
for interconnection of the&nbsp;two different types&nbsp;is&nbsp;to use =
the AU-4=20
structure (demultiplexing to either VC-3 or TUG-2 for interconnection). =
Japan=20
also uses both the AU-3 and AU-4. Later, ETSI radio applications did =
define an=20
AU-3 structure, though I don't know if it is being =
used.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D626094214-11022005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D626094214-11022005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV><BR>
<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> Friday, February 11, 2005 =
7:47=20
AM<BR><B>To:</B> [e-mail]; Brungard, Deborah A, ALABS;=20
[e-mail]<BR><B>Cc:</B>=20
[e-mail]<BR><B>Subject:</B> SDH Format<BR></FONT><BR></DIV>
<DIV></DIV><!-- Converted from text/rtf format -->
<P><FONT face=3DArial size=3D2>You guys are the experts behind this and =
from some=20
thread on the internet regarding SDH; I just need your help to explain =
the=20
differences between AU-4 and AU-3? American versus European or =
ETSI?</FONT></P>
<P><SPAN lang=3Den-us><B><FONT face=3D"Times New Roman">Jerome=20
Law<BR></FONT></B></SPAN></P></BODY></HTML>

------_=_NextPart_001_01C5104B.D8DC7886--



Envelope-to: [e-mail]
Delivery-date: Thu, 10 Feb 2005 22:08:52 +0000
Message-ID: <033801c50fbd$12f922c0$b5cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Early WG schedule for Minneapolis
Date: Thu, 10 Feb 2005 22:08:10 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

The early, provisional schedule for Minneapolis shows CCAMP on Tuesday
morning.

This is not yet definitive.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 10 Feb 2005 20:43:43 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-07.txt
Date: Thu, 10 Feb 2005 15:41:39 -0500

--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 Multiprotocol Label Switching (GMPLS) 
			  Traffic Engineering Management Information Base
	Author(s)	: T. Nadeau, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-te-mib-07.txt
	Pages		: 49
	Date		: 2005-2-10
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for Generalized
   Multiprotocol Label Switching (GMPLS) based traffic engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-07.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-te-mib-07.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-te-mib-07.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-te-mib-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-te-mib-07.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, 10 Feb 2005 16:28: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: FW: Layer 2 Switching Caps LSPs
Date: Thu, 10 Feb 2005 10:27:50 -0600
Message-ID: <[e-mail]>
Thread-Topic: FW: Layer 2 Switching Caps LSPs
Thread-Index: AcUPfufguKASm2M7SSupssSa3P/3IwACS2qA
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Don Fedyk" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

Hi Don,

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

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

Hi Dimitri

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

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

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

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

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

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

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


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

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


Regards,
Don
>=20
> thanks,
> - dimitri.
>=20
> > Regards,
> > Don
> >=20
<snip>





Envelope-to: [e-mail]
Delivery-date: Thu, 10 Feb 2005 14:43:10 +0000
Message-ID: <B258A372CEA20246A363BB86753DB53602582FB6@zrtphxm2>
From: "Don Fedyk" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: FW: Layer 2 Switching Caps LSPs
Date: Thu, 10 Feb 2005 09:41:18 -0500

Hi Dimitri

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

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

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

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

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

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

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


Regards,
Don
> 
> thanks,
> - dimitri.
> 
> > Regards,
> > Don
> > 
<snip>



Envelope-to: [e-mail]
Delivery-date: Wed, 09 Feb 2005 23:35:14 +0000
Message-ID: <[e-mail]>
Date: Thu, 10 Feb 2005 00:33:19 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Don Fedyk <[e-mail]>
CC:  [e-mail]
Subject: Re: FW: Layer 2 Switching Caps LSPs
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

don,

Don Fedyk wrote:
> Resending, ccamp list message never came through
> ------------------------------------------------ 
> 
> Hi
> 
> I read through this draft and the thread and I don't see that much detail.
> Dimitri your statements are more about what this draft is not about. While
> they would be useful additions in the draft for clarification, how does this
> draft differ from one that just says:  "Lets define some code points for
> TLVs for future signaling of packet technologies, ATM, FR and Ethernet"?

the document details RSVP-TE processing (beside introducing rationales) 
and does not limit to a list of codepoints, at the end and when looking 
at the additional code-points (beside new C-Types) this constitute a 
small part of this document (section 5.1) for the LSP encoding type

> This is very similar to another SDO just asking for a few code points IMHO. 

i don't see what differs in terms of approach from other technologies 
currently being more detailed as part of the GMPLS coverage

for the technical rationale, it comes from the definition introduced in 
LSP-hierarchy document that introduces classes of resources (in terms of 
switching capability) and LSP regions, however at some point in time 
there is a need to distinguish between the common part and the 
technology specific part (in particular when the target is a unified TE 
model) that needs only to be supported by nodes capable to initiate LSPs 
across the corresponding region (L2SC in the present context)

> Would it not be better to detail one technology and transport mode in
> detail, rather than slowly refining the signaling for multiple technologies?

what do you mean by "detail one technology and transport mode" ? 
clarification would be helpful in order for me to understand this comment

thanks,
- dimitri.

> Regards,
> Don 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of [e-mail]
> Sent: Saturday, February 05, 2005 11:43 AM
> To: Allan, David 
> Cc: '[e-mail]'; '[e-mail]'; Shahram
> Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel;
> [e-mail]
> Subject: RE: Layer 2 Switching Caps LSPs
> 
> 
> see my response to sharam - as you come all over again with the same issues
> - 
> the question is how many flows can you discriminate based on the VLAN_ID and
> the response is 4k per port, drawing an analogy with a PE PW box the same
> happens if a NSP per port, 
> the second question is but *if* you discriminate the flows on a local basis
> you are assuming a behaviour that is not defined by the IEEE (your initial
> last CCAMP meeting question) and the response there are equivalent
> mechanisms defined outside the scope of the IEEE and definition i was
> pointing did include this behaviour (or more precisely does not preclude
> it); 
> the third question how is the forwarding occurring then and the response is
> not necessarily using bridging/MAC learning as the path of these frames is
> known from the LSP establishment (it is thus the establishment of the LSP
> that determines external behaviour of the forwarding function) - note: as in
> any standard there is no point in detailing the exact implementation of the
> switching/ forwarding/connection function -
> and lastly (closing the loop) the fourth question is does it require VLAN
> swapping ? the response is no this mechanism is not assumed and (taking a
> minimalistic assumption of VLAN continuity) just mandate ensuring per-port
> (and not per node or other instances) VLAN interpretation and this would
> only be constraining the establishment of the LSP at the end since
> equivalent to a continuity principle (and this can also be tackled by GMPLS
> using the label set mechanisms) - however you could with the document as
> written assume that a VLAN_ID may be translated - note: i do not refer to
> VLAN swapping - when crossing a node and document(as part of an appendix) a
> similar table as the one written in Appendix A of
> <draft-ietf-pwe3-ethernet-encap-08.txt> - i think at the end this is what
> adrian was looking for as part of the documentation effort - 
> note: this said to respond to your claim upon what's mandatory or not as
> part of this document, the response did not change from the previous one and
> the discussion we are having now is just because you are assuming a unique
> and specific data plane behaviour as part of this document for which there
> is no specification and then challenge this document as it would be the only
> possible allowed behaviour while 1) this is not the case, and some of these
> behaviours do not require anything else than what i document in my response
> to sharam and 2) there is nothing that precludes proposing an interpretation
> of a specific data plane field, or mechanism, or entity within the control
> plane - ask yourself the question is it allowed to interpreet link locally a
> data plane wavelength or timeslot as a label in the control plane ?
> response: yes, as it is just a matter of convention (even if some are more
> "natural" than others) but these interpretation orthogonal to the
> implementation of the forwarding/switching/connection function
> 
> "David Allan" <[e-mail]>
> 02/04/2005 14:32 EST
> 
> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> cc: "'[e-mail]'" <[e-mail]>, Shahram Davari
> <[e-mail]>, "Mack-Crane, T. Benjamin"
> <[e-mail]>, David Allan <[e-mail]>,
> Adrian Farrel <[e-mail]>, [e-mail]
> bcc: 
> Subject: RE: Layer 2 Switching Caps LSPs
> 
> 
> 
> OK let me decompose your last response and see if we can bottom this out....
> 
> 
> 
>>(but 
>>also keep in mind that there are two levels of VLANs defined today so 
>>further refinment is still possible) 
> 
> 
> My interpretation of "refinement" implies modification to existing
> procedures. Judging from your last response, you are simply referring to
> hierarchy which is an existing solution and requires no "refinement". 
> 
> 
>>and with 16 ports you would have 
>>64k LSPs not that bad for an unscalable solution ;-) 
> 
> 
> How can I interpret this.... 
> 
> - I could have 4k VLANs all with a common topology (bridge for 16 spokes). 
> 
> - Using VLAN swapping I could have 64k uni-directional LSPs only in a
> perfect world where I had an exactly flat distribution acorss the ports as
> to how they were routed. (BTW Any sort of aggregation scenario could drag
> that number down to a maximum of 4k LSPs).
> 
> However the second requires VLAN tag swapping which your and your co-authors
> comments in the past have suggested was not the purpose of this draft. Many
> of us violently object to VLAN awapping as it is data plane behavior that is
> not specified anywhere, and we see no utility in defining a control plane
> for things that do not exist....
> 
> Is there a third option that I have not understood implied by your latest
> comments? 
> 
> cheers 
> Dave 
> 
> 
> 
> 
> -----Original Message----- 
> From: [e-mail]
> [mailto:[e-mail]] 
> Sent: Friday, February 04, 2005 1:34 PM 
> To: Allan, David [CAR:NS00:EXCH] 
> Cc: '[e-mail]'; '[e-mail]'; Shahram
> Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel;
> [e-mail]
> 
> Subject: RE: Layer 2 Switching Caps LSPs 
> 
> dave - your response is "you don't think refinment would be possible" for a
> reason that escapes me since the document does not define control of
> provider bridges and as i do not think i have mentioned the "snooping"
> operation you are describing here below - you are more creative than i do
> ;-)
> 
> note: this said it does not change the numbers provided here below - and i
> can live with 64k LSPs (at least in a first phase) 
> 
> "David Allan" <[e-mail]> 
> 02/04/2005 09:44 EST 
> 
> To: "'[e-mail]'" <[e-mail]>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari
> <[e-mail]>
> 
> cc: "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan
> <[e-mail]>, Adrian Farrel <[e-mail]>,
> [e-mail]
> 
> bcc: 
> Subject: RE: Layer 2 Switching Caps LSPs 
> 
> 
> Dimitri: 
> <snipped> 
>  (but 
> 
>>also keep in mind that there are two levels of VLANs defined today so 
>>further refinment is still possible) and with 16 ports you would have 
>>64k LSPs not that bad for an unscalable solution ;-) 
> 
> 
> Suggesting snooping a 802.1ad VLAN stack to forward on the basis of more
> than one tag is more creative abuse of existing standards. You cannot
> preserve the value and simplicity of Ethernet if you insist on re-inventing
> it...A provider bridge forwards on the basis to S-tag and MAC address. The
> C-tag has no significance and we would be foolish to pursue a path whereby
> it does.
> 
> MPLS devices (all disucssion of ECMP aside) only forward on the basis of the
> top label. 
> 
> rgds 
> Dave 
> 
> 
>>note: i have explained in a previous mail where use of PW makes more 
>>sense and where it does less, and where it does simply not 
>>
>>Shahram Davari wrote: 
>>
>>>Dimitri, 
>>>
>>>I have another question. As you know there are only 4094 VLANs (12 
>>>bit). This means only 4094 P2P connection could be setup 
>>
>>using GMPLS. 
>>
>>>Since this is not scalable, presumably you need a 
>>
>>multiplexing label 
>>
>>>(such as MPLS or another VLAN tag), and its associated signaling 
>>>between two edges of the network. So why not use PW and be 
>>
>>done with 
>>
>>>it. 
>>>
>>>-Shahram 
>>>
>>>-----Original Message----- From: [e-mail] 
>>>[mailto:[e-mail]]On Behalf Of Shahram Davari Sent: 
>>>Thursday, February 03, 2005 6:19 PM To: 
>>>'[e-mail]' Cc: Mack-Crane, T. Benjamin; 
>>>[e-mail]; David Allan; Adrian Farrel; 
>>
>>[e-mail] 
>>
>>>Subject: RE: Layer 2 Switching Caps LSPs 
>>>
>>>
>>>Hi Dimitri, 
>>>
>>>Thanks for your response. Please see my comments in-line. 
>>>
>>>-Shahram 
>>>
>>>-----Original Message----- From: [e-mail] 
>>>[mailto:[e-mail]] Sent: Thursday, 
>>
>>February 03, 
>>
>>>2005 5:31 PM To: Shahram Davari Cc: 
>>>'[e-mail]'; Mack-Crane, T. Benjamin; 
>>>[e-mail]; David Allan; Adrian Farrel; 
>>
>>[e-mail] 
>>
>>>Subject: RE: Layer 2 Switching Caps LSPs 
>>>
>>>
>>>
>>>sharam, the first issue is that you have to decouple the notion of 
>>>ethernet with bridging, 
>>>
>>>Ethernet networks have 3 main layers: 
>>>
>>>1) PHY = 10/100/1G/10G as explained in 802.3, 
>>>
>>>2) MAC = 802.3 
>>>
>>>3) Bridging = 802.1D 
>>>
>>>Without Bridging layer your device can only have a single port. 
>>>Example is the Ethernet port of your desktop computer. Therefore if 
>>>you want to build an Ethernet network, you need bridging layer. 
>>>
>>>
>>>
>>>the second is that this configuration operation can be automated - 
>>>
>>>But after you have configured your connections (aka VLAN 
>>
>>ports), then 
>>
>>>there is nothing left for GMPS to do. Or are you saying 
>>
>>that the GMPLS 
>>
>>>will do the configuration? 
>>>
>>>however the interesting point you brought in the loop of discussion 
>>>here is "applicability for shared medium" - isn't the PW 
>>
>>solution in 
>>
>>>the same context 
>>>
>>>No, because in PW, the payload (Ethernet) is encapsulated 
>>
>>in another 
>>
>>>layer network (aka MPLS), and is invisible to the 
>>
>>intermediate nodes. 
>>
>>>While in your case there is no encapsulation, and all the 
>>
>>intermediate 
>>
>>>nodes can act on the MAC and VLAN tag. 
>>>
>>>as 1) it can not make an automated usage of a "medium" without 
>>>configuring the tunnels (in our case the tunnels that will 
>>
>>be used to 
>>
>>>carry the ethernet payload e.g. SDH, OTH, etc. if not using 
>>>point-to-point PHY's) but in addition to the present 
>>
>>solution PW also 
>>
>>>requires 2) the provisioning of the PW - something not 
>>
>>needed in the 
>>
>>>present context as terminating points will be directly 
>>
>>accessing the 
>>
>>>"ethernet medium", in brief if such argument is used here it should 
>>>have also been used in the PW context (if not more intensively) 
>>>
>>>another fundamental point, i am also surprised seeing people 
>>>supporting MPLS (which brings a connection-oriented 
>>
>>behaviour to IP) 
>>
>>>wondering about the suitability of using one of the 
>>
>>protocol suite of 
>>
>>>the IETF i.e. GMPLS to bring another (initially) connectionless 
>>>technology to a "connection-oriented" behaviour 
>>>
>>>I don't argue against bringing connection-oriented behavior to 
>>>Ethernet. My concern is the method used to do so. if you had done 
>>>proper Network Interworking (aka, encapsulation or as ITU calls it 
>>>client/server), then there would not be any problem. 
>>
>>However, what you 
>>
>>>are trying to do is to modify Ethernet's control-plane in a 
>>
>>way that 
>>
>>>requires modification to its data-plane behavior. As an 
>>
>>analogy what 
>>
>>>you are doing is like trying to use the IP address as MPLS tag in 
>>>order to make IP connection-oriented. 
>>>
>>>In contrast you could easily change ATM's control-plane to GMPLS 
>>>without any modification to ATM data-plane behavior, because ATM by 
>>>design is connection-oriented, and the VPI/VCI could easily be 
>>>interpreted as GMPLS tags. 
>>>
>>>(even if i do rather prefer the term flow, in the present 
>>
>>context) at 
>>
>>>the end the resulting gain is the same for both 
>>
>>technologies it terms 
>>
>>>of capabilities as application of constraint-based routing 
>>
>>principles 
>>
>>>- is this not at the end what drives mostly all debates in 
>>
>>the (G)MPLS 
>>
>>>galaxy beside VPNs and that was underlying incorporation of 
>>
>>these L2 
>>
>>>technologies as part of the GMPLS protocol architecture 
>>>
>>>thanks, 
>>>
>>>- dimitri. 
>>>
>>>
>>>Shahram Davari <[e-mail]> Sent by: 
>>>[e-mail] 02/03/2005 13:13 PST 
>>>
>>>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T. 
>>>Benjamin" <[e-mail]> cc: [e-mail], 
>>>David Allan <[e-mail]>, Adrian Farrel 
>>><[e-mail]>, [e-mail] bcc: Subject: RE: Layer 2 
>>>Switching Caps LSPs 
>>>
>>>
>>>
>>>
>>>Dimitri, 
>>>
>>>Unfortunately I didn't grasp completely what you are trying 
>>
>>to convey. 
>>
>>>But one thing I know for sure, and that is  "Ethernet is 
>>>Connectionless (CLS)" (like IP) and assumes shared medium, 
>>
>>while GMPLS 
>>
>>>is connection-oriented (CO) and doesn't work in shared medium. Off 
>>>course you could always configure and build an Ethernet 
>>
>>network that 
>>
>>>looks like it is CO (by configuring a max of 2 ports with the same 
>>>VLAN ID in each bridge), and by not using any shared 
>>
>>medium. But then 
>>
>>>who needs GMPLS, when you already have to configure your network by 
>>>other means? 
>>>
>>>-Shahram 
>>>
>>>
>>>From: [e-mail] 
>>>[mailto:[e-mail]] Sent: Thursday, 
>>
>>February 03, 
>>
>>>2005 3:07 PM To: Mack-Crane, T. Benjamin Cc: 
>>
>>[e-mail]; 
>>
>>>[e-mail]; David Allan; Adrian 
>>
>>Farrel; Shahram 
>>
>>>Davari; [e-mail] Subject: RE: Layer 2 Switching Caps LSPs 
>>>
>>>
>>>
>>>ben, 
>>>
>>>the discussion with dave has been reproduced in accelerated on the 
>>>mailing list - for me it appears that the more "philosophical" 
>>>conclusion can be positioned by answering to the following question 
>>>"Was SONET/SDH or lambda switching initially intended to be 
>>
>>controlled 
>>
>>>by GMPLS ?" if the response is "No, but nothing prevents to 
>>
>>do so" the 
>>
>>>next question is what does prevent from applying GMPLS to other 
>>>technologies knowing a substantial gain is obtained from its 
>>>application - in certain conditions - (see motivations as 
>>
>>part of this 
>>
>>>introduction for instance) ? key issue being which are these 
>>>(technical) conditions and are there conditions that would preclude 
>>>progressing this document - the response is simply the negative - 
>>>there are no such conditions in the point-to-point - non-bridging - 
>>>context where this document applies. 
>>>
>>>now, not sure there is a technical "firm" conclusion but 
>>
>>the point on 
>>
>>>the ethernet label encoding appears as follows since so far 
>>
>>there is 
>>
>>>potential interest to keep the label for ethernet generic 
>>
>>enough and 
>>
>>>deduce its interpretation from type of link over which the label is 
>>>used and intepreet its value according to the 
>>
>>traffic_parameters and 
>>
>>>propose associations to cover cases such as case 2 of Appendix A of 
>>><draft-pwe3-ethernet-encap-08.txt> mechanisms that is also 
>>
>>applicable 
>>
>>>to other tunneling technology since this mechanism is orthogonal to 
>>>the use of PW's if required (example being Ethernet over 
>>
>>SDH/OTH, for 
>>
>>>instance); however, if these are the only associations we 
>>
>>see relevant 
>>
>>>as part of this document then we would fall back on the existing 
>>>encoding with potential enhancement if so required - 
>>>
>>>to come to the point of the articulation the - generic - response 
>>>holds in one line: it articulates GMPLS signaling for L2SC LSPs 
>>>(note: the latter has been introduced in RFC 3945, RFC 3471, RFC 
>>>3473) - the motivations are detailed as part of the introduction of 
>>>this document - i can not comment more from your initial statement 
>>>since not detailed enough for me to be more specific 
>>>
>>>the response to the last question is relatively simple 
>>
>>since the above 
>>
>>>mentioned do not include any specifics concerning ATM or FR - this 
>>>document intends to close this gap by defining specific 
>>>Traffic_Parameters for these technologies - is there an 
>>
>>interest for 
>>
>>>doing so: response is yes otherwise the document would not have 
>>>included the corr. details 
>>>
>>>voila, thanks, 
>>>
>>>- dimitri. 
>>>
>>>
>>>
>>>
>>>
>>>"Mack-Crane, T. Benjamin" <[e-mail]> Sent by: 
>>>[e-mail] 02/03/2005 12:16 CST 
>>>
>>>To: <[e-mail]>, Dimitri 
>>>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" 
>>><[e-mail]> cc: "Adrian Farrel" 
>>
>><[e-mail]>, 
>>
>>>"Shahram Davari" <[e-mail]>, 
>>
>><[e-mail]> 
>>
>>>bcc: Subject: 
>>>RE: Layer 2 Switching Caps LSPs 
>>>
>>>
>>>Dimitri, 
>>>
>>>Can the off-line discussion be summarized for the benefit 
>>
>>of those on  
>>
>>>the list who did not participate?  For me, the draft (and 
>>
>>the current 
>>
>>>discussion on the list) have not clearly articulated the 
>>
>>problem being 
>>
>>>addressed.  If a summary of the conclusions of the off-line 
>>
>>discussion 
>>
>>>will do this, it would be useful. 
>>>
>>>I am also interested to know what is lacking in the current 
>>
>>GMPLS RFCs 
>>
>>>with respect to ATM and Frame Relay support that necessitates 
>>>including them in this new draft (presumably this is a part of the 
>>>problem to be solved). 
>>>
>>>Regards, Ben 
>>>
>>>
>>>
>>>>-----Original Message----- From: [e-mail] 
>>>>[mailto:[e-mail]] On 
>>>
>>>Behalf 
>>>
>>>
>>>>Of dimitri papadimitriou Sent: Thursday, January 27, 2005 6:35 PM 
>>>>To: David Allan Cc: 'Adrian Farrel'; 'Shahram Davari'; 
>>>>[e-mail] Subject: Re: Layer 2 Switching Caps LSPs 
>>>>
>>>>dave - there was a lengthy off-line discussion suggested by the 
>>>>chairs intended to explain you the scope of the draft and its 
>>>>relatioship 
>>>
>>>with 
>>>
>>>
>>>>the ethernet data plane (after the question you raised 
>>
>>during the f2f 
>>
>>>>meeting) - this has been done and we have explained (via a lengthy 
>>>>exchange of e-mails) that this document and so the use of gmpls to 
>>>>control ethernet frame flows, is not targeting control of bridged 
>>>>ethernet environments - if this is not clear from the current 
>>>>document introduction we would have also to work on this 
>>
>>part of the 
>>
>>>>document - therefore, the below reference to MSTP is not in the 
>>>>current scope; on the other side, the use of the term "VLAN label" 
>>>>has created some confusion; therefore, in a next release i will 
>>>>simply refer to a 
>>>
>>>"label" 
>>>
>>>
>>>>of 32 bits (unstructured) because the intention was (and 
>>
>>still is) to 
>>
>>>>find an easy way to map the control of the ethernet frame flows on 
>>>
>>>each 
>>>
>>>
>>>>device they traverses without making any assumption on how 
>>
>>this flow 
>>
>>>is 
>>>
>>>
>>>>processed inside each node at the data plane level (note: on label 
>>>>values, RFC 3946 took an equivalent approach - for circuits - where 
>>>> sonet/sdh multiplexing structures have been used to create unique 
>>>>multiplex entry names i.e. labels - this concept is here applied 
>>>>for "virtual" circuits), so, if the working group is willing to 
>>>>enter into 
>>>
>>>a 
>>>
>>>
>>>>data plane oriented discussion to clarify the behaviour(s) 
>>
>>onto which 
>>
>>>>the present approach would be potentially applicable this is fine 
>>>>with me as long as we are within the scope of the initial 
>>
>>motivations 
>>
>>>>thanks, - dimitri. 
>>>>
>>>>David Allan wrote: 
>>>>
>>>>
>>>>>Hi Adrian: 
>>>>>
>>>>>Your suggestion is in a way reasonable but with the caveat that in 
>>>
>>>IEEE 
>>>
>>>
>>>>>terms, a bridging topology is currently all VLANs (802.1Q single 
>>>>
>>>>spanning 
>>>>
>>>>
>>>>>tree) or partitioned into specific ranges (I believe 64 in 802.1s 
>>>>>
>>>>
>>>>although I 
>>>>
>>>>
>>>>>do not claim to be an expert). 
>>>>>
>>>>>If the PEs were to implement a bridge function and we were using 
>>>
>>>GMPLS 
>>>
>>>
>>>>to 
>>>>
>>>>
>>>>>interconnect them, then the control plane should be identifying 
>>>
>>>either 
>>>
>>>
>>>>all 
>>>>
>>>>
>>>>>VLANs (single spanning tree, which I beleive the draft covers by 
>>>>
>>>>referring 
>>>>
>>>>
>>>>>simply to Ethernet port) or a VLAN range to be associated with the 
>>>
>>>LSP 
>>>
>>>
>>>>>consistent with 802.1s if it is to operate to interconnect bridges 
>>>>
>>>>defined 
>>>>
>>>>
>>>>>by the IEEE... 
>>>>>
>>>>>I suspect assuming any other behavior (e.g. LSP for single VLAN 
>>>>>tag) 
>>>>
>>>>would 
>>>>
>>>>
>>>>>go outside the boundary of what is currently defined...so 
>>
>>alignment 
>>
>>>with 
>>>
>>>
>>>>>802.1s IMO would be a minimum requirement if we are to consider 
>>>
>>>carrying 
>>>
>>>
>>>>>VLAN information in GMPLS signalling.... 
>>>>>
>>>>>cheers Dave 
>>>>>
>>>>>You wrote.... 
>>>>>
>>>>>
>>>>>
>>>>>>Hi, 
>>>>>>
>>>>>>The authors of the draft might like to clarify for the list 
>>>>>>exactly what data plane operations they are suggesting. To me 
>>>>>>it seems possible that the draft is proposing VLAN ID 
>>>>>>*swapping*. But an alternative is that the VLAN ID is used as a 
>>>>>>label, but that the same label is used for the full length of 
>>>>>>the LSP. 
>>>>>>
>>>>>>Adrian 
>>>>>
>>>>>
>>>>>
>>>>>. 
>>>>>
>>>
>>>============================================================ The 
>>>information contained in this message may be privileged and 
>>>confidential and protected from disclosure. If the reader of this 
>>>message is not the intended recipient, or an employee or agent 
>>>responsible for delivering this message to the intended 
>>
>>recipient, you 
>>
>>>are hereby notified that any reproduction, dissemination or 
>>>distribution of this communication is strictly prohibited. 
>>
>>If you have 
>>
>>>received this communication in error, please notify us 
>>
>>immediately by 
>>
>>>replying to the message and deleting it from your computer. 
>>
>>Thank you. 
>>
>>>Tellabs ============================================================ 
>>>
>>>
>>
>>
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 09 Feb 2005 21:11:46 +0000
Message-ID: <B258A372CEA20246A363BB86753DB5360251E589@zrtphxm2>
From: "Don Fedyk" <[e-mail]>
To: [e-mail]
Subject: FW: Layer 2 Switching Caps LSPs
Date: Wed, 9 Feb 2005 16:10:46 -0500

Resending, ccamp list message never came through
------------------------------------------------ 

Hi

I read through this draft and the thread and I don't see that much detail.
Dimitri your statements are more about what this draft is not about. While
they would be useful additions in the draft for clarification, how does this
draft differ from one that just says:  "Lets define some code points for
TLVs for future signaling of packet technologies, ATM, FR and Ethernet"?
This is very similar to another SDO just asking for a few code points IMHO. 

Would it not be better to detail one technology and transport mode in
detail, rather than slowly refining the signaling for multiple technologies?


Regards,
Don 


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of [e-mail]
Sent: Saturday, February 05, 2005 11:43 AM
To: Allan, David 
Cc: '[e-mail]'; '[e-mail]'; Shahram
Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel;
[e-mail]
Subject: RE: Layer 2 Switching Caps LSPs


see my response to sharam - as you come all over again with the same issues
- 
the question is how many flows can you discriminate based on the VLAN_ID and
the response is 4k per port, drawing an analogy with a PE PW box the same
happens if a NSP per port, 
the second question is but *if* you discriminate the flows on a local basis
you are assuming a behaviour that is not defined by the IEEE (your initial
last CCAMP meeting question) and the response there are equivalent
mechanisms defined outside the scope of the IEEE and definition i was
pointing did include this behaviour (or more precisely does not preclude
it); 
the third question how is the forwarding occurring then and the response is
not necessarily using bridging/MAC learning as the path of these frames is
known from the LSP establishment (it is thus the establishment of the LSP
that determines external behaviour of the forwarding function) - note: as in
any standard there is no point in detailing the exact implementation of the
switching/ forwarding/connection function -
and lastly (closing the loop) the fourth question is does it require VLAN
swapping ? the response is no this mechanism is not assumed and (taking a
minimalistic assumption of VLAN continuity) just mandate ensuring per-port
(and not per node or other instances) VLAN interpretation and this would
only be constraining the establishment of the LSP at the end since
equivalent to a continuity principle (and this can also be tackled by GMPLS
using the label set mechanisms) - however you could with the document as
written assume that a VLAN_ID may be translated - note: i do not refer to
VLAN swapping - when crossing a node and document(as part of an appendix) a
similar table as the one written in Appendix A of
<draft-ietf-pwe3-ethernet-encap-08.txt> - i think at the end this is what
adrian was looking for as part of the documentation effort - 
note: this said to respond to your claim upon what's mandatory or not as
part of this document, the response did not change from the previous one and
the discussion we are having now is just because you are assuming a unique
and specific data plane behaviour as part of this document for which there
is no specification and then challenge this document as it would be the only
possible allowed behaviour while 1) this is not the case, and some of these
behaviours do not require anything else than what i document in my response
to sharam and 2) there is nothing that precludes proposing an interpretation
of a specific data plane field, or mechanism, or entity within the control
plane - ask yourself the question is it allowed to interpreet link locally a
data plane wavelength or timeslot as a label in the control plane ?
response: yes, as it is just a matter of convention (even if some are more
"natural" than others) but these interpretation orthogonal to the
implementation of the forwarding/switching/connection function

"David Allan" <[e-mail]>
02/04/2005 14:32 EST

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



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


> (but 
> also keep in mind that there are two levels of VLANs defined today so 
> further refinment is still possible) 

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

> and with 16 ports you would have 
> 64k LSPs not that bad for an unscalable solution ;-) 

How can I interpret this.... 

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

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

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

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

cheers 
Dave 




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

Subject: RE: Layer 2 Switching Caps LSPs 

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

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

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

To: "'[e-mail]'" <[e-mail]>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari
<[e-mail]>

cc: "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan
<[e-mail]>, Adrian Farrel <[e-mail]>,
[e-mail]

bcc: 
Subject: RE: Layer 2 Switching Caps LSPs 


Dimitri: 
<snipped> 
 (but 
> also keep in mind that there are two levels of VLANs defined today so 
> further refinment is still possible) and with 16 ports you would have 
> 64k LSPs not that bad for an unscalable solution ;-) 

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

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

rgds 
Dave 

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



Envelope-to: [e-mail]
Delivery-date: Wed, 09 Feb 2005 20:25:24 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-00.txt
Date: Wed, 09 Feb 2005 15:24:18 -0500

--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-00.txt
	Pages		: 17
	Date		: 2005-2-9
	
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-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-ietf-ccamp-inter-domain-rsvp-te-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-ietf-ccamp-inter-domain-rsvp-te-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.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-rsvp-te-00.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, 09 Feb 2005 18:42:32 +0000
Message-ID: <01b701c50ed6$dcc49c70$b5cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>, "Richard Rabbat" <[e-mail]>
Subject: Re: I-D ACTION:draft-bryskin-ccamp-gmpls-ason-lexicography-00.txt
Date: Wed, 9 Feb 2005 18:37:18 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Richard points out that I'm not as smart as the average draft submitter!

I will try to submit a version that actually contains the lexicography!

Cheers,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>
Sent: Wednesday, February 09, 2005 9:42 AM
Subject: Fw: I-D ACTION:draft-bryskin-ccamp-gmpls-ason-lexicography-00.txt


> Hi,
>
> The recent ITU-T Study Group 15 Question 14 meeting in Holmdel invited
> CCAMP participants to help resolve difficulties in understanding GMPLS
> terminology.
>
> This draft attempts to capture the resulting discussion and present a
> lexicography that allows the interpretation of some key GMPLS terms
within
> the context of ASON.
>
> Please note (as the draft is at pains to say) that this lexicography
> applies *only* within the ASON context. GMPLS is clearly a bigger thing,
> and is applicable to a much wider set of architectural models than
simply
> ASON. Thus, these definitions are *NOT* GMPLS definitions, but rather
they
> are indications of how you should interpret the GMPLS terms if you live
in
> an ASON world.
>
> Comments are very welcome.
>
> Thanks,
> Adrian and Igor
>
> ----- Original Message ----- 
> From: <[e-mail]>
> To: <[e-mail]>
> Sent: Tuesday, February 08, 2005 8:32 PM
> Subject: I-D ACTION:draft-bryskin-ccamp-gmpls-ason-lexicography-00.txt
>
>
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >
> > Title : 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
> > Author(s) : I. Bryskin, A. Farrel
> > Filename : draft-bryskin-ccamp-gmpls-ason-lexicography-00.txt
> > Pages : 2
> > Date : 2005-2-8
> >
> > Generalized Multiprotocol Label Switching (GMPLS) has been developed
> >    by the IETF to facilitate the establishment of Label Switched Paths
> >    (LSPs) in a variety of physical technologies and across several
> >    architectural models. The ITU-T has specified an architecture for
> >    the management of Automatically Switched Optical Networks (ASON).
> >
> > A URL for this Internet-Draft is:
> >
>
http://www.ietf.org/internet-drafts/draft-bryskin-ccamp-gmpls-ason-lexicography-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-bryskin-ccamp-gmpls-ason-lexicography-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-bryskin-ccamp-gmpls-ason-lexicography-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.
> >
>
>
> ------------------------------------------------------------------------
--
> ------
>
>
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/i-d-announce
> >
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 09 Feb 2005 09:46:04 +0000
Message-ID: <011d01c50e8c$057c7520$b5cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>
Subject: Fw: I-D ACTION:draft-bryskin-ccamp-gmpls-ason-lexicography-00.txt
Date: Wed, 9 Feb 2005 09:42:00 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

The recent ITU-T Study Group 15 Question 14 meeting in Holmdel invited
CCAMP participants to help resolve difficulties in understanding GMPLS
terminology.

This draft attempts to capture the resulting discussion and present a
lexicography that allows the interpretation of some key GMPLS terms within
the context of ASON.

Please note (as the draft is at pains to say) that this lexicography
applies *only* within the ASON context. GMPLS is clearly a bigger thing,
and is applicable to a much wider set of architectural models than simply
ASON. Thus, these definitions are *NOT* GMPLS definitions, but rather they
are indications of how you should interpret the GMPLS terms if you live in
an ASON world.

Comments are very welcome.

Thanks,
Adrian and Igor

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, February 08, 2005 8:32 PM
Subject: I-D ACTION:draft-bryskin-ccamp-gmpls-ason-lexicography-00.txt


> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : 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
> Author(s) : I. Bryskin, A. Farrel
> Filename : draft-bryskin-ccamp-gmpls-ason-lexicography-00.txt
> Pages : 2
> Date : 2005-2-8
>
> Generalized Multiprotocol Label Switching (GMPLS) has been developed
>    by the IETF to facilitate the establishment of Label Switched Paths
>    (LSPs) in a variety of physical technologies and across several
>    architectural models. The ITU-T has specified an architecture for
>    the management of Automatically Switched Optical Networks (ASON).
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-bryskin-ccamp-gmpls-ason-lexicography-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-bryskin-ccamp-gmpls-ason-lexicography-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-bryskin-ccamp-gmpls-ason-lexicography-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.
>


--------------------------------------------------------------------------
------


> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>




Envelope-to: [e-mail]
Delivery-date: Wed, 09 Feb 2005 07:35:24 +0000
Message-ID: <[e-mail]>
Date: Wed, 09 Feb 2005 08:33:52 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Shahram Davari <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, David Allan <[e-mail]>,  "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan <[e-mail]>,  Adrian Farrel <[e-mail]>, [e-mail]
Subject: Re: Layer 2 Switching Caps LSPs
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

sharam

[snip]

> I don't see the relevance of SE to what we are talking. I may be missing
> something, but does GMPLS support SE?

yes.

> -Shahram
> 
> 
>>
>>
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 08 Feb 2005 21:19:12 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: David Allan <[e-mail]>, "'[e-mail]'" <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Mon, 7 Feb 2005 12:00:18 -0800 
MIME-Version: 1.0
Content-Type: text/plain

Dimitri,

> >  Let me make it clear: IEEE does not permit translation of 
> the VLAN ID in
> > the Core-provider bridge (S-VLAN aware bridge) as well as 
> Legacy bridges
> > (C-VLAN aware bridge).
> 
> for your information as extracted from the last 802.1ad document
> (15-12-2004): i do want to mention this because the notion of VLAN_ID
> translation exist at the IEEE as well (note: in the above i 
> did mention the
> PWE3 doc)
> 
> "8.6.1 Ingress
> Change subclause 8.6.1 as follows. After the existing note, add the
> following note:
> NOTE 2?A Service-VLAN aware Bridge considers a received frame to be
> untagged if the initial octets of the MAC user data do not compose a
> Service VLAN tag header.
> Change the following paragraph as follows:
> An S-VLAN aware Bridge Port may implement a manageable VID Translation
> Table that specifies a value to be substituted for each of 
> the possible
> 4094 VID values assigned or received as specified above.

I am fully aware of 802.1d work, and I think you are misusing the VID Translation concept. The reason to permit VID translation in 802.1ad is for Inter-Area hand-off, in which a second operator may use a different VLAN for the same service than the first operator.

For sake of argument let's even assume each bridge operates like a single area, so that you could do VLAN swapping at every node (Aka Inter-area). One problem that you would have is that in an 802.1ad bridge all VLANs have the same meaning in all ports. In other words, you can have only 4000 entries in your VLAN switching table for an entire 802.1ad device. This is equivalent to a per-platform label space. So each 802.1ad bridge can't support more than 4000 LSPs (not matter how many ports it has). And as I said before this creates scalability issue. Unless you want people to use a different non-standard 802.1ad bridge. In that case you need to define proper architecture as a brand new transport technology, including  data-plane, control-plane and management plane and explain why it is better than other transport technologies like MPLS or provider bridge networks (aka, Q in Q).

> 
> > To answer your PWE3 question:
> >
> >    A PE that supports ETH PW, has 2 disjoint and distinct 
> components: An
> > IEEE 802.1D Ethernet Bridging component followed by an PW 
> IWF. The 802.1D
> > performs the switching based on VLAN ID (and possibly MAC address),
> 
> so now switching based on the VLAN ID becomes possible (while 
> only possibly
> on the MAC address) ? why not in the scope of the present 
> document then ?
> 
> > followed by a PW IWF that performs ETH PW processing. The 
> first component
> > (802.1D bridge) is not allowed to change the VLAN ID, because IEEE
> standards
> > does not permit that. The VLAN ID May only be changed in the PW IWF,
> since
> > it is outside the scope of IEEE.
> 
> ... so ETH processing within the context of the PW allows 
> such operation as
> i did pointed out (that was not defined by the IEEE - my 
> whole point -),
> and the question is why the same couldn't happen in the 
> present context ?

Because what you are proposing is not a simple Interworking function,
at the edge of standard transport technology. What you are proposing
is a new transport technology that requires proper architecture, and
comparison to other existing technologies to justify it.


> knowing that "bridging" is not a pre-requisite
> 
> > concerning the second point, the issue of merging has also 
> to be refined
> > from what you say as you can maintain two different LSPs on 
> a link that
> > share a common label (in the frame mode) - as briefly explained in
> section
> > 2.4.3 of RFC 3209 - this said the above operation is also 
> not excluded if
> > one desires maintaining separate labels
> 
> > What? SE is for Multicast application !!!!!!!! not what we 
> are talking
> > about.
> 
> SE Style is used among other for make-before-break; sharing, 
> MP2P, etc.
> that are not related to multicast (see RFC 3209)

I don't see the relevance of SE to what we are talking. I may be missing
something, but does GMPLS support SE?

-Shahram

> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 07 Feb 2005 17:17:41 +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: GMPLS signalling for IPv6 networks.
Date: Mon, 7 Feb 2005 17:16:17 -0000
Message-ID: <[e-mail]>
Thread-Topic: GMPLS signalling for IPv6 networks.
Thread-Index: AcUNOMCjC0yUlZoTR8qGIXn8s+DKww==
From: "Alan Davey" <[e-mail]>
To: <[e-mail]>

Hi

I have been looking at signaling GMPLS LSPs in IPv6 networks.  I think =
that the specification of TLVs for control channel separation signaling =
requires extension for use in an IPv6 network.  RFC3471 defines TLVs to =
identify component interfaces using an interface ID and a 32-bit router =
addresses.  I think that there should be equivalent TLVs defined with =
128-bit router addresses for use in IPv6 networks. =20

That is, there should be IPv6 equivalents, with 128-bit router =
addresses, to the following TLV types.

-  IF_INDEX                (Interface Index)   =20
-  COMPONENT_IF_DOWNSTREAM (Component interface)
-  COMPONENT_IF_UPSTREAM   (Component interface)

My reasoning is as follows.

-  In RFC3471, the IP address in the above TLVs is defined as "an IP =
address associated with the router, where associated address is the =
value carried in a router address TLV of routing".

-  Recent drafts from the OSPF and ISIS WGs have defined IPv6 traffic =
engineering extensions with 128-bit router addresses.

	-  draft-ietf-ospf-ospfv3-traffic, which defines extensions for traffic =
engineering to OSPFv3, defines a "Router IPv6 Address" TLV to advertise =
a stable IPv6 address that is always reachable if there is connectivity =
to the OSPFv3 router.

	-  draft-ietf-isis-ipv6-te defines a 128-bit "IPv6 TE Router ID" for =
supporting IPv6 traffic engineering.

-  The GMPLS TE specification needs to change (rather than the OSPF and =
ISIS drafts) to allow the use of an IPv6 control plane.  In particular, =
to allow GMPLS routers to be identified using IPv6 addresses.

-  Therefore, to identify interfaces using interface ID and router =
addresses in GMPLS, there need to be TLVs defined that are the =
equivalent to those listed above but with 128-bit router addresses, as =
suggested above.

Is there interest in a draft to specify extensions to RFC3471 for IPv6 =
networks?

All comments are welcome.

Regards

Alan Davey

------------------------------------
Alan Davey
Data Connection Ltd
Tel:   [phone]      =20
Fax:   [phone]
Email: [e-mail] =20
Web:   http://www.dataconnection.com=20





Envelope-to: [e-mail]
Delivery-date: Mon, 07 Feb 2005 13:59:46 +0000
Message-ID: <[e-mail]>
Date: Mon, 07 Feb 2005 14:57:41 +0100
From: [e-mail]
Reply-To: [e-mail]
Organization: Alcatel CIT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail], Adrian Farrel <[e-mail]>, [e-mail]
Subject: Presentation MRN
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

Dimitri,
A-t-on une presentation MRN ?
Merci.

-- 
Bela Berde, Ph.D.
Alcatel CIT
Research & Innovation, SART
Route de Nozay, 91461 Marcoussis Cedex, France
Tel: [phone]
Fax: [phone]




Envelope-to: [e-mail]
Delivery-date: Sat, 05 Feb 2005 16:44:53 +0000
To: "David Allan" <[e-mail]>
Cc: "'[e-mail]'"	 <[e-mail]>, "'[e-mail]'" <[e-mail]>, Shahram Davari <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Sat, 5 Feb 2005 17:42:38 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+c2VlIG15IHJlc3BvbnNlIHRvIHNoYXJhbSAtIGFzIHlvdSBjb21lIGFsbCBvdmVyIGFnYWlu
IHdpdGggdGhlIHNhbWUgaXNzdWVzIC0gPC9QPjxQPnRoZSBxdWVzdGlvbiBpcyBob3cgbWFueSBm
bG93cyBjYW4geW91IGRpc2NyaW1pbmF0ZSBiYXNlZCBvbiB0aGUgVkxBTl9JRCBhbmQgdGhlIHJl
c3BvbnNlIGlzIDRrIHBlciBwb3J0LCBkcmF3aW5nIGFuIGFuYWxvZ3kgd2l0aCBhIFBFIFBXIGJv
eCB0aGUgc2FtZSBoYXBwZW5zIGlmIGEgTlNQIHBlciBwb3J0LCA8L1A+PFA+dGhlIHNlY29uZCBx
dWVzdGlvbiBpcyBidXQgKmlmKiB5b3UgZGlzY3JpbWluYXRlIHRoZSBmbG93cyBvbiBhIGxvY2Fs
IGJhc2lzIHlvdSBhcmUgYXNzdW1pbmcgYSBiZWhhdmlvdXIgdGhhdCBpcyBub3QgZGVmaW5lZCBi
eSB0aGUgSUVFRSAoeW91ciBpbml0aWFsIGxhc3QgQ0NBTVAgbWVldGluZyBxdWVzdGlvbikgYW5k
IHRoZSByZXNwb25zZSB0aGVyZSBhcmUgZXF1aXZhbGVudCBtZWNoYW5pc21zIGRlZmluZWQgb3V0
c2lkZSB0aGUgc2NvcGUgb2YgdGhlIElFRUUgYW5kIGRlZmluaXRpb24gaSB3YXMgcG9pbnRpbmcg
ZGlkIGluY2x1ZGUgdGhpcyBiZWhhdmlvdXIgKG9yIG1vcmUgcHJlY2lzZWx5IGRvZXMgbm90IHBy
ZWNsdWRlIGl0KTsgPC9QPjxQPnRoZSB0aGlyZCBxdWVzdGlvbiBob3cgaXMgdGhlIGZvcndhcmRp
bmcgb2NjdXJyaW5nIHRoZW4gYW5kIHRoZSByZXNwb25zZSBpcyBub3QgbmVjZXNzYXJpbHkgdXNp
bmcgYnJpZGdpbmcvTUFDIGxlYXJuaW5nIGFzIHRoZSBwYXRoIG9mIHRoZXNlIGZyYW1lcyBpcyBr
bm93biBmcm9tIHRoZSBMU1AgZXN0YWJsaXNobWVudCAoaXQgaXMgdGh1cyB0aGUgZXN0YWJsaXNo
bWVudCBvZiB0aGUgTFNQIHRoYXQgZGV0ZXJtaW5lcyBleHRlcm5hbCBiZWhhdmlvdXIgb2YgdGhl
IGZvcndhcmRpbmcgZnVuY3Rpb24pIC0gbm90ZTogYXMgaW4gYW55IHN0YW5kYXJkIHRoZXJlIGlz
IG5vIHBvaW50IGluIGRldGFpbGluZyB0aGUgZXhhY3QgaW1wbGVtZW50YXRpb24gb2YgdGhlIHN3
aXRjaGluZy8gZm9yd2FyZGluZy9jb25uZWN0aW9uIGZ1bmN0aW9uIC08L1A+PFA+YW5kIGxhc3Rs
eSAoY2xvc2luZyB0aGUgbG9vcCkgdGhlIGZvdXJ0aCBxdWVzdGlvbiBpcyBkb2VzIGl0IHJlcXVp
cmUgVkxBTiBzd2FwcGluZyA/IHRoZSByZXNwb25zZSBpcyBubyB0aGlzIG1lY2hhbmlzbSBpcyBu
b3QgYXNzdW1lZCBhbmQgKHRha2luZyBhIG1pbmltYWxpc3RpYyBhc3N1bXB0aW9uIG9mIFZMQU4g
Y29udGludWl0eSkganVzdCBtYW5kYXRlIGVuc3VyaW5nIHBlci1wb3J0IChhbmQgbm90IHBlciBu
b2RlIG9yIG90aGVyIGluc3RhbmNlcykgVkxBTiBpbnRlcnByZXRhdGlvbiBhbmQgdGhpcyB3b3Vs
ZCBvbmx5IGJlIGNvbnN0cmFpbmluZyB0aGUgZXN0YWJsaXNobWVudCBvZiB0aGUgTFNQIGF0IHRo
ZSBlbmQgc2luY2UgZXF1aXZhbGVudCB0byBhIGNvbnRpbnVpdHkgcHJpbmNpcGxlIChhbmQgdGhp
cyBjYW4gYWxzbyBiZSB0YWNrbGVkIGJ5IEdNUExTIHVzaW5nIHRoZSBsYWJlbCBzZXQgbWVjaGFu
aXNtcykgLSBob3dldmVyIHlvdSBjb3VsZCB3aXRoIHRoZSBkb2N1bWVudCBhcyB3cml0dGVuIGFz
c3VtZSB0aGF0IGEgVkxBTl9JRCBtYXkgYmUgdHJhbnNsYXRlZCAtIG5vdGU6IGkgZG8gbm90IHJl
ZmVyIHRvIFZMQU4gc3dhcHBpbmcgLSB3aGVuIGNyb3NzaW5nIGEgbm9kZSBhbmQgZG9jdW1lbnQo
YXMgcGFydCBvZiBhbiBhcHBlbmRpeCkgYSBzaW1pbGFyIHRhYmxlIGFzIHRoZSBvbmUgd3JpdHRl
biBpbiBBcHBlbmRpeCBBIG9mICZsdDtkcmFmdC1pZXRmLXB3ZTMtZXRoZXJuZXQtZW5jYXAtMDgu
dHh0Jmd0OyAtIGkgdGhpbmsgYXQgdGhlIGVuZCB0aGlzIGlzIHdoYXQgYWRyaWFuIHdhcyBsb29r
aW5nIGZvciBhcyBwYXJ0IG9mIHRoZSBkb2N1bWVudGF0aW9uIGVmZm9ydCAtIDwvUD48UD5ub3Rl
OiB0aGlzIHNhaWQgdG8gcmVzcG9uZCB0byB5b3VyIGNsYWltIHVwb24gd2hhdCdzIG1hbmRhdG9y
eSBvciBub3QgYXMgcGFydCBvZiB0aGlzIGRvY3VtZW50LCB0aGUgcmVzcG9uc2UgZGlkIG5vdCBj
aGFuZ2UgZnJvbSB0aGUgcHJldmlvdXMgb25lIGFuZCB0aGUgZGlzY3Vzc2lvbiB3ZSBhcmUgaGF2
aW5nIG5vdyBpcyBqdXN0IGJlY2F1c2UgeW91IGFyZSBhc3N1bWluZyBhIHVuaXF1ZSBhbmQgc3Bl
Y2lmaWMgZGF0YSBwbGFuZSBiZWhhdmlvdXIgYXMgcGFydCBvZiB0aGlzIGRvY3VtZW50IGZvciB3
aGljaCB0aGVyZSBpcyBubyBzcGVjaWZpY2F0aW9uIGFuZCB0aGVuIGNoYWxsZW5nZSB0aGlzIGRv
Y3VtZW50IGFzIGl0IHdvdWxkIGJlIHRoZSBvbmx5IHBvc3NpYmxlIGFsbG93ZWQgYmVoYXZpb3Vy
IHdoaWxlIDEpIHRoaXMgaXMgbm90IHRoZSBjYXNlLCBhbmQgc29tZSBvZiB0aGVzZSBiZWhhdmlv
dXJzIGRvIG5vdCByZXF1aXJlIGFueXRoaW5nIGVsc2UgdGhhbiB3aGF0IGkgZG9jdW1lbnQgaW4g
bXkgcmVzcG9uc2UgdG8gc2hhcmFtIGFuZCAyKSB0aGVyZSBpcyBub3RoaW5nIHRoYXQgcHJlY2x1
ZGVzIHByb3Bvc2luZyBhbiBpbnRlcnByZXRhdGlvbiBvZiBhIHNwZWNpZmljIGRhdGEgcGxhbmUg
ZmllbGQsIG9yIG1lY2hhbmlzbSwgb3IgZW50aXR5IHdpdGhpbiB0aGUgY29udHJvbCBwbGFuZSAt
IGFzayB5b3Vyc2VsZiB0aGUgcXVlc3Rpb24gaXMgaXQgYWxsb3dlZCB0byBpbnRlcnByZWV0IGxp
bmsgbG9jYWxseSBhIGRhdGEgcGxhbmUgd2F2ZWxlbmd0aCBvciB0aW1lc2xvdCBhcyBhIGxhYmVs
IGluIHRoZSBjb250cm9sIHBsYW5lID8gcmVzcG9uc2U6IHllcywgYXMgaXQgaXMganVzdCBhIG1h
dHRlciBvZiBjb252ZW50aW9uIChldmVuIGlmIHNvbWUgYXJlIG1vcmUgJnF1b3Q7bmF0dXJhbCZx
dW90OyB0aGFuIG90aGVycykgYnV0IHRoZXNlIGludGVycHJldGF0aW9uIG9ydGhvZ29uYWwgdG8g
dGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBmb3J3YXJkaW5nL3N3aXRjaGluZy9jb25uZWN0aW9u
IGZ1bmN0aW9uPEJSPiA8QlI+PEZPTlQgU0laRT0yPjxCPiZxdW90O0RhdmlkIEFsbGFuJnF1b3Q7
ICZsdDtkYWxsYW5Abm9ydGVsLmNvbSZndDs8L0I+PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+MDIv
MDQvMjAwNSAxNDozMiBFU1Q8L0ZPTlQ+PEJSPjxCUj4gPEZPTlQgU0laRT0yPlRvOjwvRk9OVD4g
PEZPTlQgU0laRT0yPkRpbWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUw8L0ZP
TlQ+PEJSPiA8Rk9OVCBTSVpFPTI+Y2M6PC9GT05UPiA8Rk9OVCBTSVpFPTI+JnF1b3Q7J2RwYXBh
ZGltaXRyaW91QHBzZy5jb20nJnF1b3Q7ICZsdDtkcGFwYWRpbWl0cmlvdUBwc2cuY29tJmd0Oywg
U2hhaHJhbSBEYXZhcmkgJmx0O1NoYWhyYW1fRGF2YXJpQHBtYy1zaWVycmEuY29tJmd0OywgJnF1
b3Q7TWFjay1DcmFuZSwgVC4gQmVuamFtaW4mcXVvdDsgJmx0O0Jlbi5NYWNrLUNyYW5lQHRlbGxh
YnMuY29tJmd0OywgRGF2aWQgQWxsYW4gJmx0O2RhbGxhbkBub3J0ZWxuZXR3b3Jrcy5jb20mZ3Q7
LCBBZHJpYW4gRmFycmVsICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OywgY2NhbXBAb3BzLmll
dGYub3JnPC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0la
RT0yPlN1YmplY3Q6PC9GT05UPiA8Rk9OVCBTSVpFPTI+UkU6IExheWVyIDIgU3dpdGNoaW5nIENh
cHMgTFNQczwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPk9LIGxldCBtZSBkZWNvbXBvc2UgeW91
ciBsYXN0IHJlc3BvbnNlIGFuZCBzZWUgaWYgd2UgY2FuIGJvdHRvbSB0aGlzIG91dC4uLi48Rk9O
VCBTSVpFPTQ+IDwvRk9OVD48QlI+PEJSPiZndDsgKGJ1dCA8QlI+Jmd0OyBhbHNvIGtlZXAgaW4g
bWluZCB0aGF0IHRoZXJlIGFyZSB0d28gbGV2ZWxzIG9mIFZMQU5zIGRlZmluZWQgdG9kYXkgc28g
PEJSPiZndDsgZnVydGhlciByZWZpbm1lbnQgaXMgc3RpbGwgcG9zc2libGUpIDxCUj48QlI+TXkg
aW50ZXJwcmV0YXRpb24gb2YgJnF1b3Q7cmVmaW5lbWVudCZxdW90OyBpbXBsaWVzIG1vZGlmaWNh
dGlvbiB0byBleGlzdGluZyBwcm9jZWR1cmVzLiBKdWRnaW5nIGZyb20geW91ciBsYXN0IHJlc3Bv
bnNlLCB5b3UgYXJlIHNpbXBseSByZWZlcnJpbmcgdG8gaGllcmFyY2h5IHdoaWNoIGlzIGFuIGV4
aXN0aW5nIHNvbHV0aW9uIGFuZCByZXF1aXJlcyBubyAmcXVvdDtyZWZpbmVtZW50JnF1b3Q7LiA8
QlI+PEJSPiZndDsgYW5kIHdpdGggMTYgcG9ydHMgeW91IHdvdWxkIGhhdmUgPEJSPiZndDsgNjRr
IExTUHMgbm90IHRoYXQgYmFkIGZvciBhbiB1bnNjYWxhYmxlIHNvbHV0aW9uIDstKSA8QlI+PEJS
PkhvdyBjYW4gSSBpbnRlcnByZXQgdGhpcy4uLi48Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+PEJS
Pi0gSSBjb3VsZCBoYXZlIDRrIFZMQU5zIGFsbCB3aXRoIGEgY29tbW9uIHRvcG9sb2d5IChicmlk
Z2UgZm9yIDE2IHNwb2tlcykuIDxCUj48QlI+LSBVc2luZyBWTEFOIHN3YXBwaW5nIEkgY291bGQg
aGF2ZSA2NGsgdW5pLWRpcmVjdGlvbmFsIExTUHMgb25seSBpbiBhIHBlcmZlY3Qgd29ybGQgd2hl
cmUgSSBoYWQgYW4gZXhhY3RseSBmbGF0IGRpc3RyaWJ1dGlvbiBhY29yc3MgdGhlIHBvcnRzIGFz
IHRvIGhvdyB0aGV5IHdlcmUgcm91dGVkLiAoQlRXIEFueSBzb3J0IG9mIGFnZ3JlZ2F0aW9uIHNj
ZW5hcmlvIGNvdWxkIGRyYWcgdGhhdCBudW1iZXIgZG93biB0byBhIG1heGltdW0gb2YgNGsgTFNQ
cykuPEJSPjxCUj5Ib3dldmVyIHRoZSBzZWNvbmQgcmVxdWlyZXMgVkxBTiB0YWcgc3dhcHBpbmcg
d2hpY2ggeW91ciBhbmQgeW91ciBjby1hdXRob3JzIGNvbW1lbnRzIGluIHRoZSBwYXN0IGhhdmUg
c3VnZ2VzdGVkIHdhcyBub3QgdGhlIHB1cnBvc2Ugb2YgdGhpcyBkcmFmdC4gTWFueSBvZiB1cyB2
aW9sZW50bHkgb2JqZWN0IHRvIFZMQU4gYXdhcHBpbmcgYXMgaXQgaXMgZGF0YSBwbGFuZSBiZWhh
dmlvciB0aGF0IGlzIG5vdCBzcGVjaWZpZWQgYW55d2hlcmUsIGFuZCB3ZSBzZWUgbm8gdXRpbGl0
eSBpbiBkZWZpbmluZyBhIGNvbnRyb2wgcGxhbmUgZm9yIHRoaW5ncyB0aGF0IGRvIG5vdCBleGlz
dC4uLi48QlI+PEJSPklzIHRoZXJlIGEgdGhpcmQgb3B0aW9uIHRoYXQgSSBoYXZlIG5vdCB1bmRl
cnN0b29kIGltcGxpZWQgYnkgeW91ciBsYXRlc3QgY29tbWVudHM/PEZPTlQgU0laRT00PiA8L0ZP
TlQ+PEJSPjxCUj5jaGVlcnM8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+RGF2ZTxGT05UIFNJWkU9
ND4gPC9GT05UPjxCUj48QlI+PEJSPjxCUj48QlI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08
Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+RnJvbTogRGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0
ZWwuYmUgWzxGT05UIENPTE9SPUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86RGltaXRyaS5QYXBhZGlt
aXRyaW91QGFsY2F0ZWwuYmU+bWFpbHRvOkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJl
PC9BPjwvVT48L0ZPTlQ+PEZPTlQgQ09MT1I9QkxBQ0s+XSA8QlI+U2VudDogRnJpZGF5LCBGZWJy
dWFyeSAwNCwgMjAwNSAxOjM0IFBNPC9GT05UPjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj5Ubzog
QWxsYW4sIERhdmlkIFtDQVI6TlMwMDpFWENIXTxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj5DYzog
J2RwYXBhZGltaXRyaW91QHBzZy5jb20nOyAnZGltaXRyaS5wYXBhZGltaXRyaW91QGFsY2F0ZWwu
YmUnOyBTaGFocmFtIERhdmFyaTsgTWFjay1DcmFuZSwgVC4gQmVuamFtaW47IERhdmlkIEFsbGFu
OyBBZHJpYW4gRmFycmVsOyBjY2FtcEBvcHMuaWV0Zi5vcmc8QlI+PEJSPlN1YmplY3Q6IFJFOiBM
YXllciAyIFN3aXRjaGluZyBDYXBzIExTUHM8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+PEJSPmRh
dmUgLSB5b3VyIHJlc3BvbnNlIGlzICZxdW90O3lvdSBkb24ndCB0aGluayByZWZpbm1lbnQgd291
bGQgYmUgcG9zc2libGUmcXVvdDsgZm9yIGEgcmVhc29uIHRoYXQgZXNjYXBlcyBtZSBzaW5jZSB0
aGUgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5lIGNvbnRyb2wgb2YgcHJvdmlkZXIgYnJpZGdlcyBh
bmQgYXMgaSBkbyBub3QgdGhpbmsgaSBoYXZlIG1lbnRpb25lZCB0aGUgJnF1b3Q7c25vb3Bpbmcm
cXVvdDsgb3BlcmF0aW9uIHlvdSBhcmUgZGVzY3JpYmluZyBoZXJlIGJlbG93IC0geW91IGFyZSBt
b3JlIGNyZWF0aXZlIHRoYW4gaSBkbyA7LSk8QlI+PEJSPm5vdGU6IHRoaXMgc2FpZCBpdCBkb2Vz
IG5vdCBjaGFuZ2UgdGhlIG51bWJlcnMgcHJvdmlkZWQgaGVyZSBiZWxvdyAtIGFuZCBpIGNhbiBs
aXZlIHdpdGggNjRrIExTUHMgKGF0IGxlYXN0IGluIGEgZmlyc3QgcGhhc2UpIDxCUj48QlI+JnF1
b3Q7RGF2aWQgQWxsYW4mcXVvdDsgJmx0O2RhbGxhbkBub3J0ZWwuY29tJmd0OzxGT05UIFNJWkU9
ND4gPC9GT05UPjxCUj4wMi8wNC8yMDA1IDA5OjQ0IEVTVDxGT05UIFNJWkU9ND4gPC9GT05UPjxC
Uj48QlI+VG86ICZxdW90OydkcGFwYWRpbWl0cmlvdUBwc2cuY29tJyZxdW90OyAmbHQ7ZHBhcGFk
aW1pdHJpb3VAcHNnLmNvbSZndDssIERpbWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFM
Q0FURUwsIFNoYWhyYW0gRGF2YXJpICZsdDtTaGFocmFtX0RhdmFyaUBwbWMtc2llcnJhLmNvbSZn
dDs8QlI+PEJSPmNjOiAmcXVvdDtNYWNrLUNyYW5lLCBULiBCZW5qYW1pbiZxdW90OyAmbHQ7QmVu
Lk1hY2stQ3JhbmVAdGVsbGFicy5jb20mZ3Q7LCBEYXZpZCBBbGxhbiAmbHQ7ZGFsbGFuQG5vcnRl
bG5ldHdvcmtzLmNvbSZndDssIEFkcmlhbiBGYXJyZWwgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsm
Z3Q7LCBjY2FtcEBvcHMuaWV0Zi5vcmc8QlI+PEJSPmJjYzogPEJSPlN1YmplY3Q6IFJFOiBMYXll
ciAyIFN3aXRjaGluZyBDYXBzIExTUHM8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+PEJSPjxCUj5E
aW1pdHJpOiA8QlI+Jmx0O3NuaXBwZWQmZ3Q7IDxCUj4mbmJzcDsoYnV0IDxCUj4mZ3Q7IGFsc28g
a2VlcCBpbiBtaW5kIHRoYXQgdGhlcmUgYXJlIHR3byBsZXZlbHMgb2YgVkxBTnMgZGVmaW5lZCB0
b2RheSBzbyA8QlI+Jmd0OyBmdXJ0aGVyIHJlZmlubWVudCBpcyBzdGlsbCBwb3NzaWJsZSkgYW5k
IHdpdGggMTYgcG9ydHMgeW91IHdvdWxkIGhhdmUgPEJSPiZndDsgNjRrIExTUHMgbm90IHRoYXQg
YmFkIGZvciBhbiB1bnNjYWxhYmxlIHNvbHV0aW9uIDstKSA8QlI+PEJSPlN1Z2dlc3Rpbmcgc25v
b3BpbmcgYSA4MDIuMWFkIFZMQU4gc3RhY2sgdG8gZm9yd2FyZCBvbiB0aGUgYmFzaXMgb2YgbW9y
ZSB0aGFuIG9uZSB0YWcgaXMgbW9yZSBjcmVhdGl2ZSBhYnVzZSBvZiBleGlzdGluZyBzdGFuZGFy
ZHMuIFlvdSBjYW5ub3QgcHJlc2VydmUgdGhlIHZhbHVlIGFuZCBzaW1wbGljaXR5IG9mIEV0aGVy
bmV0IGlmIHlvdSBpbnNpc3Qgb24gcmUtaW52ZW50aW5nIGl0Li4uQSBwcm92aWRlciBicmlkZ2Ug
Zm9yd2FyZHMgb24gdGhlIGJhc2lzIHRvIFMtdGFnIGFuZCBNQUMgYWRkcmVzcy4gVGhlIEMtdGFn
IGhhcyBubyBzaWduaWZpY2FuY2UgYW5kIHdlIHdvdWxkIGJlIGZvb2xpc2ggdG8gcHVyc3VlIGEg
cGF0aCB3aGVyZWJ5IGl0IGRvZXMuPEJSPjxCUj5NUExTIGRldmljZXMgKGFsbCBkaXN1Y3NzaW9u
IG9mIEVDTVAgYXNpZGUpIG9ubHkgZm9yd2FyZCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRvcCBsYWJl
bC4gPEJSPjxCUj5yZ2RzIDxCUj5EYXZlIDxCUj48QlI+Jmd0OyA8QlI+Jmd0OyBub3RlOiBpIGhh
dmUgZXhwbGFpbmVkIGluIGEgcHJldmlvdXMgbWFpbCB3aGVyZSB1c2Ugb2YgUFcgbWFrZXMgbW9y
ZSA8QlI+Jmd0OyBzZW5zZSBhbmQgd2hlcmUgaXQgZG9lcyBsZXNzLCBhbmQgd2hlcmUgaXQgZG9l
cyBzaW1wbHkgbm90IDxCUj4mZ3Q7IDxCUj4mZ3Q7IFNoYWhyYW0gRGF2YXJpIHdyb3RlOiA8QlI+
Jmd0OyAmZ3Q7IERpbWl0cmksIDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBJIGhhdmUgYW5v
dGhlciBxdWVzdGlvbi4gQXMgeW91IGtub3cgdGhlcmUgYXJlIG9ubHkgNDA5NCBWTEFOcyAoMTIg
PEJSPiZndDsgJmd0OyBiaXQpLiBUaGlzIG1lYW5zIG9ubHkgNDA5NCBQMlAgY29ubmVjdGlvbiBj
b3VsZCBiZSBzZXR1cCA8QlI+Jmd0OyB1c2luZyBHTVBMUy4gPEJSPiZndDsgJmd0OyBTaW5jZSB0
aGlzIGlzIG5vdCBzY2FsYWJsZSwgcHJlc3VtYWJseSB5b3UgbmVlZCBhIDxCUj4mZ3Q7IG11bHRp
cGxleGluZyBsYWJlbCA8QlI+Jmd0OyAmZ3Q7IChzdWNoIGFzIE1QTFMgb3IgYW5vdGhlciBWTEFO
IHRhZyksIGFuZCBpdHMgYXNzb2NpYXRlZCBzaWduYWxpbmcgPEJSPiZndDsgJmd0OyBiZXR3ZWVu
IHR3byBlZGdlcyBvZiB0aGUgbmV0d29yay4gU28gd2h5IG5vdCB1c2UgUFcgYW5kIGJlIDxCUj4m
Z3Q7IGRvbmUgd2l0aCA8QlI+Jmd0OyAmZ3Q7IGl0LiA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZn
dDsgLVNoYWhyYW0gPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tIEZyb206IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyA8QlI+Jmd0OyAmZ3Q7IFs8
Rk9OVCBDT0xPUj1CTFVFPjxVPjxBIEhSRUY9bWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9y
Zz5tYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnPC9BPjwvVT48L0ZPTlQ+PEZPTlQgQ09M
T1I9QkxBQ0s+XU9uIEJlaGFsZiBPZiBTaGFocmFtIERhdmFyaSBTZW50OiA8QlI+Jmd0OyAmZ3Q7
IFRodXJzZGF5LCBGZWJydWFyeSAwMywgMjAwNSA2OjE5IFBNIFRvOiA8QlI+Jmd0OyAmZ3Q7ICdE
aW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZScgQ2M6IE1hY2stQ3JhbmUsIFQuIEJlbmph
bWluOyA8QlI+Jmd0OyAmZ3Q7IGRwYXBhZGltaXRyaW91QHBzZy5jb207IERhdmlkIEFsbGFuOyBB
ZHJpYW4gRmFycmVsOyA8QlI+Jmd0OyBjY2FtcEBvcHMuaWV0Zi5vcmcgPEJSPiZndDsgJmd0OyBT
dWJqZWN0OiBSRTogTGF5ZXIgMiBTd2l0Y2hpbmcgQ2FwcyBMU1BzIDxCUj4mZ3Q7ICZndDsgPEJS
PiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IEhpIERpbWl0cmksIDxCUj4mZ3Q7ICZndDsgPEJSPiZn
dDsgJmd0OyBUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UuIFBsZWFzZSBzZWUgbXkgY29tbWVudHMg
aW4tbGluZS4gPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IC1TaGFocmFtIDxCUj4mZ3Q7ICZn
dDsgPEJSPiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBEaW1pdHJp
LlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZSA8QlI+Jmd0OyAmZ3Q7IFs8L0ZPTlQ+PEZPTlQgQ09M
T1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5i
ZT5tYWlsdG86RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmU8L0E+PC9VPjwvRk9OVD48
Rk9OVCBDT0xPUj1CTEFDSz5dIFNlbnQ6IFRodXJzZGF5LCA8QlI+Jmd0OyBGZWJydWFyeSAwMywg
PEJSPiZndDsgJmd0OyAyMDA1IDU6MzEgUE0gVG86IFNoYWhyYW0gRGF2YXJpIENjOiA8QlI+Jmd0
OyAmZ3Q7ICdEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZSc7IE1hY2stQ3JhbmUsIFQu
IEJlbmphbWluOyA8QlI+Jmd0OyAmZ3Q7IGRwYXBhZGltaXRyaW91QHBzZy5jb207IERhdmlkIEFs
bGFuOyBBZHJpYW4gRmFycmVsOyA8QlI+Jmd0OyBjY2FtcEBvcHMuaWV0Zi5vcmcgPEJSPiZndDsg
Jmd0OyBTdWJqZWN0OiBSRTogTGF5ZXIgMiBTd2l0Y2hpbmcgQ2FwcyBMU1BzIDxCUj4mZ3Q7ICZn
dDsgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgc2hhcmFtLCB0aGUg
Zmlyc3QgaXNzdWUgaXMgdGhhdCB5b3UgaGF2ZSB0byBkZWNvdXBsZSB0aGUgbm90aW9uIG9mIDxC
Uj4mZ3Q7ICZndDsgZXRoZXJuZXQgd2l0aCBicmlkZ2luZywgPEJSPiZndDsgJmd0OyA8QlI+Jmd0
OyAmZ3Q7IEV0aGVybmV0IG5ldHdvcmtzIGhhdmUgMyBtYWluIGxheWVyczogPEJSPiZndDsgJmd0
OyA8QlI+Jmd0OyAmZ3Q7IDEpIFBIWSA9IDEwLzEwMC8xRy8xMEcgYXMgZXhwbGFpbmVkIGluIDgw
Mi4zLCA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgMikgTUFDID0gODAyLjMgPEJSPiZndDsg
Jmd0OyA8QlI+Jmd0OyAmZ3Q7IDMpIEJyaWRnaW5nID0gODAyLjFEIDxCUj4mZ3Q7ICZndDsgPEJS
PiZndDsgJmd0OyBXaXRob3V0IEJyaWRnaW5nIGxheWVyIHlvdXIgZGV2aWNlIGNhbiBvbmx5IGhh
dmUgYSBzaW5nbGUgcG9ydC4gPEJSPiZndDsgJmd0OyBFeGFtcGxlIGlzIHRoZSBFdGhlcm5ldCBw
b3J0IG9mIHlvdXIgZGVza3RvcCBjb21wdXRlci4gVGhlcmVmb3JlIGlmIDxCUj4mZ3Q7ICZndDsg
eW91IHdhbnQgdG8gYnVpbGQgYW4gRXRoZXJuZXQgbmV0d29yaywgeW91IG5lZWQgYnJpZGdpbmcg
bGF5ZXIuIDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7
ICZndDsgdGhlIHNlY29uZCBpcyB0aGF0IHRoaXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb24gY2Fu
IGJlIGF1dG9tYXRlZCAtIDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBCdXQgYWZ0ZXIgeW91
IGhhdmUgY29uZmlndXJlZCB5b3VyIGNvbm5lY3Rpb25zIChha2EgVkxBTiA8QlI+Jmd0OyBwb3J0
cyksIHRoZW4gPEJSPiZndDsgJmd0OyB0aGVyZSBpcyBub3RoaW5nIGxlZnQgZm9yIEdNUFMgdG8g
ZG8uIE9yIGFyZSB5b3Ugc2F5aW5nIDxCUj4mZ3Q7IHRoYXQgdGhlIEdNUExTIDxCUj4mZ3Q7ICZn
dDsgd2lsbCBkbyB0aGUgY29uZmlndXJhdGlvbj8gPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7
IGhvd2V2ZXIgdGhlIGludGVyZXN0aW5nIHBvaW50IHlvdSBicm91Z2h0IGluIHRoZSBsb29wIG9m
IGRpc2N1c3Npb24gPEJSPiZndDsgJmd0OyBoZXJlIGlzICZxdW90O2FwcGxpY2FiaWxpdHkgZm9y
IHNoYXJlZCBtZWRpdW0mcXVvdDsgLSBpc24ndCB0aGUgUFcgPEJSPiZndDsgc29sdXRpb24gaW4g
PEJSPiZndDsgJmd0OyB0aGUgc2FtZSBjb250ZXh0IDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0
OyBObywgYmVjYXVzZSBpbiBQVywgdGhlIHBheWxvYWQgKEV0aGVybmV0KSBpcyBlbmNhcHN1bGF0
ZWQgPEJSPiZndDsgaW4gYW5vdGhlciA8QlI+Jmd0OyAmZ3Q7IGxheWVyIG5ldHdvcmsgKGFrYSBN
UExTKSwgYW5kIGlzIGludmlzaWJsZSB0byB0aGUgPEJSPiZndDsgaW50ZXJtZWRpYXRlIG5vZGVz
LiA8QlI+Jmd0OyAmZ3Q7IFdoaWxlIGluIHlvdXIgY2FzZSB0aGVyZSBpcyBubyBlbmNhcHN1bGF0
aW9uLCBhbmQgYWxsIHRoZSA8QlI+Jmd0OyBpbnRlcm1lZGlhdGUgPEJSPiZndDsgJmd0OyBub2Rl
cyBjYW4gYWN0IG9uIHRoZSBNQUMgYW5kIFZMQU4gdGFnLiA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7
ICZndDsgYXMgMSkgaXQgY2FuIG5vdCBtYWtlIGFuIGF1dG9tYXRlZCB1c2FnZSBvZiBhICZxdW90
O21lZGl1bSZxdW90OyB3aXRob3V0IDxCUj4mZ3Q7ICZndDsgY29uZmlndXJpbmcgdGhlIHR1bm5l
bHMgKGluIG91ciBjYXNlIHRoZSB0dW5uZWxzIHRoYXQgd2lsbCA8QlI+Jmd0OyBiZSB1c2VkIHRv
IDxCUj4mZ3Q7ICZndDsgY2FycnkgdGhlIGV0aGVybmV0IHBheWxvYWQgZS5nLiBTREgsIE9USCwg
ZXRjLiBpZiBub3QgdXNpbmcgPEJSPiZndDsgJmd0OyBwb2ludC10by1wb2ludCBQSFkncykgYnV0
IGluIGFkZGl0aW9uIHRvIHRoZSBwcmVzZW50IDxCUj4mZ3Q7IHNvbHV0aW9uIFBXIGFsc28gPEJS
PiZndDsgJmd0OyByZXF1aXJlcyAyKSB0aGUgcHJvdmlzaW9uaW5nIG9mIHRoZSBQVyAtIHNvbWV0
aGluZyBub3QgPEJSPiZndDsgbmVlZGVkIGluIHRoZSA8QlI+Jmd0OyAmZ3Q7IHByZXNlbnQgY29u
dGV4dCBhcyB0ZXJtaW5hdGluZyBwb2ludHMgd2lsbCBiZSBkaXJlY3RseSA8QlI+Jmd0OyBhY2Nl
c3NpbmcgdGhlIDxCUj4mZ3Q7ICZndDsgJnF1b3Q7ZXRoZXJuZXQgbWVkaXVtJnF1b3Q7LCBpbiBi
cmllZiBpZiBzdWNoIGFyZ3VtZW50IGlzIHVzZWQgaGVyZSBpdCBzaG91bGQgPEJSPiZndDsgJmd0
OyBoYXZlIGFsc28gYmVlbiB1c2VkIGluIHRoZSBQVyBjb250ZXh0IChpZiBub3QgbW9yZSBpbnRl
bnNpdmVseSkgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IGFub3RoZXIgZnVuZGFtZW50YWwg
cG9pbnQsIGkgYW0gYWxzbyBzdXJwcmlzZWQgc2VlaW5nIHBlb3BsZSA8QlI+Jmd0OyAmZ3Q7IHN1
cHBvcnRpbmcgTVBMUyAod2hpY2ggYnJpbmdzIGEgY29ubmVjdGlvbi1vcmllbnRlZCA8QlI+Jmd0
OyBiZWhhdmlvdXIgdG8gSVApIDxCUj4mZ3Q7ICZndDsgd29uZGVyaW5nIGFib3V0IHRoZSBzdWl0
YWJpbGl0eSBvZiB1c2luZyBvbmUgb2YgdGhlIDxCUj4mZ3Q7IHByb3RvY29sIHN1aXRlIG9mIDxC
Uj4mZ3Q7ICZndDsgdGhlIElFVEYgaS5lLiBHTVBMUyB0byBicmluZyBhbm90aGVyIChpbml0aWFs
bHkpIGNvbm5lY3Rpb25sZXNzIDxCUj4mZ3Q7ICZndDsgdGVjaG5vbG9neSB0byBhICZxdW90O2Nv
bm5lY3Rpb24tb3JpZW50ZWQmcXVvdDsgYmVoYXZpb3VyIDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsg
Jmd0OyBJIGRvbid0IGFyZ3VlIGFnYWluc3QgYnJpbmdpbmcgY29ubmVjdGlvbi1vcmllbnRlZCBi
ZWhhdmlvciB0byA8QlI+Jmd0OyAmZ3Q7IEV0aGVybmV0LiBNeSBjb25jZXJuIGlzIHRoZSBtZXRo
b2QgdXNlZCB0byBkbyBzby4gaWYgeW91IGhhZCBkb25lIDxCUj4mZ3Q7ICZndDsgcHJvcGVyIE5l
dHdvcmsgSW50ZXJ3b3JraW5nIChha2EsIGVuY2Fwc3VsYXRpb24gb3IgYXMgSVRVIGNhbGxzIGl0
IDxCUj4mZ3Q7ICZndDsgY2xpZW50L3NlcnZlciksIHRoZW4gdGhlcmUgd291bGQgbm90IGJlIGFu
eSBwcm9ibGVtLiA8QlI+Jmd0OyBIb3dldmVyLCB3aGF0IHlvdSA8QlI+Jmd0OyAmZ3Q7IGFyZSB0
cnlpbmcgdG8gZG8gaXMgdG8gbW9kaWZ5IEV0aGVybmV0J3MgY29udHJvbC1wbGFuZSBpbiBhIDxC
Uj4mZ3Q7IHdheSB0aGF0IDxCUj4mZ3Q7ICZndDsgcmVxdWlyZXMgbW9kaWZpY2F0aW9uIHRvIGl0
cyBkYXRhLXBsYW5lIGJlaGF2aW9yLiBBcyBhbiA8QlI+Jmd0OyBhbmFsb2d5IHdoYXQgPEJSPiZn
dDsgJmd0OyB5b3UgYXJlIGRvaW5nIGlzIGxpa2UgdHJ5aW5nIHRvIHVzZSB0aGUgSVAgYWRkcmVz
cyBhcyBNUExTIHRhZyBpbiA8QlI+Jmd0OyAmZ3Q7IG9yZGVyIHRvIG1ha2UgSVAgY29ubmVjdGlv
bi1vcmllbnRlZC4gPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IEluIGNvbnRyYXN0IHlvdSBj
b3VsZCBlYXNpbHkgY2hhbmdlIEFUTSdzIGNvbnRyb2wtcGxhbmUgdG8gR01QTFMgPEJSPiZndDsg
Jmd0OyB3aXRob3V0IGFueSBtb2RpZmljYXRpb24gdG8gQVRNIGRhdGEtcGxhbmUgYmVoYXZpb3Is
IGJlY2F1c2UgQVRNIGJ5IDxCUj4mZ3Q7ICZndDsgZGVzaWduIGlzIGNvbm5lY3Rpb24tb3JpZW50
ZWQsIGFuZCB0aGUgVlBJL1ZDSSBjb3VsZCBlYXNpbHkgYmUgPEJSPiZndDsgJmd0OyBpbnRlcnBy
ZXRlZCBhcyBHTVBMUyB0YWdzLiA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgKGV2ZW4gaWYg
aSBkbyByYXRoZXIgcHJlZmVyIHRoZSB0ZXJtIGZsb3csIGluIHRoZSBwcmVzZW50IDxCUj4mZ3Q7
IGNvbnRleHQpIGF0IDxCUj4mZ3Q7ICZndDsgdGhlIGVuZCB0aGUgcmVzdWx0aW5nIGdhaW4gaXMg
dGhlIHNhbWUgZm9yIGJvdGggPEJSPiZndDsgdGVjaG5vbG9naWVzIGl0IHRlcm1zIDxCUj4mZ3Q7
ICZndDsgb2YgY2FwYWJpbGl0aWVzIGFzIGFwcGxpY2F0aW9uIG9mIGNvbnN0cmFpbnQtYmFzZWQg
cm91dGluZyA8QlI+Jmd0OyBwcmluY2lwbGVzIDxCUj4mZ3Q7ICZndDsgLSBpcyB0aGlzIG5vdCBh
dCB0aGUgZW5kIHdoYXQgZHJpdmVzIG1vc3RseSBhbGwgZGViYXRlcyBpbiA8QlI+Jmd0OyB0aGUg
KEcpTVBMUyA8QlI+Jmd0OyAmZ3Q7IGdhbGF4eSBiZXNpZGUgVlBOcyBhbmQgdGhhdCB3YXMgdW5k
ZXJseWluZyBpbmNvcnBvcmF0aW9uIG9mIDxCUj4mZ3Q7IHRoZXNlIEwyIDxCUj4mZ3Q7ICZndDsg
dGVjaG5vbG9naWVzIGFzIHBhcnQgb2YgdGhlIEdNUExTIHByb3RvY29sIGFyY2hpdGVjdHVyZSA8
QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgdGhhbmtzLCA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7
ICZndDsgLSBkaW1pdHJpLiA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0
OyBTaGFocmFtIERhdmFyaSAmbHQ7U2hhaHJhbV9EYXZhcmlAcG1jLXNpZXJyYS5jb20mZ3Q7IFNl
bnQgYnk6IDxCUj4mZ3Q7ICZndDsgb3duZXItY2NhbXBAb3BzLmlldGYub3JnIDAyLzAzLzIwMDUg
MTM6MTMgUFNUIDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBUbzogRGltaXRyaSBQQVBBRElN
SVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTCwgJnF1b3Q7TWFjay1DcmFuZSwgVC4gPEJSPiZndDsg
Jmd0OyBCZW5qYW1pbiZxdW90OyAmbHQ7QmVuLk1hY2stQ3JhbmVAdGVsbGFicy5jb20mZ3Q7IGNj
OiBkcGFwYWRpbWl0cmlvdUBwc2cuY29tLCA8QlI+Jmd0OyAmZ3Q7IERhdmlkIEFsbGFuICZsdDtk
YWxsYW5Abm9ydGVsbmV0d29ya3MuY29tJmd0OywgQWRyaWFuIEZhcnJlbCA8QlI+Jmd0OyAmZ3Q7
ICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OywgY2NhbXBAb3BzLmlldGYub3JnIGJjYzogU3Vi
amVjdDogUkU6IExheWVyIDIgPEJSPiZndDsgJmd0OyBTd2l0Y2hpbmcgQ2FwcyBMU1BzIDxCUj4m
Z3Q7ICZndDsgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgPEJSPiZn
dDsgJmd0OyBEaW1pdHJpLCA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgVW5mb3J0dW5hdGVs
eSBJIGRpZG4ndCBncmFzcCBjb21wbGV0ZWx5IHdoYXQgeW91IGFyZSB0cnlpbmcgPEJSPiZndDsg
dG8gY29udmV5LiA8QlI+Jmd0OyAmZ3Q7IEJ1dCBvbmUgdGhpbmcgSSBrbm93IGZvciBzdXJlLCBh
bmQgdGhhdCBpcyZuYnNwOyAmcXVvdDtFdGhlcm5ldCBpcyA8QlI+Jmd0OyAmZ3Q7IENvbm5lY3Rp
b25sZXNzIChDTFMpJnF1b3Q7IChsaWtlIElQKSBhbmQgYXNzdW1lcyBzaGFyZWQgbWVkaXVtLCA8
QlI+Jmd0OyB3aGlsZSBHTVBMUyA8QlI+Jmd0OyAmZ3Q7IGlzIGNvbm5lY3Rpb24tb3JpZW50ZWQg
KENPKSBhbmQgZG9lc24ndCB3b3JrIGluIHNoYXJlZCBtZWRpdW0uIE9mZiA8QlI+Jmd0OyAmZ3Q7
IGNvdXJzZSB5b3UgY291bGQgYWx3YXlzIGNvbmZpZ3VyZSBhbmQgYnVpbGQgYW4gRXRoZXJuZXQg
PEJSPiZndDsgbmV0d29yayB0aGF0IDxCUj4mZ3Q7ICZndDsgbG9va3MgbGlrZSBpdCBpcyBDTyAo
YnkgY29uZmlndXJpbmcgYSBtYXggb2YgMiBwb3J0cyB3aXRoIHRoZSBzYW1lIDxCUj4mZ3Q7ICZn
dDsgVkxBTiBJRCBpbiBlYWNoIGJyaWRnZSksIGFuZCBieSBub3QgdXNpbmcgYW55IHNoYXJlZCA8
QlI+Jmd0OyBtZWRpdW0uIEJ1dCB0aGVuIDxCUj4mZ3Q7ICZndDsgd2hvIG5lZWRzIEdNUExTLCB3
aGVuIHlvdSBhbHJlYWR5IGhhdmUgdG8gY29uZmlndXJlIHlvdXIgbmV0d29yayBieSA8QlI+Jmd0
OyAmZ3Q7IG90aGVyIG1lYW5zPyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgLVNoYWhyYW0g
PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgRnJvbTogRGltaXRyaS5Q
YXBhZGltaXRyaW91QGFsY2F0ZWwuYmUgPEJSPiZndDsgJmd0OyBbPC9GT05UPjxGT05UIENPTE9S
PUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmU+
bWFpbHRvOkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlPC9BPjwvVT48L0ZPTlQ+PEZP
TlQgQ09MT1I9QkxBQ0s+XSBTZW50OiBUaHVyc2RheSwgPEJSPiZndDsgRmVicnVhcnkgMDMsIDxC
Uj4mZ3Q7ICZndDsgMjAwNSAzOjA3IFBNIFRvOiBNYWNrLUNyYW5lLCBULiBCZW5qYW1pbiBDYzog
PEJSPiZndDsgZHBhcGFkaW1pdHJpb3VAcHNnLmNvbTsgPEJSPiZndDsgJmd0OyBkaW1pdHJpLnBh
cGFkaW1pdHJpb3VAYWxjYXRlbC5iZTsgRGF2aWQgQWxsYW47IEFkcmlhbiA8QlI+Jmd0OyBGYXJy
ZWw7IFNoYWhyYW0gPEJSPiZndDsgJmd0OyBEYXZhcmk7IGNjYW1wQG9wcy5pZXRmLm9yZyBTdWJq
ZWN0OiBSRTogTGF5ZXIgMiBTd2l0Y2hpbmcgQ2FwcyBMU1BzIDxCUj4mZ3Q7ICZndDsgPEJSPiZn
dDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgYmVuLCA8QlI+Jmd0OyAmZ3Q7IDxC
Uj4mZ3Q7ICZndDsgdGhlIGRpc2N1c3Npb24gd2l0aCBkYXZlIGhhcyBiZWVuIHJlcHJvZHVjZWQg
aW4gYWNjZWxlcmF0ZWQgb24gdGhlIDxCUj4mZ3Q7ICZndDsgbWFpbGluZyBsaXN0IC0gZm9yIG1l
IGl0IGFwcGVhcnMgdGhhdCB0aGUgbW9yZSAmcXVvdDtwaGlsb3NvcGhpY2FsJnF1b3Q7IDxCUj4m
Z3Q7ICZndDsgY29uY2x1c2lvbiBjYW4gYmUgcG9zaXRpb25lZCBieSBhbnN3ZXJpbmcgdG8gdGhl
IGZvbGxvd2luZyBxdWVzdGlvbiA8QlI+Jmd0OyAmZ3Q7ICZxdW90O1dhcyBTT05FVC9TREggb3Ig
bGFtYmRhIHN3aXRjaGluZyBpbml0aWFsbHkgaW50ZW5kZWQgdG8gYmUgPEJSPiZndDsgY29udHJv
bGxlZCA8QlI+Jmd0OyAmZ3Q7IGJ5IEdNUExTID8mcXVvdDsgaWYgdGhlIHJlc3BvbnNlIGlzICZx
dW90O05vLCBidXQgbm90aGluZyBwcmV2ZW50cyB0byA8QlI+Jmd0OyBkbyBzbyZxdW90OyB0aGUg
PEJSPiZndDsgJmd0OyBuZXh0IHF1ZXN0aW9uIGlzIHdoYXQgZG9lcyBwcmV2ZW50IGZyb20gYXBw
bHlpbmcgR01QTFMgdG8gb3RoZXIgPEJSPiZndDsgJmd0OyB0ZWNobm9sb2dpZXMga25vd2luZyBh
IHN1YnN0YW50aWFsIGdhaW4gaXMgb2J0YWluZWQgZnJvbSBpdHMgPEJSPiZndDsgJmd0OyBhcHBs
aWNhdGlvbiAtIGluIGNlcnRhaW4gY29uZGl0aW9ucyAtIChzZWUgbW90aXZhdGlvbnMgYXMgPEJS
PiZndDsgcGFydCBvZiB0aGlzIDxCUj4mZ3Q7ICZndDsgaW50cm9kdWN0aW9uIGZvciBpbnN0YW5j
ZSkgPyBrZXkgaXNzdWUgYmVpbmcgd2hpY2ggYXJlIHRoZXNlIDxCUj4mZ3Q7ICZndDsgKHRlY2hu
aWNhbCkgY29uZGl0aW9ucyBhbmQgYXJlIHRoZXJlIGNvbmRpdGlvbnMgdGhhdCB3b3VsZCBwcmVj
bHVkZSA8QlI+Jmd0OyAmZ3Q7IHByb2dyZXNzaW5nIHRoaXMgZG9jdW1lbnQgLSB0aGUgcmVzcG9u
c2UgaXMgc2ltcGx5IHRoZSBuZWdhdGl2ZSAtIDxCUj4mZ3Q7ICZndDsgdGhlcmUgYXJlIG5vIHN1
Y2ggY29uZGl0aW9ucyBpbiB0aGUgcG9pbnQtdG8tcG9pbnQgLSBub24tYnJpZGdpbmcgLSA8QlI+
Jmd0OyAmZ3Q7IGNvbnRleHQgd2hlcmUgdGhpcyBkb2N1bWVudCBhcHBsaWVzLiA8QlI+Jmd0OyAm
Z3Q7IDxCUj4mZ3Q7ICZndDsgbm93LCBub3Qgc3VyZSB0aGVyZSBpcyBhIHRlY2huaWNhbCAmcXVv
dDtmaXJtJnF1b3Q7IGNvbmNsdXNpb24gYnV0IDxCUj4mZ3Q7IHRoZSBwb2ludCBvbiA8QlI+Jmd0
OyAmZ3Q7IHRoZSBldGhlcm5ldCBsYWJlbCBlbmNvZGluZyBhcHBlYXJzIGFzIGZvbGxvd3Mgc2lu
Y2Ugc28gZmFyIDxCUj4mZ3Q7IHRoZXJlIGlzIDxCUj4mZ3Q7ICZndDsgcG90ZW50aWFsIGludGVy
ZXN0IHRvIGtlZXAgdGhlIGxhYmVsIGZvciBldGhlcm5ldCBnZW5lcmljIDxCUj4mZ3Q7IGVub3Vn
aCBhbmQgPEJSPiZndDsgJmd0OyBkZWR1Y2UgaXRzIGludGVycHJldGF0aW9uIGZyb20gdHlwZSBv
ZiBsaW5rIG92ZXIgd2hpY2ggdGhlIGxhYmVsIGlzIDxCUj4mZ3Q7ICZndDsgdXNlZCBhbmQgaW50
ZXByZWV0IGl0cyB2YWx1ZSBhY2NvcmRpbmcgdG8gdGhlIDxCUj4mZ3Q7IHRyYWZmaWNfcGFyYW1l
dGVycyBhbmQgPEJSPiZndDsgJmd0OyBwcm9wb3NlIGFzc29jaWF0aW9ucyB0byBjb3ZlciBjYXNl
cyBzdWNoIGFzIGNhc2UgMiBvZiBBcHBlbmRpeCBBIG9mIDxCUj4mZ3Q7ICZndDsgJmx0O2RyYWZ0
LXB3ZTMtZXRoZXJuZXQtZW5jYXAtMDgudHh0Jmd0OyBtZWNoYW5pc21zIHRoYXQgaXMgYWxzbyA8
QlI+Jmd0OyBhcHBsaWNhYmxlIDxCUj4mZ3Q7ICZndDsgdG8gb3RoZXIgdHVubmVsaW5nIHRlY2hu
b2xvZ3kgc2luY2UgdGhpcyBtZWNoYW5pc20gaXMgb3J0aG9nb25hbCB0byA8QlI+Jmd0OyAmZ3Q7
IHRoZSB1c2Ugb2YgUFcncyBpZiByZXF1aXJlZCAoZXhhbXBsZSBiZWluZyBFdGhlcm5ldCBvdmVy
IDxCUj4mZ3Q7IFNESC9PVEgsIGZvciA8QlI+Jmd0OyAmZ3Q7IGluc3RhbmNlKTsgaG93ZXZlciwg
aWYgdGhlc2UgYXJlIHRoZSBvbmx5IGFzc29jaWF0aW9ucyB3ZSA8QlI+Jmd0OyBzZWUgcmVsZXZh
bnQgPEJSPiZndDsgJmd0OyBhcyBwYXJ0IG9mIHRoaXMgZG9jdW1lbnQgdGhlbiB3ZSB3b3VsZCBm
YWxsIGJhY2sgb24gdGhlIGV4aXN0aW5nIDxCUj4mZ3Q7ICZndDsgZW5jb2Rpbmcgd2l0aCBwb3Rl
bnRpYWwgZW5oYW5jZW1lbnQgaWYgc28gcmVxdWlyZWQgLSA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7
ICZndDsgdG8gY29tZSB0byB0aGUgcG9pbnQgb2YgdGhlIGFydGljdWxhdGlvbiB0aGUgLSBnZW5l
cmljIC0gcmVzcG9uc2UgPEJSPiZndDsgJmd0OyBob2xkcyBpbiBvbmUgbGluZTogaXQgYXJ0aWN1
bGF0ZXMgR01QTFMgc2lnbmFsaW5nIGZvciBMMlNDIExTUHMgPEJSPiZndDsgJmd0OyAobm90ZTog
dGhlIGxhdHRlciBoYXMgYmVlbiBpbnRyb2R1Y2VkIGluIFJGQyAzOTQ1LCBSRkMgMzQ3MSwgUkZD
IDxCUj4mZ3Q7ICZndDsgMzQ3MykgLSB0aGUgbW90aXZhdGlvbnMgYXJlIGRldGFpbGVkIGFzIHBh
cnQgb2YgdGhlIGludHJvZHVjdGlvbiBvZiA8QlI+Jmd0OyAmZ3Q7IHRoaXMgZG9jdW1lbnQgLSBp
IGNhbiBub3QgY29tbWVudCBtb3JlIGZyb20geW91ciBpbml0aWFsIHN0YXRlbWVudCA8QlI+Jmd0
OyAmZ3Q7IHNpbmNlIG5vdCBkZXRhaWxlZCBlbm91Z2ggZm9yIG1lIHRvIGJlIG1vcmUgc3BlY2lm
aWMgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IHRoZSByZXNwb25zZSB0byB0aGUgbGFzdCBx
dWVzdGlvbiBpcyByZWxhdGl2ZWx5IHNpbXBsZSA8QlI+Jmd0OyBzaW5jZSB0aGUgYWJvdmUgPEJS
PiZndDsgJmd0OyBtZW50aW9uZWQgZG8gbm90IGluY2x1ZGUgYW55IHNwZWNpZmljcyBjb25jZXJu
aW5nIEFUTSBvciBGUiAtIHRoaXMgPEJSPiZndDsgJmd0OyBkb2N1bWVudCBpbnRlbmRzIHRvIGNs
b3NlIHRoaXMgZ2FwIGJ5IGRlZmluaW5nIHNwZWNpZmljIDxCUj4mZ3Q7ICZndDsgVHJhZmZpY19Q
YXJhbWV0ZXJzIGZvciB0aGVzZSB0ZWNobm9sb2dpZXMgLSBpcyB0aGVyZSBhbiA8QlI+Jmd0OyBp
bnRlcmVzdCBmb3IgPEJSPiZndDsgJmd0OyBkb2luZyBzbzogcmVzcG9uc2UgaXMgeWVzIG90aGVy
d2lzZSB0aGUgZG9jdW1lbnQgd291bGQgbm90IGhhdmUgPEJSPiZndDsgJmd0OyBpbmNsdWRlZCB0
aGUgY29yci4gZGV0YWlscyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgdm9pbGEsIHRoYW5r
cywgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IC0gZGltaXRyaS4gPEJSPiZndDsgJmd0OyA8
QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IDxC
Uj4mZ3Q7ICZndDsgJnF1b3Q7TWFjay1DcmFuZSwgVC4gQmVuamFtaW4mcXVvdDsgJmx0O0Jlbi5N
YWNrLUNyYW5lQHRlbGxhYnMuY29tJmd0OyBTZW50IGJ5OiA8QlI+Jmd0OyAmZ3Q7IG93bmVyLWNj
YW1wQG9wcy5pZXRmLm9yZyAwMi8wMy8yMDA1IDEyOjE2IENTVCA8QlI+Jmd0OyAmZ3Q7IDxCUj4m
Z3Q7ICZndDsgVG86ICZsdDtkcGFwYWRpbWl0cmlvdUBwc2cuY29tJmd0OywgRGltaXRyaSA8QlI+
Jmd0OyAmZ3Q7IFBBUEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMLCAmcXVvdDtEYXZpZCBB
bGxhbiZxdW90OyA8QlI+Jmd0OyAmZ3Q7ICZsdDtkYWxsYW5Abm9ydGVsbmV0d29ya3MuY29tJmd0
OyBjYzogJnF1b3Q7QWRyaWFuIEZhcnJlbCZxdW90OyA8QlI+Jmd0OyAmbHQ7YWRyaWFuQG9sZGRv
Zy5jby51ayZndDssIDxCUj4mZ3Q7ICZndDsgJnF1b3Q7U2hhaHJhbSBEYXZhcmkmcXVvdDsgJmx0
O1NoYWhyYW1fRGF2YXJpQHBtYy1zaWVycmEuY29tJmd0OywgPEJSPiZndDsgJmx0O2NjYW1wQG9w
cy5pZXRmLm9yZyZndDsgPEJSPiZndDsgJmd0OyBiY2M6IFN1YmplY3Q6IDxCUj4mZ3Q7ICZndDsg
UkU6IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQcyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZn
dDsgPEJSPiZndDsgJmd0OyBEaW1pdHJpLCA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgQ2Fu
IHRoZSBvZmYtbGluZSBkaXNjdXNzaW9uIGJlIHN1bW1hcml6ZWQgZm9yIHRoZSBiZW5lZml0IDxC
Uj4mZ3Q7IG9mIHRob3NlIG9uJm5ic3A7IDxCUj4mZ3Q7ICZndDsgdGhlIGxpc3Qgd2hvIGRpZCBu
b3QgcGFydGljaXBhdGU/Jm5ic3A7IEZvciBtZSwgdGhlIGRyYWZ0IChhbmQgPEJSPiZndDsgdGhl
IGN1cnJlbnQgPEJSPiZndDsgJmd0OyBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0KSBoYXZlIG5vdCBj
bGVhcmx5IGFydGljdWxhdGVkIHRoZSA8QlI+Jmd0OyBwcm9ibGVtIGJlaW5nIDxCUj4mZ3Q7ICZn
dDsgYWRkcmVzc2VkLiZuYnNwOyBJZiBhIHN1bW1hcnkgb2YgdGhlIGNvbmNsdXNpb25zIG9mIHRo
ZSBvZmYtbGluZSA8QlI+Jmd0OyBkaXNjdXNzaW9uIDxCUj4mZ3Q7ICZndDsgd2lsbCBkbyB0aGlz
LCBpdCB3b3VsZCBiZSB1c2VmdWwuIDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBJIGFtIGFs
c28gaW50ZXJlc3RlZCB0byBrbm93IHdoYXQgaXMgbGFja2luZyBpbiB0aGUgY3VycmVudCA8QlI+
Jmd0OyBHTVBMUyBSRkNzIDxCUj4mZ3Q7ICZndDsgd2l0aCByZXNwZWN0IHRvIEFUTSBhbmQgRnJh
bWUgUmVsYXkgc3VwcG9ydCB0aGF0IG5lY2Vzc2l0YXRlcyA8QlI+Jmd0OyAmZ3Q7IGluY2x1ZGlu
ZyB0aGVtIGluIHRoaXMgbmV3IGRyYWZ0IChwcmVzdW1hYmx5IHRoaXMgaXMgYSBwYXJ0IG9mIHRo
ZSA8QlI+Jmd0OyAmZ3Q7IHByb2JsZW0gdG8gYmUgc29sdmVkKS4gPEJSPiZndDsgJmd0OyA8QlI+
Jmd0OyAmZ3Q7IFJlZ2FyZHMsIEJlbiA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgPEJSPiZn
dDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogb3duZXItY2NhbXBA
b3BzLmlldGYub3JnIDxCUj4mZ3Q7ICZndDsmZ3Q7IFs8L0ZPTlQ+PEZPTlQgQ09MT1I9QkxVRT48
VT48QSBIUkVGPW1haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc+bWFpbHRvOm93bmVyLWNj
YW1wQG9wcy5pZXRmLm9yZzwvQT48L1U+PC9GT05UPjxGT05UIENPTE9SPUJMQUNLPl0gT24gPEJS
PiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IEJlaGFsZiA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZn
dDsmZ3Q7IE9mIGRpbWl0cmkgcGFwYWRpbWl0cmlvdSBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAy
NywgMjAwNSA2OjM1IFBNIDxCUj4mZ3Q7ICZndDsmZ3Q7IFRvOiBEYXZpZCBBbGxhbiBDYzogJ0Fk
cmlhbiBGYXJyZWwnOyAnU2hhaHJhbSBEYXZhcmknOyA8QlI+Jmd0OyAmZ3Q7Jmd0OyBjY2FtcEBv
cHMuaWV0Zi5vcmcgU3ViamVjdDogUmU6IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQcyA8QlI+
Jmd0OyAmZ3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyBkYXZlIC0gdGhlcmUgd2FzIGEgbGVuZ3Ro
eSBvZmYtbGluZSBkaXNjdXNzaW9uIHN1Z2dlc3RlZCBieSB0aGUgPEJSPiZndDsgJmd0OyZndDsg
Y2hhaXJzIGludGVuZGVkIHRvIGV4cGxhaW4geW91IHRoZSBzY29wZSBvZiB0aGUgZHJhZnQgYW5k
IGl0cyA8QlI+Jmd0OyAmZ3Q7Jmd0OyByZWxhdGlvc2hpcCA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7
ICZndDsgd2l0aCA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7IHRoZSBldGhlcm5ldCBk
YXRhIHBsYW5lIChhZnRlciB0aGUgcXVlc3Rpb24geW91IHJhaXNlZCA8QlI+Jmd0OyBkdXJpbmcg
dGhlIGYyZiA8QlI+Jmd0OyAmZ3Q7Jmd0OyBtZWV0aW5nKSAtIHRoaXMgaGFzIGJlZW4gZG9uZSBh
bmQgd2UgaGF2ZSBleHBsYWluZWQgKHZpYSBhIGxlbmd0aHkgPEJSPiZndDsgJmd0OyZndDsgZXhj
aGFuZ2Ugb2YgZS1tYWlscykgdGhhdCB0aGlzIGRvY3VtZW50IGFuZCBzbyB0aGUgdXNlIG9mIGdt
cGxzIHRvIDxCUj4mZ3Q7ICZndDsmZ3Q7IGNvbnRyb2wgZXRoZXJuZXQgZnJhbWUgZmxvd3MsIGlz
IG5vdCB0YXJnZXRpbmcgY29udHJvbCBvZiBicmlkZ2VkIDxCUj4mZ3Q7ICZndDsmZ3Q7IGV0aGVy
bmV0IGVudmlyb25tZW50cyAtIGlmIHRoaXMgaXMgbm90IGNsZWFyIGZyb20gdGhlIGN1cnJlbnQg
PEJSPiZndDsgJmd0OyZndDsgZG9jdW1lbnQgaW50cm9kdWN0aW9uIHdlIHdvdWxkIGhhdmUgYWxz
byB0byB3b3JrIG9uIHRoaXMgPEJSPiZndDsgcGFydCBvZiB0aGUgPEJSPiZndDsgJmd0OyZndDsg
ZG9jdW1lbnQgLSB0aGVyZWZvcmUsIHRoZSBiZWxvdyByZWZlcmVuY2UgdG8gTVNUUCBpcyBub3Qg
aW4gdGhlIDxCUj4mZ3Q7ICZndDsmZ3Q7IGN1cnJlbnQgc2NvcGU7IG9uIHRoZSBvdGhlciBzaWRl
LCB0aGUgdXNlIG9mIHRoZSB0ZXJtICZxdW90O1ZMQU4gbGFiZWwmcXVvdDsgPEJSPiZndDsgJmd0
OyZndDsgaGFzIGNyZWF0ZWQgc29tZSBjb25mdXNpb247IHRoZXJlZm9yZSwgaW4gYSBuZXh0IHJl
bGVhc2UgaSB3aWxsIDxCUj4mZ3Q7ICZndDsmZ3Q7IHNpbXBseSByZWZlciB0byBhIDxCUj4mZ3Q7
ICZndDsgPEJSPiZndDsgJmd0OyAmcXVvdDtsYWJlbCZxdW90OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4m
Z3Q7ICZndDsmZ3Q7IG9mIDMyIGJpdHMgKHVuc3RydWN0dXJlZCkgYmVjYXVzZSB0aGUgaW50ZW50
aW9uIHdhcyAoYW5kIDxCUj4mZ3Q7IHN0aWxsIGlzKSB0byA8QlI+Jmd0OyAmZ3Q7Jmd0OyBmaW5k
IGFuIGVhc3kgd2F5IHRvIG1hcCB0aGUgY29udHJvbCBvZiB0aGUgZXRoZXJuZXQgZnJhbWUgZmxv
d3Mgb24gPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IGVhY2ggPEJSPiZndDsgJmd0OyA8QlI+
Jmd0OyAmZ3Q7Jmd0OyBkZXZpY2UgdGhleSB0cmF2ZXJzZXMgd2l0aG91dCBtYWtpbmcgYW55IGFz
c3VtcHRpb24gb24gaG93IDxCUj4mZ3Q7IHRoaXMgZmxvdyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7
ICZndDsgaXMgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyBwcm9jZXNzZWQgaW5zaWRl
IGVhY2ggbm9kZSBhdCB0aGUgZGF0YSBwbGFuZSBsZXZlbCAobm90ZTogb24gbGFiZWwgPEJSPiZn
dDsgJmd0OyZndDsgdmFsdWVzLCBSRkMgMzk0NiB0b29rIGFuIGVxdWl2YWxlbnQgYXBwcm9hY2gg
LSBmb3IgY2lyY3VpdHMgLSB3aGVyZSA8QlI+Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyBzb25ldC9zZGgg
bXVsdGlwbGV4aW5nIHN0cnVjdHVyZXMgaGF2ZSBiZWVuIHVzZWQgdG8gY3JlYXRlIHVuaXF1ZSA8
QlI+Jmd0OyAmZ3Q7Jmd0OyBtdWx0aXBsZXggZW50cnkgbmFtZXMgaS5lLiBsYWJlbHMgLSB0aGlz
IGNvbmNlcHQgaXMgaGVyZSBhcHBsaWVkIDxCUj4mZ3Q7ICZndDsmZ3Q7IGZvciAmcXVvdDt2aXJ0
dWFsJnF1b3Q7IGNpcmN1aXRzKSwgc28sIGlmIHRoZSB3b3JraW5nIGdyb3VwIGlzIHdpbGxpbmcg
dG8gPEJSPiZndDsgJmd0OyZndDsgZW50ZXIgaW50byA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZn
dDsgYSA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7IGRhdGEgcGxhbmUgb3JpZW50ZWQg
ZGlzY3Vzc2lvbiB0byBjbGFyaWZ5IHRoZSBiZWhhdmlvdXIocykgPEJSPiZndDsgb250byB3aGlj
aCA8QlI+Jmd0OyAmZ3Q7Jmd0OyB0aGUgcHJlc2VudCBhcHByb2FjaCB3b3VsZCBiZSBwb3RlbnRp
YWxseSBhcHBsaWNhYmxlIHRoaXMgaXMgZmluZSA8QlI+Jmd0OyAmZ3Q7Jmd0OyB3aXRoIG1lIGFz
IGxvbmcgYXMgd2UgYXJlIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIGluaXRpYWwgPEJSPiZndDsg
bW90aXZhdGlvbnMgPEJSPiZndDsgJmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsgdGhhbmtzLCAt
IGRpbWl0cmkuIDxCUj4mZ3Q7ICZndDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7IERhdmlkIEFsbGFu
IHdyb3RlOiA8QlI+Jmd0OyAmZ3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgSGkgQWRyaWFu
OiA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsmZ3Q7IFlvdXIgc3VnZ2Vz
dGlvbiBpcyBpbiBhIHdheSByZWFzb25hYmxlIGJ1dCB3aXRoIHRoZSBjYXZlYXQgdGhhdCBpbiA8
QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgSUVFRSA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZn
dDsmZ3Q7Jmd0OyB0ZXJtcywgYSBicmlkZ2luZyB0b3BvbG9neSBpcyBjdXJyZW50bHkgYWxsIFZM
QU5zICg4MDIuMVEgc2luZ2xlIDxCUj4mZ3Q7ICZndDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7IHNw
YW5uaW5nIDxCUj4mZ3Q7ICZndDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyB0cmVlKSBvciBw
YXJ0aXRpb25lZCBpbnRvIHNwZWNpZmljIHJhbmdlcyAoSSBiZWxpZXZlIDY0IGluIDgwMi4xcyA8
QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsg
YWx0aG91Z2ggSSA8QlI+Jmd0OyAmZ3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgZG8gbm90
IGNsYWltIHRvIGJlIGFuIGV4cGVydCkuIDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyA8QlI+Jmd0OyAm
Z3Q7Jmd0OyZndDsgSWYgdGhlIFBFcyB3ZXJlIHRvIGltcGxlbWVudCBhIGJyaWRnZSBmdW5jdGlv
biBhbmQgd2Ugd2VyZSB1c2luZyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgR01QTFMgPEJS
PiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyB0byA8QlI+Jmd0OyAmZ3Q7Jmd0OyA8QlI+Jmd0
OyAmZ3Q7Jmd0OyZndDsgaW50ZXJjb25uZWN0IHRoZW0sIHRoZW4gdGhlIGNvbnRyb2wgcGxhbmUg
c2hvdWxkIGJlIGlkZW50aWZ5aW5nIDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBlaXRoZXIg
PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyBhbGwgPEJSPiZndDsgJmd0OyZndDsgPEJS
PiZndDsgJmd0OyZndDsmZ3Q7IFZMQU5zIChzaW5nbGUgc3Bhbm5pbmcgdHJlZSwgd2hpY2ggSSBi
ZWxlaXZlIHRoZSBkcmFmdCBjb3ZlcnMgYnkgPEJSPiZndDsgJmd0OyZndDsgPEJSPiZndDsgJmd0
OyZndDsgcmVmZXJyaW5nIDxCUj4mZ3Q7ICZndDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBz
aW1wbHkgdG8gRXRoZXJuZXQgcG9ydCkgb3IgYSBWTEFOIHJhbmdlIHRvIGJlIGFzc29jaWF0ZWQg
d2l0aCB0aGUgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IExTUCA8QlI+Jmd0OyAmZ3Q7IDxC
Uj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBjb25zaXN0ZW50IHdpdGggODAyLjFzIGlmIGl0IGlzIHRvIG9w
ZXJhdGUgdG8gaW50ZXJjb25uZWN0IGJyaWRnZXMgPEJSPiZndDsgJmd0OyZndDsgPEJSPiZndDsg
Jmd0OyZndDsgZGVmaW5lZCA8QlI+Jmd0OyAmZ3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsg
YnkgdGhlIElFRUUuLi4gPEJSPiZndDsgJmd0OyZndDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0
OyBJIHN1c3BlY3QgYXNzdW1pbmcgYW55IG90aGVyIGJlaGF2aW9yIChlLmcuIExTUCBmb3Igc2lu
Z2xlIFZMQU4gPEJSPiZndDsgJmd0OyZndDsmZ3Q7IHRhZykgPEJSPiZndDsgJmd0OyZndDsgPEJS
PiZndDsgJmd0OyZndDsgd291bGQgPEJSPiZndDsgJmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsm
Z3Q7IGdvIG91dHNpZGUgdGhlIGJvdW5kYXJ5IG9mIHdoYXQgaXMgY3VycmVudGx5IGRlZmluZWQu
Li5zbyA8QlI+Jmd0OyBhbGlnbm1lbnQgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IHdpdGgg
PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgODAyLjFzIElNTyB3b3VsZCBiZSBh
IG1pbmltdW0gcmVxdWlyZW1lbnQgaWYgd2UgYXJlIHRvIGNvbnNpZGVyIDxCUj4mZ3Q7ICZndDsg
PEJSPiZndDsgJmd0OyBjYXJyeWluZyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0
OyBWTEFOIGluZm9ybWF0aW9uIGluIEdNUExTIHNpZ25hbGxpbmcuLi4uIDxCUj4mZ3Q7ICZndDsm
Z3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgY2hlZXJzIERhdmUgPEJSPiZndDsgJmd0OyZn
dDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBZb3Ugd3JvdGUuLi4uIDxCUj4mZ3Q7ICZndDsm
Z3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBI
aSwgPEJSPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRo
ZSBhdXRob3JzIG9mIHRoZSBkcmFmdCBtaWdodCBsaWtlIHRvIGNsYXJpZnkgZm9yIHRoZSBsaXN0
IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZXhhY3RseSB3aGF0IGRhdGEgcGxhbmUgb3BlcmF0
aW9ucyB0aGV5IGFyZSBzdWdnZXN0aW5nLiBUbyBtZSA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7
IGl0IHNlZW1zIHBvc3NpYmxlIHRoYXQgdGhlIGRyYWZ0IGlzIHByb3Bvc2luZyBWTEFOIElEIDxC
Uj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgKnN3YXBwaW5nKi4gQnV0IGFuIGFsdGVybmF0aXZlIGlz
IHRoYXQgdGhlIFZMQU4gSUQgaXMgdXNlZCBhcyBhIDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg
bGFiZWwsIGJ1dCB0aGF0IHRoZSBzYW1lIGxhYmVsIGlzIHVzZWQgZm9yIHRoZSBmdWxsIGxlbmd0
aCBvZiA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBMU1AuIDxCUj4mZ3Q7ICZndDsmZ3Q7
Jmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBBZHJpYW4gPEJSPiZndDsgJmd0OyZn
dDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgPEJSPiZn
dDsgJmd0OyZndDsmZ3Q7IC4gPEJSPiZndDsgJmd0OyZndDsmZ3Q7IDxCUj4mZ3Q7ICZndDsgPEJS
PiZndDsgJmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT0gVGhlIDxCUj4mZ3Q7ICZndDsgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu
IHRoaXMgbWVzc2FnZSBtYXkgYmUgcHJpdmlsZWdlZCBhbmQgPEJSPiZndDsgJmd0OyBjb25maWRl
bnRpYWwgYW5kIHByb3RlY3RlZCBmcm9tIGRpc2Nsb3N1cmUuIElmIHRoZSByZWFkZXIgb2YgdGhp
cyA8QlI+Jmd0OyAmZ3Q7IG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9y
IGFuIGVtcGxveWVlIG9yIGFnZW50IDxCUj4mZ3Q7ICZndDsgcmVzcG9uc2libGUgZm9yIGRlbGl2
ZXJpbmcgdGhpcyBtZXNzYWdlIHRvIHRoZSBpbnRlbmRlZCA8QlI+Jmd0OyByZWNpcGllbnQsIHlv
dSA8QlI+Jmd0OyAmZ3Q7IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgcmVwcm9kdWN0aW9u
LCBkaXNzZW1pbmF0aW9uIG9yIDxCUj4mZ3Q7ICZndDsgZGlzdHJpYnV0aW9uIG9mIHRoaXMgY29t
bXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiA8QlI+Jmd0OyBJZiB5b3UgaGF2ZSA8
QlI+Jmd0OyAmZ3Q7IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNl
IG5vdGlmeSB1cyA8QlI+Jmd0OyBpbW1lZGlhdGVseSBieSA8QlI+Jmd0OyAmZ3Q7IHJlcGx5aW5n
IHRvIHRoZSBtZXNzYWdlIGFuZCBkZWxldGluZyBpdCBmcm9tIHlvdXIgY29tcHV0ZXIuIDxCUj4m
Z3Q7IFRoYW5rIHlvdS4gPEJSPiZndDsgJmd0OyBUZWxsYWJzID09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSA8QlI+Jmd0OyAmZ3Q7IDxC
Uj4mZ3Q7ICZndDsgPEJSPiZndDsgPEJSPiZndDsgPC9GT05UPjwvUD4=



Envelope-to: [e-mail]
Delivery-date: Sat, 05 Feb 2005 15:11:15 +0000
To: Shahram Davari <[e-mail]>
Cc: "'[e-mail]'"	 <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, [e-mail], David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
MIME-Version: 1.0
Date: Sat, 5 Feb 2005 16:08:33 +0100
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

sharam,

first thanks for translating a physical interface as PHY+MAC (not port
please read the mail here below) it really helps understanding each other
:-( (knowing that PHY is an acronym for PHYsical)

now the basic issue, GMPLS allows setting up L2SC LSPs using Ethernet as
LSP encoding type and L2SC as switching type i.e. through - ditto RFC 3945
- "Interfaces that recognize frame/cell boundaries and can switch data
based on the content of the frame/cell header." (examples provided after
this sentence are simply illustrative) where from this definition do you
see a restriction from having an LSP processing the set of incoming frames
processing the VLAN_ID (which is afaik is part of the frame header) as a
way to seggregate flows crossing a port - which thus appear as a refinment
of the port mode

therefore, why applying this definition (coming from an RFC - the GMPLS
architecture - of the CCAMP WG) as part of other documents of the same WG
would not be not possible ?

concerning the question "do we need to detail the exact data plane
processing as part of this document to obtain an interoperable definition",
the response is complex because

o) if both vendor 1 and vendor 2 claims support for L2 LSPs - for the
backward compatible case i already responded to you - having three devices
in a row with the following sequence vendor_1 - vendor_2 - vendor_1, you
can not preclude the intermediate device to not do bridging/ learning,
(don't forget there is no insertion of any new field or any modification in
the frame header) even if it does not provide any functionality in the
point- to-point context we are discussing here, while this operation is
opaque to the operation of its neighboring devices as vendor_1 that would
apply link local semantic and vendor_2 a network wide one;

o) on the other side assuming the edge devices vendor is mandating bridging
at the data plane this is also opaque to the way (a sequence of)
intermediate devices will perform local frame forwarding, lastly such
device (vendor_2) taking the - so i do not see what i should deliver more
in terms of data plane processing as part of this document as
interoperability is ensured;

also the question on using bridging (here we speak about local frame
processing) is subtle in this context because a device claiming support of
L2 LSP may still apply it but (in the point-to- point context we are
discussing here) it does not play a role because the path for these frames
are known during the LSP establishment; therefore there is no mandatory
application of MAC learning/ bridging but note that this document does not
refer to these nodes as .1d bridges to avoid any confusion (as similarly in
the PW WG one does not refer to a PE as a bridge);

so what's left in fact very little, probably that as it is the already case
in the port mode, accept that the establishment of the LSP itself
determines the external behaviour of the forwarding operations performed by
the node (however, note that as it is the case in any other standard there
is no need to specify the exact implementation of the forwarding/switching/
connection function) and ensure a "per-port" based VLAN interpretation (but
i don't see today what would preclude implementing this)

---

Dimitri,

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

-Shahram

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of [e-mail]
> Sent: Friday, February 04, 2005 2:26 PM
> To: Mack-Crane, T. Benjamin
> Cc: [e-mail]; Shahram Davari;
> [e-mail]; David Allan; Adrian Farrel; [e-mail]
> Subject: RE: Layer 2 Switching Caps LSPs
>
>
>
> ben,
>
> > As I think Sharam has noted, 1) is a physical interface.
>
> i don't understand what you mean by 1) (= Ethernet 802.3) is
> a "physical
> interface" please take a look at IEEE 802.3 to see that it defines the
>
> 1.4.167 Media Access Control (MAC): The data link sublayer that is
> responsible for transferring data to and from the Physical Layer.
>
> - as also depicted in Figure 2.1 and 2.2, where you will see
> that PHY is
> just below the MAC sub-layer but the latter is not the "PHY"
> - Fig 2.1 is
> rather explicit
>
>
>






Envelope-to: [e-mail]
Delivery-date: Sat, 05 Feb 2005 12:16:38 +0000
Message-ID: <03a701c50b7c$457d0a80$70cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: IPR Disclosure wrt draft-ietf-ccamp-loose-path-reopt
Date: Sat, 5 Feb 2005 12:14:26 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Please be aware of the IPR disclosure lodged with the Secretariat with
respect to this draft.

Find it at
http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path-reopt-00.txt

It looks like standard terms apply.

Adrian
----- Original Message ----- 
From: "IETF Secretariat" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Wednesday, February 02, 2005 7:01 PM
Subject: Posting of IPR Disclosure


> Dear Jean-Philippe Vasseur, Yuichi Ikejiri, Raymond Zhang:
>
> An IPR disclosure that pertains to your Internet-Draft entitled
"Reoptimization
> of MPLS Traffic Engineering loosely routed LSP"
> (draft-ietf-ccamp-loose-path-reopt) was submitted to the IETF
Secretariat on
> 2005-01-28 and has been posted on the "IETF Page of Intellectual
Property Rights
> Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The
title of
> the IPR disclosure is "Nortel Networks Statement on IPR claimed in
> draft-ietf-ccamp-loose-path-reopt-00.txt."
>
> The IETF Secretariat
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 23:42:41 +0000
To: Shahram Davari <[e-mail]>
Cc: "'[e-mail]'"	 <[e-mail]>, "'[e-mail]'" <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
MIME-Version: 1.0
Date: Sat, 5 Feb 2005 00:42:06 +0100
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

sharam,

> I think we have a disconnect here. Could you please explain
> how you could
> reuse the VLAN IDs in a single switch for different LSPs?
>
> -> the port scopes their usage, incoming LSP_1 is associated to frames
> flowing with VLAN_1 through port_8 is distinct from LSP_2
> associated to
> frames flowing with VLAN_1 through port_2 (on the same node)
>

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

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





Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 23:23:51 +0000
To: Shahram Davari <[e-mail]>
Cc: "'[e-mail]'"	 <[e-mail]>, David Allan <[e-mail]>, "'[e-mail]'" <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
MIME-Version: 1.0
Date: Sat, 5 Feb 2005 00:22:17 +0100
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

sharam,

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

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

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

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

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

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

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

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

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

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

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






Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 20:22:28 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>
Cc: [e-mail], David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 12:22:02 -0800 
MIME-Version: 1.0
Content-Type: text/plain

Dimitri,

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

-Shahram

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of [e-mail]
> Sent: Friday, February 04, 2005 2:26 PM
> To: Mack-Crane, T. Benjamin
> Cc: [e-mail]; Shahram Davari;
> [e-mail]; David Allan; Adrian Farrel; [e-mail]
> Subject: RE: Layer 2 Switching Caps LSPs
> 
> 
> 
> ben,
> 
> > As I think Sharam has noted, 1) is a physical interface.
> 
> i don't understand what you mean by 1) (= Ethernet 802.3) is 
> a "physical
> interface" please take a look at IEEE 802.3 to see that it defines the
> 
> 1.4.167 Media Access Control (MAC): The data link sublayer that is
> responsible for transferring data to and from the Physical Layer.
> 
> - as also depicted in Figure 2.1 and 2.2, where you will see 
> that PHY is
> just below the MAC sub-layer but the latter is not the "PHY" 
> - Fig 2.1 is
> rather explicit
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 19:52:26 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: David Allan <[e-mail]>, "'[e-mail]'" <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 11:51:33 -0800 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50AF2.ED35FC4E"

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_01C50AF2.ED35FC4E
Content-Type: text/plain;
	charset="iso-8859-1"

Dimitri,

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



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

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

To answer your PWE3 question: 

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

 

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

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

-Shahram   

Shahram Davari <[e-mail]>
Sent by: [e-mail]
02/04/2005 10:55 PST

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




Dimitri,

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

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



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

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

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

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


Dimitri: 
<snipped> 
 (but 
> also keep in mind that there are two levels of VLANs defined today so 
> further refinment is still possible) and with 16 ports you would have 
> 64k LSPs not that bad for an unscalable solution ;-) 

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

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

rgds 
Dave 

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


------_=_NextPart_001_01C50AF2.ED35FC4E
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.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=351121319-04022005><FONT face=Arial color=#0000ff 
size=2>Dimitri,</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> 
  [e-mail] 
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, February 04, 
  2005 2:10 PM<BR><B>To:</B> Shahram Davari<BR><B>Cc:</B> 
  '[e-mail]'; David Allan; '[e-mail]'; 
  Mack-Crane, T. Benjamin; David Allan; Adrian Farrel; 
  [e-mail]<BR><B>Subject:</B> RE: Layer 2 Switching Caps 
  LSPs<BR><BR></FONT></DIV>
  <P>sharam, i have explained in a previous thread taking translation operation 
  allowed on VLAN IDs (see PWE3 encaps document for inst.) and here assuming 
  that the inverse translation is performed at the egress you are retrieving the 
  value when leaving the network<SPAN class=351121319-04022005><FONT face=Arial 
  color=#0000ff size=2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=351121319-04022005><FONT face=Arial color=#0000ff size=2>Let me 
  make it clear: IEEE does not permit translation of the VLAN ID&nbsp;in 
  the&nbsp;Core-provider bridge (S-VLAN aware bridge) as well as Legacy bridges 
  (C-VLAN aware bridge).</FONT></SPAN></P>
  <P><SPAN class=351121319-04022005><FONT face=Arial color=#0000ff size=2>To 
  answer your PWE3 question: </FONT></SPAN></P>
  <P><SPAN class=351121319-04022005><FONT face=Arial color=#0000ff size=2>A PE 
  that supports ETH PW, has 2 disjoint and distinct components: An IEEE 802.1D 
  Ethernet Bridging component followed by an PW IWF. The 802.1D performs the 
  switching based on VLAN ID (and possibly MAC address), followed by a PW IWF 
  that performs ETH PW processing. The first component (802.1D bridge) is not 
  allowed to change the VLAN ID, because IEEE standards does not permit that. 
  The VLAN ID May only be changed in the PW IWF, since it is outside the scope 
  of&nbsp;IEEE.</FONT></SPAN></P>
  <P><SPAN class=351121319-04022005><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=351121319-04022005>&nbsp;</SPAN>concerning the second point, 
  the issue of merging has also to be refined from what you say as you can 
  maintain two different LSPs on a link that share a common label (in the frame 
  mode) - as briefly explained in section &nbsp;2.4.3 of RFC 3209 - this said 
  the above operation is also not excluded if one desires maintaining separate 
  labels&nbsp;<SPAN class=351121319-04022005><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></P>
  <P><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=351121319-04022005>What?&nbsp;SE is for Multicast application !!!!!!!! 
  not what we are talking about.</SPAN></FONT></FONT></FONT></P>
  <P><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
  class=351121319-04022005>-Shahram&nbsp;</SPAN><SPAN 
  class=351121319-04022005>&nbsp;</SPAN><SPAN 
  class=351121319-04022005>&nbsp;</SPAN></FONT></FONT></FONT><BR><BR><FONT 
  size=2><B>Shahram Davari 
  &lt;[e-mail]&gt;</B></FONT><BR><FONT size=2>Sent by: 
  [e-mail]</FONT><BR><FONT size=2>02/04/2005 10:55 
  PST</FONT><BR><BR><FONT size=2>To:</FONT> <FONT size=2>Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan 
  &lt;[e-mail]&gt;</FONT><BR><FONT size=2>cc:</FONT> <FONT 
  size=2>"'[e-mail]'" &lt;[e-mail]&gt;, "Mack-Crane, 
  T. Benjamin" &lt;[e-mail]&gt;, David Allan 
  &lt;[e-mail]&gt;, Adrian Farrel &lt;[e-mail]&gt;, 
  [e-mail]</FONT><BR><FONT size=2>bcc:</FONT> <BR><FONT 
  size=2>Subject:</FONT> <FONT size=2>RE: Layer 2 Switching Caps 
  LSPs</FONT><BR><BR><BR></P>
  <P>Dimitri,<BR><BR>Ho do you achieve the 64K? Are you planning to reuse the 
  VLAN-ID in different ports for different LSPs?<BR>If so your proposal is 
  broken, because VLAN IDs don't have local significance, rather they have 
  network-wide <BR>significance and meaning. So if&nbsp; 2 of these LSPs (having 
  the same VLAN ID) pass through the same link, they would be 
  merged.<BR><BR>-Shahram<BR>-----Original Message-----<BR><B>From:</B> 
  [e-mail] 
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, February 04, 
  2005 1:34 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B> '[e-mail]'; 
  '[e-mail]'; Shahram Davari; Mack-Crane, T. Benjamin; 
  David Allan; Adrian Farrel; [e-mail]<BR><B>Subject:</B> RE: Layer 2 
  Switching Caps LSPs<BR><BR><BR><BR><FONT size=4>dave - your response is "you 
  don't think refinment would be possible" for a reason that escapes me since 
  the document does not define control of provider bridges and as i do not think 
  i have mentioned the "snooping" operation you are describing here below - you 
  are more creative than i do ;-)</FONT><BR><BR><FONT size=4>note: this said it 
  does not change the numbers provided here below - and i can live with 64k LSPs 
  (at least in a first phase) </FONT><BR><BR><B>"David Allan" 
  &lt;[e-mail]&gt;</B><BR>02/04/2005 09:44 EST<BR><BR>To:<FONT size=4> 
  </FONT>"'[e-mail]'" &lt;[e-mail]&gt;, Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari 
  &lt;[e-mail]&gt;<BR>cc:<FONT size=4> </FONT>"Mack-Crane, 
  T. Benjamin" &lt;[e-mail]&gt;, David Allan 
  &lt;[e-mail]&gt;, Adrian Farrel &lt;[e-mail]&gt;, 
  [e-mail]<BR>bcc:<FONT size=4> </FONT><BR>Subject:<FONT size=4> 
  </FONT>RE: Layer 2 Switching Caps LSPs<BR><BR><BR><FONT 
  size=4>Dimitri:</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&lt;snipped&gt;</FONT><FONT size=5> </FONT><BR><FONT size=4>&nbsp;(but 
  </FONT><BR><FONT size=4>&gt; also keep in mind that there are two levels of 
  VLANs defined today so </FONT><BR><FONT size=4>&gt; further refinment is still 
  possible) and with 16 ports you would have </FONT><BR><FONT size=4>&gt; 64k 
  LSPs not that bad for an unscalable solution ;-)</FONT><FONT size=5> 
  </FONT><BR><BR><FONT size=4>Suggesting snooping a 802.1ad VLAN stack to 
  forward on the basis of more than one tag is more creative abuse of existing 
  standards. You cannot preserve the value and simplicity of Ethernet if you 
  insist on re-inventing it...A provider bridge forwards on the basis to S-tag 
  and MAC address. The C-tag has no significance and we would be foolish to 
  pursue a path whereby it does.</FONT><BR><BR><FONT size=4>MPLS devices (all 
  disucssion of ECMP aside) only forward on the basis of the top 
  label.</FONT><FONT size=5> </FONT><BR><BR><FONT size=4>rgds</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>Dave</FONT><FONT size=5> </FONT><BR><BR><FONT 
  size=4>&gt; </FONT><BR><FONT size=4>&gt; note: i have explained in a previous 
  mail where use of PW makes more </FONT><BR><FONT size=4>&gt; sense and where 
  it does less, and where it does simply not</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; </FONT><BR><FONT size=4>&gt; Shahram Davari 
  wrote:</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  Dimitri,</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; I have another question. As you know there 
  are only 4094 VLANs (12 </FONT><BR><FONT size=4>&gt; &gt; bit). This means 
  only 4094 P2P connection could be setup </FONT><BR><FONT size=4>&gt; using 
  GMPLS. </FONT><BR><FONT size=4>&gt; &gt; Since this is not scalable, 
  presumably you need a </FONT><BR><FONT size=4>&gt; multiplexing label 
  </FONT><BR><FONT size=4>&gt; &gt; (such as MPLS or another VLAN tag), and its 
  associated signaling </FONT><BR><FONT size=4>&gt; &gt; between two edges of 
  the network. So why not use PW and be </FONT><BR><FONT size=4>&gt; done with 
  </FONT><BR><FONT size=4>&gt; &gt; it.</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; -Shahram</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  -----Original Message----- From: [e-mail] </FONT><BR><FONT 
  size=4>&gt; &gt; [</FONT><FONT color=blue size=4><U><A 
  href="mailto:[e-mail]">mailto:[e-mail]</A></U></FONT><FONT 
  color=black size=4>]On Behalf Of Shahram Davari Sent: </FONT><BR><FONT 
  size=4>&gt; &gt; Thursday, February 03, 2005 6:19 PM To: </FONT><BR><FONT 
  size=4>&gt; &gt; '[e-mail]' Cc: Mack-Crane, T. 
  Benjamin; </FONT><BR><FONT size=4>&gt; &gt; [e-mail]; David 
  Allan; Adrian Farrel; </FONT><BR><FONT size=4>&gt; [e-mail] 
  </FONT><BR><FONT size=4>&gt; &gt; Subject: RE: Layer 2 Switching Caps 
  LSPs</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; Hi Dimitri,</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  Thanks for your response. Please see my comments in-line.</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  -Shahram</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; -----Original Message----- From: 
  [e-mail] </FONT><BR><FONT size=4>&gt; &gt; 
  [</FONT><FONT color=blue size=4><U><A 
  href="mailto:[e-mail]">mailto:[e-mail]</A></U></FONT><FONT 
  color=black size=4>] Sent: Thursday, </FONT><BR><FONT size=4>&gt; February 03, 
  </FONT><BR><FONT size=4>&gt; &gt; 2005 5:31 PM To: Shahram Davari Cc: 
  </FONT><BR><FONT size=4>&gt; &gt; '[e-mail]'; 
  Mack-Crane, T. Benjamin; </FONT><BR><FONT size=4>&gt; &gt; 
  [e-mail]; David Allan; Adrian Farrel; </FONT><BR><FONT 
  size=4>&gt; [e-mail] </FONT><BR><FONT size=4>&gt; &gt; Subject: RE: 
  Layer 2 Switching Caps LSPs</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt; </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; sharam, the first issue is that you have to 
  decouple the notion of </FONT><BR><FONT size=4>&gt; &gt; ethernet with 
  bridging,</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; Ethernet networks have 3 main 
  layers:</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt; 1) PHY = 10/100/1G/10G as explained in 802.3,</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 2) 
  MAC = 802.3</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; 3) Bridging = 802.1D</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; Without 
  Bridging layer your device can only have a single port. </FONT><BR><FONT 
  size=4>&gt; &gt; Example is the Ethernet port of your desktop computer. 
  Therefore if </FONT><BR><FONT size=4>&gt; &gt; you want to build an Ethernet 
  network, you need bridging layer.</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; the second is that this 
  configuration operation can be automated -</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; But after 
  you have configured your connections (aka VLAN </FONT><BR><FONT size=4>&gt; 
  ports), then </FONT><BR><FONT size=4>&gt; &gt; there is nothing left for GMPS 
  to do. Or are you saying </FONT><BR><FONT size=4>&gt; that the GMPLS 
  </FONT><BR><FONT size=4>&gt; &gt; will do the configuration?</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  however the interesting point you brought in the loop of discussion 
  </FONT><BR><FONT size=4>&gt; &gt; here is "applicability for shared medium" - 
  isn't the PW </FONT><BR><FONT size=4>&gt; solution in </FONT><BR><FONT 
  size=4>&gt; &gt; the same context</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; No, because in PW, the 
  payload (Ethernet) is encapsulated </FONT><BR><FONT size=4>&gt; in another 
  </FONT><BR><FONT size=4>&gt; &gt; layer network (aka MPLS), and is invisible 
  to the </FONT><BR><FONT size=4>&gt; intermediate nodes. </FONT><BR><FONT 
  size=4>&gt; &gt; While in your case there is no encapsulation, and all the 
  </FONT><BR><FONT size=4>&gt; intermediate </FONT><BR><FONT size=4>&gt; &gt; 
  nodes can act on the MAC and VLAN tag.</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; as 1) it can not make an 
  automated usage of a "medium" without </FONT><BR><FONT size=4>&gt; &gt; 
  configuring the tunnels (in our case the tunnels that will </FONT><BR><FONT 
  size=4>&gt; be used to </FONT><BR><FONT size=4>&gt; &gt; carry the ethernet 
  payload e.g. SDH, OTH, etc. if not using </FONT><BR><FONT size=4>&gt; &gt; 
  point-to-point PHY's) but in addition to the present </FONT><BR><FONT 
  size=4>&gt; solution PW also </FONT><BR><FONT size=4>&gt; &gt; requires 2) the 
  provisioning of the PW - something not </FONT><BR><FONT size=4>&gt; needed in 
  the </FONT><BR><FONT size=4>&gt; &gt; present context as terminating points 
  will be directly </FONT><BR><FONT size=4>&gt; accessing the </FONT><BR><FONT 
  size=4>&gt; &gt; "ethernet medium", in brief if such argument is used here it 
  should </FONT><BR><FONT size=4>&gt; &gt; have also been used in the PW context 
  (if not more intensively)</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt; </FONT><BR><FONT size=4>&gt; &gt; another fundamental point, i am also 
  surprised seeing people </FONT><BR><FONT size=4>&gt; &gt; supporting MPLS 
  (which brings a connection-oriented </FONT><BR><FONT size=4>&gt; behaviour to 
  IP) </FONT><BR><FONT size=4>&gt; &gt; wondering about the suitability of using 
  one of the </FONT><BR><FONT size=4>&gt; protocol suite of </FONT><BR><FONT 
  size=4>&gt; &gt; the IETF i.e. GMPLS to bring another (initially) 
  connectionless </FONT><BR><FONT size=4>&gt; &gt; technology to a 
  "connection-oriented" behaviour</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; I don't argue against 
  bringing connection-oriented behavior to </FONT><BR><FONT size=4>&gt; &gt; 
  Ethernet. My concern is the method used to do so. if you had done 
  </FONT><BR><FONT size=4>&gt; &gt; proper Network Interworking (aka, 
  encapsulation or as ITU calls it </FONT><BR><FONT size=4>&gt; &gt; 
  client/server), then there would not be any problem. </FONT><BR><FONT 
  size=4>&gt; However, what you </FONT><BR><FONT size=4>&gt; &gt; are trying to 
  do is to modify Ethernet's control-plane in a </FONT><BR><FONT size=4>&gt; way 
  that </FONT><BR><FONT size=4>&gt; &gt; requires modification to its data-plane 
  behavior. As an </FONT><BR><FONT size=4>&gt; analogy what </FONT><BR><FONT 
  size=4>&gt; &gt; you are doing is like trying to use the IP address as MPLS 
  tag in </FONT><BR><FONT size=4>&gt; &gt; order to make IP 
  connection-oriented.</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; In contrast you could easily change ATM's 
  control-plane to GMPLS </FONT><BR><FONT size=4>&gt; &gt; without any 
  modification to ATM data-plane behavior, because ATM by </FONT><BR><FONT 
  size=4>&gt; &gt; design is connection-oriented, and the VPI/VCI could easily 
  be </FONT><BR><FONT size=4>&gt; &gt; interpreted as GMPLS tags.</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  (even if i do rather prefer the term flow, in the present </FONT><BR><FONT 
  size=4>&gt; context) at </FONT><BR><FONT size=4>&gt; &gt; the end the 
  resulting gain is the same for both </FONT><BR><FONT size=4>&gt; technologies 
  it terms </FONT><BR><FONT size=4>&gt; &gt; of capabilities as application of 
  constraint-based routing </FONT><BR><FONT size=4>&gt; principles</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt; - is this not at the end what drives 
  mostly all debates in </FONT><BR><FONT size=4>&gt; the (G)MPLS 
  </FONT><BR><FONT size=4>&gt; &gt; galaxy beside VPNs and that was underlying 
  incorporation of </FONT><BR><FONT size=4>&gt; these L2 </FONT><BR><FONT 
  size=4>&gt; &gt; technologies as part of the GMPLS protocol 
  architecture</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; thanks,</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; - dimitri.</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; Shahram Davari 
  &lt;[e-mail]&gt; Sent by: </FONT><BR><FONT size=4>&gt; 
  &gt; [e-mail] 02/03/2005 13:13 PST</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; To: 
  Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T. </FONT><BR><FONT 
  size=4>&gt; &gt; Benjamin" &lt;[e-mail]&gt; cc: 
  [e-mail], </FONT><BR><FONT size=4>&gt; &gt; David Allan 
  &lt;[e-mail]&gt;, Adrian Farrel </FONT><BR><FONT size=4>&gt; 
  &gt; &lt;[e-mail]&gt;, [e-mail] bcc: Subject: RE: Layer 2 
  </FONT><BR><FONT size=4>&gt; &gt; Switching Caps LSPs</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; Dimitri,</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  Unfortunately I didn't grasp completely what you are trying </FONT><BR><FONT 
  size=4>&gt; to convey. </FONT><BR><FONT size=4>&gt; &gt; But one thing I know 
  for sure, and that is&nbsp; "Ethernet is </FONT><BR><FONT size=4>&gt; &gt; 
  Connectionless (CLS)" (like IP) and assumes shared medium, </FONT><BR><FONT 
  size=4>&gt; while GMPLS </FONT><BR><FONT size=4>&gt; &gt; is 
  connection-oriented (CO) and doesn't work in shared medium. Off 
  </FONT><BR><FONT size=4>&gt; &gt; course you could always configure and build 
  an Ethernet </FONT><BR><FONT size=4>&gt; network that </FONT><BR><FONT 
  size=4>&gt; &gt; looks like it is CO (by configuring a max of 2 ports with the 
  same </FONT><BR><FONT size=4>&gt; &gt; VLAN ID in each bridge), and by not 
  using any shared </FONT><BR><FONT size=4>&gt; medium. But then 
  </FONT><BR><FONT size=4>&gt; &gt; who needs GMPLS, when you already have to 
  configure your network by </FONT><BR><FONT size=4>&gt; &gt; other 
  means?</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt; -Shahram</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt; </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; From: 
  [e-mail] </FONT><BR><FONT size=4>&gt; &gt; 
  [</FONT><FONT color=blue size=4><U><A 
  href="mailto:[e-mail]">mailto:[e-mail]</A></U></FONT><FONT 
  color=black size=4>] Sent: Thursday, </FONT><BR><FONT size=4>&gt; February 03, 
  </FONT><BR><FONT size=4>&gt; &gt; 2005 3:07 PM To: Mack-Crane, T. Benjamin Cc: 
  </FONT><BR><FONT size=4>&gt; [e-mail]; </FONT><BR><FONT 
  size=4>&gt; &gt; [e-mail]; David Allan; Adrian 
  </FONT><BR><FONT size=4>&gt; Farrel; Shahram </FONT><BR><FONT size=4>&gt; &gt; 
  Davari; [e-mail] Subject: RE: Layer 2 Switching Caps 
  LSPs</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt; ben,</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; the discussion with dave has been reproduced 
  in accelerated on the </FONT><BR><FONT size=4>&gt; &gt; mailing list - for me 
  it appears that the more "philosophical" </FONT><BR><FONT size=4>&gt; &gt; 
  conclusion can be positioned by answering to the following question 
  </FONT><BR><FONT size=4>&gt; &gt; "Was SONET/SDH or lambda switching initially 
  intended to be </FONT><BR><FONT size=4>&gt; controlled </FONT><BR><FONT 
  size=4>&gt; &gt; by GMPLS ?" if the response is "No, but nothing prevents to 
  </FONT><BR><FONT size=4>&gt; do so" the </FONT><BR><FONT size=4>&gt; &gt; next 
  question is what does prevent from applying GMPLS to other </FONT><BR><FONT 
  size=4>&gt; &gt; technologies knowing a substantial gain is obtained from its 
  </FONT><BR><FONT size=4>&gt; &gt; application - in certain conditions - (see 
  motivations as </FONT><BR><FONT size=4>&gt; part of this </FONT><BR><FONT 
  size=4>&gt; &gt; introduction for instance) ? key issue being which are 
  these</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; (technical) 
  conditions and are there conditions that would preclude </FONT><BR><FONT 
  size=4>&gt; &gt; progressing this document - the response is simply the 
  negative - </FONT><BR><FONT size=4>&gt; &gt; there are no such conditions in 
  the point-to-point - non-bridging - </FONT><BR><FONT size=4>&gt; &gt; context 
  where this document applies.</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt; </FONT><BR><FONT size=4>&gt; &gt; now, not sure there is a technical 
  "firm" conclusion but </FONT><BR><FONT size=4>&gt; the point on 
  </FONT><BR><FONT size=4>&gt; &gt; the ethernet label encoding appears as 
  follows since so far </FONT><BR><FONT size=4>&gt; there is </FONT><BR><FONT 
  size=4>&gt; &gt; potential interest to keep the label for ethernet generic 
  </FONT><BR><FONT size=4>&gt; enough and </FONT><BR><FONT size=4>&gt; &gt; 
  deduce its interpretation from type of link over which the label is 
  </FONT><BR><FONT size=4>&gt; &gt; used and intepreet its value according to 
  the </FONT><BR><FONT size=4>&gt; traffic_parameters and </FONT><BR><FONT 
  size=4>&gt; &gt; propose associations to cover cases such as case 2 of 
  Appendix A of </FONT><BR><FONT size=4>&gt; &gt; 
  &lt;draft-pwe3-ethernet-encap-08.txt&gt; mechanisms that is also 
  </FONT><BR><FONT size=4>&gt; applicable </FONT><BR><FONT size=4>&gt; &gt; to 
  other tunneling technology since this mechanism is orthogonal to 
  </FONT><BR><FONT size=4>&gt; &gt; the use of PW's if required (example being 
  Ethernet over </FONT><BR><FONT size=4>&gt; SDH/OTH, for </FONT><BR><FONT 
  size=4>&gt; &gt; instance); however, if these are the only associations we 
  </FONT><BR><FONT size=4>&gt; see relevant </FONT><BR><FONT size=4>&gt; &gt; as 
  part of this document then we would fall back on the existing </FONT><BR><FONT 
  size=4>&gt; &gt; encoding with potential enhancement if so required 
  -</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt; to come to the point of the articulation the - generic - 
  response </FONT><BR><FONT size=4>&gt; &gt; holds in one line: it articulates 
  GMPLS signaling for L2SC LSPs</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt; (note: the latter has been introduced in RFC 3945, RFC 3471, 
  RFC</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 3473) - the 
  motivations are detailed as part of the introduction of </FONT><BR><FONT 
  size=4>&gt; &gt; this document - i can not comment more from your initial 
  statement </FONT><BR><FONT size=4>&gt; &gt; since not detailed enough for me 
  to be more specific</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; the response to the last question is 
  relatively simple </FONT><BR><FONT size=4>&gt; since the above 
  </FONT><BR><FONT size=4>&gt; &gt; mentioned do not include any specifics 
  concerning ATM or FR - this </FONT><BR><FONT size=4>&gt; &gt; document intends 
  to close this gap by defining specific </FONT><BR><FONT size=4>&gt; &gt; 
  Traffic_Parameters for these technologies - is there an </FONT><BR><FONT 
  size=4>&gt; interest for </FONT><BR><FONT size=4>&gt; &gt; doing so: response 
  is yes otherwise the document would not have </FONT><BR><FONT size=4>&gt; &gt; 
  included the corr. details</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt; </FONT><BR><FONT size=4>&gt; &gt; voila, thanks,</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; - 
  dimitri.</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; "Mack-Crane, T. Benjamin" 
  &lt;[e-mail]&gt; Sent by: </FONT><BR><FONT size=4>&gt; &gt; 
  [e-mail] 02/03/2005 12:16 CST</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; To: 
  &lt;[e-mail]&gt;, Dimitri </FONT><BR><FONT size=4>&gt; &gt; 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" </FONT><BR><FONT size=4>&gt; 
  &gt; &lt;[e-mail]&gt; cc: "Adrian Farrel" </FONT><BR><FONT 
  size=4>&gt; &lt;[e-mail]&gt;, </FONT><BR><FONT size=4>&gt; &gt; 
  "Shahram Davari" &lt;[e-mail]&gt;, </FONT><BR><FONT 
  size=4>&gt; &lt;[e-mail]&gt; </FONT><BR><FONT size=4>&gt; &gt; bcc: 
  Subject:</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; RE: Layer 2 
  Switching Caps LSPs</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  Dimitri,</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; Can the off-line discussion be summarized 
  for the benefit </FONT><BR><FONT size=4>&gt; of those on&nbsp; 
  </FONT><BR><FONT size=4>&gt; &gt; the list who did not participate?&nbsp; For 
  me, the draft (and </FONT><BR><FONT size=4>&gt; the current </FONT><BR><FONT 
  size=4>&gt; &gt; discussion on the list) have not clearly articulated the 
  </FONT><BR><FONT size=4>&gt; problem being </FONT><BR><FONT size=4>&gt; &gt; 
  addressed.&nbsp; If a summary of the conclusions of the off-line 
  </FONT><BR><FONT size=4>&gt; discussion </FONT><BR><FONT size=4>&gt; &gt; will 
  do this, it would be useful.</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt; </FONT><BR><FONT size=4>&gt; &gt; I am also interested to know what is 
  lacking in the current </FONT><BR><FONT size=4>&gt; GMPLS RFCs 
  </FONT><BR><FONT size=4>&gt; &gt; with respect to ATM and Frame Relay support 
  that necessitates </FONT><BR><FONT size=4>&gt; &gt; including them in this new 
  draft (presumably this is a part of the </FONT><BR><FONT size=4>&gt; &gt; 
  problem to be solved).</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; Regards, Ben</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; -----Original Message----- From: 
  [e-mail] </FONT><BR><FONT size=4>&gt; &gt;&gt; [</FONT><FONT 
  color=blue size=4><U><A 
  href="mailto:[e-mail]">mailto:[e-mail]</A></U></FONT><FONT 
  color=black size=4>] On</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; Behalf</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt;&gt; Of dimitri 
  papadimitriou Sent: Thursday, January 27, 2005 6:35 PM</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; To: David Allan Cc: 'Adrian Farrel'; 
  'Shahram Davari';</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt; 
  [e-mail] Subject: Re: Layer 2 Switching Caps LSPs</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt; </FONT><BR><FONT size=4>&gt; 
  &gt;&gt; dave - there was a lengthy off-line discussion suggested by the 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; chairs intended to explain you the scope 
  of the draft and its </FONT><BR><FONT size=4>&gt; &gt;&gt; 
  relatioship</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; with</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt;&gt; the ethernet data plane 
  (after the question you raised </FONT><BR><FONT size=4>&gt; during the f2f 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; meeting) - this has been done and we 
  have explained (via a lengthy </FONT><BR><FONT size=4>&gt; &gt;&gt; exchange 
  of e-mails) that this document and so the use of gmpls to </FONT><BR><FONT 
  size=4>&gt; &gt;&gt; control ethernet frame flows, is not targeting control of 
  bridged </FONT><BR><FONT size=4>&gt; &gt;&gt; ethernet environments - if this 
  is not clear from the current </FONT><BR><FONT size=4>&gt; &gt;&gt; document 
  introduction we would have also to work on this </FONT><BR><FONT size=4>&gt; 
  part of the </FONT><BR><FONT size=4>&gt; &gt;&gt; document - therefore, the 
  below reference to MSTP is not in the </FONT><BR><FONT size=4>&gt; &gt;&gt; 
  current scope; on the other side, the use of the term "VLAN label" 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; has created some confusion; therefore, 
  in a next release i will </FONT><BR><FONT size=4>&gt; &gt;&gt; simply refer to 
  a</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt; "label"</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; of 32 bits (unstructured) because the 
  intention was (and </FONT><BR><FONT size=4>&gt; still is) to </FONT><BR><FONT 
  size=4>&gt; &gt;&gt; find an easy way to map the control of the ethernet frame 
  flows on</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; each</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt;&gt; device they traverses 
  without making any assumption on how </FONT><BR><FONT size=4>&gt; this 
  flow</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt; is</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; processed inside each node at the data 
  plane level (note: on label</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt;&gt; values, RFC 3946 took an equivalent approach - for circuits - 
  where</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt;&nbsp; 
  sonet/sdh multiplexing structures have been used to create unique 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; multiplex entry names i.e. labels - this 
  concept is here applied</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt;&gt; for "virtual" circuits), so, if the working group is willing 
  to</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt; enter 
  into</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt; a</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; data plane oriented discussion to 
  clarify the behaviour(s) </FONT><BR><FONT size=4>&gt; onto which 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; the present approach would be 
  potentially applicable this is fine </FONT><BR><FONT size=4>&gt; &gt;&gt; with 
  me as long as we are within the scope of the initial </FONT><BR><FONT 
  size=4>&gt; motivations</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt;&gt; </FONT><BR><FONT size=4>&gt; &gt;&gt; thanks, - dimitri.</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt; </FONT><BR><FONT size=4>&gt; 
  &gt;&gt; David Allan wrote:</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt;&gt; </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; Hi Adrian:</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; </FONT><BR><FONT size=4>&gt; 
  &gt;&gt;&gt; Your suggestion is in a way reasonable but with the caveat that 
  in</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt; IEEE</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; terms, a bridging topology is 
  currently all VLANs (802.1Q single</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt;&gt; </FONT><BR><FONT size=4>&gt; &gt;&gt; 
  spanning</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; tree) or partitioned into specific 
  ranges (I believe 64 in 802.1s</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt;&gt;&gt; </FONT><BR><FONT size=4>&gt; &gt;&gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; although I</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; </FONT><BR><FONT size=4>&gt; 
  &gt;&gt;&gt; do not claim to be an expert).</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; </FONT><BR><FONT size=4>&gt; 
  &gt;&gt;&gt; If the PEs were to implement a bridge function and we were 
  using</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt; GMPLS</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; to</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt;&gt; </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; interconnect 
  them, then the control plane should be identifying</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  either</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT 
  size=4>&gt; &gt;&gt; all</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt;&gt; </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; VLANs (single spanning 
  tree, which I beleive the draft covers by</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt;&gt; </FONT><BR><FONT size=4>&gt; &gt;&gt; 
  referring</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; simply to Ethernet port) or a VLAN 
  range to be associated with the</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; LSP</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; 
  consistent with 802.1s if it is to operate to interconnect bridges</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt; </FONT><BR><FONT size=4>&gt; 
  &gt;&gt; defined</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; by the IEEE...</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; </FONT><BR><FONT size=4>&gt; 
  &gt;&gt;&gt; I suspect assuming any other behavior (e.g. LSP for single 
  VLAN</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; 
  tag)</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; would</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt;&gt; </FONT><BR><FONT size=4>&gt; 
  &gt;&gt;&gt; go outside the boundary of what is currently defined...so 
  </FONT><BR><FONT size=4>&gt; alignment</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; with</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; 
  802.1s IMO would be a minimum requirement if we are to consider</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  carrying</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; VLAN information in GMPLS 
  signalling....</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; cheers Dave</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; </FONT><BR><FONT size=4>&gt; 
  &gt;&gt;&gt; You wrote....</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt;&gt;&gt; </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; </FONT><BR><FONT 
  size=4>&gt; &gt;&gt;&gt;&gt; Hi,</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt;&gt;&gt;&gt; </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt;&gt; The 
  authors of the draft might like to clarify for the list</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt;&gt; exactly what data plane 
  operations they are suggesting. To me </FONT><BR><FONT size=4>&gt; 
  &gt;&gt;&gt;&gt; it seems possible that the draft is proposing VLAN ID 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt;&gt; *swapping*. But an alternative 
  is that the VLAN ID is used as a</FONT><FONT size=5> </FONT><BR><FONT 
  size=4>&gt; &gt;&gt;&gt;&gt; label, but that the same label is used for the 
  full length of</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt;&gt;&gt;&gt; the LSP.</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; 
  &gt;&gt;&gt;&gt; </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt;&gt; 
  Adrian</FONT><FONT size=5> </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; </FONT><BR><FONT size=4>&gt; 
  &gt;&gt;&gt; </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; .</FONT><FONT size=5> 
  </FONT><BR><FONT size=4>&gt; &gt;&gt;&gt; </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; &gt; 
  ============================================================ The 
  </FONT><BR><FONT size=4>&gt; &gt; information contained in this message may be 
  privileged and </FONT><BR><FONT size=4>&gt; &gt; confidential and protected 
  from disclosure. If the reader of this </FONT><BR><FONT size=4>&gt; &gt; 
  message is not the intended recipient, or an employee or agent 
  </FONT><BR><FONT size=4>&gt; &gt; responsible for delivering this message to 
  the intended </FONT><BR><FONT size=4>&gt; recipient, you </FONT><BR><FONT 
  size=4>&gt; &gt; are hereby notified that any reproduction, dissemination or 
  </FONT><BR><FONT size=4>&gt; &gt; distribution of this communication is 
  strictly prohibited. </FONT><BR><FONT size=4>&gt; If you have </FONT><BR><FONT 
  size=4>&gt; &gt; received this communication in error, please notify us 
  </FONT><BR><FONT size=4>&gt; immediately by </FONT><BR><FONT size=4>&gt; &gt; 
  replying to the message and deleting it from your computer. </FONT><BR><FONT 
  size=4>&gt; Thank you. </FONT><BR><FONT size=4>&gt; &gt; Tellabs 
  ============================================================</FONT><FONT 
  size=5> </FONT><BR><FONT size=4>&gt; &gt; </FONT><BR><FONT size=4>&gt; &gt; 
  </FONT><BR><FONT size=4>&gt; </FONT><BR><FONT size=4>&gt; 
</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C50AF2.ED35FC4E--



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 19:27:19 +0000
To: "Mack-Crane, T. Benjamin" <[e-mail]>
Cc: <[e-mail]>, "Shahram Davari" <[e-mail]>, <[e-mail]>, "David Allan" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
MIME-Version: 1.0
Date: Fri, 4 Feb 2005 20:26:12 +0100
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

ben,

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

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

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

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





Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 19:10:12 +0000
To: Shahram Davari <[e-mail]>
Cc: "'[e-mail]'"	 <[e-mail]>, David Allan <[e-mail]>, "'[e-mail]'" <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 20:09:32 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+c2hhcmFtLCBpIGhhdmUgZXhwbGFpbmVkIGluIGEgcHJldmlvdXMgdGhyZWFkIHRha2luZyB0
cmFuc2xhdGlvbiBvcGVyYXRpb24gYWxsb3dlZCBvbiBWTEFOIElEcyAoc2VlIFBXRTMgZW5jYXBz
IGRvY3VtZW50IGZvciBpbnN0LikgYW5kIGhlcmUgYXNzdW1pbmcgdGhhdCB0aGUgaW52ZXJzZSB0
cmFuc2xhdGlvbiBpcyBwZXJmb3JtZWQgYXQgdGhlIGVncmVzcyB5b3UgYXJlIHJldHJpZXZpbmcg
dGhlIHZhbHVlIHdoZW4gbGVhdmluZyB0aGUgbmV0d29yazwvUD48UD5jb25jZXJuaW5nIHRoZSBz
ZWNvbmQgcG9pbnQsIHRoZSBpc3N1ZSBvZiBtZXJnaW5nIGhhcyBhbHNvIHRvIGJlIHJlZmluZWQg
ZnJvbSB3aGF0IHlvdSBzYXkgYXMgeW91IGNhbiBtYWludGFpbiB0d28gZGlmZmVyZW50IExTUHMg
b24gYSBsaW5rIHRoYXQgc2hhcmUgYSBjb21tb24gbGFiZWwgKGluIHRoZSBmcmFtZSBtb2RlKSAt
IGFzIGJyaWVmbHkgZXhwbGFpbmVkIGluIHNlY3Rpb24gJm5ic3A7Mi40LjMgb2YgUkZDIDMyMDkg
LSB0aGlzIHNhaWQgdGhlIGFib3ZlIG9wZXJhdGlvbiBpcyBhbHNvIG5vdCBleGNsdWRlZCBpZiBv
bmUgZGVzaXJlcyBtYWludGFpbmluZyBzZXBhcmF0ZSBsYWJlbHMgPEJSPjxCUj48Rk9OVCBTSVpF
PTI+PEI+U2hhaHJhbSBEYXZhcmkgJmx0O1NoYWhyYW1fRGF2YXJpQHBtYy1zaWVycmEuY29tJmd0
OzwvQj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0
Zi5vcmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj4wMi8wNC8yMDA1IDEwOjU1IFBTVDwvRk9OVD48
QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+RGltaXRyaSBQQVBB
RElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTCwgRGF2aWQgQWxsYW4gJmx0O2RhbGxhbkBub3J0
ZWwuY29tJmd0OzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9
Mj4mcXVvdDsnZHBhcGFkaW1pdHJpb3VAcHNnLmNvbScmcXVvdDsgJmx0O2RwYXBhZGltaXRyaW91
QHBzZy5jb20mZ3Q7LCAmcXVvdDtNYWNrLUNyYW5lLCBULiBCZW5qYW1pbiZxdW90OyAmbHQ7QmVu
Lk1hY2stQ3JhbmVAdGVsbGFicy5jb20mZ3Q7LCBEYXZpZCBBbGxhbiAmbHQ7ZGFsbGFuQG5vcnRl
bG5ldHdvcmtzLmNvbSZndDssIEFkcmlhbiBGYXJyZWwgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsm
Z3Q7LCBjY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+YmNjOjwvRk9O
VD4gPEJSPiA8Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5SRTogTGF5
ZXIgMiBTd2l0Y2hpbmcgQ2FwcyBMU1BzPC9GT05UPjxCUj4gPEJSPjxCUj48L1A+PFA+RGltaXRy
aSw8QlI+PEJSPkhvIGRvIHlvdSBhY2hpZXZlIHRoZSA2NEs/IEFyZSB5b3UgcGxhbm5pbmcgdG8g
cmV1c2UgdGhlIFZMQU4tSUQgaW4gZGlmZmVyZW50IHBvcnRzIGZvciBkaWZmZXJlbnQgTFNQcz88
QlI+SWYgc28geW91ciBwcm9wb3NhbCBpcyBicm9rZW4sIGJlY2F1c2UgVkxBTiBJRHMgZG9uJ3Qg
aGF2ZSBsb2NhbCBzaWduaWZpY2FuY2UsIHJhdGhlciB0aGV5IGhhdmUgbmV0d29yay13aWRlIDxC
Uj5zaWduaWZpY2FuY2UgYW5kIG1lYW5pbmcuIFNvIGlmJm5ic3A7IDIgb2YgdGhlc2UgTFNQcyAo
aGF2aW5nIHRoZSBzYW1lIFZMQU4gSUQpIHBhc3MgdGhyb3VnaCB0aGUgc2FtZSBsaW5rLCB0aGV5
IHdvdWxkIGJlIG1lcmdlZC48QlI+PEJSPi1TaGFocmFtPEJSPi0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tPEJSPjxCPkZyb206PC9CPiBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZSBb
bWFpbHRvOkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlXTxCUj48Qj5TZW50OjwvQj4g
RnJpZGF5LCBGZWJydWFyeSAwNCwgMjAwNSAxOjM0IFBNPEJSPjxCPlRvOjwvQj4gRGF2aWQgQWxs
YW48QlI+PEI+Q2M6PC9CPiAnZHBhcGFkaW1pdHJpb3VAcHNnLmNvbSc7ICdkaW1pdHJpLnBhcGFk
aW1pdHJpb3VAYWxjYXRlbC5iZSc7IFNoYWhyYW0gRGF2YXJpOyBNYWNrLUNyYW5lLCBULiBCZW5q
YW1pbjsgRGF2aWQgQWxsYW47IEFkcmlhbiBGYXJyZWw7IGNjYW1wQG9wcy5pZXRmLm9yZzxCUj48
Qj5TdWJqZWN0OjwvQj4gUkU6IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQczxCUj48QlI+PEJS
PjxCUj48Rk9OVCBTSVpFPTQ+ZGF2ZSAtIHlvdXIgcmVzcG9uc2UgaXMgJnF1b3Q7eW91IGRvbid0
IHRoaW5rIHJlZmlubWVudCB3b3VsZCBiZSBwb3NzaWJsZSZxdW90OyBmb3IgYSByZWFzb24gdGhh
dCBlc2NhcGVzIG1lIHNpbmNlIHRoZSBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgY29udHJvbCBv
ZiBwcm92aWRlciBicmlkZ2VzIGFuZCBhcyBpIGRvIG5vdCB0aGluayBpIGhhdmUgbWVudGlvbmVk
IHRoZSAmcXVvdDtzbm9vcGluZyZxdW90OyBvcGVyYXRpb24geW91IGFyZSBkZXNjcmliaW5nIGhl
cmUgYmVsb3cgLSB5b3UgYXJlIG1vcmUgY3JlYXRpdmUgdGhhbiBpIGRvIDstKTwvRk9OVD48QlI+
PEJSPjxGT05UIFNJWkU9ND5ub3RlOiB0aGlzIHNhaWQgaXQgZG9lcyBub3QgY2hhbmdlIHRoZSBu
dW1iZXJzIHByb3ZpZGVkIGhlcmUgYmVsb3cgLSBhbmQgaSBjYW4gbGl2ZSB3aXRoIDY0ayBMU1Bz
IChhdCBsZWFzdCBpbiBhIGZpcnN0IHBoYXNlKSA8L0ZPTlQ+PEJSPjxCUj48Qj4mcXVvdDtEYXZp
ZCBBbGxhbiZxdW90OyAmbHQ7ZGFsbGFuQG5vcnRlbC5jb20mZ3Q7PC9CPjxCUj4wMi8wNC8yMDA1
IDA5OjQ0IEVTVDxCUj48QlI+VG86PEZPTlQgU0laRT00PiA8L0ZPTlQ+JnF1b3Q7J2RwYXBhZGlt
aXRyaW91QHBzZy5jb20nJnF1b3Q7ICZsdDtkcGFwYWRpbWl0cmlvdUBwc2cuY29tJmd0OywgRGlt
aXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTCwgU2hhaHJhbSBEYXZhcmkgJmx0
O1NoYWhyYW1fRGF2YXJpQHBtYy1zaWVycmEuY29tJmd0OzxCUj5jYzo8Rk9OVCBTSVpFPTQ+IDwv
Rk9OVD4mcXVvdDtNYWNrLUNyYW5lLCBULiBCZW5qYW1pbiZxdW90OyAmbHQ7QmVuLk1hY2stQ3Jh
bmVAdGVsbGFicy5jb20mZ3Q7LCBEYXZpZCBBbGxhbiAmbHQ7ZGFsbGFuQG5vcnRlbG5ldHdvcmtz
LmNvbSZndDssIEFkcmlhbiBGYXJyZWwgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7LCBjY2Ft
cEBvcHMuaWV0Zi5vcmc8QlI+YmNjOjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj5TdWJqZWN0OjxG
T05UIFNJWkU9ND4gPC9GT05UPlJFOiBMYXllciAyIFN3aXRjaGluZyBDYXBzIExTUHM8QlI+PEJS
PjxCUj48Rk9OVCBTSVpFPTQ+RGltaXRyaTo8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND4mbHQ7c25pcHBlZCZndDs8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mbmJzcDsoYnV0IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsg
YWxzbyBrZWVwIGluIG1pbmQgdGhhdCB0aGVyZSBhcmUgdHdvIGxldmVscyBvZiBWTEFOcyBkZWZp
bmVkIHRvZGF5IHNvIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgZnVydGhlciByZWZpbm1l
bnQgaXMgc3RpbGwgcG9zc2libGUpIGFuZCB3aXRoIDE2IHBvcnRzIHlvdSB3b3VsZCBoYXZlIDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgNjRrIExTUHMgbm90IHRoYXQgYmFkIGZvciBhbiB1
bnNjYWxhYmxlIHNvbHV0aW9uIDstKTwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEJS
PjxGT05UIFNJWkU9ND5TdWdnZXN0aW5nIHNub29waW5nIGEgODAyLjFhZCBWTEFOIHN0YWNrIHRv
IGZvcndhcmQgb24gdGhlIGJhc2lzIG9mIG1vcmUgdGhhbiBvbmUgdGFnIGlzIG1vcmUgY3JlYXRp
dmUgYWJ1c2Ugb2YgZXhpc3Rpbmcgc3RhbmRhcmRzLiBZb3UgY2Fubm90IHByZXNlcnZlIHRoZSB2
YWx1ZSBhbmQgc2ltcGxpY2l0eSBvZiBFdGhlcm5ldCBpZiB5b3UgaW5zaXN0IG9uIHJlLWludmVu
dGluZyBpdC4uLkEgcHJvdmlkZXIgYnJpZGdlIGZvcndhcmRzIG9uIHRoZSBiYXNpcyB0byBTLXRh
ZyBhbmQgTUFDIGFkZHJlc3MuIFRoZSBDLXRhZyBoYXMgbm8gc2lnbmlmaWNhbmNlIGFuZCB3ZSB3
b3VsZCBiZSBmb29saXNoIHRvIHB1cnN1ZSBhIHBhdGggd2hlcmVieSBpdCBkb2VzLjwvRk9OVD48
QlI+PEJSPjxGT05UIFNJWkU9ND5NUExTIGRldmljZXMgKGFsbCBkaXN1Y3NzaW9uIG9mIEVDTVAg
YXNpZGUpIG9ubHkgZm9yd2FyZCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRvcCBsYWJlbC48L0ZPTlQ+
PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+cmdkczwvRk9OVD48Rk9O
VCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PkRhdmU8L0ZPTlQ+PEZPTlQgU0laRT01
PiA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7IG5vdGU6IGkgaGF2ZSBleHBsYWluZWQgaW4gYSBwcmV2aW91cyBtYWlsIHdoZXJlIHVz
ZSBvZiBQVyBtYWtlcyBtb3JlIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgc2Vuc2UgYW5k
IHdoZXJlIGl0IGRvZXMgbGVzcywgYW5kIHdoZXJlIGl0IGRvZXMgc2ltcGx5IG5vdDwvRk9OVD48
Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyBTaGFocmFtIERhdmFyaSB3cm90ZTo8L0ZPTlQ+PEZPTlQgU0laRT01PiA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgRGltaXRyaSw8L0ZPTlQ+PEZPTlQgU0la
RT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyAmZ3Q7IEkgaGF2ZSBhbm90aGVyIHF1ZXN0aW9uLiBBcyB5b3Uga25vdyB0aGVy
ZSBhcmUgb25seSA0MDk0IFZMQU5zICgxMiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZn
dDsgYml0KS4gVGhpcyBtZWFucyBvbmx5IDQwOTQgUDJQIGNvbm5lY3Rpb24gY291bGQgYmUgc2V0
dXAgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyB1c2luZyBHTVBMUy4gPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IFNpbmNlIHRoaXMgaXMgbm90IHNjYWxhYmxlLCBwcmVzdW1h
Ymx5IHlvdSBuZWVkIGEgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBtdWx0aXBsZXhpbmcg
bGFiZWwgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IChzdWNoIGFzIE1QTFMgb3Ig
YW5vdGhlciBWTEFOIHRhZyksIGFuZCBpdHMgYXNzb2NpYXRlZCBzaWduYWxpbmcgPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IGJldHdlZW4gdHdvIGVkZ2VzIG9mIHRoZSBuZXR3b3Jr
LiBTbyB3aHkgbm90IHVzZSBQVyBhbmQgYmUgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBk
b25lIHdpdGggPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IGl0LjwvRk9OVD48Rk9O
VCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mZ3Q7ICZndDsgLVNoYWhyYW08L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAm
Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IG93bmVyLWNjYW1wQG9wcy5pZXRm
Lm9yZyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgWzwvRk9OVD48Rk9OVCBTSVpF
PTQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc+
bWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvQT48L1U+PC9GT05UPjxGT05UIFNJWkU9
NCBDT0xPUj1CTEFDSz5dT24gQmVoYWxmIE9mIFNoYWhyYW0gRGF2YXJpIFNlbnQ6IDwvRk9OVD48
QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBUaHVyc2RheSwgRmVicnVhcnkgMDMsIDIwMDUgNjox
OSBQTSBUbzogPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7ICdEaW1pdHJpLlBhcGFk
aW1pdHJpb3VAYWxjYXRlbC5iZScgQ2M6IE1hY2stQ3JhbmUsIFQuIEJlbmphbWluOyA8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgZHBhcGFkaW1pdHJpb3VAcHNnLmNvbTsgRGF2aWQg
QWxsYW47IEFkcmlhbiBGYXJyZWw7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgY2NhbXBA
b3BzLmlldGYub3JnIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBTdWJqZWN0OiBS
RTogTGF5ZXIgMiBTd2l0Y2hpbmcgQ2FwcyBMU1BzPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05U
PjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsg
Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgSGkgRGltaXRyaSw8L0ZPTlQ+
PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IFRoYW5rcyBmb3IgeW91ciByZXNwb25zZS4gUGxlYXNl
IHNlZSBteSBjb21tZW50cyBpbi1saW5lLjwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+
PEZPTlQgU0laRT00PiZndDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsg
LVNoYWhyYW08L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7
ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tIEZyb206IERpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlIDwvRk9OVD48
QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBbPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVF
PjxVPjxBIEhSRUY9bWFpbHRvOkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlPm1haWx0
bzpEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZTwvQT48L1U+PC9GT05UPjxGT05UIFNJ
WkU9NCBDT0xPUj1CTEFDSz5dIFNlbnQ6IFRodXJzZGF5LCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7IEZlYnJ1YXJ5IDAzLCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgMjAw
NSA1OjMxIFBNIFRvOiBTaGFocmFtIERhdmFyaSBDYzogPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyAmZ3Q7ICdEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZSc7IE1hY2stQ3JhbmUs
IFQuIEJlbmphbWluOyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgZHBhcGFkaW1p
dHJpb3VAcHNnLmNvbTsgRGF2aWQgQWxsYW47IEFkcmlhbiBGYXJyZWw7IDwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiZndDsgY2NhbXBAb3BzLmlldGYub3JnIDwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZndDsgJmd0OyBTdWJqZWN0OiBSRTogTGF5ZXIgMiBTd2l0Y2hpbmcgQ2FwcyBMU1BzPC9GT05U
PjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48
QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZn
dDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IHNoYXJhbSwgdGhlIGZpcnN0IGlz
c3VlIGlzIHRoYXQgeW91IGhhdmUgdG8gZGVjb3VwbGUgdGhlIG5vdGlvbiBvZiA8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgZXRoZXJuZXQgd2l0aCBicmlkZ2luZyw8L0ZPTlQ+PEZP
TlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IEV0aGVybmV0IG5ldHdvcmtzIGhhdmUgMyBtYWluIGxheWVy
czo8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsg
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDEpIFBIWSA9IDEwLzEwMC8xRy8xMEcg
YXMgZXhwbGFpbmVkIGluIDgwMi4zLDwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiZndDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgMikg
TUFDID0gODAyLjM8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4m
Z3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDMpIEJyaWRnaW5nID0g
ODAyLjFEPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAm
Z3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBXaXRob3V0IEJyaWRnaW5nIGxh
eWVyIHlvdXIgZGV2aWNlIGNhbiBvbmx5IGhhdmUgYSBzaW5nbGUgcG9ydC4gPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IEV4YW1wbGUgaXMgdGhlIEV0aGVybmV0IHBvcnQgb2YgeW91
ciBkZXNrdG9wIGNvbXB1dGVyLiBUaGVyZWZvcmUgaWYgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyAmZ3Q7IHlvdSB3YW50IHRvIGJ1aWxkIGFuIEV0aGVybmV0IG5ldHdvcmssIHlvdSBuZWVk
IGJyaWRnaW5nIGxheWVyLjwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0la
RT00PiZndDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0
OyB0aGUgc2Vjb25kIGlzIHRoYXQgdGhpcyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbiBjYW4gYmUg
YXV0b21hdGVkIC08L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4m
Z3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IEJ1dCBhZnRlciB5b3Ug
aGF2ZSBjb25maWd1cmVkIHlvdXIgY29ubmVjdGlvbnMgKGFrYSBWTEFOIDwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiZndDsgcG9ydHMpLCB0aGVuIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsg
Jmd0OyB0aGVyZSBpcyBub3RoaW5nIGxlZnQgZm9yIEdNUFMgdG8gZG8uIE9yIGFyZSB5b3Ugc2F5
aW5nIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgdGhhdCB0aGUgR01QTFMgPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IHdpbGwgZG8gdGhlIGNvbmZpZ3VyYXRpb24/PC9GT05U
PjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48
QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBob3dldmVyIHRoZSBpbnRlcmVzdGluZyBwb2ludCB5
b3UgYnJvdWdodCBpbiB0aGUgbG9vcCBvZiBkaXNjdXNzaW9uIDwvRk9OVD48QlI+PEZPTlQgU0la
RT00PiZndDsgJmd0OyBoZXJlIGlzICZxdW90O2FwcGxpY2FiaWxpdHkgZm9yIHNoYXJlZCBtZWRp
dW0mcXVvdDsgLSBpc24ndCB0aGUgUFcgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBzb2x1
dGlvbiBpbiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgdGhlIHNhbWUgY29udGV4
dDwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgTm8sIGJlY2F1c2UgaW4gUFcsIHRoZSBw
YXlsb2FkIChFdGhlcm5ldCkgaXMgZW5jYXBzdWxhdGVkIDwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZndDsgaW4gYW5vdGhlciA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgbGF5ZXIg
bmV0d29yayAoYWthIE1QTFMpLCBhbmQgaXMgaW52aXNpYmxlIHRvIHRoZSA8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mZ3Q7IGludGVybWVkaWF0ZSBub2Rlcy4gPC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQ+Jmd0OyAmZ3Q7IFdoaWxlIGluIHlvdXIgY2FzZSB0aGVyZSBpcyBubyBlbmNhcHN1bGF0aW9u
LCBhbmQgYWxsIHRoZSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IGludGVybWVkaWF0ZSA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgbm9kZXMgY2FuIGFjdCBvbiB0aGUgTUFD
IGFuZCBWTEFOIHRhZy48L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IGFzIDEpIGl0IGNh
biBub3QgbWFrZSBhbiBhdXRvbWF0ZWQgdXNhZ2Ugb2YgYSAmcXVvdDttZWRpdW0mcXVvdDsgd2l0
aG91dCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgY29uZmlndXJpbmcgdGhlIHR1
bm5lbHMgKGluIG91ciBjYXNlIHRoZSB0dW5uZWxzIHRoYXQgd2lsbCA8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7IGJlIHVzZWQgdG8gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7
IGNhcnJ5IHRoZSBldGhlcm5ldCBwYXlsb2FkIGUuZy4gU0RILCBPVEgsIGV0Yy4gaWYgbm90IHVz
aW5nIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBwb2ludC10by1wb2ludCBQSFkn
cykgYnV0IGluIGFkZGl0aW9uIHRvIHRoZSBwcmVzZW50IDwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZndDsgc29sdXRpb24gUFcgYWxzbyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsg
cmVxdWlyZXMgMikgdGhlIHByb3Zpc2lvbmluZyBvZiB0aGUgUFcgLSBzb21ldGhpbmcgbm90IDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgbmVlZGVkIGluIHRoZSA8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7ICZndDsgcHJlc2VudCBjb250ZXh0IGFzIHRlcm1pbmF0aW5nIHBvaW50cyB3
aWxsIGJlIGRpcmVjdGx5IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgYWNjZXNzaW5nIHRo
ZSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgJnF1b3Q7ZXRoZXJuZXQgbWVkaXVt
JnF1b3Q7LCBpbiBicmllZiBpZiBzdWNoIGFyZ3VtZW50IGlzIHVzZWQgaGVyZSBpdCBzaG91bGQg
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IGhhdmUgYWxzbyBiZWVuIHVzZWQgaW4g
dGhlIFBXIGNvbnRleHQgKGlmIG5vdCBtb3JlIGludGVuc2l2ZWx5KTwvRk9OVD48Rk9OVCBTSVpF
PTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDsgYW5vdGhlciBmdW5kYW1lbnRhbCBwb2ludCwgaSBhbSBhbHNvIHN1cnBy
aXNlZCBzZWVpbmcgcGVvcGxlIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBzdXBw
b3J0aW5nIE1QTFMgKHdoaWNoIGJyaW5ncyBhIGNvbm5lY3Rpb24tb3JpZW50ZWQgPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyBiZWhhdmlvdXIgdG8gSVApIDwvRk9OVD48QlI+PEZPTlQgU0la
RT00PiZndDsgJmd0OyB3b25kZXJpbmcgYWJvdXQgdGhlIHN1aXRhYmlsaXR5IG9mIHVzaW5nIG9u
ZSBvZiB0aGUgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBwcm90b2NvbCBzdWl0ZSBvZiA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgdGhlIElFVEYgaS5lLiBHTVBMUyB0byBi
cmluZyBhbm90aGVyIChpbml0aWFsbHkpIGNvbm5lY3Rpb25sZXNzIDwvRk9OVD48QlI+PEZPTlQg
U0laRT00PiZndDsgJmd0OyB0ZWNobm9sb2d5IHRvIGEgJnF1b3Q7Y29ubmVjdGlvbi1vcmllbnRl
ZCZxdW90OyBiZWhhdmlvdXI8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IEkgZG9uJ3Qg
YXJndWUgYWdhaW5zdCBicmluZ2luZyBjb25uZWN0aW9uLW9yaWVudGVkIGJlaGF2aW9yIHRvIDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBFdGhlcm5ldC4gTXkgY29uY2VybiBpcyB0
aGUgbWV0aG9kIHVzZWQgdG8gZG8gc28uIGlmIHlvdSBoYWQgZG9uZSA8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7ICZndDsgcHJvcGVyIE5ldHdvcmsgSW50ZXJ3b3JraW5nIChha2EsIGVuY2Fw
c3VsYXRpb24gb3IgYXMgSVRVIGNhbGxzIGl0IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsg
Jmd0OyBjbGllbnQvc2VydmVyKSwgdGhlbiB0aGVyZSB3b3VsZCBub3QgYmUgYW55IHByb2JsZW0u
IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgSG93ZXZlciwgd2hhdCB5b3UgPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IGFyZSB0cnlpbmcgdG8gZG8gaXMgdG8gbW9kaWZ5IEV0
aGVybmV0J3MgY29udHJvbC1wbGFuZSBpbiBhIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsg
d2F5IHRoYXQgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IHJlcXVpcmVzIG1vZGlm
aWNhdGlvbiB0byBpdHMgZGF0YS1wbGFuZSBiZWhhdmlvci4gQXMgYW4gPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyBhbmFsb2d5IHdoYXQgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAm
Z3Q7IHlvdSBhcmUgZG9pbmcgaXMgbGlrZSB0cnlpbmcgdG8gdXNlIHRoZSBJUCBhZGRyZXNzIGFz
IE1QTFMgdGFnIGluIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBvcmRlciB0byBt
YWtlIElQIGNvbm5lY3Rpb24tb3JpZW50ZWQuPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0
OyBJbiBjb250cmFzdCB5b3UgY291bGQgZWFzaWx5IGNoYW5nZSBBVE0ncyBjb250cm9sLXBsYW5l
IHRvIEdNUExTIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyB3aXRob3V0IGFueSBt
b2RpZmljYXRpb24gdG8gQVRNIGRhdGEtcGxhbmUgYmVoYXZpb3IsIGJlY2F1c2UgQVRNIGJ5IDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBkZXNpZ24gaXMgY29ubmVjdGlvbi1vcmll
bnRlZCwgYW5kIHRoZSBWUEkvVkNJIGNvdWxkIGVhc2lseSBiZSA8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDsgaW50ZXJwcmV0ZWQgYXMgR01QTFMgdGFncy48L0ZPTlQ+PEZPTlQgU0la
RT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyAmZ3Q7IChldmVuIGlmIGkgZG8gcmF0aGVyIHByZWZlciB0aGUgdGVybSBmbG93
LCBpbiB0aGUgcHJlc2VudCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IGNvbnRleHQpIGF0
IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyB0aGUgZW5kIHRoZSByZXN1bHRpbmcg
Z2FpbiBpcyB0aGUgc2FtZSBmb3IgYm90aCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IHRl
Y2hub2xvZ2llcyBpdCB0ZXJtcyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgb2Yg
Y2FwYWJpbGl0aWVzIGFzIGFwcGxpY2F0aW9uIG9mIGNvbnN0cmFpbnQtYmFzZWQgcm91dGluZyA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IHByaW5jaXBsZXM8L0ZPTlQ+PEZPTlQgU0laRT01
PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgLSBpcyB0aGlzIG5vdCBhdCB0aGUg
ZW5kIHdoYXQgZHJpdmVzIG1vc3RseSBhbGwgZGViYXRlcyBpbiA8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7IHRoZSAoRylNUExTIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBn
YWxheHkgYmVzaWRlIFZQTnMgYW5kIHRoYXQgd2FzIHVuZGVybHlpbmcgaW5jb3Jwb3JhdGlvbiBv
ZiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IHRoZXNlIEwyIDwvRk9OVD48QlI+PEZPTlQg
U0laRT00PiZndDsgJmd0OyB0ZWNobm9sb2dpZXMgYXMgcGFydCBvZiB0aGUgR01QTFMgcHJvdG9j
b2wgYXJjaGl0ZWN0dXJlPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyB0aGFua3MsPC9G
T05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9O
VD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyAtIGRpbWl0cmkuPC9GT05UPjxGT05UIFNJWkU9
NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0la
RT00PiZndDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgU2hhaHJhbSBE
YXZhcmkgJmx0O1NoYWhyYW1fRGF2YXJpQHBtYy1zaWVycmEuY29tJmd0OyBTZW50IGJ5OiA8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgb3duZXItY2NhbXBAb3BzLmlldGYub3JnIDAy
LzAzLzIwMDUgMTM6MTMgUFNUPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBUbzogRGlt
aXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTCwgJnF1b3Q7TWFjay1DcmFuZSwg
VC4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IEJlbmphbWluJnF1b3Q7ICZsdDtC
ZW4uTWFjay1DcmFuZUB0ZWxsYWJzLmNvbSZndDsgY2M6IGRwYXBhZGltaXRyaW91QHBzZy5jb20s
IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBEYXZpZCBBbGxhbiAmbHQ7ZGFsbGFu
QG5vcnRlbG5ldHdvcmtzLmNvbSZndDssIEFkcmlhbiBGYXJyZWwgPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyAmZ3Q7ICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OywgY2NhbXBAb3BzLmll
dGYub3JnIGJjYzogU3ViamVjdDogUkU6IExheWVyIDIgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyAmZ3Q7IFN3aXRjaGluZyBDYXBzIExTUHM8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAm
Z3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IERpbWl0cmks
PC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBVbmZvcnR1bmF0ZWx5IEkgZGlkbid0IGdy
YXNwIGNvbXBsZXRlbHkgd2hhdCB5b3UgYXJlIHRyeWluZyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7IHRvIGNvbnZleS4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IEJ1dCBv
bmUgdGhpbmcgSSBrbm93IGZvciBzdXJlLCBhbmQgdGhhdCBpcyZuYnNwOyAmcXVvdDtFdGhlcm5l
dCBpcyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgQ29ubmVjdGlvbmxlc3MgKENM
UykmcXVvdDsgKGxpa2UgSVApIGFuZCBhc3N1bWVzIHNoYXJlZCBtZWRpdW0sIDwvRk9OVD48QlI+
PEZPTlQgU0laRT00PiZndDsgd2hpbGUgR01QTFMgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyAmZ3Q7IGlzIGNvbm5lY3Rpb24tb3JpZW50ZWQgKENPKSBhbmQgZG9lc24ndCB3b3JrIGluIHNo
YXJlZCBtZWRpdW0uIE9mZiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgY291cnNl
IHlvdSBjb3VsZCBhbHdheXMgY29uZmlndXJlIGFuZCBidWlsZCBhbiBFdGhlcm5ldCA8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IG5ldHdvcmsgdGhhdCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7ICZndDsgbG9va3MgbGlrZSBpdCBpcyBDTyAoYnkgY29uZmlndXJpbmcgYSBtYXggb2Yg
MiBwb3J0cyB3aXRoIHRoZSBzYW1lIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBW
TEFOIElEIGluIGVhY2ggYnJpZGdlKSwgYW5kIGJ5IG5vdCB1c2luZyBhbnkgc2hhcmVkIDwvRk9O
VD48QlI+PEZPTlQgU0laRT00PiZndDsgbWVkaXVtLiBCdXQgdGhlbiA8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7ICZndDsgd2hvIG5lZWRzIEdNUExTLCB3aGVuIHlvdSBhbHJlYWR5IGhhdmUg
dG8gY29uZmlndXJlIHlvdXIgbmV0d29yayBieSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7
ICZndDsgb3RoZXIgbWVhbnM/PC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyAtU2hhaHJh
bTwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyAmZ3Q7IEZyb206IERpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlIDwvRk9OVD48
QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBbPC9GT05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTFVF
PjxVPjxBIEhSRUY9bWFpbHRvOkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlPm1haWx0
bzpEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZTwvQT48L1U+PC9GT05UPjxGT05UIFNJ
WkU9NCBDT0xPUj1CTEFDSz5dIFNlbnQ6IFRodXJzZGF5LCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7IEZlYnJ1YXJ5IDAzLCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgMjAw
NSAzOjA3IFBNIFRvOiBNYWNrLUNyYW5lLCBULiBCZW5qYW1pbiBDYzogPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyBkcGFwYWRpbWl0cmlvdUBwc2cuY29tOyA8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDsgZGltaXRyaS5wYXBhZGltaXRyaW91QGFsY2F0ZWwuYmU7IERhdmlkIEFs
bGFuOyBBZHJpYW4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBGYXJyZWw7IFNoYWhyYW0g
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IERhdmFyaTsgY2NhbXBAb3BzLmlldGYu
b3JnIFN1YmplY3Q6IFJFOiBMYXllciAyIFN3aXRjaGluZyBDYXBzIExTUHM8L0ZPTlQ+PEZPTlQg
U0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgYmVuLDwvRk9OVD48Rk9OVCBTSVpFPTU+IDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4m
Z3Q7ICZndDsgdGhlIGRpc2N1c3Npb24gd2l0aCBkYXZlIGhhcyBiZWVuIHJlcHJvZHVjZWQgaW4g
YWNjZWxlcmF0ZWQgb24gdGhlIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBtYWls
aW5nIGxpc3QgLSBmb3IgbWUgaXQgYXBwZWFycyB0aGF0IHRoZSBtb3JlICZxdW90O3BoaWxvc29w
aGljYWwmcXVvdDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IGNvbmNsdXNpb24g
Y2FuIGJlIHBvc2l0aW9uZWQgYnkgYW5zd2VyaW5nIHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb24g
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7ICZxdW90O1dhcyBTT05FVC9TREggb3Ig
bGFtYmRhIHN3aXRjaGluZyBpbml0aWFsbHkgaW50ZW5kZWQgdG8gYmUgPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyBjb250cm9sbGVkIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0
OyBieSBHTVBMUyA/JnF1b3Q7IGlmIHRoZSByZXNwb25zZSBpcyAmcXVvdDtObywgYnV0IG5vdGhp
bmcgcHJldmVudHMgdG8gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBkbyBzbyZxdW90OyB0
aGUgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IG5leHQgcXVlc3Rpb24gaXMgd2hh
dCBkb2VzIHByZXZlbnQgZnJvbSBhcHBseWluZyBHTVBMUyB0byBvdGhlciA8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mZ3Q7ICZndDsgdGVjaG5vbG9naWVzIGtub3dpbmcgYSBzdWJzdGFudGlhbCBn
YWluIGlzIG9idGFpbmVkIGZyb20gaXRzIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0
OyBhcHBsaWNhdGlvbiAtIGluIGNlcnRhaW4gY29uZGl0aW9ucyAtIChzZWUgbW90aXZhdGlvbnMg
YXMgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBwYXJ0IG9mIHRoaXMgPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IGludHJvZHVjdGlvbiBmb3IgaW5zdGFuY2UpID8ga2V5IGlz
c3VlIGJlaW5nIHdoaWNoIGFyZSB0aGVzZTwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+
PEZPTlQgU0laRT00PiZndDsgJmd0OyAodGVjaG5pY2FsKSBjb25kaXRpb25zIGFuZCBhcmUgdGhl
cmUgY29uZGl0aW9ucyB0aGF0IHdvdWxkIHByZWNsdWRlIDwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZndDsgJmd0OyBwcm9ncmVzc2luZyB0aGlzIGRvY3VtZW50IC0gdGhlIHJlc3BvbnNlIGlzIHNp
bXBseSB0aGUgbmVnYXRpdmUgLSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgdGhl
cmUgYXJlIG5vIHN1Y2ggY29uZGl0aW9ucyBpbiB0aGUgcG9pbnQtdG8tcG9pbnQgLSBub24tYnJp
ZGdpbmcgLSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgY29udGV4dCB3aGVyZSB0
aGlzIGRvY3VtZW50IGFwcGxpZXMuPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBub3cs
IG5vdCBzdXJlIHRoZXJlIGlzIGEgdGVjaG5pY2FsICZxdW90O2Zpcm0mcXVvdDsgY29uY2x1c2lv
biBidXQgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyB0aGUgcG9pbnQgb24gPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IHRoZSBldGhlcm5ldCBsYWJlbCBlbmNvZGluZyBhcHBl
YXJzIGFzIGZvbGxvd3Mgc2luY2Ugc28gZmFyIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsg
dGhlcmUgaXMgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IHBvdGVudGlhbCBpbnRl
cmVzdCB0byBrZWVwIHRoZSBsYWJlbCBmb3IgZXRoZXJuZXQgZ2VuZXJpYyA8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mZ3Q7IGVub3VnaCBhbmQgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAm
Z3Q7IGRlZHVjZSBpdHMgaW50ZXJwcmV0YXRpb24gZnJvbSB0eXBlIG9mIGxpbmsgb3ZlciB3aGlj
aCB0aGUgbGFiZWwgaXMgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IHVzZWQgYW5k
IGludGVwcmVldCBpdHMgdmFsdWUgYWNjb3JkaW5nIHRvIHRoZSA8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7IHRyYWZmaWNfcGFyYW1ldGVycyBhbmQgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyAmZ3Q7IHByb3Bvc2UgYXNzb2NpYXRpb25zIHRvIGNvdmVyIGNhc2VzIHN1Y2ggYXMgY2Fz
ZSAyIG9mIEFwcGVuZGl4IEEgb2YgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7ICZs
dDtkcmFmdC1wd2UzLWV0aGVybmV0LWVuY2FwLTA4LnR4dCZndDsgbWVjaGFuaXNtcyB0aGF0IGlz
IGFsc28gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBhcHBsaWNhYmxlIDwvRk9OVD48QlI+
PEZPTlQgU0laRT00PiZndDsgJmd0OyB0byBvdGhlciB0dW5uZWxpbmcgdGVjaG5vbG9neSBzaW5j
ZSB0aGlzIG1lY2hhbmlzbSBpcyBvcnRob2dvbmFsIHRvIDwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZndDsgJmd0OyB0aGUgdXNlIG9mIFBXJ3MgaWYgcmVxdWlyZWQgKGV4YW1wbGUgYmVpbmcgRXRo
ZXJuZXQgb3ZlciA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IFNESC9PVEgsIGZvciA8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgaW5zdGFuY2UpOyBob3dldmVyLCBpZiB0aGVz
ZSBhcmUgdGhlIG9ubHkgYXNzb2NpYXRpb25zIHdlIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZn
dDsgc2VlIHJlbGV2YW50IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBhcyBwYXJ0
IG9mIHRoaXMgZG9jdW1lbnQgdGhlbiB3ZSB3b3VsZCBmYWxsIGJhY2sgb24gdGhlIGV4aXN0aW5n
IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBlbmNvZGluZyB3aXRoIHBvdGVudGlh
bCBlbmhhbmNlbWVudCBpZiBzbyByZXF1aXJlZCAtPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05U
PjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsg
Jmd0OyB0byBjb21lIHRvIHRoZSBwb2ludCBvZiB0aGUgYXJ0aWN1bGF0aW9uIHRoZSAtIGdlbmVy
aWMgLSByZXNwb25zZSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgaG9sZHMgaW4g
b25lIGxpbmU6IGl0IGFydGljdWxhdGVzIEdNUExTIHNpZ25hbGluZyBmb3IgTDJTQyBMU1BzPC9G
T05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IChub3Rl
OiB0aGUgbGF0dGVyIGhhcyBiZWVuIGludHJvZHVjZWQgaW4gUkZDIDM5NDUsIFJGQyAzNDcxLCBS
RkM8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsg
MzQ3MykgLSB0aGUgbW90aXZhdGlvbnMgYXJlIGRldGFpbGVkIGFzIHBhcnQgb2YgdGhlIGludHJv
ZHVjdGlvbiBvZiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgdGhpcyBkb2N1bWVu
dCAtIGkgY2FuIG5vdCBjb21tZW50IG1vcmUgZnJvbSB5b3VyIGluaXRpYWwgc3RhdGVtZW50IDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBzaW5jZSBub3QgZGV0YWlsZWQgZW5vdWdo
IGZvciBtZSB0byBiZSBtb3JlIHNwZWNpZmljPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0
OyB0aGUgcmVzcG9uc2UgdG8gdGhlIGxhc3QgcXVlc3Rpb24gaXMgcmVsYXRpdmVseSBzaW1wbGUg
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBzaW5jZSB0aGUgYWJvdmUgPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IG1lbnRpb25lZCBkbyBub3QgaW5jbHVkZSBhbnkgc3BlY2lm
aWNzIGNvbmNlcm5pbmcgQVRNIG9yIEZSIC0gdGhpcyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4m
Z3Q7ICZndDsgZG9jdW1lbnQgaW50ZW5kcyB0byBjbG9zZSB0aGlzIGdhcCBieSBkZWZpbmluZyBz
cGVjaWZpYyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgVHJhZmZpY19QYXJhbWV0
ZXJzIGZvciB0aGVzZSB0ZWNobm9sb2dpZXMgLSBpcyB0aGVyZSBhbiA8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7IGludGVyZXN0IGZvciA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZn
dDsgZG9pbmcgc286IHJlc3BvbnNlIGlzIHllcyBvdGhlcndpc2UgdGhlIGRvY3VtZW50IHdvdWxk
IG5vdCBoYXZlIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBpbmNsdWRlZCB0aGUg
Y29yci4gZGV0YWlsczwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZndDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgdm9pbGEsIHRoYW5r
cyw8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsg
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IC0gZGltaXRyaS48L0ZPTlQ+PEZPTlQg
U0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyAmcXVvdDtNYWNrLUNyYW5l
LCBULiBCZW5qYW1pbiZxdW90OyAmbHQ7QmVuLk1hY2stQ3JhbmVAdGVsbGFicy5jb20mZ3Q7IFNl
bnQgYnk6IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBvd25lci1jY2FtcEBvcHMu
aWV0Zi5vcmcgMDIvMDMvMjAwNSAxMjoxNiBDU1Q8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAm
Z3Q7IFRvOiAmbHQ7ZHBhcGFkaW1pdHJpb3VAcHNnLmNvbSZndDssIERpbWl0cmkgPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IFBBUEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVM
LCAmcXVvdDtEYXZpZCBBbGxhbiZxdW90OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZn
dDsgJmx0O2RhbGxhbkBub3J0ZWxuZXR3b3Jrcy5jb20mZ3Q7IGNjOiAmcXVvdDtBZHJpYW4gRmFy
cmVsJnF1b3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmx0O2FkcmlhbkBvbGRkb2cu
Y28udWsmZ3Q7LCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgJnF1b3Q7U2hhaHJh
bSBEYXZhcmkmcXVvdDsgJmx0O1NoYWhyYW1fRGF2YXJpQHBtYy1zaWVycmEuY29tJmd0OywgPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmbHQ7Y2NhbXBAb3BzLmlldGYub3JnJmd0OyA8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgYmNjOiBTdWJqZWN0OjwvRk9OVD48Rk9OVCBT
SVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBSRTogTGF5ZXIgMiBTd2l0
Y2hpbmcgQ2FwcyBMU1BzPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgRGltaXRyaSw8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyAmZ3Q7IENhbiB0aGUgb2ZmLWxpbmUgZGlzY3Vzc2lvbiBiZSBzdW1tYXJpemVkIGZvciB0aGUg
YmVuZWZpdCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IG9mIHRob3NlIG9uJm5ic3A7IDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyB0aGUgbGlzdCB3aG8gZGlkIG5vdCBwYXJ0
aWNpcGF0ZT8mbmJzcDsgRm9yIG1lLCB0aGUgZHJhZnQgKGFuZCA8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7IHRoZSBjdXJyZW50IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBk
aXNjdXNzaW9uIG9uIHRoZSBsaXN0KSBoYXZlIG5vdCBjbGVhcmx5IGFydGljdWxhdGVkIHRoZSA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IHByb2JsZW0gYmVpbmcgPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyAmZ3Q7IGFkZHJlc3NlZC4mbmJzcDsgSWYgYSBzdW1tYXJ5IG9mIHRoZSBj
b25jbHVzaW9ucyBvZiB0aGUgb2ZmLWxpbmUgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBk
aXNjdXNzaW9uIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyB3aWxsIGRvIHRoaXMs
IGl0IHdvdWxkIGJlIHVzZWZ1bC48L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IEkgYW0g
YWxzbyBpbnRlcmVzdGVkIHRvIGtub3cgd2hhdCBpcyBsYWNraW5nIGluIHRoZSBjdXJyZW50IDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgR01QTFMgUkZDcyA8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDsgd2l0aCByZXNwZWN0IHRvIEFUTSBhbmQgRnJhbWUgUmVsYXkgc3VwcG9y
dCB0aGF0IG5lY2Vzc2l0YXRlcyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgaW5j
bHVkaW5nIHRoZW0gaW4gdGhpcyBuZXcgZHJhZnQgKHByZXN1bWFibHkgdGhpcyBpcyBhIHBhcnQg
b2YgdGhlIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBwcm9ibGVtIHRvIGJlIHNv
bHZlZCkuPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAm
Z3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBSZWdhcmRzLCBCZW48L0ZPTlQ+
PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0
OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogb3duZXItY2NhbXBAb3BzLmll
dGYub3JnIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgWzwvRk9OVD48Rk9O
VCBTSVpFPTQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0
Zi5vcmc+bWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvQT48L1U+PC9GT05UPjxGT05U
IFNJWkU9NCBDT0xPUj1CTEFDSz5dIE9uPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBC
ZWhhbGY8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZn
dDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBPZiBkaW1pdHJpIHBhcGFk
aW1pdHJpb3UgU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjcsIDIwMDUgNjozNSBQTTwvRk9OVD48
Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgVG86IERh
dmlkIEFsbGFuIENjOiAnQWRyaWFuIEZhcnJlbCc7ICdTaGFocmFtIERhdmFyaSc7PC9GT05UPjxG
T05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBjY2FtcEBv
cHMuaWV0Zi5vcmcgU3ViamVjdDogUmU6IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQczwvRk9O
VD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBkYXZlIC0gdGhlcmUgd2FzIGEgbGVu
Z3RoeSBvZmYtbGluZSBkaXNjdXNzaW9uIHN1Z2dlc3RlZCBieSB0aGUgPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBjaGFpcnMgaW50ZW5kZWQgdG8gZXhwbGFpbiB5b3UgdGhl
IHNjb3BlIG9mIHRoZSBkcmFmdCBhbmQgaXRzIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsg
Jmd0OyZndDsgcmVsYXRpb3NoaXA8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IHdpdGg8
L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyB0aGUgZXRoZXJuZXQgZGF0YSBwbGFu
ZSAoYWZ0ZXIgdGhlIHF1ZXN0aW9uIHlvdSByYWlzZWQgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyBkdXJpbmcgdGhlIGYyZiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7
IG1lZXRpbmcpIC0gdGhpcyBoYXMgYmVlbiBkb25lIGFuZCB3ZSBoYXZlIGV4cGxhaW5lZCAodmlh
IGEgbGVuZ3RoeSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IGV4Y2hhbmdl
IG9mIGUtbWFpbHMpIHRoYXQgdGhpcyBkb2N1bWVudCBhbmQgc28gdGhlIHVzZSBvZiBnbXBscyB0
byA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IGNvbnRyb2wgZXRoZXJuZXQg
ZnJhbWUgZmxvd3MsIGlzIG5vdCB0YXJnZXRpbmcgY29udHJvbCBvZiBicmlkZ2VkIDwvRk9OVD48
QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgZXRoZXJuZXQgZW52aXJvbm1lbnRzIC0gaWYg
dGhpcyBpcyBub3QgY2xlYXIgZnJvbSB0aGUgY3VycmVudCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7ICZndDsmZ3Q7IGRvY3VtZW50IGludHJvZHVjdGlvbiB3ZSB3b3VsZCBoYXZlIGFsc28g
dG8gd29yayBvbiB0aGlzIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgcGFydCBvZiB0aGUg
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBkb2N1bWVudCAtIHRoZXJlZm9y
ZSwgdGhlIGJlbG93IHJlZmVyZW5jZSB0byBNU1RQIGlzIG5vdCBpbiB0aGUgPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBjdXJyZW50IHNjb3BlOyBvbiB0aGUgb3RoZXIgc2lk
ZSwgdGhlIHVzZSBvZiB0aGUgdGVybSAmcXVvdDtWTEFOIGxhYmVsJnF1b3Q7IDwvRk9OVD48QlI+
PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgaGFzIGNyZWF0ZWQgc29tZSBjb25mdXNpb247IHRo
ZXJlZm9yZSwgaW4gYSBuZXh0IHJlbGVhc2UgaSB3aWxsIDwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZndDsgJmd0OyZndDsgc2ltcGx5IHJlZmVyIHRvIGE8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyAmZ3Q7ICZxdW90O2xhYmVsJnF1b3Q7PC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZn
dDsgb2YgMzIgYml0cyAodW5zdHJ1Y3R1cmVkKSBiZWNhdXNlIHRoZSBpbnRlbnRpb24gd2FzIChh
bmQgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBzdGlsbCBpcykgdG8gPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBmaW5kIGFuIGVhc3kgd2F5IHRvIG1hcCB0aGUgY29u
dHJvbCBvZiB0aGUgZXRoZXJuZXQgZnJhbWUgZmxvd3Mgb248L0ZPTlQ+PEZPTlQgU0laRT01PiA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyAmZ3Q7IGVhY2g8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBkZXZpY2Ug
dGhleSB0cmF2ZXJzZXMgd2l0aG91dCBtYWtpbmcgYW55IGFzc3VtcHRpb24gb24gaG93IDwvRk9O
VD48QlI+PEZPTlQgU0laRT00PiZndDsgdGhpcyBmbG93PC9GT05UPjxGT05UIFNJWkU9NT4gPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZn
dDsgJmd0OyBpczwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZn
dDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IHByb2Nlc3NlZCBp
bnNpZGUgZWFjaCBub2RlIGF0IHRoZSBkYXRhIHBsYW5lIGxldmVsIChub3RlOiBvbiBsYWJlbDwv
Rk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsg
dmFsdWVzLCBSRkMgMzk0NiB0b29rIGFuIGVxdWl2YWxlbnQgYXBwcm9hY2ggLSBmb3IgY2lyY3Vp
dHMgLSB3aGVyZTwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZn
dDsgJmd0OyZndDsmbmJzcDsgc29uZXQvc2RoIG11bHRpcGxleGluZyBzdHJ1Y3R1cmVzIGhhdmUg
YmVlbiB1c2VkIHRvIGNyZWF0ZSB1bmlxdWUgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAm
Z3Q7Jmd0OyBtdWx0aXBsZXggZW50cnkgbmFtZXMgaS5lLiBsYWJlbHMgLSB0aGlzIGNvbmNlcHQg
aXMgaGVyZSBhcHBsaWVkPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQ+Jmd0OyAmZ3Q7Jmd0OyBmb3IgJnF1b3Q7dmlydHVhbCZxdW90OyBjaXJjdWl0cyksIHNvLCBp
ZiB0aGUgd29ya2luZyBncm91cCBpcyB3aWxsaW5nIHRvPC9GT05UPjxGT05UIFNJWkU9NT4gPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBlbnRlciBpbnRvPC9GT05UPjxGT05U
IFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiZndDsgJmd0OyBhPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsg
ZGF0YSBwbGFuZSBvcmllbnRlZCBkaXNjdXNzaW9uIHRvIGNsYXJpZnkgdGhlIGJlaGF2aW91cihz
KSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IG9udG8gd2hpY2ggPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyB0aGUgcHJlc2VudCBhcHByb2FjaCB3b3VsZCBiZSBwb3Rl
bnRpYWxseSBhcHBsaWNhYmxlIHRoaXMgaXMgZmluZSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4m
Z3Q7ICZndDsmZ3Q7IHdpdGggbWUgYXMgbG9uZyBhcyB3ZSBhcmUgd2l0aGluIHRoZSBzY29wZSBv
ZiB0aGUgaW5pdGlhbCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IG1vdGl2YXRpb25zPC9G
T05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IHRoYW5rcywgLSBkaW1pdHJpLjwv
Rk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsg
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBEYXZpZCBBbGxhbiB3cm90ZTo8
L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7
IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsmZ3Q7IEhpIEFkcmlhbjo8L0ZP
TlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0
OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0OyBZb3VyIHN1Z2dlc3Rp
b24gaXMgaW4gYSB3YXkgcmVhc29uYWJsZSBidXQgd2l0aCB0aGUgY2F2ZWF0IHRoYXQgaW48L0ZP
TlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05U
PjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IElFRUU8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyAmZ3Q7Jmd0OyZndDsgdGVybXMsIGEgYnJpZGdpbmcgdG9wb2xvZ3kgaXMgY3VycmVudGx5IGFs
bCBWTEFOcyAoODAyLjFRIHNpbmdsZTwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiZndDsgJmd0OyZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7
Jmd0OyBzcGFubmluZzwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZndDsgJmd0OyZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZndDsg
dHJlZSkgb3IgcGFydGl0aW9uZWQgaW50byBzcGVjaWZpYyByYW5nZXMgKEkgYmVsaWV2ZSA2NCBp
biA4MDIuMXM8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7
ICZndDsmZ3Q7Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IDwvRk9O
VD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgYWx0aG91Z2ggSTwvRk9OVD48Rk9OVCBT
SVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZndDsgZG8gbm90IGNsYWltIHRvIGJlIGFuIGV4cGVy
dCkuPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7
Jmd0OyZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZndDsgSWYgdGhl
IFBFcyB3ZXJlIHRvIGltcGxlbWVudCBhIGJyaWRnZSBmdW5jdGlvbiBhbmQgd2Ugd2VyZSB1c2lu
ZzwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgR01QTFM8L0ZPTlQ+PEZPTlQgU0laRT01
PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQ+Jmd0OyAmZ3Q7Jmd0OyB0bzwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQg
U0laRT00PiZndDsgJmd0OyZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0
OyZndDsgaW50ZXJjb25uZWN0IHRoZW0sIHRoZW4gdGhlIGNvbnRyb2wgcGxhbmUgc2hvdWxkIGJl
IGlkZW50aWZ5aW5nPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBlaXRoZXI8L0ZPTlQ+
PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyBhbGw8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZndDsgJmd0OyZndDsmZ3Q7IFZMQU5zIChzaW5nbGUgc3Bhbm5pbmcgdHJlZSwgd2hpY2ggSSBi
ZWxlaXZlIHRoZSBkcmFmdCBjb3ZlcnMgYnk8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsg
Jmd0OyZndDsgcmVmZXJyaW5nPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7
Jmd0OyBzaW1wbHkgdG8gRXRoZXJuZXQgcG9ydCkgb3IgYSBWTEFOIHJhbmdlIHRvIGJlIGFzc29j
aWF0ZWQgd2l0aCB0aGU8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IExTUDwvRk9OVD48
Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0OyBjb25zaXN0ZW50IHdpdGggODAyLjFzIGlm
IGl0IGlzIHRvIG9wZXJhdGUgdG8gaW50ZXJjb25uZWN0IGJyaWRnZXM8L0ZPTlQ+PEZPTlQgU0la
RT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IDwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiZndDsgJmd0OyZndDsgZGVmaW5lZDwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9O
VD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyAmZ3Q7Jmd0OyZndDsgYnkgdGhlIElFRUUuLi48L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0OyBJIHN1c3BlY3QgYXNzdW1pbmcgYW55IG90aGVyIGJlaGF2
aW9yIChlLmcuIExTUCBmb3Igc2luZ2xlIFZMQU48L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0OyB0YWcpPC9GT05UPjxGT05UIFNJWkU9
NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyA8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7IHdvdWxkPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7
ICZndDsmZ3Q7Jmd0OyBnbyBvdXRzaWRlIHRoZSBib3VuZGFyeSBvZiB3aGF0IGlzIGN1cnJlbnRs
eSBkZWZpbmVkLi4uc28gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBhbGlnbm1lbnQ8L0ZP
TlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05U
PjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IHdpdGg8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyAmZ3Q7Jmd0OyZndDsgODAyLjFzIElNTyB3b3VsZCBiZSBhIG1pbmltdW0gcmVxdWlyZW1lbnQg
aWYgd2UgYXJlIHRvIGNvbnNpZGVyPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBjYXJy
eWluZzwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0
OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0OyBWTEFOIGluZm9ybWF0
aW9uIGluIEdNUExTIHNpZ25hbGxpbmcuLi4uPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyAmZ3Q7Jmd0OyZndDsgY2hlZXJzIERhdmU8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7ICZndDsmZ3Q7Jmd0OyBZb3Ugd3JvdGUuLi4uPC9GT05UPjxGT05UIFNJWkU9NT4gPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZndDsgPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7
Jmd0OyZndDsmZ3Q7IEhpLDwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0la
RT00PiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZn
dDsmZ3Q7Jmd0OyZndDsgVGhlIGF1dGhvcnMgb2YgdGhlIGRyYWZ0IG1pZ2h0IGxpa2UgdG8gY2xh
cmlmeSBmb3IgdGhlIGxpc3Q8L0ZPTlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZXhhY3RseSB3aGF0IGRhdGEgcGxhbmUgb3BlcmF0
aW9ucyB0aGV5IGFyZSBzdWdnZXN0aW5nLiBUbyBtZSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4m
Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgaXQgc2VlbXMgcG9zc2libGUgdGhhdCB0aGUgZHJhZnQgaXMg
cHJvcG9zaW5nIFZMQU4gSUQgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZn
dDsmZ3Q7ICpzd2FwcGluZyouIEJ1dCBhbiBhbHRlcm5hdGl2ZSBpcyB0aGF0IHRoZSBWTEFOIElE
IGlzIHVzZWQgYXMgYTwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBsYWJlbCwgYnV0IHRoYXQgdGhlIHNhbWUgbGFiZWwgaXMg
dXNlZCBmb3IgdGhlIGZ1bGwgbGVuZ3RoIG9mPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBMU1AuPC9GT05UPjxGT05U
IFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBBZHJpYW48L0ZPTlQ+
PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0OyA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0OyA8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZn
dDsmZ3Q7Jmd0OyAuPC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyAmZ3Q7Jmd0OyZndDsgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9O
VD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gVGhlIDwvRk9OVD48QlI+PEZPTlQgU0la
RT00PiZndDsgJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBi
ZSBwcml2aWxlZ2VkIGFuZCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgY29uZmlk
ZW50aWFsIGFuZCBwcm90ZWN0ZWQgZnJvbSBkaXNjbG9zdXJlLiBJZiB0aGUgcmVhZGVyIG9mIHRo
aXMgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IG1lc3NhZ2UgaXMgbm90IHRoZSBp
bnRlbmRlZCByZWNpcGllbnQsIG9yIGFuIGVtcGxveWVlIG9yIGFnZW50IDwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiZndDsgJmd0OyByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0aGlzIG1lc3Nh
Z2UgdG8gdGhlIGludGVuZGVkIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgcmVjaXBpZW50
LCB5b3UgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IGFyZSBoZXJlYnkgbm90aWZp
ZWQgdGhhdCBhbnkgcmVwcm9kdWN0aW9uLCBkaXNzZW1pbmF0aW9uIG9yIDwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiZndDsgJmd0OyBkaXN0cmlidXRpb24gb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlz
IHN0cmljdGx5IHByb2hpYml0ZWQuIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgSWYgeW91
IGhhdmUgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IHJlY2VpdmVkIHRoaXMgY29t
bXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyA8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7IGltbWVkaWF0ZWx5IGJ5IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0
OyByZXBseWluZyB0byB0aGUgbWVzc2FnZSBhbmQgZGVsZXRpbmcgaXQgZnJvbSB5b3VyIGNvbXB1
dGVyLiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IFRoYW5rIHlvdS4gPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IFRlbGxhYnMgPT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9GT05UPjxGT05UIFNJWkU9NT4gPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZn
dDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IDwvRk9OVD48QlI+PEZPTlQgU0la
RT00PiZndDsgPC9GT05UPjwvUD4=



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 19:05:07 +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: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 13:04:44 -0600
Message-ID: <[e-mail]>
Thread-Topic: Layer 2 Switching Caps LSPs
Thread-Index: AcUK5kOfJmh10UONQPWOtL0N72g4NwABclVw
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: <[e-mail]>
Cc: "Shahram Davari" <[e-mail]>, <[e-mail]>, "David Allan" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>

Dimitri,

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


Regards,
Ben

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Friday, February 04, 2005 12:21 PM
> To: Mack-Crane, T. Benjamin
> Cc: [e-mail]; Shahram Davari;
> [e-mail]; David Allan; Adrian Farrel; [e-mail]
> Subject: RE: Layer 2 Switching Caps LSPs
>=20
>=20
> ben,
>=20
> > Regarding your statement ?you have to decouple the notion of
ethernet
> with
> > bridging?
>=20
> -> i did mention this to clearly distinguish
>    1. Ethernet 802.3
>    2. Bridging
>    3. MAC learning
>=20
>    to lead to the example where the Ethernet term is mentioned (take
for
> inst.
>    the ethernet port mode of some of this WG RFCs), this by
referencing
> only
>    1) but not 2) and 3)
>=20
> > Forwarding of Ethernet frames IS bridging (as defined by the IEEE)
and a
> lot > of work has gone into defining the forwarding behavior of
bridges.
> Are you > proposing to define a new form of Ethernet forwarding
outside of
> the IEEE?  > This seems like a bad idea.
>=20
> -> for the ethernet port mode (nothing new here, the whole flow
entering
> the
>    incoming port is inserted into the outgoing port) for the other
mode,
> it
>    additionally allows for distinguishing the flows (entering a port)
> based
>    on the VLAN ID (in the point-to-point context that we are
discussing
> here)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: Fri, 04 Feb 2005 19:05:05 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 11:04:53 -0800 
MIME-Version: 1.0
Content-Type: text/plain

Dimitri,

 
> I think we have a disconnect here. Could you please explain 
> how you could
> reuse the VLAN IDs in a single switch for different LSPs?
> 
> -> the port scopes their usage, incoming LSP_1 is associated to frames
> flowing with VLAN_1 through port_8 is distinct from LSP_2 
> associated to
> frames flowing with VLAN_1 through port_2 (on the same node)
> 

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

-Shahram



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 19:01:37 +0000
To: Shahram Davari <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
MIME-Version: 1.0
Date: Fri, 4 Feb 2005 20:01:10 +0100
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

sharam

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

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

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

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






Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 18:56:34 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, David Allan <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 10:55:56 -0800 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50AEA.9071E318"

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_01C50AEA.9071E318
Content-Type: text/plain;
	charset="iso-8859-1"

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

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



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

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

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

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




Dimitri: 
<snipped> 
 (but 
> also keep in mind that there are two levels of VLANs defined today so 
> further refinment is still possible) and with 16 ports you would have 
> 64k LSPs not that bad for an unscalable solution ;-) 

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

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

rgds 
Dave 

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


------_=_NextPart_001_01C50AEA.9071E318
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.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=733415118-04022005><FONT face=Arial color=#0000ff 
size=2>Dimitri,</FONT></SPAN></DIV>
<DIV><SPAN class=733415118-04022005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=733415118-04022005><FONT face=Arial color=#0000ff size=2>Ho do 
you achieve the 64K? Are you planning to reuse the VLAN-ID in different ports 
for different LSPs?</FONT></SPAN></DIV>
<DIV><SPAN class=733415118-04022005><FONT face=Arial color=#0000ff size=2>If so 
your proposal is broken, because VLAN IDs don't have local significance, rather 
they have network-wide </FONT></SPAN></DIV>
<DIV><SPAN class=733415118-04022005><FONT face=Arial color=#0000ff 
size=2>significance and meaning. So if&nbsp; 2 of these LSPs (having the same 
VLAN ID) pass through the same link, they would be merged.</FONT></SPAN></DIV>
<DIV><SPAN class=733415118-04022005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=733415118-04022005><FONT face=Arial color=#0000ff 
size=2>-Shahram</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> 
  [e-mail] 
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, February 04, 
  2005 1:34 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B> '[e-mail]'; 
  '[e-mail]'; Shahram Davari; Mack-Crane, T. Benjamin; 
  David Allan; Adrian Farrel; [e-mail]<BR><B>Subject:</B> RE: Layer 2 
  Switching Caps LSPs<BR><BR></FONT></DIV>
  <P>dave - your response is "you don't think refinment would be possible" for a 
  reason that escapes me since the document does not define control of provider 
  bridges and as i do not think i have mentioned the "snooping" operation you 
  are describing here below - you are more creative than i do ;-)</P>
  <P>note: this said it does not change the numbers provided here below - and i 
  can live with 64k LSPs (at least in a first phase) <BR><BR><FONT 
  size=2><B>"David Allan" &lt;[e-mail]&gt;</B></FONT><BR><FONT 
  size=2>02/04/2005 09:44 EST</FONT><BR><BR><FONT size=2>To:</FONT> <FONT 
  size=2>"'[e-mail]'" &lt;[e-mail]&gt;, Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari 
  &lt;[e-mail]&gt;</FONT><BR><FONT size=2>cc:</FONT> <FONT 
  size=2>"Mack-Crane, T. Benjamin" &lt;[e-mail]&gt;, David 
  Allan &lt;[e-mail]&gt;, Adrian Farrel 
  &lt;[e-mail]&gt;, [e-mail]</FONT><BR><FONT 
  size=2>bcc:</FONT> <BR><FONT size=2>Subject:</FONT> <FONT size=2>RE: Layer 2 
  Switching Caps LSPs</FONT><BR><BR><BR></P>
  <P>Dimitri:<FONT size=4> </FONT><BR>&lt;snipped&gt;<FONT size=4> 
  </FONT><BR>&nbsp;(but <BR>&gt; also keep in mind that there are two levels of 
  VLANs defined today so <BR>&gt; further refinment is still possible) and with 
  16 ports you would have <BR>&gt; 64k LSPs not that bad for an unscalable 
  solution ;-)<FONT size=4> </FONT><BR><BR>Suggesting snooping a 802.1ad VLAN 
  stack to forward on the basis of more than one tag is more creative abuse of 
  existing standards. You cannot preserve the value and simplicity of Ethernet 
  if you insist on re-inventing it...A provider bridge forwards on the basis to 
  S-tag and MAC address. The C-tag has no significance and we would be foolish 
  to pursue a path whereby it does.<BR><BR>MPLS devices (all disucssion of ECMP 
  aside) only forward on the basis of the top label.<FONT size=4> 
  </FONT><BR><BR>rgds<FONT size=4> </FONT><BR>Dave<FONT size=4> 
  </FONT><BR><BR>&gt; <BR>&gt; note: i have explained in a previous mail where 
  use of PW makes more <BR>&gt; sense and where it does less, and where it does 
  simply not<FONT size=4> </FONT><BR>&gt; <BR>&gt; Shahram Davari wrote:<FONT 
  size=4> </FONT><BR>&gt; &gt; Dimitri,<FONT size=4> </FONT><BR>&gt; &gt; 
  <BR>&gt; &gt; I have another question. As you know there are only 4094 VLANs 
  (12 <BR>&gt; &gt; bit). This means only 4094 P2P connection could be setup 
  <BR>&gt; using GMPLS. <BR>&gt; &gt; Since this is not scalable, presumably you 
  need a <BR>&gt; multiplexing label <BR>&gt; &gt; (such as MPLS or another VLAN 
  tag), and its associated signaling <BR>&gt; &gt; between two edges of the 
  network. So why not use PW and be <BR>&gt; done with <BR>&gt; &gt; it.<FONT 
  size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; -Shahram<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt; -----Original Message----- From: 
  [e-mail] <BR>&gt; &gt; [<FONT color=blue><U><A 
  href="mailto:[e-mail]">mailto:[e-mail]</A></U></FONT><FONT 
  color=black>]On Behalf Of Shahram Davari Sent: <BR>&gt; &gt; Thursday, 
  February 03, 2005 6:19 PM To: <BR>&gt; &gt; '[e-mail]' 
  Cc: Mack-Crane, T. Benjamin; <BR>&gt; &gt; [e-mail]; David 
  Allan; Adrian Farrel; <BR>&gt; [e-mail] <BR>&gt; &gt; Subject: RE: 
  Layer 2 Switching Caps LSPs</FONT><FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; 
  &gt; <BR>&gt; &gt; Hi Dimitri,<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; 
  Thanks for your response. Please see my comments in-line.<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt; -Shahram<FONT size=4> </FONT><BR>&gt; &gt; 
  <BR>&gt; &gt; -----Original Message----- From: 
  [e-mail] <BR>&gt; &gt; [<FONT color=blue><U><A 
  href="mailto:[e-mail]">mailto:[e-mail]</A></U></FONT><FONT 
  color=black>] Sent: Thursday, <BR>&gt; February 03, <BR>&gt; &gt; 2005 5:31 PM 
  To: Shahram Davari Cc: <BR>&gt; &gt; '[e-mail]'; 
  Mack-Crane, T. Benjamin; <BR>&gt; &gt; [e-mail]; David Allan; 
  Adrian Farrel; <BR>&gt; [e-mail] <BR>&gt; &gt; Subject: RE: Layer 2 
  Switching Caps LSPs</FONT><FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; 
  <BR>&gt; &gt; <BR>&gt; &gt; sharam, the first issue is that you have to 
  decouple the notion of <BR>&gt; &gt; ethernet with bridging,<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt; Ethernet networks have 3 main layers:<FONT 
  size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; 1) PHY = 10/100/1G/10G as explained 
  in 802.3,<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; 2) MAC = 802.3<FONT 
  size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; 3) Bridging = 802.1D<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt; Without Bridging layer your device can only 
  have a single port. <BR>&gt; &gt; Example is the Ethernet port of your desktop 
  computer. Therefore if <BR>&gt; &gt; you want to build an Ethernet network, 
  you need bridging layer.<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; 
  <BR>&gt; &gt; <BR>&gt; &gt; the second is that this configuration operation 
  can be automated -<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; But after 
  you have configured your connections (aka VLAN <BR>&gt; ports), then <BR>&gt; 
  &gt; there is nothing left for GMPS to do. Or are you saying <BR>&gt; that the 
  GMPLS <BR>&gt; &gt; will do the configuration?<FONT size=4> </FONT><BR>&gt; 
  &gt; <BR>&gt; &gt; however the interesting point you brought in the loop of 
  discussion <BR>&gt; &gt; here is "applicability for shared medium" - isn't the 
  PW <BR>&gt; solution in <BR>&gt; &gt; the same context<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt; No, because in PW, the payload (Ethernet) 
  is encapsulated <BR>&gt; in another <BR>&gt; &gt; layer network (aka MPLS), 
  and is invisible to the <BR>&gt; intermediate nodes. <BR>&gt; &gt; While in 
  your case there is no encapsulation, and all the <BR>&gt; intermediate 
  <BR>&gt; &gt; nodes can act on the MAC and VLAN tag.<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt; as 1) it can not make an automated usage of 
  a "medium" without <BR>&gt; &gt; configuring the tunnels (in our case the 
  tunnels that will <BR>&gt; be used to <BR>&gt; &gt; carry the ethernet payload 
  e.g. SDH, OTH, etc. if not using <BR>&gt; &gt; point-to-point PHY's) but in 
  addition to the present <BR>&gt; solution PW also <BR>&gt; &gt; requires 2) 
  the provisioning of the PW - something not <BR>&gt; needed in the <BR>&gt; 
  &gt; present context as terminating points will be directly <BR>&gt; accessing 
  the <BR>&gt; &gt; "ethernet medium", in brief if such argument is used here it 
  should <BR>&gt; &gt; have also been used in the PW context (if not more 
  intensively)<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; another 
  fundamental point, i am also surprised seeing people <BR>&gt; &gt; supporting 
  MPLS (which brings a connection-oriented <BR>&gt; behaviour to IP) <BR>&gt; 
  &gt; wondering about the suitability of using one of the <BR>&gt; protocol 
  suite of <BR>&gt; &gt; the IETF i.e. GMPLS to bring another (initially) 
  connectionless <BR>&gt; &gt; technology to a "connection-oriented" 
  behaviour<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; I don't argue 
  against bringing connection-oriented behavior to <BR>&gt; &gt; Ethernet. My 
  concern is the method used to do so. if you had done <BR>&gt; &gt; proper 
  Network Interworking (aka, encapsulation or as ITU calls it <BR>&gt; &gt; 
  client/server), then there would not be any problem. <BR>&gt; However, what 
  you <BR>&gt; &gt; are trying to do is to modify Ethernet's control-plane in a 
  <BR>&gt; way that <BR>&gt; &gt; requires modification to its data-plane 
  behavior. As an <BR>&gt; analogy what <BR>&gt; &gt; you are doing is like 
  trying to use the IP address as MPLS tag in <BR>&gt; &gt; order to make IP 
  connection-oriented.<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; In 
  contrast you could easily change ATM's control-plane to GMPLS <BR>&gt; &gt; 
  without any modification to ATM data-plane behavior, because ATM by <BR>&gt; 
  &gt; design is connection-oriented, and the VPI/VCI could easily be <BR>&gt; 
  &gt; interpreted as GMPLS tags.<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; 
  &gt; (even if i do rather prefer the term flow, in the present <BR>&gt; 
  context) at <BR>&gt; &gt; the end the resulting gain is the same for both 
  <BR>&gt; technologies it terms <BR>&gt; &gt; of capabilities as application of 
  constraint-based routing <BR>&gt; principles<FONT size=4> </FONT><BR>&gt; &gt; 
  - is this not at the end what drives mostly all debates in <BR>&gt; the 
  (G)MPLS <BR>&gt; &gt; galaxy beside VPNs and that was underlying incorporation 
  of <BR>&gt; these L2 <BR>&gt; &gt; technologies as part of the GMPLS protocol 
  architecture<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; thanks,<FONT 
  size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; - dimitri.<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; Shahram Davari 
  &lt;[e-mail]&gt; Sent by: <BR>&gt; &gt; 
  [e-mail] 02/03/2005 13:13 PST<FONT size=4> </FONT><BR>&gt; 
  &gt; <BR>&gt; &gt; To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, 
  T. <BR>&gt; &gt; Benjamin" &lt;[e-mail]&gt; cc: 
  [e-mail], <BR>&gt; &gt; David Allan 
  &lt;[e-mail]&gt;, Adrian Farrel <BR>&gt; &gt; 
  &lt;[e-mail]&gt;, [e-mail] bcc: Subject: RE: Layer 2 
  <BR>&gt; &gt; Switching Caps LSPs<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; 
  &gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; Dimitri,<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt; Unfortunately I didn't grasp completely 
  what you are trying <BR>&gt; to convey. <BR>&gt; &gt; But one thing I know for 
  sure, and that is&nbsp; "Ethernet is <BR>&gt; &gt; Connectionless (CLS)" (like 
  IP) and assumes shared medium, <BR>&gt; while GMPLS <BR>&gt; &gt; is 
  connection-oriented (CO) and doesn't work in shared medium. Off <BR>&gt; &gt; 
  course you could always configure and build an Ethernet <BR>&gt; network that 
  <BR>&gt; &gt; looks like it is CO (by configuring a max of 2 ports with the 
  same <BR>&gt; &gt; VLAN ID in each bridge), and by not using any shared 
  <BR>&gt; medium. But then <BR>&gt; &gt; who needs GMPLS, when you already have 
  to configure your network by <BR>&gt; &gt; other means?<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt; -Shahram<FONT size=4> </FONT><BR>&gt; &gt; 
  <BR>&gt; &gt; <BR>&gt; &gt; From: [e-mail] <BR>&gt; 
  &gt; [<FONT color=blue><U><A 
  href="mailto:[e-mail]">mailto:[e-mail]</A></U></FONT><FONT 
  color=black>] Sent: Thursday, <BR>&gt; February 03, <BR>&gt; &gt; 2005 3:07 PM 
  To: Mack-Crane, T. Benjamin Cc: <BR>&gt; [e-mail]; <BR>&gt; &gt; 
  [e-mail]; David Allan; Adrian <BR>&gt; Farrel; Shahram 
  <BR>&gt; &gt; Davari; [e-mail] Subject: RE: Layer 2 Switching Caps 
  LSPs</FONT><FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; 
  <BR>&gt; &gt; ben,<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; the 
  discussion with dave has been reproduced in accelerated on the <BR>&gt; &gt; 
  mailing list - for me it appears that the more "philosophical" <BR>&gt; &gt; 
  conclusion can be positioned by answering to the following question <BR>&gt; 
  &gt; "Was SONET/SDH or lambda switching initially intended to be <BR>&gt; 
  controlled <BR>&gt; &gt; by GMPLS ?" if the response is "No, but nothing 
  prevents to <BR>&gt; do so" the <BR>&gt; &gt; next question is what does 
  prevent from applying GMPLS to other <BR>&gt; &gt; technologies knowing a 
  substantial gain is obtained from its <BR>&gt; &gt; application - in certain 
  conditions - (see motivations as <BR>&gt; part of this <BR>&gt; &gt; 
  introduction for instance) ? key issue being which are these<FONT size=4> 
  </FONT><BR>&gt; &gt; (technical) conditions and are there conditions that 
  would preclude <BR>&gt; &gt; progressing this document - the response is 
  simply the negative - <BR>&gt; &gt; there are no such conditions in the 
  point-to-point - non-bridging - <BR>&gt; &gt; context where this document 
  applies.<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; now, not sure there 
  is a technical "firm" conclusion but <BR>&gt; the point on <BR>&gt; &gt; the 
  ethernet label encoding appears as follows since so far <BR>&gt; there is 
  <BR>&gt; &gt; potential interest to keep the label for ethernet generic 
  <BR>&gt; enough and <BR>&gt; &gt; deduce its interpretation from type of link 
  over which the label is <BR>&gt; &gt; used and intepreet its value according 
  to the <BR>&gt; traffic_parameters and <BR>&gt; &gt; propose associations to 
  cover cases such as case 2 of Appendix A of <BR>&gt; &gt; 
  &lt;draft-pwe3-ethernet-encap-08.txt&gt; mechanisms that is also <BR>&gt; 
  applicable <BR>&gt; &gt; to other tunneling technology since this mechanism is 
  orthogonal to <BR>&gt; &gt; the use of PW's if required (example being 
  Ethernet over <BR>&gt; SDH/OTH, for <BR>&gt; &gt; instance); however, if these 
  are the only associations we <BR>&gt; see relevant <BR>&gt; &gt; as part of 
  this document then we would fall back on the existing <BR>&gt; &gt; encoding 
  with potential enhancement if so required -<FONT size=4> </FONT><BR>&gt; &gt; 
  <BR>&gt; &gt; to come to the point of the articulation the - generic - 
  response <BR>&gt; &gt; holds in one line: it articulates GMPLS signaling for 
  L2SC LSPs<FONT size=4> </FONT><BR>&gt; &gt; (note: the latter has been 
  introduced in RFC 3945, RFC 3471, RFC<FONT size=4> </FONT><BR>&gt; &gt; 3473) 
  - the motivations are detailed as part of the introduction of <BR>&gt; &gt; 
  this document - i can not comment more from your initial statement <BR>&gt; 
  &gt; since not detailed enough for me to be more specific<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt; the response to the last question is 
  relatively simple <BR>&gt; since the above <BR>&gt; &gt; mentioned do not 
  include any specifics concerning ATM or FR - this <BR>&gt; &gt; document 
  intends to close this gap by defining specific <BR>&gt; &gt; 
  Traffic_Parameters for these technologies - is there an <BR>&gt; interest for 
  <BR>&gt; &gt; doing so: response is yes otherwise the document would not have 
  <BR>&gt; &gt; included the corr. details<FONT size=4> </FONT><BR>&gt; &gt; 
  <BR>&gt; &gt; voila, thanks,<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; - 
  dimitri.<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; 
  <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; "Mack-Crane, T. Benjamin" 
  &lt;[e-mail]&gt; Sent by: <BR>&gt; &gt; 
  [e-mail] 02/03/2005 12:16 CST<FONT size=4> </FONT><BR>&gt; 
  &gt; <BR>&gt; &gt; To: &lt;[e-mail]&gt;, Dimitri <BR>&gt; &gt; 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" <BR>&gt; &gt; 
  &lt;[e-mail]&gt; cc: "Adrian Farrel" <BR>&gt; 
  &lt;[e-mail]&gt;, <BR>&gt; &gt; "Shahram Davari" 
  &lt;[e-mail]&gt;, <BR>&gt; &lt;[e-mail]&gt; 
  <BR>&gt; &gt; bcc: Subject:<FONT size=4> </FONT><BR>&gt; &gt; RE: Layer 2 
  Switching Caps LSPs<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; 
  &gt; Dimitri,<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; Can the off-line 
  discussion be summarized for the benefit <BR>&gt; of those on&nbsp; <BR>&gt; 
  &gt; the list who did not participate?&nbsp; For me, the draft (and <BR>&gt; 
  the current <BR>&gt; &gt; discussion on the list) have not clearly articulated 
  the <BR>&gt; problem being <BR>&gt; &gt; addressed.&nbsp; If a summary of the 
  conclusions of the off-line <BR>&gt; discussion <BR>&gt; &gt; will do this, it 
  would be useful.<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; I am also 
  interested to know what is lacking in the current <BR>&gt; GMPLS RFCs <BR>&gt; 
  &gt; with respect to ATM and Frame Relay support that necessitates <BR>&gt; 
  &gt; including them in this new draft (presumably this is a part of the 
  <BR>&gt; &gt; problem to be solved).<FONT size=4> </FONT><BR>&gt; &gt; 
  <BR>&gt; &gt; Regards, Ben<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; 
  <BR>&gt; &gt;&gt; -----Original Message----- From: [e-mail] 
  <BR>&gt; &gt;&gt; [<FONT color=blue><U><A 
  href="mailto:[e-mail]">mailto:[e-mail]</A></U></FONT><FONT 
  color=black>] On</FONT><FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; 
  Behalf<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt;&gt; Of dimitri 
  papadimitriou Sent: Thursday, January 27, 2005 6:35 PM<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt; To: David Allan Cc: 'Adrian Farrel'; 'Shahram 
  Davari';<FONT size=4> </FONT><BR>&gt; &gt;&gt; [e-mail] Subject: Re: 
  Layer 2 Switching Caps LSPs<FONT size=4> </FONT><BR>&gt; &gt;&gt; <BR>&gt; 
  &gt;&gt; dave - there was a lengthy off-line discussion suggested by the 
  <BR>&gt; &gt;&gt; chairs intended to explain you the scope of the draft and 
  its <BR>&gt; &gt;&gt; relatioship<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; 
  &gt; with<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt;&gt; the ethernet 
  data plane (after the question you raised <BR>&gt; during the f2f <BR>&gt; 
  &gt;&gt; meeting) - this has been done and we have explained (via a lengthy 
  <BR>&gt; &gt;&gt; exchange of e-mails) that this document and so the use of 
  gmpls to <BR>&gt; &gt;&gt; control ethernet frame flows, is not targeting 
  control of bridged <BR>&gt; &gt;&gt; ethernet environments - if this is not 
  clear from the current <BR>&gt; &gt;&gt; document introduction we would have 
  also to work on this <BR>&gt; part of the <BR>&gt; &gt;&gt; document - 
  therefore, the below reference to MSTP is not in the <BR>&gt; &gt;&gt; current 
  scope; on the other side, the use of the term "VLAN label" <BR>&gt; &gt;&gt; 
  has created some confusion; therefore, in a next release i will <BR>&gt; 
  &gt;&gt; simply refer to a<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; 
  "label"<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt;&gt; of 32 bits 
  (unstructured) because the intention was (and <BR>&gt; still is) to <BR>&gt; 
  &gt;&gt; find an easy way to map the control of the ethernet frame flows 
  on<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; each<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt;&gt; device they traverses without making 
  any assumption on how <BR>&gt; this flow<FONT size=4> </FONT><BR>&gt; &gt; 
  <BR>&gt; &gt; is<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt;&gt; processed 
  inside each node at the data plane level (note: on label<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt; values, RFC 3946 took an equivalent approach - for 
  circuits - where<FONT size=4> </FONT><BR>&gt; &gt;&gt;&nbsp; sonet/sdh 
  multiplexing structures have been used to create unique <BR>&gt; &gt;&gt; 
  multiplex entry names i.e. labels - this concept is here applied<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt; for "virtual" circuits), so, if the working group is 
  willing to<FONT size=4> </FONT><BR>&gt; &gt;&gt; enter into<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt; a<FONT size=4> </FONT><BR>&gt; &gt; 
  <BR>&gt; &gt;&gt; data plane oriented discussion to clarify the behaviour(s) 
  <BR>&gt; onto which <BR>&gt; &gt;&gt; the present approach would be 
  potentially applicable this is fine <BR>&gt; &gt;&gt; with me as long as we 
  are within the scope of the initial <BR>&gt; motivations<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt; thanks, - dimitri.<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt; David Allan wrote:<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;&gt; Hi Adrian:<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt; Your suggestion is in a way 
  reasonable but with the caveat that in<FONT size=4> </FONT><BR>&gt; &gt; 
  <BR>&gt; &gt; IEEE<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt;&gt;&gt; 
  terms, a bridging topology is currently all VLANs (802.1Q single<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt; spanning<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;&gt; tree) or partitioned into 
  specific ranges (I believe 64 in 802.1s<FONT size=4> </FONT><BR>&gt; 
  &gt;&gt;&gt; <BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt; although I<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;&gt; do not claim to be an 
  expert).<FONT size=4> </FONT><BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt; If 
  the PEs were to implement a bridge function and we were using<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt; GMPLS<FONT size=4> </FONT><BR>&gt; &gt; 
  <BR>&gt; &gt;&gt; to<FONT size=4> </FONT><BR>&gt; &gt;&gt; <BR>&gt; 
  &gt;&gt;&gt; interconnect them, then the control plane should be 
  identifying<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; either<FONT 
  size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt;&gt; all<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;&gt; VLANs (single spanning tree, 
  which I beleive the draft covers by<FONT size=4> </FONT><BR>&gt; &gt;&gt; 
  <BR>&gt; &gt;&gt; referring<FONT size=4> </FONT><BR>&gt; &gt;&gt; <BR>&gt; 
  &gt;&gt;&gt; simply to Ethernet port) or a VLAN range to be associated with 
  the<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; LSP<FONT size=4> 
  </FONT><BR>&gt; &gt; <BR>&gt; &gt;&gt;&gt; consistent with 802.1s if it is to 
  operate to interconnect bridges<FONT size=4> </FONT><BR>&gt; &gt;&gt; <BR>&gt; 
  &gt;&gt; defined<FONT size=4> </FONT><BR>&gt; &gt;&gt; <BR>&gt; &gt;&gt;&gt; 
  by the IEEE...<FONT size=4> </FONT><BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt; 
  I suspect assuming any other behavior (e.g. LSP for single VLAN<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt;&gt; tag)<FONT size=4> </FONT><BR>&gt; &gt;&gt; 
  <BR>&gt; &gt;&gt; would<FONT size=4> </FONT><BR>&gt; &gt;&gt; <BR>&gt; 
  &gt;&gt;&gt; go outside the boundary of what is currently defined...so 
  <BR>&gt; alignment<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; with<FONT 
  size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt;&gt;&gt; 802.1s IMO would be a 
  minimum requirement if we are to consider<FONT size=4> </FONT><BR>&gt; &gt; 
  <BR>&gt; &gt; carrying<FONT size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt;&gt;&gt; 
  VLAN information in GMPLS signalling....<FONT size=4> </FONT><BR>&gt; 
  &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt; cheers Dave<FONT size=4> </FONT><BR>&gt; 
  &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt; You wrote....<FONT size=4> </FONT><BR>&gt; 
  &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;&gt; Hi,<FONT size=4> 
  </FONT><BR>&gt; &gt;&gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt;&gt; The authors of the 
  draft might like to clarify for the list<FONT size=4> </FONT><BR>&gt; 
  &gt;&gt;&gt;&gt; exactly what data plane operations they are suggesting. To me 
  <BR>&gt; &gt;&gt;&gt;&gt; it seems possible that the draft is proposing VLAN 
  ID <BR>&gt; &gt;&gt;&gt;&gt; *swapping*. But an alternative is that the VLAN 
  ID is used as a<FONT size=4> </FONT><BR>&gt; &gt;&gt;&gt;&gt; label, but that 
  the same label is used for the full length of<FONT size=4> </FONT><BR>&gt; 
  &gt;&gt;&gt;&gt; the LSP.<FONT size=4> </FONT><BR>&gt; &gt;&gt;&gt;&gt; 
  <BR>&gt; &gt;&gt;&gt;&gt; Adrian<FONT size=4> </FONT><BR>&gt; &gt;&gt;&gt; 
  <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt;&gt;&gt; .<FONT 
  size=4> </FONT><BR>&gt; &gt;&gt;&gt; <BR>&gt; &gt; <BR>&gt; &gt; 
  ============================================================ The <BR>&gt; &gt; 
  information contained in this message may be privileged and <BR>&gt; &gt; 
  confidential and protected from disclosure. If the reader of this <BR>&gt; 
  &gt; message is not the intended recipient, or an employee or agent <BR>&gt; 
  &gt; responsible for delivering this message to the intended <BR>&gt; 
  recipient, you <BR>&gt; &gt; are hereby notified that any reproduction, 
  dissemination or <BR>&gt; &gt; distribution of this communication is strictly 
  prohibited. <BR>&gt; If you have <BR>&gt; &gt; received this communication in 
  error, please notify us <BR>&gt; immediately by <BR>&gt; &gt; replying to the 
  message and deleting it from your computer. <BR>&gt; Thank you. <BR>&gt; &gt; 
  Tellabs ============================================================<FONT 
  size=4> </FONT><BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; <BR>&gt; 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C50AEA.9071E318--



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 18:34:14 +0000
To: "David Allan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, Shahram Davari <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 19:33:32 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+ZGF2ZSAtIHlvdXIgcmVzcG9uc2UgaXMgJnF1b3Q7eW91IGRvbid0IHRoaW5rIHJlZmlubWVu
dCB3b3VsZCBiZSBwb3NzaWJsZSZxdW90OyBmb3IgYSByZWFzb24gdGhhdCBlc2NhcGVzIG1lIHNp
bmNlIHRoZSBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgY29udHJvbCBvZiBwcm92aWRlciBicmlk
Z2VzIGFuZCBhcyBpIGRvIG5vdCB0aGluayBpIGhhdmUgbWVudGlvbmVkIHRoZSAmcXVvdDtzbm9v
cGluZyZxdW90OyBvcGVyYXRpb24geW91IGFyZSBkZXNjcmliaW5nIGhlcmUgYmVsb3cgLSB5b3Ug
YXJlIG1vcmUgY3JlYXRpdmUgdGhhbiBpIGRvIDstKTwvUD48UD5ub3RlOiB0aGlzIHNhaWQgaXQg
ZG9lcyBub3QgY2hhbmdlIHRoZSBudW1iZXJzIHByb3ZpZGVkIGhlcmUgYmVsb3cgLSBhbmQgaSBj
YW4gbGl2ZSB3aXRoIDY0ayBMU1BzIChhdCBsZWFzdCBpbiBhIGZpcnN0IHBoYXNlKSA8QlI+PEJS
PjxGT05UIFNJWkU9Mj48Qj4mcXVvdDtEYXZpZCBBbGxhbiZxdW90OyAmbHQ7ZGFsbGFuQG5vcnRl
bC5jb20mZ3Q7PC9CPjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjAyLzA0LzIwMDUgMDk6NDQgRVNU
PC9GT05UPjxCUj48QlI+IDxGT05UIFNJWkU9Mj5Ubzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj4mcXVv
dDsnZHBhcGFkaW1pdHJpb3VAcHNnLmNvbScmcXVvdDsgJmx0O2RwYXBhZGltaXRyaW91QHBzZy5j
b20mZ3Q7LCBEaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMLCBTaGFocmFt
IERhdmFyaSAmbHQ7U2hhaHJhbV9EYXZhcmlAcG1jLXNpZXJyYS5jb20mZ3Q7PC9GT05UPjxCUj4g
PEZPTlQgU0laRT0yPmNjOjwvRk9OVD4gPEZPTlQgU0laRT0yPiZxdW90O01hY2stQ3JhbmUsIFQu
IEJlbmphbWluJnF1b3Q7ICZsdDtCZW4uTWFjay1DcmFuZUB0ZWxsYWJzLmNvbSZndDssIERhdmlk
IEFsbGFuICZsdDtkYWxsYW5Abm9ydGVsbmV0d29ya3MuY29tJmd0OywgQWRyaWFuIEZhcnJlbCAm
bHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDssIGNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+
IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5TdWJqZWN0OjwvRk9O
VD4gPEZPTlQgU0laRT0yPlJFOiBMYXllciAyIFN3aXRjaGluZyBDYXBzIExTUHM8L0ZPTlQ+PEJS
PiA8QlI+PEJSPjwvUD48UD5EaW1pdHJpOjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mbHQ7c25p
cHBlZCZndDs8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jm5ic3A7KGJ1dCA8QlI+Jmd0OyBhbHNv
IGtlZXAgaW4gbWluZCB0aGF0IHRoZXJlIGFyZSB0d28gbGV2ZWxzIG9mIFZMQU5zIGRlZmluZWQg
dG9kYXkgc28gPEJSPiZndDsgZnVydGhlciByZWZpbm1lbnQgaXMgc3RpbGwgcG9zc2libGUpIGFu
ZCB3aXRoIDE2IHBvcnRzIHlvdSB3b3VsZCBoYXZlIDxCUj4mZ3Q7IDY0ayBMU1BzIG5vdCB0aGF0
IGJhZCBmb3IgYW4gdW5zY2FsYWJsZSBzb2x1dGlvbiA7LSk8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48
QlI+PEJSPlN1Z2dlc3Rpbmcgc25vb3BpbmcgYSA4MDIuMWFkIFZMQU4gc3RhY2sgdG8gZm9yd2Fy
ZCBvbiB0aGUgYmFzaXMgb2YgbW9yZSB0aGFuIG9uZSB0YWcgaXMgbW9yZSBjcmVhdGl2ZSBhYnVz
ZSBvZiBleGlzdGluZyBzdGFuZGFyZHMuIFlvdSBjYW5ub3QgcHJlc2VydmUgdGhlIHZhbHVlIGFu
ZCBzaW1wbGljaXR5IG9mIEV0aGVybmV0IGlmIHlvdSBpbnNpc3Qgb24gcmUtaW52ZW50aW5nIGl0
Li4uQSBwcm92aWRlciBicmlkZ2UgZm9yd2FyZHMgb24gdGhlIGJhc2lzIHRvIFMtdGFnIGFuZCBN
QUMgYWRkcmVzcy4gVGhlIEMtdGFnIGhhcyBubyBzaWduaWZpY2FuY2UgYW5kIHdlIHdvdWxkIGJl
IGZvb2xpc2ggdG8gcHVyc3VlIGEgcGF0aCB3aGVyZWJ5IGl0IGRvZXMuPEJSPjxCUj5NUExTIGRl
dmljZXMgKGFsbCBkaXN1Y3NzaW9uIG9mIEVDTVAgYXNpZGUpIG9ubHkgZm9yd2FyZCBvbiB0aGUg
YmFzaXMgb2YgdGhlIHRvcCBsYWJlbC48Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+PEJSPnJnZHM8
Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+RGF2ZTxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj48QlI+
Jmd0OyA8QlI+Jmd0OyBub3RlOiBpIGhhdmUgZXhwbGFpbmVkIGluIGEgcHJldmlvdXMgbWFpbCB3
aGVyZSB1c2Ugb2YgUFcgbWFrZXMgbW9yZSA8QlI+Jmd0OyBzZW5zZSBhbmQgd2hlcmUgaXQgZG9l
cyBsZXNzLCBhbmQgd2hlcmUgaXQgZG9lcyBzaW1wbHkgbm90PEZPTlQgU0laRT00PiA8L0ZPTlQ+
PEJSPiZndDsgPEJSPiZndDsgU2hhaHJhbSBEYXZhcmkgd3JvdGU6PEZPTlQgU0laRT00PiA8L0ZP
TlQ+PEJSPiZndDsgJmd0OyBEaW1pdHJpLDxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZn
dDsgPEJSPiZndDsgJmd0OyBJIGhhdmUgYW5vdGhlciBxdWVzdGlvbi4gQXMgeW91IGtub3cgdGhl
cmUgYXJlIG9ubHkgNDA5NCBWTEFOcyAoMTIgPEJSPiZndDsgJmd0OyBiaXQpLiBUaGlzIG1lYW5z
IG9ubHkgNDA5NCBQMlAgY29ubmVjdGlvbiBjb3VsZCBiZSBzZXR1cCA8QlI+Jmd0OyB1c2luZyBH
TVBMUy4gPEJSPiZndDsgJmd0OyBTaW5jZSB0aGlzIGlzIG5vdCBzY2FsYWJsZSwgcHJlc3VtYWJs
eSB5b3UgbmVlZCBhIDxCUj4mZ3Q7IG11bHRpcGxleGluZyBsYWJlbCA8QlI+Jmd0OyAmZ3Q7IChz
dWNoIGFzIE1QTFMgb3IgYW5vdGhlciBWTEFOIHRhZyksIGFuZCBpdHMgYXNzb2NpYXRlZCBzaWdu
YWxpbmcgPEJSPiZndDsgJmd0OyBiZXR3ZWVuIHR3byBlZGdlcyBvZiB0aGUgbmV0d29yay4gU28g
d2h5IG5vdCB1c2UgUFcgYW5kIGJlIDxCUj4mZ3Q7IGRvbmUgd2l0aCA8QlI+Jmd0OyAmZ3Q7IGl0
LjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAtU2hhaHJh
bTxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcgPEJSPiZn
dDsgJmd0OyBbPEZPTlQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpvd25lci1jY2FtcEBv
cHMuaWV0Zi5vcmc+bWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvQT48L1U+PC9GT05U
PjxGT05UIENPTE9SPUJMQUNLPl1PbiBCZWhhbGYgT2YgU2hhaHJhbSBEYXZhcmkgU2VudDogPEJS
PiZndDsgJmd0OyBUaHVyc2RheSwgRmVicnVhcnkgMDMsIDIwMDUgNjoxOSBQTSBUbzogPEJSPiZn
dDsgJmd0OyAnRGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUnIENjOiBNYWNrLUNyYW5l
LCBULiBCZW5qYW1pbjsgPEJSPiZndDsgJmd0OyBkcGFwYWRpbWl0cmlvdUBwc2cuY29tOyBEYXZp
ZCBBbGxhbjsgQWRyaWFuIEZhcnJlbDsgPEJSPiZndDsgY2NhbXBAb3BzLmlldGYub3JnIDxCUj4m
Z3Q7ICZndDsgU3ViamVjdDogUkU6IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQczwvRk9OVD48
Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsg
Jmd0OyBIaSBEaW1pdHJpLDxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZn
dDsgJmd0OyBUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UuIFBsZWFzZSBzZWUgbXkgY29tbWVudHMg
aW4tbGluZS48Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsg
LVNoYWhyYW08Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsg
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogRGltaXRyaS5QYXBhZGltaXRyaW91QGFs
Y2F0ZWwuYmUgPEJSPiZndDsgJmd0OyBbPEZPTlQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0
bzpEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZT5tYWlsdG86RGltaXRyaS5QYXBhZGlt
aXRyaW91QGFsY2F0ZWwuYmU8L0E+PC9VPjwvRk9OVD48Rk9OVCBDT0xPUj1CTEFDSz5dIFNlbnQ6
IFRodXJzZGF5LCA8QlI+Jmd0OyBGZWJydWFyeSAwMywgPEJSPiZndDsgJmd0OyAyMDA1IDU6MzEg
UE0gVG86IFNoYWhyYW0gRGF2YXJpIENjOiA8QlI+Jmd0OyAmZ3Q7ICdEaW1pdHJpLlBhcGFkaW1p
dHJpb3VAYWxjYXRlbC5iZSc7IE1hY2stQ3JhbmUsIFQuIEJlbmphbWluOyA8QlI+Jmd0OyAmZ3Q7
IGRwYXBhZGltaXRyaW91QHBzZy5jb207IERhdmlkIEFsbGFuOyBBZHJpYW4gRmFycmVsOyA8QlI+
Jmd0OyBjY2FtcEBvcHMuaWV0Zi5vcmcgPEJSPiZndDsgJmd0OyBTdWJqZWN0OiBSRTogTGF5ZXIg
MiBTd2l0Y2hpbmcgQ2FwcyBMU1BzPC9GT05UPjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7
ICZndDsgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgc2hhcmFtLCB0
aGUgZmlyc3QgaXNzdWUgaXMgdGhhdCB5b3UgaGF2ZSB0byBkZWNvdXBsZSB0aGUgbm90aW9uIG9m
IDxCUj4mZ3Q7ICZndDsgZXRoZXJuZXQgd2l0aCBicmlkZ2luZyw8Rk9OVCBTSVpFPTQ+IDwvRk9O
VD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgRXRoZXJuZXQgbmV0d29ya3MgaGF2ZSAzIG1h
aW4gbGF5ZXJzOjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0
OyAxKSBQSFkgPSAxMC8xMDAvMUcvMTBHIGFzIGV4cGxhaW5lZCBpbiA4MDIuMyw8Rk9OVCBTSVpF
PTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgMikgTUFDID0gODAyLjM8Rk9O
VCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgMykgQnJpZGdpbmcg
PSA4MDIuMUQ8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsg
V2l0aG91dCBCcmlkZ2luZyBsYXllciB5b3VyIGRldmljZSBjYW4gb25seSBoYXZlIGEgc2luZ2xl
IHBvcnQuIDxCUj4mZ3Q7ICZndDsgRXhhbXBsZSBpcyB0aGUgRXRoZXJuZXQgcG9ydCBvZiB5b3Vy
IGRlc2t0b3AgY29tcHV0ZXIuIFRoZXJlZm9yZSBpZiA8QlI+Jmd0OyAmZ3Q7IHlvdSB3YW50IHRv
IGJ1aWxkIGFuIEV0aGVybmV0IG5ldHdvcmssIHlvdSBuZWVkIGJyaWRnaW5nIGxheWVyLjxGT05U
IFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7
IDxCUj4mZ3Q7ICZndDsgdGhlIHNlY29uZCBpcyB0aGF0IHRoaXMgY29uZmlndXJhdGlvbiBvcGVy
YXRpb24gY2FuIGJlIGF1dG9tYXRlZCAtPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0
OyA8QlI+Jmd0OyAmZ3Q7IEJ1dCBhZnRlciB5b3UgaGF2ZSBjb25maWd1cmVkIHlvdXIgY29ubmVj
dGlvbnMgKGFrYSBWTEFOIDxCUj4mZ3Q7IHBvcnRzKSwgdGhlbiA8QlI+Jmd0OyAmZ3Q7IHRoZXJl
IGlzIG5vdGhpbmcgbGVmdCBmb3IgR01QUyB0byBkby4gT3IgYXJlIHlvdSBzYXlpbmcgPEJSPiZn
dDsgdGhhdCB0aGUgR01QTFMgPEJSPiZndDsgJmd0OyB3aWxsIGRvIHRoZSBjb25maWd1cmF0aW9u
PzxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBob3dldmVy
IHRoZSBpbnRlcmVzdGluZyBwb2ludCB5b3UgYnJvdWdodCBpbiB0aGUgbG9vcCBvZiBkaXNjdXNz
aW9uIDxCUj4mZ3Q7ICZndDsgaGVyZSBpcyAmcXVvdDthcHBsaWNhYmlsaXR5IGZvciBzaGFyZWQg
bWVkaXVtJnF1b3Q7IC0gaXNuJ3QgdGhlIFBXIDxCUj4mZ3Q7IHNvbHV0aW9uIGluIDxCUj4mZ3Q7
ICZndDsgdGhlIHNhbWUgY29udGV4dDxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsg
PEJSPiZndDsgJmd0OyBObywgYmVjYXVzZSBpbiBQVywgdGhlIHBheWxvYWQgKEV0aGVybmV0KSBp
cyBlbmNhcHN1bGF0ZWQgPEJSPiZndDsgaW4gYW5vdGhlciA8QlI+Jmd0OyAmZ3Q7IGxheWVyIG5l
dHdvcmsgKGFrYSBNUExTKSwgYW5kIGlzIGludmlzaWJsZSB0byB0aGUgPEJSPiZndDsgaW50ZXJt
ZWRpYXRlIG5vZGVzLiA8QlI+Jmd0OyAmZ3Q7IFdoaWxlIGluIHlvdXIgY2FzZSB0aGVyZSBpcyBu
byBlbmNhcHN1bGF0aW9uLCBhbmQgYWxsIHRoZSA8QlI+Jmd0OyBpbnRlcm1lZGlhdGUgPEJSPiZn
dDsgJmd0OyBub2RlcyBjYW4gYWN0IG9uIHRoZSBNQUMgYW5kIFZMQU4gdGFnLjxGT05UIFNJWkU9
ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBhcyAxKSBpdCBjYW4gbm90IG1h
a2UgYW4gYXV0b21hdGVkIHVzYWdlIG9mIGEgJnF1b3Q7bWVkaXVtJnF1b3Q7IHdpdGhvdXQgPEJS
PiZndDsgJmd0OyBjb25maWd1cmluZyB0aGUgdHVubmVscyAoaW4gb3VyIGNhc2UgdGhlIHR1bm5l
bHMgdGhhdCB3aWxsIDxCUj4mZ3Q7IGJlIHVzZWQgdG8gPEJSPiZndDsgJmd0OyBjYXJyeSB0aGUg
ZXRoZXJuZXQgcGF5bG9hZCBlLmcuIFNESCwgT1RILCBldGMuIGlmIG5vdCB1c2luZyA8QlI+Jmd0
OyAmZ3Q7IHBvaW50LXRvLXBvaW50IFBIWSdzKSBidXQgaW4gYWRkaXRpb24gdG8gdGhlIHByZXNl
bnQgPEJSPiZndDsgc29sdXRpb24gUFcgYWxzbyA8QlI+Jmd0OyAmZ3Q7IHJlcXVpcmVzIDIpIHRo
ZSBwcm92aXNpb25pbmcgb2YgdGhlIFBXIC0gc29tZXRoaW5nIG5vdCA8QlI+Jmd0OyBuZWVkZWQg
aW4gdGhlIDxCUj4mZ3Q7ICZndDsgcHJlc2VudCBjb250ZXh0IGFzIHRlcm1pbmF0aW5nIHBvaW50
cyB3aWxsIGJlIGRpcmVjdGx5IDxCUj4mZ3Q7IGFjY2Vzc2luZyB0aGUgPEJSPiZndDsgJmd0OyAm
cXVvdDtldGhlcm5ldCBtZWRpdW0mcXVvdDssIGluIGJyaWVmIGlmIHN1Y2ggYXJndW1lbnQgaXMg
dXNlZCBoZXJlIGl0IHNob3VsZCA8QlI+Jmd0OyAmZ3Q7IGhhdmUgYWxzbyBiZWVuIHVzZWQgaW4g
dGhlIFBXIGNvbnRleHQgKGlmIG5vdCBtb3JlIGludGVuc2l2ZWx5KTxGT05UIFNJWkU9ND4gPC9G
T05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBhbm90aGVyIGZ1bmRhbWVudGFsIHBvaW50
LCBpIGFtIGFsc28gc3VycHJpc2VkIHNlZWluZyBwZW9wbGUgPEJSPiZndDsgJmd0OyBzdXBwb3J0
aW5nIE1QTFMgKHdoaWNoIGJyaW5ncyBhIGNvbm5lY3Rpb24tb3JpZW50ZWQgPEJSPiZndDsgYmVo
YXZpb3VyIHRvIElQKSA8QlI+Jmd0OyAmZ3Q7IHdvbmRlcmluZyBhYm91dCB0aGUgc3VpdGFiaWxp
dHkgb2YgdXNpbmcgb25lIG9mIHRoZSA8QlI+Jmd0OyBwcm90b2NvbCBzdWl0ZSBvZiA8QlI+Jmd0
OyAmZ3Q7IHRoZSBJRVRGIGkuZS4gR01QTFMgdG8gYnJpbmcgYW5vdGhlciAoaW5pdGlhbGx5KSBj
b25uZWN0aW9ubGVzcyA8QlI+Jmd0OyAmZ3Q7IHRlY2hub2xvZ3kgdG8gYSAmcXVvdDtjb25uZWN0
aW9uLW9yaWVudGVkJnF1b3Q7IGJlaGF2aW91cjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7
ICZndDsgPEJSPiZndDsgJmd0OyBJIGRvbid0IGFyZ3VlIGFnYWluc3QgYnJpbmdpbmcgY29ubmVj
dGlvbi1vcmllbnRlZCBiZWhhdmlvciB0byA8QlI+Jmd0OyAmZ3Q7IEV0aGVybmV0LiBNeSBjb25j
ZXJuIGlzIHRoZSBtZXRob2QgdXNlZCB0byBkbyBzby4gaWYgeW91IGhhZCBkb25lIDxCUj4mZ3Q7
ICZndDsgcHJvcGVyIE5ldHdvcmsgSW50ZXJ3b3JraW5nIChha2EsIGVuY2Fwc3VsYXRpb24gb3Ig
YXMgSVRVIGNhbGxzIGl0IDxCUj4mZ3Q7ICZndDsgY2xpZW50L3NlcnZlciksIHRoZW4gdGhlcmUg
d291bGQgbm90IGJlIGFueSBwcm9ibGVtLiA8QlI+Jmd0OyBIb3dldmVyLCB3aGF0IHlvdSA8QlI+
Jmd0OyAmZ3Q7IGFyZSB0cnlpbmcgdG8gZG8gaXMgdG8gbW9kaWZ5IEV0aGVybmV0J3MgY29udHJv
bC1wbGFuZSBpbiBhIDxCUj4mZ3Q7IHdheSB0aGF0IDxCUj4mZ3Q7ICZndDsgcmVxdWlyZXMgbW9k
aWZpY2F0aW9uIHRvIGl0cyBkYXRhLXBsYW5lIGJlaGF2aW9yLiBBcyBhbiA8QlI+Jmd0OyBhbmFs
b2d5IHdoYXQgPEJSPiZndDsgJmd0OyB5b3UgYXJlIGRvaW5nIGlzIGxpa2UgdHJ5aW5nIHRvIHVz
ZSB0aGUgSVAgYWRkcmVzcyBhcyBNUExTIHRhZyBpbiA8QlI+Jmd0OyAmZ3Q7IG9yZGVyIHRvIG1h
a2UgSVAgY29ubmVjdGlvbi1vcmllbnRlZC48Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAm
Z3Q7IDxCUj4mZ3Q7ICZndDsgSW4gY29udHJhc3QgeW91IGNvdWxkIGVhc2lseSBjaGFuZ2UgQVRN
J3MgY29udHJvbC1wbGFuZSB0byBHTVBMUyA8QlI+Jmd0OyAmZ3Q7IHdpdGhvdXQgYW55IG1vZGlm
aWNhdGlvbiB0byBBVE0gZGF0YS1wbGFuZSBiZWhhdmlvciwgYmVjYXVzZSBBVE0gYnkgPEJSPiZn
dDsgJmd0OyBkZXNpZ24gaXMgY29ubmVjdGlvbi1vcmllbnRlZCwgYW5kIHRoZSBWUEkvVkNJIGNv
dWxkIGVhc2lseSBiZSA8QlI+Jmd0OyAmZ3Q7IGludGVycHJldGVkIGFzIEdNUExTIHRhZ3MuPEZP
TlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IChldmVuIGlmIGkg
ZG8gcmF0aGVyIHByZWZlciB0aGUgdGVybSBmbG93LCBpbiB0aGUgcHJlc2VudCA8QlI+Jmd0OyBj
b250ZXh0KSBhdCA8QlI+Jmd0OyAmZ3Q7IHRoZSBlbmQgdGhlIHJlc3VsdGluZyBnYWluIGlzIHRo
ZSBzYW1lIGZvciBib3RoIDxCUj4mZ3Q7IHRlY2hub2xvZ2llcyBpdCB0ZXJtcyA8QlI+Jmd0OyAm
Z3Q7IG9mIGNhcGFiaWxpdGllcyBhcyBhcHBsaWNhdGlvbiBvZiBjb25zdHJhaW50LWJhc2VkIHJv
dXRpbmcgPEJSPiZndDsgcHJpbmNpcGxlczxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZn
dDsgLSBpcyB0aGlzIG5vdCBhdCB0aGUgZW5kIHdoYXQgZHJpdmVzIG1vc3RseSBhbGwgZGViYXRl
cyBpbiA8QlI+Jmd0OyB0aGUgKEcpTVBMUyA8QlI+Jmd0OyAmZ3Q7IGdhbGF4eSBiZXNpZGUgVlBO
cyBhbmQgdGhhdCB3YXMgdW5kZXJseWluZyBpbmNvcnBvcmF0aW9uIG9mIDxCUj4mZ3Q7IHRoZXNl
IEwyIDxCUj4mZ3Q7ICZndDsgdGVjaG5vbG9naWVzIGFzIHBhcnQgb2YgdGhlIEdNUExTIHByb3Rv
Y29sIGFyY2hpdGVjdHVyZTxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZn
dDsgJmd0OyB0aGFua3MsPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyA8QlI+Jmd0
OyAmZ3Q7IC0gZGltaXRyaS48Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4m
Z3Q7ICZndDsgPEJSPiZndDsgJmd0OyBTaGFocmFtIERhdmFyaSAmbHQ7U2hhaHJhbV9EYXZhcmlA
cG1jLXNpZXJyYS5jb20mZ3Q7IFNlbnQgYnk6IDxCUj4mZ3Q7ICZndDsgb3duZXItY2NhbXBAb3Bz
LmlldGYub3JnIDAyLzAzLzIwMDUgMTM6MTMgUFNUPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZn
dDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IFRvOiBEaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxDQVRF
TEBBTENBVEVMLCAmcXVvdDtNYWNrLUNyYW5lLCBULiA8QlI+Jmd0OyAmZ3Q7IEJlbmphbWluJnF1
b3Q7ICZsdDtCZW4uTWFjay1DcmFuZUB0ZWxsYWJzLmNvbSZndDsgY2M6IGRwYXBhZGltaXRyaW91
QHBzZy5jb20sIDxCUj4mZ3Q7ICZndDsgRGF2aWQgQWxsYW4gJmx0O2RhbGxhbkBub3J0ZWxuZXR3
b3Jrcy5jb20mZ3Q7LCBBZHJpYW4gRmFycmVsIDxCUj4mZ3Q7ICZndDsgJmx0O2FkcmlhbkBvbGRk
b2cuY28udWsmZ3Q7LCBjY2FtcEBvcHMuaWV0Zi5vcmcgYmNjOiBTdWJqZWN0OiBSRTogTGF5ZXIg
MiA8QlI+Jmd0OyAmZ3Q7IFN3aXRjaGluZyBDYXBzIExTUHM8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48
QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IDxC
Uj4mZ3Q7ICZndDsgRGltaXRyaSw8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxC
Uj4mZ3Q7ICZndDsgVW5mb3J0dW5hdGVseSBJIGRpZG4ndCBncmFzcCBjb21wbGV0ZWx5IHdoYXQg
eW91IGFyZSB0cnlpbmcgPEJSPiZndDsgdG8gY29udmV5LiA8QlI+Jmd0OyAmZ3Q7IEJ1dCBvbmUg
dGhpbmcgSSBrbm93IGZvciBzdXJlLCBhbmQgdGhhdCBpcyZuYnNwOyAmcXVvdDtFdGhlcm5ldCBp
cyA8QlI+Jmd0OyAmZ3Q7IENvbm5lY3Rpb25sZXNzIChDTFMpJnF1b3Q7IChsaWtlIElQKSBhbmQg
YXNzdW1lcyBzaGFyZWQgbWVkaXVtLCA8QlI+Jmd0OyB3aGlsZSBHTVBMUyA8QlI+Jmd0OyAmZ3Q7
IGlzIGNvbm5lY3Rpb24tb3JpZW50ZWQgKENPKSBhbmQgZG9lc24ndCB3b3JrIGluIHNoYXJlZCBt
ZWRpdW0uIE9mZiA8QlI+Jmd0OyAmZ3Q7IGNvdXJzZSB5b3UgY291bGQgYWx3YXlzIGNvbmZpZ3Vy
ZSBhbmQgYnVpbGQgYW4gRXRoZXJuZXQgPEJSPiZndDsgbmV0d29yayB0aGF0IDxCUj4mZ3Q7ICZn
dDsgbG9va3MgbGlrZSBpdCBpcyBDTyAoYnkgY29uZmlndXJpbmcgYSBtYXggb2YgMiBwb3J0cyB3
aXRoIHRoZSBzYW1lIDxCUj4mZ3Q7ICZndDsgVkxBTiBJRCBpbiBlYWNoIGJyaWRnZSksIGFuZCBi
eSBub3QgdXNpbmcgYW55IHNoYXJlZCA8QlI+Jmd0OyBtZWRpdW0uIEJ1dCB0aGVuIDxCUj4mZ3Q7
ICZndDsgd2hvIG5lZWRzIEdNUExTLCB3aGVuIHlvdSBhbHJlYWR5IGhhdmUgdG8gY29uZmlndXJl
IHlvdXIgbmV0d29yayBieSA8QlI+Jmd0OyAmZ3Q7IG90aGVyIG1lYW5zPzxGT05UIFNJWkU9ND4g
PC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyAtU2hhaHJhbTxGT05UIFNJWkU9ND4g
PC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IEZyb206IERp
bWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlIDxCUj4mZ3Q7ICZndDsgWzxGT05UIENPTE9S
PUJMVUU+PFU+PEEgSFJFRj1tYWlsdG86RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmU+
bWFpbHRvOkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlPC9BPjwvVT48L0ZPTlQ+PEZP
TlQgQ09MT1I9QkxBQ0s+XSBTZW50OiBUaHVyc2RheSwgPEJSPiZndDsgRmVicnVhcnkgMDMsIDxC
Uj4mZ3Q7ICZndDsgMjAwNSAzOjA3IFBNIFRvOiBNYWNrLUNyYW5lLCBULiBCZW5qYW1pbiBDYzog
PEJSPiZndDsgZHBhcGFkaW1pdHJpb3VAcHNnLmNvbTsgPEJSPiZndDsgJmd0OyBkaW1pdHJpLnBh
cGFkaW1pdHJpb3VAYWxjYXRlbC5iZTsgRGF2aWQgQWxsYW47IEFkcmlhbiA8QlI+Jmd0OyBGYXJy
ZWw7IFNoYWhyYW0gPEJSPiZndDsgJmd0OyBEYXZhcmk7IGNjYW1wQG9wcy5pZXRmLm9yZyBTdWJq
ZWN0OiBSRTogTGF5ZXIgMiBTd2l0Y2hpbmcgQ2FwcyBMU1BzPC9GT05UPjxGT05UIFNJWkU9ND4g
PC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7
ICZndDsgYmVuLDxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0
OyB0aGUgZGlzY3Vzc2lvbiB3aXRoIGRhdmUgaGFzIGJlZW4gcmVwcm9kdWNlZCBpbiBhY2NlbGVy
YXRlZCBvbiB0aGUgPEJSPiZndDsgJmd0OyBtYWlsaW5nIGxpc3QgLSBmb3IgbWUgaXQgYXBwZWFy
cyB0aGF0IHRoZSBtb3JlICZxdW90O3BoaWxvc29waGljYWwmcXVvdDsgPEJSPiZndDsgJmd0OyBj
b25jbHVzaW9uIGNhbiBiZSBwb3NpdGlvbmVkIGJ5IGFuc3dlcmluZyB0byB0aGUgZm9sbG93aW5n
IHF1ZXN0aW9uIDxCUj4mZ3Q7ICZndDsgJnF1b3Q7V2FzIFNPTkVUL1NESCBvciBsYW1iZGEgc3dp
dGNoaW5nIGluaXRpYWxseSBpbnRlbmRlZCB0byBiZSA8QlI+Jmd0OyBjb250cm9sbGVkIDxCUj4m
Z3Q7ICZndDsgYnkgR01QTFMgPyZxdW90OyBpZiB0aGUgcmVzcG9uc2UgaXMgJnF1b3Q7Tm8sIGJ1
dCBub3RoaW5nIHByZXZlbnRzIHRvIDxCUj4mZ3Q7IGRvIHNvJnF1b3Q7IHRoZSA8QlI+Jmd0OyAm
Z3Q7IG5leHQgcXVlc3Rpb24gaXMgd2hhdCBkb2VzIHByZXZlbnQgZnJvbSBhcHBseWluZyBHTVBM
UyB0byBvdGhlciA8QlI+Jmd0OyAmZ3Q7IHRlY2hub2xvZ2llcyBrbm93aW5nIGEgc3Vic3RhbnRp
YWwgZ2FpbiBpcyBvYnRhaW5lZCBmcm9tIGl0cyA8QlI+Jmd0OyAmZ3Q7IGFwcGxpY2F0aW9uIC0g
aW4gY2VydGFpbiBjb25kaXRpb25zIC0gKHNlZSBtb3RpdmF0aW9ucyBhcyA8QlI+Jmd0OyBwYXJ0
IG9mIHRoaXMgPEJSPiZndDsgJmd0OyBpbnRyb2R1Y3Rpb24gZm9yIGluc3RhbmNlKSA/IGtleSBp
c3N1ZSBiZWluZyB3aGljaCBhcmUgdGhlc2U8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAm
Z3Q7ICh0ZWNobmljYWwpIGNvbmRpdGlvbnMgYW5kIGFyZSB0aGVyZSBjb25kaXRpb25zIHRoYXQg
d291bGQgcHJlY2x1ZGUgPEJSPiZndDsgJmd0OyBwcm9ncmVzc2luZyB0aGlzIGRvY3VtZW50IC0g
dGhlIHJlc3BvbnNlIGlzIHNpbXBseSB0aGUgbmVnYXRpdmUgLSA8QlI+Jmd0OyAmZ3Q7IHRoZXJl
IGFyZSBubyBzdWNoIGNvbmRpdGlvbnMgaW4gdGhlIHBvaW50LXRvLXBvaW50IC0gbm9uLWJyaWRn
aW5nIC0gPEJSPiZndDsgJmd0OyBjb250ZXh0IHdoZXJlIHRoaXMgZG9jdW1lbnQgYXBwbGllcy48
Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgbm93LCBub3Qg
c3VyZSB0aGVyZSBpcyBhIHRlY2huaWNhbCAmcXVvdDtmaXJtJnF1b3Q7IGNvbmNsdXNpb24gYnV0
IDxCUj4mZ3Q7IHRoZSBwb2ludCBvbiA8QlI+Jmd0OyAmZ3Q7IHRoZSBldGhlcm5ldCBsYWJlbCBl
bmNvZGluZyBhcHBlYXJzIGFzIGZvbGxvd3Mgc2luY2Ugc28gZmFyIDxCUj4mZ3Q7IHRoZXJlIGlz
IDxCUj4mZ3Q7ICZndDsgcG90ZW50aWFsIGludGVyZXN0IHRvIGtlZXAgdGhlIGxhYmVsIGZvciBl
dGhlcm5ldCBnZW5lcmljIDxCUj4mZ3Q7IGVub3VnaCBhbmQgPEJSPiZndDsgJmd0OyBkZWR1Y2Ug
aXRzIGludGVycHJldGF0aW9uIGZyb20gdHlwZSBvZiBsaW5rIG92ZXIgd2hpY2ggdGhlIGxhYmVs
IGlzIDxCUj4mZ3Q7ICZndDsgdXNlZCBhbmQgaW50ZXByZWV0IGl0cyB2YWx1ZSBhY2NvcmRpbmcg
dG8gdGhlIDxCUj4mZ3Q7IHRyYWZmaWNfcGFyYW1ldGVycyBhbmQgPEJSPiZndDsgJmd0OyBwcm9w
b3NlIGFzc29jaWF0aW9ucyB0byBjb3ZlciBjYXNlcyBzdWNoIGFzIGNhc2UgMiBvZiBBcHBlbmRp
eCBBIG9mIDxCUj4mZ3Q7ICZndDsgJmx0O2RyYWZ0LXB3ZTMtZXRoZXJuZXQtZW5jYXAtMDgudHh0
Jmd0OyBtZWNoYW5pc21zIHRoYXQgaXMgYWxzbyA8QlI+Jmd0OyBhcHBsaWNhYmxlIDxCUj4mZ3Q7
ICZndDsgdG8gb3RoZXIgdHVubmVsaW5nIHRlY2hub2xvZ3kgc2luY2UgdGhpcyBtZWNoYW5pc20g
aXMgb3J0aG9nb25hbCB0byA8QlI+Jmd0OyAmZ3Q7IHRoZSB1c2Ugb2YgUFcncyBpZiByZXF1aXJl
ZCAoZXhhbXBsZSBiZWluZyBFdGhlcm5ldCBvdmVyIDxCUj4mZ3Q7IFNESC9PVEgsIGZvciA8QlI+
Jmd0OyAmZ3Q7IGluc3RhbmNlKTsgaG93ZXZlciwgaWYgdGhlc2UgYXJlIHRoZSBvbmx5IGFzc29j
aWF0aW9ucyB3ZSA8QlI+Jmd0OyBzZWUgcmVsZXZhbnQgPEJSPiZndDsgJmd0OyBhcyBwYXJ0IG9m
IHRoaXMgZG9jdW1lbnQgdGhlbiB3ZSB3b3VsZCBmYWxsIGJhY2sgb24gdGhlIGV4aXN0aW5nIDxC
Uj4mZ3Q7ICZndDsgZW5jb2Rpbmcgd2l0aCBwb3RlbnRpYWwgZW5oYW5jZW1lbnQgaWYgc28gcmVx
dWlyZWQgLTxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyB0
byBjb21lIHRvIHRoZSBwb2ludCBvZiB0aGUgYXJ0aWN1bGF0aW9uIHRoZSAtIGdlbmVyaWMgLSBy
ZXNwb25zZSA8QlI+Jmd0OyAmZ3Q7IGhvbGRzIGluIG9uZSBsaW5lOiBpdCBhcnRpY3VsYXRlcyBH
TVBMUyBzaWduYWxpbmcgZm9yIEwyU0MgTFNQczxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7
ICZndDsgKG5vdGU6IHRoZSBsYXR0ZXIgaGFzIGJlZW4gaW50cm9kdWNlZCBpbiBSRkMgMzk0NSwg
UkZDIDM0NzEsIFJGQzxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgMzQ3MykgLSB0
aGUgbW90aXZhdGlvbnMgYXJlIGRldGFpbGVkIGFzIHBhcnQgb2YgdGhlIGludHJvZHVjdGlvbiBv
ZiA8QlI+Jmd0OyAmZ3Q7IHRoaXMgZG9jdW1lbnQgLSBpIGNhbiBub3QgY29tbWVudCBtb3JlIGZy
b20geW91ciBpbml0aWFsIHN0YXRlbWVudCA8QlI+Jmd0OyAmZ3Q7IHNpbmNlIG5vdCBkZXRhaWxl
ZCBlbm91Z2ggZm9yIG1lIHRvIGJlIG1vcmUgc3BlY2lmaWM8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48
QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgdGhlIHJlc3BvbnNlIHRvIHRoZSBsYXN0IHF1ZXN0
aW9uIGlzIHJlbGF0aXZlbHkgc2ltcGxlIDxCUj4mZ3Q7IHNpbmNlIHRoZSBhYm92ZSA8QlI+Jmd0
OyAmZ3Q7IG1lbnRpb25lZCBkbyBub3QgaW5jbHVkZSBhbnkgc3BlY2lmaWNzIGNvbmNlcm5pbmcg
QVRNIG9yIEZSIC0gdGhpcyA8QlI+Jmd0OyAmZ3Q7IGRvY3VtZW50IGludGVuZHMgdG8gY2xvc2Ug
dGhpcyBnYXAgYnkgZGVmaW5pbmcgc3BlY2lmaWMgPEJSPiZndDsgJmd0OyBUcmFmZmljX1BhcmFt
ZXRlcnMgZm9yIHRoZXNlIHRlY2hub2xvZ2llcyAtIGlzIHRoZXJlIGFuIDxCUj4mZ3Q7IGludGVy
ZXN0IGZvciA8QlI+Jmd0OyAmZ3Q7IGRvaW5nIHNvOiByZXNwb25zZSBpcyB5ZXMgb3RoZXJ3aXNl
IHRoZSBkb2N1bWVudCB3b3VsZCBub3QgaGF2ZSA8QlI+Jmd0OyAmZ3Q7IGluY2x1ZGVkIHRoZSBj
b3JyLiBkZXRhaWxzPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAm
Z3Q7IHZvaWxhLCB0aGFua3MsPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyA8QlI+
Jmd0OyAmZ3Q7IC0gZGltaXRyaS48Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxC
Uj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgPEJS
PiZndDsgJmd0OyAmcXVvdDtNYWNrLUNyYW5lLCBULiBCZW5qYW1pbiZxdW90OyAmbHQ7QmVuLk1h
Y2stQ3JhbmVAdGVsbGFicy5jb20mZ3Q7IFNlbnQgYnk6IDxCUj4mZ3Q7ICZndDsgb3duZXItY2Nh
bXBAb3BzLmlldGYub3JnIDAyLzAzLzIwMDUgMTI6MTYgQ1NUPEZPTlQgU0laRT00PiA8L0ZPTlQ+
PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IFRvOiAmbHQ7ZHBhcGFkaW1pdHJpb3VAcHNnLmNv
bSZndDssIERpbWl0cmkgPEJSPiZndDsgJmd0OyBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxD
QVRFTCwgJnF1b3Q7RGF2aWQgQWxsYW4mcXVvdDsgPEJSPiZndDsgJmd0OyAmbHQ7ZGFsbGFuQG5v
cnRlbG5ldHdvcmtzLmNvbSZndDsgY2M6ICZxdW90O0FkcmlhbiBGYXJyZWwmcXVvdDsgPEJSPiZn
dDsgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7LCA8QlI+Jmd0OyAmZ3Q7ICZxdW90O1NoYWhy
YW0gRGF2YXJpJnF1b3Q7ICZsdDtTaGFocmFtX0RhdmFyaUBwbWMtc2llcnJhLmNvbSZndDssIDxC
Uj4mZ3Q7ICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7IDxCUj4mZ3Q7ICZndDsgYmNjOiBTdWJq
ZWN0OjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgUkU6IExheWVyIDIgU3dpdGNo
aW5nIENhcHMgTFNQczxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsg
Jmd0OyA8QlI+Jmd0OyAmZ3Q7IERpbWl0cmksPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsg
Jmd0OyA8QlI+Jmd0OyAmZ3Q7IENhbiB0aGUgb2ZmLWxpbmUgZGlzY3Vzc2lvbiBiZSBzdW1tYXJp
emVkIGZvciB0aGUgYmVuZWZpdCA8QlI+Jmd0OyBvZiB0aG9zZSBvbiZuYnNwOyA8QlI+Jmd0OyAm
Z3Q7IHRoZSBsaXN0IHdobyBkaWQgbm90IHBhcnRpY2lwYXRlPyZuYnNwOyBGb3IgbWUsIHRoZSBk
cmFmdCAoYW5kIDxCUj4mZ3Q7IHRoZSBjdXJyZW50IDxCUj4mZ3Q7ICZndDsgZGlzY3Vzc2lvbiBv
biB0aGUgbGlzdCkgaGF2ZSBub3QgY2xlYXJseSBhcnRpY3VsYXRlZCB0aGUgPEJSPiZndDsgcHJv
YmxlbSBiZWluZyA8QlI+Jmd0OyAmZ3Q7IGFkZHJlc3NlZC4mbmJzcDsgSWYgYSBzdW1tYXJ5IG9m
IHRoZSBjb25jbHVzaW9ucyBvZiB0aGUgb2ZmLWxpbmUgPEJSPiZndDsgZGlzY3Vzc2lvbiA8QlI+
Jmd0OyAmZ3Q7IHdpbGwgZG8gdGhpcywgaXQgd291bGQgYmUgdXNlZnVsLjxGT05UIFNJWkU9ND4g
PC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBJIGFtIGFsc28gaW50ZXJlc3RlZCB0
byBrbm93IHdoYXQgaXMgbGFja2luZyBpbiB0aGUgY3VycmVudCA8QlI+Jmd0OyBHTVBMUyBSRkNz
IDxCUj4mZ3Q7ICZndDsgd2l0aCByZXNwZWN0IHRvIEFUTSBhbmQgRnJhbWUgUmVsYXkgc3VwcG9y
dCB0aGF0IG5lY2Vzc2l0YXRlcyA8QlI+Jmd0OyAmZ3Q7IGluY2x1ZGluZyB0aGVtIGluIHRoaXMg
bmV3IGRyYWZ0IChwcmVzdW1hYmx5IHRoaXMgaXMgYSBwYXJ0IG9mIHRoZSA8QlI+Jmd0OyAmZ3Q7
IHByb2JsZW0gdG8gYmUgc29sdmVkKS48Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7
IDxCUj4mZ3Q7ICZndDsgUmVnYXJkcywgQmVuPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsg
Jmd0OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tIEZyb206IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyA8QlI+Jmd0OyAmZ3Q7Jmd0OyBb
PEZPTlQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5v
cmc+bWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvQT48L1U+PC9GT05UPjxGT05UIENP
TE9SPUJMQUNLPl0gT248L0ZPTlQ+PEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyA8
QlI+Jmd0OyAmZ3Q7IEJlaGFsZjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJS
PiZndDsgJmd0OyZndDsgT2YgZGltaXRyaSBwYXBhZGltaXRyaW91IFNlbnQ6IFRodXJzZGF5LCBK
YW51YXJ5IDI3LCAyMDA1IDY6MzUgUE08Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7
Jmd0OyBUbzogRGF2aWQgQWxsYW4gQ2M6ICdBZHJpYW4gRmFycmVsJzsgJ1NoYWhyYW0gRGF2YXJp
Jzs8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7Jmd0OyBjY2FtcEBvcHMuaWV0Zi5v
cmcgU3ViamVjdDogUmU6IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQczxGT05UIFNJWkU9ND4g
PC9GT05UPjxCUj4mZ3Q7ICZndDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7IGRhdmUgLSB0aGVyZSB3
YXMgYSBsZW5ndGh5IG9mZi1saW5lIGRpc2N1c3Npb24gc3VnZ2VzdGVkIGJ5IHRoZSA8QlI+Jmd0
OyAmZ3Q7Jmd0OyBjaGFpcnMgaW50ZW5kZWQgdG8gZXhwbGFpbiB5b3UgdGhlIHNjb3BlIG9mIHRo
ZSBkcmFmdCBhbmQgaXRzIDxCUj4mZ3Q7ICZndDsmZ3Q7IHJlbGF0aW9zaGlwPEZPTlQgU0laRT00
PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IHdpdGg8Rk9OVCBTSVpFPTQ+IDwv
Rk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7IHRoZSBldGhlcm5ldCBkYXRhIHBs
YW5lIChhZnRlciB0aGUgcXVlc3Rpb24geW91IHJhaXNlZCA8QlI+Jmd0OyBkdXJpbmcgdGhlIGYy
ZiA8QlI+Jmd0OyAmZ3Q7Jmd0OyBtZWV0aW5nKSAtIHRoaXMgaGFzIGJlZW4gZG9uZSBhbmQgd2Ug
aGF2ZSBleHBsYWluZWQgKHZpYSBhIGxlbmd0aHkgPEJSPiZndDsgJmd0OyZndDsgZXhjaGFuZ2Ug
b2YgZS1tYWlscykgdGhhdCB0aGlzIGRvY3VtZW50IGFuZCBzbyB0aGUgdXNlIG9mIGdtcGxzIHRv
IDxCUj4mZ3Q7ICZndDsmZ3Q7IGNvbnRyb2wgZXRoZXJuZXQgZnJhbWUgZmxvd3MsIGlzIG5vdCB0
YXJnZXRpbmcgY29udHJvbCBvZiBicmlkZ2VkIDxCUj4mZ3Q7ICZndDsmZ3Q7IGV0aGVybmV0IGVu
dmlyb25tZW50cyAtIGlmIHRoaXMgaXMgbm90IGNsZWFyIGZyb20gdGhlIGN1cnJlbnQgPEJSPiZn
dDsgJmd0OyZndDsgZG9jdW1lbnQgaW50cm9kdWN0aW9uIHdlIHdvdWxkIGhhdmUgYWxzbyB0byB3
b3JrIG9uIHRoaXMgPEJSPiZndDsgcGFydCBvZiB0aGUgPEJSPiZndDsgJmd0OyZndDsgZG9jdW1l
bnQgLSB0aGVyZWZvcmUsIHRoZSBiZWxvdyByZWZlcmVuY2UgdG8gTVNUUCBpcyBub3QgaW4gdGhl
IDxCUj4mZ3Q7ICZndDsmZ3Q7IGN1cnJlbnQgc2NvcGU7IG9uIHRoZSBvdGhlciBzaWRlLCB0aGUg
dXNlIG9mIHRoZSB0ZXJtICZxdW90O1ZMQU4gbGFiZWwmcXVvdDsgPEJSPiZndDsgJmd0OyZndDsg
aGFzIGNyZWF0ZWQgc29tZSBjb25mdXNpb247IHRoZXJlZm9yZSwgaW4gYSBuZXh0IHJlbGVhc2Ug
aSB3aWxsIDxCUj4mZ3Q7ICZndDsmZ3Q7IHNpbXBseSByZWZlciB0byBhPEZPTlQgU0laRT00PiA8
L0ZPTlQ+PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7ICZxdW90O2xhYmVsJnF1b3Q7PEZPTlQg
U0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyBvZiAzMiBiaXRz
ICh1bnN0cnVjdHVyZWQpIGJlY2F1c2UgdGhlIGludGVudGlvbiB3YXMgKGFuZCA8QlI+Jmd0OyBz
dGlsbCBpcykgdG8gPEJSPiZndDsgJmd0OyZndDsgZmluZCBhbiBlYXN5IHdheSB0byBtYXAgdGhl
IGNvbnRyb2wgb2YgdGhlIGV0aGVybmV0IGZyYW1lIGZsb3dzIG9uPEZPTlQgU0laRT00PiA8L0ZP
TlQ+PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IGVhY2g8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48
QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7IGRldmljZSB0aGV5IHRyYXZlcnNlcyB3aXRo
b3V0IG1ha2luZyBhbnkgYXNzdW1wdGlvbiBvbiBob3cgPEJSPiZndDsgdGhpcyBmbG93PEZPTlQg
U0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IGlzPEZPTlQgU0laRT00
PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyBwcm9jZXNzZWQgaW5zaWRl
IGVhY2ggbm9kZSBhdCB0aGUgZGF0YSBwbGFuZSBsZXZlbCAobm90ZTogb24gbGFiZWw8Rk9OVCBT
SVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7Jmd0OyB2YWx1ZXMsIFJGQyAzOTQ2IHRvb2sgYW4g
ZXF1aXZhbGVudCBhcHByb2FjaCAtIGZvciBjaXJjdWl0cyAtIHdoZXJlPEZPTlQgU0laRT00PiA8
L0ZPTlQ+PEJSPiZndDsgJmd0OyZndDsmbmJzcDsgc29uZXQvc2RoIG11bHRpcGxleGluZyBzdHJ1
Y3R1cmVzIGhhdmUgYmVlbiB1c2VkIHRvIGNyZWF0ZSB1bmlxdWUgPEJSPiZndDsgJmd0OyZndDsg
bXVsdGlwbGV4IGVudHJ5IG5hbWVzIGkuZS4gbGFiZWxzIC0gdGhpcyBjb25jZXB0IGlzIGhlcmUg
YXBwbGllZDxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsmZ3Q7IGZvciAmcXVvdDt2
aXJ0dWFsJnF1b3Q7IGNpcmN1aXRzKSwgc28sIGlmIHRoZSB3b3JraW5nIGdyb3VwIGlzIHdpbGxp
bmcgdG88Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7Jmd0OyBlbnRlciBpbnRvPEZP
TlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyA8QlI+Jmd0OyAmZ3Q7IGE8Rk9OVCBTSVpF
PTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7IGRhdGEgcGxhbmUgb3Jp
ZW50ZWQgZGlzY3Vzc2lvbiB0byBjbGFyaWZ5IHRoZSBiZWhhdmlvdXIocykgPEJSPiZndDsgb250
byB3aGljaCA8QlI+Jmd0OyAmZ3Q7Jmd0OyB0aGUgcHJlc2VudCBhcHByb2FjaCB3b3VsZCBiZSBw
b3RlbnRpYWxseSBhcHBsaWNhYmxlIHRoaXMgaXMgZmluZSA8QlI+Jmd0OyAmZ3Q7Jmd0OyB3aXRo
IG1lIGFzIGxvbmcgYXMgd2UgYXJlIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIGluaXRpYWwgPEJS
PiZndDsgbW90aXZhdGlvbnM8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7Jmd0OyA8
QlI+Jmd0OyAmZ3Q7Jmd0OyB0aGFua3MsIC0gZGltaXRyaS48Rk9OVCBTSVpFPTQ+IDwvRk9OVD48
QlI+Jmd0OyAmZ3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyBEYXZpZCBBbGxhbiB3cm90ZTo8Rk9O
VCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsg
SGkgQWRyaWFuOjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyA8QlI+
Jmd0OyAmZ3Q7Jmd0OyZndDsgWW91ciBzdWdnZXN0aW9uIGlzIGluIGEgd2F5IHJlYXNvbmFibGUg
YnV0IHdpdGggdGhlIGNhdmVhdCB0aGF0IGluPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsg
Jmd0OyA8QlI+Jmd0OyAmZ3Q7IElFRUU8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7
IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyB0ZXJtcywgYSBicmlkZ2luZyB0b3BvbG9neSBpcyBjdXJy
ZW50bHkgYWxsIFZMQU5zICg4MDIuMVEgc2luZ2xlPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZn
dDsgJmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsgc3Bhbm5pbmc8Rk9OVCBTSVpFPTQ+IDwvRk9O
VD48QlI+Jmd0OyAmZ3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgdHJlZSkgb3IgcGFydGl0
aW9uZWQgaW50byBzcGVjaWZpYyByYW5nZXMgKEkgYmVsaWV2ZSA2NCBpbiA4MDIuMXM8Rk9OVCBT
SVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsgPEJS
PiZndDsgJmd0OyZndDsgYWx0aG91Z2ggSTxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZn
dDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBkbyBub3QgY2xhaW0gdG8gYmUgYW4gZXhwZXJ0
KS48Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgPEJSPiZndDsgJmd0
OyZndDsmZ3Q7IElmIHRoZSBQRXMgd2VyZSB0byBpbXBsZW1lbnQgYSBicmlkZ2UgZnVuY3Rpb24g
YW5kIHdlIHdlcmUgdXNpbmc8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4m
Z3Q7ICZndDsgR01QTFM8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7
ICZndDsmZ3Q7IHRvPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyZndDsgPEJSPiZn
dDsgJmd0OyZndDsmZ3Q7IGludGVyY29ubmVjdCB0aGVtLCB0aGVuIHRoZSBjb250cm9sIHBsYW5l
IHNob3VsZCBiZSBpZGVudGlmeWluZzxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsg
PEJSPiZndDsgJmd0OyBlaXRoZXI8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxC
Uj4mZ3Q7ICZndDsmZ3Q7IGFsbDxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsmZ3Q7
IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBWTEFOcyAoc2luZ2xlIHNwYW5uaW5nIHRyZWUsIHdoaWNo
IEkgYmVsZWl2ZSB0aGUgZHJhZnQgY292ZXJzIGJ5PEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZn
dDsgJmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsgcmVmZXJyaW5nPEZPTlQgU0laRT00PiA8L0ZP
TlQ+PEJSPiZndDsgJmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsmZ3Q7IHNpbXBseSB0byBFdGhl
cm5ldCBwb3J0KSBvciBhIFZMQU4gcmFuZ2UgdG8gYmUgYXNzb2NpYXRlZCB3aXRoIHRoZTxGT05U
IFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBMU1A8Rk9OVCBTSVpF
PTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBjb25zaXN0ZW50
IHdpdGggODAyLjFzIGlmIGl0IGlzIHRvIG9wZXJhdGUgdG8gaW50ZXJjb25uZWN0IGJyaWRnZXM8
Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyBk
ZWZpbmVkPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyZndDsgPEJSPiZndDsgJmd0
OyZndDsmZ3Q7IGJ5IHRoZSBJRUVFLi4uPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0
OyZndDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBJIHN1c3BlY3QgYXNzdW1pbmcgYW55IG90
aGVyIGJlaGF2aW9yIChlLmcuIExTUCBmb3Igc2luZ2xlIFZMQU48Rk9OVCBTSVpFPTQ+IDwvRk9O
VD48QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgdGFnKTxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7
ICZndDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7IHdvdWxkPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJS
PiZndDsgJmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsmZ3Q7IGdvIG91dHNpZGUgdGhlIGJvdW5k
YXJ5IG9mIHdoYXQgaXMgY3VycmVudGx5IGRlZmluZWQuLi5zbyA8QlI+Jmd0OyBhbGlnbm1lbnQ8
Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgd2l0aDxGT05U
IFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyZndDsmZ3Q7IDgwMi4x
cyBJTU8gd291bGQgYmUgYSBtaW5pbXVtIHJlcXVpcmVtZW50IGlmIHdlIGFyZSB0byBjb25zaWRl
cjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyBjYXJyeWlu
ZzxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsgPEJSPiZndDsgJmd0OyZndDsmZ3Q7
IFZMQU4gaW5mb3JtYXRpb24gaW4gR01QTFMgc2lnbmFsbGluZy4uLi48Rk9OVCBTSVpFPTQ+IDwv
Rk9OVD48QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsmZ3Q7IGNoZWVycyBE
YXZlPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyZndDsmZ3Q7IDxCUj4mZ3Q7ICZn
dDsmZ3Q7Jmd0OyBZb3Ugd3JvdGUuLi4uPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0
OyZndDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7
IEhpLDxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPEJSPiZn
dDsgJmd0OyZndDsmZ3Q7Jmd0OyBUaGUgYXV0aG9ycyBvZiB0aGUgZHJhZnQgbWlnaHQgbGlrZSB0
byBjbGFyaWZ5IGZvciB0aGUgbGlzdDxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsm
Z3Q7Jmd0OyZndDsgZXhhY3RseSB3aGF0IGRhdGEgcGxhbmUgb3BlcmF0aW9ucyB0aGV5IGFyZSBz
dWdnZXN0aW5nLiBUbyBtZSA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGl0IHNlZW1zIHBvc3Np
YmxlIHRoYXQgdGhlIGRyYWZ0IGlzIHByb3Bvc2luZyBWTEFOIElEIDxCUj4mZ3Q7ICZndDsmZ3Q7
Jmd0OyZndDsgKnN3YXBwaW5nKi4gQnV0IGFuIGFsdGVybmF0aXZlIGlzIHRoYXQgdGhlIFZMQU4g
SUQgaXMgdXNlZCBhcyBhPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyZndDsmZ3Q7
Jmd0OyBsYWJlbCwgYnV0IHRoYXQgdGhlIHNhbWUgbGFiZWwgaXMgdXNlZCBmb3IgdGhlIGZ1bGwg
bGVuZ3RoIG9mPEZPTlQgU0laRT00PiA8L0ZPTlQ+PEJSPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0
aGUgTFNQLjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPEJS
PiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBBZHJpYW48Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0
OyAmZ3Q7Jmd0OyZndDsgPEJSPiZndDsgJmd0OyZndDsmZ3Q7IDxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0
OyA8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgLjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj4mZ3Q7ICZn
dDsmZ3Q7Jmd0OyA8QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZndDsgPT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IFRoZSA8QlI+Jmd0OyAm
Z3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIHByaXZpbGVn
ZWQgYW5kIDxCUj4mZ3Q7ICZndDsgY29uZmlkZW50aWFsIGFuZCBwcm90ZWN0ZWQgZnJvbSBkaXNj
bG9zdXJlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgPEJSPiZndDsgJmd0OyBtZXNzYWdlIGlzIG5v
dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBvciBhbiBlbXBsb3llZSBvciBhZ2VudCA8QlI+Jmd0
OyAmZ3Q7IHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRoaXMgbWVzc2FnZSB0byB0aGUgaW50
ZW5kZWQgPEJSPiZndDsgcmVjaXBpZW50LCB5b3UgPEJSPiZndDsgJmd0OyBhcmUgaGVyZWJ5IG5v
dGlmaWVkIHRoYXQgYW55IHJlcHJvZHVjdGlvbiwgZGlzc2VtaW5hdGlvbiBvciA8QlI+Jmd0OyAm
Z3Q7IGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGli
aXRlZC4gPEJSPiZndDsgSWYgeW91IGhhdmUgPEJSPiZndDsgJmd0OyByZWNlaXZlZCB0aGlzIGNv
bW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgPEJSPiZndDsgaW1tZWRpYXRl
bHkgYnkgPEJSPiZndDsgJmd0OyByZXBseWluZyB0byB0aGUgbWVzc2FnZSBhbmQgZGVsZXRpbmcg
aXQgZnJvbSB5b3VyIGNvbXB1dGVyLiA8QlI+Jmd0OyBUaGFuayB5b3UuIDxCUj4mZ3Q7ICZndDsg
VGVsbGFicyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT08Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyAmZ3Q7IDxCUj4mZ3Q7ICZn
dDsgPEJSPiZndDsgPEJSPiZndDsgPC9QPg==



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 18:22:17 +0000
To: "Mack-Crane, T. Benjamin" <[e-mail]>
Cc: <[e-mail]>, "Shahram Davari" <[e-mail]>, <[e-mail]>, "David Allan" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
MIME-Version: 1.0
Date: Fri, 4 Feb 2005 19:20:47 +0100
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

ben,

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

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

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

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

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





Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 17:10:33 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50ADC.3CFF79BC"
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 11:09:08 -0600
Message-ID: <[e-mail]>
Thread-Topic: Layer 2 Switching Caps LSPs
Thread-Index: AcUKQBQHCpOMxI6lTE+Oz2HxvwhzogAma0dA
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: <[e-mail]>, "Shahram Davari" <[e-mail]>
Cc: <[e-mail]>, "David Allan" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C50ADC.3CFF79BC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dmitri,

=20

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

=20

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

=20

Regards,

Ben

=20

=20

________________________________

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

=20

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

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

thanks,

- dimitri.


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

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



Dimitri,

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

-Shahram


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



ben,=20

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

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

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

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

voila, thanks,

- dimitri.





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

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


Dimitri,

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

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

Regards,
Ben

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

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Dmitri,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regarding your statement</span></font>=
<font
face=3DCourier><span style=3D'font-family:Courier'> &#8220;you have to deco=
uple the
notion of ethernet with bridging&#8221;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Forwarding of Ethernet frames IS bridg=
ing
(as defined by the IEEE) and a lot of work has gone into defining the
forwarding behavior of bridges.&nbsp; Are you proposing to define a new for=
m of
Ethernet forwarding outside of the IEEE?&nbsp; This seems like a bad idea.<=
/span></font></p>


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Ben</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4=2E0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, February 03,=
 2005
4:31 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Shahram Davari<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b>
'[e-mail]'; Mack-Crane, T. Benjamin;
[e-mail]; David Allan; Adrian Farrel; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Layer 2 Switchi=
ng
Caps LSPs</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;</span></font></p>

<p><font size=3D3 face=3DCourier><span style=3D'font-size:12.0pt;font-famil=
y:Courier'>sharam,
the first issue is that you have to decouple the notion of ethernet with
bridging, the second is that this configuration operation can be automated -
however the interesting point you brought in the loop of discussion here is
&quot;applicability for shared medium&quot; - isn't the PW solution in the =
same
context as 1) it can not make an automated usage of a &quot;medium&quot;
without configuring the tunnels (in our case the tunnels that will be used =
to
carry the ethernet payload e.g. SDH, OTH, etc. if not using point-to-point
PHY's) but in addition to the present solution PW also requires 2) the
provisioning of the PW - something not needed in the present context as
terminating points will be directly accessing the &quot;ethernet medium&quo=
t;,
in brief if such argument is used here it should have also been used in the=
 PW
context (if not more intensively)</span></font></p>

<p><font size=3D3 face=3DCourier><span style=3D'font-size:12.0pt;font-famil=
y:Courier'>another
fundamental point, i am also surprised seeing people supporting MPLS (which
brings a connection-oriented behaviour to IP) wondering about the suitabili=
ty
of using one of the protocol suite of the IETF i.e. GMPLS to bring another
(initially) connectionless technology to a &quot;connection-oriented&quot;
behaviour (even if i do rather prefer the term flow, in the present context=
) at
the end the resulting gain is the same for both technologies it terms of
capabilities as application of constraint-based routing principles - is this
not at the end what drives mostly all debates in the (G)MPLS galaxy beside =
VPNs
and that was underlying incorporation of these L2 technologies as part of t=
he
GMPLS protocol architecture</span></font></p>

<p><font size=3D3 face=3DCourier><span style=3D'font-size:12.0pt;font-famil=
y:Courier'>thanks,</span></font></p>

<p><font size=3D3 face=3DCourier><span style=3D'font-size:12.0pt;font-famil=
y:Courier'>-
dimitri.</span></font></p>

<p style=3D'margin-bottom:12.0pt'><font size=3D3 face=3D"Times New Roman"><=
span
style=3D'font-size:12.0pt'><br>
</span></font><b><font size=3D2><span style=3D'font-size:10.0pt;font-weight=
:bold'>Shahram
Davari &lt;[e-mail]&gt;</span></font></b><br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent by: [e-mail]=
tf.org</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>02/03/2005 13:13 PST</span>=
</font><br>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>To:</span></font> <font siz=
e=3D2><span
style=3D'font-size:10.0pt'>Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL,
&quot;Mack-Crane, T. Benjamin&quot; &lt;[e-mail]&gt;</spa=
n></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>cc:</span></font> <font siz=
e=3D2><span
style=3D'font-size:10.0pt'>[e-mail], David Allan
&lt;[e-mail]&gt;, Adrian Farrel &lt;[e-mail]&gt=
;,
[e-mail]</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>bcc:</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject:</span></font> <font
size=3D2><span style=3D'font-size:10.0pt'>RE: Layer 2 Switching Caps LSPs</=
span></font><br>
<br>
</p>

<p><font size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'=
>Dimitri,<br>
<br>
Unfortunately I didn't grasp completely what you are trying to convey. But =
one
thing I know for sure, and that is&nbsp; &quot;Ethernet is Connectionless
(CLS)&quot; (like IP) and assumes shared medium, while GMPLS is
connection-oriented (CO)&nbsp;and doesn't work in shared medium. Off course=
 you
could always configure and build an Ethernet network that looks like it is =
CO
(by configuring a max of 2 ports with the same VLAN ID in each bridge), and=
 by
not using any shared medium. But then who needs GMPLS, when you already hav=
e to
configure your network by other means?<br>
<br>
-Shahram<br>
<br>
<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Dimitri.Papadimitriou@=
alcatel.be
[mailto:[e-mail]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, February 03,=
 2005
3:07 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Mack-Crane, T. Benjamin<=
br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [e-mail];
[e-mail]; David Allan; Adrian Farrel; Shahram Davar=
i;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Layer 2 Switchi=
ng
Caps LSPs<br>
<br>
<br>
<br>
</span></font><font size=3D4><span style=3D'font-size:13.5pt'>ben, </span><=
/font><br>
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>the discussion with dave ha=
s been
reproduced in accelerated on the mailing list - for me it appears that the =
more
&quot;philosophical&quot; conclusion can be positioned by answering to the
following question &quot;Was SONET/SDH or lambda switching initially intend=
ed
to be controlled by GMPLS ?&quot; if the response is &quot;No, but nothing
prevents to do so&quot; the next question is what does prevent from applying
GMPLS to other technologies knowing a substantial gain is obtained from its
application - in certain conditions - (see motivations as part of this
introduction for instance) ? key issue being which are these (technical)
conditions and are there conditions that would preclude progressing this
document - the response is simply the negative - there are no such conditio=
ns
in the point-to-point - non-bridging - context where this document applies.=
 </span></font><br>
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>now, not sure there is a te=
chnical
&quot;firm&quot; conclusion but the point on the ethernet label encoding
appears as follows since so far there is potential interest to keep the lab=
el
for ethernet generic enough and deduce its interpretation from type of link

over which the label is used and intepreet its value according to the
traffic_parameters and propose associations to cover cases such as case 2 of
Appendix A of &lt;draft-pwe3-ethernet-encap-08.txt&gt; mechanisms that is a=
lso
applicable to other tunneling technology since this mechanism is orthogonal=
 to
the use of PW's if required (example being Ethernet over SDH/OTH, for insta=
nce);
however, if these are the only associations we see relevant as part of this
document then we would fall back on the existing encoding with potential
enhancement if so required - </span></font><br>
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>to come to the point of the
articulation the - generic - response holds in one line: it articulates GMP=
LS
signaling for L2SC LSPs (note: the latter has been introduced in RFC 3945, =
RFC
3471, RFC 3473) - the motivations are detailed as part of the introduction =
of
this document - i can not comment more from your initial statement since not
detailed enough for me to be more specific </span></font><br>
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>the response to the last qu=
estion
is relatively simple since the above mentioned do not include any specifics
concerning ATM or FR - this document intends to close this gap by defining
specific Traffic_Parameters for these technologies - is there an interest f=
or
doing so: response is yes otherwise the document would not have included the
corr. details</span></font><br>
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>voila, thanks,</span></font=
><br>
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>- dimitri.</span></font><br>
<br>
<br>
<br>
<br>
<br>
<b><span style=3D'font-weight:bold'>&quot;Mack-Crane, T. Benjamin&quot;
&lt;[e-mail]&gt;</span></b><br>
Sent by: [e-mail]<br>
02/03/2005 12:16 CST<br>
<br>
To:<font size=3D4><span style=3D'font-size:13.5pt'> </span></font>&lt;dpapa=
[e-mail]&gt;,
Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, &quot;David Allan&quot;
&lt;[e-mail]&gt;<br>
cc:<font size=3D4><span style=3D'font-size:13.5pt'> </span></font>&quot;Adr=
ian Farrel&quot; &lt;[e-mail]&gt;, &quot;Shahram Davari&quot;
&lt;[e-mail]&gt;, &lt;[e-mail]&gt;<br>
bcc:<font size=3D4><span style=3D'font-size:13.5pt'> </span></font><br>
Subject:<font size=3D4><span style=3D'font-size:13.5pt'> </span></font>RE: =
Layer 2
Switching Caps LSPs<br>
<br>
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>Dimitri,</span></font><br>
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>Can the off-line discussion=
 be
summarized for the benefit of those on</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>the list who did not partic=
ipate?
&nbsp;For me, the draft (and the current</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>discussion on the list) hav=
e not
clearly articulated the problem being</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>addressed. &nbsp;If a summa=
ry of
the conclusions of the off-line discussion</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>will do this, it would be u=
seful.</span></font><br>
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>I am also interested to kno=
w what
is lacking in the current GMPLS RFCs</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>with respect to ATM and Fra=
me Relay
support that necessitates including</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>them in this new draft (pre=
sumably
this is a part of the problem to be</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>solved).</span></font><br>
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>Regards,</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>Ben</span></font><br>
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; -----Original Message-=
----</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; From: owner-ccamp@ops.=
ietf.org
[mailto:[e-mail]] On</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>Behalf</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; Of dimitri papadimitri=
ou</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; Sent: Thursday, Januar=
y 27,
2005 6:35 PM</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; To: David Allan</span>=
</font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; Cc: 'Adrian Farrel'; '=
Shahram
Davari'; [e-mail]</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; Subject: Re: Layer 2 S=
witching
Caps LSPs</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; dave - there was a len=
gthy
off-line discussion suggested by the chairs</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; intended to explain yo=
u the
scope of the draft and its relatioship</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>with</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; the ethernet data plan=
e (after
the question you raised during the f2f</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; meeting) - this has be=
en done
and we have explained (via a lengthy</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; exchange of e-mails) t=
hat this
document and so the use of gmpls to</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; control ethernet frame=
 flows,
is not targeting control of bridged</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; ethernet environments =
- if
this is not clear from the current document</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; introduction we would =
have
also to work on this part of the document -</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; therefore, the below r=
eference
to MSTP is not in the current scope; on</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; the other side, the us=
e of the
term &quot;VLAN label&quot; has created some</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; confusion; therefore, =
in a
next release i will simply refer to a</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&quot;label&quot;</span></f=
ont><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; of 32 bits (unstructur=
ed)
because the intention was (and still is) to</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; find an easy way to ma=
p the
control of the ethernet frame flows on</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>each</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; device they traverses =
without
making any assumption on how this flow</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>is</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; processed inside each =
node at
the data plane level (note: on label</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; values, RFC 3946 took =
an
equivalent approach - for circuits - where</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; sonet/sdh multiplexing
structures have been used to create unique</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; multiplex entry names =
i=2Ee.
labels - this concept is here applied for</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &quot;virtual&quot; ci=
rcuits),
so, if the working group is willing to enter into</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>a</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; data plane oriented di=
scussion
to clarify the behaviour(s) onto which</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; the present approach w=
ould be
potentially applicable this is fine with</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; me as long as we are w=
ithin
the scope of the initial motivations</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; thanks,</span></font><=
br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; - dimitri.</span></fon=
t><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; David Allan wrote:</sp=
an></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; Hi Adrian:</span>=
</font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; Your suggestion i=
s in a
way reasonable but with the caveat that in</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>IEEE</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; terms, a bridging
topology is currently all VLANs (802.1Q single</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; spanning</span></font>=
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; tree) or partitio=
ned into
specific ranges (I believe 64 in 802.1s</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; although I</span></fon=
t><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; do not claim to b=
e an
expert).</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; If the PEs were to
implement a bridge function and we were using</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>GMPLS</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; to</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; interconnect them=
, then
the control plane should be identifying</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>either</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; all</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; VLANs (single spa=
nning
tree, which I beleive the draft covers by</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; referring</span></font=
><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; simply to Etherne=
t port)
or a VLAN range to be associated with the</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>LSP</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; consistent with 8=
02.1s if
it is to operate to interconnect bridges</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; defined</span></font><=
br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; by the IEEE...</s=
pan></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; I suspect assumin=
g any
other behavior (e.g. LSP for single VLAN tag)</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; would</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; go outside the bo=
undary
of what is currently defined...so alignment</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>with</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; 802.1s IMO would =
be a
minimum requirement if we are to consider</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>carrying</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; VLAN information =
in GMPLS
signalling....</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; cheers</span></fo=
nt><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; Dave</span></font=
><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; You wrote....</sp=
an></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;&gt;Hi,</span></fo=
nt><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;&gt;</span></font>=
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;&gt;The authors of=
 the
draft might like to clarify for the list</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;&gt;exactly what d=
ata
plane operations they are suggesting. To me</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;&gt;it seems possi=
ble that
the draft is proposing VLAN ID</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;&gt;*swapping*. Bu=
t an
alternative is that the VLAN ID is used as</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;&gt;a label, but t=
hat the
same label is used for the full length</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;&gt;of the LSP.</s=
pan></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;&gt;</span></font>=
<br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;&gt;Adrian</span><=
/font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt; .</span></font><b=
r>
<font size=3D4><span style=3D'font-size:13.5pt'>&gt; &gt;</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>The information contained i=
n this
message may be privileged</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>and confidential and protec=
ted from
disclosure. If the reader</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>of this message is not the =
intended
recipient, or an employee</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>or agent responsible for de=
livering
this message to the</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>intended recipient, you are=
 hereby
notified that any reproduction,</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>dissemination or distributi=
on of
this communication is strictly</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>prohibited. If you have rec=
eived
this communication in error,</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>please notify us immediatel=
y by replying
to the message and</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>deleting it from your compu=
ter.
Thank you. Tellabs</span></font><br>
<font size=3D4><span style=3D'font-size:13.5pt'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D</span></font></p>

</div>

</div>

<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_01C50ADC.3CFF79BC--



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 17:10:25 +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: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 11:09:58 -0600
Message-ID: <[e-mail]>
Thread-Topic: Layer 2 Switching Caps LSPs
Thread-Index: AcUKakHmrNGlIE4qSNGSPtHaBXdSqwAbNm7A
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Shahram Davari" <[e-mail]>
Cc: "David Allan" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>

Dmitri,

Some questions in-line below.

Regards,
Ben

> -----Original Message-----
> From: dimitri papadimitriou [mailto:[e-mail]]
> Sent: Thursday, February 03, 2005 9:33 PM
> To: Shahram Davari
> Cc: '[e-mail]'; Mack-Crane, T. Benjamin; David
> Allan; Adrian Farrel; [e-mail]
> Subject: Re: Layer 2 Switching Caps LSPs
>=20
> Sharam, see in-line
>=20
> Shahram Davari wrote:
> > Hi Dimitri,
> >
> > Thanks for your response. Please see my comments in-line.
> >
> > -Shahram
> >
> > -----Original Message----- From: [e-mail]
> > [mailto:[e-mail]] Sent: Thursday, February
> > 03, 2005 5:31 PM To: Shahram Davari Cc:
> > '[e-mail]'; Mack-Crane, T. Benjamin;
> > [e-mail]; David Allan; Adrian Farrel;
> > [e-mail] Subject: RE: Layer 2 Switching Caps LSPs
> >
> > sharam, the first issue is that you have to decouple the notion of
> > ethernet with bridging,
> >
> > Ethernet networks have 3 main layers:
> >
> > 1) PHY =3D 10/100/1G/10G as explained in 802.3,
> >
> > 2) MAC =3D 802.3
> >
> > 3) Bridging =3D 802.1D
> >
> > Without Bridging layer your device can only have a single port.
> > Example is the Ethernet port of your desktop computer. Therefore if
> > you want to build an Ethernet network, you need bridging layer.
>=20
> this is exactly where we did start from "port mode" in the first
version
> of the document and then "vlan mode" but in none of these modes
bridging
> is required as the path is known from its establishment (therefore
there
> is no MAC learning is needed here in the point-to-point case that we
are
> talking about) in brief, such interface would not make use of the
> canonical operations performed on ETH switches

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

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

>=20
> > the second is that this configuration operation can be automated -
> >
> > But after you have configured your connections (aka VLAN ports),
then
> > there is nothing left for GMPS to do. Or are you saying that the
> > GMPLS will do the configuration?
> >
> > however the interesting point you brought in the loop of discussion
> > here is "applicability for shared medium" - isn't the PW solution in
> > the same context
> >
> > No, because in PW, the payload (Ethernet) is encapsulated in another
> > layer network (aka MPLS), and is invisible to the intermediate
nodes.
> > While in your case there is no encapsulation, and all the
> > intermediate nodes can act on the MAC and VLAN tag.
>=20
> then if you ask me wether there can be an intermediate device
(bridging
> device) between two devices as discussed in this thread, the response
is
> yes - but does it change something fundamental here (as the scope of
the
> discussion is non-bridging environment), the response is: no - as such
> intermediate devices if they (unlikely) happen to be located as
> mentioned above would just behave as they do today when
interconnection
> two edge nodes (with point to point VLANs but this would require
manual
> provisioning as there is no GMPLS control on such bridging devices)

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

>=20
> this said and as defined MPLS and used currently used for PW, MPLS is
> not a "layer" in the sense you are using this word
>=20
> > as 1) it can not make an automated usage of a "medium" without
> > configuring the tunnels (in our case the tunnels that will be used
to
> > carry the ethernet payload e.g. SDH, OTH, etc. if not using
> > point-to-point PHY's) but in addition to the present solution PW
also
> > requires 2) the provisioning of the PW - something not needed in the
> > present context as terminating points will be directly accessing the
> > "ethernet medium", in brief if such argument is used here it should
> > have also been used in the PW context (if not more intensively)
> >
> > another fundamental point, i am also surprised seeing people
> > supporting MPLS (which brings a connection-oriented behaviour to IP)
> > wondering about the suitability of using one of the protocol suite
of
> > the IETF i.e. GMPLS to bring another (initially) connectionless
> > technology to a "connection-oriented" behaviour
> >
> > I don't argue against bringing connection-oriented behavior to
> > Ethernet. My concern is the method used to do so. if you had done
> > proper Network Interworking (aka, encapsulation or as ITU calls it
> > client/server), then there would not be any problem.
>=20
> would you further explain what is/would be fundamentally different if
i
> had a client/server layer ? this knowing that inverse translation can
be
> performed when leaving the network to reach the ethernet terminating
> point ?
>=20
> > However, what
> > you are trying to do is to modify Ethernet's control-plane in a way
> > that requires modification to its data-plane behavior.
>=20
> i disagree on the last part of the sentence, this document does not
> modify behaviour for existing bridging devices as it is not its scope,
> as the port more already defined in several RFCs did not modify the
> behaviour consider this as being a way to sub-segment the flows
crossing
> an interface based on their VLAN ID, in case you consider each device
as
> a device allowing VLAN ID translation the latter becomes indeed
locally
> significant so we may say that this approach when applied on each
device
> scopes the VLAN ID - but again this is already the case for tagged
> frames crossing PE's today -
>=20
> > As an analogy
> > what you are doing is like trying to use the IP address as MPLS tag
> > in order to make IP connection-oriented.
>=20
> this is not a good analogy because IP addresses are end-to-end
> significant if NATing is not used - the same applies here consider
this
> translation as occurring on particular devices PE's for instance i.e.
> VLANs do not have in the present context an end-to-end semantic
anymore
>=20
> > In contrast you could easily change ATM's control-plane to GMPLS
> > without any modification to ATM data-plane behavior, because ATM by
> > design is connection-oriented, and the VPI/VCI could easily be
> > interpreted as GMPLS tags.
>=20
> it is obvious that for ATM for instance situation is much more easy to
> tackle due its initial design
>=20
> > (even if i do rather prefer the term flow, in the present context)
at
> > the end the resulting gain is the same for both technologies it
terms
> > of capabilities as application of constraint-based routing
principles
> > - is this not at the end what drives mostly all debates in the
> > (G)MPLS galaxy beside VPNs and that was underlying incorporation of
> > these L2 technologies as part of the GMPLS protocol architecture
> >
> > thanks,
> >
> > - dimitri.
> >
> >
> > Shahram Davari <[e-mail]> Sent by:
> > [e-mail] 02/03/2005 13:13 PST
> >
> > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T.
> > Benjamin" <[e-mail]> cc: [e-mail],
> > David Allan <[e-mail]>, Adrian Farrel
> > <[e-mail]>, [e-mail] bcc: Subject: RE: Layer 2
> > Switching Caps LSPs
> >
> >
> >
> >
> > Dimitri,
> >
> > Unfortunately I didn't grasp completely what you are trying to
> > convey. But one thing I know for sure, and that is  "Ethernet is
> > Connectionless (CLS)" (like IP) and assumes shared medium, while
> > GMPLS is connection-oriented (CO) and doesn't work in shared medium.
> > Off course you could always configure and build an Ethernet network
> > that looks like it is CO (by configuring a max of 2 ports with the
> > same VLAN ID in each bridge), and by not using any shared medium.
But
> > then who needs GMPLS, when you already have to configure your
network
> > by other means?
> >
> > -Shahram
> >
> >
> > From: [e-mail]
> > [mailto:[e-mail]] Sent: Thursday, February
> > 03, 2005 3:07 PM To: Mack-Crane, T. Benjamin Cc:
> > [e-mail]; [e-mail]; David
> > Allan; Adrian Farrel; Shahram Davari; [e-mail] Subject:
RE:
> > Layer 2 Switching Caps LSPs
> >
> >
> >
> > ben,
> >
> > the discussion with dave has been reproduced in accelerated on the
> > mailing list - for me it appears that the more "philosophical"
> > conclusion can be positioned by answering to the following question
> > "Was SONET/SDH or lambda switching initially intended to be
> > controlled by GMPLS ?" if the response is "No, but nothing prevents
> > to do so" the next question is what does prevent from applying GMPLS
> > to other technologies knowing a substantial gain is obtained from
its
> > application - in certain conditions - (see motivations as part of
> > this introduction for instance) ? key issue being which are these
> > (technical) conditions and are there conditions that would preclude
> > progressing this document - the response is simply the negative -
> > there are no such conditions in the point-to-point - non-bridging -
> > context where this document applies.
> >
> > now, not sure there is a technical "firm" conclusion but the point
on
> > the ethernet label encoding appears as follows since so far there is
> > potential interest to keep the label for ethernet generic enough and
> > deduce its interpretation from type of link over which the label is
> > used and intepreet its value according to the traffic_parameters and
> > propose associations to cover cases such as case 2 of Appendix A of
> > <draft-pwe3-ethernet-encap-08.txt> mechanisms that is also
applicable
> > to other tunneling technology since this mechanism is orthogonal to
> > the use of PW's if required (example being Ethernet over SDH/OTH,
for
> > instance); however, if these are the only associations we see
> > relevant as part of this document then we would fall back on the
> > existing encoding with potential enhancement if so required -
> >
> > to come to the point of the articulation the - generic - response
> > holds in one line: it articulates GMPLS signaling for L2SC LSPs
> > (note: the latter has been introduced in RFC 3945, RFC 3471, RFC
> > 3473) - the motivations are detailed as part of the introduction of
> > this document - i can not comment more from your initial statement
> > since not detailed enough for me to be more specific
> >
> > the response to the last question is relatively simple since the
> > above mentioned do not include any specifics concerning ATM or FR -
> > this document intends to close this gap by defining specific
> > Traffic_Parameters for these technologies - is there an interest for
> > doing so: response is yes otherwise the document would not have
> > included the corr. details
> >
> > voila, thanks,
> >
> > - dimitri.
> >
> >
> >
> >
> >
> > "Mack-Crane, T. Benjamin" <[e-mail]> Sent by:
> > [e-mail] 02/03/2005 12:16 CST
> >
> > To: <[e-mail]>, Dimitri
> > PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan"
> > <[e-mail]> cc: "Adrian Farrel"
> > <[e-mail]>, "Shahram Davari"
> > <[e-mail]>, <[e-mail]> bcc: Subject:
> > RE: Layer 2 Switching Caps LSPs
> >
> >
> > Dimitri,
> >
> > Can the off-line discussion be summarized for the benefit of those
on
> >  the list who did not participate?  For me, the draft (and the
> > current discussion on the list) have not clearly articulated the
> > problem being addressed.  If a summary of the conclusions of the
> > off-line discussion will do this, it would be useful.
> >
> > I am also interested to know what is lacking in the current GMPLS
> > RFCs with respect to ATM and Frame Relay support that necessitates
> > including them in this new draft (presumably this is a part of the
> > problem to be solved).
> >
> > Regards, Ben
> >
> >
> >> -----Original Message----- From: [e-mail]
> >> [mailto:[e-mail]] On
> >
> > Behalf
> >
> >> Of dimitri papadimitriou Sent: Thursday, January 27, 2005 6:35 PM
> >> To: David Allan Cc: 'Adrian Farrel'; 'Shahram Davari';
> >> [e-mail] Subject: Re: Layer 2 Switching Caps LSPs
> >>
> >> dave - there was a lengthy off-line discussion suggested by the
> >> chairs intended to explain you the scope of the draft and its
> >> relatioship
> >
> > with
> >
> >> the ethernet data plane (after the question you raised during the
> >> f2f meeting) - this has been done and we have explained (via a
> >> lengthy exchange of e-mails) that this document and so the use of
> >> gmpls to control ethernet frame flows, is not targeting control of
> >> bridged ethernet environments - if this is not clear from the
> >> current document introduction we would have also to work on this
> >> part of the document - therefore, the below reference to MSTP is
> >> not in the current scope; on the other side, the use of the term
> >> "VLAN label" has created some confusion; therefore, in a next
> >> release i will simply refer to a
> >
> > "label"
> >
> >> of 32 bits (unstructured) because the intention was (and still is)
> >> to find an easy way to map the control of the ethernet frame flows
> >> on
> >
> > each
> >
> >> device they traverses without making any assumption on how this
> >> flow
> >
> > is
> >
> >> processed inside each node at the data plane level (note: on label
> >> values, RFC 3946 took an equivalent approach - for circuits - where
> >>  sonet/sdh multiplexing structures have been used to create unique
> >> multiplex entry names i.e. labels - this concept is here applied
> >> for "virtual" circuits), so, if the working group is willing to
> >> enter into
> >
> > a
> >
> >> data plane oriented discussion to clarify the behaviour(s) onto
> >> which the present approach would be potentially applicable this is
> >> fine with me as long as we are within the scope of the initial
> >> motivations
> >>
> >> thanks, - dimitri.
> >>
> >> David Allan wrote:
> >>
> >>> Hi Adrian:
> >>>
> >>> Your suggestion is in a way reasonable but with the caveat that
> >>> in
> >
> > IEEE
> >
> >>> terms, a bridging topology is currently all VLANs (802.1Q single
> >>
> >> spanning
> >>
> >>> tree) or partitioned into specific ranges (I believe 64 in 802.1s
> >>>
> >>
> >> although I
> >>
> >>> do not claim to be an expert).
> >>>
> >>> If the PEs were to implement a bridge function and we were using
> >
> > GMPLS
> >
> >> to
> >>
> >>> interconnect them, then the control plane should be identifying
> >
> > either
> >
> >> all
> >>
> >>> VLANs (single spanning tree, which I beleive the draft covers by
> >>
> >> referring
> >>
> >>> simply to Ethernet port) or a VLAN range to be associated with
> >>> the
> >
> > LSP
> >
> >>> consistent with 802.1s if it is to operate to interconnect
> >>> bridges
> >>
> >> defined
> >>
> >>> by the IEEE...
> >>>
> >>> I suspect assuming any other behavior (e.g. LSP for single VLAN
> >>> tag)
> >>
> >> would
> >>
> >>> go outside the boundary of what is currently defined...so
> >>> alignment
> >
> > with
> >
> >>> 802.1s IMO would be a minimum requirement if we are to consider
> >
> > carrying
> >
> >>> VLAN information in GMPLS signalling....
> >>>
> >>> cheers Dave
> >>>
> >>> You wrote....
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>> The authors of the draft might like to clarify for the list
> >>>> exactly what data plane operations they are suggesting. To me
> >>>> it seems possible that the draft is proposing VLAN ID
> >>>> *swapping*. But an alternative is that the VLAN ID is used as a
> >>>> label, but that the same label is used for the full length of
> >>>> the LSP.
> >>>>
> >>>> Adrian
> >>>
> >>>
> >>>
> >>> .
> >>>
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 15:22:43 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50ACD.4E123B26"
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 09:22:14 -0600
Message-ID: <[e-mail]>
Thread-Topic: Layer 2 Switching Caps LSPs
Thread-Index: AcUKLA7+6agLJ61oR+2lW9QyIBRW4wAB40zQ
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "David Allan" <[e-mail]>, "Adrian Farrel" <[e-mail]>, "Shahram Davari" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C50ACD.4E123B26
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dimitri,

=20

See in-line below.

=20

Regards,

Ben

=20

________________________________

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

=20

ben,=20

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

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

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

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

=20

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

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

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

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

=20

voila, thanks,

- dimitri.

=20



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

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



Dimitri,

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

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

Regards,
Ben

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

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Dimitri,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>See in-line below.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Ben</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4=2E0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, February 03,=
 2005
2:07 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Mack-Crane, T. Benjamin<=
br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [e-mail];
[e-mail]; David Allan; Adrian Farrel; Shahram Davar=
i;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Layer 2 Switchi=
ng
Caps LSPs</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;</span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'=
>ben, </span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'=
>the
discussion with dave has been reproduced in accelerated on the mailing list=
 -
for me it appears that the more &quot;philosophical&quot; conclusion can be
positioned by answering to the following question &quot;Was SONET/SDH or la=
mbda
switching initially intended to be controlled by GMPLS ?&quot; if the respo=
nse
is &quot;No, but nothing prevents to do so&quot; the next question is what =
does
prevent from applying GMPLS to other technologies knowing a substantial gai=
n is
obtained from its application - in certain conditions - (see motivations as
part of this introduction for instance) ? key issue being which are these
(technical) conditions and are there conditions that would preclude progres=
sing
this document - the response is simply the negative - there are no such
conditions in the point-to-point - non-bridging - context where this docume=
nt
applies.</span></font></p>

<p><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt=
;font-family:
Arial;color:navy'>SONET/SDH is well-defined in terms of its information
forwarding behavior, both in normal state and under fault conditions.</span=
></font></p>

<p><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt=
;font-family:
Arial;color:navy'>I do not believe GMPLS has adequately addressed lambda (a=
nalog
optical) switching yet, probably because the technology is not mature.</spa=
n></font></p>

<p><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt=
;font-family:
Arial;color:navy'>Where can I find the definition of the forwarding behavio=
r you
refer to as &#8220;point-to-point &#8211; non-bridging&#8221;?</span></font=
></p>

<p><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt=
;font-family:
Arial;color:navy'>&nbsp;</span></font></p>

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

<p><font size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'=
>to come
to the point of the articulation the - generic - response holds in one line=
: it
articulates GMPLS signaling for L2SC LSPs (note: the latter has been introd=
uced
in RFC 3945, RFC 3471, RFC 3473) - the motivations are detailed as part of =
the
introduction of this document - i can not comment more from your initial
statement since not detailed enough for me to be more specific </span></fon=
t></p>

<p><font size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'=
>the
response to the last question is relatively simple since the above mentione=
d do
not include any specifics concerning ATM or FR - this document intends to c=
lose
this gap by defining specific Traffic_Parameters for these technologies - is
there an interest for doing so: response is yes otherwise the document would
not have included the corr. Details</span></font></p>

<p><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt=
;font-family:
Arial;color:navy'>ATM and FR already have standard traffic parameters. &nbs=
p;GMPLS
uses Intserv in some cases, which could be applied to L2SC.&nbsp; ATM and FR
labels are defined in RFC 3471.&nbsp; This draft adds (without definition) =
&#8220;delay&#8221;
and &#8220;jitter,&#8221; which are not specific to L2SC technology and are=
 not
traffic parameters in the sense defined by the TSPEC (traffic characteristi=
cs
of the data flow that the</span></font><font color=3Dnavy face=3DArial><span
style=3D'font-family:Arial;color:navy'> </span></font><font size=3D2 color=
=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
sender
will generate) but rather are constraints on the route.&nbsp; It also adds =
&#8220;switching
granularity&#8221; which is perhaps more closely aligned with Encoding Type
than TSPEC.&nbsp; Some discussion of the rationale for the encodings propos=
ed
would be helpful.</span></font></p>

<p><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt=
;font-family:
Arial;color:navy'>&nbsp;</span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'=
>voila,
thanks,</span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'=
>-
dimitri.</span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'=
>&nbsp;</span></font></p>

<p style=3D'margin-bottom:12.0pt'><font size=3D3 face=3D"Times New Roman"><=
span
style=3D'font-size:12.0pt'><br>
<br>
</span></font><b><font size=3D2><span style=3D'font-size:10.0pt;font-weight=
:bold'>&quot;Mack-Crane,
T=2E Benjamin&quot; &lt;[e-mail]&gt;</span></font></b><br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent by: [e-mail]=
tf.org</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>02/03/2005 12:16 CST</span>=
</font><br>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>To:</span></font> <font siz=
e=3D2><span
style=3D'font-size:10.0pt'>&lt;[e-mail]&gt;, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, &quot;David Allan&quot;
&lt;[e-mail]&gt;</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>cc:</span></font> <font siz=
e=3D2><span
style=3D'font-size:10.0pt'>&quot;Adrian Farrel&quot; &lt;[e-mail].u=
k&gt;,
&quot;Shahram Davari&quot; &lt;[e-mail]&gt;,
&lt;[e-mail]&gt;</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>bcc:</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject:</span></font> <font
size=3D2><span style=3D'font-size:10.0pt'>RE: Layer 2 Switching Caps LSPs</=
span></font><br>
<br>
</p>

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

</div>

</div>

<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_01C50ACD.4E123B26--



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 14:47:05 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "Mack-Crane, T. Benjamin" <[e-mail]>, David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 06:43:51 -0800 
MIME-Version: 1.0
Content-Type: text/plain

Dimitri,

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

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

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



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 10:33:22 +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-leroux-ccamp-ctrl-saturation-00.txt 
Date: Fri, 4 Feb 2005 11:30:11 +0100
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt 
Thread-Index: AcUJKZ4CgGrk+Vg/QpOtuaI3lafpXQBX+ZZA
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>

Hi Adrian,

Thanks a lot for these comments

Please see inline

Regards

JL



>-----Message d'origine-----
>De : Adrian Farrel [mailto:[e-mail]]=20
>Envoy=E9 : mardi 1 f=E9vrier 2005 19:41
>=C0 : LE ROUX Jean-Louis RD-CORE-LAN
>Cc : [e-mail]
>Objet : Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt=20
>
>
>Jean-Louis,
>
>Thanks for this draft.
>
>A couple of immediate thoughts.
>
>1. What is wrong with using Error Code 23?

Error code 23 is used for "System Errors".=20
IMHO the saturation semantic defined here is quite different.


>2. Will implementations really want to confess to the reason=20
>that they are unable to handle more LSPs? It seems to me that=20
>it would be a remarkably honest implementation that=20
>implemented this draft.=20

Bascially the draft proposes to handle properly control plane saturation =
cases.
If you want to handle these cases you need a dedicated error code, this =
would allow
Head-end LSRs to take appropriate actions.

>Isn't it more likely that the LSR=20
>would claim an admission control error? 3.=20

Saturation is not and admission control problem=20

>"The head-end=20
>should not reroute already established LSPs passing through=20
>the saturated node." Why ever not? Surely this is local=20
>policy, and the ingress may know that the only way to route=20
>its new and projected LSPs is to move some of the existing=20
>ones.=20

Stability is better, the LSR is already supporting a set of TE-LSPs, it =
is saturated, why would you want to move these LSPs?

4. Why is saturation a good thing to advertise in the=20
>IGP? If an LSR wishes to prevent new LSPs being routed through=20
>it, it should withdraw bandwidth just as it would if the=20
>signaling elements of the control plane had failed. 5.=20

But what about 0 bandwidth LSPs?=20
A head-end may select a node with 0 bandwidth available, when computing =
the path
of a 0 bandwidth LSP.=20
So withdrawing bandwidth is not sufficient to handle properly control =
plane saturations


>Much of=20
>the draft restates default behavior (e.g. what to do when you=20
>receive a Path message). This is interesting information for=20
>the reader, but I am not sure that it is right to present it=20
>here.=20

Agree

6. Why does the new Error Codes have three Error Values,=20
>but the Saturation TLV only have one bit defined?=20

Good point, we need to define 3 flags

>7. Section=20
>5.2. All "MUST" should be "SHOULD" I think.

Why? This is IMHO a mandatory behavior for an implementation compliant =
with this draft.

>
>My main question is why you need this draft. It seems that you=20
>can already achieve all of these features using existing=20
>protocol elements.=20

I think that this would be cleaner with these light signaling and =
routing extensions.

>At most you might want to write a one page=20
>BCP to say what a transit or egress LSP should do when it=20
>cannot handle a new LSP because of some internal resource=20
>shortage other than an admission control problem.

But the problem is that we consider that when a transit or egress LSR =
cannot handle a new LSP because of some internal resource shortage other =
than an admission control problem,
it should notify the head end about its saturation, and if you want =
proper=20
reaction you need a specific notification...thus dedicated error code =
points are required

Again thanks a lot for these comments

Regards

JL


>
>Cheers,
>Adrian
>
>
>----- Original Message -----=20
>From: "LE ROUX Jean-Louis RD-CORE-LAN"=20
><[e-mail]>
>To: <[e-mail]>
>Sent: Tuesday, February 01, 2005 7:21 AM
>Subject: TR: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
>
>
>Hi all,
>
>We just posted a new draft related to (G)MPLS-TE control plane=20
>resource shortages. Your comments/feedbacks on this draft are welcome.
>
>Regards,
>
>JL
>
>
>
>
>A New Internet-Draft is available from the on-line=20
>Internet-Drafts directories.
>
>
>Title : Procedure to handle (G)MPLS-TE control plane
>saturation
>Author(s) : J. Le Roux, et al.
>Filename : draft-leroux-ccamp-ctrl-saturation-00.txt
>Pages : 10
>Date : 2005-1-31
>
>This document defines extensions to RSVP-TE (Resource Reservation
>   Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to
>   signal control plane resources saturation, when an LSR runs out of
>   control plane resources available to support a new LSP. Such
>   notification may serve as trigger for the impacted Head-end LSR to
>   take appropriate actions.
>
>A URL for this Internet-Draft is:=20
>http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat
uration-0
0.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-leroux-ccamp-ctrl-saturation-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:
mailserv at ietf.org.
In the body type:
"FILE /internet-drafts/draft-leroux-ccamp-ctrl-saturation-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-leroux-ccamp-ctrl-saturation-0
0.txt> =
<ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturation-0
0.txt>





Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 03:34:38 +0000
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2005 04:33:11 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Shahram Davari <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>,  David Allan <[e-mail]>, Adrian Farrel <[e-mail]>,  [e-mail]
Subject: Re: Layer 2 Switching Caps LSPs
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Sharam, see in-line

Shahram Davari wrote:
> Hi Dimitri,
> 
> Thanks for your response. Please see my comments in-line.
> 
> -Shahram
> 
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] Sent: Thursday, February
> 03, 2005 5:31 PM To: Shahram Davari Cc:
> '[e-mail]'; Mack-Crane, T. Benjamin;
> [e-mail]; David Allan; Adrian Farrel;
> [e-mail] Subject: RE: Layer 2 Switching Caps LSPs 
> 
> sharam, the first issue is that you have to decouple the notion of
> ethernet with bridging,
> 
> Ethernet networks have 3 main layers:
> 
> 1) PHY = 10/100/1G/10G as explained in 802.3,
> 
> 2) MAC = 802.3
> 
> 3) Bridging = 802.1D
> 
> Without Bridging layer your device can only have a single port.
> Example is the Ethernet port of your desktop computer. Therefore if
> you want to build an Ethernet network, you need bridging layer.

this is exactly where we did start from "port mode" in the first version 
of the document and then "vlan mode" but in none of these modes bridging 
is required as the path is known from its establishment (therefore there 
is no MAC learning is needed here in the point-to-point case that we are 
talking about) in brief, such interface would not make use of the 
canonical operations performed on ETH switches

> the second is that this configuration operation can be automated -
> 
> But after you have configured your connections (aka VLAN ports), then
> there is nothing left for GMPS to do. Or are you saying that the
> GMPLS will do the configuration?
> 
> however the interesting point you brought in the loop of discussion
> here is "applicability for shared medium" - isn't the PW solution in
> the same context
> 
> No, because in PW, the payload (Ethernet) is encapsulated in another
> layer network (aka MPLS), and is invisible to the intermediate nodes.
> While in your case there is no encapsulation, and all the
> intermediate nodes can act on the MAC and VLAN tag.

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

this said and as defined MPLS and used currently used for PW, MPLS is 
not a "layer" in the sense you are using this word

> as 1) it can not make an automated usage of a "medium" without
> configuring the tunnels (in our case the tunnels that will be used to
> carry the ethernet payload e.g. SDH, OTH, etc. if not using
> point-to-point PHY's) but in addition to the present solution PW also
> requires 2) the provisioning of the PW - something not needed in the
> present context as terminating points will be directly accessing the
> "ethernet medium", in brief if such argument is used here it should
> have also been used in the PW context (if not more intensively)
> 
> another fundamental point, i am also surprised seeing people
> supporting MPLS (which brings a connection-oriented behaviour to IP)
> wondering about the suitability of using one of the protocol suite of
> the IETF i.e. GMPLS to bring another (initially) connectionless
> technology to a "connection-oriented" behaviour
> 
> I don't argue against bringing connection-oriented behavior to
> Ethernet. My concern is the method used to do so. if you had done
> proper Network Interworking (aka, encapsulation or as ITU calls it
> client/server), then there would not be any problem. 

would you further explain what is/would be fundamentally different if i 
had a client/server layer ? this knowing that inverse translation can be 
performed when leaving the network to reach the ethernet terminating 
point ?

> However, what
> you are trying to do is to modify Ethernet's control-plane in a way
> that requires modification to its data-plane behavior. 

i disagree on the last part of the sentence, this document does not 
modify behaviour for existing bridging devices as it is not its scope, 
as the port more already defined in several RFCs did not modify the 
behaviour consider this as being a way to sub-segment the flows crossing 
an interface based on their VLAN ID, in case you consider each device as 
a device allowing VLAN ID translation the latter becomes indeed locally 
significant so we may say that this approach when applied on each device 
scopes the VLAN ID - but again this is already the case for tagged 
frames crossing PE's today -

> As an analogy
> what you are doing is like trying to use the IP address as MPLS tag
> in order to make IP connection-oriented.

this is not a good analogy because IP addresses are end-to-end 
significant if NATing is not used - the same applies here consider this 
translation as occurring on particular devices PE's for instance i.e. 
VLANs do not have in the present context an end-to-end semantic anymore

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

it is obvious that for ATM for instance situation is much more easy to 
tackle due its initial design

> (even if i do rather prefer the term flow, in the present context) at
> the end the resulting gain is the same for both technologies it terms
> of capabilities as application of constraint-based routing principles
> - is this not at the end what drives mostly all debates in the
> (G)MPLS galaxy beside VPNs and that was underlying incorporation of
> these L2 technologies as part of the GMPLS protocol architecture
> 
> thanks,
> 
> - dimitri.
> 
> 
> Shahram Davari <[e-mail]> Sent by:
> [e-mail] 02/03/2005 13:13 PST
> 
> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T.
> Benjamin" <[e-mail]> cc: [e-mail],
> David Allan <[e-mail]>, Adrian Farrel
> <[e-mail]>, [e-mail] bcc: Subject: RE: Layer 2
> Switching Caps LSPs
> 
> 
> 
> 
> Dimitri,
> 
> Unfortunately I didn't grasp completely what you are trying to
> convey. But one thing I know for sure, and that is  "Ethernet is
> Connectionless (CLS)" (like IP) and assumes shared medium, while
> GMPLS is connection-oriented (CO) and doesn't work in shared medium.
> Off course you could always configure and build an Ethernet network
> that looks like it is CO (by configuring a max of 2 ports with the
> same VLAN ID in each bridge), and by not using any shared medium. But
> then who needs GMPLS, when you already have to configure your network
> by other means?
> 
> -Shahram
> 
> 
> From: [e-mail]
> [mailto:[e-mail]] Sent: Thursday, February
> 03, 2005 3:07 PM To: Mack-Crane, T. Benjamin Cc:
> [e-mail]; [e-mail]; David
> Allan; Adrian Farrel; Shahram Davari; [e-mail] Subject: RE:
> Layer 2 Switching Caps LSPs
> 
> 
> 
> ben,
> 
> the discussion with dave has been reproduced in accelerated on the
> mailing list - for me it appears that the more "philosophical"
> conclusion can be positioned by answering to the following question
> "Was SONET/SDH or lambda switching initially intended to be
> controlled by GMPLS ?" if the response is "No, but nothing prevents
> to do so" the next question is what does prevent from applying GMPLS
> to other technologies knowing a substantial gain is obtained from its
> application - in certain conditions - (see motivations as part of
> this introduction for instance) ? key issue being which are these
> (technical) conditions and are there conditions that would preclude
> progressing this document - the response is simply the negative -
> there are no such conditions in the point-to-point - non-bridging -
> context where this document applies.
> 
> now, not sure there is a technical "firm" conclusion but the point on
> the ethernet label encoding appears as follows since so far there is
> potential interest to keep the label for ethernet generic enough and
> deduce its interpretation from type of link over which the label is
> used and intepreet its value according to the traffic_parameters and
> propose associations to cover cases such as case 2 of Appendix A of
> <draft-pwe3-ethernet-encap-08.txt> mechanisms that is also applicable
> to other tunneling technology since this mechanism is orthogonal to
> the use of PW's if required (example being Ethernet over SDH/OTH, for
> instance); however, if these are the only associations we see
> relevant as part of this document then we would fall back on the
> existing encoding with potential enhancement if so required -
> 
> to come to the point of the articulation the - generic - response
> holds in one line: it articulates GMPLS signaling for L2SC LSPs
> (note: the latter has been introduced in RFC 3945, RFC 3471, RFC
> 3473) - the motivations are detailed as part of the introduction of
> this document - i can not comment more from your initial statement
> since not detailed enough for me to be more specific
> 
> the response to the last question is relatively simple since the
> above mentioned do not include any specifics concerning ATM or FR -
> this document intends to close this gap by defining specific
> Traffic_Parameters for these technologies - is there an interest for
> doing so: response is yes otherwise the document would not have
> included the corr. details
> 
> voila, thanks,
> 
> - dimitri.
> 
> 
> 
> 
> 
> "Mack-Crane, T. Benjamin" <[e-mail]> Sent by:
> [e-mail] 02/03/2005 12:16 CST
> 
> To: <[e-mail]>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan"
> <[e-mail]> cc: "Adrian Farrel"
> <[e-mail]>, "Shahram Davari"
> <[e-mail]>, <[e-mail]> bcc: Subject:
> RE: Layer 2 Switching Caps LSPs
> 
> 
> Dimitri,
> 
> Can the off-line discussion be summarized for the benefit of those on
>  the list who did not participate?  For me, the draft (and the
> current discussion on the list) have not clearly articulated the
> problem being addressed.  If a summary of the conclusions of the
> off-line discussion will do this, it would be useful.
> 
> I am also interested to know what is lacking in the current GMPLS
> RFCs with respect to ATM and Frame Relay support that necessitates
> including them in this new draft (presumably this is a part of the
> problem to be solved).
> 
> Regards, Ben
> 
> 
>> -----Original Message----- From: [e-mail]
>> [mailto:[e-mail]] On
> 
> Behalf
> 
>> Of dimitri papadimitriou Sent: Thursday, January 27, 2005 6:35 PM 
>> To: David Allan Cc: 'Adrian Farrel'; 'Shahram Davari';
>> [e-mail] Subject: Re: Layer 2 Switching Caps LSPs
>> 
>> dave - there was a lengthy off-line discussion suggested by the
>> chairs intended to explain you the scope of the draft and its
>> relatioship
> 
> with
> 
>> the ethernet data plane (after the question you raised during the
>> f2f meeting) - this has been done and we have explained (via a
>> lengthy exchange of e-mails) that this document and so the use of
>> gmpls to control ethernet frame flows, is not targeting control of
>> bridged ethernet environments - if this is not clear from the
>> current document introduction we would have also to work on this
>> part of the document - therefore, the below reference to MSTP is
>> not in the current scope; on the other side, the use of the term
>> "VLAN label" has created some confusion; therefore, in a next
>> release i will simply refer to a
> 
> "label"
> 
>> of 32 bits (unstructured) because the intention was (and still is)
>> to find an easy way to map the control of the ethernet frame flows
>> on
> 
> each
> 
>> device they traverses without making any assumption on how this
>> flow
> 
> is
> 
>> processed inside each node at the data plane level (note: on label 
>> values, RFC 3946 took an equivalent approach - for circuits - where
>>  sonet/sdh multiplexing structures have been used to create unique 
>> multiplex entry names i.e. labels - this concept is here applied
>> for "virtual" circuits), so, if the working group is willing to
>> enter into
> 
> a
> 
>> data plane oriented discussion to clarify the behaviour(s) onto
>> which the present approach would be potentially applicable this is
>> fine with me as long as we are within the scope of the initial
>> motivations
>> 
>> thanks, - dimitri.
>> 
>> David Allan wrote:
>> 
>>> Hi Adrian:
>>> 
>>> Your suggestion is in a way reasonable but with the caveat that
>>> in
> 
> IEEE
> 
>>> terms, a bridging topology is currently all VLANs (802.1Q single
>> 
>> spanning
>> 
>>> tree) or partitioned into specific ranges (I believe 64 in 802.1s
>>> 
>> 
>> although I
>> 
>>> do not claim to be an expert).
>>> 
>>> If the PEs were to implement a bridge function and we were using
> 
> GMPLS
> 
>> to
>> 
>>> interconnect them, then the control plane should be identifying
> 
> either
> 
>> all
>> 
>>> VLANs (single spanning tree, which I beleive the draft covers by
>> 
>> referring
>> 
>>> simply to Ethernet port) or a VLAN range to be associated with
>>> the
> 
> LSP
> 
>>> consistent with 802.1s if it is to operate to interconnect
>>> bridges
>> 
>> defined
>> 
>>> by the IEEE...
>>> 
>>> I suspect assuming any other behavior (e.g. LSP for single VLAN
>>> tag)
>> 
>> would
>> 
>>> go outside the boundary of what is currently defined...so
>>> alignment
> 
> with
> 
>>> 802.1s IMO would be a minimum requirement if we are to consider
> 
> carrying
> 
>>> VLAN information in GMPLS signalling....
>>> 
>>> cheers Dave
>>> 
>>> You wrote....
>>> 
>>> 
>>>> Hi,
>>>> 
>>>> The authors of the draft might like to clarify for the list 
>>>> exactly what data plane operations they are suggesting. To me 
>>>> it seems possible that the draft is proposing VLAN ID 
>>>> *swapping*. But an alternative is that the VLAN ID is used as a
>>>> label, but that the same label is used for the full length of
>>>> the LSP.
>>>> 
>>>> Adrian
>>> 
>>> 
>>> 
>>> .
>>> 
> 
> ============================================================ The
> information contained in this message may be privileged and
> confidential and protected from disclosure. If the reader of this
> message is not the intended recipient, or an employee or agent
> responsible for delivering this message to the intended recipient,
> you are hereby notified that any reproduction, dissemination or
> distribution of this communication is strictly prohibited. If you
> have received this communication in error, please notify us
> immediately by replying to the message and deleting it from your
> computer. Thank you. Tellabs 
> ============================================================
> 
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 04 Feb 2005 02:15:47 +0000
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>
From: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>
To: <[e-mail]>
Cc: 
Bcc: 
Date: Fri, 4 Feb 2005 11:14:52 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCC9w726xdu8s7DoxsAsILTjtOc=?=
Message-ID: <e04c01c50a5f$4fc13480$[e-mail]>
Content-Transfer-Encoding: 7bit
Thread-Index: AcUKXt0zE11U8RFIRGu07GKEuVyWnQ==
Thread-Topic: I-D ACTION:draft-jaihyung-ccamp-arpsignal-00.txt
Subject: I-D ACTION:draft-jaihyung-ccamp-arpsignal-00.txt
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_DF33_01C50AAA.4D1F9280"
Content-class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_DF33_01C50AAA.4D1F9280
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_DF34_01C50AAA.4D1F9280"


------=_NextPart_001_DF34_01C50AAA.4D1F9280
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64


------=_NextPart_001_DF34_01C50AAA.4D1F9280
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy
Ij4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5EZWFyIEFsbDwv
RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SSBhbSBwbGVhc2VkIHRvIGFubm91bmNlIGZv
bGxvd2luZyBuZXcgaW5kaXZpZHVhbCBkcmFmdCByZWdhcmRpbmcgR01QTFM8L0RJVj4NCjxESVY+
Y29udHJvbCZuYnNwO292ZXIgRXRoZXJuZXQuPC9ESVY+DQo8RElWPlRoZSB0YXJnZXQgYXJlYSBv
ZiB0aGlzIGRyYWZ0IGlzIEV0aGVybmV0IGZpcnN0LW1pbGUsIGhvd2V2ZXIsIHdlIGhvcGU8L0RJ
Vj4NCjxESVY+dGhpcyB0ZWNobmlxdWUgd2lsbCBiZSBsZXZlcmFnZSB0byBleHRlbmQgc2ltaWxh
ciZuYnNwO2FwcHJvYWNoIHRvIDwvRElWPg0KPERJVj5FdGhlcm5ldCBiYXNlZCBhY2Nlc3MgbmV0
d29yayBhbmQgY29yZSBuZXR3b3JrLiA8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlJl
YWRlcnMgYXJlIGFsc28gYWR2aXNlZCB0byBub3RlIGNvbXBhbmlvbiBkb2N1bWVudHMgb2Y8L0RJ
Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPg0KPERJVj4xLiZuYnNwOyBSZXF1aXJlbWVudCBm
b3IgKEcpTVBMUyBpbXBsYW50YXRpb24gb3ZlciBFdGhlcm5ldDwvRElWPg0KPERJVj4mbmJzcDsg
Jmx0O2RyYWZ0LWphaWh5dW5nLWNjYW1wLWxzZXJlcXVpcmVtZW50cy0wMC50eHQmZ3Q7PC9ESVY+
DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4yLiZuYnNwOyBGcmFtZXdvcmsgZm9yIChHKU1QTFMg
aW1wbGVtZW50YXRpb24gaW4gRXRoZXJuZXQgYmFzZWQgQ3VzdG9tZXIgUHJlbWlzZSBOZXR3b3Jr
PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZsdDtkcmFmdC1qYWloeXVuZy1jY2FtcC1sc2VmcmFt
ZXdvcmstMDAudHh0Jmd0OzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9E
SVY+PC9ESVY+DQo8RElWPllvdXIgY29tbWVudHMgYXJlIHZhbHVhYmxlIHRvIHVzLjwvRElWPg0K
PERJVj5QbGVhc2Ugc2VuZCB1cyB5b3VyIGZlZWRiYWNrLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ
Vj4NCjxESVY+VGhhbmsgeW91PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5SZWdhcmRz
PC9ESVY+DQo8RElWPjxCUj4NCjxESVYgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J
TFk6ILG8uLIiPg0KPERJVj4NCjxESVYgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J
TFk6ILG8uLIiPg0KPERJVj5KYWloeXVuZyBDaG88L0RJVj4NCjxESVY+RVRSSSwgS29yZWE8L0RJ
Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj49PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9ESVY+
DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi
bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8QlI+ZGlyZWN0b3JpZXMuPEJSPjxC
Uj48QlI+VGl0bGUgOiBVc2Ugb2YgQVJQIGFuZCBGbG9vZCBSb3V0aW5nIFRlY2huaXF1ZSBmb3Ig
TFNQIHNldHVwIGluIEVDUE48QlI+QXV0aG9yKHMpIDogSmFpaHl1bmcgQ2hvPEJSPkZpbGVuYW1l
IDogPEEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamFp
aHl1bmctY2NhbXAtYXJwc2lnbmFsLTAwLnR4dCIgdGFyZ2V0PV9ibGFuaz5kcmFmdC1qYWloeXVu
Zy1jY2FtcC1hcnBzaWduYWwtMDAudHh0PC9BPiZuYnNwOyZuYnNwOzxCUj5QYWdlcyA6IDE4PEJS
PkRhdGUgOiAyMDA1LTItMTxCUj48QlI+PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBJbiB0aGlzIG1lbW8sIHdlIGZpcnN0IGRpc2N1c3Mgc29tZSB3ZWFrbmVzc2VzIG9mIHBy
b3Bvc2FsczxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW1wbG95aW5nIFJTVlAgaW4gbG9j
YWwgbmV0d29yaywgc3VjaCBhcyBSRkMyODE0LCAyODE1LCAyODE2LCBhbmQ8QlI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHByb3Bvc2UgZXh0ZW5zaW9uIG9mIEFSUCAoQWRkcmVzcyBSZXNvbHV0
aW9uIFByb3RvY29sKSBhbmQgW0xTRV08QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRlY2hu
aXF1ZSBmb3Igc29sdXRpb24gdG8gcHJvdmlkZSBRb1MgaW4gRXRoZXJuZXQgYmFzZWQgQ3VzdG9t
ZXI8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByZW1pc2UgTmV0d29yayAoRUNQTikuIEZy
YW1ld29yayBhcmNoaXRlY3R1cmUgb2YgTFNFIChMYWJlbDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgU3dpdGNoZWQgRXRoZXJuZXQpIGFzIGEgbWV0aG9kIG9mIEdNUExTIGltcGxlbWVudGF0
aW9uIGZvciBFdGhlcm5ldDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgZGVzY3JpYmVk
IGluIFtMU0VdLiBBUlAgaXMgcHJvcG9zZWQgZm9yIGludGVncmF0ZWQgc2lnbmFsaW5nIGFuZDxC
Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcm91dGluZyBwcm90b2NvbCBpbiBFQ1BOLiBUaGlz
IGRvY3VtZW50IGRlc2NyaWJlcyBvdmVydmlldyBvZiBBUlA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGV4dGVuc2lvbiwgcHJvY2VkdXJlIGZvciBsYWJlbCBuZWdvdGlhdGlvbiBhbmQgbWV0
aG9kIGZvciBRb1M8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJvdXRpbmcuJm5ic3A7IE1h
am9yIGZlYXR1cmVzIG9mIHRoaXMgQVJQIGV4dGVuc2lvbiBhcmU7IHN1cHBvcnQgZm9yPEJSPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsYWJlbCBzd2l0Y2hpbmcsIGluY29ycG9yYXRpb24gb2Yg
cm91dGluZyBmdW5jdGlvbiwgY29tcGF0aWJpbGl0eTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgd2l0aCBsZWdhY3kgRXRoZXJuZXQgYW5kIGVuaGFuY2VkIHNlY3VyaXR5LjxCUj48QlI+PC9E
SVY+DQo8RElWPjxCUj48QlI+QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6PEJSPjxB
IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyI+aHR0cDovL3d3dy5p
ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9BPjxBIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv
aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWphaWh5dW5nLWNjYW1wLWFycHNpZ25hbC0wMC50eHQiIHRh
cmdldD1fYmxhbms+ZHJhZnQtamFpaHl1bmctY2NhbXAtYXJwc2lnbmFsLTAwLnR4dDwvQT4mbmJz
cDsmbmJzcDs8QlI+PEJSPjxCUj5UbyByZW1vdmUgeW91cnNlbGYgZnJvbSB0aGUgSS1EIEFubm91
bmNlbWVudCBsaXN0LCBzZW5kIGEgbWVzc2FnZSB0bzxCUj5pLWQtYW5ub3VuY2UtcmVxdWVzdCBh
dCBpZXRmLm9yZyB3aXRoIHRoZSB3b3JkIHVuc3Vic2NyaWJlIGluIHRoZSBib2R5PEJSPm9mIHRo
ZSBtZXNzYWdlLjxCUj5Zb3UgY2FuIGFsc28gdmlzaXQgPEEgaHJlZj0iaHR0cHM6Ly93d3cxLmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vSS1ELWFubm91bmNlIiB0YXJnZXQ9X2JsYW5rPmh0dHBz
Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL0ktRC1hbm5vdW5jZTwvQT48QlI+dG8g
Y2hhbmdlIHlvdXIgc3Vic2NyaXB0aW9uIHNldHRpbmdzLjxCUj48QlI+PEJSPkludGVybmV0LURy
YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUC4gTG9naW4gd2l0aCB0aGU8
QlI+dXNlcm5hbWU8QlI+ImFub255bW91cyIgYW5kIGEgcGFzc3dvcmQgb2YgeW91ciBlLW1haWwg
YWRkcmVzcy4gQWZ0ZXIgbG9nZ2luZyBpbiw8QlI+dHlwZSAiY2QgaW50ZXJuZXQtZHJhZnRzIiBh
bmQgdGhlbjxCUj4iZ2V0IGRyYWZ0LWxlcm91eC1jY2FtcC1jdHJsLXNhdHVyYXRpb24tMDAudHh0
Ii48QlI+PEJSPkEgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMgY2FuIGJlIGZv
dW5kIGluPEJSPjxBIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwiIHRhcmdl
dD1fYmxhbms+aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbDwvQT48QlI+b3IgPEEgaHJl
Zj0iZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQiIHRhcmdldD1fYmxh
bms+ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8L0E+PEJSPjxCUj48
QlI+SW50ZXJuZXQtRHJhZnRzIGNhbiBhbHNvIGJlIG9idGFpbmVkIGJ5IGUtbWFpbC48QlI+PEJS
PlNlbmQgYSBtZXNzYWdlIHRvOjxCUj5tYWlsc2VydiBhdCBpZXRmLm9yZy48QlI+SW4gdGhlIGJv
ZHkgdHlwZTo8QlI+IkZJTEU8QlI+L2ludGVybmV0LWRyYWZ0cy88QSBocmVmPSJodHRwOi8vd3d3
LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qYWloeXVuZy1jY2FtcC1hcnBzaWduYWwt
MDAudHh0IiB0YXJnZXQ9X2JsYW5rPmRyYWZ0LWphaWh5dW5nLWNjYW1wLWFycHNpZ25hbC0wMC50
eHQ8L0E+Ii48QlI+PEJSPk5PVEU6IFRoZSBtYWlsIHNlcnZlciBhdCBpZXRmLm9yZyBjYW4gcmV0
dXJuIHRoZSBkb2N1bWVudCBpbjxCUj5NSU1FLWVuY29kZWQgZm9ybSBieSB1c2luZyB0aGUgIm1w
YWNrIiB1dGlsaXR5LiZuYnNwOyBUbyB1c2UgdGhpczxCUj5mZWF0dXJlLCBpbnNlcnQgdGhlIGNv
bW1hbmQgIkVOQ09ESU5HIG1pbWUiIGJlZm9yZSB0aGUgIkZJTEUiPEJSPmNvbW1hbmQuJm5ic3A7
IFRvIGRlY29kZSB0aGUgcmVzcG9uc2UocyksIHlvdSB3aWxsIG5lZWQgIm11bnBhY2siIG9yPEJS
PmEgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXIuJm5ic3A7IERpZmZlcmVudCBNSU1FLWNvbXBs
aWFudCBtYWlsPEJSPnJlYWRlcnM8QlI+ZXhoaWJpdCBkaWZmZXJlbnQgYmVoYXZpb3IsIGVzcGVj
aWFsbHkgd2hlbiBkZWFsaW5nIHdpdGg8QlI+Im11bHRpcGFydCIgTUlNRSBtZXNzYWdlcyAoaS5l
LiBkb2N1bWVudHMgd2hpY2ggaGF2ZSBiZWVuIHNwbGl0PEJSPnVwIGludG8gbXVsdGlwbGUgbWVz
c2FnZXMpLCBzbyBjaGVjayB5b3VyIGxvY2FsIGRvY3VtZW50YXRpb24gb248QlI+aG93IHRvIG1h
bmlwdWxhdGUgdGhlc2UgbWVzc2FnZXMuPEJSPjxCUj48QlI+QmVsb3cgaXMgdGhlIGRhdGEgd2hp
Y2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcjxCUj5pbXBsZW1lbnRh
dGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZTxC
Uj5JbnRlcm5ldC1EcmFmdC48QlI+Jmx0O2Z0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm
dHMvPEEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamFp
aHl1bmctY2NhbXAtYXJwc2lnbmFsLTAwLnR4dCIgdGFyZ2V0PV9ibGFuaz5kcmFmdC1qYWloeXVu
Zy1jY2FtcC1hcnBzaWduYWwtMDAudHh0PC9BPiZuYnNwOyZuYnNwOzxCUj4mZ3Q7PEJSPjxCUj48
QlI+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvRElWPjwvRElW
PjxpbWcgc3R5bGU9ImRpc3BsYXk6bm9uZSIgd2lkdGg9MCBoZWlnaHQ9MCBzcmM9Imh0dHA6Ly91
bWFpbC5ldHJpLnJlLmtyL0V4dGVybmFsX1JlYWRDaGVjay5hc3B4P2VtYWlsPWNjYW1wQG9wcy5p
ZXRmLm9yZyZuYW1lPWNjYW1wJTQwb3BzLmlldGYub3JnJmZyb21lbWFpbD1qYWloeXVuZ0BldHJp
LnJlLmtyJm1lc3NhZ2VpZD0lM0MzZWUyOGUyMC05YmZiLTQ3YmItOGEyYi1lODNjZmQ0ZGFmNmNA
ZXRyaS5yZS5rciUzRSI+

------=_NextPart_001_DF34_01C50AAA.4D1F9280--

------=_NextPart_000_DF33_01C50AAA.4D1F9280
Content-Type: application/octet-stream;
	name="draft-jaihyung-ccamp-arpsignal-00.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="draft-jaihyung-ccamp-arpsignal-00.txt"

CgoKCgoKQ0NBTVAgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgSmFpaHl1bmcgQ2hvCklOVEVSTkVUIERSQUZUICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRVRSSQpFeHBpcmVzOiBKdWx5IDIwMDUg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMDUKCgoK
ICAgICAgVXNlIG9mIEFSUCBhbmQgRmxvb2QgUm91dGluZyBUZWNobmlxdWUgZm9yIExTUCBzZXR1
cCBpbiBFQ1BOCgoKICAgICAgICAgICAgICAgIDxkcmFmdC1qYWloeXVuZy1jY2FtcC1hcnBzaWdu
YWwtMDAudHh0PgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgICBCeSBzdWJtaXR0aW5nIHRoaXMg
SW50ZXJuZXQtRHJhZnQsIEkgY2VydGlmeSB0aGF0IGFueSBhcHBsaWNhYmxlCiAgICAgcGF0ZW50
IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggSSBhbSBhd2FyZSBoYXZlIGJlZW4gZGlzY2xv
c2VkLAogICAgIGFuZCBhbnkgb2Ygd2hpY2ggSSBiZWNvbWUgYXdhcmUgd2lsbCBiZSBkaXNjbG9z
ZWQsIGluIGFjY29yZGFuY2UKICAgICB3aXRoIFJGQyAzNjY4LgoKICAgICBJbnRlcm5ldC1EcmFm
dHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICAg
IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBO
b3RlIHRoYXQKICAgICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRv
Y3VtZW50cyBhcyBJbnRlcm5ldC0KICAgICBEcmFmdHMuCgogICAgIEludGVybmV0LURyYWZ0cyBh
cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4CiAgICAgbW9udGhz
IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1
LQogICAgIG1lbnRzIGF0IGFueSB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50
ZXJuZXQtRHJhZnRzIGFzCiAgICAgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBv
dGhlciB0aGFuIGFzICJ3b3JrIGluCiAgICAgcHJvZ3Jlc3MuIgoKICAgICBUaGUgbGlzdCBvZiBj
dXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgICBodHRwOi8vd3d3
LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuCgogICAgIFRoZSBsaXN0IG9mIEludGVy
bmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgICBodHRw
Oi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgICBUaGlzIEludGVybmV0LURyYWZ0IHdp
bGwgZXhwaXJlIG9uIEZlYnJ1YXJ5IDIwMDUuCgoKQWJzdHJhY3QKCiAgICAgSW4gdGhpcyBtZW1v
LCB3ZSBmaXJzdCBkaXNjdXNzIHNvbWUgd2Vha25lc3NlcyBvZiBwcm9wb3NhbHMKICAgICBlbXBs
b3lpbmcgUlNWUCBpbiBsb2NhbCBuZXR3b3JrLCBzdWNoIGFzIFJGQzI4MTQsIDI4MTUsIDI4MTYs
IGFuZAogICAgIHByb3Bvc2UgZXh0ZW5zaW9uIG9mIEFSUCAoQWRkcmVzcyBSZXNvbHV0aW9uIFBy
b3RvY29sKSBhbmQgW0xTRV0KICAgICB0ZWNobmlxdWUgZm9yIHNvbHV0aW9uIHRvIHByb3ZpZGUg
UW9TIGluIEV0aGVybmV0IGJhc2VkIEN1c3RvbWVyCiAgICAgUHJlbWlzZSBOZXR3b3JrIChFQ1BO
KS4gRnJhbWV3b3JrIGFyY2hpdGVjdHVyZSBvZiBMU0UgKExhYmVsCiAgICAgU3dpdGNoZWQgRXRo
ZXJuZXQpIGFzIGEgbWV0aG9kIG9mIEdNUExTIGltcGxlbWVudGF0aW9uIGZvciBFdGhlcm5ldAog
ICAgIGlzIGRlc2NyaWJlZCBpbiBbTFNFXS4gQVJQIGlzIHByb3Bvc2VkIGZvciBpbnRlZ3JhdGVk
IHNpZ25hbGluZyBhbmQKICAgICByb3V0aW5nIHByb3RvY29sIGluIEVDUE4uIFRoaXMgZG9jdW1l
bnQgZGVzY3JpYmVzIG92ZXJ2aWV3IG9mIEFSUAogICAgIGV4dGVuc2lvbiwgcHJvY2VkdXJlIGZv
ciBsYWJlbCBuZWdvdGlhdGlvbiBhbmQgbWV0aG9kIGZvciBRb1MKICAgICByb3V0aW5nLiAgTWFq
b3IgZmVhdHVyZXMgb2YgdGhpcyBBUlAgZXh0ZW5zaW9uIGFyZTsgc3VwcG9ydCBmb3IKICAgICBs
YWJlbCBzd2l0Y2hpbmcsIGluY29ycG9yYXRpb24gb2Ygcm91dGluZyBmdW5jdGlvbiwgY29tcGF0
aWJpbGl0eQogICAgIHdpdGggbGVnYWN5IEV0aGVybmV0IGFuZCBlbmhhbmNlZCBzZWN1cml0eS4K
CgoKCkphaWh5dW5nIENobyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjAwNSAgICAgICAg
ICAgICAgICAgICBbUGFnZSAxXQoMCgpJTlRFUk5FVC1EUkFGVCAgICAgICAgICBBUlAgZm9yIExT
UCBzZXR1cCBpbiBFQ1BOICAgICAgICAgIEZlYnJ1YXJ5IDIwMDUKCgpUYWJsZSBvZiBDb250ZW50
czoKCiAgICAgMS4gSW50cm9kdWN0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uMgogICAgIDIuIE92ZXJhbGwgTWVjaGFuaXNtIG9mIExTRSBhbmQgQVJQ
IFNpZ25hbGluZyAuLi4uLi4uLi4uLi4uLi4uLjUKICAgICAzLiBGbG9vZCBSb3V0aW5nIFRlY2hu
aXF1ZSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44CiAgICAgNC4gQ29uc3Ry
YWludCBCYXNlZCBSb3V0aW5nICAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMgog
ICAgIDUuIERpc2N1c3Npb24gb24gT3ZlcmhlYWQgb2YgRmxvb2RpbmcgLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uMTIKICAgICA2LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjEzCiAgICAgNy4gUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMwogICAgIEFwcGVuZGl4IEEgIEV4
YW1wbGUgb2YgQVJQIE1lc3NhZ2VzIGluIEZpZ3VyZSAxICAuLi4uLi4uLi4uLi4uMTQKICAgICBB
dXRob3IncyBBZGRyZXNzZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLjE3CgoKCjEuIEludHJvZHVjdGlvbgoKCiAgICAgV2hpbGUgdGhlcmUgaGFzIGJlZW4gc2ln
bmlmaWNhbnQgcHJvZ3Jlc3MgaW4gUXVhbGl0eSBvZiBTZXJ2aWNlCiAgICAgKFFvUykgYXJjaGl0
ZWN0dXJlcyBmb3IgcHJvdmlkZXIgbmV0d29ya3MsIG1lY2hhbmlzbSBmb3IgZW5kCiAgICAgc3Rh
dGlvbnMgdG8gdXRpbGl6ZSBzdWNoIHNlcnZpY2UgaXMgbmVjZXNzYXJ5IGluIG9yZGVyIHRvIGd1
YXJhbnRlZQogICAgIGVuZC10by1lbmQgc2VydmljZSBkZWxpdmVyeS4gUkZDMjk5OCBzdHJlc3Nl
cyB0aGlzIGlzc3VlIGFuZAogICAgIGRlc2NyaWJlcyBhbiBhcmNoaXRlY3R1cmUgbWFwcGluZyBJ
bnRTZXJ2ZSBhbmQgRGlmZlNlcnZlIHJlZ2lvbnMuCiAgICAgSW4gdGhlIFJGQywgUlNWUCBpcyBw
cm9wb3NlZCBmb3IgZXhwbGljaXQgc2lnbmFsIHRoYXQgZGVsaXZlciB1c2VyCiAgICAgcmVxdWVz
dCBpbiBhcm91bmQgY3VzdG9tZXIgcHJlbWlzZSBhbmQgYWdncmVnYXRlIHRoZSBmbG93cyBpbiBj
b3JlCiAgICAgbmV0d29yay4gSW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBkaXNjdXNzaW9uLCBSRkMy
ODE2IG91dGxpbmVzIGEKICAgICBmdW5jdGlvbmFsIG1vZGVsIGZvciBzdXBwb3J0aW5nIFJTVlAg
aW4gc2hhcmVkIGFuZCBzd2l0Y2hlZCBMQU4KICAgICBpbmZyYXN0cnVjdHVyZS4gVGhlIGFyY2hp
dGVjdHVyZSBkb2VzIG5vdCByZXF1aXJlIG1vZGlmaWNhdGlvbiBpbgogICAgIGZlYXR1cmVzIGRl
ZmluZWQgaW4gSUVFRSA4MDIgc3BlY2lmaWNhdGlvbiBidXQgc2ltcGx5IGRlZmluZQogICAgIG1h
cHBpbmdzIG9mIHRoZSB2YXJpb3VzIElFVEYgSW50ZWdyYXRlZCBTZXJ2aWNlcyBvbnRvIHByaW9y
aXR5CiAgICAgc2NoZW1lcyBpbiA4MDIgTEFOcy4gRGV0YWlsIG9mIHRoZSBleHRlbnNpb24gb2Yg
UlNWUCwgYW5kIFNCTQogICAgIChTdWJuZXQgQmFuZHdpZHRoIE1hbmFnZXIpIHByb3RvY29sIGZv
ciBhZG1pc3Npb24gY29udHJvbCBhbmQKICAgICBiYW5kd2lkdGggbWFuYWdlbWVudCBhcmUgZGVz
Y3JpYmVkIGluIFJGQzI4MTQgYW5kIFJGQzI4MTUuCgogICAgIFdoaWxlIHRoZSB3b3JrIGRlbW9u
c3RyYXRlZCBhbiBSU1ZQIGltcGxlbWVudGF0aW9uIG92ZXIgTEFOIG1lZGlhLAogICAgIHdlYWtu
ZXNzIG9mIFJGQzI4MTYgaXMgY29tcGxleGl0eS4gRm9yIGV4YW1wbGUsIHRoZSBtZXRob2QgcmVx
dWlyZXMKICAgICBhbGwgdGhlIGhlYXZpbmVzcyBhbmFsb2dvdXMgdG8gcm91dGVycyBpbiBhZGRp
dGlvbiB0byBiYXNpYwogICAgIG9wZXJhdGlvbiBvZiBSU1ZQLCBzdWNoIGFzIGxvb3AtZGV0ZWN0
aW9uLCBMMi9MMyBhZGRyZXNzIG1hcHBpbmcsCiAgICAgYWNjZXNzIGNvbnRyb2wgYW5kIHNlcnZp
Y2UgY2xhc3MgdHJhbnNsYXRpb24sIG1hc3RlciBub2RlIGVsZWN0aW9uCiAgICAgYW5kIHNvIG9u
LiBBcyBzdGF0ZWQgaW4gdGhlIFJGQywgICIgoaYgIEl0IGVzc2VudGlhbGx5IGRvZXMgd2hhdAog
ICAgIFJTVlAgYWxyZWFkeSBkb2VzIGF0IExheWVyIDMiLiBJZiB0aGVyZSBpcyBvbmx5IGEgbGl0
dGxlIGRpZmZlcmVuY2UKICAgICB3aXRoIGxheWVyLTMgUlNWUCwgaXQgd2lsbCBiZSBiZXR0ZXIg
dG8gdXNlIGxvdy1jb3N0IGxheWVyLTMKICAgICBzd2l0Y2hlcyByYXRoZXIgdGhhbiBjb21wbGV4
IGxheWVyLTIgc3dpdGNoZXMgd2l0aCBtb2RpZmllZCBSU1ZQLgoKICAgICBBbm90aGVyIGRyYXdi
YWNrIGlzIHZ1bG5lcmFiaWxpdHkgZnJvbSBtYWxpY2lvdXMgYXR0YWNrLiBSRkMyODE2CiAgICAg
YXNzdW1lcyBlbmQgc3RhdGlvbnMgYXJlIHRydXN0ZWQgdG8gYWRoZXJlIHRvIHRoZWlyIG5lZ290
aWF0ZWQKICAgICBjb250cmFjdHMgYXQgdGhlIGlucHV0cyB0byB0aGUgbmV0d29yay4gVGhpcyBh
c3N1bXB0aW9uIGlzIG5vdAogICAgIHZhbGlkIGluIG9wZW4sIHB1YmxpYyBlbnZpcm9ubWVudCBz
dWNoIGFzIGNhbXB1cyBuZXR3b3JrIG9yCiAgICAgRXRoZXJuZXQgYmFzZWQgYWNjZXNzIG5ldHdv
cmsuIFVzZXJzIG1heSBtYW5pcHVsYXRlIFZMQU4gdGFnLCBJUAogICAgIGhlYWRlcnMgY2FuIGJl
IGVuY3J5cHRlZCBhbmQgcG9ydCBudW1iZXJzIGNhbiBiZSBkeW5hbWljYWxseQogICAgIGNoYW5n
ZWQuIEl0IGlzIHNvIGVhc3kgdG8gYWJ1c2Ugc2VydmljZSBjbGFzcyBhbmQgZGlzdHVyYiB0cmFm
ZmljCiAgICAgZmxvd3MuIFNlY3VyZSBhbmQgcmVsaWFibGUgbWV0aG9kIGZvciBpZGVudGlmaWNh
dGlvbiBvZiBwcmVtaXVtCiAgICAgc2VydmljZSBmbG93cyBpcyBpbXBvcnRhbnQgaW4gc3VjaCBl
bnZpcm9ubWVudC4KCgoKCkphaWh5dW5nIENobyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkg
MjAwNSAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCgpJTlRFUk5FVC1EUkFGVCAgICAgICAg
ICBBUlAgZm9yIExTUCBzZXR1cCBpbiBFQ1BOICAgICAgICAgIEZlYnJ1YXJ5IDIwMDUKCgogICAg
IE9wZXJhdGlvbmFsIGRpZmZpY3VsdHkgaXMgdGhlIG90aGVyIHByb2JsZW0uIFRoZSBSRkMgcmVx
dWlyZXMKICAgICBtYW51YWwgY29uZmlndXJhdGlvbiBvZiBJUCBhZGRyZXNzZXMgYW5kIE1BQyBh
ZGRyZXNzZXMuIEFwYXJ0IGZyb20KICAgICBzY2FyY2l0eSBvZiBJUCBhbmQgTUFDIGFkZHJlc3Nl
cywgbW9zdCByZXNpZGVudGlhbCB1c2VycyBvciBzbWFsbC0KICAgICBuZXR3b3JrIG93bmVycyB3
aWxsIG5vdCBoYXZlIHRoZSBwcm9mZXNzaW9uYWwga25vd2xlZGdlIG9mIG5ldHdvcmsuCiAgICAg
RnVydGhlcm1vcmUsIGl0IHJlcXVpcmVzIGVuZCB1c2VycyB1bmRlcnN0YW5kIGNvbXBsZXggcGFy
YW1ldGVycyBvZgogICAgIFJTVlAsIHN1Y2ggYXMgRmxvd3NwZWMsIFRzcGVjLCB3aGljaCBtYXkg
bm90IGJlIG5lY2Vzc2FyeSBhdCBhbGwKICAgICB0aW1lcy4gSXQgaXMgbm90ZWQgdGhhdCBJU1Bz
IGhhdmUgdG8gc3BlbmQgZW5vcm1vdXMgb3BlcmF0aW9uIGNvc3QKICAgICBmb3Igc3VwcG9ydGlu
ZyBpbmRpdmlkdWFsIGN1c3RvbWVycy4gSWYgY3VzdG9tZXJzIGhhdmUgZGlmZmljdWx0eQogICAg
IGluIGNvbmZpZ3VyaW5nIHRoZWlyIHJlc2lkZW50aWFsIG5ldHdvcmsgb3Igb2ZmaWNlIG5ldHdv
cmssIGl0IHdpbGwKICAgICBiZSBtb3JlIGJ1cmRlbnMgdG8gc2VydmljZSBwcm92aWRlcnMgYW5k
IGFwcGxpY2F0aW9uIGRldmVsb3BlcnMuCiAgICAgQWx0aG91Z2ggc29tZSBwcm9mZXNzaW9uYWwg
dGVjaG5pY2lhbnMgbWF5IGxpa2UgdGhlIGZsZXhpYmlsaXR5IGFuZAogICAgIHNvcGhpc3RpY2F0
aW9uIG9mIFJTVlAsIGl0IHdpbGwgbm90IGJlIHNvIGRlc2lyYWJsZSB0byBtb3N0CiAgICAgb3Jk
aW5hcnkgdXNlcnMuCgogICAgIFRvIHRoZSBsYXN0IHBvaW50LCBSRkMyODE0IHJlcXVpcmVzIHVi
aXF1aXRvdXMgZGVwbG95bWVudCBvZiBjb21tb24KICAgICBzaWduYWxpbmcgZW50aXR5IGluIGFs
bCB1c2VyIHRlcm1pbmFscyBhbmQgbmV0d29yayBkZXZpY2UuCiAgICAgVW5mb3J0dW5hdGVseSwg
bG9jYWwgc3dpdGNoIG1hbnVmYWN0dXJlcnMgZG8gbm90IHN1cHBvcnQgaXQgZm9yCiAgICAgcmVh
c29ucyBhYm92ZSBhbmQgaW1tYXR1cml0eSBvZiBhcHBsaWNhdGlvbiBtYXJrZXQuIExhY2sgb2Yg
dXNlcgogICAgIGNhcGFiaWxpdHkgZm9yIHNpZ25hbGluZyBpbXBlZGVzIGVtZXJnZW5jZSBvZiBu
ZXcgY29tbWVyY2lhbAogICAgIHNlcnZpY2UgYW5kIGV2b2x1dGlvbiBvZiBRb1MgdGVjaG5pcXVl
LiBJbiBvcmRlciB0byBmYWNpbGl0YXRlIGZhc3QKICAgICBwcm9saWZlcmF0aW9uIG9mIFFvUyBh
cHBsaWNhdGlvbnMsIHNpZ25hbGluZyBwcm90b2NvbCBtdXN0IG5vdAogICAgIGV4cGVjdCByZWNl
aXZpbmcgdGVybWluYWwgaXMgcmVjaXByb2NhbC4gSW4gb3RoZXIgd29yZHMsIHNvdXJjZQogICAg
IHRlcm1pbmFsIG11c3QgYmUgYWJsZSB0byBuZWdvdGlhdGUgc2VydmljZSBldmVuIHdoZW4gdGhl
IHJlY2VpdmluZwogICAgIHBhcnR5IGlzIG5vdCBjb25mb3JtYW50LiBUaGUgbmV0d29yayBtdXN0
IGJlIGFibGUgdG8gcHJvdmlkZQogICAgIHNlcnZpY2UgYWx0aG91Z2ggZGVwbG95bWVudCBvZiBu
ZXcgc2VydmljZSBpcyBwYXJ0aWFsLgoKICAgICBUaGUgQVJQIHNpZ25hbGluZyBwcmVzZW50ZWQg
aGVyZSwgYWxvbmcgd2l0aCBMYWJlbCBTd2l0Y2hlZAogICAgIEV0aGVybmV0IChMU0UpIHRlY2hu
aXF1ZSBkZXNjcmliZWQgaW4gW0xTRV0sIG92ZXJjb21lcyB0aGUKICAgICBzaG9ydGNvbWluZ3Mg
ZGlzY3Vzc2VkIGFib3ZlLiBDb250cmFzdCB0byBhcHByb2FjaGVzIHRoYXQgdXNlIFJTVlAKICAg
ICBmb3IgYXBwbGljYXRpb24gc2lnbmFsLCB0ZXJtaW5hbHMgYW5kIEV0aGVybmV0IHN3aXRjaGVz
IHVzZSBBUlAKICAgICAoQWRkcmVzcyBSZXNvbHV0aW9uIFByb3RvY29sKSBmb3IgbmVnb3RpYXRp
bmcgcmVzb3VyY2VzIGFuZAogICAgIGVzdGFibGlzaGluZyBMU1AuIFNvbWUgZGlzdGluY3QgZmVh
dHVyZXMgb2YgQVJQIHNpZ25hbGluZyBhcmUKICAgICBsaXN0ZWQgYmVsb3cgOgoKICAgICAtIFN1
cHBvcnQgZm9yIE1BQyBhZGRyZXNzIHN3YXBwaW5nIDogVGhlIG1vZGlmaWVkIEFSUCBpcyBwcmlt
YXJpbHkKICAgICBkZXNpZ25lZCBmb3IgcGFzc2luZyBsYWJlbCBpbmZvcm1hdGlvbiBvZiBNQUMg
YWRkcmVzcyBmb3JtYXQgYW5kCiAgICAgZXN0YWJsaXNoaW5nIExTUCBiZXR3ZWVuIHRlcm1pbmFs
cyBhbmQgRXRoZXJuZXQgc3dpdGNoZXMuIFRoZSByb2xlCiAgICAgaXMgc2ltaWxhciB0byBbTERQ
XSBvciBbUlNWUC1URV0gaW4gTVBMUyBuZXR3b3JrLCBob3dldmVyLCB0aGlzCiAgICAgcHJvdG9j
b2wgaXMgZGVkaWNhdGVkIGZvciBFdGhlcm5ldC4KCiAgICAgLSBJbmNvcnBvcmF0ZXMgcm91dGlu
ZyA6IFRoZSBtb3N0IGRpc3RpbmN0aXZlIGZlYXR1cmUgb2YgdGhpcwogICAgIGV4dGVuc2lvbiBp
cyB0aGF0IEFSUCBwcm90b2NvbCBjYXJyaWVzIG91dCByb3V0aW5nIGZ1bmN0aW9uIHVzaW5nCiAg
ICAgbm92ZWwgZmxvb2Qgcm91dGluZyB0ZWNobmlxdWUuIEV0aGVybmV0IHN3aXRjaGVzIGVzdGFi
bGlzaCBMU1AgdmlhCiAgICAgc2hvcnRlc3QgYXZhaWxhYmxlIHBhdGggd2l0aG91dCByZWx5aW5n
IG9uIHByZS1lc3RhYmxpc2hlZCByb3V0aW5nCiAgICAgZGF0YWJhc2Ugb3Igc3Bhbm5pbmcgdHJl
ZSBhbGdvcml0aG0uIEl0IGRvZXMgbm90IGhhdmUgdHlwaWNhbAogICAgIHdlYWtuZXNzZXMgb2Yg
b3RoZXIgcm91dGluZyBhbGdvcml0aG1zIHN1Y2ggYXMgbG9vcGluZywgdHJhZmZpYwogICAgIGNv
bmNlbnRyYXRpb24gb3IgZ2xvYmFsIHVwZGF0ZSBvbiBmYWlsdXJlLgoKICAgICAtIE5vbi1yZWNp
cHJvY2FsIDogQ29udHJhc3QgdG8gUkZDMjgxNCwgdGhlIHByb3Bvc2VkIG1ldGhvZCBkb2VzCiAg
ICAgbm90IHJlcXVpcmUgYmlsYXRlcmFsIGltcGxlbWVudGF0aW9uIG9mIHNpZ25hbGluZyBlbnRp
dHkgaW4gYm90aAogICAgIGNvbW11bmljYXRpbmcgdGVybWluYWxzLiBFdGhlcm5ldCBzd2l0Y2hl
cyBvZiB0aGlzIGltcGxlbWVudGF0aW9uCiAgICAgd2lsbCBkbyBiZXN0IHRvIG1lZXQgdGhlIGJh
bmR3aWR0aCByZXF1aXJlbWVudCBvZiByZWFsLXRpbWUgdHJhZmZpYwoKCgoKSmFpaHl1bmcgQ2hv
ICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyMDA1ICAgICAgICAgICAgICAgICAgIFtQYWdl
IDNdCgwKCklOVEVSTkVULURSQUZUICAgICAgICAgIEFSUCBmb3IgTFNQIHNldHVwIGluIEVDUE4g
ICAgICAgICAgRmVicnVhcnkgMjAwNQoKCiAgICAgYW5kIHByb3ZpZGUgcHJlZmVyZW50aWFsIHNl
cnZpY2UgdGhhbiBiZXN0ZWZmb3J0IHRyYWZmaWMuCgogICAgIC0gQ29tcGF0aWJpbGl0eSB3aXRo
IGxlZ2FjeSBFdGhlcm5ldCA6IFRoZSBwcm9wb3NlZCBtZXRob2QgYWxsb3dzCiAgICAgaW50ZXJj
b25uZWN0aW9uIHdpdGggbGVnYWN5IHRlcm1pbmFscyBhbmQgc3dpdGNoZXMgaW4gYW55CiAgICAg
Y29uZmlndXJhdGlvbi4gUW9TIGFwcGxpY2F0aW9ucyBtYXkgdXNlIGV4dGVuZGVkIGZlYXR1cmUg
b2YgQVJQCiAgICAgd2hpbGUgb3RoZXIgYmVzdGVmZm9ydCBhcHBsaWNhdGlvbnMgYXJlIG5vdCBh
ZmZlY3RlZCBhdCBhbGwuCgogICAgIC0gTG93IG9wZXJhdGlvbmFsIG92ZXJoZWFkIDogQmFzaWMg
b3BlcmF0aW9uIG1vZGUgb2YgdGhpcyBwcm90b2NvbAogICAgIGRvZXMgbm90IHJlcXVpcmUgcHJl
LWNvbmZpZ3VyYXRpb24gb2Ygc3dpdGNoZXMsIHdoaWxlIG5ldHdvcmsKICAgICBtYW5hZ2VycyBt
YXkgY29uZmlndXJlIHNvcGhpc3RpY2F0ZWQgZnVuY3Rpb25zIHRvIGltcG9zZSBwb2xpY3kgb3IK
ICAgICBhY2Nlc3MgY29udHJvbC4KCiAgICAgLSBTY2FsYWJpbGl0eSA6IFRoaXMgZXh0ZW5zaW9u
IGFsbG93cyBsYXJnZS1zY2FsZSBFdGhlcm5ldCBzdWItCiAgICAgZGl2aWRlZCBhbmQgc3RydWN0
dXJlZCBhY2NvcmRpbmcgdG8gSVAgYWRkcmVzcyBoaWVyYXJjaHkuIEJvcmRlcgogICAgIHN3aXRj
aGVzIG9mIHN1Yi1kaXZpc2lvbiBtYXkgYmxvY2sgaW50ZXJuYWwgYnJvYWRjYXN0IGFuZAogICAg
IHNlbGVjdGl2ZWx5IHJlbGF5IEFSUCBtZXNzYWdlcy4gU2luY2UgQVJQIGluY29ycG9yYXRlcyBy
b3V0aW5nCiAgICAgZnVuY3Rpb24sIEV0aGVybmV0IHN3aXRjaGVzIGhhdmUgdGhlIHNjYWxhYmls
aXR5IGNvbXBhcmFibGUgdG8KICAgICByb3V0ZXJzLgoKICAgICAtIFRyYWZmaWMgRW5naW5lZXJp
bmcgOiBJbiBMU0UgbmV0d29yaywgYmVzdGVmZm9ydCBhbmQgcmVhbC10aW1lCiAgICAgZmxvd3Mg
YXJlIHRyYW5zbWl0dGVkIHZpYSBMU1BzLiBIZW5jZSwgTmV0d29yayBvcGVyYXRvcnMgYXJlIGFi
bGUKICAgICB0byBjb250cm9sIHRyYWZmaWMgZmxvd3MgaW4gZmluZSBncmFudWxhcml0eSB1c2lu
ZyBMU1BzLgoKCgoKCiAgICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFV
SVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIs
ICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbgogICAgIHRoaXMgZG9jdW1l
bnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDIDIxMTldLgoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgoKCkphaWh5dW5nIENobyAgICAgICAgICAgICAgICBFeHBpcmVz
IEp1bHkgMjAwNSAgICAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCgpJTlRFUk5FVC1EUkFGVCAg
ICAgICAgICBBUlAgZm9yIExTUCBzZXR1cCBpbiBFQ1BOICAgICAgICAgIEZlYnJ1YXJ5IDIwMDUK
CgoyLiBPdmVyYWxsIE1lY2hhbmlzbSBvZiBMU0UgYW5kIEFSUCBTaWduYWxpbmcKCgogICAgIEZy
YW1ld29yayBhcmNoaXRlY3R1cmUgb2YgTFNFIChMYWJlbCBTd2l0Y2hlZCBFdGhlcm5ldCkgYXMg
YSBtZXRob2QKICAgICBvZiBHTVBMUyBpbXBsZW1lbnRhdGlvbiBmb3IgRXRoZXJuZXQgaXMgZGVz
Y3JpYmVkIGluIFtMU0VdLiBSZWFkZXJzCiAgICAgYXJlIGFkdmlzZWQgdG8gaGF2ZSBrbm93bGVk
Z2Ugb2YgTUFDIGFkZHJlc3Mgc3dhcHBpbmcgZXhwbGFpbmVkIGluCiAgICAgW0xTRV0uCgogICAg
IEluIExTRSwgNDhiaXRzIG9mIEV0aGVybmV0IGFkZHJlc3MgaW4gTUFDIGhlYWRlciBpcyB1c2Vk
IGZvcgogICAgIGxhYmVscy4gRXRoZXJuZXQgc3dpdGNoZXMgc3VwcG9ydGluZyB0aGlzIHRlY2hu
aXF1ZSBpZGVudGlmeSBmbG93cwogICAgIG9mIGRpZmZlcmVudCBhcHBsaWNhdGlvbnMgYWNjb3Jk
aW5nIHRvIE1BQyBhZGRyZXNzZXMuIExTRSBzd2l0Y2hlcwogICAgIGFsbG9jYXRlIE1BQyBhZGRy
ZXNzZXMgd2hlbiB0aGV5IHJlY2VpdmUgQVJQIHJlcXVlc3QvcmVwbHkgbWVzc2FnZXMKICAgICBh
bmQgcGFzcyB0aGUgbGFiZWwgaW5mb3JtYXRpb24gdXNpbmcgQVJQLiBGaWd1cmUgMSBiZWxvdyBz
aG93cwogICAgIGZvcm1hdCBvZiBBUlAgbWVzc2FnZSBkZXNjcmliZWQgaW4gUkZDODI2LgoKCiAg
ICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAg
ICAgICAgIDMgMwogICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg
MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICAgIERlc3Rp
bmF0aW9uIEV0aGVybmV0IEFkZHJlc3MgKDZieXRlPWJyb2FkY2FzdCBNQUMpICAgICAgIHwKICAg
ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSsKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsKICAgICAgfCAgICAgICAg
ICAgICAgU291cmNlIEV0aGVybmV0IEFkZHJlc3MgKDZieXRlKSAgICAgICAgICAgICAgICAgIHwK
ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSsKICAgICAgfCAgICAgIExlbmd0aC9UeXBlICg9QVJQKSAgICAgICB8ICBM
MiBBZGRyZXNzIFR5cGUgKD1FdGhlcm5ldCkgIHwKICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsKICAgICAgfCAgICBM
MyBBZGRyZXNzIFR5cGUgKD1JUHY0KSAgICB8TDIgTGVuZyAoPTB4MDYpfEwzIExlbmcgKD0weDA0
KXwKICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t
Ky0tLS0tLS0tLS0tLS0tLSsKICAgICAgfCAgIE9QIENvZGUgKD1SZXEvUnB5L1JhcnAuLi4pICB8
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsKICAgICAgfCAg
ICAgICAgICAgICAgU2VuZGVyIEV0aGVybmV0IEFkZHJlc3MgKDZieXRlKSAgICAgICAgICAgICAg
ICAgIHwKICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgfCAgICAgICAgICAgICAgICBTZW5kZXIgSVB2NCBB
ZGRyZXNzICg0Ynl0ZSkgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAg
fCAgICAgICAgICAgICAgVGFyZ2V0IEV0aGVybmV0IEFkZHJlc3MgKDZieXRlKSAgICAgICAgICAg
ICAgICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgfCAgICAgICAoJXVzZWQgZm9yIExTRSkgICAg
ICAgICB8ICAgICBUYXJnZXQgSVB2NCBBZGRyZXNzICAgICAgIHwKICAgICAgKy0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAg
ICAgfCAgICAgICAgICAgICAoNGJ5dGUpICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwKICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgfCAgICAgICAg
ICAgICAgICAgICAgICAgIFBhZGRpbmcgKG9yIEZDUykgICAgICAgICAgICAgICAgICAgICAgIHwK
ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgICAgRmlndXJl
IDEgIEFSUCBtZXNzYWdlIGZvcm1hdAoKCiAgICAgQWNjb3JkaW5nIHRvIFJGQzgyNiwgdGhlIG1l
c3NhZ2UgZm9ybWF0IG9mIEZpZ3VyZSAxIGlzIHVzZWQgd2hlbgogICAgIHNvdXJjZSB0ZXJtaW5h
bCBicm9hZGNhc3RzIEFSUCByZXF1ZXN0LiBUYXJnZXQgdGVybWluYWwgYWxzbyB1c2VzCgoKCgpK
YWloeXVuZyBDaG8gICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDIwMDUgICAgICAgICAgICAg
ICAgICAgW1BhZ2UgNV0KDAoKSU5URVJORVQtRFJBRlQgICAgICAgICAgQVJQIGZvciBMU1Agc2V0
dXAgaW4gRUNQTiAgICAgICAgICBGZWJydWFyeSAyMDA1CgoKICAgICB0aGUgc2FtZSBmb3JtYXQg
d2hlbiBpdCByZXNwb25kcyB3aXRoIEFSUCByZXBseS4gU2luY2UgaWRlbnRpY2FsCiAgICAgZm9y
bWF0IGlzIHVzZWQgaW4gYm90aCBkaXJlY3Rpb25zLCBzb21lIGluZm9ybWF0aW9uIGZpZWxkIGlz
CiAgICAgbWVhbmluZ2xlc3MgZGVwZW5kcyBvbiBtZXNzYWdlIHR5cGUgKGkuZS4sIE9QIENvZGUp
LiBGb3IgZXhhbXBsZSBpbgogICAgIHRoZSBjYXNlIG9mIEFSUCByZXF1ZXN0LCBzb3VyY2UgRXRo
ZXJuZXQgYWRkcmVzcyBpbiB0aGUgaGVhZGVyIGFuZAogICAgIHNlbmRlciBFdGhlcm5ldCBhZGRy
ZXNzIGluIHRoZSBtZXNzYWdlIGJvZHkgYXJlIHJlZHVuZGFudAogICAgIGluZm9ybWF0aW9uLiA2
IGJ5dGVzIG9mIFRhcmdldCBFdGhlcm5ldCBBZGRyZXNzIChURUEpIGZpZWxkIGlzCiAgICAgdW51
c2VkIGluIEFSUCByZXF1ZXN0IGJlY2F1c2Ugb25seSB0aGUgdGFyZ2V0IHRlcm1pbmFsIGNhbiBm
aWxsIHRoZQogICAgIGluZm9ybWF0aW9uLiBUaGUgQVJQIGV4dGVuc2lvbiB1c2VzIHN1Y2ggZmll
bGRzIGZvciBjb250cm9sbGluZyBBUlAKICAgICBicm9hZGNhc3QgYW5kIExTUCBlc3RhYmxpc2ht
ZW50LiBUaGUgcHJvY2VkdXJlIGZvciBMU1Agc2V0dXAgYW5kCiAgICAgc3dhcHBpbmcgb2YgTUFD
IGFkZHJlc3MgaXMgZGVzY3JpYmVkIGluIEZpZ3VyZSAyLgoKCiAgICAgIFRlcm1pbmFsICAgICAg
ICAgU3dpdGNoICAgICAgICAgICAgICAgU3dpdGNoICAgICAgICAgVGVybWluYWwKICAgICAgW0Vh
XT09PT09PT09PT09PT09W1MxXT09PT09PT09PT09PT09PT09W1MyXT09PT09PT09PT09PT09W0Vi
XQoKICAgICAgICBBUlByZXEoU0E9RWEsVEE9PyApIC0tLS0tLS0tPgogICAgICAgICAgICAgICAg
ICAgICAgICAgLS1BUlByZXEoU0E9RkYsVEE9PyApLS0+CiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIC0tLS0tLT4gQVJQcmVxKFNBPUZGLFRBPT8gKQoKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLS0tLSBBUlBycHkoU0E9RWIsVEE9RkYpCiAg
ICAgICAgICAgICAgICAgICAgICAgIDwtLUFSUHJweShTQT1MYyxUQT1GRiktLQogICAgICAgIEFS
UHJweShTQT1MYSxUQT1FYSkgPC0tLS0tLS0KCgogICAgICAuLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4KCgogICAgICAgREFUQShTQT1F
YSxEQT1MYSkgLT4gREFUQShTQT1MYixEQT1MYykgLT4gREFUQShTQT1MZCxEQT1FYikKCiAgICAg
ICBEQVRBKFNBPUxhLERBPUVhKSA8LSBEQVRBKFNBPUxjLERBPUxiKSA8LSBEQVRBKFNBPUViLERB
PUxkKQoKCiAgICAgRmlndXJlIDIgQVJQIHByb2NlZHVyZSBhbmQgZnJhbWUgdHJhbnNtaXNzaW9u
CgoKICAgICBJbiBGaWd1cmUgMiwgaXQgaXMgYXNzdW1lZCB0aGF0IGEgUW9TIGFwcGxpY2F0aW9u
IGluIHNvdXJjZQogICAgIHRlcm1pbmFsIEVhIGlzIHJlcXVlc3RpbmcgYSBjb25uZWN0aW9uIG9m
IGNlcnRhaW4gYmFuZHdpZHRoCiAgICAgcmVxdWlyZW1lbnQgdG8gdW5kZXJseWluZyBsYXllci4g
VGhpcyB0cmlnZ2VycyBzb3VyY2UgdGVybWluYWwgRWEKICAgICB0cmFuc21pdHMgQVJQIHJlcXVl
c3QgaW4gb3JkZXIgdG8gcmVzb2x2ZSBJUC10by1FdGhlcm5ldCBhZGRyZXNzCiAgICAgbWFwcGlu
ZyBvZiB0YXJnZXQgZGVzdGluYXRpb24gdGVybWluYWwgRWIuIFRoZSBiYW5kd2lkdGgKICAgICBy
ZXF1aXJlbWVudCBpcyBlbmNvZGVkIGluIFRFQSBmaWVsZCBvZiB0aGUgQVJQIG1lc3NhZ2UgYmVj
YXVzZSB0aGUKICAgICBmaWVsZCBpcyBub3QgdXNlZCBpbiBsZWdhY3kgQVJQIHJlcXVlc3QuIFRo
ZSBhZGRyZXNzZXMgb2YgZnJhbWUKICAgICBoZWFkZXIgYXJlIChEQT1icm9hZGNhc3QgYWRkcmVz
cywgU0E9RWEpLgoKICAgICBTMSBhbmQgUzIgYXJlIExTRSBzd2l0Y2hlcyB0aGF0IGhhdmUgaW5z
dGFuY2VzIG9mIGV4dGVuZGVkIEFSUCBpbgogICAgIGNvbnRyb2wgcGxhbmUuIE5vdGUgdGhhdCBB
UlAgdXNlcyByZXNlcnZlZCBMZW5ndGgvVHlwZSBjb2RlCiAgICAgKD0weDA4MDYpIGluIGZyYW1l
IGhlYWRlci4gVGhlcmVmb3JlLCBMU0Ugc3dpdGNoZXMgYXJlIGFibGUgdG8KICAgICBkaXN0aW5n
dWlzaCBBUlAgbWVzc2FnZXMgZnJvbSBvdGhlciBFdGhlcm5ldCBmcmFtZXMsIGFuZCBpbnRlcmNl
cHQKICAgICAoaS5lLiBzbm9vcCkgQVJQIG1lc3NhZ2VzIGZvciBwcm9jZXNzaW5nIGluIGNvbnRy
b2wgcGxhbmUuIEluIHRoZQogICAgIGV4YW1wbGUgYWJvdmUsIFMxIGlzIHRoZSBmaXJzdCBMU0Ug
c3dpdGNoIHRoYXQgaW50ZXJjZXB0cyBBUlAKICAgICByZXF1ZXN0LgoKCgoKCkphaWh5dW5nIENo
byAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjAwNSAgICAgICAgICAgICAgICAgICBbUGFn
ZSA2XQoMCgpJTlRFUk5FVC1EUkFGVCAgICAgICAgICBBUlAgZm9yIExTUCBzZXR1cCBpbiBFQ1BO
ICAgICAgICAgIEZlYnJ1YXJ5IDIwMDUKCgogICAgIFMxIG92ZXJ3cml0ZXMgU291cmNlIEV0aGVy
bmV0IEFkZHJlc3MgZmllbGQgYW5kIFNlbmRlciBFdGhlcm5ldAogICAgIEFkZHJlc3MgZmllbGQg
b2YgdGhlIEFSUCByZXF1ZXN0IG1lc3NhZ2UgdG8gYSBtdWx0aWNhc3QgYWRkcmVzcwogICAgIHJl
c2VydmVkIGZvciB0aGlzIHByb3RvY29sLCBoZW5jZSB0aGUgYWRkcmVzc2VzIG9mIGZyYW1lIGhl
YWRlcgogICAgIGJlY29tZSAoREE9YnJvYWRjYXN0IGFkZHJlc3MsIFNBPW11bHRpY2FzdCBhZGRy
ZXNzKS4gVGhpcwogICAgIG1hc3F1ZXJhZGluZyBpcyBuZWNlc3NhcnkgaW4gb3JkZXIgdG8gcHJl
dmVudCBBUlAgcmVwbHkgbWVzc2FnZQogICAgIGJlaW5nIGZvcndhcmRlZCB0byBzb3VyY2Ugbm9k
ZSBkaXJlY3RseSBieSBub24tTFNFIHN3aXRjaGVzLiBJdAogICAgIGFsc28gZ2l2ZXMgYW4gZWZm
ZWN0IG9mIGNvbmNlYWxpbmcgcGh5c2ljYWwgYWRkcmVzcyBvZiBzb3VyY2UKICAgICB0ZXJtaW5h
bCwgdGh1cyBwcm92aWRlcyBnb29kIHNlY3VyaXR5LiBUaGUgZmlyc3QtaG9wIExTRSBzd2l0Y2gs
CiAgICAgUzEsIGVuY29kZXMgc2Vzc2lvbiBpZGVudGlmaWNhdGlvbiBpbmZvcm1hdGlvbiBpbiB0
aGUgVEVBIGZpZWxkLiBTMQogICAgIGJyb2FkY2FzdHMgdGhlIG1vZGlmaWVkIEFSUCByZXF1ZXN0
LCBhbmQgb3RoZXIgTFNFIHN3aXRjaGVzIHJlbGF5CiAgICAgdGhlIG1lc3NhZ2UuIEFzIGEgcmVz
dWx0LCB0aGUgbWVzc2FnZSBmaW5hbGx5IHJlYWNoZXMgdGFyZ2V0CiAgICAgdGVybWluYWwgRWIu
CgogICAgIFRhcmdldCB0ZXJtaW5hbCBFYiBtYXkgb3IgbWF5IG5vdCBoYXZlIGNhcGFiaWxpdHkg
Zm9yIG5lZ290aWF0aW5nCiAgICAgcmVzb3VyY2VzIGFjY29yZGluZyB0byB0aGlzIHByb3RvY29s
LiBXaGVuIEViIGlzIExTRSBjb25mb3JtaW5nLCBFYgogICAgIG1heSByZXBseSBhIG5lZ2F0aXZl
IG1lc3NhZ2UgZXhwbGljaXRseSwgc3VjaCBhcyBBUlAgZXJyb3IsIG9yCiAgICAgc2lsZW50bHkg
aWdub3JlIHRoZSBtZXNzYWdlIGlmIHRoZSByZXF1ZXN0IGlzIG5vdCBhY2NlcHRhYmxlLgogICAg
IE90aGVyd2lzZSwgYW55IG9yZGluYXJ5IHJlc3BvbnNlIHdpdGggQVJQIHJlcGx5IHdpbGwgYmUg
cmVnYXJkZWQgYXMKICAgICBjb25zZW50IHRvIGVzdGFibGlzaCBMU1AuIEZvciB0aGlzIHJlYXNv
biwgc291cmNlIHRlcm1pbmFscyBvZiB0aGlzCiAgICAgcHJvdG9jb2wgYXJlIGFibGUgdG8gZXN0
YWJsaXNoIExTUCB3aXRoIGFueSB0ZXJtaW5hbCByZWdhcmRsZXNzIG9mCiAgICAgcmVjZWl2ZXIg
Y2FwYWJpbGl0eSBvZiBzYW1lIHByb3RvY29sLiBUaGVyZWZvcmUsIHViaXF1aXRvdXMKICAgICBk
ZXBsb3ltZW50IG9mIHRoaXMgZXh0ZW5kZWQgZmVhdHVyZSBpcyBub3QgcHJlcmVxdWlzaXRlLgoK
ICAgICBUZXJtaW5hbCBFYiByZWNvcmRzIGl0cyBwaHlzaWNhbCBhZGRyZXNzICdFYicgaW4gU2Vu
ZGVyIEV0aGVybmV0CiAgICAgQWRkcmVzcyBmaWVsZCBhbmQgSVAgYWRkcmVzcyBpbiBTZW5kZXIg
SVB2NCBBZGRyZXNzIGZpZWxkLiAgVGFyZ2V0CiAgICAgSVB2NCBBZGRyZXNzIGlzIHRoZSBJUCBh
ZGRyZXNzIG9mIEVhLCBob3dldmVyLCBUYXJnZXQgRXRoZXJuZXQKICAgICBBZGRyZXNzIChURUEp
IGJlY29tZXMgbXVsdGljYXN0IGFkZHJlc3MgYmVjYXVzZSByZXNlcnZlZCBtdWx0aWNhc3QKICAg
ICBhZGRyZXNzIHdhcyB1c2VkIGluIFNvdXJjZSBFdGhlcm5ldCBBZGRyZXNzIGZpZWxkIGluIEFS
UCByZXF1ZXN0LgogICAgIEFkZHJlc3NlcyBvZiBmcmFtZSBoZWFkZXIgYmVjb21lIChEQT1tdWx0
aWNhc3QgYWRkcmVzcywgU0E9RWIpLiBFYgogICAgIHRyYW5zbWl0cyBBUlAgcmVwbHkgdG8gUzIu
CgogICAgIFMyIHJlY2VpdmVzIHRoZSBBUlAgcmVwbHkgYW5kIGFsbG9jYXRlcyB0d28gbGFiZWxz
LCAnTGMnIGFuZCAnTGQnCiAgICAgZm9yIGVhY2ggc2lkZSBvZiBpbnRlcmZhY2UuIE5vdGUgdGhh
dCB0aGUgbGFiZWxzLCAnTGMnIGFuZCAnTGQnLAogICAgIGFyZSByZXVzYWJsZSBNQUMgYWRkcmVz
c2VzIGNob3NlbiBvdXQgb2YgYWRkcmVzcyBwb29sIHJlc2VydmVkIGZvcgogICAgIExTRSBwcm90
b2NvbCAoc2VlIFtMU0VdIGZvciBkZXRhaWwpLiBTMiBjb25maWd1cmVzIHN3YXBwaW5nIGVudHJp
ZXMKICAgICBpbiBNQUMgbG9va3VwIHRhYmxlIHNvIHRoYXQgZGVzdGluYXRpb24gYWRkcmVzcyAn
TGMnIG9mIGFueQogICAgIGluY29taW5nIEV0aGVybmV0IGZyYW1lIHdpbGwgYmUgdHJhbnNsYXRl
ZCB0byAnRWInIHdoZW4gaXQgaXMKICAgICBmb3J3YXJkZWQgdG8gdGVybWluYWwgRWIuICBTMiBy
ZWNvcmRzIHRoZSBsYWJlbCAnTGMnIGluIFNlbmRlcgogICAgIEV0aGVybmV0IEFkZHJlc3MgZmll
bGQgYW5kIHBhc3NlcyB0aGUgQVJQIHJlcGx5IHRvIHVwc3RyZWFtCiAgICAgbmVpZ2hib3IgUzEu
CgogICAgIFVwb24gcmVjZWl2aW5nIHRoZSBBUlAgcmVwbHksIFMxIGFsc28gYWxsb2NhdGVzIHR3
byBuZXcgbGFiZWxzLAogICAgICdMYScgYW5kICdMYicsIGFuZCBjb25maWd1cmVzIHN3YXBwaW5n
IGVudHJpZXMgaW4gTUFDIHRhYmxlLiBTMQogICAgIG92ZXJ3cml0ZXMgU2VuZGVyIEV0aGVybmV0
IEFkZHJlc3MgYW5kIFNvdXJjZSBFdGhlcm5ldCBBZGRyZXNzIG9mCiAgICAgdGhlIG1lc3NhZ2Ug
dG8gJ0xhJywgYW5kIHJldHJpZXZlcyBEZXN0aW5hdGlvbiBFdGhlcm5ldCBBZGRyZXNzIGFuZAog
ICAgIFRhcmdldCBFdGhlcm5ldCBBZGRyZXNzdG8gb3JpZ2luYWwgcGh5c2ljYWwgYWRkcmVzcyBv
ZiB0ZXJtaW5hbCBFYS4KICAgICBIZW5jZSwgYWRkcmVzc2VzIG9mIGZyYW1lIGhlYWRlciBiZWNv
bWUgKERBPUVhLCBTQT1MYSkuIFdoZW4gRWEKICAgICByZWNlaXZlcyB0aGUgbW9kaWZpZWQgQVJQ
IHJlcGx5IG1lc3NhZ2UsIEVhIHdpbGwgYmVsaWV2ZSB0aGF0ICdMYScKICAgICBpcyB0aGUgcGh5
c2ljYWwgYWRkcmVzcyBvZiBkZXN0aW5hdGlvbiB0ZXJtaW5hbCBFYiwgYW5kIGNvbmZpZ3VyZXMK
ICAgICBJUC1FdGhlcm5ldCBtYXBwaW5nIGVudHJ5IG9mIEViIGluIEFSUCBjYXNoLiBBcyBhIHJl
c3VsdCwgYW55IElQCiAgICAgcGFja2V0IHRyYW5zbWl0dGVkIHRvIEViIHdpbGwgdXNlIHRoZSBN
QUMgYWRkcmVzcyAnTGEnLiBEZXRhaWwgb2YKICAgICBtZXNzYWdlIHZhbHVlcyBhdCBlYWNoIHN0
YWdlIG9mIEFSUCBwcm9jZWR1cmUgaXMgZXhwbGluZWQgaW4KCgoKCkphaWh5dW5nIENobyAgICAg
ICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjAwNSAgICAgICAgICAgICAgICAgICBbUGFnZSA3XQoM
CgpJTlRFUk5FVC1EUkFGVCAgICAgICAgICBBUlAgZm9yIExTUCBzZXR1cCBpbiBFQ1BOICAgICAg
ICAgIEZlYnJ1YXJ5IDIwMDUKCgogICAgIGFwcGVuZGl4IEEuCgoKICAgICBMYWJlbCBzd2l0Y2hl
ZCBmcmFtZSB0cmFuc21pc3Npb24gcHJvY2VkdXJlIGlzIGRlc2NyaWJlZCBiZWxvdyBvZgogICAg
IGRvdHRlZCBsaW5lIGluIEZpZ3VyZSAxLiBUaGUgaW5pdGlhbCBNQUMgaGVhZGVyIHRoYXQgRWEg
Y3JlYXRlcwogICAgIHdpbGwgYmUgKERBPUxhLCBTQT1FYSkuIFdoZW4gUzEgcmVjZWl2ZXMgdGhl
IGZyYW1lLCBTMSBwZXJmb3JtcwogICAgIG5vcm1hbCBNQUMgdGFibGUgbG9va3VwIHVzaW5nIHRo
ZSBkZXN0aW5hdGlvbiBhZGRyZXNzIExhIGFuZAogICAgIGlkZW50aWZpZXMgdGhhdCBMYSBpcyB0
aGUgbGFiZWwgdGhhdCBTMSBhc3NpZ25lZCBmb3IgdGhpcyBmbG93LiBTMQogICAgIHN3YXBzIE1B
QyBhZGRyZXNzZXMgaW4gdGhlIGhlYWRlciBmcm9tIChEQT1MYSwgU0E9RWEpIHRvIChEQT1MYywK
ICAgICBTQT1MYikuIFJlY2FsbCB0aGF0IExiIGlzIHRoZSBhZGRyZXNzIFMxIGFzc2lnbmVkIG9u
IG91dHB1dAogICAgIGludGVyZmFjZSBhbmQgTGMgaXMgdGhlIGFkZHJlc3MgUzIgaW5mb3JtZWQg
dXNpbmcgQVJQIHJlcGx5LiBXaGVuCiAgICAgUzIgcmVjZWl2ZXMgdGhpcyBmcmFtZSwgUzIgYWxz
byBzd2FwcyBNQUMgYWRkcmVzc2VzIGZyb20gKERBPUxjLAogICAgIFNBPUxiKSB0byAoREE9RWIs
IFNBPUxkKSBhbmQgZm9yd2FyZHMgdGhlIGZyYW1lIHRvIGRlc3RpbmF0aW9uCiAgICAgdGVybWlu
YWwgRWIuIE5vIG1vZGlmaWNhdGlvbiBvZiBpbnRlcmZhY2UgaGFyZHdhcmUgaXMgcmVxdWlyZWQg
aW4KICAgICBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIHRlcm1pbmFscy4KCiAgICAgRGV0YWlsIG9m
IGFkZHJlc3Mgc3dhcHBpbmcgdGVjaG5pcXVlIGlzIGRpc2N1c3NlZCBpbiBbTFNFXS4gSXQgaXMK
ICAgICByZS1zdGF0ZWQgdGhhdCB0cmFkZW9mZiBvZiBzd2FwcGluZyBvcGVyYXRpb24gY29tcGFy
ZWQgdG8gdHlwaWNhbAogICAgIEV0aGVybmV0IHN3aXRjaGluZyBpcyBpbXByb3ZlZCBRb1MgYW5k
IHByb3RlY3Rpb24uIEZsb3cKICAgICBpZGVudGlmaWNhdGlvbiBpcyBhbiBlc3NlbnRpYWwgZWxl
bWVudCBpbiBwcm92aWRpbmcgUW9TLiBUaGUKICAgICBwcm9wb3NlZCBMU0UgdGVjaG5pcXVlIGVu
YWJsZXMgRXRoZXJuZXQgc3dpdGNoZXMgZGlzdGluZ3Vpc2gKICAgICBhcHBsaWNhdGlvbiBmbG93
cyBvbmx5IHVzaW5nIE1BQyBhZGRyZXNzLiBUaGlzIHNpbXBsaWZpZXMgaGFyZHdhcmUKICAgICBh
cmNoaXRlY3R1cmUgdG8gaW1wbGVtZW50IHBlci1mbG93IGRpZmZlcmVudGlhdGVkIHNlcnZpY2Us
IGJlY2F1c2UKICAgICBFdGhlcm5ldCBzd2l0Y2hlcyBkbyBub3QgbmVlZCB0byBjaGVjayBhZGRp
dGlvbmFsIGZpZWxkcywgc3VjaCBhcwogICAgIFZMQU4gdGFnLCBJUCBoZWFkZXIgYW5kIFRDUCBo
ZWFkZXIuIEltcHJvdmVkIHByb3RlY3Rpb24gZnJvbQogICAgIGludHJ1c2lvbiBpcyBhZGRpdGlv
bmFsIGJlbmVmaXQgYmVjYXVzZSBwaHlzaWNhbCBhZGRyZXNzIG9mIHVzZXIKICAgICB0ZXJtaW5h
bCBpcyBub3QgZXhwb3NlZC4KCgozLiBGbG9vZCBSb3V0aW5nIFRlY2huaXF1ZQoKICAgICBUaGUg
dW5pcXVlIGZlYXR1cmUgb2YgQVJQIHNpZ25hbGluZyBpcyBBUlAgaW5jb3Jwb3JhdGVzIHJvdXRp
bmcKICAgICBjYXBhYmlsaXR5IHRoYXQgaXQgZmluZHMgb3B0aW11bSBwYXRoIHNhdGlzZnlpbmcg
UW9TIHJlcXVpcmVtZW50LgogICAgIEl0IGlzIGFuIGludGVncmF0ZWQgc29sdXRpb24gdGhhdCBt
ZXJnZXMgYWRkcmVzcyByZXNvbHV0aW9uLCByb3V0ZQogICAgIHNlbGVjdGlvbiBhbmQgbGFiZWwg
ZGlzdHJpYnV0aW9uIGluIG9uZSBtZWNoYW5pc20uIENvbnRyYXN0IHRvIElQCiAgICAgcm91dGlu
ZyBwcm90b2NvbHMsIHRoaXMgbWV0aG9kIGRvZXMgbm90IHJlcXVpcmUgYW55IHByZS0KICAgICBj
b25maWd1cmF0aW9uIHN1Y2ggYXMgbm9kZSBvciBsaW5rIG51bWJlcmluZywgaGVuY2UgcmVkdWNl
cwogICAgIG9wZXJhdGlvbmFsIG92ZXJoZWFkLiBUaGlzIGFsZ29yaXRobSBhbHNvIG1pbmltaXpl
cyBkZXBlbmRlbmN5IHRvCiAgICAgaW5lZmZpY2llbnQgc3Bhbm5pbmcgdHJlZSBhbGdvcml0aG1z
LgoKICAgICBUaGUgcmF0aW9uYWxlIGJlaGluZCB0aGUgZmxvb2Qgcm91dGluZyBhbGdvcml0aG0g
aXMgc3Vydml2YWwgb2YgdGhlCiAgICAgZml0dGVzdC4gTFNFIG5vZGVzIHByb2R1Y2UgbXVsdGlw
bGUgY29waWVzIG9mIEFSUCBtZXNzYWdlcyB0bwogICAgIGV4cGxvcmUgdW5rbm93biByb3V0ZXMu
IEFzIHRoZSBBUlAgbWVzc2FnZXMgcHJvcGFnYXRlIG5ldHdvcmssIGVhY2gKICAgICBtZXNzYWdl
IGV4cGVyaWVuY2UgZGlmZmVyZW50IGRpZmZpY3VsdHkgaW4gcHJvZ3Jlc3NpbmcgbmV0d29yawog
ICAgIGFjY29yZGluZyB0byBuZXR3b3JrIGxvYWQsIGFuZCByZWNvcmQgdGhlIGRpZmZpY3VsdHkg
aW5mb3JtYXRpb24uCiAgICAgSW50ZXJtZWRpYXRlIG5vZGVzIGV2YWx1YXRlIHRoZSBpbmZvcm1h
dGlvbiBjYXJyaWVkIGluIG1lc3NhZ2UgYW5kCiAgICAgc2VsZWN0IHRoZSBmaXR0ZXN0IG9uZSBm
b3IgZHVwbGljYXRpb24uIEFzIGEgcmVzdWx0LCBvbmx5IHRoZQogICAgIG1lc3NhZ2UgdGhhdCB0
cmF2ZXJzZWQgdmlhIG1vc3QgYXBwcm9wcmlhdGUgcGF0aCBpcyBhY2NlcHRlZCBhcwogICAgIGZp
bmFsIHdpbm5lciwgYW5kIHRoZSBpbmZvcm1hdGlvbiBvZiB0aGUgcGF0aCBleHBsb3JlZCBieSB0
aGUKICAgICBtZXNzYWdlIGlzIHVzZWQgZm9yIGVzdGFibGlzaGluZyBMU1Agb3Igcm91dGluZyBk
YXRhYmFzZS4KCiAgICAgVGhlIGJhc2ljIGFjdGlvbiBvZiBmbG9vZGluZyBpcyBkZXNjcmliZWQg
aW4gZmlndXJlIDMgYmVsb3cuIFdoZW4gYQoKCgoKSmFpaHl1bmcgQ2hvICAgICAgICAgICAgICAg
IEV4cGlyZXMgSnVseSAyMDA1ICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKCklOVEVSTkVU
LURSQUZUICAgICAgICAgIEFSUCBmb3IgTFNQIHNldHVwIGluIEVDUE4gICAgICAgICAgRmVicnVh
cnkgMjAwNQoKCiAgICAgbm9kZSByZWNlaXZlcyBhbiBBUlAgcmVxdWVzdCBmcm9tIGEgc291cmNl
IHRlcm1pbmFsLCB0aGUgbm9kZQogICAgIGJyb2FkY2FzdHMgZHVwbGljYXRlcyBvZiB0aGUgQVJQ
IG1lc3NhZ2UgdG8gYWxsIG91dHB1dCBpbnRlcmZhY2VzCiAgICAgZXhjZXB0IHRoZSBvbmUgZnJv
bSB3aGljaCB0aGUgbWVzc2FnZSB3YXMgcmVjZWl2ZWQuIE5laWdoYm9yaW5nCiAgICAgbm9kZXMg
dGhhdCByZWNlaXZlIHRoZSBtZXNzYWdlIGFsc28gcmVwZWF0IHRoZSBjb3B5LWFuZC1icm9hZGNh
c3QKICAgICBhY3Rpb24gYmxpbmRseSwgYXMgYSByZXN1bHQsIG5ldHdvcmsgd2lsbCBzb29uIGJl
IHNhdHVyYXRlZCBieQogICAgIGR1cGxpY2F0ZXMgb2YgdGhlIG1lc3NhZ2VzIGlmIHRoZXJlIGlz
IG5vIGNvbnRyb2wgbWV0aG9kLiBJbiB0aGlzCiAgICAgQVJQIGV4dGVuc2lvbiwgNmJ5dGVzIG9m
IFRFQSAoVGFyZ2V0IEV0aGVybmV0IEFkZHJlc3MpIGZpZWxkIGlzCiAgICAgdXNlZCBmb3IgZW5j
b2RpbmcgaW5mb3JtYXRpb24gbmVjZXNzYXJ5IHRvIGNvbnRyb2wgZmxvb2RpbmcuIEZpZ3VyZQog
ICAgIDQgZGVzY3JpYmVzIHRoZSBURUEgZm9ybWF0LgoKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBfX18KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFS
UChtPTcpICAgIC8gICBcICAgICBBUlAobT0xNSkKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAtLS0tLS0tLS0tLS0+fCAgUzIgfC0tLS0tLS0tLS0tLS0tPgogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgLyAgW2Nvc3Q9OF0gICAgXF9fXy8KICAgICAgICAgICAgICAgICAgICAgICAgICAg
LyAgICAgICAgICAgICAgW21pbj0xNV0gICBBUlAobT05KQogICAgICAgICAgICAgICAgICAgIF9f
XyAgIC8gICAgICAgICAgICAgICAgIF9fXyAgIC0tLS0tLS0tLS0tLS0+CiAgICAgICAgQVJQKG09
MykgICAvICAgXCAvICAgICBBUlAobT03KSAgICAvICAgXCAvCiAgICAgIC0tLS0tLS0tLS0tPnwg
IFMxIHwtLS0tLS0tLS0tLS0tLS0tPnwgIFMzIHwtLS0tQVJQKG09OSktLT4KICAgICAgICBbY29z
dD00XSAgIFxfX18vIFwgICAgIFtjb3N0PTJdICAgIFxfX18vIFwKICAgICAgICAgICAgICAgICAg
W21pbj03XSBcICAgICAgICAgICAgICAgW21pbj05XSAtLS0tLS0tLS0tLS0tPgogICAgICAgICAg
ICAgICAgICAgICAgICAgICBcICAgICAgICAgICAgICAgIF9fXyAgICAgIEFSUChtPTkpCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBcICBBUlAobT03KSAgICAvICAgXAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLT58ICBTNCB8LS0tLS0tLS0tLS0tLS0+CiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBbY29zdD05XSAgICBcX19fLyAgICAgQVJQKG09MTYp
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbbWluPTE2XQoKICAg
ICBGaWd1cmUgMyAgQmFzaWMgRmxvb2RpbmcgQWN0aW9uCgoKICAgICBJbiBmaWd1cmUgNCwgdGhl
IGZpcnN0IDE2IGJpdHMgb2YgVGltZXN0YW1wIGlzIHVzZWQgZm9yCiAgICAgaWRlbnRpZmljYXRp
b24gb2YgZmxvb2QgYXNzb2NpYXRlZCB3aXRoIHRoaXMgc2Vzc2lvbi4gQ29tYmluZWQgd2l0aAog
ICAgIFNlbmRlciBJUHY0IGFkZHJlc3MgKGkuZS4sIHNvdXJjZSB0ZXJtaW5hbCBhZGRyZXNzKSwg
dGhlIHBhaXIgb2YKICAgICAoSVB2NCBhZGRyZXNzLCBUaW1lc3RhbXApIHVuaXF1ZWx5IGlkZW50
aWZpZXMgQVJQIG1lc3NhZ2UuIE9ubHkgdGhlCiAgICAgZmlyc3QtaG9wIExTRSBzd2l0Y2ggdGhh
dCByZWNlaXZlcyBBUlAgcmVxdWVzdCBkaXJlY3RseSBmcm9tIHNvdXJjZQogICAgIHRlcm1pbmFs
IGlzIGVudGl0bGVkIHRvIHNldCB0aGUgVGltZXN0YW1wLCBhbmQgb3ZlcndyaXRlcyB0aGUKICAg
ICBTb3VyY2UgRXRoZXJuZXQgQWRkcmVzcyB0byBhIHJlc2VydmVkIG11bHRpY2FzdCBhZGRyZXNz
LiBPdGhlciBMU0UKICAgICBub2RlcyBtdXN0IG5vdCBhbHRlciB0aGUgVGltZXN0YW1wIGlmIHRo
ZSBTb3VyY2UgRXRoZXJuZXQgQWRkcmVzcwogICAgIGlzIHRoZSBtdWx0aWNhc3QgYWRkcmVzcy4K
CiAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg
ICAgICAgICAgIDMgMwogICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4
IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICAgVGlt
ZXN0YW1wICgxNmJpdCkgICAgICAgICB8ICAgICAgIE1ldHJpYyAoMTZiaXQpICAgICAgICAgIHwK
ICAgICAgKy0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSsKICAgICAgfEZPIHwgIEJhbmR3aWR0aCAoMTRiaXQpICAgICAgICB8CiAg
ICAgICstLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgICBGaWd1cmUgNCAgRmxv
b2QgQ29udHJvbCBJbmZvcm1hdGlvbiBFbmNvZGluZyBpbiBURUEgRmllbGQKCgogICAgIEZvbGxv
d2luZyB0aGUgVGltZXN0YW1wLCAxNiBiaXRzIG9mIE1ldHJpYyBmaWVsZCBpbmRpY2F0ZXMKICAg
ICBkaWZmaWN1bHR5IG9mIHBhdGggdGhhdCBBUlAgcmVxdWVzdCBoYXMgdHJhdmVyc2VkLiBMU0Ug
bm9kZXMgYWRkIHVwCgoKCgpKYWloeXVuZyBDaG8gICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5
IDIwMDUgICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDAoKSU5URVJORVQtRFJBRlQgICAgICAg
ICAgQVJQIGZvciBMU1Agc2V0dXAgaW4gRUNQTiAgICAgICAgICBGZWJydWFyeSAyMDA1CgoKICAg
ICBjb3N0IG9mIGlucHV0IGxpbmsgdG8gdGhlIG1ldHJpYyB2YWx1ZS4gVGhlIGxpbmsgY29zdCBp
cyBhIGxvY2FsbHkKICAgICBtZWFzdXJlZCB2YWx1ZSBvZiBjdXJyZW50IGxvYWQgdGhhdCByZWZs
ZWN0cyB2YXJpb3VzIGNyaXRlcmlhIG9mCiAgICAgdHJhZmZpYyBzdGF0ZSBzdWNoIGFzIGxpbmsg
dXRpbGl6YXRpb24sIGZyYW1lIGxvc3Mgb3IgbnVtYmVyIG9mCiAgICAgTFNQcy4gSGlnaCBtZXRy
aWMgdmFsdWUgaW1wbGllcyBiYWQgcGF0aCB0byBhdm9pZC4KCiAgICAgRmlndXJlIDMgc2hvd3Mg
ZXhhbXBsZSB0aGF0IG1ldHJpYyB2YWx1ZXMgYXJlIGNvbXB1dGVkIGF0IGVhY2gKICAgICBub2Rl
LiBJbiBmaWd1cmUgMywgcmVjZWl2ZWQgbWV0cmljIHZhbHVlIG9mIEFSUCByZXF1ZXN0IGF0IFMx
IGlzIDMKICAgICBhbmQgY29zdCBvZiBpbnB1dCBsaW5rIGlzIDQsIGhlbmNlIHRoZSBtZXRyaWMg
dmFsdWUgYmVjb21lcyA3CiAgICAgKD0zKzQpLiBNZXRyaWMgdmFsdWUgb2YgdGhlIEFSUCByZXF1
ZXN0IGlzIHVwZGF0ZWQgdG8gNy4gVGhlCiAgICAgaW5mb3JtYXRpb24gb2YgQVJQIG1lc3NhZ2Ug
YW5kIG1ldHJpYyB2YWx1ZSwgZGVub3RlZCBieSBbbWluPTddIGluCiAgICAgdGhlIGZpZ3VyZSwg
aXMgc3RvcmVkIGluIFMxLiBTMSBicm9hZGNhc3RzIHRoZSBtZXNzYWdlIHRocm91Z2ggYWxsCiAg
ICAgb3V0cHV0IGxpbmtzLiBOZWlnaGJvcmluZyBub2RlcywgUzIsIFMzIGFuZCBTNCwgcmVjZWl2
ZSBkdXBsaWNhdGVzCiAgICAgb2YgQVJQIHJlcXVlc3QuIEVhY2ggbm9kZSB1cGRhdGVzIG1ldHJp
YyB2YWx1ZSBhY2NvcmRpbmcgdG8gY29zdCBvZgogICAgIGlucHV0IGxpbmsgYW5kIHJlcGVhdHMg
dGhlIGNvcHktYW5kLWJyb2FkY2FzdGluZyBhY3Rpb24gZGVzY3JpYmVkCiAgICAgYWJvdmUuIFNp
bmNlIHRoZSBBUlAgbWVzc2FnZXMgdHJhdmVyc2VkIGxpbmtzIG9mIGRpZmZlcmVudCBjb3N0LAog
ICAgIG1ldHJpYyB2YWx1ZXMgb2Ygb3V0cHV0IG1lc3NhZ2VzIGFmdGVyIHRoZSBub2RlcyBiZWNv
bWUgZGlmZmVyZW50LgogICAgIEFtb25nIHRoZSBtZXNzYWdlcyBvZiBkaWZmZXJlbnQgbWV0cmlj
cywgb25seSB0aGUgbG93ZXN0IG9uZSB3aWxsCiAgICAgYmUgY2hvc2VuIHRvIHByb2R1Y2Ugb2Zm
c3ByaW5nIGJ5IGludGVybWVkaWF0ZSBub2Rlcy4gVGhpcwogICAgIHNlbGVjdGlvbiBwcm9jZWR1
cmUgaXMgZGVzY3JpYmVkIGluIGZpZ3VyZSA1IGJlbG93LgoKCiAgICAgICAgIEFSUChtPTQpICAg
ICAgICAgICAgICAgICBBUlAobT05KQogICAgICAtLS0tLS0tLS0tLS0tLSAgICAgICAgICAgIC0t
LS0tLS0tLS0tCiAgICAgICAgIFtjb3N0PTZdICAgXCAgICAgICAgICAgICBbY29zdD0xXSBcCiAg
ICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAg
ICAgICAgICAgeCAgIF9fXyAgICAgICAgICAgICAgICB4ICAgX19fCiAgICAgICAgIEFSUChtPTIp
ICAgICAgICAvICAgXCAgICAgQVJQKG09NikgICAgIC8gICBcICAgQVJQKG09OCkKICAgICAgLS0t
LS0tLS0tLS0tLS0tLS0+fCAgUzUgfC0tLS0tLS0tLS0tLS0tLT58ICBTNiB8LS0tLS0tLS0tLS0+
CiAgICAgICAgIFtjb3N0PTRdICAgICAgICBcX19fLyAgICAgW2Nvc3Q9Ml0gICAgIFxfX18vCiAg
ICAgICAgICAgICAgICAgICAgICB4IFttaW49Nl0gICAgICAgICAgICAgIHggW21pbj04XQogICAg
ICAgICAgICAgICAgICAgICAvICAgICAgICAgICAgICAgICAgICAgIC8KICAgICAgICAgQVJQKG09
OCkgICAvICAgICAgICAgICAgIEFSUChtPTUpIC8KICAgICAgLS0tLS0tLS0tLS0tLS0gICAgICAg
ICAgICAtLS0tLS0tLS0tLQogICAgICAgICBbY29zdD0yXSAgICAgICAgICAgICAgICAgW2Nvc3Q9
NV0KCiAgICAgRmlndXJlIDUgIFNlbGVjdGlvbiBwcm9jZXNzIG9mIHRoZSBsb3dlc3QgbWV0cmlj
IEFSUCByZXF1ZXN0CgoKICAgICBJbiBmaWd1cmUgNSwgaXQgaXMgYXNzdW1lZCB0aGF0IFM1IHJl
Y2VpdmVzIG11bHRpcGxlIEFSUCByZXF1ZXN0cwogICAgIHRyYXZlcnNlZCB2aWEgZGlmZmVyZW50
IHJvdXRlcy4gQW1vbmcgdGhlIG1lc3NhZ2VzLCBTNSBzZWxlY3RzCiAgICAgbWVzc2FnZSBvZiB0
aGUgbG93ZXN0IG1ldHJpYyB2YWx1ZSAoaS5lLiwgbT0yLCBjb3N0PTQsIHRodXMKICAgICBbbWlu
PTZdKSBmb3IgZHVwbGljYXRpb24uIE90aGVyIG1lc3NhZ2VzIG9mIGhpZ2hlciBtZXRyaWMgdmFs
dWUgYXJlCiAgICAgZGlzY2FyZGVkLiBTNiBhbHNvIHJlY2VpdmVzIEFSUCByZXF1ZXN0cyBmcm9t
IG5laWdoYm9yaW5nIG5vZGVzLAogICAgIGhvd2V2ZXIsIG9ubHkgdGhlIG9uZSByZWNlaXZlZCBm
cm9tIFM1IGhhcyB0aGUgbG93ZXN0IG1ldHJpYyB2YWx1ZQogICAgIChpLmUuLCBtPTYsIGNvc3Q9
MiwgdGh1cyBbbWluPThdKS4gVGhlcmVmb3JlIHRoZSBtZXNzYWdlIGlzCiAgICAgc2VsZWN0ZWQg
dG8gcHJvcGFnYXRlIHRoZSBuZXR3b3JrLiBOb3RlIHRoYXQgbmV0d29yayBub2RlcyBzaW1wbHkK
ICAgICByZXBlYXQgc2VsZWN0LWFuZC1icm9hZGNhc3QgYWN0aW9uIGJsaW5kbHksIGhvd2V2ZXIg
dGhlIGVuZCByZXN1bHQKICAgICBpcyByZWZpbmluZyByb3V0ZXMgdGhhdCBvbmx5IHRoZSBtZXNz
YWdlIHRyYXZlcnNlZCB2aWEgbW9zdAogICAgIGFwcHJvcHJpYXRlIHBhdGggc3Vydml2ZXMgYW5k
IHJlYWNoZXMgZmluYWwgdGFyZ2V0LgoKICAgICBUaGVyZSBjYW4gYmUgbXVsdGlwbGUgYXZhaWxh
YmxlIHBhdGhzIGJldHdlZW4gc291cmNlIGFuZAogICAgIGRlc3RpbmF0aW9uIHRlcm1pbmFscywg
aG93ZXZlciwgdGhlIG1vc3QgbGlnaHRseSBsb2FkZWQgcGF0aCBpcwoKCgoKSmFpaHl1bmcgQ2hv
ICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyMDA1ICAgICAgICAgICAgICAgICAgW1BhZ2Ug
MTBdCgwKCklOVEVSTkVULURSQUZUICAgICAgICAgIEFSUCBmb3IgTFNQIHNldHVwIGluIEVDUE4g
ICAgICAgICAgRmVicnVhcnkgMjAwNQoKCiAgICAgY2hvc2VuIGJ5IGZsb29kaW5nIGZvciBlc3Rh
Ymxpc2htZW50IG9mIExTUC4gRm9yIGV4YW1wbGUgaW4gZmlndXJlCiAgICAgNiwgdGhlcmUgYXJl
IHRocmVlIGF2YWlsYWJsZSBwYXRocyBiZXR3ZWVuIHRlcm1pbmFscyBFYSBhbmQgRWIuIFM1CiAg
ICAgcmVjZWl2ZXMgQVJQIHJlcXVlc3RzIG9mIGRpZmZlcmVudCBtZXRyaWMgdmFsdWVzIGZyb20g
UzIsIFMzIGFuZAogICAgIFM0LiBBbW9uZyB0aGUgcHJlc2VudGVkIHBhdGhzLCBFYS0+UzEtPlMz
LT5TNS0+RWIgaXMgdGhlIGxpZ2h0bHkKICAgICBsb2FkZWQgcGF0aCBiZWNhdXNlIG1ldHJpYyB2
YWx1ZSBvZiB0aGUgQVJQIHJlcXVlc3QgaXMgb25seSA1IHdoaWxlCiAgICAgb3RoZXJzIGFyZSAx
MCBhbmQgMTYuIEhlbmNlLCBTNSBzZWxlY3RzIHRoZSBBUlAgcmVxdWVzdCByZWNlaXZlZAogICAg
IGZyb20gUzMgYW5kIGJyb2FkY2FzdHMgaXQuCgogICAgIFRhcmdldCB0ZXJtaW5hbCBFYiByZXNw
b25kcyB3aXRoIEFSUCByZXBseSBhcyB0eXBpY2FsIEFSUAogICAgIHByb2NlZHVyZS4gVXBvbiBy
ZWNlaXZpbmcgdGhlIEFSUCByZXBseSwgUzUgY29uZmlndXJlcyBMU1AgYXMgdGhlCiAgICAgcHJv
Y2VkdXJlIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDIuIFM1IGVuY29kZXMgbGFiZWwgaW5mb3JtYXRp
b24gaW4KICAgICBBUlAgcmVwbHkgYW5kIHBhc3NlcyBpdCB0byBTMyBiZWNhdXNlIEFSUCByZXF1
ZXN0IG9mIHRoZSBsb3dlc3QKICAgICBtZXRyaWMgdmFsdWUgd2FzIHJlY2VpdmVkIGZyb20gUzMu
IFMzIGFsc28gY29uZmlndXJlcyBMU1AgYW5kCiAgICAgZm9yd2FyZHMgQVJQIHJlcGx5IHRvIFMx
IGJlY2F1c2UgUzEgaXMgdGhlIG9ubHkgbm9kZSB0aGF0IHBhc3NlZAogICAgIEFSUCByZXF1ZXN0
LiBGaW5hbGx5LCBTMSBjb25maWd1cmVzIExTUCBhbmQgaW5mb3JtcyBhIE1BQyBhZGRyZXNzCiAg
ICAgdGhhdCBFYSB3aWxsIHVzZSBmb3IgdGhpcyBMU1AuIEFzIGEgcmVzdWx0LCBMU1AgaXMgZXN0
YWJsaXNoZWQgdmlhCiAgICAgc2hvcnRlc3QgcGF0aCBpbiBsb2NhbCBuZXR3b3JrIHdpdGhvdXQg
cmVseWluZyBvbiBwcmUtZXN0YWJsaXNoZWQKICAgICByb3V0aW5nIGRhdGFiYXNlIG9yIGNvbXBs
ZXggcm91dGluZyBhbGdvcml0aG0uIERldGFpbCBvZiBvdGhlcgogICAgIGlzc3Vlcywgc3VjaCBh
cyBMU1Aga2VlcC1hbGl2ZSwgdGVybWluYXRpb24gYW5kIGZhaWx1cmUgcmVjb3ZlciwKICAgICBh
cmUgbm90IHByZXNlbnRlZCBpbiB0aGlzIGludHJvZHVjdG9yeSBkcmFmdC4KCiAgICAgICAgICAg
ICAgICAgICAgICAgICArLS0tLSsgICBTb3VyY2UgVGVybWluYWwKICAgICAgICAgICAgICAgICAg
ICAgICAgIHwgRWEgfAogICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0rCiAgICAgICAgICAg
ICAgICAgICBBUlBycHkgXiB8IEFSUHJlcQogICAgICAgICAgICAgICAgICAgICAgICAgIHwgfAog
ICAgICAgICAgICAgICAgICAgICAgICAgIHxfVgogICAgICAgICAgICBBUlByZXEobT0xKSAgLyAg
IFwgIEFSUHJlcShtPTEpCiAgICAgICAgICAgICAgIDwtLS0tLS0tLXwgIFMxIHwtLS0tLS0tLS0+
CiAgICAgICAgICAgICAgLyAgICAgICAgICBcX19fLyAgICAgICAgICAgXAogICAgICAgICAgICAg
LyAgICAgICAgICAgIF4gfCAgICAgICAgICAgICBcCiAgICAgICAgICAgIC8gICAgICBBUlBycHkg
fCB8IEFSUHJlcShtPTEpICBcCiAgICAgICAgX19fLyAgICAgICAgICAgICAgfF9WICAgICAgICAg
ICAgICAgXF9fXwogICAgICAgLyAgIFwgICAgICAgICAgICAgLyAgIFwgICAgICAgICAgICAgIC8g
ICBcCiAgICAgIHwgIFMyIHwgICAgICAgICAgIHwgIFMzIHwgICAgICAgICAgICB8ICBTNCB8CiAg
ICAgICBcX19fLyAgICAgICAgICAgICBcX19fLyAgICAgICAgICAgICAgXF9fXy8KICAgICAgICAg
ICBcICAgICAgICAgICAgICBeIHwgICAgICAgICAgICAgICAvCiAgICAgICAgICAgIFwgICAgICBB
UlBycHkgfCB8IEFSUHJlcShtPTUpICAvCiAgICAgICAgICAgICBcICAgICAgICAgICAgfF9WICAg
ICAgICAgICAgIC8KICAgICAgICAgICAgICBcICAgICAgICAgIC8gICBcICAgICAgICAgICAvCiAg
ICAgICAgICAgICAgIC0tLS0tLT54IHwgIFM1IHwgeDwtLS0tLS0tCiAgICAgICAgICAgQVJQcmVx
KG09MTApICBcX19fLyAgICBBUlByZXEobT0xNikKICAgICAgICAgICAgICAgICAgICAgICAgICBe
IHwKICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwKICAgICAgICAgICAgICAgICAgIEFSUHJw
eSB8IFYgQVJQcmVxCiAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLSsKICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgRWIgfAogICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0rICBEZXN0
LiBUZXJtaW5hbAoKCiAgICAgIEZpZ3VyZSA2IFBhdGggc2VsZWN0aW9uIGFuZCBBUlAgcmVwbHkK
CgoKCgpKYWloeXVuZyBDaG8gICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDIwMDUgICAgICAg
ICAgICAgICAgICBbUGFnZSAxMV0KDAoKSU5URVJORVQtRFJBRlQgICAgICAgICAgQVJQIGZvciBM
U1Agc2V0dXAgaW4gRUNQTiAgICAgICAgICBGZWJydWFyeSAyMDA1CgoKNC4gQ29uc3RyYWludCBC
YXNlZCBSb3V0aW5nCgoKICAgICBUaGUgYmFzaWMgbWVjaGFuaXNtIG9mIGZsb29kaW5nIGV4cGxh
aW5lZCBpbiBzZWN0aW9uIDMgYWNoaWV2ZXMKICAgICBsaWdodGx5IGxvYWRlZCBwYXRoIGluIG5l
dHdvcmsuIEhvd2V2ZXIgdGhlIHBhdGggaXMgbm90IGEgUW9TIHBhdGgKICAgICBiZWNhdXNlIG5v
IHVzZXIgcmVxdWlyZW1lbnQgaXMgY29uc2lkZXJlZCBpbiBpbnRlcm1lZGlhdGUgbm9kZXMuCiAg
ICAgQVJQIHJlcXVlc3QgbWVzc2FnZSBjYW4gY2FycnkgdXNlciByZXF1aXJlbWVudCBvZiBiYW5k
d2lkdGggaW4gVEVBCiAgICAgZmllbGQuIExhc3QgMTQgYml0cyBvZiBURUEgZmllbGQgaW5kaWNh
dGVzIGJhbmR3aWR0aCBjb25zdHJhaW50CiAgICAgKHNlZSBmaWd1cmUgNCkuIElmIHVzZXIgYXBw
bGljYXRpb24gaXMgTFNFIGNhcGFibGUsIHNvdXJjZSB0ZXJtaW5hbAogICAgIGVuY29kZXMgYmFu
ZHdpZHRoIHJlcXVpcmVtZW50IGluIFRFQSBmaWVsZCB3aGVuIHRoZSBhcHBsaWNhdGlvbgogICAg
IHNwZWNpZmllZCBRb1MgcGFyYW1ldGVyLgoKICAgICBJbnRlcm1lZGlhdGUgbm9kZXMgZXZhbHVh
dGUgYXZhaWxhYmxlIHJlc291cmNlcyB3aGVuIHRoZSBiYW5kd2lkdGgKICAgICBmaWVsZCBvZiBy
ZWNlaXZlZCBBUlAgcmVxdWVzdCBpcyBub3QgbnVsbC4gSWYgdGhlIHVzZXIgcmVxdWVzdCBmb3IK
ICAgICBiYW5kd2lkdGggY2Fubm90IGJlIHNhdGlzZmllZCwgdGhlIG5vZGUgc2ltcGx5IGRpc2Nh
cmRzIHRoZQogICAgIHJlY2VpdmVkIG1lc3NhZ2UuIE90aGVyd2lzZSwgdGhlIG5vZGUgcGVyZm9y
bXMgYmFzaWMgZmxvb2RpbmcKICAgICBhY3Rpb24gYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4g
VGhlIHJlc3VsdCBpcyB0aGF0IEFSUCByZXF1ZXN0CiAgICAgbWVzc2FnZXMgcHJvcGFnYXRlIG9u
bHkgdGhyb3VnaCBsaW5rcyBvZiBlbm91Z2ggYmFuZHdpZHRoLiBJZiB0aGVyZQogICAgIGFyZSBt
dWx0aXBsZSBwYXRocyBzYXRpc2Z5aW5nIHRoZSBiYW5kd2lkdGggcmVxdWlyZW1lbnQsIG11bHRp
cGxlCiAgICAgQVJQIG1lc3NhZ2VzIG1heSBzdWNjZWVkIHRvIHJlYWNoIGRlc3RpbmF0aW9uLiBB
bW9uZyB0aGUgbWVzc2FnZXMsCiAgICAgQVJQIHJlcXVlc3Qgb2YgdGhlIGxvd2VzdCBtZXRyaWMg
aXMgYWNjZXB0ZWQuIEFzIGEgcmVzdWx0LCBsaWdodGx5CiAgICAgbG9hZGVkIHBhdGggc2F0aXNm
eWluZyB0aGUgYmFuZHdpZHRoIHJlcXVpcmVtZW50IGlzIHNlbGVjdGVkIGZvcgogICAgIGVzdGFi
bGlzaG1lbnQgb2YgTFNQLgoKICAgICBOb3RlIHRoYXQgaW4gb3JkZXIgdG8gYWNoaWV2ZSBRb1Mg
cm91dGluZyB1c2luZyBmbG9vZGluZywgaXQgb25seQogICAgIGFkZGVkIGJhbmR3aWR0aCBldmFs
dWF0aW9uIHByb2Nlc3MgcHJpb3IgdG8gc2ltcGxlIHNlbGVjdC1hbmQtCiAgICAgYnJvYWRjYXN0
IGFjdGlvbi4gQ29tcGFyZWQgdG8gb3RoZXIgUW9TIHJvdXRpbmcgcHJvcG9zYWxzLCBpdCBkb2Vz
CiAgICAgbm90IHJlcXVpcmUgZW50aXJlIHRvcG9sb2d5IG1hcCwgY29tcGxleCByb3V0ZSBjb21w
dXRhdGlvbiBvcgogICAgIHNvdXJjZSByb3V0aW5nIGNhcGFiaWxpdHkuIFRoZSBzaW1wbGljaXR5
IGlzIGFjaGlldmVkIHRocm91Z2gKICAgICBkaWZmdXNpb24gb2YgY29tcHV0YXRpb24gdG8gZW50
aXJlIG5vZGUgdXNpbmcgZmxvb2RpbmcuCgoKCjUuIERpc2N1c3Npb24gb24gT3ZlcmhlYWQgb2Yg
Rmxvb2RpbmcKCiAgICAgT25lIG9mIGZyZXF1ZW50bHkgcmFpc2VkIHF1ZXN0aW9uIGFib3V0IGZs
b29kIHJvdXRpbmcgaXMKICAgICBzY2FsYWJpbGl0eSBjb25jZXJuaW5nIG51bWJlciBvZiBkdXBs
aWNhdGVzLiBOZXR3b3JrIG5vZGVzIG1heQogICAgIHJlcGVhdCBmbG9vZGluZyB3aGVuIGl0IHJl
Y2VpdmUgQVJQIHJlcXVlc3Qgb2YgbG93ZXIgbWV0cmljIHZhbHVlCiAgICAgdGhhbiBwcmV2aW91
c2x5IHJlY2VpdmVkIG9uZS4gVGhpcyBtYXkgdHJpZ2dlciByZS1mbG9vZGluZyBvZgogICAgIG5l
aWdoYm9yaW5nIG5vZGVzLiBBcyBhIHJlc3VsdCwgdGhlIHdob2xlIG5ldHdvcmsgbWF5IHByb2R1
Y2UKICAgICBjb25zaWRlcmFibGUgYW1vdW50IG9mIGNvbnRyb2wgdHJhZmZpYy4KCiAgICAgV2hl
biBmbG9vZGluZyBtZXNzYWdlcyBwcm9wYWdhdGUsIGR1cGxpY2F0ZXMgb2YgbWVzc2FnZXMgcmFj
ZQogICAgIHRvZ2V0aGVyLCBhbmQgdGhlIHBoZW5vbWVub24gb2YgcmUtZmxvb2RpbmcgaXMgb2Jz
ZXJ2ZWQgc2hvcnRseS4KICAgICBIb3dldmVyIG5ldHdvcmsgbm9kZXMgc29vbiBjb252ZXJnZSB0
byBhIGxvd2VzdCBtZXRyaWMgdmFsdWUgYW5kCiAgICAgdGhlIGZsb29kIG9mIG1lc3NhZ2VzIHN1
YnNpZGVzLiBJbml0aWFsIHNpbXVsYXRpb24gcmVzdWx0IHNob3dzCiAgICAgdGhhdCB1bmRlciBp
ZGVhbCBjb25kaXRpb24sIG1vc3QgbmV0d29yayBub2RlcyBwcm9kdWNlIGR1cGxpY2F0ZXMKICAg
ICBhdCBtb3N0IHR3aWNlIHBlciBzZXNzaW9uLCBhbmQgdGhlIG5ldHdvcmsgaXMgc3RhYmlsaXpl
ZCBpbiBhIGZldwogICAgIHNlY29uZHMuIFRoZXJlZm9yZSwgdGhlIGFjdHVhbCBudW1iZXIgb2Yg
Zmxvb2RpbmcgZnJhbWVzIG9ic2VydmVkCiAgICAgYXQgZWFjaCBsaW5rIHdvdWxkIGJlIG5lZ2xp
Z2libGUgY29uc2lkZXJpbmcgdm9sdW1lIG9mIGRhdGEKICAgICB0cmFmZmljLiBIb3dldmVyIHRo
ZSB3b3JzdC1jYXNlIHBlcmZvcm1hbmNlIGluIHZhcmlvdXMKICAgICBjb25maWd1cmF0aW9ucyBv
ZiBuZXR3b3JrIG5lZWRzIHRvIGJlIGV2YWx1YXRlZCBpbiBmdXR1cmUuCgoKCgpKYWloeXVuZyBD
aG8gICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDIwMDUgICAgICAgICAgICAgICAgICBbUGFn
ZSAxMl0KDAoKSU5URVJORVQtRFJBRlQgICAgICAgICAgQVJQIGZvciBMU1Agc2V0dXAgaW4gRUNQ
TiAgICAgICAgICBGZWJydWFyeSAyMDA1CgoKICAgICBUaGUgb3RoZXIgY29uY2VybiByZWxhdGVz
IHRvIHNjYWxlIG9mIG5ldHdvcmsuIEFSUCBicm9hZGNhc3QgaXMKICAgICBuZXR3b3JrLXdpZGUg
ZXZlbnQuIEFzIHRoZSBzaXplIG9mIG5ldHdvcmsgZ3Jvd3MsIHRoZSBudW1iZXIgb2YgQVJQCiAg
ICAgZnJhbWVzIGlzIGFsc28gaW5jcmVhc2VkLgoKICAgICBJbiBPU1BGIG9yIElTLUlTLCBsYXJn
ZSBuZXR3b3JrIGlzIHN1Yi1kaXZpZGVkIHRvIHNtYWxsIGFyZWFzIGFuZAogICAgIHRoZSBzdWIt
YXJlYXMgYXJlIGxpbmtlZCBieSBiYWNrYm9uZSBuZXR3b3JrLiBJbnRlcm5hbCBicm9hZGNhc3Qg
b2YKICAgICBzdWItYXJlYSBkb2VzIG5vdCBwcm9wYWdhdGUgdG8gb3RoZXIgYXJlYSB1bmxlc3Mg
dGhlIGluZm9ybWF0aW9uIGlzCiAgICAgbWVhbnQgdG8gYmUgZ2xvYmFsLiBTaW1pbGFyIHRlY2hu
aXF1ZSBjYW4gYmUgdXNlZCBpbiBsYXJnZSBmbG9vZAogICAgIHJvdXRpbmcgbmV0d29yay4gQSBu
ZXR3b3JrIGNhbiBiZSBkaXZpZGVkIGFjY29yZGluZyB0byBJUCBzdWJuZXQuCiAgICAgQm9yZGVy
IHN3aXRjaGVzIG9mIHN1Yi1hcmVhIG1heSBmaWx0ZXIgaW50ZXJuYWwgQVJQIG1lc3NhZ2VzIHVz
aW5nCiAgICAgSVAgYWRkcmVzcyBjb250YWluZWQgaW4gdGhlIG1lc3NhZ2UuIFRoaXMgd2lsbCBy
ZWR1Y2UgZ2xvYmFsCiAgICAgYnJvYWRjYXN0IHNpZ25pZmljYW50bHkuIERldGFpbCBvZiBuZXR3
b3JrIHN0cnVjdHVyaW5nIGluIGxhcmdlLQogICAgIHNjYWxlIG5ldHdvcmsgaXMgb3V0IG9mIHNj
b3BlIG9mIHRoaXMgZG9jdW1lbnQuCgogICAgIEluIGNvbmNsdXNpb24sIHRoZSBhbW91bnQgb2Yg
c2lnbmFsaW5nIHRyYWZmaWMgaW4gZmxvb2Qgcm91dGluZwogICAgIGFsZ29yaXRobSBpcyByZWxh
dGl2ZWx5IGdyZWF0ZXIgdGhhbiBvdGhlciBwcm90b2NvbHMuIEhvd2V2ZXIgdGhlCiAgICAgdHJh
ZGVvZmYgYWNoaWV2ZWQgZnJvbSByZWR1bmRhbmN5IG9mIHNpZ25hbCBpcyByb2J1c3RuZXNzLiBO
b3RlCiAgICAgdGhhdCB0aGUgZmxvb2Qgcm91dGluZyBhbGdvcml0aG0gaXMgc28gcG93ZXJmdWwg
dGhhdCBjb25uZWN0aW9uIGNhbgogICAgIGJlIHN1Y2Nlc3NmdWwgZXZlbiB3aGVuIG5ldHdvcmsg
aXMgc2V2ZXJlbHkgZGFtYWdlZC4gQW1vbmcgbWFueQogICAgIGR1cGxpY2F0ZXMgb2YgbWVzc2Fn
ZXMsIGl0IG9ubHkgcmVxdWlyZXMgYXQgbW9zdCBvbmUgbWVzc2FnZQogICAgIHN1cnZpdmVzIGFu
ZCByZWFjaGVzIGRlc3RpbmF0aW9uIHZpYSBhbnkgYXZhaWxhYmxlIHBhdGguIFRoaXMsIGluCiAg
ICAgcGFydGljdWxhciwgaXMgZGVzaXJhYmxlIGZlYXR1cmUgaW4gc29tZSBuZXR3b3JrIHN1Y2gg
YXMgYWQtaG9jIG9yCiAgICAgYXJteSBuZXR3b3JrLiBDb25zaWRlcmluZyBwcm9jZXNzaW5nIHBv
d2VyIG9mIG1vZGVybiBicm9hZGJhbmQKICAgICBzd2l0Y2hlcywgd2UgYmVsaWV2ZSB0aGUgb3Zl
cmhlYWQgb2YgZmxvb2Qgcm91dGluZyBhbGdvcml0aG0gaXMKICAgICBpbnNpZ25pZmljYW50IGlu
IExBTiBlbnZpcm9ubWVudCwgYW5kIGl0IGlzIHdvcnRoIHRvIHRyYWRlIHdpdGgKICAgICBiZW5l
Zml0cyBleHBlY3RlZCBmcm9tIG5ldyByb3V0aW5nIHRlY2hub2xvZ3kuCgoKCjYuIFNlY3VyaXR5
IENvbnNpZGVyYXRpb25zCgoKICAgICBJdCB3YXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24gMi4KCgoK
Ny4gUmVmZXJlbmNlcwoKCiAgICAgIFtSRkMgMjExOV0gIFMuIEJyYWRuZXIsICJLZXkgd29yZHMg
Zm9yIHVzZSBpbiBSRkNzIHRvIGluZGljYXRlCiAgICAgICAgICAgICAgICAgIFJlcXVpcmVtZW50
IExldmVscyIsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgogICAgICBbUkZDODI2XSAgICBEYXZpZCBD
LiBQbHVtbWVyLCAiQW4gRXRoZXJuZXQgQWRkcmVzcyBSZXNvbHV0aW9uCiAgICAgICAgICAgICAg
ICAgIFByb3RvY29sIiwgUkZDODI2LCBOb3ZlbWJlciAxOTgyCiAgICAgIFtSRkMyODE0XSAgIFIu
IFlhdmF0a2FyLCBELiBIb2ZmbWFuLCBZLiBCZXJuZXQsIEYuIEJha2VyLAogICAgICAgICAgICAg
ICAgICBNLiBTcGVlciwgIlNCTSAoU3VibmV0IEJhbmR3aWR0aCBNYW5hZ2VyKTogQSBQcm90b2Nv
bAogICAgICAgICAgICAgICAgICBmb3IgUlNWUC1iYXNlZCBBZG1pc3Npb24gQ29udHJvbCBvdmVy
IElFRUUgODAyLXN0eWxlCiAgICAgICAgICAgICAgICAgIG5ldHdvcmtzIiwgUkZDIDI4MTQsIE1h
eSAyMDAwCiAgICAgIFtSRkMyODE1XSAgIE0uIFNlYW1hbiwgQS4gU21pdGgsIEUuIENyYXdsZXks
IEouIFdyb2NsYXdza2ksCiAgICAgICAgICAgICAgICAgICJJbnRlZ3JhdGVkIFNlcnZpY2UgTWFw
cGluZ3Mgb24gSUVFRSA4MDIgTmV0d29ya3MiLAogICAgICAgICAgICAgICAgICBSRkMgMjgxNSwg
TWF5IDIwMDAKICAgICAgW1JGQzI4MTZdICAgQS4gR2hhbndhbmksIFcuIFBhY2UsIFYuIFNyaW5p
dmFzYW4sIEEuIFNtaXRoLAogICAgICAgICAgICAgICAgICBNLiBTZWFtYW4sICJBIEZyYW1ld29y
ayBmb3IgSW50ZWdyYXRlZCBTZXJ2aWNlcwoKCgoKSmFpaHl1bmcgQ2hvICAgICAgICAgICAgICAg
IEV4cGlyZXMgSnVseSAyMDA1ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKCklOVEVSTkVU
LURSQUZUICAgICAgICAgIEFSUCBmb3IgTFNQIHNldHVwIGluIEVDUE4gICAgICAgICAgRmVicnVh
cnkgMjAwNQoKCiAgICAgICAgICAgICAgICAgIE92ZXIgU2hhcmVkIGFuZCBTd2l0Y2hlZCBJRUVF
IDgwMiBMQU4gVGVjaG5vbG9naWVzIiwKICAgICAgICAgICAgICAgICAgUkZDIDI4MTYsIE1heSAy
MDAwCiAgICAgIFtSRkMyOTk4XSAgIFkuIEJlcm5ldCwgZXQuIGFsLCAiQSBGcmFtZXdvcmsgZm9y
IEludGVncmF0ZWQKICAgICAgICAgICAgICAgICAgU2VydmljZXMgT3BlcmF0aW9uIG92ZXIgRGlm
ZnNlcnYgTmV0d29ya3MiLAogICAgICAgICAgICAgICAgICBSRkMgMjk5OCwgTm92LiAyMDAwCiAg
ICAgIFtMU0VdICAgICAgIEphaWh5dW5nIENobywgIkZyYW1ld29yayBmb3IgKEcpTVBMUyBpbXBs
ZW1lbnRhdGlvbgogICAgICAgICAgICAgICAgICBpbiBFdGhlcm5ldCBiYXNlZCBDdXN0b21lciBQ
cmVtaXNlIE5ldHdvcmsiLAogICAgICAgICAgICAgICAgICBkcmFmdC1qYWloeXVuZy1jY2FtcC1s
c2VmcmFtZXdvcmstMDAudHh0LCBEZWMuIDIwMDQKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgoKSmFpaHl1bmcgQ2hvICAgICAgICAgICAgICAgIEV4cGlyZXMg
SnVseSAyMDA1ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKCklOVEVSTkVULURSQUZUICAg
ICAgICAgIEFSUCBmb3IgTFNQIHNldHVwIGluIEVDUE4gICAgICAgICAgRmVicnVhcnkgMjAwNQoK
CkFwcGVuZGl4IEEgICBFeGFtcGxlIG9mIEFSUCBNZXNzYWdlcyBpbiBGaWd1cmUgMQoKCiAgICAg
Rm9sbG93aW5nIGFic3RyYWN0IG5vdGF0aW9uIHNob3dzIGV4YW1wbGUgb2YgbWVzc2FnZSBmaWVs
ZHMgYXQgZWFjaAogICAgIHN0YWdlIG9mIEFSUCBwcm9jZWR1cmUgZGVzY3JpYmVkIGluIGZpZ3Vy
ZSAxLiBJbiB0aGUgbm90YXRpb24sICd0JywKICAgICAnbicsICdiJyBkZW5vdGUgc29tZSBjb25z
dGFudCB2YWx1ZXMuCgoKICAgICAxKSBUZXJtaW5hbCBFYSAoSVA9MTAuMS4xLjEpIC0tLS0+IFN3
aXRjaCBTMQoKICAgICAgQVJQIHJlcXVlc3QgPSB7CiAgICAgICAgICBNQUMgSGVhZGVyID0geyBE
ZXN0LiBBZGRyID0gYnJvYWRjYXN0IGFkZHJlc3M7CiAgICAgICAgICAgICAgICAgICAgICAgICBT
cmMuICBBZGRyID0gRWE7CiAgICAgICAgICAgICAgICAgICAgICAgICBMZW5ndGgvVHlwZSA9IEFS
UCB0eXBlICg9MHgwODA2KTsKICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICBNZXNz
YWdlIEJvZHkgPSB7IE9QIENvZGUgPSBBUlAgcmVxdWVzdDsKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgU2VuZGVyIEV0aGVybmV0IEFkZHJlc3MgPSBFYTsKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgU2VuZGVyIElQdjQgQWRkcmVzcyA9IDEwLjEuMS4xOwogICAgICAgICAgICAgICAgICAg
ICAgICAgICBUYXJnZXQgRXRoZXJuZXQgQWRkcmVzcyA9CiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB7IFRpbWVzdGFtcCA9IG51bGw7CiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIE1ldHJpYyA9IG51bGw7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIEJhbmR3aWR0aCA9IGI7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9CiAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFRhcmdldCBJUHY0IEFkZHJlc3MgPSAxMC4xLjEuMjsK
ICAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgfQoKICAgICAyKSBTd2l0Y2ggUzEgLS0t
LT4gU3dpdGNoIFMyCgogICAgICBBUlAgcmVxdWVzdCA9IHsKICAgICAgICAgIE1BQyBIZWFkZXIg
PSB7IERlc3QuIEFkZHIgPSBicm9hZGNhc3QgYWRkcmVzczsKICAgICAgICAgICAgICAgICAgICAg
ICAgIFNyYy4gIEFkZHIgPSBtdWx0aWNhc3QgYWRkcmVzczsKICAgICAgICAgICAgICAgICAgICAg
ICAgIExlbmd0aC9UeXBlID0gQVJQIHR5cGUgKD0weDA4MDYpOwogICAgICAgICAgICAgICAgICAg
ICAgIH0KICAgICAgICAgIE1lc3NhZ2UgQm9keSA9IHsgT1AgQ29kZSA9IEFSUCByZXF1ZXN0Owog
ICAgICAgICAgICAgICAgICAgICAgICAgICBTZW5kZXIgRXRoZXJuZXQgQWRkcmVzcyA9IG11bHRp
Y2FzdDsKICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VuZGVyIElQdjQgQWRkcmVzcyA9IDEw
LjEuMS4xOwogICAgICAgICAgICAgICAgICAgICAgICAgICBUYXJnZXQgRXRoZXJuZXQgQWRkcmVz
cyA9CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7IFRpbWVzdGFtcCA9IHQ7CiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1ldHJpYyA9IDE7CiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIEJhbmR3aWR0aCA9IGI7CiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgICAgICAgIFRhcmdldCBJUHY0
IEFkZHJlc3MgPSAxMC4xLjEuMjsKICAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgfQoK
CgoKCgoKCgoKCkphaWh5dW5nIENobyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjAwNSAg
ICAgICAgICAgICAgICAgIFtQYWdlIDE1XQoMCgpJTlRFUk5FVC1EUkFGVCAgICAgICAgICBBUlAg
Zm9yIExTUCBzZXR1cCBpbiBFQ1BOICAgICAgICAgIEZlYnJ1YXJ5IDIwMDUKCgogICAgIDMpIFN3
aXRjaCBTMiAtLS0tPiBUZXJtaW5hbCBFYiAoSVA9MTAuMS4xLjIpCgogICAgICBBUlAgcmVxdWVz
dCA9IHsKICAgICAgICAgIE1BQyBIZWFkZXIgPSB7IERlc3QuIEFkZHIgPSBicm9hZGNhc3QgYWRk
cmVzczsKICAgICAgICAgICAgICAgICAgICAgICAgIFNyYy4gIEFkZHIgPSBtdWx0aWNhc3QgYWRk
cmVzczsKICAgICAgICAgICAgICAgICAgICAgICAgIExlbmd0aC9UeXBlID0gQVJQIHR5cGUgKD0w
eDA4MDYpOwogICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgIE1lc3NhZ2UgQm9keSA9
IHsgT1AgQ29kZSA9IEFSUCByZXF1ZXN0OwogICAgICAgICAgICAgICAgICAgICAgICAgICBTZW5k
ZXIgRXRoZXJuZXQgQWRkcmVzcyA9IG11bHRpY2FzdDsKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgU2VuZGVyIElQdjQgQWRkcmVzcyA9IDEwLjEuMS4xOwogICAgICAgICAgICAgICAgICAgICAg
ICAgICBUYXJnZXQgRXRoZXJuZXQgQWRkcmVzcyA9CiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB7IFRpbWVzdGFtcCA9IHQ7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIE1ldHJpYyA9IG47CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJhbmR3
aWR0aCA9IGI7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFRhcmdldCBJUHY0IEFkZHJlc3MgPSAxMC4xLjEuMjsKICAgICAgICAg
ICAgICAgICAgICAgICAgIH0KICAgICAgfQoKCiAgICAgICBBUlAgcmVxdWVzdCBwcm9jZWR1cmUK
ICAgICAgIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4K
ICAgICAgIEFSUCByZXBseSBwcm9jZWR1cmUKCgogICAgIDQpIFN3aXRjaCBTMiA8LS0tLSBUZXJt
aW5hbCBFYiAoSVA9MTAuMS4xLjIpCgogICAgICBBUlAgcmVwbHkgPSB7CiAgICAgICAgICBNQUMg
SGVhZGVyID0geyBEZXN0LiBBZGRyID0gbXVsdGljYXN0IGFkZHJlc3M7CiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAoJSBpdCBjYW4gYmUgUzIgaWYga25vd24pCiAgICAgICAg
ICAgICAgICAgICAgICAgICBTcmMuICBBZGRyID0gRWI7CiAgICAgICAgICAgICAgICAgICAgICAg
ICBMZW5ndGgvVHlwZSA9IEFSUCB0eXBlICg9MHgwODA2KTsKICAgICAgICAgICAgICAgICAgICAg
ICB9CiAgICAgICAgICBNZXNzYWdlIEJvZHkgPSB7IE9QIENvZGUgPSBBUlAgcmVwbHk7CiAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFNlbmRlciBFdGhlcm5ldCBBZGRyZXNzID0gRWI7CiAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFNlbmRlciBJUHY0IEFkZHJlc3MgPSAxMC4xLjEuMjsKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgVGFyZ2V0IEV0aGVybmV0IEFkZHJlc3MgPSBtdWx0aWNh
c3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICglIG9yIHJlY2VpdmVk
IFRFQSB2YWx1ZSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFyZ2V0IElQdjQgQWRkcmVz
cyA9IDEwLjEuMS4xOwogICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICB9CgoKCgoKCgoK
CgoKCgoKCkphaWh5dW5nIENobyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjAwNSAgICAg
ICAgICAgICAgICAgIFtQYWdlIDE2XQoMCgpJTlRFUk5FVC1EUkFGVCAgICAgICAgICBBUlAgZm9y
IExTUCBzZXR1cCBpbiBFQ1BOICAgICAgICAgIEZlYnJ1YXJ5IDIwMDUKCgogICAgIDUpIFN3aXRj
aCBTMSA8LS0tLSBTd2l0Y2ggUzIgICglIGFsbG9jYXRlICBMYywgTGQpCgogICAgICBBUlAgcmVw
bHkgPSB7CiAgICAgICAgICBNQUMgSGVhZGVyID0geyBEZXN0LiBBZGRyID0gbXVsdGljYXN0IGFk
ZHJlc3M7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoJSBpdCBjYW4gYmUg
UzEgaWYga25vd24pCiAgICAgICAgICAgICAgICAgICAgICAgICBTcmMuICBBZGRyID0gTGM7CiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoJSBpdCBjYW4gYmUgUzIgaWYga25v
d24pCiAgICAgICAgICAgICAgICAgICAgICAgICBMZW5ndGgvVHlwZSA9IEFSUCB0eXBlICg9MHgw
ODA2KTsKICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICBNZXNzYWdlIEJvZHkgPSB7
IE9QIENvZGUgPSBBUlAgcmVwbHk7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlbmRlciBF
dGhlcm5ldCBBZGRyZXNzID0gTGM7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlbmRlciBJ
UHY0IEFkZHJlc3MgPSAxMC4xLjEuMjsKICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFyZ2V0
IEV0aGVybmV0IEFkZHJlc3MgPSAoJSBsYXN0IGhvcCBURUEpCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB7IFRpbWVzdGFtcCA9IHQ7CiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIE1ldHJpYyA9IG47CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IEJhbmR3aWR0aCA9IGI7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFRhcmdldCBJUHY0IEFkZHJlc3MgPSAxMC4xLjEuMTsKICAg
ICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgfQoKCiAgICAgNikgVGVybWluYWwgRWEgIDwt
LS0tIFN3aXRjaCBTMSAgICglIGFsbG9jYXRlIExhLExiKQoKICAgICAgQVJQIHJlcGx5ID0gewog
ICAgICAgICAgTUFDIEhlYWRlciA9IHsgRGVzdC4gQWRkciA9IEVhOwogICAgICAgICAgICAgICAg
ICAgICAgICAgU3JjLiAgQWRkciA9IExhOwogICAgICAgICAgICAgICAgICAgICAgICAgTGVuZ3Ro
L1R5cGUgPSBBUlAgdHlwZSAoPTB4MDgwNik7CiAgICAgICAgICAgICAgICAgICAgICAgfQogICAg
ICAgICAgTWVzc2FnZSBCb2R5ID0geyBPUCBDb2RlID0gQVJQIHJlcGx5OwogICAgICAgICAgICAg
ICAgICAgICAgICAgICBTZW5kZXIgRXRoZXJuZXQgQWRkcmVzcyA9IExhOwogICAgICAgICAgICAg
ICAgICAgICAgICAgICBTZW5kZXIgSVB2NCBBZGRyZXNzID0gMTAuMS4xLjI7CiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFRhcmdldCBFdGhlcm5ldCBBZGRyZXNzID0gRWE7CiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFRhcmdldCBJUHY0IEFkZHJlc3MgPSAxMC4xLjEuMTsKICAgICAgICAg
ICAgICAgICAgICAgICAgIH0KICAgICAgfQoKCgoKCgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICAg
ICAgSmFpaHl1bmcgQ2hvCiAgICAgICBFVFJJCiAgICAgICAxNjEgR2FqZW9uZy1Eb25nLCBZdXNl
b25nLUd1LCBEYWVqZW9uIDMwNS0zNTAsIEtvcmVhCiAgICAgICBQaG9uZTogKzgyIDQyIDg2MCA1
NTE0CiAgICAgICBFbWFpbDogamFpaHl1bmdAZXRyaS5yZS5rcgoKCgoKCgpKYWloeXVuZyBDaG8g
ICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDIwMDUgICAgICAgICAgICAgICAgICBbUGFnZSAx
N10KDAoKSU5URVJORVQtRFJBRlQgICAgICAgICAgQVJQIGZvciBMU1Agc2V0dXAgaW4gRUNQTiAg
ICAgICAgICBGZWJydWFyeSAyMDA1CgoKSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudAoK
ICAgICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9y
IHNjb3BlIG9mIGFueQogICAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIg
cmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZAogICAgIHRvIHBlcnRhaW4gdG8gdGhlIGltcGxl
bWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQKICAgICBpbiB0aGlz
IGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaAog
ICAgIHJpZ2h0cyBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCBy
ZXByZXNlbnQgdGhhdAogICAgIGl0IGhhcyBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8g
aWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLgogICAgIEluZm9ybWF0aW9uIG9uIHRoZSBwcm9jZWR1
cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDCiAgICAgZG9jdW1lbnRzIGNhbiBiZSBm
b3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJl
cyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkKICAgICBhc3N1cmFuY2VzIG9m
IGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuCiAgICAg
YXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZv
ciB0aGUgdXNlCiAgICAgb2Ygc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJz
IG9yIHVzZXJzIG9mIHRoaXMKICAgICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9t
IHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkKICAgICBhdCBodHRwOi8vd3d3LmlldGYu
b3JnL2lwci4KCiAgICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBi
cmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQogICAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0
ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkKICAgICByaWdodHMgdGhhdCBt
YXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQKICAg
ICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJ
RVRGIGF0IGlldGYtCiAgICAgaXByQGlldGYub3JnLgoKCkRpc2NsYWltZXIgb2YgVmFsaWRpdHkK
CiAgICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4g
YXJlIHByb3ZpZGVkIG9uCiAgICAgYW4gIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9S
LCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRQogICAgIFJFUFJFU0VOVFMgT1IgSVMgU1BPTlNPUkVE
IEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQKICAgICBUSEUgSU5URVJORVQg
RU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywKICAgICBFWFBS
RVNTIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZ
IFRIQVQKICAgICBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5G
UklOR0UgQU5ZIFJJR0hUUyBPUgogICAgIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hB
TlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEKICAgICBQQVJUSUNVTEFSIFBVUlBPU0UuCgoKQ29w
eXJpZ2h0IFN0YXRlbWVudAoKICAgICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5
ICgyMDA0KS4gIFRoaXMgZG9jdW1lbnQgaXMKICAgICBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxp
Y2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUAogICAgIDc4LCBhbmQgZXhj
ZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyCiAg
ICAgcmlnaHRzLgoKCgoKCgoKCgoKCgoKSmFpaHl1bmcgQ2hvICAgICAgICAgICAgICAgIEV4cGly
ZXMgSnVseSAyMDA1ICAgICAgICAgICAgICAgICAgW1BhZ2UgMThdCgw=

------=_NextPart_000_DF33_01C50AAA.4D1F9280--



Envelope-to: [e-mail]
Delivery-date: Thu, 03 Feb 2005 23:38:11 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: Shahram Davari <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "Mack-Crane, T. Benjamin" <[e-mail]>, [e-mail], David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Thu, 3 Feb 2005 15:37:19 -0800 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50A49.4D043E42"

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_01C50A49.4D043E42
Content-Type: text/plain;
	charset="iso-8859-1"

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

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


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

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



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

Ethernet networks have 3 main layers: 

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

2) MAC = 802.3

3) Bridging = 802.1D

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

 

  the second is that this configuration operation can be automated - 

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

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

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

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

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

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

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

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

thanks,

- dimitri.


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

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




Dimitri,

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

-Shahram


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



ben, 

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

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

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

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

voila, thanks,

- dimitri.





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

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


Dimitri,

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

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

Regards,
Ben

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


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

------_=_NextPart_001_01C50A49.4D043E42--



Envelope-to: [e-mail]
Delivery-date: Thu, 03 Feb 2005 23:20:10 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "Mack-Crane, T. Benjamin" <[e-mail]>, [e-mail], David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Thu, 3 Feb 2005 15:19:22 -0800 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50A46.CB7273D2"

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_01C50A46.CB7273D2
Content-Type: text/plain;
	charset="iso-8859-1"

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

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



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

Ethernet networks have 3 main layers: 

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

2) MAC = 802.3

3) Bridging = 802.1D

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

 

  the second is that this configuration operation can be automated - 

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

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

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

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

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

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

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

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

thanks,

- dimitri.


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

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




Dimitri,

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

-Shahram


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



ben, 

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

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

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

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

voila, thanks,

- dimitri.





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

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


Dimitri,

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

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

Regards,
Ben

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


------_=_NextPart_001_01C50A46.CB7273D2
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.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=390425022-03022005><FONT face=Arial color=#0000ff size=2>Hi 
Dimitri,</FONT></SPAN></DIV>
<DIV><SPAN class=390425022-03022005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=390425022-03022005><FONT face=Arial color=#0000ff size=2>Thanks 
for your response. Please see my comments in-line.</FONT></SPAN></DIV>
<DIV><SPAN class=390425022-03022005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=390425022-03022005><FONT face=Arial color=#0000ff 
size=2>-Shahram</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> 
  [e-mail] 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, February 
  03, 2005 5:31 PM<BR><B>To:</B> Shahram Davari<BR><B>Cc:</B> 
  '[e-mail]'; Mack-Crane, T. Benjamin; 
  [e-mail]; David Allan; Adrian Farrel; 
  [e-mail]<BR><B>Subject:</B> RE: Layer 2 Switching Caps 
  LSPs<BR><BR></FONT></DIV>
  <P><FONT face=Monospace,Courier>sharam, the first issue is that you have to 
  decouple the notion of ethernet with bridging,<SPAN 
  class=390425022-03022005><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT face=Monospace,Courier><SPAN 
  class=390425022-03022005></SPAN></FONT><FONT face=Monospace,Courier 
  color=#0000ff><SPAN class=390425022-03022005>Ethernet networks have 3 main 
  layers: </SPAN></FONT></P>
  <P><FONT face=Monospace,Courier color=#0000ff><SPAN 
  class=390425022-03022005>1) PHY = 10/100/1G/10G as explained in 802.3, 
  </SPAN></FONT></P>
  <P><FONT face=Monospace,Courier color=#0000ff><SPAN 
  class=390425022-03022005>2) MAC = 802.3</SPAN></FONT></P>
  <P><FONT face=Monospace,Courier color=#0000ff><SPAN 
  class=390425022-03022005>3) Bridging = 802.1D</SPAN></FONT></P>
  <P><FONT face=Monospace,Courier color=#0000ff><SPAN 
  class=390425022-03022005>Without Bridging layer your device can only have a 
  single port. Example is the Ethernet port of your desktop computer. Therefore 
  if you want to build an Ethernet network, you need bridging 
  layer.</SPAN></FONT></P>
  <P><FONT face=Monospace,Courier color=#0000ff><SPAN 
  class=390425022-03022005></SPAN></FONT><FONT face=Monospace,Courier 
  color=#0000ff><SPAN class=390425022-03022005></SPAN></FONT>&nbsp;</P>
  <P><FONT face=Monospace,Courier><SPAN class=390425022-03022005>&nbsp;</SPAN> 
  the second is that this configuration operation can be automated -<SPAN 
  class=390425022-03022005><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT face=Monospace,Courier><SPAN 
  class=390425022-03022005></SPAN></FONT><FONT face=Monospace,Courier 
  color=#0000ff><SPAN class=390425022-03022005>But after you have configured 
  your connections (aka VLAN ports), then there is nothing left for GMPS to do. 
  Or are you saying that the GMPLS will do the configuration?</SPAN></FONT></P>
  <P><FONT face=Monospace,Courier><SPAN class=390425022-03022005>&nbsp;</SPAN> 
  however the interesting point you brought in the loop of discussion here is 
  "applicability for shared medium" - isn't the PW solution in the same 
  context<SPAN class=390425022-03022005><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT face=Monospace,Courier color=#0000ff><SPAN 
  class=390425022-03022005>No, because in PW, the payload (Ethernet) is 
  encapsulated in another layer network (aka MPLS), and is invisible to the 
  intermediate nodes. While in your case there is no encapsulation, and all the 
  intermediate nodes can act on the MAC and VLAN tag.</SPAN></FONT></P>
  <P><FONT face=Monospace,Courier><SPAN class=390425022-03022005>&nbsp;</SPAN> 
  as 1) it can not make an automated usage of a "medium" without configuring the 
  tunnels (in our case the tunnels that will be used to carry the ethernet 
  payload e.g. SDH, OTH, etc. if not using point-to-point PHY's) but in addition 
  to the present solution PW also requires 2) the provisioning of the PW - 
  something not needed in the present context as terminating points will be 
  directly accessing the "ethernet medium", in brief if such argument is used 
  here it should have also been used in the PW context (if not more 
  intensively)</FONT></P>
  <P><FONT face=Monospace,Courier>another fundamental point, i am also surprised 
  seeing people supporting MPLS (which brings a connection-oriented behaviour to 
  IP) wondering about the suitability of using one of the protocol suite of the 
  IETF i.e. GMPLS to bring another (initially) connectionless technology to a 
  "connection-oriented" behaviour<SPAN class=390425022-03022005><FONT face=Arial 
  color=#0000ff size=2>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT face=Monospace,Courier color=#0000ff><SPAN class=390425022-03022005>I 
  don't argue against bringing connection-oriented behavior to Ethernet. My 
  concern is the method used to do so. if you had done proper Network 
  Interworking (aka, encapsulation or as ITU calls it client/server), then there 
  would not be any problem. However, what you are trying to do is to modify 
  Ethernet's control-plane in a way that requires modification to its data-plane 
  behavior. As an analogy what you are doing is&nbsp;like trying to use the IP 
  address as MPLS tag in order to make IP connection-oriented.</SPAN></FONT></P>
  <P><FONT face=Monospace,Courier color=#0000ff><SPAN 
  class=390425022-03022005>In contrast you could easily change ATM's 
  control-plane to GMPLS without any modification to ATM data-plane behavior, 
  because ATM by design is connection-oriented, and the VPI/VCI could easily 
  be&nbsp;interpreted as GMPLS tags.</SPAN></FONT></P>
  <P><FONT face=Monospace,Courier><SPAN class=390425022-03022005>&nbsp;</SPAN> 
  (even if i do rather prefer the term flow, in the present context) at the end 
  the resulting gain is the same for both technologies it terms of capabilities 
  as application of constraint-based routing principles - is this not at the end 
  what drives mostly all debates in the (G)MPLS galaxy beside VPNs and that was 
  underlying incorporation of these L2 technologies as part of the GMPLS 
  protocol architecture</FONT></P>
  <P><FONT face=Monospace,Courier>thanks,</FONT></P>
  <P><FONT face=Monospace,Courier>- dimitri.</FONT></P>
  <P><BR><FONT size=2><B>Shahram Davari 
  &lt;[e-mail]&gt;</B></FONT><BR><FONT size=2>Sent by: 
  [e-mail]</FONT><BR><FONT size=2>02/03/2005 13:13 
  PST</FONT><BR><BR><FONT size=2>To:</FONT> <FONT size=2>Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T. Benjamin" 
  &lt;[e-mail]&gt;</FONT><BR><FONT size=2>cc:</FONT> <FONT 
  size=2>[e-mail], David Allan &lt;[e-mail]&gt;, 
  Adrian Farrel &lt;[e-mail]&gt;, [e-mail]</FONT><BR><FONT 
  size=2>bcc:</FONT> <BR><FONT size=2>Subject:</FONT> <FONT size=2>RE: Layer 2 
  Switching Caps LSPs</FONT><BR><BR><BR></P>
  <P>Dimitri,<BR><BR>Unfortunately I didn't grasp completely what you are trying 
  to convey. But one thing I know for sure, and that is&nbsp; "Ethernet is 
  Connectionless (CLS)" (like IP) and assumes shared medium, while GMPLS is 
  connection-oriented (CO)&nbsp;and doesn't work in shared medium. Off course 
  you could always configure and build an Ethernet network that looks like it is 
  CO (by configuring a max of 2 ports with the same VLAN ID in each bridge), and 
  by not using any shared medium. But then who needs GMPLS, when you already 
  have to configure your network by other 
  means?<BR><BR>-Shahram<BR><BR><BR><B>From:</B> 
  [e-mail] 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, February 
  03, 2005 3:07 PM<BR><B>To:</B> Mack-Crane, T. Benjamin<BR><B>Cc:</B> 
  [e-mail]; [e-mail]; David Allan; Adrian 
  Farrel; Shahram Davari; [e-mail]<BR><B>Subject:</B> RE: Layer 2 
  Switching Caps LSPs<BR><BR><BR><BR><FONT size=4>ben, </FONT><BR><BR><FONT 
  size=4>the discussion with dave has been reproduced in accelerated on the 
  mailing list - for me it appears that the more "philosophical" conclusion can 
  be positioned by answering to the following question "Was SONET/SDH or lambda 
  switching initially intended to be controlled by GMPLS ?" if the response is 
  "No, but nothing prevents to do so" the next question is what does prevent 
  from applying GMPLS to other technologies knowing a substantial gain is 
  obtained from its application - in certain conditions - (see motivations as 
  part of this introduction for instance) ? key issue being which are these 
  (technical) conditions and are there conditions that would preclude 
  progressing this document - the response is simply the negative - there are no 
  such conditions in the point-to-point - non-bridging - context where this 
  document applies. </FONT><BR><BR><FONT size=4>now, not sure there is a 
  technical "firm" conclusion but the point on the ethernet label encoding 
  appears as follows since so far there is potential interest to keep the label 
  for ethernet generic enough and deduce its interpretation from type of link 
  over which the label is used and intepreet its value according to the 
  traffic_parameters and propose associations to cover cases such as case 2 of 
  Appendix A of &lt;draft-pwe3-ethernet-encap-08.txt&gt; mechanisms that is also 
  applicable to other tunneling technology since this mechanism is orthogonal to 
  the use of PW's if required (example being Ethernet over SDH/OTH, for 
  instance); however, if these are the only associations we see relevant as part 
  of this document then we would fall back on the existing encoding with 
  potential enhancement if so required - </FONT><BR><BR><FONT size=4>to come to 
  the point of the articulation the - generic - response holds in one line: it 
  articulates GMPLS signaling for L2SC LSPs (note: the latter has been 
  introduced in RFC 3945, RFC 3471, RFC 3473) - the motivations are detailed as 
  part of the introduction of this document - i can not comment more from your 
  initial statement since not detailed enough for me to be more specific 
  </FONT><BR><BR><FONT size=4>the response to the last question is relatively 
  simple since the above mentioned do not include any specifics concerning ATM 
  or FR - this document intends to close this gap by defining specific 
  Traffic_Parameters for these technologies - is there an interest for doing so: 
  response is yes otherwise the document would not have included the corr. 
  details</FONT><BR><BR><FONT size=4>voila, thanks,</FONT><BR><BR><FONT size=4>- 
  dimitri.</FONT><BR><BR><BR><BR><BR><BR><B>"Mack-Crane, T. Benjamin" 
  &lt;[e-mail]&gt;</B><BR>Sent by: 
  [e-mail]<BR>02/03/2005 12:16 CST<BR><BR>To:<FONT size=4> 
  </FONT>&lt;[e-mail]&gt;, Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" 
  &lt;[e-mail]&gt;<BR>cc:<FONT size=4> </FONT>"Adrian Farrel" 
  &lt;[e-mail]&gt;, "Shahram Davari" 
  &lt;[e-mail]&gt;, &lt;[e-mail]&gt;<BR>bcc:<FONT 
  size=4> </FONT><BR>Subject:<FONT size=4> </FONT>RE: Layer 2 Switching Caps 
  LSPs<BR><BR><BR><FONT size=4>Dimitri,</FONT><BR><BR><FONT size=4>Can the 
  off-line discussion be summarized for the benefit of those on</FONT><BR><FONT 
  size=4>the list who did not participate? &nbsp;For me, the draft (and the 
  current</FONT><BR><FONT size=4>discussion on the list) have not clearly 
  articulated the problem being</FONT><BR><FONT size=4>addressed. &nbsp;If a 
  summary of the conclusions of the off-line discussion</FONT><BR><FONT 
  size=4>will do this, it would be useful.</FONT><BR><BR><FONT size=4>I am also 
  interested to know what is lacking in the current GMPLS RFCs</FONT><BR><FONT 
  size=4>with respect to ATM and Frame Relay support that necessitates 
  including</FONT><BR><FONT size=4>them in this new draft (presumably this is a 
  part of the problem to be</FONT><BR><FONT size=4>solved).</FONT><BR><BR><FONT 
  size=4>Regards,</FONT><BR><FONT size=4>Ben</FONT><BR><BR><FONT size=4>&gt; 
  -----Original Message-----</FONT><BR><FONT size=4>&gt; From: 
  [e-mail] [mailto:[e-mail]] On</FONT><BR><FONT 
  size=4>Behalf</FONT><BR><FONT size=4>&gt; Of dimitri 
  papadimitriou</FONT><BR><FONT size=4>&gt; Sent: Thursday, January 27, 2005 
  6:35 PM</FONT><BR><FONT size=4>&gt; To: David Allan</FONT><BR><FONT 
  size=4>&gt; Cc: 'Adrian Farrel'; 'Shahram Davari'; 
  [e-mail]</FONT><BR><FONT size=4>&gt; Subject: Re: Layer 2 Switching 
  Caps LSPs</FONT><BR><FONT size=4>&gt;</FONT><BR><FONT size=4>&gt; dave - there 
  was a lengthy off-line discussion suggested by the chairs</FONT><BR><FONT 
  size=4>&gt; intended to explain you the scope of the draft and its 
  relatioship</FONT><BR><FONT size=4>with</FONT><BR><FONT size=4>&gt; the 
  ethernet data plane (after the question you raised during the 
  f2f</FONT><BR><FONT size=4>&gt; meeting) - this has been done and we have 
  explained (via a lengthy</FONT><BR><FONT size=4>&gt; exchange of e-mails) that 
  this document and so the use of gmpls to</FONT><BR><FONT size=4>&gt; control 
  ethernet frame flows, is not targeting control of bridged</FONT><BR><FONT 
  size=4>&gt; ethernet environments - if this is not clear from the current 
  document</FONT><BR><FONT size=4>&gt; introduction we would have also to work 
  on this part of the document -</FONT><BR><FONT size=4>&gt; therefore, the 
  below reference to MSTP is not in the current scope; on</FONT><BR><FONT 
  size=4>&gt; the other side, the use of the term "VLAN label" has created 
  some</FONT><BR><FONT size=4>&gt; confusion; therefore, in a next release i 
  will simply refer to a</FONT><BR><FONT size=4>"label"</FONT><BR><FONT 
  size=4>&gt; of 32 bits (unstructured) because the intention was (and still is) 
  to</FONT><BR><FONT size=4>&gt; find an easy way to map the control of the 
  ethernet frame flows on</FONT><BR><FONT size=4>each</FONT><BR><FONT 
  size=4>&gt; device they traverses without making any assumption on how this 
  flow</FONT><BR><FONT size=4>is</FONT><BR><FONT size=4>&gt; processed inside 
  each node at the data plane level (note: on label</FONT><BR><FONT size=4>&gt; 
  values, RFC 3946 took an equivalent approach - for circuits - 
  where</FONT><BR><FONT size=4>&gt; sonet/sdh multiplexing structures have been 
  used to create unique</FONT><BR><FONT size=4>&gt; multiplex entry names i.e. 
  labels - this concept is here applied for</FONT><BR><FONT size=4>&gt; 
  "virtual" circuits), so, if the working group is willing to enter 
  into</FONT><BR><FONT size=4>a</FONT><BR><FONT size=4>&gt; data plane oriented 
  discussion to clarify the behaviour(s) onto which</FONT><BR><FONT size=4>&gt; 
  the present approach would be potentially applicable this is fine 
  with</FONT><BR><FONT size=4>&gt; me as long as we are within the scope of the 
  initial motivations</FONT><BR><FONT size=4>&gt;</FONT><BR><FONT size=4>&gt; 
  thanks,</FONT><BR><FONT size=4>&gt; - dimitri.</FONT><BR><FONT 
  size=4>&gt;</FONT><BR><FONT size=4>&gt; David Allan wrote:</FONT><BR><FONT 
  size=4>&gt; &gt; Hi Adrian:</FONT><BR><FONT size=4>&gt; &gt;</FONT><BR><FONT 
  size=4>&gt; &gt; Your suggestion is in a way reasonable but with the caveat 
  that in</FONT><BR><FONT size=4>IEEE</FONT><BR><FONT size=4>&gt; &gt; terms, a 
  bridging topology is currently all VLANs (802.1Q single</FONT><BR><FONT 
  size=4>&gt; spanning</FONT><BR><FONT size=4>&gt; &gt; tree) or partitioned 
  into specific ranges (I believe 64 in 802.1s</FONT><BR><FONT size=4>&gt; 
  although I</FONT><BR><FONT size=4>&gt; &gt; do not claim to be an 
  expert).</FONT><BR><FONT size=4>&gt; &gt;</FONT><BR><FONT size=4>&gt; &gt; If 
  the PEs were to implement a bridge function and we were using</FONT><BR><FONT 
  size=4>GMPLS</FONT><BR><FONT size=4>&gt; to</FONT><BR><FONT size=4>&gt; &gt; 
  interconnect them, then the control plane should be 
  identifying</FONT><BR><FONT size=4>either</FONT><BR><FONT size=4>&gt; 
  all</FONT><BR><FONT size=4>&gt; &gt; VLANs (single spanning tree, which I 
  beleive the draft covers by</FONT><BR><FONT size=4>&gt; 
  referring</FONT><BR><FONT size=4>&gt; &gt; simply to Ethernet port) or a VLAN 
  range to be associated with the</FONT><BR><FONT size=4>LSP</FONT><BR><FONT 
  size=4>&gt; &gt; consistent with 802.1s if it is to operate to interconnect 
  bridges</FONT><BR><FONT size=4>&gt; defined</FONT><BR><FONT size=4>&gt; &gt; 
  by the IEEE...</FONT><BR><FONT size=4>&gt; &gt;</FONT><BR><FONT size=4>&gt; 
  &gt; I suspect assuming any other behavior (e.g. LSP for single VLAN 
  tag)</FONT><BR><FONT size=4>&gt; would</FONT><BR><FONT size=4>&gt; &gt; go 
  outside the boundary of what is currently defined...so 
  alignment</FONT><BR><FONT size=4>with</FONT><BR><FONT size=4>&gt; &gt; 802.1s 
  IMO would be a minimum requirement if we are to consider</FONT><BR><FONT 
  size=4>carrying</FONT><BR><FONT size=4>&gt; &gt; VLAN information in GMPLS 
  signalling....</FONT><BR><FONT size=4>&gt; &gt;</FONT><BR><FONT size=4>&gt; 
  &gt; cheers</FONT><BR><FONT size=4>&gt; &gt; Dave</FONT><BR><FONT size=4>&gt; 
  &gt;</FONT><BR><FONT size=4>&gt; &gt; You wrote....</FONT><BR><FONT 
  size=4>&gt; &gt;</FONT><BR><FONT size=4>&gt; &gt;&gt;Hi,</FONT><BR><FONT 
  size=4>&gt; &gt;&gt;</FONT><BR><FONT size=4>&gt; &gt;&gt;The authors of the 
  draft might like to clarify for the list</FONT><BR><FONT size=4>&gt; 
  &gt;&gt;exactly what data plane operations they are suggesting. To 
  me</FONT><BR><FONT size=4>&gt; &gt;&gt;it seems possible that the draft is 
  proposing VLAN ID</FONT><BR><FONT size=4>&gt; &gt;&gt;*swapping*. But an 
  alternative is that the VLAN ID is used as</FONT><BR><FONT size=4>&gt; 
  &gt;&gt;a label, but that the same label is used for the full 
  length</FONT><BR><FONT size=4>&gt; &gt;&gt;of the LSP.</FONT><BR><FONT 
  size=4>&gt; &gt;&gt;</FONT><BR><FONT size=4>&gt; 
  &gt;&gt;Adrian</FONT><BR><FONT size=4>&gt; &gt;</FONT><BR><FONT size=4>&gt; 
  &gt;</FONT><BR><FONT size=4>&gt; &gt;</FONT><BR><FONT size=4>&gt; &gt; 
  .</FONT><BR><FONT size=4>&gt; &gt;</FONT><BR><FONT 
  size=4>============================================================</FONT><BR><FONT 
  size=4>The information contained in this message may be 
  privileged</FONT><BR><FONT size=4>and confidential and protected from 
  disclosure. If the reader</FONT><BR><FONT size=4>of this message is not the 
  intended recipient, or an employee</FONT><BR><FONT size=4>or agent responsible 
  for delivering this message to the</FONT><BR><FONT size=4>intended recipient, 
  you are hereby notified that any reproduction,</FONT><BR><FONT 
  size=4>dissemination or distribution of this communication is 
  strictly</FONT><BR><FONT size=4>prohibited. If you have received this 
  communication in error,</FONT><BR><FONT size=4>please notify us immediately by 
  replying to the message and</FONT><BR><FONT size=4>deleting it from your 
  computer. Thank you. Tellabs</FONT><BR><FONT 
  size=4>============================================================</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C50A46.CB7273D2--



Envelope-to: [e-mail]
Delivery-date: Thu, 03 Feb 2005 22:32:13 +0000
To: Shahram Davari <[e-mail]>
Cc: "'[e-mail]'"	 <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>, [e-mail], David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Thu, 3 Feb 2005 23:30:56 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnNoYXJhbSwgdGhlIGZpcnN0IGlzc3Vl
IGlzIHRoYXQgeW91IGhhdmUgdG8gZGVjb3VwbGUgdGhlIG5vdGlvbiBvZiBldGhlcm5ldCB3aXRo
IGJyaWRnaW5nLCB0aGUgc2Vjb25kIGlzIHRoYXQgdGhpcyBjb25maWd1cmF0aW9uIG9wZXJhdGlv
biBjYW4gYmUgYXV0b21hdGVkIC0gaG93ZXZlciB0aGUgaW50ZXJlc3RpbmcgcG9pbnQgeW91IGJy
b3VnaHQgaW4gdGhlIGxvb3Agb2YgZGlzY3Vzc2lvbiBoZXJlIGlzICZxdW90O2FwcGxpY2FiaWxp
dHkgZm9yIHNoYXJlZCBtZWRpdW0mcXVvdDsgLSBpc24ndCB0aGUgUFcgc29sdXRpb24gaW4gdGhl
IHNhbWUgY29udGV4dCBhcyAxKSBpdCBjYW4gbm90IG1ha2UgYW4gYXV0b21hdGVkIHVzYWdlIG9m
IGEgJnF1b3Q7bWVkaXVtJnF1b3Q7IHdpdGhvdXQgY29uZmlndXJpbmcgdGhlIHR1bm5lbHMgKGlu
IG91ciBjYXNlIHRoZSB0dW5uZWxzIHRoYXQgd2lsbCBiZSB1c2VkIHRvIGNhcnJ5IHRoZSBldGhl
cm5ldCBwYXlsb2FkIGUuZy4gU0RILCBPVEgsIGV0Yy4gaWYgbm90IHVzaW5nIHBvaW50LXRvLXBv
aW50IFBIWSdzKSBidXQgaW4gYWRkaXRpb24gdG8gdGhlIHByZXNlbnQgc29sdXRpb24gUFcgYWxz
byByZXF1aXJlcyAyKSB0aGUgcHJvdmlzaW9uaW5nIG9mIHRoZSBQVyAtIHNvbWV0aGluZyBub3Qg
bmVlZGVkIGluIHRoZSBwcmVzZW50IGNvbnRleHQgYXMgdGVybWluYXRpbmcgcG9pbnRzIHdpbGwg
YmUgZGlyZWN0bHkgYWNjZXNzaW5nIHRoZSAmcXVvdDtldGhlcm5ldCBtZWRpdW0mcXVvdDssIGlu
IGJyaWVmIGlmIHN1Y2ggYXJndW1lbnQgaXMgdXNlZCBoZXJlIGl0IHNob3VsZCBoYXZlIGFsc28g
YmVlbiB1c2VkIGluIHRoZSBQVyBjb250ZXh0IChpZiBub3QgbW9yZSBpbnRlbnNpdmVseSk8L0ZP
TlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5hbm90aGVyIGZ1bmRhbWVu
dGFsIHBvaW50LCBpIGFtIGFsc28gc3VycHJpc2VkIHNlZWluZyBwZW9wbGUgc3VwcG9ydGluZyBN
UExTICh3aGljaCBicmluZ3MgYSBjb25uZWN0aW9uLW9yaWVudGVkIGJlaGF2aW91ciB0byBJUCkg
d29uZGVyaW5nIGFib3V0IHRoZSBzdWl0YWJpbGl0eSBvZiB1c2luZyBvbmUgb2YgdGhlIHByb3Rv
Y29sIHN1aXRlIG9mIHRoZSBJRVRGIGkuZS4gR01QTFMgdG8gYnJpbmcgYW5vdGhlciAoaW5pdGlh
bGx5KSBjb25uZWN0aW9ubGVzcyB0ZWNobm9sb2d5IHRvIGEgJnF1b3Q7Y29ubmVjdGlvbi1vcmll
bnRlZCZxdW90OyBiZWhhdmlvdXIgKGV2ZW4gaWYgaSBkbyByYXRoZXIgcHJlZmVyIHRoZSB0ZXJt
IGZsb3csIGluIHRoZSBwcmVzZW50IGNvbnRleHQpIGF0IHRoZSBlbmQgdGhlIHJlc3VsdGluZyBn
YWluIGlzIHRoZSBzYW1lIGZvciBib3RoIHRlY2hub2xvZ2llcyBpdCB0ZXJtcyBvZiBjYXBhYmls
aXRpZXMgYXMgYXBwbGljYXRpb24gb2YgY29uc3RyYWludC1iYXNlZCByb3V0aW5nIHByaW5jaXBs
ZXMgLSBpcyB0aGlzIG5vdCBhdCB0aGUgZW5kIHdoYXQgZHJpdmVzIG1vc3RseSBhbGwgZGViYXRl
cyBpbiB0aGUgKEcpTVBMUyBnYWxheHkgYmVzaWRlIFZQTnMgYW5kIHRoYXQgd2FzIHVuZGVybHlp
bmcgaW5jb3Jwb3JhdGlvbiBvZiB0aGVzZSBMMiB0ZWNobm9sb2dpZXMgYXMgcGFydCBvZiB0aGUg
R01QTFMgcHJvdG9jb2wgYXJjaGl0ZWN0dXJlPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25v
c3BhY2UsQ291cmllciI+dGhhbmtzLDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNl
LENvdXJpZXIiPi0gZGltaXRyaS48L0ZPTlQ+PC9QPjxQPjxCUj48Rk9OVCBTSVpFPTI+PEI+U2hh
aHJhbSBEYXZhcmkgJmx0O1NoYWhyYW1fRGF2YXJpQHBtYy1zaWVycmEuY29tJmd0OzwvQj48L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9Mj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9Mj4wMi8wMy8yMDA1IDEzOjEzIFBTVDwvRk9OVD48QlI+PEJSPiA8
Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+RGltaXRyaSBQQVBBRElNSVRSSU9V
L0JFL0FMQ0FURUxAQUxDQVRFTCwgJnF1b3Q7TWFjay1DcmFuZSwgVC4gQmVuamFtaW4mcXVvdDsg
Jmx0O0Jlbi5NYWNrLUNyYW5lQHRlbGxhYnMuY29tJmd0OzwvRk9OVD48QlI+IDxGT05UIFNJWkU9
Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5kcGFwYWRpbWl0cmlvdUBwc2cuY29tLCBEYXZpZCBB
bGxhbiAmbHQ7ZGFsbGFuQG5vcnRlbG5ldHdvcmtzLmNvbSZndDssIEFkcmlhbiBGYXJyZWwgJmx0
O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7LCBjY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPiA8
Rk9OVCBTSVpFPTI+YmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+
IDxGT05UIFNJWkU9Mj5SRTogTGF5ZXIgMiBTd2l0Y2hpbmcgQ2FwcyBMU1BzPC9GT05UPjxCUj4g
PEJSPjxCUj48L1A+PFA+RGltaXRyaSw8QlI+PEJSPlVuZm9ydHVuYXRlbHkgSSBkaWRuJ3QgZ3Jh
c3AgY29tcGxldGVseSB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGNvbnZleS4gQnV0IG9uZSB0aGlu
ZyBJIGtub3cgZm9yIHN1cmUsIGFuZCB0aGF0IGlzJm5ic3A7ICZxdW90O0V0aGVybmV0IGlzIENv
bm5lY3Rpb25sZXNzIChDTFMpJnF1b3Q7IChsaWtlIElQKSBhbmQgYXNzdW1lcyBzaGFyZWQgbWVk
aXVtLCB3aGlsZSBHTVBMUyBpcyBjb25uZWN0aW9uLW9yaWVudGVkIChDTykmbmJzcDthbmQgZG9l
c24ndCB3b3JrIGluIHNoYXJlZCBtZWRpdW0uIE9mZiBjb3Vyc2UgeW91IGNvdWxkIGFsd2F5cyBj
b25maWd1cmUgYW5kIGJ1aWxkIGFuIEV0aGVybmV0IG5ldHdvcmsgdGhhdCBsb29rcyBsaWtlIGl0
IGlzIENPIChieSBjb25maWd1cmluZyBhIG1heCBvZiAyIHBvcnRzIHdpdGggdGhlIHNhbWUgVkxB
TiBJRCBpbiBlYWNoIGJyaWRnZSksIGFuZCBieSBub3QgdXNpbmcgYW55IHNoYXJlZCBtZWRpdW0u
IEJ1dCB0aGVuIHdobyBuZWVkcyBHTVBMUywgd2hlbiB5b3UgYWxyZWFkeSBoYXZlIHRvIGNvbmZp
Z3VyZSB5b3VyIG5ldHdvcmsgYnkgb3RoZXIgbWVhbnM/PEJSPjxCUj4tU2hhaHJhbTxCUj48QlI+
PEJSPjxCPkZyb206PC9CPiBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZSBbbWFpbHRv
OkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlXTxCUj48Qj5TZW50OjwvQj4gVGh1cnNk
YXksIEZlYnJ1YXJ5IDAzLCAyMDA1IDM6MDcgUE08QlI+PEI+VG86PC9CPiBNYWNrLUNyYW5lLCBU
LiBCZW5qYW1pbjxCUj48Qj5DYzo8L0I+IGRwYXBhZGltaXRyaW91QHBzZy5jb207IGRpbWl0cmku
cGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlOyBEYXZpZCBBbGxhbjsgQWRyaWFuIEZhcnJlbDsgU2hh
aHJhbSBEYXZhcmk7IGNjYW1wQG9wcy5pZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gUkU6IExh
eWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQczxCUj48QlI+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+YmVu
LCA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+dGhlIGRpc2N1c3Npb24gd2l0aCBkYXZlIGhh
cyBiZWVuIHJlcHJvZHVjZWQgaW4gYWNjZWxlcmF0ZWQgb24gdGhlIG1haWxpbmcgbGlzdCAtIGZv
ciBtZSBpdCBhcHBlYXJzIHRoYXQgdGhlIG1vcmUgJnF1b3Q7cGhpbG9zb3BoaWNhbCZxdW90OyBj
b25jbHVzaW9uIGNhbiBiZSBwb3NpdGlvbmVkIGJ5IGFuc3dlcmluZyB0byB0aGUgZm9sbG93aW5n
IHF1ZXN0aW9uICZxdW90O1dhcyBTT05FVC9TREggb3IgbGFtYmRhIHN3aXRjaGluZyBpbml0aWFs
bHkgaW50ZW5kZWQgdG8gYmUgY29udHJvbGxlZCBieSBHTVBMUyA/JnF1b3Q7IGlmIHRoZSByZXNw
b25zZSBpcyAmcXVvdDtObywgYnV0IG5vdGhpbmcgcHJldmVudHMgdG8gZG8gc28mcXVvdDsgdGhl
IG5leHQgcXVlc3Rpb24gaXMgd2hhdCBkb2VzIHByZXZlbnQgZnJvbSBhcHBseWluZyBHTVBMUyB0
byBvdGhlciB0ZWNobm9sb2dpZXMga25vd2luZyBhIHN1YnN0YW50aWFsIGdhaW4gaXMgb2J0YWlu
ZWQgZnJvbSBpdHMgYXBwbGljYXRpb24gLSBpbiBjZXJ0YWluIGNvbmRpdGlvbnMgLSAoc2VlIG1v
dGl2YXRpb25zIGFzIHBhcnQgb2YgdGhpcyBpbnRyb2R1Y3Rpb24gZm9yIGluc3RhbmNlKSA/IGtl
eSBpc3N1ZSBiZWluZyB3aGljaCBhcmUgdGhlc2UgKHRlY2huaWNhbCkgY29uZGl0aW9ucyBhbmQg
YXJlIHRoZXJlIGNvbmRpdGlvbnMgdGhhdCB3b3VsZCBwcmVjbHVkZSBwcm9ncmVzc2luZyB0aGlz
IGRvY3VtZW50IC0gdGhlIHJlc3BvbnNlIGlzIHNpbXBseSB0aGUgbmVnYXRpdmUgLSB0aGVyZSBh
cmUgbm8gc3VjaCBjb25kaXRpb25zIGluIHRoZSBwb2ludC10by1wb2ludCAtIG5vbi1icmlkZ2lu
ZyAtIGNvbnRleHQgd2hlcmUgdGhpcyBkb2N1bWVudCBhcHBsaWVzLiA8L0ZPTlQ+PEJSPjxCUj48
Rk9OVCBTSVpFPTQ+bm93LCBub3Qgc3VyZSB0aGVyZSBpcyBhIHRlY2huaWNhbCAmcXVvdDtmaXJt
JnF1b3Q7IGNvbmNsdXNpb24gYnV0IHRoZSBwb2ludCBvbiB0aGUgZXRoZXJuZXQgbGFiZWwgZW5j
b2RpbmcgYXBwZWFycyBhcyBmb2xsb3dzIHNpbmNlIHNvIGZhciB0aGVyZSBpcyBwb3RlbnRpYWwg
aW50ZXJlc3QgdG8ga2VlcCB0aGUgbGFiZWwgZm9yIGV0aGVybmV0IGdlbmVyaWMgZW5vdWdoIGFu
ZCBkZWR1Y2UgaXRzIGludGVycHJldGF0aW9uIGZyb20gdHlwZSBvZiBsaW5rIG92ZXIgd2hpY2gg
dGhlIGxhYmVsIGlzIHVzZWQgYW5kIGludGVwcmVldCBpdHMgdmFsdWUgYWNjb3JkaW5nIHRvIHRo
ZSB0cmFmZmljX3BhcmFtZXRlcnMgYW5kIHByb3Bvc2UgYXNzb2NpYXRpb25zIHRvIGNvdmVyIGNh
c2VzIHN1Y2ggYXMgY2FzZSAyIG9mIEFwcGVuZGl4IEEgb2YgJmx0O2RyYWZ0LXB3ZTMtZXRoZXJu
ZXQtZW5jYXAtMDgudHh0Jmd0OyBtZWNoYW5pc21zIHRoYXQgaXMgYWxzbyBhcHBsaWNhYmxlIHRv
IG90aGVyIHR1bm5lbGluZyB0ZWNobm9sb2d5IHNpbmNlIHRoaXMgbWVjaGFuaXNtIGlzIG9ydGhv
Z29uYWwgdG8gdGhlIHVzZSBvZiBQVydzIGlmIHJlcXVpcmVkIChleGFtcGxlIGJlaW5nIEV0aGVy
bmV0IG92ZXIgU0RIL09USCwgZm9yIGluc3RhbmNlKTsgaG93ZXZlciwgaWYgdGhlc2UgYXJlIHRo
ZSBvbmx5IGFzc29jaWF0aW9ucyB3ZSBzZWUgcmVsZXZhbnQgYXMgcGFydCBvZiB0aGlzIGRvY3Vt
ZW50IHRoZW4gd2Ugd291bGQgZmFsbCBiYWNrIG9uIHRoZSBleGlzdGluZyBlbmNvZGluZyB3aXRo
IHBvdGVudGlhbCBlbmhhbmNlbWVudCBpZiBzbyByZXF1aXJlZCAtIDwvRk9OVD48QlI+PEJSPjxG
T05UIFNJWkU9ND50byBjb21lIHRvIHRoZSBwb2ludCBvZiB0aGUgYXJ0aWN1bGF0aW9uIHRoZSAt
IGdlbmVyaWMgLSByZXNwb25zZSBob2xkcyBpbiBvbmUgbGluZTogaXQgYXJ0aWN1bGF0ZXMgR01Q
TFMgc2lnbmFsaW5nIGZvciBMMlNDIExTUHMgKG5vdGU6IHRoZSBsYXR0ZXIgaGFzIGJlZW4gaW50
cm9kdWNlZCBpbiBSRkMgMzk0NSwgUkZDIDM0NzEsIFJGQyAzNDczKSAtIHRoZSBtb3RpdmF0aW9u
cyBhcmUgZGV0YWlsZWQgYXMgcGFydCBvZiB0aGUgaW50cm9kdWN0aW9uIG9mIHRoaXMgZG9jdW1l
bnQgLSBpIGNhbiBub3QgY29tbWVudCBtb3JlIGZyb20geW91ciBpbml0aWFsIHN0YXRlbWVudCBz
aW5jZSBub3QgZGV0YWlsZWQgZW5vdWdoIGZvciBtZSB0byBiZSBtb3JlIHNwZWNpZmljIDwvRk9O
VD48QlI+PEJSPjxGT05UIFNJWkU9ND50aGUgcmVzcG9uc2UgdG8gdGhlIGxhc3QgcXVlc3Rpb24g
aXMgcmVsYXRpdmVseSBzaW1wbGUgc2luY2UgdGhlIGFib3ZlIG1lbnRpb25lZCBkbyBub3QgaW5j
bHVkZSBhbnkgc3BlY2lmaWNzIGNvbmNlcm5pbmcgQVRNIG9yIEZSIC0gdGhpcyBkb2N1bWVudCBp
bnRlbmRzIHRvIGNsb3NlIHRoaXMgZ2FwIGJ5IGRlZmluaW5nIHNwZWNpZmljIFRyYWZmaWNfUGFy
YW1ldGVycyBmb3IgdGhlc2UgdGVjaG5vbG9naWVzIC0gaXMgdGhlcmUgYW4gaW50ZXJlc3QgZm9y
IGRvaW5nIHNvOiByZXNwb25zZSBpcyB5ZXMgb3RoZXJ3aXNlIHRoZSBkb2N1bWVudCB3b3VsZCBu
b3QgaGF2ZSBpbmNsdWRlZCB0aGUgY29yci4gZGV0YWlsczwvRk9OVD48QlI+PEJSPjxGT05UIFNJ
WkU9ND52b2lsYSwgdGhhbmtzLDwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND4tIGRpbWl0cmku
PC9GT05UPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCPiZxdW90O01hY2stQ3JhbmUsIFQuIEJl
bmphbWluJnF1b3Q7ICZsdDtCZW4uTWFjay1DcmFuZUB0ZWxsYWJzLmNvbSZndDs8L0I+PEJSPlNl
bnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzxCUj4wMi8wMy8yMDA1IDEyOjE2IENTVDxC
Uj48QlI+VG86PEZPTlQgU0laRT00PiA8L0ZPTlQ+Jmx0O2RwYXBhZGltaXRyaW91QHBzZy5jb20m
Z3Q7LCBEaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMLCAmcXVvdDtEYXZp
ZCBBbGxhbiZxdW90OyAmbHQ7ZGFsbGFuQG5vcnRlbG5ldHdvcmtzLmNvbSZndDs8QlI+Y2M6PEZP
TlQgU0laRT00PiA8L0ZPTlQ+JnF1b3Q7QWRyaWFuIEZhcnJlbCZxdW90OyAmbHQ7YWRyaWFuQG9s
ZGRvZy5jby51ayZndDssICZxdW90O1NoYWhyYW0gRGF2YXJpJnF1b3Q7ICZsdDtTaGFocmFtX0Rh
dmFyaUBwbWMtc2llcnJhLmNvbSZndDssICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PEJSPmJj
Yzo8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+U3ViamVjdDo8Rk9OVCBTSVpFPTQ+IDwvRk9OVD5S
RTogTGF5ZXIgMiBTd2l0Y2hpbmcgQ2FwcyBMU1BzPEJSPjxCUj48QlI+PEZPTlQgU0laRT00PkRp
bWl0cmksPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PkNhbiB0aGUgb2ZmLWxpbmUgZGlzY3Vz
c2lvbiBiZSBzdW1tYXJpemVkIGZvciB0aGUgYmVuZWZpdCBvZiB0aG9zZSBvbjwvRk9OVD48QlI+
PEZPTlQgU0laRT00PnRoZSBsaXN0IHdobyBkaWQgbm90IHBhcnRpY2lwYXRlPyAmbmJzcDtGb3Ig
bWUsIHRoZSBkcmFmdCAoYW5kIHRoZSBjdXJyZW50PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+ZGlz
Y3Vzc2lvbiBvbiB0aGUgbGlzdCkgaGF2ZSBub3QgY2xlYXJseSBhcnRpY3VsYXRlZCB0aGUgcHJv
YmxlbSBiZWluZzwvRk9OVD48QlI+PEZPTlQgU0laRT00PmFkZHJlc3NlZC4gJm5ic3A7SWYgYSBz
dW1tYXJ5IG9mIHRoZSBjb25jbHVzaW9ucyBvZiB0aGUgb2ZmLWxpbmUgZGlzY3Vzc2lvbjwvRk9O
VD48QlI+PEZPTlQgU0laRT00PndpbGwgZG8gdGhpcywgaXQgd291bGQgYmUgdXNlZnVsLjwvRk9O
VD48QlI+PEJSPjxGT05UIFNJWkU9ND5JIGFtIGFsc28gaW50ZXJlc3RlZCB0byBrbm93IHdoYXQg
aXMgbGFja2luZyBpbiB0aGUgY3VycmVudCBHTVBMUyBSRkNzPC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQ+d2l0aCByZXNwZWN0IHRvIEFUTSBhbmQgRnJhbWUgUmVsYXkgc3VwcG9ydCB0aGF0IG5lY2Vz
c2l0YXRlcyBpbmNsdWRpbmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND50aGVtIGluIHRoaXMgbmV3
IGRyYWZ0IChwcmVzdW1hYmx5IHRoaXMgaXMgYSBwYXJ0IG9mIHRoZSBwcm9ibGVtIHRvIGJlPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+c29sdmVkKS48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+
UmVnYXJkcyw8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5CZW48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD48QlI+PEZPTlQgU0la
RT00PiZndDsgRnJvbTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItY2Nh
bXBAb3BzLmlldGYub3JnXSBPbjwvRk9OVD48QlI+PEZPTlQgU0laRT00PkJlaGFsZjwvRk9OVD48
QlI+PEZPTlQgU0laRT00PiZndDsgT2YgZGltaXRyaSBwYXBhZGltaXRyaW91PC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyNywgMjAwNSA2OjM1IFBN
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBUbzogRGF2aWQgQWxsYW48L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mZ3Q7IENjOiAnQWRyaWFuIEZhcnJlbCc7ICdTaGFocmFtIERhdmFyaSc7IGNj
YW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgU3ViamVjdDogUmU6
IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQczwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDs8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IGRhdmUgLSB0aGVyZSB3YXMgYSBsZW5ndGh5IG9m
Zi1saW5lIGRpc2N1c3Npb24gc3VnZ2VzdGVkIGJ5IHRoZSBjaGFpcnM8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7IGludGVuZGVkIHRvIGV4cGxhaW4geW91IHRoZSBzY29wZSBvZiB0aGUgZHJh
ZnQgYW5kIGl0cyByZWxhdGlvc2hpcDwvRk9OVD48QlI+PEZPTlQgU0laRT00PndpdGg8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IHRoZSBldGhlcm5ldCBkYXRhIHBsYW5lIChhZnRlciB0aGUg
cXVlc3Rpb24geW91IHJhaXNlZCBkdXJpbmcgdGhlIGYyZjwvRk9OVD48QlI+PEZPTlQgU0laRT00
PiZndDsgbWVldGluZykgLSB0aGlzIGhhcyBiZWVuIGRvbmUgYW5kIHdlIGhhdmUgZXhwbGFpbmVk
ICh2aWEgYSBsZW5ndGh5PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBleGNoYW5nZSBvZiBl
LW1haWxzKSB0aGF0IHRoaXMgZG9jdW1lbnQgYW5kIHNvIHRoZSB1c2Ugb2YgZ21wbHMgdG88L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IGNvbnRyb2wgZXRoZXJuZXQgZnJhbWUgZmxvd3MsIGlz
IG5vdCB0YXJnZXRpbmcgY29udHJvbCBvZiBicmlkZ2VkPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyBldGhlcm5ldCBlbnZpcm9ubWVudHMgLSBpZiB0aGlzIGlzIG5vdCBjbGVhciBmcm9tIHRo
ZSBjdXJyZW50IGRvY3VtZW50PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBpbnRyb2R1Y3Rp
b24gd2Ugd291bGQgaGF2ZSBhbHNvIHRvIHdvcmsgb24gdGhpcyBwYXJ0IG9mIHRoZSBkb2N1bWVu
dCAtPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyB0aGVyZWZvcmUsIHRoZSBiZWxvdyByZWZl
cmVuY2UgdG8gTVNUUCBpcyBub3QgaW4gdGhlIGN1cnJlbnQgc2NvcGU7IG9uPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyB0aGUgb3RoZXIgc2lkZSwgdGhlIHVzZSBvZiB0aGUgdGVybSAmcXVv
dDtWTEFOIGxhYmVsJnF1b3Q7IGhhcyBjcmVhdGVkIHNvbWU8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7IGNvbmZ1c2lvbjsgdGhlcmVmb3JlLCBpbiBhIG5leHQgcmVsZWFzZSBpIHdpbGwgc2lt
cGx5IHJlZmVyIHRvIGE8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mcXVvdDtsYWJlbCZxdW90Ozwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgb2YgMzIgYml0cyAodW5zdHJ1Y3R1cmVkKSBiZWNh
dXNlIHRoZSBpbnRlbnRpb24gd2FzIChhbmQgc3RpbGwgaXMpIHRvPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyBmaW5kIGFuIGVhc3kgd2F5IHRvIG1hcCB0aGUgY29udHJvbCBvZiB0aGUgZXRo
ZXJuZXQgZnJhbWUgZmxvd3Mgb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5lYWNoPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTQ+Jmd0OyBkZXZpY2UgdGhleSB0cmF2ZXJzZXMgd2l0aG91dCBtYWtpbmcg
YW55IGFzc3VtcHRpb24gb24gaG93IHRoaXMgZmxvdzwvRk9OVD48QlI+PEZPTlQgU0laRT00Pmlz
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBwcm9jZXNzZWQgaW5zaWRlIGVhY2ggbm9kZSBh
dCB0aGUgZGF0YSBwbGFuZSBsZXZlbCAobm90ZTogb24gbGFiZWw8L0ZPTlQ+PEJSPjxGT05UIFNJ
WkU9ND4mZ3Q7IHZhbHVlcywgUkZDIDM5NDYgdG9vayBhbiBlcXVpdmFsZW50IGFwcHJvYWNoIC0g
Zm9yIGNpcmN1aXRzIC0gd2hlcmU8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IHNvbmV0L3Nk
aCBtdWx0aXBsZXhpbmcgc3RydWN0dXJlcyBoYXZlIGJlZW4gdXNlZCB0byBjcmVhdGUgdW5pcXVl
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBtdWx0aXBsZXggZW50cnkgbmFtZXMgaS5lLiBs
YWJlbHMgLSB0aGlzIGNvbmNlcHQgaXMgaGVyZSBhcHBsaWVkIGZvcjwvRk9OVD48QlI+PEZPTlQg
U0laRT00PiZndDsgJnF1b3Q7dmlydHVhbCZxdW90OyBjaXJjdWl0cyksIHNvLCBpZiB0aGUgd29y
a2luZyBncm91cCBpcyB3aWxsaW5nIHRvIGVudGVyIGludG88L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND5hPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBkYXRhIHBsYW5lIG9yaWVudGVkIGRpc2N1
c3Npb24gdG8gY2xhcmlmeSB0aGUgYmVoYXZpb3VyKHMpIG9udG8gd2hpY2g8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mZ3Q7IHRoZSBwcmVzZW50IGFwcHJvYWNoIHdvdWxkIGJlIHBvdGVudGlhbGx5
IGFwcGxpY2FibGUgdGhpcyBpcyBmaW5lIHdpdGg8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7
IG1lIGFzIGxvbmcgYXMgd2UgYXJlIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIGluaXRpYWwgbW90
aXZhdGlvbnM8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQ+Jmd0OyB0aGFua3MsPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAtIGRpbWl0cmkuPC9G
T05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgRGF2
aWQgQWxsYW4gd3JvdGU6PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IEhpIEFkcmlh
bjo8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND4mZ3Q7ICZndDsgWW91ciBzdWdnZXN0aW9uIGlzIGluIGEgd2F5IHJlYXNvbmFibGUgYnV0IHdp
dGggdGhlIGNhdmVhdCB0aGF0IGluPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+SUVFRTwvRk9OVD48
QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyB0ZXJtcywgYSBicmlkZ2luZyB0b3BvbG9neSBpcyBj
dXJyZW50bHkgYWxsIFZMQU5zICg4MDIuMVEgc2luZ2xlPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyBzcGFubmluZzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyB0cmVlKSBvciBw
YXJ0aXRpb25lZCBpbnRvIHNwZWNpZmljIHJhbmdlcyAoSSBiZWxpZXZlIDY0IGluIDgwMi4xczwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgYWx0aG91Z2ggSTwvRk9OVD48QlI+PEZPTlQgU0la
RT00PiZndDsgJmd0OyBkbyBub3QgY2xhaW0gdG8gYmUgYW4gZXhwZXJ0KS48L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mZ3Q7ICZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgSWYg
dGhlIFBFcyB3ZXJlIHRvIGltcGxlbWVudCBhIGJyaWRnZSBmdW5jdGlvbiBhbmQgd2Ugd2VyZSB1
c2luZzwvRk9OVD48QlI+PEZPTlQgU0laRT00PkdNUExTPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+
Jmd0OyB0bzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBpbnRlcmNvbm5lY3QgdGhl
bSwgdGhlbiB0aGUgY29udHJvbCBwbGFuZSBzaG91bGQgYmUgaWRlbnRpZnlpbmc8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND5laXRoZXI8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IGFsbDwvRk9O
VD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBWTEFOcyAoc2luZ2xlIHNwYW5uaW5nIHRyZWUs
IHdoaWNoIEkgYmVsZWl2ZSB0aGUgZHJhZnQgY292ZXJzIGJ5PC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQ+Jmd0OyByZWZlcnJpbmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgc2ltcGx5
IHRvIEV0aGVybmV0IHBvcnQpIG9yIGEgVkxBTiByYW5nZSB0byBiZSBhc3NvY2lhdGVkIHdpdGgg
dGhlPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+TFNQPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyAmZ3Q7IGNvbnNpc3RlbnQgd2l0aCA4MDIuMXMgaWYgaXQgaXMgdG8gb3BlcmF0ZSB0byBpbnRl
cmNvbm5lY3QgYnJpZGdlczwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgZGVmaW5lZDwvRk9O
VD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBieSB0aGUgSUVFRS4uLjwvRk9OVD48QlI+PEZP
TlQgU0laRT00PiZndDsgJmd0OzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBJIHN1
c3BlY3QgYXNzdW1pbmcgYW55IG90aGVyIGJlaGF2aW9yIChlLmcuIExTUCBmb3Igc2luZ2xlIFZM
QU4gdGFnKTwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgd291bGQ8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7ICZndDsgZ28gb3V0c2lkZSB0aGUgYm91bmRhcnkgb2Ygd2hhdCBpcyBjdXJy
ZW50bHkgZGVmaW5lZC4uLnNvIGFsaWdubWVudDwvRk9OVD48QlI+PEZPTlQgU0laRT00PndpdGg8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgODAyLjFzIElNTyB3b3VsZCBiZSBhIG1p
bmltdW0gcmVxdWlyZW1lbnQgaWYgd2UgYXJlIHRvIGNvbnNpZGVyPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Y2Fycnlpbmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgVkxBTiBpbmZv
cm1hdGlvbiBpbiBHTVBMUyBzaWduYWxsaW5nLi4uLjwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZn
dDsgJmd0OzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBjaGVlcnM8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsgRGF2ZTwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsg
Jmd0OzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyBZb3Ugd3JvdGUuLi4uPC9GT05U
PjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAm
Z3Q7Jmd0O0hpLDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDs8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7VGhlIGF1dGhvcnMgb2YgdGhlIGRyYWZ0IG1pZ2h0
IGxpa2UgdG8gY2xhcmlmeSBmb3IgdGhlIGxpc3Q8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7
ICZndDsmZ3Q7ZXhhY3RseSB3aGF0IGRhdGEgcGxhbmUgb3BlcmF0aW9ucyB0aGV5IGFyZSBzdWdn
ZXN0aW5nLiBUbyBtZTwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDtpdCBzZWVt
cyBwb3NzaWJsZSB0aGF0IHRoZSBkcmFmdCBpcyBwcm9wb3NpbmcgVkxBTiBJRDwvRk9OVD48QlI+
PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDsqc3dhcHBpbmcqLiBCdXQgYW4gYWx0ZXJuYXRpdmUg
aXMgdGhhdCB0aGUgVkxBTiBJRCBpcyB1c2VkIGFzPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0
OyAmZ3Q7Jmd0O2EgbGFiZWwsIGJ1dCB0aGF0IHRoZSBzYW1lIGxhYmVsIGlzIHVzZWQgZm9yIHRo
ZSBmdWxsIGxlbmd0aDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDtvZiB0aGUg
TFNQLjwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgJmd0OyZndDs8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7ICZndDsmZ3Q7QWRyaWFuPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAm
Z3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpF
PTQ+Jmd0OyAmZ3Q7PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyAmZ3Q7IC48L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND4mZ3Q7ICZndDs8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND49PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2Fn
ZSBtYXkgYmUgcHJpdmlsZWdlZDwvRk9OVD48QlI+PEZPTlQgU0laRT00PmFuZCBjb25maWRlbnRp
YWwgYW5kIHByb3RlY3RlZCBmcm9tIGRpc2Nsb3N1cmUuIElmIHRoZSByZWFkZXI8L0ZPTlQ+PEJS
PjxGT05UIFNJWkU9ND5vZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll
bnQsIG9yIGFuIGVtcGxveWVlPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+b3IgYWdlbnQgcmVzcG9u
c2libGUgZm9yIGRlbGl2ZXJpbmcgdGhpcyBtZXNzYWdlIHRvIHRoZTwvRk9OVD48QlI+PEZPTlQg
U0laRT00PmludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBh
bnkgcmVwcm9kdWN0aW9uLDwvRk9OVD48QlI+PEZPTlQgU0laRT00PmRpc3NlbWluYXRpb24gb3Ig
ZGlzdHJpYnV0aW9uIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseTwvRk9OVD48QlI+
PEZPTlQgU0laRT00PnByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVu
aWNhdGlvbiBpbiBlcnJvciw8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5wbGVhc2Ugbm90aWZ5IHVz
IGltbWVkaWF0ZWx5IGJ5IHJlcGx5aW5nIHRvIHRoZSBtZXNzYWdlIGFuZDwvRk9OVD48QlI+PEZP
TlQgU0laRT00PmRlbGV0aW5nIGl0IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91LiBUZWxs
YWJzPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9GT05UPjwvUD4=



Envelope-to: [e-mail]
Delivery-date: Thu, 03 Feb 2005 21:14:34 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Mack-Crane, T. Benjamin" <[e-mail]>
Cc: [e-mail], David Allan <[e-mail]>, Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Thu, 3 Feb 2005 13:13:23 -0800 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50A35.3193FCF6"

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_01C50A35.3193FCF6
Content-Type: text/plain;
	charset="iso-8859-1"

Dimitri,
 
Unfortunately I didn't grasp completely what you are trying to convey. But one thing I know for sure, and that is  "Ethernet is Connectionless (CLS)" (like IP) and assumes shared medium, while GMPLS is connection-oriented (CO) and doesn't work in shared medium. Off course you could always configure and build an Ethernet network that looks like it is CO (by configuring a max of 2 ports with the same VLAN ID in each bridge), and by not using any shared medium. But then who needs GMPLS, when you already have to configure your network by other means?
 
-Shahram
 
 
 From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, February 03, 2005 3:07 PM
To: Mack-Crane, T. Benjamin
Cc: [e-mail]; [e-mail]; David Allan; Adrian Farrel; Shahram Davari; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs



ben, 

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

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

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

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

voila, thanks,

- dimitri.

 



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

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




Dimitri,

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

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

Regards,
Ben

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


------_=_NextPart_001_01C50A35.3193FCF6
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.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=203485920-03022005><FONT face=Arial color=#0000ff 
size=2>Dimitri,</FONT></SPAN></DIV>
<DIV><SPAN class=203485920-03022005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=203485920-03022005><FONT face=Arial color=#0000ff 
size=2>Unfortunately I didn't grasp completely what you are trying to convey. 
But one thing I know for sure, and that is&nbsp; "Ethernet is Connectionless 
(CLS)" (like IP) and assumes shared medium, while GMPLS is connection-oriented 
(CO)&nbsp;and doesn't work in shared medium. Off course you could always 
configure and build an Ethernet network that looks like it is CO (by configuring 
a max of 2 ports with the same VLAN ID in each bridge), and by not using any 
shared medium. But then who needs GMPLS, when you already have to configure your 
network by other means?</FONT></SPAN></DIV>
<DIV><SPAN class=203485920-03022005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=203485920-03022005><FONT face=Arial color=#0000ff 
size=2>-Shahram</FONT></SPAN></DIV>
<DIV><SPAN class=203485920-03022005></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=203485920-03022005><FONT face=Arial 
color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=203485920-03022005></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=203485920-03022005>&nbsp;</SPAN><STRONG>From:</STRONG> 
[e-mail] 
[mailto:[e-mail]]<BR><B>Sent:</B> Thursday, February 03, 
2005 3:07 PM<BR><B>To:</B> Mack-Crane, T. Benjamin<BR><B>Cc:</B> 
[e-mail]; [e-mail]; David Allan; Adrian 
Farrel; Shahram Davari; [e-mail]<BR><B>Subject:</B> RE: Layer 2 
Switching Caps LSPs<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <P>ben, </P>
  <P>the discussion with dave has been reproduced in accelerated on the mailing 
  list - for me it appears that the more "philosophical" conclusion can be 
  positioned by answering to the following question "Was SONET/SDH or lambda 
  switching initially intended to be controlled by GMPLS ?" if the response is 
  "No, but nothing prevents to do so" the next question is what does prevent 
  from applying GMPLS to other technologies knowing a substantial gain is 
  obtained from its application - in certain conditions - (see motivations as 
  part of this introduction for instance) ? key issue being which are these 
  (technical) conditions and are there conditions that would preclude 
  progressing this document - the response is simply the negative - there are no 
  such conditions in the point-to-point - non-bridging - context where this 
  document applies. </P>
  <P>now, not sure there is a technical "firm" conclusion but the point on the 
  ethernet label encoding appears as follows since so far there is potential 
  interest to keep the label for ethernet generic enough and deduce its 
  interpretation from type of link over which the label is used and intepreet 
  its value according to the traffic_parameters and propose associations to 
  cover cases such as case 2 of Appendix A of 
  &lt;draft-pwe3-ethernet-encap-08.txt&gt; mechanisms that is also applicable to 
  other tunneling technology since this mechanism is orthogonal to the use of 
  PW's if required (example being Ethernet over SDH/OTH, for instance); however, 
  if these are the only associations we see relevant as part of this document 
  then we would fall back on the existing encoding with potential enhancement if 
  so required - </P>
  <P>to come to the point of the articulation the - generic - response holds in 
  one line: it articulates GMPLS signaling for L2SC LSPs (note: the latter has 
  been introduced in RFC 3945, RFC 3471, RFC 3473) - the motivations are 
  detailed as part of the introduction of this document - i can not comment more 
  from your initial statement since not detailed enough for me to be more 
  specific </P>
  <P>the response to the last question is relatively simple since the above 
  mentioned do not include any specifics concerning ATM or FR - this document 
  intends to close this gap by defining specific Traffic_Parameters for these 
  technologies - is there an interest for doing so: response is yes otherwise 
  the document would not have included the corr. details</P>
  <P>voila, thanks,</P>
  <P>- dimitri.</P>
  <P>&nbsp;</P>
  <P><BR><BR><FONT size=2><B>"Mack-Crane, T. Benjamin" 
  &lt;[e-mail]&gt;</B></FONT><BR><FONT size=2>Sent by: 
  [e-mail]</FONT><BR><FONT size=2>02/03/2005 12:16 
  CST</FONT><BR><BR><FONT size=2>To:</FONT> <FONT 
  size=2>&lt;[e-mail]&gt;, Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" 
  &lt;[e-mail]&gt;</FONT><BR><FONT size=2>cc:</FONT> <FONT 
  size=2>"Adrian Farrel" &lt;[e-mail]&gt;, "Shahram Davari" 
  &lt;[e-mail]&gt;, 
  &lt;[e-mail]&gt;</FONT><BR><FONT size=2>bcc:</FONT> <BR><FONT 
  size=2>Subject:</FONT> <FONT size=2>RE: Layer 2 Switching Caps 
  LSPs</FONT><BR><BR><BR></P>
  <P><FONT face=Monospace,Courier>Dimitri,<BR></FONT><BR><FONT 
  face=Monospace,Courier>Can the off-line discussion be summarized for the 
  benefit of those on<BR>the list who did not participate? &nbsp;For me, the 
  draft (and the current<BR>discussion on the list) have not clearly articulated 
  the problem being<BR>addressed. &nbsp;If a summary of the conclusions of the 
  off-line discussion<BR>will do this, it would be useful.<BR></FONT><BR><FONT 
  face=Monospace,Courier>I am also interested to know what is lacking in the 
  current GMPLS RFCs<BR>with respect to ATM and Frame Relay support that 
  necessitates including<BR>them in this new draft (presumably this is a part of 
  the problem to be<BR>solved).<BR></FONT><BR><FONT 
  face=Monospace,Courier>Regards,<BR>Ben<BR></FONT><BR><FONT 
  face=Monospace,Courier>&gt; -----Original Message-----<BR>&gt; From: 
  [e-mail] [mailto:[e-mail]] 
  On<BR>Behalf<BR>&gt; Of dimitri papadimitriou<BR>&gt; Sent: Thursday, January 
  27, 2005 6:35 PM<BR>&gt; To: David Allan<BR>&gt; Cc: 'Adrian Farrel'; 'Shahram 
  Davari'; [e-mail]<BR>&gt; Subject: Re: Layer 2 Switching Caps 
  LSPs<BR>&gt;<BR>&gt; dave - there was a lengthy off-line discussion suggested 
  by the chairs<BR>&gt; intended to explain you the scope of the draft and its 
  relatioship<BR>with<BR>&gt; the ethernet data plane (after the question you 
  raised during the f2f<BR>&gt; meeting) - this has been done and we have 
  explained (via a lengthy<BR>&gt; exchange of e-mails) that this document and 
  so the use of gmpls to<BR>&gt; control ethernet frame flows, is not targeting 
  control of bridged<BR>&gt; ethernet environments - if this is not clear from 
  the current document<BR>&gt; introduction we would have also to work on this 
  part of the document -<BR>&gt; therefore, the below reference to MSTP is not 
  in the current scope; on<BR>&gt; the other side, the use of the term "VLAN 
  label" has created some<BR>&gt; confusion; therefore, in a next release i will 
  simply refer to a<BR>"label"<BR>&gt; of 32 bits (unstructured) because the 
  intention was (and still is) to<BR>&gt; find an easy way to map the control of 
  the ethernet frame flows on<BR>each<BR>&gt; device they traverses without 
  making any assumption on how this flow<BR>is<BR>&gt; processed inside each 
  node at the data plane level (note: on label<BR>&gt; values, RFC 3946 took an 
  equivalent approach - for circuits - where<BR>&gt; sonet/sdh multiplexing 
  structures have been used to create unique<BR>&gt; multiplex entry names i.e. 
  labels - this concept is here applied for<BR>&gt; "virtual" circuits), so, if 
  the working group is willing to enter into<BR>a<BR>&gt; data plane oriented 
  discussion to clarify the behaviour(s) onto which<BR>&gt; the present approach 
  would be potentially applicable this is fine with<BR>&gt; me as long as we are 
  within the scope of the initial motivations<BR>&gt;<BR>&gt; thanks,<BR>&gt; - 
  dimitri.<BR>&gt;<BR>&gt; David Allan wrote:<BR>&gt; &gt; Hi Adrian:<BR>&gt; 
  &gt;<BR>&gt; &gt; Your suggestion is in a way reasonable but with the caveat 
  that in<BR>IEEE<BR>&gt; &gt; terms, a bridging topology is currently all VLANs 
  (802.1Q single<BR>&gt; spanning<BR>&gt; &gt; tree) or partitioned into 
  specific ranges (I believe 64 in 802.1s<BR>&gt; although I<BR>&gt; &gt; do not 
  claim to be an expert).<BR>&gt; &gt;<BR>&gt; &gt; If the PEs were to implement 
  a bridge function and we were using<BR>GMPLS<BR>&gt; to<BR>&gt; &gt; 
  interconnect them, then the control plane should be 
  identifying<BR>either<BR>&gt; all<BR>&gt; &gt; VLANs (single spanning tree, 
  which I beleive the draft covers by<BR>&gt; referring<BR>&gt; &gt; simply to 
  Ethernet port) or a VLAN range to be associated with the<BR>LSP<BR>&gt; &gt; 
  consistent with 802.1s if it is to operate to interconnect bridges<BR>&gt; 
  defined<BR>&gt; &gt; by the IEEE...<BR>&gt; &gt;<BR>&gt; &gt; I suspect 
  assuming any other behavior (e.g. LSP for single VLAN tag)<BR>&gt; 
  would<BR>&gt; &gt; go outside the boundary of what is currently defined...so 
  alignment<BR>with<BR>&gt; &gt; 802.1s IMO would be a minimum requirement if we 
  are to consider<BR>carrying<BR>&gt; &gt; VLAN information in GMPLS 
  signalling....<BR>&gt; &gt;<BR>&gt; &gt; cheers<BR>&gt; &gt; Dave<BR>&gt; 
  &gt;<BR>&gt; &gt; You wrote....<BR>&gt; &gt;<BR>&gt; &gt;&gt;Hi,<BR>&gt; 
  &gt;&gt;<BR>&gt; &gt;&gt;The authors of the draft might like to clarify for 
  the list<BR>&gt; &gt;&gt;exactly what data plane operations they are 
  suggesting. To me<BR>&gt; &gt;&gt;it seems possible that the draft is 
  proposing VLAN ID<BR>&gt; &gt;&gt;*swapping*. But an alternative is that the 
  VLAN ID is used as<BR>&gt; &gt;&gt;a label, but that the same label is used 
  for the full length<BR>&gt; &gt;&gt;of the LSP.<BR>&gt; &gt;&gt;<BR>&gt; 
  &gt;&gt;Adrian<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; .<BR>&gt; 
  &gt;<BR>============================================================<BR>The 
  information contained in this message may be privileged<BR>and confidential 
  and protected from disclosure. If the reader<BR>of this message is not the 
  intended recipient, or an employee<BR>or agent responsible for delivering this 
  message to the<BR>intended recipient, you are hereby notified that any 
  reproduction,<BR>dissemination or distribution of this communication is 
  strictly<BR>prohibited. If you have received this communication in 
  error,<BR>please notify us immediately by replying to the message 
  and<BR>deleting it from your computer. Thank you. 
  Tellabs<BR>============================================================</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C50A35.3193FCF6--



Envelope-to: [e-mail]
Delivery-date: Thu, 03 Feb 2005 20:07:59 +0000
To: "Mack-Crane, T. Benjamin" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "David Allan" <[e-mail]>, "Adrian Farrel" <[e-mail]>, "Shahram Davari" <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Thu, 3 Feb 2005 21:07:00 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+YmVuLCA8L1A+PFA+dGhlIGRpc2N1c3Npb24gd2l0aCBkYXZlIGhhcyBiZWVuIHJlcHJvZHVj
ZWQgaW4gYWNjZWxlcmF0ZWQgb24gdGhlIG1haWxpbmcgbGlzdCAtIGZvciBtZSBpdCBhcHBlYXJz
IHRoYXQgdGhlIG1vcmUgJnF1b3Q7cGhpbG9zb3BoaWNhbCZxdW90OyBjb25jbHVzaW9uIGNhbiBi
ZSBwb3NpdGlvbmVkIGJ5IGFuc3dlcmluZyB0byB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uICZxdW90
O1dhcyBTT05FVC9TREggb3IgbGFtYmRhIHN3aXRjaGluZyBpbml0aWFsbHkgaW50ZW5kZWQgdG8g
YmUgY29udHJvbGxlZCBieSBHTVBMUyA/JnF1b3Q7IGlmIHRoZSByZXNwb25zZSBpcyAmcXVvdDtO
bywgYnV0IG5vdGhpbmcgcHJldmVudHMgdG8gZG8gc28mcXVvdDsgdGhlIG5leHQgcXVlc3Rpb24g
aXMgd2hhdCBkb2VzIHByZXZlbnQgZnJvbSBhcHBseWluZyBHTVBMUyB0byBvdGhlciB0ZWNobm9s
b2dpZXMga25vd2luZyBhIHN1YnN0YW50aWFsIGdhaW4gaXMgb2J0YWluZWQgZnJvbSBpdHMgYXBw
bGljYXRpb24gLSBpbiBjZXJ0YWluIGNvbmRpdGlvbnMgLSAoc2VlIG1vdGl2YXRpb25zIGFzIHBh
cnQgb2YgdGhpcyBpbnRyb2R1Y3Rpb24gZm9yIGluc3RhbmNlKSA/IGtleSBpc3N1ZSBiZWluZyB3
aGljaCBhcmUgdGhlc2UgKHRlY2huaWNhbCkgY29uZGl0aW9ucyBhbmQgYXJlIHRoZXJlIGNvbmRp
dGlvbnMgdGhhdCB3b3VsZCBwcmVjbHVkZSBwcm9ncmVzc2luZyB0aGlzIGRvY3VtZW50IC0gdGhl
IHJlc3BvbnNlIGlzIHNpbXBseSB0aGUgbmVnYXRpdmUgLSB0aGVyZSBhcmUgbm8gc3VjaCBjb25k
aXRpb25zIGluIHRoZSBwb2ludC10by1wb2ludCAtIG5vbi1icmlkZ2luZyAtIGNvbnRleHQgd2hl
cmUgdGhpcyBkb2N1bWVudCBhcHBsaWVzLiA8L1A+PFA+bm93LCBub3Qgc3VyZSB0aGVyZSBpcyBh
IHRlY2huaWNhbCAmcXVvdDtmaXJtJnF1b3Q7IGNvbmNsdXNpb24gYnV0IHRoZSBwb2ludCBvbiB0
aGUgZXRoZXJuZXQgbGFiZWwgZW5jb2RpbmcgYXBwZWFycyBhcyBmb2xsb3dzIHNpbmNlIHNvIGZh
ciB0aGVyZSBpcyBwb3RlbnRpYWwgaW50ZXJlc3QgdG8ga2VlcCB0aGUgbGFiZWwgZm9yIGV0aGVy
bmV0IGdlbmVyaWMgZW5vdWdoIGFuZCBkZWR1Y2UgaXRzIGludGVycHJldGF0aW9uIGZyb20gdHlw
ZSBvZiBsaW5rIG92ZXIgd2hpY2ggdGhlIGxhYmVsIGlzIHVzZWQgYW5kIGludGVwcmVldCBpdHMg
dmFsdWUgYWNjb3JkaW5nIHRvIHRoZSB0cmFmZmljX3BhcmFtZXRlcnMgYW5kIHByb3Bvc2UgYXNz
b2NpYXRpb25zIHRvIGNvdmVyIGNhc2VzIHN1Y2ggYXMgY2FzZSAyIG9mIEFwcGVuZGl4IEEgb2Yg
Jmx0O2RyYWZ0LXB3ZTMtZXRoZXJuZXQtZW5jYXAtMDgudHh0Jmd0OyBtZWNoYW5pc21zIHRoYXQg
aXMgYWxzbyBhcHBsaWNhYmxlIHRvIG90aGVyIHR1bm5lbGluZyB0ZWNobm9sb2d5IHNpbmNlIHRo
aXMgbWVjaGFuaXNtIGlzIG9ydGhvZ29uYWwgdG8gdGhlIHVzZSBvZiBQVydzIGlmIHJlcXVpcmVk
IChleGFtcGxlIGJlaW5nIEV0aGVybmV0IG92ZXIgU0RIL09USCwgZm9yIGluc3RhbmNlKTsgaG93
ZXZlciwgaWYgdGhlc2UgYXJlIHRoZSBvbmx5IGFzc29jaWF0aW9ucyB3ZSBzZWUgcmVsZXZhbnQg
YXMgcGFydCBvZiB0aGlzIGRvY3VtZW50IHRoZW4gd2Ugd291bGQgZmFsbCBiYWNrIG9uIHRoZSBl
eGlzdGluZyBlbmNvZGluZyB3aXRoIHBvdGVudGlhbCBlbmhhbmNlbWVudCBpZiBzbyByZXF1aXJl
ZCAtIDwvUD48UD50byBjb21lIHRvIHRoZSBwb2ludCBvZiB0aGUgYXJ0aWN1bGF0aW9uIHRoZSAt
IGdlbmVyaWMgLSByZXNwb25zZSBob2xkcyBpbiBvbmUgbGluZTogaXQgYXJ0aWN1bGF0ZXMgR01Q
TFMgc2lnbmFsaW5nIGZvciBMMlNDIExTUHMgKG5vdGU6IHRoZSBsYXR0ZXIgaGFzIGJlZW4gaW50
cm9kdWNlZCBpbiBSRkMgMzk0NSwgUkZDIDM0NzEsIFJGQyAzNDczKSAtIHRoZSBtb3RpdmF0aW9u
cyBhcmUgZGV0YWlsZWQgYXMgcGFydCBvZiB0aGUgaW50cm9kdWN0aW9uIG9mIHRoaXMgZG9jdW1l
bnQgLSBpIGNhbiBub3QgY29tbWVudCBtb3JlIGZyb20geW91ciBpbml0aWFsIHN0YXRlbWVudCBz
aW5jZSBub3QgZGV0YWlsZWQgZW5vdWdoIGZvciBtZSB0byBiZSBtb3JlIHNwZWNpZmljIDwvUD48
UD50aGUgcmVzcG9uc2UgdG8gdGhlIGxhc3QgcXVlc3Rpb24gaXMgcmVsYXRpdmVseSBzaW1wbGUg
c2luY2UgdGhlIGFib3ZlIG1lbnRpb25lZCBkbyBub3QgaW5jbHVkZSBhbnkgc3BlY2lmaWNzIGNv
bmNlcm5pbmcgQVRNIG9yIEZSIC0gdGhpcyBkb2N1bWVudCBpbnRlbmRzIHRvIGNsb3NlIHRoaXMg
Z2FwIGJ5IGRlZmluaW5nIHNwZWNpZmljIFRyYWZmaWNfUGFyYW1ldGVycyBmb3IgdGhlc2UgdGVj
aG5vbG9naWVzIC0gaXMgdGhlcmUgYW4gaW50ZXJlc3QgZm9yIGRvaW5nIHNvOiByZXNwb25zZSBp
cyB5ZXMgb3RoZXJ3aXNlIHRoZSBkb2N1bWVudCB3b3VsZCBub3QgaGF2ZSBpbmNsdWRlZCB0aGUg
Y29yci4gZGV0YWlsczwvUD48UD52b2lsYSwgdGhhbmtzLDwvUD48UD4tIGRpbWl0cmkuPC9QPjxQ
PiZuYnNwOzwvUD48UD48QlI+PEJSPjxGT05UIFNJWkU9Mj48Qj4mcXVvdDtNYWNrLUNyYW5lLCBU
LiBCZW5qYW1pbiZxdW90OyAmbHQ7QmVuLk1hY2stQ3JhbmVAdGVsbGFicy5jb20mZ3Q7PC9CPjwv
Rk9OVD48QlI+PEZPTlQgU0laRT0yPlNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwv
Rk9OVD48QlI+PEZPTlQgU0laRT0yPjAyLzAzLzIwMDUgMTI6MTYgQ1NUPC9GT05UPjxCUj48QlI+
IDxGT05UIFNJWkU9Mj5Ubzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj4mbHQ7ZHBhcGFkaW1pdHJpb3VA
cHNnLmNvbSZndDssIERpbWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUwsICZx
dW90O0RhdmlkIEFsbGFuJnF1b3Q7ICZsdDtkYWxsYW5Abm9ydGVsbmV0d29ya3MuY29tJmd0Ozwv
Rk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj4mcXVvdDtBZHJp
YW4gRmFycmVsJnF1b3Q7ICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OywgJnF1b3Q7U2hhaHJh
bSBEYXZhcmkmcXVvdDsgJmx0O1NoYWhyYW1fRGF2YXJpQHBtYy1zaWVycmEuY29tJmd0OywgJmx0
O2NjYW1wQG9wcy5pZXRmLm9yZyZndDs8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+YmNjOjwvRk9O
VD4gPEJSPiA8Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5SRTogTGF5
ZXIgMiBTd2l0Y2hpbmcgQ2FwcyBMU1BzPC9GT05UPjxCUj4gPEJSPjxCUj48L1A+PFA+PEZPTlQg
RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkRpbWl0cmksPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFD
RT0iTW9ub3NwYWNlLENvdXJpZXIiPkNhbiB0aGUgb2ZmLWxpbmUgZGlzY3Vzc2lvbiBiZSBzdW1t
YXJpemVkIGZvciB0aGUgYmVuZWZpdCBvZiB0aG9zZSBvbjxCUj50aGUgbGlzdCB3aG8gZGlkIG5v
dCBwYXJ0aWNpcGF0ZT8gJm5ic3A7Rm9yIG1lLCB0aGUgZHJhZnQgKGFuZCB0aGUgY3VycmVudDxC
Uj5kaXNjdXNzaW9uIG9uIHRoZSBsaXN0KSBoYXZlIG5vdCBjbGVhcmx5IGFydGljdWxhdGVkIHRo
ZSBwcm9ibGVtIGJlaW5nPEJSPmFkZHJlc3NlZC4gJm5ic3A7SWYgYSBzdW1tYXJ5IG9mIHRoZSBj
b25jbHVzaW9ucyBvZiB0aGUgb2ZmLWxpbmUgZGlzY3Vzc2lvbjxCUj53aWxsIGRvIHRoaXMsIGl0
IHdvdWxkIGJlIHVzZWZ1bC48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291
cmllciI+SSBhbSBhbHNvIGludGVyZXN0ZWQgdG8ga25vdyB3aGF0IGlzIGxhY2tpbmcgaW4gdGhl
IGN1cnJlbnQgR01QTFMgUkZDczxCUj53aXRoIHJlc3BlY3QgdG8gQVRNIGFuZCBGcmFtZSBSZWxh
eSBzdXBwb3J0IHRoYXQgbmVjZXNzaXRhdGVzIGluY2x1ZGluZzxCUj50aGVtIGluIHRoaXMgbmV3
IGRyYWZ0IChwcmVzdW1hYmx5IHRoaXMgaXMgYSBwYXJ0IG9mIHRoZSBwcm9ibGVtIHRvIGJlPEJS
PnNvbHZlZCkuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlJl
Z2FyZHMsPEJSPkJlbjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy
Ij4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPiZndDsgRnJvbTogb3duZXItY2Nh
bXBAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXSBPbjxCUj5C
ZWhhbGY8QlI+Jmd0OyBPZiBkaW1pdHJpIHBhcGFkaW1pdHJpb3U8QlI+Jmd0OyBTZW50OiBUaHVy
c2RheSwgSmFudWFyeSAyNywgMjAwNSA2OjM1IFBNPEJSPiZndDsgVG86IERhdmlkIEFsbGFuPEJS
PiZndDsgQ2M6ICdBZHJpYW4gRmFycmVsJzsgJ1NoYWhyYW0gRGF2YXJpJzsgY2NhbXBAb3BzLmll
dGYub3JnPEJSPiZndDsgU3ViamVjdDogUmU6IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQczxC
Uj4mZ3Q7PEJSPiZndDsgZGF2ZSAtIHRoZXJlIHdhcyBhIGxlbmd0aHkgb2ZmLWxpbmUgZGlzY3Vz
c2lvbiBzdWdnZXN0ZWQgYnkgdGhlIGNoYWlyczxCUj4mZ3Q7IGludGVuZGVkIHRvIGV4cGxhaW4g
eW91IHRoZSBzY29wZSBvZiB0aGUgZHJhZnQgYW5kIGl0cyByZWxhdGlvc2hpcDxCUj53aXRoPEJS
PiZndDsgdGhlIGV0aGVybmV0IGRhdGEgcGxhbmUgKGFmdGVyIHRoZSBxdWVzdGlvbiB5b3UgcmFp
c2VkIGR1cmluZyB0aGUgZjJmPEJSPiZndDsgbWVldGluZykgLSB0aGlzIGhhcyBiZWVuIGRvbmUg
YW5kIHdlIGhhdmUgZXhwbGFpbmVkICh2aWEgYSBsZW5ndGh5PEJSPiZndDsgZXhjaGFuZ2Ugb2Yg
ZS1tYWlscykgdGhhdCB0aGlzIGRvY3VtZW50IGFuZCBzbyB0aGUgdXNlIG9mIGdtcGxzIHRvPEJS
PiZndDsgY29udHJvbCBldGhlcm5ldCBmcmFtZSBmbG93cywgaXMgbm90IHRhcmdldGluZyBjb250
cm9sIG9mIGJyaWRnZWQ8QlI+Jmd0OyBldGhlcm5ldCBlbnZpcm9ubWVudHMgLSBpZiB0aGlzIGlz
IG5vdCBjbGVhciBmcm9tIHRoZSBjdXJyZW50IGRvY3VtZW50PEJSPiZndDsgaW50cm9kdWN0aW9u
IHdlIHdvdWxkIGhhdmUgYWxzbyB0byB3b3JrIG9uIHRoaXMgcGFydCBvZiB0aGUgZG9jdW1lbnQg
LTxCUj4mZ3Q7IHRoZXJlZm9yZSwgdGhlIGJlbG93IHJlZmVyZW5jZSB0byBNU1RQIGlzIG5vdCBp
biB0aGUgY3VycmVudCBzY29wZTsgb248QlI+Jmd0OyB0aGUgb3RoZXIgc2lkZSwgdGhlIHVzZSBv
ZiB0aGUgdGVybSAmcXVvdDtWTEFOIGxhYmVsJnF1b3Q7IGhhcyBjcmVhdGVkIHNvbWU8QlI+Jmd0
OyBjb25mdXNpb247IHRoZXJlZm9yZSwgaW4gYSBuZXh0IHJlbGVhc2UgaSB3aWxsIHNpbXBseSBy
ZWZlciB0byBhPEJSPiZxdW90O2xhYmVsJnF1b3Q7PEJSPiZndDsgb2YgMzIgYml0cyAodW5zdHJ1
Y3R1cmVkKSBiZWNhdXNlIHRoZSBpbnRlbnRpb24gd2FzIChhbmQgc3RpbGwgaXMpIHRvPEJSPiZn
dDsgZmluZCBhbiBlYXN5IHdheSB0byBtYXAgdGhlIGNvbnRyb2wgb2YgdGhlIGV0aGVybmV0IGZy
YW1lIGZsb3dzIG9uPEJSPmVhY2g8QlI+Jmd0OyBkZXZpY2UgdGhleSB0cmF2ZXJzZXMgd2l0aG91
dCBtYWtpbmcgYW55IGFzc3VtcHRpb24gb24gaG93IHRoaXMgZmxvdzxCUj5pczxCUj4mZ3Q7IHBy
b2Nlc3NlZCBpbnNpZGUgZWFjaCBub2RlIGF0IHRoZSBkYXRhIHBsYW5lIGxldmVsIChub3RlOiBv
biBsYWJlbDxCUj4mZ3Q7IHZhbHVlcywgUkZDIDM5NDYgdG9vayBhbiBlcXVpdmFsZW50IGFwcHJv
YWNoIC0gZm9yIGNpcmN1aXRzIC0gd2hlcmU8QlI+Jmd0OyBzb25ldC9zZGggbXVsdGlwbGV4aW5n
IHN0cnVjdHVyZXMgaGF2ZSBiZWVuIHVzZWQgdG8gY3JlYXRlIHVuaXF1ZTxCUj4mZ3Q7IG11bHRp
cGxleCBlbnRyeSBuYW1lcyBpLmUuIGxhYmVscyAtIHRoaXMgY29uY2VwdCBpcyBoZXJlIGFwcGxp
ZWQgZm9yPEJSPiZndDsgJnF1b3Q7dmlydHVhbCZxdW90OyBjaXJjdWl0cyksIHNvLCBpZiB0aGUg
d29ya2luZyBncm91cCBpcyB3aWxsaW5nIHRvIGVudGVyIGludG88QlI+YTxCUj4mZ3Q7IGRhdGEg
cGxhbmUgb3JpZW50ZWQgZGlzY3Vzc2lvbiB0byBjbGFyaWZ5IHRoZSBiZWhhdmlvdXIocykgb250
byB3aGljaDxCUj4mZ3Q7IHRoZSBwcmVzZW50IGFwcHJvYWNoIHdvdWxkIGJlIHBvdGVudGlhbGx5
IGFwcGxpY2FibGUgdGhpcyBpcyBmaW5lIHdpdGg8QlI+Jmd0OyBtZSBhcyBsb25nIGFzIHdlIGFy
ZSB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBpbml0aWFsIG1vdGl2YXRpb25zPEJSPiZndDs8QlI+
Jmd0OyB0aGFua3MsPEJSPiZndDsgLSBkaW1pdHJpLjxCUj4mZ3Q7PEJSPiZndDsgRGF2aWQgQWxs
YW4gd3JvdGU6PEJSPiZndDsgJmd0OyBIaSBBZHJpYW46PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZn
dDsgWW91ciBzdWdnZXN0aW9uIGlzIGluIGEgd2F5IHJlYXNvbmFibGUgYnV0IHdpdGggdGhlIGNh
dmVhdCB0aGF0IGluPEJSPklFRUU8QlI+Jmd0OyAmZ3Q7IHRlcm1zLCBhIGJyaWRnaW5nIHRvcG9s
b2d5IGlzIGN1cnJlbnRseSBhbGwgVkxBTnMgKDgwMi4xUSBzaW5nbGU8QlI+Jmd0OyBzcGFubmlu
ZzxCUj4mZ3Q7ICZndDsgdHJlZSkgb3IgcGFydGl0aW9uZWQgaW50byBzcGVjaWZpYyByYW5nZXMg
KEkgYmVsaWV2ZSA2NCBpbiA4MDIuMXM8QlI+Jmd0OyBhbHRob3VnaCBJPEJSPiZndDsgJmd0OyBk
byBub3QgY2xhaW0gdG8gYmUgYW4gZXhwZXJ0KS48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBJ
ZiB0aGUgUEVzIHdlcmUgdG8gaW1wbGVtZW50IGEgYnJpZGdlIGZ1bmN0aW9uIGFuZCB3ZSB3ZXJl
IHVzaW5nPEJSPkdNUExTPEJSPiZndDsgdG88QlI+Jmd0OyAmZ3Q7IGludGVyY29ubmVjdCB0aGVt
LCB0aGVuIHRoZSBjb250cm9sIHBsYW5lIHNob3VsZCBiZSBpZGVudGlmeWluZzxCUj5laXRoZXI8
QlI+Jmd0OyBhbGw8QlI+Jmd0OyAmZ3Q7IFZMQU5zIChzaW5nbGUgc3Bhbm5pbmcgdHJlZSwgd2hp
Y2ggSSBiZWxlaXZlIHRoZSBkcmFmdCBjb3ZlcnMgYnk8QlI+Jmd0OyByZWZlcnJpbmc8QlI+Jmd0
OyAmZ3Q7IHNpbXBseSB0byBFdGhlcm5ldCBwb3J0KSBvciBhIFZMQU4gcmFuZ2UgdG8gYmUgYXNz
b2NpYXRlZCB3aXRoIHRoZTxCUj5MU1A8QlI+Jmd0OyAmZ3Q7IGNvbnNpc3RlbnQgd2l0aCA4MDIu
MXMgaWYgaXQgaXMgdG8gb3BlcmF0ZSB0byBpbnRlcmNvbm5lY3QgYnJpZGdlczxCUj4mZ3Q7IGRl
ZmluZWQ8QlI+Jmd0OyAmZ3Q7IGJ5IHRoZSBJRUVFLi4uPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZn
dDsgSSBzdXNwZWN0IGFzc3VtaW5nIGFueSBvdGhlciBiZWhhdmlvciAoZS5nLiBMU1AgZm9yIHNp
bmdsZSBWTEFOIHRhZyk8QlI+Jmd0OyB3b3VsZDxCUj4mZ3Q7ICZndDsgZ28gb3V0c2lkZSB0aGUg
Ym91bmRhcnkgb2Ygd2hhdCBpcyBjdXJyZW50bHkgZGVmaW5lZC4uLnNvIGFsaWdubWVudDxCUj53
aXRoPEJSPiZndDsgJmd0OyA4MDIuMXMgSU1PIHdvdWxkIGJlIGEgbWluaW11bSByZXF1aXJlbWVu
dCBpZiB3ZSBhcmUgdG8gY29uc2lkZXI8QlI+Y2Fycnlpbmc8QlI+Jmd0OyAmZ3Q7IFZMQU4gaW5m
b3JtYXRpb24gaW4gR01QTFMgc2lnbmFsbGluZy4uLi48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0
OyBjaGVlcnM8QlI+Jmd0OyAmZ3Q7IERhdmU8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBZb3Ug
d3JvdGUuLi4uPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsmZ3Q7SGksPEJSPiZndDsgJmd0OyZn
dDs8QlI+Jmd0OyAmZ3Q7Jmd0O1RoZSBhdXRob3JzIG9mIHRoZSBkcmFmdCBtaWdodCBsaWtlIHRv
IGNsYXJpZnkgZm9yIHRoZSBsaXN0PEJSPiZndDsgJmd0OyZndDtleGFjdGx5IHdoYXQgZGF0YSBw
bGFuZSBvcGVyYXRpb25zIHRoZXkgYXJlIHN1Z2dlc3RpbmcuIFRvIG1lPEJSPiZndDsgJmd0OyZn
dDtpdCBzZWVtcyBwb3NzaWJsZSB0aGF0IHRoZSBkcmFmdCBpcyBwcm9wb3NpbmcgVkxBTiBJRDxC
Uj4mZ3Q7ICZndDsmZ3Q7KnN3YXBwaW5nKi4gQnV0IGFuIGFsdGVybmF0aXZlIGlzIHRoYXQgdGhl
IFZMQU4gSUQgaXMgdXNlZCBhczxCUj4mZ3Q7ICZndDsmZ3Q7YSBsYWJlbCwgYnV0IHRoYXQgdGhl
IHNhbWUgbGFiZWwgaXMgdXNlZCBmb3IgdGhlIGZ1bGwgbGVuZ3RoPEJSPiZndDsgJmd0OyZndDtv
ZiB0aGUgTFNQLjxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDtBZHJpYW48QlI+Jmd0
OyAmZ3Q7PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IC48QlI+Jmd0OyAm
Z3Q7PEJSPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PTxCUj5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBt
YXkgYmUgcHJpdmlsZWdlZDxCUj5hbmQgY29uZmlkZW50aWFsIGFuZCBwcm90ZWN0ZWQgZnJvbSBk
aXNjbG9zdXJlLiBJZiB0aGUgcmVhZGVyPEJSPm9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGlu
dGVuZGVkIHJlY2lwaWVudCwgb3IgYW4gZW1wbG95ZWU8QlI+b3IgYWdlbnQgcmVzcG9uc2libGUg
Zm9yIGRlbGl2ZXJpbmcgdGhpcyBtZXNzYWdlIHRvIHRoZTxCUj5pbnRlbmRlZCByZWNpcGllbnQs
IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHJlcHJvZHVjdGlvbiw8QlI+ZGlzc2Vt
aW5hdGlvbiBvciBkaXN0cmlidXRpb24gb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5
PEJSPnByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBp
biBlcnJvciw8QlI+cGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSByZXBseWluZyB0byB0
aGUgbWVzc2FnZSBhbmQ8QlI+ZGVsZXRpbmcgaXQgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5
b3UuIFRlbGxhYnM8QlI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PC9GT05UPjwvUD4=



Envelope-to: [e-mail]
Delivery-date: Thu, 03 Feb 2005 19:32:07 +0000
From: "Richard Rabbat" <[e-mail]>
To: <[e-mail]>
Cc: "'Richard Rabbat'" <[e-mail]>, "'Rajiv Papneja'" <[e-mail]>, <[e-mail]>
Subject: new draft submission draft-shiomoto-ccamp-gmpls-addressing-00.txt
Date: Thu, 3 Feb 2005 11:30:18 -0800
Message-ID: <003d01c50a26$cb6f9650$483ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01C509E3.BD4C5650"

This is a multi-part message in MIME format.

------=_NextPart_000_003E_01C509E3.BD4C5650
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi all,
We have submitted a new draft for the next IETF meeting:
http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-addressing=
-00
.txt
This draft is to address issues related to interoperability and to allow
interworking between diverse GMPLS implementations.
Please read the draft and send us feedback.
Thanks,
Richard, Rajiv and Kohei
Abstract =20

   =20

   This document describes best practices in addressing and messaging in =


   Generalized Multi-Protocol Label Switching (GMPLS) networks.  The aim =


   of this document is to facilitate and ensure better interworking of=20

   GMPLS-capable Label Switching Routers (LSR) based on experience=20

   gained in deployments and interoperability testing.  =20

   =20

   The document recommends best practices for the 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 Engineering=20

   (RSVP-TE) signaling message processing issues and recommends best=20

   practices.
=20
=20

------=_NextPart_000_003E_01C509E3.BD4C5650
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.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<DIV><SPAN class=3D403342317-02022005><FONT face=3DArial size=3D2>Hi=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D403342317-02022005><FONT face=3DArial size=3D2>We=20
have&nbsp;submitted a new draft for&nbsp;<SPAN =
class=3D776542519-03022005>the=20
</SPAN>next&nbsp;<SPAN class=3D776542519-03022005>IETF=20
</SPAN>meeting:</FONT></SPAN></DIV>
<DIV><SPAN class=3D403342317-02022005><FONT face=3DArial size=3D2><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-ad=
dressing-00.txt">http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp=
-gmpls-addressing-00.txt</A></FONT></SPAN></DIV>
<DIV><SPAN class=3D403342317-02022005><FONT face=3DArial size=3D2>This =
draft is to=20
address issues related to interoperability and to allow interworking =
between=20
diverse GMPLS implementations.</FONT></SPAN></DIV>
<DIV><SPAN class=3D403342317-02022005><SPAN =
class=3D776542519-03022005><FONT=20
face=3DArial size=3D2>Please read the draft and send us=20
feedback.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D403342317-02022005><SPAN=20
class=3D776542519-03022005></SPAN></SPAN><SPAN =
class=3D403342317-02022005><FONT=20
face=3DArial size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D403342317-02022005><FONT face=3DArial size=3D2>
<DIV align=3Dleft><FONT face=3DArial><FONT size=3D2>Richard<SPAN=20
class=3D776542519-03022005>, Rajiv and=20
Kohei</SPAN></FONT></FONT></FONT></DIV></DIV><PRE>Abstract =20
   =20
   This document describes best practices in addressing and messaging in =

   Generalized Multi-Protocol Label Switching (GMPLS) networks.  The aim =

   of this document is to facilitate and ensure better interworking of=20
   GMPLS-capable Label Switching Routers (LSR) based on experience=20
   gained in deployments and interoperability testing.  =20
   =20
   The document recommends best practices for the 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 Engineering=20
   (RSVP-TE) signaling message processing issues and recommends best=20
   practices.</PRE></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D776542519-03022005></SPAN></FONT></FONT>&nbsp;</DIV></BODY></HTML=
>

------=_NextPart_000_003E_01C509E3.BD4C5650--




Envelope-to: [e-mail]
Delivery-date: Thu, 03 Feb 2005 18:17: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: Layer 2 Switching Caps LSPs
Date: Thu, 3 Feb 2005 12:16:22 -0600
Message-ID: <[e-mail]>
Thread-Topic: Layer 2 Switching Caps LSPs
Thread-Index: AcUE0XERnOu3c6lqQLCqrt1FXHtTdgFSkguA
From: "Mack-Crane, T. Benjamin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "David Allan" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>, "Shahram Davari" <[e-mail]>, <[e-mail]>

Dimitri,

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

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

Regards,
Ben

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
Behalf
> Of dimitri papadimitriou
> Sent: Thursday, January 27, 2005 6:35 PM
> To: David Allan
> Cc: 'Adrian Farrel'; 'Shahram Davari'; [e-mail]
> Subject: Re: Layer 2 Switching Caps LSPs
>=20
> dave - there was a lengthy off-line discussion suggested by the chairs
> intended to explain you the scope of the draft and its relatioship
with
> the ethernet data plane (after the question you raised during the f2f
> meeting) - this has been done and we have explained (via a lengthy
> exchange of e-mails) that this document and so the use of gmpls to
> control ethernet frame flows, is not targeting control of bridged
> ethernet environments - if this is not clear from the current document
> introduction we would have also to work on this part of the document -
> therefore, the below reference to MSTP is not in the current scope; on
> the other side, the use of the term "VLAN label" has created some
> confusion; therefore, in a next release i will simply refer to a
"label"
> of 32 bits (unstructured) because the intention was (and still is) to
> find an easy way to map the control of the ethernet frame flows on
each
> device they traverses without making any assumption on how this flow
is
> processed inside each node at the data plane level (note: on label
> values, RFC 3946 took an equivalent approach - for circuits - where
> sonet/sdh multiplexing structures have been used to create unique
> multiplex entry names i.e. labels - this concept is here applied for
> "virtual" circuits), so, if the working group is willing to enter into
a
> data plane oriented discussion to clarify the behaviour(s) onto which
> the present approach would be potentially applicable this is fine with
> me as long as we are within the scope of the initial motivations
>=20
> thanks,
> - dimitri.
>=20
> David Allan wrote:
> > Hi Adrian:
> >
> > Your suggestion is in a way reasonable but with the caveat that in
IEEE
> > terms, a bridging topology is currently all VLANs (802.1Q single
> spanning
> > tree) or partitioned into specific ranges (I believe 64 in 802.1s
> although I
> > do not claim to be an expert).
> >
> > If the PEs were to implement a bridge function and we were using
GMPLS
> to
> > interconnect them, then the control plane should be identifying
either
> all
> > VLANs (single spanning tree, which I beleive the draft covers by
> referring
> > simply to Ethernet port) or a VLAN range to be associated with the
LSP
> > consistent with 802.1s if it is to operate to interconnect bridges
> defined
> > by the IEEE...
> >
> > I suspect assuming any other behavior (e.g. LSP for single VLAN tag)
> would
> > go outside the boundary of what is currently defined...so alignment
with
> > 802.1s IMO would be a minimum requirement if we are to consider
carrying
> > VLAN information in GMPLS signalling....
> >
> > cheers
> > Dave
> >
> > You wrote....
> >
> >>Hi,
> >>
> >>The authors of the draft might like to clarify for the list
> >>exactly what data plane operations they are suggesting. To me
> >>it seems possible that the draft is proposing VLAN ID
> >>*swapping*. But an alternative is that the VLAN ID is used as
> >>a label, but that the same label is used for the full length
> >>of the LSP.
> >>
> >>Adrian
> >
> >
> >
> > .
> >
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: Thu, 03 Feb 2005 13:35:36 +0000
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: multipart/alternative; boundary=Apple-Mail-1-281493736
Message-Id: <[e-mail]>
Cc: <[e-mail]>
From: JP Vasseur <[e-mail]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Thu, 3 Feb 2005 08:35:12 -0500
To: "Adrian Farrel" <[e-mail]>

--Apple-Mail-1-281493736
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed

Hi Adrian,

On Jan 29, 2005, at 9:59 AM, Adrian Farrel wrote:

> Thanks JP (and thanks for the rigour of tracking down all of the=20
> points raised).
>
>
> =A0
> [SNIPPED]
>
>
>
> >> It seems to me that this draft is applicable to a strict ERO where=20=

> one
>
>
> >> of the hops is a non-specific abstract node such as an AS number.=20=

> This
>
>
>  >> is made clear in section 2, but the Abstract and Introduction=20
> (yeah,
>
>
> >> and also the title and draft name) do not adequately expose this=20
> fact.
>
>
> >> But, further, the Introduction talks only about reoptimization=20
> without
>
>
> >> any mention of loose hops or abstract nodes. Thus the draft is
>
>
>  >> schizoid to the third degree - is this loose path reoptimization,
>
>
>  >> reoptimization of loose and non-specific abstract nodes, or =
general
>
>
> >> reoptimization? The draft needs to be consistent and clear.
>
>
> >
>
>
> >Agree, the following definition has been adopted throughout the
>
>
> >document: "A loosely routed LSP is defined as an LSP that follows a
>
>
> >path that contains at least one loose hop or a strict (abstract node)
>
>
> >hop"
>
>
> =A0
> So, to be clear, you are only interested in the reoptimization of such=20=

> "loosely routed LSPs".
>
>
> =A0
> But note RFC 3209...
>
>
> =A0=A0 An abstract node
>
>
> =A0=A0 is a group of nodes whose internal topology is opaque to the =
ingress
>
>
> =A0=A0 node of the LSP.=A0 An abstract node is said to be simple if it
>
>
> =A0=A0 contains only one physical node.
>
>
> So your definition is not quite accurate since a "strict (abstract=20
> node) hop" includes a strict simple abstract node.
>
>
> =A0
> How about:
>
>
> =A0=A0 A loosely routed LSP is defined as one that does not contain a =
full
>
>
> =A0 =A0explicit route identifying each LSR along the path of the LSP =
at
>
>
>  =A0=A0 the time it is signaled by the ingress LSR. Such an LSP is =
signaled
>
>
> =A0=A0 with no ERO, with an ERO that contains at least one loose hop, =
or
>
>
> =A0=A0=A0with an ERO that contains an abstract node that is not a =
simple
>
>
> =A0=A0=A0abstract node (that is, an abstract node that identifies more =
than
>
>
> =A0=A0 one LSR).
>
>

Good suggestion, thanks.

> =A0
> >I guess that the document title can remain unchanged considering that=20=

> a
>
>
> >loose path also includes the case of a path where at least one hop is
>
>
> >an abstract node.
>
>
> =A0
> Following the above definition, that is true. Just check that the=20
> defintion appears early in the Introduction (and maybe in the=20
> Abstract).
>
>
>

Sure.

>
> >> Section 2 states that an ERO expansion is either up to the next=20
> loose
>
>
> >> hop or to the destination. But, in fact, the ERO expansion may also=20=

> be
>
>
> >> any partial fragment towards either of these targets (including =
next
>
>
> >> hop resolution). I suggest re-wording this paragraph to list (as
>
>
> >> bullets) what an ERO might contain, and in a separate list, what =
the
>
>
>  >> computation might produce.
>
>
> >
>
>
> >We listed in this paragraph the most usual case of ERO expansion. If
>
>
> >you're ok with this, elaborating further on ERO expansion is out of=20=

> the
>
>
> >scope of this document.
>
>
> =A0
>
>
> "Most usual" is subjective. Consider nested domains.
>
>
> But I'm not too bothered about this particular issue, so leave the=20
> text.
>
>
> =A0
>
>
> >> Section 4.1
>
>
> >>
>
>
> >> I'm not comfortable with the Session Attributes toggling like this.
>
>
> >> This type of function is what the Admin Status object was invented
>
>
>  >> for.
>
>
> =A0
>
>
> ?
>
>

Well if there is no strong reason for:
- using the Admin Status instead,
or
- not using one bit of the Session Attribute object

we would prefer to keep this part unchanged.

>
> >> In section 5.3.2
>
>
> >> - The link (sub-code=3D7) or the node (sub-code=3D8) MUST be
>
>
> >>=A0 locally registered for further reference (the TE database must
>
>
> >> =A0be updated)
>
>
> >>
>
>
> >> What does "the TE database must be updated" mean? Are you saying=20
> that
>
>
> >> the TED is now built from information flooded by the IGP *and* by
>
>
>  >> information fed back from signaling? If so (and I don't approve!)=20=

> then
>
>
> >> you must define what happens when you receive a new LSA for the
>
>
> >> specific link that contradicts the information signaled. There is a
>
>
> >> strong argument that says that *the* method we use for building the
>
>
> >> TED is IGP flooding - if this mechanism doesn't provide you with =
the
>
>
> >> information you need, then you should propose extensions to the =
IGP,
>
>
> >> not hook the information onto signaling.
>
>
>
> >Let me sightly disagree here. I'm fine to not mention this since this
>
>
> >may be implementation specific. That said, I do think that this is
>
>
> >highly desirable (in combination with timer-based mechanism) so as to
>
>
>  >speed convergence. Typically, upon receiving a PathErr message it=20
> does
>
>
> >make sense to first update your TED or the head-end will keep trying
>
>
> >the same path until an LSA/LSP get received. In many networks, such
>
>
> >optimization is definitely required to speed up the TE LSP rerouting.
>
>
>  I really disagree (more than slightly :-)
>
>
> =A0
>
>
> It is absolutely OK to say that the failed/going-oos link/node can be=20=

> supplied to the path computation component as an exclusion. This=20
> applies to the recomputation of the failed LSP.
>
>
> =A0
>
>
> It is very suspect to say that you will update the TED. This would=20
> apply to the computation of new LSP *only*

no, no ... see below.

> by the LSR that happens to be the ingress for the failed LSP. How do=20=

> you know that the next LSP computed will be computed at that LSR?
>
>
> =A0
>
>
> For this procedure to have any realistic meaning, you would want the=20=

> information to reach all computation points, and the signaling=20
> protocol should not do this.
>
>
> =A0
>
>
> Certainly, if you cite "rapid convergence", we will have to convince=20=

> the IGP WGs and the ADs that it is correct to distribute routing=20
> information using the signaling protocol, and not to make changes to=20=

> the IGP as necessary.
>
>

I'm certainly *not* suggesting to rely on signaling to populate the=20
TED. All I'm saying (and without this, most deployed TE networks would=20=

have serious issues in term of convergence upon link failure) is that=20
an LSR receiving a PERR should prune momentarily (timer-based) the=20
failed network element from its TED before recomputing a new TE LSP=20
path. If you have an issue with the formulation, I can suggest:

- The link (sub-code=3D7) or the node (sub-code=3D8) SHOULD be locally=20=

registered for further reference so as to avoid re-using the link to=20
compute in subsequent path computation (at least for some period of=20
time until the TED is updated by the routing protocol).

OR

I can simple remove that text since this is implementation specific and=20=

not directly related to the protocol itself.

> =A0
>
>
> Again, I would like to refer you to the crankback draft which handles=20=

> this issue at ingress and transit computation points.
>
>

This is orthogonal to crankback.

> =A0
>
>
> >> OTOH it may be that all you mean is that the Session state should =
be
>
>
> >> updated to indicate the link or node that is being shut down so =
that
>
>
> >> later recomputation can avoid this link. In this case, I suggest =
you
>
>
> >> refer to the CCAMP crankback draft.
>
>
>
> >Still such update may be beneficial to other TE LSP and is orthogonal
>
>
>  >to the use of crankback?
>
>
> =A0
>
>
> The only way in which it is orthogonal is that it has been specified=20=

> differently.
>
>
> =A0
>
>
> We have three drafts we need to sort out here.
>
>
> - Loose path reoptimization
>
>
> - Crankback
>
>
> - Graceful shutdown
>
>
> =A0
>
>
> It seems to me (humbly ;-) that crankback defines the mechanisms for=20=

> reporting failed resources during LSP setup or after the LSP is=20
> established. It specifies the procedures by which various LSRs may=20
> attempt to reroute.
>
>

The term "various LSRs" is key indeed whereas this ID exclusively=20
relies on head-end reroute.

> =A0
>
>
> Graceful shutdown specifies procedures for withdrawing resources so=20
> that LSPs are moved using make-before-break before a resource is set=20=

> oos. This uses existing routing and signaling procedures, but=20
> introduces new error codes so that we can distinguish graceful=20
> shutdown from failure cases.
>
>
> =A0
>
>
> Loose path reoptimization essentially defines how an ingress may=20
> request information about potential reoptimization, and how an LSR may=20=

> report potential reoptimization. The former is, of course, new=20
> procedures. The latter is new error codes.
>
>
> =A0
>
>
> I think I recall that you agreed that the local maintenance stuff=20
> should move out of the Loose Path Reoptimization draft [did I make=20
> that up?] in which case, the discussion we are having applies only to=20=

> the split between crankback and graceful shutdown.
>

In other words, you'd be happy with the removal of the maintenance=20
procedure from this ID, right ?
That said, all the procedure are identical, so why not keeping the=20
paragraph that suggests to cope with maintenance since this certainly=20
requires a head-end reopt ?

>
> =A0
>
>
> >> In section 5.3.2
>
>
> >> - ... Note that in the case of TE LSP
>
>
> >>=A0 spanning multiple administrative domains, it may be desirable
>
>
> >>=A0 for the boundary LSR to modify the RSVP PathError message and
>
>
> >> =A0insert its own address for confidentiality reason.
>
>
> >>
>
>
> >> Yes. Good point, but doesn't the error code also need to change?
>
>
> >> Otherwise it will appear that the border node is the node being=20
> taken
>
>
> >> oos.
>
>
> >
>
>
> >If you agree with this argument I would vote for keeping the same=20
> error
>
>
> >code since this would not change the action taken by the head-end.
>
>
> =A0
>
>
> Note that=A0this debate needs to be split for reoptimization and=20
> graceful shutdown. [Increasingly I hope I did hear you say you would=20=

> remove all graceful=A0shutdown text from this draft!]
>
>
> But absolutely it would...
>
>
> =A0
>
>
> =A0=A0=A0=A0AS1=A0=A0=A0=A0 :=A0=A0=A0 AS2=A0=A0
>
>
> =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0 :
>
>
> A---.....---B---D-------Z
>
>
> =A0=A0=A0=A0=A0=A0=A0=A0 \=A0 :\ /=A0=A0=A0=A0=A0=A0 /
>
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0 \ :=A0E=A0=A0=A0=A0=A0=A0 /
>
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0\:=A0=A0=A0=A0=A0=A0=A0 /
>
>
>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0C---..../
>
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0:
>
>
> Graceful shutdown...
>
>
> Link BD wants to go out of service.
>
>
> B needs to report this to A so that there is a make-before-break=20
> resignaling.
>
>
> B substitutes its address in the PathErr.
>
>
> A assumes B is not healthy and routes through C (very sub-optimal).
>
>
> A should have resignaled through B and allowed B to route via E.
>
>

In case of link oos, for inter-domain the head-end does not have any=20
idea of what is the best strategy to apply because of its lack of=20
visibility ! You can draw two topologies for which the best strategy=20
will either be to reroute along the same ABR or via another ABR. We=20
know other path computation techniques to sort this out, should the=20
shortest path be required ....

> =A0
>
>
> Reoptimization...
>
>
> LSP is via E. Link BD comes up.
>
>
> B needs to signal simply "reoptimize".
>
>
> Since B will do the recomputation, the PathErr can safely carry its=20
> address.
>
>

I think that in both cases, the issue is identical. Regardless, of the=20=

address carried in the PERR, the head-end cannot determine what is the=20=

"more optimal" choice with such path computation technique. Note that=20
an implementation may try multiple alternatives.

> =A0
>
>
> >> Section 6
>
>
> >>
>
>
> >> Need to describe the processing by an LSR that does not understand=20=

> the
>
>
> >> new flag (rather than understand it but not support it). Note that=20=

> you
>
>
>  >> cannot define the behavior of legacy LSRs in this draft, so you=20
> must
>
>
> >> reference behavior defined in some other document.
>
>
> >>
>
>
> >> Ditto the new error code.
>
>
> >
>
>
> >Unfortunately I do not think that RFC3209 specifies the behavior of a
>
>
> >node receiving a SESSION ATTRIBUTE flag that it does not understand=20=

> ...
>
>
> >An implementation should then just ignore such flag if it does not
>
>
> >understand it.
>
>
> =A0
>
>
> You are correct. This is one of the joys in our life.
>
>

I know ;-)

>  =A0
>
>
> But since nothing is stated, there is a high risk that your new flag=20=

> will be zeroed out by a transit LSR. Oh dear; does that mean that your=20=

> extensions cannot be guaranteed to work unless the whole network is=20
> upgraded?
>
>

Hey not at all ... in fact, unless some mid-point LSR does weird things=20=

on flags that they do not understand because some procedure have not=20
been documented, this only requires partial network upgrades. Quite=20
frankly since this is not likely to happen ...

> =A0
>
>
> So you need to make some statement. (Or perhaps you'd like to write a=20=

> BCP for 3209?)
>
>

Ah, I was feeling the suggestion ;-) ... Along these lines, if we had=20
to write BCP for all the non-specified behavior, I'm afraid we would=20
have to write quite a few.
If the WG think that this may be an potential issue that must be=20
documented I would volunteer but I could bet a few beers ;-) that=20
existing implementations will just do the right things.

>
>
> >>=A0Question...
>
>
> >>
>
>
> >> How does the process of unsolicited notification (of a potential
>
>
>  >> better path rather than of a link going oos) avoid thrashing=20
> races? As
>
>
> >> a very simple example, consider the following n/w.
>
>
> >>
>
>
> >> <-A1-> <--A0-> <-A2->
>
>
> >> A-----B=A0=A0=A0=A0=A0=A0 C-----D
>
>
> >>=A0=A0=A0=A0=A0=A0=A0|=A0=A0=A0=A0=A0=A0 |
>
>
> >>=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 |
>
>
> >> E-----F---G---H-----I
>
>
> >>
>
>
> >> Set up two LSPs AI and ED using EROs {A,B(L),H(L),I} and
>
>
> >> {E,F(L),C(L),D} producing paths ABFGHI and EFGHCD.
>
>
> >>
>
>
> >> Now install a *low* bandwidth link BC capable of carrying either =
but
>
>
> >> not both LSPs. Both B and F will notice that the LSPs entering A0
>
>
> >> through them can be re-optimized and will report the fact to A and =
E
>
>
> >> respectively.
>
>
>
> >note that if the link is a "low" bw link, it is unlikely that B and F
>
>
> >will report a better path but yes that could happen depending on the
>
>
> >IGP links costs indeed.
>
>
> =A0
>
>
> Well, Let us assume that all links are 10G except BC which is 9.8G.=20
> Let us assume that the LSPs are 5G each...
>
>
>
> >> Both A and E will attempt mb4b, but (of course) only one will=20
> succeed.
>
>
>  >> In a small network, this is not a big deal, but in a large network
>
>
> >> with a lot of LSPs this is clearly a waste of processing and will
>
>
>  >> cause a degree of network thrash maybe only in the control plane,=20=

> but
>
>
> >> maybe in the data plane if a lower priority LSP is re-routed first.=20=

> In
>
>
> >> fact, this scenario can cause significant disruption in the data=20
> plane
>
>
> >> as the re-routed LSP will be preempted and could have been
>
>
> >> successfully left in its original place.
>
>
> >
>
>
> >Indeed, but this is no different that any other reoptimization=20
> scenario
>
>
>  >in a single area. If for example, a link is restored within an area
>
>
>  >that could offer a potentially more optimal path to a large number =
of
>
>
>  >TE LSPs, there could be race conditions indeed. This is usually=20
> sorted
>
>
>  >out by using jittered reoptimization at the head-end.
>
>
> =A0
>
>
> Sure. In a single domain you can apply sensible and rational=20
> reoptimization centrally. This is relatively trivial and works well=20
> because:
>
>
> - repotimization of one LSP at a time is bound to lead to
>
>
>  =A0 relatively poor results
>
>
> - reoptimization is not time-critical
>
>

well the latter is quite arguable ;-)

> Note that it is very important that an operation like reoptimization=20=

> should not lead to LSPs being dropped.
>
>
>  [SNIP]
>
>
>
> >> Thus I would suggest removing the unsolicited notification of
>
>
>  >> reoptimization opportunities (while retaining the unsolicited
>
>
>  >> notification of links going oos) or requiring that the policy be
>
>
>  >> timer-based not event triggered.
>
>
> >
>
>
> >We would definitely prefer to keep this mode. Implementation could=20
> just
>
>
> >activate the function for *some* sensitive LSP + combined with with
>
>
> >jittered reoptimization but such notification is desirable to quickly
>
>
> >take advantage of a newly restored link.
>
>
> =A0
>
>
> OK, that's interesting.
>
>
> So I didn't see any descripition of processing rules for when 25:6 is=20=

> received. I (flasely) assumed that the text for 25:7 and 25:8 applied,=20=

> but clearly it doesn't. Perhaps you'd like to add some processing=20
> thoughts for 25:6?
>
>

Well, there are a multitude of options both in term of implementations=20=

*and* parameters settings ... so I would prefer to not elaborate too=20
much here on implementation specific details. The aim of the draft is=20
for the head-end to get notified on the existence of a more desirable=20
path. The head-end behavior upon such notification is a bit out of the=20=

scope.

Hope you're ok with this and if so I'll repost the new rev.

Cheers, and thanks for your detailed comments.

JP.

> =A0
>
>
> Cheers,
>
>
> Adrian
>
>
 =20
 =20=

--Apple-Mail-1-281493736
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
	charset=ISO-8859-1

Hi Adrian,


On Jan 29, 2005, at 9:59 AM, Adrian Farrel wrote:


<excerpt><fixed><smaller><smaller><x-tad-smaller>Thanks JP (and thanks
for the rigour of tracking down all of the points =
raised).</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=A0

=
<fixed><smaller><smaller><x-tad-smaller>[SNIPPED]</x-tad-smaller></smaller=
></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>>> It seems to me that this
draft is applicable to a strict ERO where one =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> of the hops is a
non-specific abstract node such as an AS number. This =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >> is made clear in section
2, but the Abstract and Introduction (yeah, =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> and also the title and
draft name) do not adequately expose this fact. =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> But, further, the
Introduction talks only about reoptimization without =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> any mention of loose hops
or abstract nodes. Thus the draft =
is</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >> schizoid to the third
degree - is this loose path =
reoptimization,</x-tad-smaller></smaller></smaller></fixed></excerpt><exce=
rpt>



<fixed><smaller><smaller><x-tad-smaller> >> reoptimization of loose
and non-specific abstract nodes, or general =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> reoptimization? The draft
needs to be consistent and =
clear.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>></x-tad-smaller></smaller></small=
er></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>Agree, the following
definition has been adopted throughout the =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>document: "A loosely routed
LSP is defined as an LSP that follows a =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>path that contains at least
one loose hop or a strict (abstract node) =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>>hop"</x-tad-smaller></smaller></s=
maller></fixed></excerpt><excerpt>



=A0

<fixed><smaller><smaller><x-tad-smaller>So, to be clear, you are only
interested in the reoptimization of such "loosely routed =
LSPs".</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=A0

<fixed><smaller><smaller><x-tad-smaller>But note RFC =
3209...</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0 An abstract =
node</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0 is a group of nodes whose
internal topology is opaque to the =
ingress</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0 node of the LSP.=A0 An
abstract node is said to be simple if =
it</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0 contains only one =
physical
node.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>So your definition is not
quite accurate since a "strict (abstract node) hop" includes a strict
simple abstract =
node.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=A0

<fixed><smaller><smaller><x-tad-smaller>How =
about:</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0 A loosely routed LSP is
defined as one that does not contain a =
full</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0 =A0explicit route =
identifying
each LSR along the path of the LSP =
at</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> =A0=A0 the time it is signaled =
by
the ingress LSR. Such an LSP is =
signaled</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0 with no ERO, with an ERO
that contains at least one loose hop, =
or</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0with an ERO that =
contains
an abstract node that is not a =
simple</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0abstract node (that is, =
an
abstract node that identifies more =
than</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0 one =
LSR).</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

Good suggestion, thanks.


<excerpt>=A0

<fixed><smaller><smaller><x-tad-smaller>>I guess that the document
title can remain unchanged considering that a =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>loose path also includes the
case of a path where at least one hop is =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>an abstract =
node.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=A0

<fixed><smaller><smaller><x-tad-smaller>Following the above
definition, that is true. Just check that the defintion appears early
in the Introduction (and maybe in the =
Abstract).</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




</excerpt>

Sure.


<excerpt>

<fixed><smaller><smaller><x-tad-smaller>>> Section 2 states that an
ERO expansion is either up to the next loose =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> hop or to the destination.
But, in fact, the ERO expansion may also be =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> any partial fragment
towards either of these targets (including next =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> hop resolution). I suggest
re-wording this paragraph to list (as =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> bullets) what an ERO might
contain, and in a separate list, what =
the</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >> computation might =
produce.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>></x-tad-smaller></smaller></small=
er></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>We listed in this paragraph
the most usual case of ERO expansion. If =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>you're ok with this,
elaborating further on ERO expansion is out of the =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>scope of this =
document.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>"Most usual" is subjective.
Consider nested =
domains.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>But I'm not too bothered about
this particular issue, so leave the =
text.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> Section =
4.1</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>>></x-tad-smaller></smaller></smal=
ler></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> I'm not comfortable with
the Session Attributes toggling like this. =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> This type of function is
what the Admin Status object was =
invented</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >> =
for.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>?</x-tad-smaller></smaller></small=
er></fixed></excerpt><excerpt>



</excerpt>

Well if there is no strong reason for:

- using the Admin Status instead,

or

- not using one bit of the Session Attribute object


we would prefer to keep this part unchanged.


<excerpt>

<fixed><smaller><smaller><x-tad-smaller>>> In section =
5.3.2</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> - The link (sub-code=3D7) or
the node (sub-code=3D8) MUST =
be</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>>=A0 locally registered for
further reference (the TE database =
must</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> =A0be =
updated)</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>>></x-tad-smaller></smaller></smal=
ler></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> What does "the TE database
must be updated" mean? Are you saying that =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> the TED is now built from
information flooded by the IGP *and* =
by</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >> information fed back from
signaling? If so (and I don't approve!) then =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> you must define what
happens when you receive a new LSA for the =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> specific link that
contradicts the information signaled. There is a =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> strong argument that says
that *the* method we use for building the =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> TED is IGP flooding - if
this mechanism doesn't provide you with the =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> information you need, then
you should propose extensions to the IGP, =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> not hook the information
onto =
signaling.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>>Let me sightly disagree here.
I'm fine to not mention this since this =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>may be implementation
specific. That said, I do think that this is =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>highly desirable (in
combination with timer-based mechanism) so as =
to</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >speed convergence.
Typically, upon receiving a PathErr message it does =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>make sense to first update
your TED or the head-end will keep trying =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>the same path until an
LSA/LSP get received. In many networks, such =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>optimization is definitely
required to speed up the TE LSP =
rerouting.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> I really disagree (more than
slightly =
:-)</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>It is absolutely OK to say
that the failed/going-oos link/node can be supplied to the path
computation component as an exclusion. This applies to the
recomputation of the failed =
LSP.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>It is very suspect to say that
you will update the TED. This would apply to the computation of new
LSP *only*=20

</x-tad-smaller></smaller></smaller></fixed></excerpt>

no, no ... see below.


<excerpt><fixed><smaller><smaller><x-tad-smaller>by the LSR that
happens to be the ingress for the failed LSP. How do you know that the
next LSP computed will be computed at that =
LSR?</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>For this procedure to have any
realistic meaning, you would want the information to reach all
computation points, and the signaling protocol should not do =
this.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>Certainly, if you cite "rapid
convergence", we will have to convince the IGP WGs and the ADs that it
is correct to distribute routing information using the signaling
protocol, and not to make changes to the IGP as =
necessary.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

I'm certainly *not* suggesting to rely on signaling to populate the
TED. All I'm saying (and without this, most deployed TE networks would
have serious issues in term of convergence upon link failure) is that
an LSR receiving a PERR should prune momentarily (timer-based) the
failed network element from its TED before recomputing a new TE LSP
path. If you have an issue with the formulation, I can suggest:


- The link (sub-code=3D7) or the node (sub-code=3D8) SHOULD be locally
registered for further reference so as to avoid re-using the link to
compute in subsequent path computation (at least for some period of
time until the TED is updated by the routing protocol).=20


OR=20


I can simple remove that text since this is implementation specific
and not directly related to the protocol itself.


=
<excerpt><fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smal=
ler></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>Again, I would like to refer
you to the crankback draft which handles this issue at ingress and
transit computation =
points.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

This is orthogonal to crankback.


=
<excerpt><fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smal=
ler></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> OTOH it may be that all you
mean is that the Session state should be =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> updated to indicate the
link or node that is being shut down so that =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> later recomputation can
avoid this link. In this case, I suggest you =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> refer to the CCAMP
crankback =
draft.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>>Still such update may be
beneficial to other TE LSP and is =
orthogonal</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >to the use of =
crankback?</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>The only way in which it is
orthogonal is that it has been specified =
differently.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt=
>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>We have three drafts we need
to sort out =
here.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>- Loose path =
reoptimization</x-tad-smaller></smaller></smaller></fixed></excerpt><excer=
pt>



<fixed><smaller><smaller><x-tad-smaller>- =
Crankback</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>- Graceful =
shutdown</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>It seems to me (humbly ;-)
that crankback defines the mechanisms for reporting failed resources
during LSP setup or after the LSP is established. It specifies the
procedures by which various LSRs may attempt to =
reroute.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

The term "various LSRs" is key indeed whereas this ID exclusively
relies on head-end reroute.


=
<excerpt><fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smal=
ler></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>Graceful shutdown specifies
procedures for withdrawing resources so that LSPs are moved using
make-before-break before a resource is set oos. This uses existing
routing and signaling procedures, but introduces new error codes so
that we can distinguish graceful shutdown from failure =
cases.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>Loose path reoptimization
essentially defines how an ingress may request information about
potential reoptimization, and how an LSR may report potential
reoptimization. The former is, of course, new procedures. The latter
is new error =
codes.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>I think I recall that you
agreed that the local maintenance stuff should move out of the Loose
Path Reoptimization draft [did I make that up?] in which case, the
discussion we are having applies only to the split between crankback
and graceful =
shutdown.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>


</excerpt>

In other words, you'd be happy with the removal of the maintenance
procedure from this ID, right ?

That said, all the procedure are identical, so why not keeping the
paragraph that suggests to cope with maintenance since this certainly
requires a head-end reopt ?


<excerpt>

=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> In section =
5.3.2</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> - ... Note that in the case
of TE LSP</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>>=A0 spanning multiple
administrative domains, it may be =
desirable</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>>=A0 for the boundary LSR to
modify the RSVP PathError message =
and</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> =A0insert its own address for
confidentiality =
reason.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>>></x-tad-smaller></smaller></smal=
ler></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> Yes. Good point, but
doesn't the error code also need to change? =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> Otherwise it will appear
that the border node is the node being taken =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> =
oos.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>></x-tad-smaller></smaller></small=
er></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>If you agree with this
argument I would vote for keeping the same error =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>code since this would not
change the action taken by the =
head-end.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>Note that=A0this debate needs to
be split for reoptimization and graceful shutdown. [Increasingly I
hope I did hear you say you would remove all graceful=A0shutdown text
from this =
draft!]</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>But absolutely it =
would...</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0=A0AS1=A0=A0=A0=A0 :=A0=A0=
=A0 AS2=A0=A0</x-tad-smaller></smaller></smaller></fixed></excerpt><excerp=
t>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0 =
:</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>A---.....---B---D-------Z</x-tad-s=
maller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0=A0=A0=A0=A0=A0 \=A0 :\ =
/=A0=A0=A0=A0=A0=A0 =
/</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =
:=A0E=A0=A0=A0=A0=A0=A0 =
/</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0\=
:=A0=A0=A0=A0=A0=A0=A0 =
/</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0C---..../</x-tad-smaller></smaller></s=
maller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
:</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>Graceful =
shutdown...</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>=




<fixed><smaller><smaller><x-tad-smaller>Link BD wants to go out of
service.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>B needs to report this to A so
that there is a make-before-break =
resignaling.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt=
>



<fixed><smaller><smaller><x-tad-smaller>B substitutes its address in
the =
PathErr.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>A assumes B is not healthy and
routes through C (very =
sub-optimal).</x-tad-smaller></smaller></smaller></fixed></excerpt><excerp=
t>



<fixed><smaller><smaller><x-tad-smaller>A should have resignaled
through B and allowed B to route via =
E.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

In case of link oos, for inter-domain the head-end does not have any
idea of what is the best strategy to apply because of its lack of
visibility ! You can draw two topologies for which the best strategy
will either be to reroute along the same ABR or via another ABR. We
know other path computation techniques to sort this out, should the
shortest path be required ....


=
<excerpt><fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smal=
ler></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>Reoptimization...</x-tad-smaller><=
/smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>LSP is via E. Link BD comes =
up.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>B needs to signal simply
=
"reoptimize".</x-tad-smaller></smaller></smaller></fixed></excerpt><excerp=
t>



<fixed><smaller><smaller><x-tad-smaller>Since B will do the
recomputation, the PathErr can safely carry its =
address.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

I think that in both cases, the issue is identical. Regardless, of the
address carried in the PERR, the head-end cannot determine what is the
"more optimal" choice with such path computation technique. Note that
an implementation may try multiple alternatives.


=
<excerpt><fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smal=
ler></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> Section =
6</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>>></x-tad-smaller></smaller></smal=
ler></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> Need to describe the
processing by an LSR that does not understand the =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> new flag (rather than
understand it but not support it). Note that =
you</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >> cannot define the behavior
of legacy LSRs in this draft, so you must =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> reference behavior defined
in some other =
document.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>>></x-tad-smaller></smaller></smal=
ler></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> Ditto the new error =
code.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>></x-tad-smaller></smaller></small=
er></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>Unfortunately I do not think
that RFC3209 specifies the behavior of a =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>node receiving a SESSION
ATTRIBUTE flag that it does not understand ... =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>An implementation should then
just ignore such flag if it does not =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>understand =
it.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>You are correct. This is one
of the joys in our =
life.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

I know ;-)


<excerpt><fixed><smaller><smaller><x-tad-smaller> =
=A0</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>But since nothing is stated,
there is a high risk that your new flag will be zeroed out by a
transit LSR. Oh dear; does that mean that your extensions cannot be
guaranteed to work unless the whole network is =
upgraded?</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

Hey not at all ... in fact, unless some mid-point LSR does weird
things on flags that they do not understand because some procedure
have not been documented, this only requires partial network upgrades.
Quite frankly since this is not likely to happen ...


=
<excerpt><fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smal=
ler></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>So you need to make some
statement. (Or perhaps you'd like to write a BCP for =
3209?)</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

Ah, I was feeling the suggestion ;-) ... Along these lines, if we had
to write BCP for all the non-specified behavior, I'm afraid we would
have to write quite a few.

If the WG think that this may be an potential issue that must be
documented I would volunteer but I could bet a few beers ;-) that
existing implementations will just do the right things.


<excerpt>


=
<fixed><smaller><smaller><x-tad-smaller>>>=A0Question...</x-tad-smaller></=
smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>>></x-tad-smaller></smaller></smal=
ler></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> How does the process of
unsolicited notification (of a =
potential</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >> better path rather than of
a link going oos) avoid thrashing races? As =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> a very simple example,
consider the following =
n/w.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> <<-A1-> <<--A0-> =
<<-A2-></x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> A-----B=A0=A0=A0=A0=A0=A0 =
C-----D</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>>=A0=A0=A0=A0=A0=A0=A0|=A0=A0=A0=A0=
=A0=A0 |</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>>=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=
=A0=A0 |</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> =
E-----F---G---H-----I</x-tad-smaller></smaller></smaller></fixed></excerpt=
><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>>></x-tad-smaller></smaller></smal=
ler></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> Set up two LSPs AI and ED
using EROs {A,B(L),H(L),I} and =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> {E,F(L),C(L),D} producing
paths ABFGHI and =
EFGHCD.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>>></x-tad-smaller></smaller></smal=
ler></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> Now install a *low*
bandwidth link BC capable of carrying either but =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> not both LSPs. Both B and F
will notice that the LSPs entering A0 =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> through them can be
re-optimized and will report the fact to A and E =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> =
respectively.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerp=
t>




<fixed><smaller><smaller><x-tad-smaller>>note that if the link is a
"low" bw link, it is unlikely that B and F =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>will report a better path but
yes that could happen depending on the =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>IGP links costs =
indeed.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>Well, Let us assume that all
links are 10G except BC which is 9.8G. Let us assume that the LSPs are
5G =
each...</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>>> Both A and E will attempt
mb4b, but (of course) only one will =
succeed.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >> In a small network, this
is not a big deal, but in a large network =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> with a lot of LSPs this is
clearly a waste of processing and =
will</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >> cause a degree of network
thrash maybe only in the control plane, but =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> maybe in the data plane if
a lower priority LSP is re-routed first. In =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> fact, this scenario can
cause significant disruption in the data plane =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> as the re-routed LSP will
be preempted and could have been =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>> successfully left in its
original =
place.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>></x-tad-smaller></smaller></small=
er></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>Indeed, but this is no
different that any other reoptimization =
scenario</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >in a single area. If for
example, a link is restored within an area =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >that could offer a
potentially more optimal path to a large number of =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >TE LSPs, there could be race
conditions indeed. This is usually sorted =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >out by using jittered
reoptimization at the =
head-end.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>Sure. In a single domain you
can apply sensible and rational reoptimization centrally. This is
relatively trivial and works well =
because:</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>- repotimization of one LSP at
a time is bound to lead =
to</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> =A0 relatively poor =
results</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>- reoptimization is not
=
time-critical</x-tad-smaller></smaller></smaller></fixed></excerpt><excerp=
t>



</excerpt>

well the latter is quite arguable ;-)


<excerpt><fixed><smaller><smaller><x-tad-smaller>Note that it is very
important that an operation like reoptimization should not lead to
LSPs being =
dropped.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> =
[SNIP]</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>>> Thus I would suggest
removing the unsolicited notification of =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >> reoptimization
opportunities (while retaining the =
unsolicited</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>=




<fixed><smaller><smaller><x-tad-smaller> >> notification of links
going oos) or requiring that the policy be =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller> >> timer-based not event
=
triggered.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>></x-tad-smaller></smaller></small=
er></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>We would definitely prefer to
keep this mode. Implementation could just =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>activate the function for
*some* sensitive LSP + combined with with =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>jittered reoptimization but
such notification is desirable to quickly =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>>take advantage of a newly
restored =
link.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>



<fixed><smaller><smaller><x-tad-smaller>OK, that's =
interesting.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt=
>



<fixed><smaller><smaller><x-tad-smaller>So I didn't see any
descripition of processing rules for when 25:6 is received. I
(flasely) assumed that the text for 25:7 and 25:8 applied, but clearly
it doesn't. Perhaps you'd like to add some processing thoughts for
25:6?</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

Well, there are a multitude of options both in term of implementations
*and* parameters settings ... so I would prefer to not elaborate too
much here on implementation specific details. The aim of the draft is
for the head-end to get notified on the existence of a more desirable
path. The head-end behavior upon such notification is a bit out of the
scope.


Hope you're ok with this and if so I'll repost the new rev.


Cheers, and thanks for your detailed comments.


JP.


=
<excerpt><fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smal=
ler></smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>Cheers,</x-tad-smaller></smaller><=
/smaller></fixed></excerpt><excerpt>



=
<fixed><smaller><smaller><x-tad-smaller>Adrian</x-tad-smaller></smaller></=
smaller></fixed></excerpt><excerpt>



</excerpt> =20=

--Apple-Mail-1-281493736--



Envelope-to: [e-mail]
Delivery-date: Thu, 03 Feb 2005 13:21:57 +0000
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: "Adrian Farrel" <[e-mail]>, <[e-mail]>
From: JP Vasseur <[e-mail]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Thu, 3 Feb 2005 08:19:39 -0500
To: [e-mail]

Hi Dimitri,

On Jan 30, 2005, at 7:48 AM, [e-mail] wrote:

>
> adrian, concerning the below point:
>
>>>> Question...
>>>>
>>>> How does the process of unsolicited notification (of a potential
>>>> better path rather than of a link going oos) avoid thrashing races? 
>>>> As
>>>> a very simple example, consider the following n/w.
>>>>
>>>> <-A1-> <--A0-> <-A2->
>>>> A-----B       C-----D
>>>>       |       |
>>>>       |       |
>>>> E-----F---G---H-----I
>>>>
>>>> Set up two LSPs AI and ED using EROs {A,B(L),H(L),I} and
>>>> {E,F(L),C(L),D} producing paths ABFGHI and EFGHCD.
>>>>
>>>> Now install a *low* bandwidth link BC capable of carrying either but
>>>> not both LSPs. Both B and F will notice that the LSPs entering A0
>>>> through them can be re-optimized and will report the fact to A and E
>>>> respectively.
>>>
>>> note that if the link is a "low" bw link, it is unlikely that B and F
>>> will report a better path but yes that could happen depending on the
>>> IGP links costs indeed.
>>
>> Well, Let us assume that all links are 10G except BC which is 9.8G. 
>> Let us
>> assume that the LSPs are 5G each...
>>
>>>> Both A and E will attempt mb4b, but (of course) only one will 
>>>> succeed.
>>>> In a small network, this is not a big deal, but in a large network
>>>> with a lot of LSPs this is clearly a waste of processing and will
>>>> cause a degree of network thrash maybe only in the control plane, 
>>>> but
>>>> maybe in the data plane if a lower priority LSP is re-routed first. 
>>>> In
>>>> fact, this scenario can cause significant disruption in the data 
>>>> plane
>>>> as the re-routed LSP will be preempted and could have been
>>>> successfully left in its original place.
>>>
>>> Indeed, but this is no different that any other reoptimization 
>>> scenario
>>> in a single area. If for example, a link is restored within an area
>>> that could offer a potentially more optimal path to a large number of
>>> TE LSPs, there could be race conditions indeed. This is usually 
>>> sorted
>>> out by using jittered reoptimization at the head-end.
>
> and how this is sorted out when there are multiple competing head-ends
> (that may belong to separate domains) ?

race conditions are unavoidable and sorted out upon CAC on Mid-point 
... this has been the case for ever in both intra and inter-area.

Thanks.

JP.

>
>> Sure. In a single domain you can apply sensible and rational
> reoptimization >centrally.
>
> note that this "central" processing is difficult to achieve when 
> multiple
> hea ends do not belong (or are not under the control of a single 
> entity)
>
>> This is relatively trivial and works well because:
>> - repotimization of one LSP at a time is bound to lead to
>>  relatively poor results
>> - reoptimization is not time-critical
>> Note that it is very important that an operation like reoptimization
> should >not lead to LSPs being dropped.
>> [SNIP]
>>
>>>> Thus I would suggest removing the unsolicited notification of
>>>> reoptimization opportunities (while retaining the unsolicited
>>>> notification of links going oos) or requiring that the policy be
>>>> timer-based not event triggered.
>>>
>>> We would definitely prefer to keep this mode. Implementation could 
>>> just
>>> activate the function for *some* sensitive LSP + combined with with
>>> jittered reoptimization but such notification is desirable to quickly
>>> take advantage of a newly restored link.
>>
>> OK, that's interesting.
>> So I didn't see any descripition of processing rules for when 25:6 is
>> received. I (flasely) assumed that the text for 25:7 and 25:8 
>> applied, but
>> clearly it doesn't. Perhaps you'd like to add some processing 
>> thoughts for
>> 25:6?
>>
>> Cheers,
>> Adrian
>



Envelope-to: [e-mail]
Delivery-date: Wed, 02 Feb 2005 13:21:19 +0000
Message-ID: <009401c50929$b94393d0$70cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt 
Date: Tue, 1 Feb 2005 18:40:48 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Jean-Louis,

Thanks for this draft.

A couple of immediate thoughts.

1. What is wrong with using Error Code 23?
2. Will implementations really want to confess to the reason that they are
unable to handle more LSPs? It seems to me that it would be a remarkably
honest implementation that implemented this draft. Isn't it more likely
that the LSR would claim an admission control error?
3. "The head-end should not reroute already established LSPs passing
through the saturated node." Why ever not? Surely this is local policy,
and the ingress may know that the only way to route its new and projected
LSPs is to move some of the existing ones.
4. Why is saturation a good thing to advertise in the IGP? If an LSR
wishes to prevent new LSPs being routed through it, it should withdraw
bandwidth just as it would if the signaling elements of the control plane
had failed.
5. Much of the draft restates default behavior (e.g. what to do when you
receive a Path message). This is interesting information for the reader,
but I am not sure that it is right to present it here.
6. Why does the new Error Codes have three Error Values, but the
Saturation TLV only have one bit defined?
7. Section 5.2. All "MUST" should be "SHOULD" I think.

My main question is why you need this draft. It seems that you can already
achieve all of these features using existing protocol elements. At most
you might want to write a one page BCP to say what a transit or egress LSP
should do when it cannot handle a new LSP because of some internal
resource shortage other than an admission control problem.

Cheers,
Adrian


----- Original Message ----- 
From: "LE ROUX Jean-Louis RD-CORE-LAN"
<[e-mail]>
To: <[e-mail]>
Sent: Tuesday, February 01, 2005 7:21 AM
Subject: TR: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt


Hi all,

We just posted a new draft related to (G)MPLS-TE control plane resource
shortages.
Your comments/feedbacks on this draft are welcome.

Regards,

JL




A New Internet-Draft is available from the on-line Internet-Drafts
directories.


Title : Procedure to handle (G)MPLS-TE control plane
saturation
Author(s) : J. Le Roux, et al.
Filename : draft-leroux-ccamp-ctrl-saturation-00.txt
Pages : 10
Date : 2005-1-31

This document defines extensions to RSVP-TE (Resource Reservation
   Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to
   signal control plane resources saturation, when an LSR runs out of
   control plane resources available to support a new LSP. Such
   notification may serve as trigger for the impacted Head-end LSR to
   take appropriate actions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturation-0
0.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-leroux-ccamp-ctrl-saturation-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:
mailserv at ietf.org.
In the body type:
"FILE
/internet-drafts/draft-leroux-ccamp-ctrl-saturation-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-leroux-ccamp-ctrl-saturation-0
0.txt>
<ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturation-0
0.txt>





Envelope-to: [e-mail]
Delivery-date: Tue, 01 Feb 2005 19:23:27 +0000
Date: Tue, 1 Feb 2005 11:21:05 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: CCAMP 62 agenda
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Time to set the agenda ...

Please send your requests for speaking slots as a REPLY to this email
to Adrian and me (and the list, if you so desire).

The usual caveats apply: no presentations, no long-winded histories,
please get right to the issues.  For new items, start by generating
interest on the mailing list, and if you get on the agenda, by saying
how it fits in the CCAMP charter.

Wesam, Marco: please let us know how much time you need for your usual
slots for ITU SG 15 and SG 13 (L1VPNs) updates.

I've noticed that some IDs address items in the proposed new charter.
In that case, items in the current charter will take precedence, and
the new ones will be handled as time permits.

Thanks,
Adrian and Kireeti



Envelope-to: [e-mail]
Delivery-date: Tue, 01 Feb 2005 09:50:02 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>, "JP Vasseur" <[e-mail]>, <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Tue, 1 Feb 2005 10:48:35 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+aGkgYWRyaWFuLCBzbyBpIGhhdmUgYSBtb3JlIGZ1bmRhbWVudGFsIHF1ZXN0aW9ucy9pc3N1
ZXMgdGhlIE5vdGlmeSByZXF1ZXN0IG9iamVjdCB3YXMgbWVhbnQgdG8gTm90aWZ5IGVudGl0aWVz
IGRpZmZlcmVudCBmcm9tIHRoZSBoZWFkLWVuZCAtIHNvIHdoeSBpcyB0aGlzIG1lY2hhbmlzbSBu
b3QgY29uc2lkZXJlZCB0aGF0IG5vdGlmaWVzIHRoaXMgKG5vdGlmeWluZyBkb21haW4pIGVudGl0
eSBvbiBiZWhhbGYgb2YgdGhlIG90aGVyIGxvY2FsIGRvbWFpbiBub2RlcyB0aGF0IGluIHR1cm4g
d291bGQgbm90aWZ5IHRoZSBoZWFkLWVuZCBMU1Agbm9kZXMgKG5vdGU6IHRoZSBOb3RpZnkgUmVx
dWVzdCBvYmplY3QgcHJvY2Vzc2luZyBoYXMgYmVlbiBleHRlbmRlZCBpbiB0aGUgc2VnbWVudCBy
ZWNvdmVyeSBkb2N1bWVudCB0byB0YWNrbGUgc2ltaWxhciBjYXNlcykgPyA8L1A+PFA+Jm5ic3A7
IDxCUj48QlI+PEZPTlQgU0laRT0yPjxCPiZxdW90O0FkcmlhbiBGYXJyZWwmcXVvdDsgJmx0O2Fk
cmlhbkBvbGRkb2cuY28udWsmZ3Q7PC9CPjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjAxLzMxLzIw
MDUgMDk6NTQgR01UPC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+UGxlYXNlIHJlc3BvbmQgdG8gJnF1
b3Q7QWRyaWFuIEZhcnJlbCZxdW90OzwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9G
T05UPiA8Rk9OVCBTSVpFPTI+RGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRF
TDwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj4mcXVvdDtK
UCBWYXNzZXVyJnF1b3Q7ICZsdDtqdmFzc2V1ckBjaXNjby5jb20mZ3Q7LCAmbHQ7Y2NhbXBAb3Bz
LmlldGYub3JnJmd0OzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxG
T05UIFNJWkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZPTlQgU0laRT0yPlJlOiBXb3JraW5nIEdyb3Vw
IExhc3QgQ2FsbCBkcmFmdC1pZXRmLWNjYW1wLWxvb3NlLXBhdGgtcmVvcHQtPC9GT05UPjxCUj4g
PEJSPjxCUj48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkRpbWl0cmksPEJS
PjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkkgYWdyZWUgd2l0aCB5
b3VyIHBvaW50cywgaGVuY2UgbXkgb3JpZ2luYWwgcXVlc3Rpb25zLjxCUj48L0ZPTlQ+PEJSPjxG
T05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5Ob3RlIHRoYXQgcmVvcHRpbWl6YXRpb24gd2l0
aGluIGEgKnNpbmdsZSogZG9tYWluIGNhbiBiZSBoYW5kbGVkPEJSPiZxdW90O2NlbnRyYWxseSZx
dW90OyB3aXRoIHRoZSBhZHZhbnRhZ2VzIEkgZGVzY3JpYmUuPEJSPjwvRk9OVD48QlI+PEZPTlQg
RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPklmIHRoZXJlIGFyZSBtdWx0aXBsZSBkb21haW5zIGlu
dm9sdmVkIChhcyB5b3UgcG9pbnQgb3V0KSB0aGluZ3MgZ2V0PEJSPm1lc3N5LiBCdXQgbm90ZSB0
aGF0IGl0IGlzIG9ubHkgdGhlIGRvbWFpbiBpbiB3aGljaCByZW9wdGltaXphdGlvbiBpczxCUj5w
b3NzaWJsZSB0aGF0IGlzIGdvaW5nIHRvIGFkdmVydGlzZSBhIHJlb3B0aW1pemF0aW9uIHBvc3Np
YmlsaXR5LiBUaHVzPEJSPnRoaXMgc2luZ2xlIGRvbWFpbiBjYW4gd29yayBvdXQgd2hpY2ggTFNQ
cyB3b3VsZCBiZSBiZXN0IHJlb3B0aW1pemVkLCBhbmQ8QlI+b25seSBub3RpZnkgdGhlIGFwcHJv
cHJpYXRlIGluZ3Jlc3NlcyBhYm91dCB0aGUgc3Vic2V0IG9mIExTUHMuIEluIHRoaXM8QlI+Y2Fz
ZSAoYWdhaW4pIHRoZSBub3RpZnlpbmcgZG9tYWluIHdvdWxkIGJlc3QgbWFrZSB0aGlzIGRlY2lz
aW9uIGluIGE8QlI+JnF1b3Q7Y2VudHJhbGl6ZWQmcXVvdDsgbWFubmVyLjxCUj48L0ZPTlQ+PEJS
PjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5DaGVlcnMsPEJSPkFkcmlhbjxCUj48L0ZP
TlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4tLS0tLSBPcmlnaW5hbCBNZXNz
YWdlIC0tLS0tPEJSPkZyb206ICZsdDtEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZSZn
dDs8QlI+VG86ICZxdW90O0FkcmlhbiBGYXJyZWwmcXVvdDsgJmx0O2FkcmlhbkBvbGRkb2cuY28u
dWsmZ3Q7PEJSPkNjOiAmcXVvdDtKUCBWYXNzZXVyJnF1b3Q7ICZsdDtqdmFzc2V1ckBjaXNjby5j
b20mZ3Q7ICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PEJSPlNlbnQ6IFN1bmRheSwgSmFudWFy
eSAzMCwgMjAwNSAxMjo0OCBQTTxCUj5TdWJqZWN0OiBSZTogV29ya2luZyBHcm91cCBMYXN0IENh
bGwgZHJhZnQtaWV0Zi1jY2FtcC1sb29zZS1wYXRoLXJlb3B0LTxCUj48L0ZPTlQ+PEJSPjxCUj48
Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OzxCUj4mZ3Q7IGFkcmlhbiwgY29uY2Vy
bmluZyB0aGUgYmVsb3cgcG9pbnQ6PEJSPiZndDs8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgUXVlc3Rp
b24uLi48QlI+Jmd0OyAmZ3Q7Jmd0OyZndDs8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgSG93IGRvZXMg
dGhlIHByb2Nlc3Mgb2YgdW5zb2xpY2l0ZWQgbm90aWZpY2F0aW9uIChvZiBhIHBvdGVudGlhbDxC
Uj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBiZXR0ZXIgcGF0aCByYXRoZXIgdGhhbiBvZiBhIGxpbmsgZ29p
bmcgb29zKSBhdm9pZCB0aHJhc2hpbmcgcmFjZXM/PEJSPkFzPEJSPiZndDsgJmd0OyZndDsmZ3Q7
IGEgdmVyeSBzaW1wbGUgZXhhbXBsZSwgY29uc2lkZXIgdGhlIGZvbGxvd2luZyBuL3cuPEJSPiZn
dDsgJmd0OyZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDsmZ3Q7ICZsdDstQTEtJmd0OyAmbHQ7LS1B
MC0mZ3Q7ICZsdDstQTItJmd0OzxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBBLS0tLS1CICZuYnNwOyAm
bmJzcDsgJm5ic3A7IEMtLS0tLUQ8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PEJSPiZndDsgJmd0OyZndDsmZ3Q7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxCUj4mZ3Q7ICZndDsmZ3Q7
Jmd0OyBFLS0tLS1GLS0tRy0tLUgtLS0tLUk8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDs8QlI+Jmd0OyAm
Z3Q7Jmd0OyZndDsgU2V0IHVwIHR3byBMU1BzIEFJIGFuZCBFRCB1c2luZyBFUk9zIHtBLEIoTCks
SChMKSxJfSBhbmQ8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsge0UsRihMKSxDKEwpLER9IHByb2R1Y2lu
ZyBwYXRocyBBQkZHSEkgYW5kIEVGR0hDRC48QlI+Jmd0OyAmZ3Q7Jmd0OyZndDs8QlI+Jmd0OyAm
Z3Q7Jmd0OyZndDsgTm93IGluc3RhbGwgYSAqbG93KiBiYW5kd2lkdGggbGluayBCQyBjYXBhYmxl
IG9mIGNhcnJ5aW5nIGVpdGhlciBidXQ8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgbm90IGJvdGggTFNQ
cy4gQm90aCBCIGFuZCBGIHdpbGwgbm90aWNlIHRoYXQgdGhlIExTUHMgZW50ZXJpbmcgQTA8QlI+
Jmd0OyAmZ3Q7Jmd0OyZndDsgdGhyb3VnaCB0aGVtIGNhbiBiZSByZS1vcHRpbWl6ZWQgYW5kIHdp
bGwgcmVwb3J0IHRoZSBmYWN0IHRvIEEgYW5kIEU8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgcmVzcGVj
dGl2ZWx5LjxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDtub3RlIHRoYXQgaWYgdGhl
IGxpbmsgaXMgYSAmcXVvdDtsb3cmcXVvdDsgYncgbGluaywgaXQgaXMgdW5saWtlbHkgdGhhdCBC
IGFuZCBGPEJSPiZndDsgJmd0OyZndDt3aWxsIHJlcG9ydCBhIGJldHRlciBwYXRoIGJ1dCB5ZXMg
dGhhdCBjb3VsZCBoYXBwZW4gZGVwZW5kaW5nIG9uIHRoZTxCUj4mZ3Q7ICZndDsmZ3Q7SUdQIGxp
bmtzIGNvc3RzIGluZGVlZC48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0O1dlbGwsIExldCB1cyBh
c3N1bWUgdGhhdCBhbGwgbGlua3MgYXJlIDEwRyBleGNlcHQgQkMgd2hpY2ggaXMgOS44Ry4gTGV0
PEJSPnVzPEJSPiZndDsgJmd0O2Fzc3VtZSB0aGF0IHRoZSBMU1BzIGFyZSA1RyBlYWNoLi4uPEJS
PiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBCb3RoIEEgYW5kIEUgd2lsbCBhdHRlbXB0
IG1iNGIsIGJ1dCAob2YgY291cnNlKSBvbmx5IG9uZSB3aWxsPEJSPnN1Y2NlZWQuPEJSPiZndDsg
Jmd0OyZndDsmZ3Q7IEluIGEgc21hbGwgbmV0d29yaywgdGhpcyBpcyBub3QgYSBiaWcgZGVhbCwg
YnV0IGluIGEgbGFyZ2UgbmV0d29yazxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyB3aXRoIGEgbG90IG9m
IExTUHMgdGhpcyBpcyBjbGVhcmx5IGEgd2FzdGUgb2YgcHJvY2Vzc2luZyBhbmQgd2lsbDxCUj4m
Z3Q7ICZndDsmZ3Q7Jmd0OyBjYXVzZSBhIGRlZ3JlZSBvZiBuZXR3b3JrIHRocmFzaCBtYXliZSBv
bmx5IGluIHRoZSBjb250cm9sIHBsYW5lLDxCUj5idXQ8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgbWF5
YmUgaW4gdGhlIGRhdGEgcGxhbmUgaWYgYSBsb3dlciBwcmlvcml0eSBMU1AgaXMgcmUtcm91dGVk
IGZpcnN0LjxCUj5JbjxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBmYWN0LCB0aGlzIHNjZW5hcmlvIGNh
biBjYXVzZSBzaWduaWZpY2FudCBkaXNydXB0aW9uIGluIHRoZSBkYXRhPEJSPnBsYW5lPEJSPiZn
dDsgJmd0OyZndDsmZ3Q7IGFzIHRoZSByZS1yb3V0ZWQgTFNQIHdpbGwgYmUgcHJlZW1wdGVkIGFu
ZCBjb3VsZCBoYXZlIGJlZW48QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsgc3VjY2Vzc2Z1bGx5IGxlZnQg
aW4gaXRzIG9yaWdpbmFsIHBsYWNlLjxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDtJ
bmRlZWQsIGJ1dCB0aGlzIGlzIG5vIGRpZmZlcmVudCB0aGF0IGFueSBvdGhlciByZW9wdGltaXph
dGlvbjxCUj5zY2VuYXJpbzxCUj4mZ3Q7ICZndDsmZ3Q7aW4gYSBzaW5nbGUgYXJlYS4gSWYgZm9y
IGV4YW1wbGUsIGEgbGluayBpcyByZXN0b3JlZCB3aXRoaW4gYW4gYXJlYTxCUj4mZ3Q7ICZndDsm
Z3Q7dGhhdCBjb3VsZCBvZmZlciBhIHBvdGVudGlhbGx5IG1vcmUgb3B0aW1hbCBwYXRoIHRvIGEg
bGFyZ2UgbnVtYmVyIG9mPEJSPiZndDsgJmd0OyZndDtURSBMU1BzLCB0aGVyZSBjb3VsZCBiZSBy
YWNlIGNvbmRpdGlvbnMgaW5kZWVkLiBUaGlzIGlzIHVzdWFsbHkgc29ydGVkPEJSPiZndDsgJmd0
OyZndDtvdXQgYnkgdXNpbmcgaml0dGVyZWQgcmVvcHRpbWl6YXRpb24gYXQgdGhlIGhlYWQtZW5k
LjxCUj4mZ3Q7PEJSPiZndDsgYW5kIGhvdyB0aGlzIGlzIHNvcnRlZCBvdXQgd2hlbiB0aGVyZSBh
cmUgbXVsdGlwbGUgY29tcGV0aW5nIGhlYWQtZW5kczxCUj4mZ3Q7ICh0aGF0IG1heSBiZWxvbmcg
dG8gc2VwYXJhdGUgZG9tYWlucykgPzxCUj4mZ3Q7PEJSPiZndDsgJmd0O1N1cmUuIEluIGEgc2lu
Z2xlIGRvbWFpbiB5b3UgY2FuIGFwcGx5IHNlbnNpYmxlIGFuZCByYXRpb25hbDxCUj4mZ3Q7IHJl
b3B0aW1pemF0aW9uICZndDtjZW50cmFsbHkuPEJSPiZndDs8QlI+Jmd0OyBub3RlIHRoYXQgdGhp
cyAmcXVvdDtjZW50cmFsJnF1b3Q7IHByb2Nlc3NpbmcgaXMgZGlmZmljdWx0IHRvIGFjaGlldmUg
d2hlbjxCUj5tdWx0aXBsZTxCUj4mZ3Q7IGhlYSBlbmRzIGRvIG5vdCBiZWxvbmcgKG9yIGFyZSBu
b3QgdW5kZXIgdGhlIGNvbnRyb2wgb2YgYSBzaW5nbGUgZW50aXR5KTxCUj4mZ3Q7PEJSPiZndDsg
Jmd0OyBUaGlzIGlzIHJlbGF0aXZlbHkgdHJpdmlhbCBhbmQgd29ya3Mgd2VsbCBiZWNhdXNlOjxC
Uj4mZ3Q7ICZndDstIHJlcG90aW1pemF0aW9uIG9mIG9uZSBMU1AgYXQgYSB0aW1lIGlzIGJvdW5k
IHRvIGxlYWQgdG88QlI+Jmd0OyAmZ3Q7ICZuYnNwO3JlbGF0aXZlbHkgcG9vciByZXN1bHRzPEJS
PiZndDsgJmd0Oy0gcmVvcHRpbWl6YXRpb24gaXMgbm90IHRpbWUtY3JpdGljYWw8QlI+Jmd0OyAm
Z3Q7Tm90ZSB0aGF0IGl0IGlzIHZlcnkgaW1wb3J0YW50IHRoYXQgYW4gb3BlcmF0aW9uIGxpa2Ug
cmVvcHRpbWl6YXRpb248QlI+Jmd0OyBzaG91bGQgJmd0O25vdCBsZWFkIHRvIExTUHMgYmVpbmcg
ZHJvcHBlZC48QlI+Jmd0OyAmZ3Q7W1NOSVBdPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsmZ3Q7
Jmd0OyBUaHVzIEkgd291bGQgc3VnZ2VzdCByZW1vdmluZyB0aGUgdW5zb2xpY2l0ZWQgbm90aWZp
Y2F0aW9uIG9mPEJSPiZndDsgJmd0OyZndDsmZ3Q7IHJlb3B0aW1pemF0aW9uIG9wcG9ydHVuaXRp
ZXMgKHdoaWxlIHJldGFpbmluZyB0aGUgdW5zb2xpY2l0ZWQ8QlI+Jmd0OyAmZ3Q7Jmd0OyZndDsg
bm90aWZpY2F0aW9uIG9mIGxpbmtzIGdvaW5nIG9vcykgb3IgcmVxdWlyaW5nIHRoYXQgdGhlIHBv
bGljeSBiZTxCUj4mZ3Q7ICZndDsmZ3Q7Jmd0OyB0aW1lci1iYXNlZCBub3QgZXZlbnQgdHJpZ2dl
cmVkLjxCUj4mZ3Q7ICZndDsmZ3Q7PEJSPiZndDsgJmd0OyZndDtXZSB3b3VsZCBkZWZpbml0ZWx5
IHByZWZlciB0byBrZWVwIHRoaXMgbW9kZS4gSW1wbGVtZW50YXRpb24gY291bGQ8QlI+anVzdDxC
Uj4mZ3Q7ICZndDsmZ3Q7YWN0aXZhdGUgdGhlIGZ1bmN0aW9uIGZvciAqc29tZSogc2Vuc2l0aXZl
IExTUCArIGNvbWJpbmVkIHdpdGggd2l0aDxCUj4mZ3Q7ICZndDsmZ3Q7aml0dGVyZWQgcmVvcHRp
bWl6YXRpb24gYnV0IHN1Y2ggbm90aWZpY2F0aW9uIGlzIGRlc2lyYWJsZSB0byBxdWlja2x5PEJS
PiZndDsgJmd0OyZndDt0YWtlIGFkdmFudGFnZSBvZiBhIG5ld2x5IHJlc3RvcmVkIGxpbmsuPEJS
PiZndDsgJmd0OzxCUj4mZ3Q7ICZndDtPSywgdGhhdCdzIGludGVyZXN0aW5nLjxCUj4mZ3Q7ICZn
dDtTbyBJIGRpZG4ndCBzZWUgYW55IGRlc2NyaXBpdGlvbiBvZiBwcm9jZXNzaW5nIHJ1bGVzIGZv
ciB3aGVuIDI1OjYgaXM8QlI+Jmd0OyAmZ3Q7cmVjZWl2ZWQuIEkgKGZsYXNlbHkpIGFzc3VtZWQg
dGhhdCB0aGUgdGV4dCBmb3IgMjU6NyBhbmQgMjU6OCBhcHBsaWVkLDxCUj5idXQ8QlI+Jmd0OyAm
Z3Q7Y2xlYXJseSBpdCBkb2Vzbid0LiBQZXJoYXBzIHlvdSdkIGxpa2UgdG8gYWRkIHNvbWUgcHJv
Y2Vzc2luZyB0aG91Z2h0czxCUj5mb3I8QlI+Jmd0OyAmZ3Q7MjU6Nj88QlI+Jmd0OyAmZ3Q7PEJS
PiZndDsgJmd0O0NoZWVycyw8QlI+Jmd0OyAmZ3Q7QWRyaWFuPEJSPiZndDs8QlI+Jmd0OzxCUj4m
Z3Q7PEJSPiZndDs8L0ZPTlQ+PC9QPg==



Envelope-to: [e-mail]
Delivery-date: Tue, 01 Feb 2005 07:23:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5082E.B79BA1B8"
Subject: TR: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt 
Date: Tue, 1 Feb 2005 08:21:57 +0100
Message-ID: <[e-mail]>
Thread-Topic: TR: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt 
Thread-Index: AcUILrUPeA5oBJocRnmuYY67Y5tGtA==
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: <[e-mail]>

This is a multi-part message in MIME format.

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

Hi all,

We just posted a new draft related to (G)MPLS-TE control plane resource
shortages.
Your comments/feedbacks on this draft are welcome.

Regards,

JL




A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Procedure to handle (G)MPLS-TE control plane
saturation
	Author(s)	: J. Le Roux, et al.
	Filename	: draft-leroux-ccamp-ctrl-saturation-00.txt
	Pages		: 10
	Date		: 2005-1-31
=09
This document defines extensions to RSVP-TE (Resource Reservation=20
   Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to=20
   signal control plane resources saturation, when an LSR runs out of=20
   control plane resources available to support a new LSP. Such=20
   notification may serve as trigger for the impacted Head-end LSR to=20
   take appropriate actions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturation-0
0.txt

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.


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-00.txt".

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


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE
/internet-drafts/draft-leroux-ccamp-ctrl-saturation-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 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-0
0.txt>
<ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturation-0
0.txt>=20


------_=_NextPart_001_01C5082E.B79BA1B8
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-00.txt </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Courier New">Hi all,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">We just posted a new draft =
related to (G)MPLS-TE control plane resource shortages.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">Your comments/feedbacks on this =
draft are welcome.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">JL</FONT>
</P>
<BR>
<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 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-00.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-1-31</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; signal control =
plane resources saturation, when an LSR runs out of </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; control plane =
resources available to support a new LSP. Such </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; notification may =
serve as trigger for the impacted Head-end LSR to </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; 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-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-saturati=
on-00.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-00.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-00.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-00.txt"><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New =
Roman">&lt;ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat=
uration-00.txt&gt;</FONT></U></A>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5082E.B79BA1B8--