Subject: RE: Draft status updated on alternate CCAMP web page

From: "Ong, Lyndon" <[email-masked]>
Date: Sat, 26 Feb 2005 13:07:38 -0500

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: [email-masked] [mailto:[email-masked]]On
Behalf Of Richard Rabbat
Sent: Thursday, February 24, 2005 10:52 AM
To: 'Adrian Farrel'; [email-masked]
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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Monday, February 21, 2005 10:35 AM
> To: Adrian Farrel; [email-masked]
> 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" <[email-masked]>
> To: <[email-masked]>
> 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
> >
> >
> >
> >
> 
> 
>

---

From: "Yumiko Kawashima" <[email-masked]>
Date: Mon, 28 Feb 2005 20:32:23 +0900

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Ong, Lyndon
Sent: Sunday, February 27, 2005 3:08 AM
To: Richard Rabbat; Adrian Farrel; [email-masked]
Subject: RE: Draft status updated on alternate CCAMP web page

Hi Adrian,

Cheers,

Lyndon

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

Adrian,
Can you add

> > covers personal drafts related to CCAMP.

Delivery-date: Mon, 28 Feb 2005 11:34:45 +0000
From: "Yumiko Kawashima" <[email-masked]>
To: <[email-masked]>
Subject: RE: Draft status updated on alternate CCAMP web page
Date: Mon, 28 Feb 2005 20:32:23 +0900

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Ong, Lyndon
Sent: Sunday, February 27, 2005 3:08 AM
To: Richard Rabbat; Adrian Farrel; [email-masked]
Subject: RE: Draft status updated on alternate CCAMP web page

Hi Adrian,

Cheers,

Lyndon

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

Adrian,
Can you add

> > covers personal drafts related to CCAMP.

Delivery-date: Mon, 28 Feb 2005 00:06:49 +0000
Date: Sun, 27 Feb 2005 16:04:03 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Tomonori TAKEDA <[email-masked]>
cc: Igor Bryskin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: What is happenning to CCAMP WG recharter ?

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

Delivery-date: Sat, 26 Feb 2005 18:09:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Draft status updated on alternate CCAMP web page
Date: Sat, 26 Feb 2005 13:07:38 -0500
From: "Ong, Lyndon" <[email-masked]>
To: "Richard Rabbat" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Adrian,

Cheers,

Lyndon

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

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.

> From: [email-masked]=20
>=20
>=20
>=20
>=20
>=20
> ----- Original Message -----=20
>=20
>=20
> > I have updated http://www.oldog.co.uk/ccamp-drafts.htm to=20
> indicate the
>=20
>=20
>=20

Delivery-date: Sat, 26 Feb 2005 14:00:38 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Igor Bryskin" <[email-masked]>
Subject: GMPLS/ASON Lexicography
Date: Sat, 26 Feb 2005 13:54:28 -0000

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

Delivery-date: Sat, 26 Feb 2005 08:59:44 +0000
Date: Sat, 26 Feb 2005 17:58:15 +0900
To: [email-masked], [email-masked]
From: Tomonori TAKEDA <[email-masked]>
Subject: Updates of L1VPN IDs

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: +81-422-59-7434

Delivery-date: Sat, 26 Feb 2005 07:27:49 +0000
Date: Sat, 26 Feb 2005 16:24:57 +0900
From: Kenji Kumaki <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Subject: Re: Draft status updated on alternate CCAMP web page
Cc: <[email-masked]>

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" <[email-masked]> 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

-- 
Kenji Kumaki <[email-masked]>

Delivery-date: Fri, 25 Feb 2005 05:41:17 +0000
To: [email-masked], [email-masked], [email-masked]
Subject: MPLS/GMPLS Change Process
Reply-To: [email-masked]
Date: Thu, 24 Feb 2005 21:39:47 -0800
From: Bill Fenner <[email-masked]>
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: [email-masked]
Subject: I-D ACTION:draft-andersson-rtg-gmpls-change-01.txt
Date: Tue, 22 Feb 2005 15:50:01 -0500
To: [email-masked]
Reply-to: [email-masked]

	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 
[email-masked] with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-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:
	[email-masked].
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

----- End forwarded message:

Delivery-date: Thu, 24 Feb 2005 18:58:45 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Subject: RE: Draft status updated on alternate CCAMP web page
Date: Thu, 24 Feb 2005 10:51:46 -0800

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.

> From: [email-masked]=20
>=20
>=20
>=20
>=20
>=20
> ----- Original Message -----=20
>=20
>=20
> > I have updated http://www.oldog.co.uk/ccamp-drafts.htm to=20
> indicate the
>=20
>=20
>=20

Delivery-date: Wed, 23 Feb 2005 20:34:33 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 23 Feb 2005 12:28:43 +0000
Date: Wed, 23 Feb 2005 21:27:40 +0900
To: Igor Bryskin <[email-masked]>, [email-masked], [email-masked]
From: Tomonori TAKEDA <[email-masked]>
Subject: Re: What is happenning to CCAMP WG recharter ?
Cc: [email-masked]

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: +81-422-59-7434

Delivery-date: Wed, 23 Feb 2005 11:18:01 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Drafts ready for WG last call
Date: Wed, 23 Feb 2005 11:11:32 -0000

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

Adrian
----- Original Message ----- 
From: "Thomas D. Nadeau" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
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
> >
>
>

Delivery-date: Wed, 23 Feb 2005 11:16:47 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: lmp linkcorrelation error code
Date: Tue, 22 Feb 2005 20:18:00 -0000

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
> > From: <[email-masked]>
> > To: <[email-masked]>
> > 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
>
>
>
>
>

Delivery-date: Wed, 23 Feb 2005 01:31:59 +0000
Date: Wed, 23 Feb 2005 09:31:13 +0800
From: harishm 70229 <[email-masked]>
Subject: Re: lmp linkcorrelation error code
To: [email-masked]
Cc: [email-masked]

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

----- Original Message -----
From: [email-masked]
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
> 
> 
> 
> 
> 

Delivery-date: Tue, 22 Feb 2005 20:38:14 +0000
Cc: <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: Drafts ready for WG last call
Date: Tue, 22 Feb 2005 15:37:10 -0500
To: "Adrian Farrel" <[email-masked]>

	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
>

Delivery-date: Tue, 22 Feb 2005 19:33:00 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Tue, 22 Feb 2005 11:30:54 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: What is happenning to CCAMP WG recharter ?
To: [email-masked], [email-masked]
Cc: [email-masked]

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

Delivery-date: Tue, 22 Feb 2005 09:45:24 +0000
Date: Tue, 22 Feb 2005 10:44:48 +0100 (CET)
Subject: Re: lmp linkcorrelation error code
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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
> From: <[email-masked]>
> To: <[email-masked]>
> 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

Delivery-date: Tue, 22 Feb 2005 09:16:05 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: lmp linkcorrelation error code
Date: Tue, 22 Feb 2005 08:21:11 -0000

Fab,

See section 13.15.

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

Cheers,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
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
>
>
>
>
>
>

Delivery-date: Tue, 22 Feb 2005 07:27:54 +0000
Date: Tue, 22 Feb 2005 08:25:53 +0100 (CET)
Subject: lmp linkcorrelation error code
From: <[email-masked]>
To: <[email-masked]>

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

Delivery-date: Mon, 21 Feb 2005 20:28:21 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 21 Feb 2005 20:27:46 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-rsvp-te-ason-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 21 Feb 2005 20:27:38 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-inter-domain-framework-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-inter-domain-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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 21 Feb 2005 20:27:31 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 21 Feb 2005 20:27:22 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-rsvp-restart-ext-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 21 Feb 2005 20:27:15 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 21 Feb 2005 18:36:39 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: Re: Draft status updated on alternate CCAMP web page
Date: Mon, 21 Feb 2005 18:34:52 -0000

So, I can't type.

(Thanks Jean-Louis)

Adrian

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
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
that
> covers personal drafts related to CCAMP.

Delivery-date: Mon, 21 Feb 2005 18:30:58 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Drafts ready for WG last call
Date: Mon, 21 Feb 2005 14:40:46 -0000

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

Delivery-date: Mon, 21 Feb 2005 16:57:51 +0000
From: "Zafar Ali" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Subject: RE: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Mon, 21 Feb 2005 11:56:16 -0500

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:[email-masked]] 
Sent: Monday, February 21, 2005 7:19 AM
To: Zafar Ali; [email-masked]
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:[email-masked]] <BR><B>Sent:</B> Monday, February 21, =
2005 7:19=20
  AM<BR><B>To:</B> Zafar Ali; [email-masked]<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--

Delivery-date: Mon, 21 Feb 2005 15:03:26 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Date: Mon, 21 Feb 2005 15:02:29 -0000
From: "Philip Crocker" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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:[email-masked]]
Sent: 18 February 2005 00:50
To: Philip Crocker
Cc: [email-masked]; [email-masked]
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

Delivery-date: Mon, 21 Feb 2005 14:27:00 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Zafar Ali" <[email-masked]>, <[email-masked]>
Subject: Re: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Mon, 21 Feb 2005 12:18:57 -0000

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

Delivery-date: Mon, 21 Feb 2005 14:26:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Draft status updated on alternate CCAMP web page
Date: Mon, 21 Feb 2005 12:32:04 -0000

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

Delivery-date: Sun, 20 Feb 2005 20:22:21 +0000
From: "Zafar Ali" <[email-masked]>
To: "'Richard Rabbat'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Subject: RE: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Sun, 20 Feb 2005 12:16:10 -0500

Dear Richard, 

Please see my reply in-line.

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

> [mailto:[email-masked]] On Behalf Of Richard Rabbat
> Sent: Thursday, February 17, 2005 5:35 PM
> To: 'Zafar Ali'; 'Adrian Farrel'; [email-masked]
> 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. 

> > [mailto:[email-masked]] On Behalf Of Zafar Ali
> > Sent: Tuesday, February 15, 2005 10:34 PM
> > 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
> > 
> > > Sent: Tuesday, December 07, 2004 10:39 AM
> > > To: [email-masked]
> > > 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
> > > 
> > > 
> > 
> > 
> 

Delivery-date: Sun, 20 Feb 2005 17:48:45 +0000
From: "Zafar Ali" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Subject: RE: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Sun, 20 Feb 2005 12:45:41 -0500

Dear Adrian, 

Please see my reply in-line. 

Thanks again for your input.

Regards... Zafar

> Sent: Thursday, February 17, 2005 4:01 PM
> To: Zafar Ali; [email-masked]
> 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
> > >
> > >
> >
> >
> 

Delivery-date: Sat, 19 Feb 2005 10:06:23 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
Date: Sat, 19 Feb 2005 09:48:59 -0000

Hi,

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

Thanks,
Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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
> [email-masked] with the word unsubscribe in the body of
the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ccamp-rsvp-te-exclude-route-03.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-ietf-ccamp-rsvp-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.
>

Delivery-date: Sat, 19 Feb 2005 02:37:18 +0000
Date: Sat, 19 Feb 2005 03:34:00 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Igor Bryskin <[email-masked]>
CC:  [email-masked], Arthi Ayyangar <[email-masked]>,  [email-masked]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

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
> From: "dimitri papadimitriou" <[email-masked]>
> To: "Igor Bryskin" <[email-masked]>
> Cc: <[email-masked]>; "Arthi Ayyangar"
> <[email-masked]>; <[email-masked]>
> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>From: "dimitri papadimitriou" <[email-masked]>
>>>>>To: "Igor Bryskin" <[email-masked]>
>>>>>Cc: <[email-masked]>; "Arthi Ayyangar"
>>>>><[email-masked]>; <[email-masked]>
>>>>>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.
>>>>>>>
>>>>>>>From: "dimitri papadimitriou" <[email-masked]>
>>>>>>>To: "Igor Bryskin" <[email-masked]>
>>>>>>>Cc: <[email-masked]>; "Arthi Ayyangar"
>>>>>>><[email-masked]>; <[email-masked]>
>>>>>>>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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>.
>>>>>>>>>
>>>>>>>>
>>>>>>>.
>>>>>>>
>>>>>>
>>>>>.
>>>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>
> 
> 
> .
> 

Delivery-date: Fri, 18 Feb 2005 20:22:02 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-rsvp-te-exclude-route-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-rsvp-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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 18 Feb 2005 13:54:24 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Date: Fri, 18 Feb 2005 08:51:50 -0500

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" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; "Arthi Ayyangar"
<[email-masked]>; <[email-masked]>
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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>From: "dimitri papadimitriou" <[email-masked]>
> >>>To: "Igor Bryskin" <[email-masked]>
> >>>Cc: <[email-masked]>; "Arthi Ayyangar"
> >>><[email-masked]>; <[email-masked]>
> >>>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.
> >>>>>
> >>>>>From: "dimitri papadimitriou" <[email-masked]>
> >>>>>To: "Igor Bryskin" <[email-masked]>
> >>>>>Cc: <[email-masked]>; "Arthi Ayyangar"
> >>>>><[email-masked]>; <[email-masked]>
> >>>>>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
> >>>>>>>>>.
> >>>>>>>.
> >>>>>.
> >>>.
> > .

Delivery-date: Fri, 18 Feb 2005 00:51:31 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Philip Crocker" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Date: Fri, 18 Feb 2005 00:49:36 -0000

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

Delivery-date: Fri, 18 Feb 2005 00:07:47 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Zafar Ali" <[email-masked]>, <[email-masked]>
Subject: Re: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Thu, 17 Feb 2005 21:01:12 -0000

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

Delivery-date: Thu, 17 Feb 2005 22:35:44 +0000
From: "Richard Rabbat" <[email-masked]>
To: "'Zafar Ali'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Subject: RE: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Thu, 17 Feb 2005 14:35:17 -0800

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?

> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Zafar Ali
> Sent: Tuesday, February 15, 2005 10:34 PM
> 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
> > From: [email-masked]=20
> > Sent: Tuesday, December 07, 2004 10:39 AM
> > To: [email-masked]
> > 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
> >=20
> >=20
>=20
>=20

Delivery-date: Thu, 17 Feb 2005 22:34:39 +0000
Date: Thu, 17 Feb 2005 23:33:41 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Igor Bryskin <[email-masked]>
CC:  [email-masked], Arthi Ayyangar <[email-masked]>,  [email-masked]
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
>>>
>>>
>>>
>>>
>>>
>>>From: "dimitri papadimitriou" <[email-masked]>
>>>To: "Igor Bryskin" <[email-masked]>
>>>Cc: <[email-masked]>; "Arthi Ayyangar"
>>><[email-masked]>; <[email-masked]>
>>>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.
>>>>>
>>>>>From: "dimitri papadimitriou" <[email-masked]>
>>>>>To: "Igor Bryskin" <[email-masked]>
>>>>>Cc: <[email-masked]>; "Arthi Ayyangar"
>>>>><[email-masked]>; <[email-masked]>
>>>>>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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>.
>>>>>>>>>
>>>>>>>>
>>>>>>>.
>>>>>>>
>>>>>>
>>>>>.
>>>>>
>>>>
>>>
>>>.
>>>
> 
> 
> 
> 
> .
> 

Delivery-date: Thu, 17 Feb 2005 21:44:01 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Date: Thu, 17 Feb 2005 16:43:14 -0500

Dimitri,

See my comments in line.

Igor

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; "Arthi Ayyangar"
<[email-masked]>; <[email-masked]>
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
> >
> >
> >
> >
> >
> > From: "dimitri papadimitriou" <[email-masked]>
> > To: "Igor Bryskin" <[email-masked]>
> > Cc: <[email-masked]>; "Arthi Ayyangar"
> > <[email-masked]>; <[email-masked]>
> > 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.
> >>>
> >>>From: "dimitri papadimitriou" <[email-masked]>
> >>>To: "Igor Bryskin" <[email-masked]>
> >>>Cc: <[email-masked]>; "Arthi Ayyangar"
> >>><[email-masked]>; <[email-masked]>
> >>>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
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>.
> >>>>>>>
> >>>>>>
> >>>>>.
> >>>>>
> >>>>
> >>>
> >>>.
> >>>
> >>
> >
> >
> > .
> >

Delivery-date: Thu, 17 Feb 2005 20:56:44 +0000
Date: Thu, 17 Feb 2005 21:55:38 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Igor Bryskin <[email-masked]>
CC:  [email-masked], Arthi Ayyangar <[email-masked]>,  [email-masked]
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 ?

> 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
> From: "dimitri papadimitriou" <[email-masked]>
> To: "Igor Bryskin" <[email-masked]>
> Cc: <[email-masked]>; "Arthi Ayyangar"
> <[email-masked]>; <[email-masked]>
> 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.
>>>
>>>From: "dimitri papadimitriou" <[email-masked]>
>>>To: "Igor Bryskin" <[email-masked]>
>>>Cc: <[email-masked]>; "Arthi Ayyangar"
>>><[email-masked]>; <[email-masked]>
>>>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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>.
>>>>>>>
>>>>>>
>>>>>.
>>>>>
>>>>
>>>
>>>.
>>>
>>
> 
> 
> .
> 

Delivery-date: Thu, 17 Feb 2005 19:39:43 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Date: Thu, 17 Feb 2005 14:38:41 -0500

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" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; "Arthi Ayyangar"
<[email-masked]>; <[email-masked]>
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.
> > From: "dimitri papadimitriou" <[email-masked]>
> > To: "Igor Bryskin" <[email-masked]>
> > Cc: <[email-masked]>; "Arthi Ayyangar"
> > <[email-masked]>; <[email-masked]>
> > 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
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>.
> >>>>>
> >>>>
> >>>
> >>>.
> >>>
> >>
> >
> >
> > .
> >
>

Delivery-date: Thu, 17 Feb 2005 18:35:27 +0000
Date: Thu, 17 Feb 2005 19:34:26 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Arthi Ayyangar <[email-masked]>
CC: Igor Bryskin <[email-masked]>,  [email-masked],  [email-masked]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

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

Delivery-date: Thu, 17 Feb 2005 18:21:38 +0000
Date: Thu, 17 Feb 2005 19:20:56 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Arthi Ayyangar <[email-masked]>
CC: Igor Bryskin <[email-masked]>,  [email-masked],  [email-masked]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

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

Delivery-date: Thu, 17 Feb 2005 18:20:08 +0000
Date: Thu, 17 Feb 2005 19:19:02 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Igor Bryskin <[email-masked]>
CC:  [email-masked], Arthi Ayyangar <[email-masked]>,  [email-masked]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

Igor Bryskin wrote:

> dimitri, see in line.
> From: "dimitri papadimitriou" <[email-masked]>
> To: "Igor Bryskin" <[email-masked]>
> Cc: <[email-masked]>; "Arthi Ayyangar"
> <[email-masked]>; <[email-masked]>
> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>.
>>>>>
>>>>
>>>
>>>.
>>>
>>
> 
> 
> .
> 

Delivery-date: Thu, 17 Feb 2005 17:59:53 +0000
Date: Thu, 17 Feb 2005 09:58:57 -0800 (PST)
From: Arthi Ayyangar <[email-masked]>
To: Igor Bryskin <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

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

Delivery-date: Thu, 17 Feb 2005 17:50:53 +0000
Date: Thu, 17 Feb 2005 09:49:30 -0800 (PST)
From: Arthi Ayyangar <[email-masked]>
To: Igor Bryskin <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

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

Delivery-date: Thu, 17 Feb 2005 17:39:55 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Arthi Ayyangar" <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Date: Thu, 17 Feb 2005 12:39:18 -0500

dimitri, see in line.

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; "Arthi Ayyangar"
<[email-masked]>; <[email-masked]>
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
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>.
> >>>
> >>
> >
> >
> > .
> >
>

Delivery-date: Thu, 17 Feb 2005 16:41:21 +0000
Date: Thu, 17 Feb 2005 17:40:21 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Igor Bryskin <[email-masked]>
CC:  [email-masked], Arthi Ayyangar <[email-masked]>,  [email-masked]
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 - 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
>>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>
> 
> 
> .
> 

Delivery-date: Thu, 17 Feb 2005 15:38:53 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Arthi Ayyangar" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Date: Thu, 17 Feb 2005 10:37:41 -0500

Dimitri,
see my comment in line.

Igor

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Arthi Ayyangar" <[email-masked]>;
<[email-masked]>; <[email-masked]>
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
> > From: "Arthi Ayyangar" <[email-masked]>
> > To: <[email-masked]>; <[email-masked]>
> > Cc: <[email-masked]>
> > 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
> > .

Delivery-date: Thu, 17 Feb 2005 13:54:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Date: Thu, 17 Feb 2005 13:54:36 -0000
From: "Philip Crocker" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Adrian,

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

Phil.

> 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
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 17 February 2005 10:29
> To: Philip Crocker; [email-masked]
> Cc: [email-masked]
> 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
>=20

Delivery-date: Thu, 17 Feb 2005 13:48:02 +0000
Date: Thu, 17 Feb 2005 14:47:43 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Igor Bryskin <[email-masked]>
CC: Arthi Ayyangar <[email-masked]>,  [email-masked],  [email-masked]
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
> From: "Arthi Ayyangar" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> 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
>>
> 
> 
> 
> 
> .
> 

Delivery-date: Thu, 17 Feb 2005 13:36:07 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Arthi Ayyangar" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Date: Thu, 17 Feb 2005 08:32:58 -0500

Dimitri, Arthi,
See my comments in line.

Igor

----- Original Message ----- 
From: "Arthi Ayyangar" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
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

Delivery-date: Thu, 17 Feb 2005 12:07:37 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Philip Crocker" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Date: Thu, 17 Feb 2005 10:28:48 -0000

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

Delivery-date: Thu, 17 Feb 2005 02:11:08 +0000
Date: Wed, 16 Feb 2005 18:08:37 -0800 (PST)
From: Arthi Ayyangar <[email-masked]>
To: [email-masked], [email-masked]
cc: "[email-masked]" <[email-masked]>
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 ?

> 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

Delivery-date: Wed, 16 Feb 2005 17:34:29 +0000
Date: Wed, 16 Feb 2005 12:31:44 -0500
To: Arthi Ayyangar <[email-masked]>
From: Alia Atlas <[email-masked]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
Cc: "[email-masked]" <[email-masked]>

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

Delivery-date: Wed, 16 Feb 2005 12:04:22 +0000
Content-class: urn:content-classes:message
Subject: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Date: Wed, 16 Feb 2005 12:01:38 -0000
From: "Philip Crocker" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

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

Delivery-date: Wed, 16 Feb 2005 06:59:21 +0000
Date: Wed, 16 Feb 2005 07:58:56 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Arthi Ayyangar <[email-masked]>
CC:  [email-masked],  "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

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

Delivery-date: Wed, 16 Feb 2005 06:36:43 +0000
From: "Zafar Ali" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Subject: Summary [was: RE: Starting a discussion on graceful shutdown]
Date: Wed, 16 Feb 2005 01:34:26 -0500

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 

> Sent: Tuesday, December 07, 2004 10:39 AM
> To: [email-masked]
> 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

Delivery-date: Wed, 16 Feb 2005 00:34:36 +0000
Date: Tue, 15 Feb 2005 16:33:30 -0800 (PST)
From: Arthi Ayyangar <[email-masked]>
To: [email-masked], [email-masked]
cc: "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

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

Delivery-date: Tue, 15 Feb 2005 23:09:12 +0000
Date: Wed, 16 Feb 2005 00:08:03 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

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.

[email-masked] 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 
> [email-masked] with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-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:
> 	[email-masked].
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

Delivery-date: Tue, 15 Feb 2005 17:19:57 +0000
To: [email-masked]
Subject: Correction: RFC 4003 on GMPLS Signaling Procedure for Egress Control
Cc: [email-masked], [email-masked]
From: [email-masked]
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:    [email-masked]
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

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

...

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

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

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

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

RETRIEVE: rfc
DOC-ID: 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: <[email-masked]>

--OtherAccess--
--NextPart--

Delivery-date: Tue, 15 Feb 2005 14:28:12 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: IPR claim in MRN drafts
Date: Tue, 15 Feb 2005 14:23:53 -0000

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

Delivery-date: Tue, 15 Feb 2005 10:56:05 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Berger, Lou" <[email-masked]>, <[email-masked]>
Subject: Fw: RFC 4003 on GMPLS Signaling Procedure for Egress Control
Date: Tue, 15 Feb 2005 10:47:09 -0000

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

Delivery-date: Tue, 15 Feb 2005 06:14:11 +0000
To: [email-masked]
From: [email-masked]
Date: Mon, 14 Feb 2005 15:46:35 -0800
Cc: [email-masked], [email-masked]
Subject: RFC 4003 on GMPLS Signaling Procedure for Egress Control

--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:    [email-masked]
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

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

...

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

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

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

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

RETRIEVE: rfc
DOC-ID: 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: <[email-masked]>

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

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

--NextPart--

Delivery-date: Mon, 14 Feb 2005 23:51:48 +0000
To: [email-masked]
Subject: RFC 4003 on GMPLS Signaling Procedure for Egress Control
Cc: [email-masked], [email-masked]
From: [email-masked]
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:    [email-masked]
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

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

...

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

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

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

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

RETRIEVE: rfc
DOC-ID: 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: <[email-masked]>

--OtherAccess--
--NextPart--

Delivery-date: Mon, 14 Feb 2005 10:26:27 +0000
Content-class: urn:content-classes:message
Subject: FW: I-D ACTION:draft-davey-ccamp-gmpls-ipv6-if-index-00.txt
Date: Mon, 14 Feb 2005 10:23:24 -0000
From: "Alan Davey" <[email-masked]>
To: <[email-masked]>

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:   +44 20 8366 1177      =20
Fax:   +44 20 8363 1039
Email: [email-masked] =20
Web:   http://www.dataconnection.com=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 10 February 2005 20:45
To: [email-masked]
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
[email-masked] 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:
	[email-masked].
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--

Delivery-date: Fri, 11 Feb 2005 22:02:50 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: GMPLS TE MIB
Date: Fri, 11 Feb 2005 22:02:15 -0000

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

Delivery-date: Fri, 11 Feb 2005 20:22:14 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 11 Feb 2005 15:14:40 +0000
content-class: urn:content-classes:message
Subject: RE: SDH Format
Date: Fri, 11 Feb 2005 09:10:39 -0600
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

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: [email-masked] [mailto:[email-masked]]=20
Sent: Friday, February 11, 2005 7:47 AM
To: [email-masked]; Brungard, Deborah A, ALABS;
[email-masked]
Cc: [email-masked]
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> [email-masked]=20
[mailto:[email-masked]] <BR><B>Sent:</B> Friday, February 11, 2005 =
7:47=20
AM<BR><B>To:</B> [email-masked]; Brungard, Deborah A, ALABS;=20
[email-masked]<BR><B>Cc:</B>=20
[email-masked]<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--

Delivery-date: Thu, 10 Feb 2005 22:08:52 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Early WG schedule for Minneapolis
Date: Thu, 10 Feb 2005 22:08:10 -0000

Hi,

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

This is not yet definitive.

Thanks,
Adrian

Delivery-date: Thu, 10 Feb 2005 20:43:43 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 10 Feb 2005 16:28:42 +0000
content-class: urn:content-classes:message
Subject: RE: FW: Layer 2 Switching Caps LSPs
Date: Thu, 10 Feb 2005 10:27:50 -0600
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Don,

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

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

Hi Dimitri

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

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

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

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

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

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

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

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

Delivery-date: Wed, 09 Feb 2005 23:35:14 +0000
Date: Thu, 10 Feb 2005 00:33:19 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Don Fedyk <[email-masked]>
CC:  [email-masked]
Subject: Re: FW: Layer 2 Switching Caps LSPs

don,

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

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

> 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 
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Saturday, February 05, 2005 11:43 AM
> To: Allan, David 
> Cc: [email-masked]'; [email-masked]'; Shahram
> Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel;
> [email-masked]
> 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" <[email-masked]>
> 02/04/2005 14:32 EST
> 
> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> cc: "[email-masked]'" <[email-masked]>, Shahram Davari
> <[email-masked]>, "Mack-Crane, T. Benjamin"
> <[email-masked]>, David Allan <[email-masked]>,
> Adrian Farrel <[email-masked]>, [email-masked]
> bcc: 
> Subject: RE: Layer 2 Switching Caps LSPs
> 
> 
> 
> OK let me decompose your last response and see if we can bottom this out....
> 
> 
> 
>>(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 
> 
> 
> 
> 
> From: [email-masked]
> [mailto:[email-masked]] 
> Sent: Friday, February 04, 2005 1:34 PM 
> To: Allan, David [CAR:NS00:EXCH] 
> Cc: [email-masked]'; [email-masked]'; Shahram
> Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel;
> [email-masked]
> 
> 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" <[email-masked]> 
> 02/04/2005 09:44 EST 
> 
> To: "[email-masked]'" <[email-masked]>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari
> <[email-masked]>
> 
> cc: "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan
> <[email-masked]>, Adrian Farrel <[email-masked]>,
> [email-masked]
> 
> bcc: 
> Subject: RE: Layer 2 Switching Caps LSPs 
> 
> 
> Dimitri: 
> <snipped> 
>  (but 
> 
>>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: [email-masked] 
>>>[mailto:[email-masked]]On Behalf Of Shahram Davari Sent: 
>>>Thursday, February 03, 2005 6:19 PM To: 
>>>[email-masked]' Cc: Mack-Crane, T. Benjamin; 
>>>[email-masked]; David Allan; Adrian Farrel; 
>>
>>[email-masked] 
>>
>>>Subject: RE: Layer 2 Switching Caps LSPs 
>>>
>>>
>>>Hi Dimitri, 
>>>
>>>Thanks for your response. Please see my comments in-line. 
>>>
>>>-Shahram 
>>>
>>>-----Original Message----- From: [email-masked] 
>>>[mailto:[email-masked]] Sent: Thursday, 
>>
>>February 03, 
>>
>>>2005 5:31 PM To: Shahram Davari Cc: 
>>>[email-masked]'; Mack-Crane, T. Benjamin; 
>>>[email-masked]; David Allan; Adrian Farrel; 
>>
>>[email-masked] 
>>
>>>Subject: RE: Layer 2 Switching Caps LSPs 
>>>
>>>
>>>
>>>sharam, the first issue is that you have to decouple the notion of 
>>>ethernet with bridging, 
>>>
>>>Ethernet networks have 3 main layers: 
>>>
>>>1) PHY = 10/100/1G/10G as explained in 802.3, 
>>>
>>>2) MAC = 802.3 
>>>
>>>3) Bridging = 802.1D 
>>>
>>>Without Bridging layer your device can only have a single port. 
>>>Example is the Ethernet port of your desktop computer. Therefore if 
>>>you want to build an Ethernet network, you need bridging layer. 
>>>
>>>
>>>
>>>the second is that this configuration operation can be automated - 
>>>
>>>But after you have configured your connections (aka VLAN 
>>
>>ports), then 
>>
>>>there is nothing left for GMPS to do. Or are you saying 
>>
>>that the GMPLS 
>>
>>>will do the configuration? 
>>>
>>>however the interesting point you brought in the loop of discussion 
>>>here is "applicability for shared medium" - isn't the PW 
>>
>>solution in 
>>
>>>the same context 
>>>
>>>No, because in PW, the payload (Ethernet) is encapsulated 
>>
>>in another 
>>
>>>layer network (aka MPLS), and is invisible to the 
>>
>>intermediate nodes. 
>>
>>>While in your case there is no encapsulation, and all the 
>>
>>intermediate 
>>
>>>nodes can act on the MAC and VLAN tag. 
>>>
>>>as 1) it can not make an automated usage of a "medium" without 
>>>configuring the tunnels (in our case the tunnels that will 
>>
>>be used to 
>>
>>>carry the ethernet payload e.g. SDH, OTH, etc. if not using 
>>>point-to-point PHY's) but in addition to the present 
>>
>>solution PW also 
>>
>>>requires 2) the provisioning of the PW - something not 
>>
>>needed in the 
>>
>>>present context as terminating points will be directly 
>>
>>accessing the 
>>
>>>"ethernet medium", in brief if such argument is used here it should 
>>>have also been used in the PW context (if not more intensively) 
>>>
>>>another fundamental point, i am also surprised seeing people 
>>>supporting MPLS (which brings a connection-oriented 
>>
>>behaviour to IP) 
>>
>>>wondering about the suitability of using one of the 
>>
>>protocol suite of 
>>
>>>the IETF i.e. GMPLS to bring another (initially) connectionless 
>>>technology to a "connection-oriented" behaviour 
>>>
>>>I don't argue against bringing connection-oriented behavior to 
>>>Ethernet. My concern is the method used to do so. if you had done 
>>>proper Network Interworking (aka, encapsulation or as ITU calls it 
>>>client/server), then there would not be any problem. 
>>
>>However, what you 
>>
>>>are trying to do is to modify Ethernet's control-plane in a 
>>
>>way that 
>>
>>>requires modification to its data-plane behavior. As an 
>>
>>analogy what 
>>
>>>you are doing is like trying to use the IP address as MPLS tag in 
>>>order to make IP connection-oriented. 
>>>
>>>In contrast you could easily change ATM's control-plane to GMPLS 
>>>without any modification to ATM data-plane behavior, because ATM by 
>>>design is connection-oriented, and the VPI/VCI could easily be 
>>>interpreted as GMPLS tags. 
>>>
>>>(even if i do rather prefer the term flow, in the present 
>>
>>context) at 
>>
>>>the end the resulting gain is the same for both 
>>
>>technologies it terms 
>>
>>>of capabilities as application of constraint-based routing 
>>
>>principles 
>>
>>>- is this not at the end what drives mostly all debates in 
>>
>>the (G)MPLS 
>>
>>>galaxy beside VPNs and that was underlying incorporation of 
>>
>>these L2 
>>
>>>technologies as part of the GMPLS protocol architecture 
>>>
>>>thanks, 
>>>
>>>- dimitri. 
>>>
>>>
>>>Shahram Davari <[email-masked]> Sent by: 
>>>[email-masked] 02/03/2005 13:13 PST 
>>>
>>>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T. 
>>>Benjamin" <[email-masked]> cc: [email-masked], 
>>>David Allan <[email-masked]>, Adrian Farrel 
>>><[email-masked]>, [email-masked] bcc: Subject: RE: Layer 2 
>>>Switching Caps LSPs 
>>>
>>>
>>>
>>>
>>>Dimitri, 
>>>
>>>Unfortunately I didn't grasp completely what you are trying 
>>
>>to convey. 
>>
>>>But one thing I know for sure, and that is  "Ethernet is 
>>>Connectionless (CLS)" (like IP) and assumes shared medium, 
>>
>>while GMPLS 
>>
>>>is connection-oriented (CO) and doesn't work in shared medium. Off 
>>>course you could always configure and build an Ethernet 
>>
>>network that 
>>
>>>looks like it is CO (by configuring a max of 2 ports with the same 
>>>VLAN ID in each bridge), and by not using any shared 
>>
>>medium. But then 
>>
>>>who needs GMPLS, when you already have to configure your network by 
>>>other means? 
>>>
>>>-Shahram 
>>>
>>>
>>>From: [email-masked] 
>>>[mailto:[email-masked]] Sent: Thursday, 
>>
>>February 03, 
>>
>>>2005 3:07 PM To: Mack-Crane, T. Benjamin Cc: 
>>
>>[email-masked]; 
>>
>>>[email-masked]; David Allan; Adrian 
>>
>>Farrel; Shahram 
>>
>>>Davari; [email-masked] Subject: RE: 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" <[email-masked]> Sent by: 
>>>[email-masked] 02/03/2005 12:16 CST 
>>>
>>>To: <[email-masked]>, Dimitri 
>>>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" 
>>><[email-masked]> cc: "Adrian Farrel" 
>>
>><[email-masked]>, 
>>
>>>"Shahram Davari" <[email-masked]>, 
>>
>><[email-masked]> 
>>
>>>bcc: Subject: 
>>>RE: Layer 2 Switching Caps LSPs 
>>>
>>>
>>>Dimitri, 
>>>
>>>Can the off-line discussion be summarized for the benefit 
>>
>>of those on  
>>
>>>the list who did not participate?  For me, the draft (and 
>>
>>the current 
>>
>>>discussion on the list) have not clearly articulated the 
>>
>>problem being 
>>
>>>addressed.  If a summary of the conclusions of the off-line 
>>
>>discussion 
>>
>>>will do this, it would be useful. 
>>>
>>>I am also interested to know what is lacking in the current 
>>
>>GMPLS RFCs 
>>
>>>with respect to ATM and Frame Relay support that necessitates 
>>>including them in this new draft (presumably this is a part of the 
>>>problem to be solved). 
>>>
>>>Regards, Ben 
>>>
>>>
>>>
>>>>-----Original Message----- From: [email-masked] 
>>>>[mailto:[email-masked]] On 
>>>
>>>Behalf 
>>>
>>>
>>>>Of dimitri papadimitriou Sent: Thursday, January 27, 2005 6:35 PM 
>>>>To: David Allan Cc: 'Adrian Farrel'; 'Shahram Davari'; 
>>>>[email-masked] Subject: Re: Layer 2 Switching Caps LSPs 
>>>>
>>>>dave - there was a lengthy off-line discussion suggested by the 
>>>>chairs intended to explain you the scope of the draft and its 
>>>>relatioship 
>>>
>>>with 
>>>
>>>
>>>>the ethernet data plane (after the question you raised 
>>
>>during the f2f 
>>
>>>>meeting) - this has been done and we have explained (via a lengthy 
>>>>exchange of e-mails) that this document and so the use of gmpls to 
>>>>control ethernet frame flows, is not targeting control of bridged 
>>>>ethernet environments - if this is not clear from the current 
>>>>document introduction we would have also to work on this 
>>
>>part of the 
>>
>>>>document - therefore, the below reference to MSTP is not in the 
>>>>current scope; on the other side, the use of the term "VLAN label" 
>>>>has created some confusion; therefore, in a next release i will 
>>>>simply refer to a 
>>>
>>>"label" 
>>>
>>>
>>>>of 32 bits (unstructured) because the intention was (and 
>>
>>still is) to 
>>
>>>>find an easy way to map the control of the ethernet frame flows on 
>>>
>>>each 
>>>
>>>
>>>>device they traverses without making any assumption on how 
>>
>>this flow 
>>
>>>is 
>>>
>>>
>>>>processed inside each node at the data plane level (note: on label 
>>>>values, RFC 3946 took an equivalent approach - for circuits - where 
>>>> sonet/sdh multiplexing structures have been used to create unique 
>>>>multiplex entry names i.e. labels - this concept is here applied 
>>>>for "virtual" circuits), so, if the working group is willing to 
>>>>enter into 
>>>
>>>a 
>>>
>>>
>>>>data plane oriented discussion to clarify the behaviour(s) 
>>
>>onto which 
>>
>>>>the present approach would be potentially applicable this is fine 
>>>>with me as long as we are within the scope of the initial 
>>
>>motivations 
>>
>>>>thanks, - dimitri. 
>>>>
>>>>David Allan wrote: 
>>>>
>>>>
>>>>>Hi Adrian: 
>>>>>
>>>>>Your suggestion is in a way reasonable but with the caveat that in 
>>>
>>>IEEE 
>>>
>>>
>>>>>terms, a bridging topology is currently all VLANs (802.1Q single 
>>>>
>>>>spanning 
>>>>
>>>>
>>>>>tree) or partitioned into specific ranges (I believe 64 in 802.1s 
>>>>>
>>>>
>>>>although I 
>>>>
>>>>
>>>>>do not claim to be an expert). 
>>>>>
>>>>>If the PEs were to implement a bridge function and we were using 
>>>
>>>GMPLS 
>>>
>>>
>>>>to 
>>>>
>>>>
>>>>>interconnect them, then the control plane should be identifying 
>>>
>>>either 
>>>
>>>
>>>>all 
>>>>
>>>>
>>>>>VLANs (single spanning tree, which I beleive the draft covers by 
>>>>
>>>>referring 
>>>>
>>>>
>>>>>simply to Ethernet port) or a VLAN range to be associated with the 
>>>
>>>LSP 
>>>
>>>
>>>>>consistent with 802.1s if it is to operate to interconnect bridges 
>>>>
>>>>defined 
>>>>
>>>>
>>>>>by the IEEE... 
>>>>>
>>>>>I suspect assuming any other behavior (e.g. LSP for single VLAN 
>>>>>tag) 
>>>>
>>>>would 
>>>>
>>>>
>>>>>go outside the boundary of what is currently defined...so 
>>
>>alignment 
>>
>>>with 
>>>
>>>
>>>>>802.1s IMO would be a minimum requirement if we are to consider 
>>>
>>>carrying 
>>>
>>>
>>>>>VLAN information in GMPLS signalling.... 
>>>>>
>>>>>cheers Dave 
>>>>>
>>>>>You wrote.... 
>>>>>
>>>>>
>>>>>
>>>>>>Hi, 
>>>>>>
>>>>>>The authors of the draft might like to clarify for the list 
>>>>>>exactly what data plane operations they are suggesting. To me 
>>>>>>it seems possible that the draft is proposing VLAN ID 
>>>>>>*swapping*. But an alternative is that the VLAN ID is used as a 
>>>>>>label, but that the same label is used for the full length of 
>>>>>>the LSP. 
>>>>>>
>>>>>>Adrian 
>>>>>
>>>>>
>>>>>
>>>>>. 
>>>>>
>>>
>>>============================================================ The 
>>>information contained in this message may be privileged and 
>>>confidential and protected from disclosure. If the reader of this 
>>>message is not the intended recipient, or an employee or agent 
>>>responsible for delivering this message to the intended 
>>
>>recipient, you 
>>
>>>are hereby notified that any reproduction, dissemination or 
>>>distribution of this communication is strictly prohibited. 
>>
>>If you have 
>>
>>>received this communication in error, please notify us 
>>
>>immediately by 
>>
>>>replying to the message and deleting it from your computer. 
>>
>>Thank you. 
>>
>>>Tellabs ============================================================ 
>>>
>>>
>>
>>
> 
> 
> .
> 

Envelope-to: [email-masked]
Delivery-date: Wed, 09 Feb 2005 21:11:46 +0000
Message-ID: <B258A372CEA20246A363BB86753DB5360251E589@zrtphxm2>
From: "Don Fedyk" <[email-masked]>
To: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Saturday, February 05, 2005 11:43 AM
To: Allan, David 
Cc: [email-masked]'; [email-masked]'; Shahram
Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel;
[email-masked]
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" <[email-masked]>
02/04/2005 14:32 EST

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

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

> (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: [email-masked]
[mailto:[email-masked]] 
Sent: Friday, February 04, 2005 1:34 PM 
To: Allan, David [CAR:NS00:EXCH] 
Cc: [email-masked]'; [email-masked]'; Shahram
Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel;
[email-masked]

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" <[email-masked]> 
02/04/2005 09:44 EST 

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

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

bcc: 
Subject: RE: Layer 2 Switching Caps LSPs 

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

Delivery-date: Wed, 09 Feb 2005 20:25:24 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-inter-domain-rsvp-te-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 09 Feb 2005 18:42:32 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Igor Bryskin" <[email-masked]>, "Richard Rabbat" <[email-masked]>
Subject: Re: I-D ACTION:draft-bryskin-ccamp-gmpls-ason-lexicography-00.txt
Date: Wed, 9 Feb 2005 18:37:18 -0000

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" <[email-masked]>
To: <[email-masked]>
Cc: "Igor Bryskin" <[email-masked]>
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
>
> From: <[email-masked]>
> To: <[email-masked]>
> 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
> > [email-masked] with the word unsubscribe in the body of
> the message.
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-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:
> > [email-masked].
> > 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/i-d-announce
> >
>
>
>
>

Delivery-date: Wed, 09 Feb 2005 09:46:04 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Igor Bryskin" <[email-masked]>
Subject: Fw: I-D ACTION:draft-bryskin-ccamp-gmpls-ason-lexicography-00.txt
Date: Wed, 9 Feb 2005 09:42:00 -0000

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: <[email-masked]>
To: <[email-masked]>
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
> [email-masked] with the word unsubscribe in the body of
the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-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:
> [email-masked].
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>

Delivery-date: Wed, 09 Feb 2005 07:35:24 +0000
Date: Wed, 09 Feb 2005 08:33:52 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Shahram Davari <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, David Allan <[email-masked]>,  "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>,  Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: Layer 2 Switching Caps LSPs

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

Delivery-date: Tue, 08 Feb 2005 21:19:12 +0000
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: David Allan <[email-masked]>, "[email-masked]'" <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Mon, 7 Feb 2005 12:00:18 -0800 

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

Delivery-date: Mon, 07 Feb 2005 17:17:41 +0000
Content-class: urn:content-classes:message
Subject: GMPLS signalling for IPv6 networks.
Date: Mon, 7 Feb 2005 17:16:17 -0000
From: "Alan Davey" <[email-masked]>
To: <[email-masked]>

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:   +44 20 8366 1177      =20
Fax:   +44 20 8363 1039
Email: [email-masked] =20
Web:   http://www.dataconnection.com=20

Delivery-date: Mon, 07 Feb 2005 13:59:46 +0000
Date: Mon, 07 Feb 2005 14:57:41 +0100
From: [email-masked]
Reply-To: [email-masked]
Organization: Alcatel CIT
To: [email-masked]
Cc: [email-masked], Adrian Farrel <[email-masked]>, [email-masked]
Subject: Presentation MRN

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: 33 (0)1 69 63 47 31
Fax: 33 (0)1 69 63 44 50

Delivery-date: Sat, 05 Feb 2005 16:44:53 +0000
To: "David Allan" <[email-masked]>
Cc: "[email-masked]'"	 <[email-masked]>, "[email-masked]'" <[email-masked]>, Shahram Davari <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Sat, 5 Feb 2005 17:42:38 +0100

Delivery-date: Sat, 05 Feb 2005 15:11:15 +0000
To: Shahram Davari <[email-masked]>
Cc: "[email-masked]'"	 <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, [email-masked], David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Sat, 5 Feb 2005 16:08:33 +0100

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

> Behalf Of [email-masked]
> Sent: Friday, February 04, 2005 2:26 PM
> To: Mack-Crane, T. Benjamin
> Cc: [email-masked]; Shahram Davari;
> [email-masked]; David Allan; Adrian Farrel; [email-masked]
> 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
>
>
>

Delivery-date: Sat, 05 Feb 2005 12:16:38 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: IPR Disclosure wrt draft-ietf-ccamp-loose-path-reopt
Date: Sat, 5 Feb 2005 12:14:26 -0000

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" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
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
>
>
>
>

Delivery-date: Fri, 04 Feb 2005 23:42:41 +0000
To: Shahram Davari <[email-masked]>
Cc: "[email-masked]'"	 <[email-masked]>, "[email-masked]'" <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Sat, 5 Feb 2005 00:42:06 +0100

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

Delivery-date: Fri, 04 Feb 2005 23:23:51 +0000
To: Shahram Davari <[email-masked]>
Cc: "[email-masked]'"	 <[email-masked]>, David Allan <[email-masked]>, "[email-masked]'" <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Sat, 5 Feb 2005 00:22:17 +0100

sharam,

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

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

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

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

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

Delivery-date: Fri, 04 Feb 2005 20:22:28 +0000
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: [email-masked], David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 12:22:02 -0800 

Dimitri,

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

-Shahram

> Behalf Of [email-masked]
> Sent: Friday, February 04, 2005 2:26 PM
> To: Mack-Crane, T. Benjamin
> Cc: [email-masked]; Shahram Davari;
> [email-masked]; David Allan; Adrian Farrel; [email-masked]
> 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
> 
> 
> 

Delivery-date: Fri, 04 Feb 2005 19:52:26 +0000
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: David Allan <[email-masked]>, "[email-masked]'" <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 11:51:33 -0800 

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: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 04, 2005 2:10 PM
To: Shahram Davari
Cc: [email-masked]'; David Allan; [email-masked]'; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

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 <[email-masked]>
Sent by: [email-masked]
02/04/2005 10:55 PST

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

Dimitri,

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

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

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

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

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

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

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

------_=_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> 
  [email-masked] 
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, February 04, 
  2005 2:10 PM<BR><B>To:</B> Shahram Davari<BR><B>Cc:</B> 
  [email-masked]'; David Allan; [email-masked]'; 
  Mack-Crane, T. Benjamin; David Allan; Adrian Farrel; 
  [email-masked]<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;[email-masked]&gt;</B></FONT><BR><FONT size=2>Sent by: 
  [email-masked]</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;[email-masked]&gt;</FONT><BR><FONT size=2>cc:</FONT> <FONT 
  size=2>"[email-masked]'" &lt;[email-masked]&gt;, "Mack-Crane, 
  T. Benjamin" &lt;[email-masked]&gt;, David Allan 
  &lt;[email-masked]&gt;, Adrian Farrel &lt;[email-masked]&gt;, 
  [email-masked]</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> 
  [email-masked] 
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, February 04, 
  2005 1:34 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B> [email-masked]'; 
  [email-masked]'; Shahram Davari; Mack-Crane, T. Benjamin; 
  David Allan; Adrian Farrel; [email-masked]<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;[email-masked]&gt;</B><BR>02/04/2005 09:44 EST<BR><BR>To:<FONT size=4> 
  </FONT>"[email-masked]'" &lt;[email-masked]&gt;, Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari 
  &lt;[email-masked]&gt;<BR>cc:<FONT size=4> </FONT>"Mack-Crane, 
  T. Benjamin" &lt;[email-masked]&gt;, David Allan 
  &lt;[email-masked]&gt;, Adrian Farrel &lt;[email-masked]&gt;, 
  [email-masked]<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: [email-masked] </FONT><BR><FONT 
  size=4>&gt; &gt; [</FONT><FONT color=blue size=4><U><A 
  href="mailto:[email-masked]">mailto:[email-masked]</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; [email-masked]' Cc: Mack-Crane, T. 
  Benjamin; </FONT><BR><FONT size=4>&gt; &gt; [email-masked]; David 
  Allan; Adrian Farrel; </FONT><BR><FONT size=4>&gt; [email-masked] 
  </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: 
  [email-masked] </FONT><BR><FONT size=4>&gt; &gt; 
  [</FONT><FONT color=blue size=4><U><A 
  href="mailto:[email-masked]">mailto:[email-masked]</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; [email-masked]'; 
  Mack-Crane, T. Benjamin; </FONT><BR><FONT size=4>&gt; &gt; 
  [email-masked]; David Allan; Adrian Farrel; </FONT><BR><FONT 
  size=4>&gt; [email-masked] </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;[email-masked]&gt; Sent by: </FONT><BR><FONT size=4>&gt; 
  &gt; [email-masked] 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;[email-masked]&gt; cc: 
  [email-masked], </FONT><BR><FONT size=4>&gt; &gt; David Allan 
  &lt;[email-masked]&gt;, Adrian Farrel </FONT><BR><FONT size=4>&gt; 
  &gt; &lt;[email-masked]&gt;, [email-masked] 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: 
  [email-masked] </FONT><BR><FONT size=4>&gt; &gt; 
  [</FONT><FONT color=blue size=4><U><A 
  href="mailto:[email-masked]">mailto:[email-masked]</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; [email-masked]; </FONT><BR><FONT 
  size=4>&gt; &gt; [email-masked]; David Allan; Adrian 
  </FONT><BR><FONT size=4>&gt; Farrel; Shahram </FONT><BR><FONT size=4>&gt; &gt; 
  Davari; [email-masked] 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;[email-masked]&gt; Sent by: </FONT><BR><FONT size=4>&gt; &gt; 
  [email-masked] 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;[email-masked]&gt;, Dimitri </FONT><BR><FONT size=4>&gt; &gt; 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" </FONT><BR><FONT size=4>&gt; 
  &gt; &lt;[email-masked]&gt; cc: "Adrian Farrel" </FONT><BR><FONT 
  size=4>&gt; &lt;[email-masked]&gt;, </FONT><BR><FONT size=4>&gt; &gt; 
  "Shahram Davari" &lt;[email-masked]&gt;, </FONT><BR><FONT 
  size=4>&gt; &lt;[email-masked]&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: 
  [email-masked] </FONT><BR><FONT size=4>&gt; &gt;&gt; [</FONT><FONT 
  color=blue size=4><U><A 
  href="mailto:[email-masked]">mailto:[email-masked]</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; 
  [email-masked] 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--

Delivery-date: Fri, 04 Feb 2005 19:27:19 +0000
To: "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: <[email-masked]>, "Shahram Davari" <[email-masked]>, <[email-masked]>, "David Allan" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 20:26:12 +0100

ben,

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

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

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

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

Delivery-date: Fri, 04 Feb 2005 19:10:12 +0000
To: Shahram Davari <[email-masked]>
Cc: "[email-masked]'"	 <[email-masked]>, David Allan <[email-masked]>, "[email-masked]'" <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 20:09:32 +0100

Delivery-date: Fri, 04 Feb 2005 19:05:07 +0000
Content-class: urn:content-classes:message
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 13:04:44 -0600
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: <[email-masked]>
Cc: "Shahram Davari" <[email-masked]>, <[email-masked]>, "David Allan" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

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

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, February 04, 2005 12:21 PM
> To: Mack-Crane, T. Benjamin
> Cc: [email-masked]; Shahram Davari;
> [email-masked]; David Allan; Adrian Farrel; [email-masked]
> 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

Delivery-date: Fri, 04 Feb 2005 19:05:05 +0000
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 11:04:53 -0800 

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

Delivery-date: Fri, 04 Feb 2005 19:01:37 +0000
To: Shahram Davari <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 20:01:10 +0100

sharam

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

Delivery-date: Fri, 04 Feb 2005 18:56:34 +0000
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>, David Allan <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 10:55:56 -0800 

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: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 04, 2005 1:34 PM
To: David Allan
Cc: [email-masked]'; [email-masked]'; Shahram Davari; Mack-Crane, T. Benjamin; David Allan; Adrian Farrel; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

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

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

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

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

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

------_=_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> 
  [email-masked] 
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, February 04, 
  2005 1:34 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B> [email-masked]'; 
  [email-masked]'; Shahram Davari; Mack-Crane, T. Benjamin; 
  David Allan; Adrian Farrel; [email-masked]<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;[email-masked]&gt;</B></FONT><BR><FONT 
  size=2>02/04/2005 09:44 EST</FONT><BR><BR><FONT size=2>To:</FONT> <FONT 
  size=2>"[email-masked]'" &lt;[email-masked]&gt;, Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari 
  &lt;[email-masked]&gt;</FONT><BR><FONT size=2>cc:</FONT> <FONT 
  size=2>"Mack-Crane, T. Benjamin" &lt;[email-masked]&gt;, David 
  Allan &lt;[email-masked]&gt;, Adrian Farrel 
  &lt;[email-masked]&gt;, [email-masked]</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: 
  [email-masked] <BR>&gt; &gt; [<FONT color=blue><U><A 
  href="mailto:[email-masked]">mailto:[email-masked]</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; [email-masked]' 
  Cc: Mack-Crane, T. Benjamin; <BR>&gt; &gt; [email-masked]; David 
  Allan; Adrian Farrel; <BR>&gt; [email-masked] <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: 
  [email-masked] <BR>&gt; &gt; [<FONT color=blue><U><A 
  href="mailto:[email-masked]">mailto:[email-masked]</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; [email-masked]'; 
  Mack-Crane, T. Benjamin; <BR>&gt; &gt; [email-masked]; David Allan; 
  Adrian Farrel; <BR>&gt; [email-masked] <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;[email-masked]&gt; Sent by: <BR>&gt; &gt; 
  [email-masked] 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;[email-masked]&gt; cc: 
  [email-masked], <BR>&gt; &gt; David Allan 
  &lt;[email-masked]&gt;, Adrian Farrel <BR>&gt; &gt; 
  &lt;[email-masked]&gt;, [email-masked] 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: [email-masked] <BR>&gt; 
  &gt; [<FONT color=blue><U><A 
  href="mailto:[email-masked]">mailto:[email-masked]</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; [email-masked]; <BR>&gt; &gt; 
  [email-masked]; David Allan; Adrian <BR>&gt; Farrel; Shahram 
  <BR>&gt; &gt; Davari; [email-masked] 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;[email-masked]&gt; Sent by: <BR>&gt; &gt; 
  [email-masked] 02/03/2005 12:16 CST<FONT size=4> </FONT><BR>&gt; 
  &gt; <BR>&gt; &gt; To: &lt;[email-masked]&gt;, Dimitri <BR>&gt; &gt; 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" <BR>&gt; &gt; 
  &lt;[email-masked]&gt; cc: "Adrian Farrel" <BR>&gt; 
  &lt;[email-masked]&gt;, <BR>&gt; &gt; "Shahram Davari" 
  &lt;[email-masked]&gt;, <BR>&gt; &lt;[email-masked]&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: [email-masked] 
  <BR>&gt; &gt;&gt; [<FONT color=blue><U><A 
  href="mailto:[email-masked]">mailto:[email-masked]</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; [email-masked] 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--

Delivery-date: Fri, 04 Feb 2005 18:34:14 +0000
To: "David Allan" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, Shahram Davari <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 19:33:32 +0100

Delivery-date: Fri, 04 Feb 2005 18:22:17 +0000
To: "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: <[email-masked]>, "Shahram Davari" <[email-masked]>, <[email-masked]>, "David Allan" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 19:20:47 +0100

ben,

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

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

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

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

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

Delivery-date: Fri, 04 Feb 2005 17:10:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 11:09:08 -0600
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: <[email-masked]>, "Shahram Davari" <[email-masked]>
Cc: <[email-masked]>, "David Allan" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

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: [email-masked]
[mailto:[email-masked]]=20
Sent: Thursday, February 03, 2005 4:31 PM
To: Shahram Davari
Cc: [email-masked]'; Mack-Crane, T. Benjamin;
[email-masked]; David Allan; Adrian Farrel; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

=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 <[email-masked]>
Sent by: [email-masked]
02/03/2005 13:13 PST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T. Benjamin"
<[email-masked]>
cc: [email-masked], David Allan <[email-masked]>,
Adrian Farrel <[email-masked]>, [email-masked]
bcc:=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: [email-masked]
[mailto:[email-masked]]
Sent: Thursday, February 03, 2005 3:07 PM
To: Mack-Crane, T. Benjamin
Cc: [email-masked]; [email-masked]; David
Allan; Adrian Farrel; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

ben,=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" <[email-masked]>
Sent by: [email-masked]
02/03/2005 12:16 CST

To: <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL,
"David Allan" <[email-masked]>
cc: "Adrian Farrel" <[email-masked]>, "Shahram Davari"
<[email-masked]>, <[email-masked]>
bcc:=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

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

Delivery-date: Fri, 04 Feb 2005 17:10:25 +0000
Content-class: urn:content-classes:message
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 11:09:58 -0600
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Shahram Davari" <[email-masked]>
Cc: "David Allan" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

Dmitri,

Some questions in-line below.

Regards,
Ben

> From: dimitri papadimitriou [mailto:[email-masked]]
> Sent: Thursday, February 03, 2005 9:33 PM
> To: Shahram Davari
> Cc: [email-masked]'; Mack-Crane, T. Benjamin; David
> Allan; Adrian Farrel; [email-masked]
> 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: [email-masked]
> > [mailto:[email-masked]] Sent: Thursday, February
> > 03, 2005 5:31 PM To: Shahram Davari Cc:
> > [email-masked]'; Mack-Crane, T. Benjamin;
> > [email-masked]; David Allan; Adrian Farrel;
> > [email-masked] Subject: RE: Layer 2 Switching Caps LSPs
> >
> > sharam, the first issue is that you have to decouple the notion of
> > ethernet with bridging,
> >
> > Ethernet networks have 3 main layers:
> >
> > 1) PHY =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 <[email-masked]> Sent by:
> > [email-masked] 02/03/2005 13:13 PST
> >
> > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T.
> > Benjamin" <[email-masked]> cc: [email-masked],
> > David Allan <[email-masked]>, Adrian Farrel
> > <[email-masked]>, [email-masked] bcc: Subject: RE: Layer 2
> > Switching Caps LSPs
> >
> >
> >
> >
> > Dimitri,
> >
> > Unfortunately I didn't grasp completely what you are trying to
> > convey. But one thing I know for sure, and that is  "Ethernet is
> > Connectionless (CLS)" (like IP) and assumes shared medium, while
> > GMPLS is connection-oriented (CO) and doesn't work in shared medium.
> > Off course you could always configure and build an Ethernet network
> > that looks like it is CO (by configuring a max of 2 ports with the
> > same VLAN ID in each bridge), and by not using any shared medium.
But
> > then who needs GMPLS, when you already have to configure your
network
> > by other means?
> >
> > -Shahram
> >
> >
> > From: [email-masked]
> > [mailto:[email-masked]] Sent: Thursday, February
> > 03, 2005 3:07 PM To: Mack-Crane, T. Benjamin Cc:
> > [email-masked]; [email-masked]; David
> > Allan; Adrian Farrel; Shahram Davari; [email-masked] Subject:
RE:
> > 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" <[email-masked]> Sent by:
> > [email-masked] 02/03/2005 12:16 CST
> >
> > To: <[email-masked]>, Dimitri
> > PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan"
> > <[email-masked]> cc: "Adrian Farrel"
> > <[email-masked]>, "Shahram Davari"
> > <[email-masked]>, <[email-masked]> bcc: Subject:
> > RE: Layer 2 Switching Caps LSPs
> >
> >
> > Dimitri,
> >
> > Can the off-line discussion be summarized for the benefit of those
on
> >  the list who did not participate?  For me, the draft (and the
> > current discussion on the list) have not clearly articulated the
> > problem being addressed.  If a summary of the conclusions of the
> > off-line discussion will do this, it would be useful.
> >
> > I am also interested to know what is lacking in the current GMPLS
> > RFCs with respect to ATM and Frame Relay support that necessitates
> > including them in this new draft (presumably this is a part of the
> > problem to be solved).
> >
> > Regards, Ben
> >
> >
> >> -----Original Message----- From: [email-masked]
> >> [mailto:[email-masked]] On
> >
> > Behalf
> >
> >> Of dimitri papadimitriou Sent: Thursday, January 27, 2005 6:35 PM
> >> To: David Allan Cc: 'Adrian Farrel'; 'Shahram Davari';
> >> [email-masked] Subject: Re: Layer 2 Switching Caps LSPs
> >>
> >> dave - there was a lengthy off-line discussion suggested by the
> >> chairs intended to explain you the scope of the draft and its
> >> relatioship
> >
> > with
> >
> >> the ethernet data plane (after the question you raised during the
> >> f2f meeting) - this has been done and we have explained (via a
> >> lengthy exchange of e-mails) that this document and so the use of
> >> gmpls to control ethernet frame flows, is not targeting control of
> >> bridged ethernet environments - if this is not clear from the
> >> current document introduction we would have also to work on this
> >> part of the document - therefore, the below reference to MSTP is
> >> not in the current scope; on the other side, the use of the term
> >> "VLAN label" has created some confusion; therefore, in a next
> >> release i will simply refer to a
> >
> > "label"
> >
> >> of 32 bits (unstructured) because the intention was (and still is)
> >> to find an easy way to map the control of the ethernet frame flows
> >> on
> >
> > each
> >
> >> device they traverses without making any assumption on how this
> >> flow
> >
> > is
> >
> >> processed inside each node at the data plane level (note: on label
> >> values, RFC 3946 took an equivalent approach - for circuits - where
> >>  sonet/sdh multiplexing structures have been used to create unique
> >> multiplex entry names i.e. labels - this concept is here applied
> >> for "virtual" circuits), so, if the working group is willing to
> >> enter into
> >
> > a
> >
> >> data plane oriented discussion to clarify the behaviour(s) onto
> >> which the present approach would be potentially applicable this is
> >> fine with me as long as we are within the scope of the initial
> >> motivations
> >>
> >> thanks, - dimitri.
> >>
> >> David Allan wrote:
> >>
> >>> Hi Adrian:
> >>>
> >>> Your suggestion is in a way reasonable but with the caveat that
> >>> in
> >
> > IEEE
> >
> >>> terms, a bridging topology is currently all VLANs (802.1Q single
> >>
> >> spanning
> >>
> >>> tree) or partitioned into specific ranges (I believe 64 in 802.1s
> >>>
> >>
> >> although I
> >>
> >>> do not claim to be an expert).
> >>>
> >>> If the PEs were to implement a bridge function and we were using
> >
> > GMPLS
> >
> >> to
> >>
> >>> interconnect them, then the control plane should be identifying
> >
> > either
> >
> >> all
> >>
> >>> VLANs (single spanning tree, which I beleive the draft covers by
> >>
> >> referring
> >>
> >>> simply to Ethernet port) or a VLAN range to be associated with
> >>> the
> >
> > LSP
> >
> >>> consistent with 802.1s if it is to operate to interconnect
> >>> bridges
> >>
> >> defined
> >>
> >>> by the IEEE...
> >>>
> >>> I suspect assuming any other behavior (e.g. LSP for single VLAN
> >>> tag)
> >>
> >> would
> >>
> >>> go outside the boundary of what is currently defined...so
> >>> alignment
> >
> > with
> >
> >>> 802.1s IMO would be a minimum requirement if we are to consider
> >
> > carrying
> >
> >>> VLAN information in GMPLS signalling....
> >>>
> >>> cheers Dave
> >>>
> >>> You wrote....
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>> The authors of the draft might like to clarify for the list
> >>>> exactly what data plane operations they are suggesting. To me
> >>>> it seems possible that the draft is proposing VLAN ID
> >>>> *swapping*. But an alternative is that the VLAN ID is used as a
> >>>> label, but that the same label is used for the full length of
> >>>> the LSP.
> >>>>
> >>>> Adrian
> >>>
> >>>
> >>>
> >>> .
> >>>
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

Delivery-date: Fri, 04 Feb 2005 15:22:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 09:22:14 -0600
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "David Allan" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Shahram Davari" <[email-masked]>, <[email-masked]>

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: [email-masked]
[mailto:[email-masked]]=20
Sent: Thursday, February 03, 2005 2:07 PM
To: Mack-Crane, T. Benjamin
Cc: [email-masked]; [email-masked]; David
Allan; Adrian Farrel; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

=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" <[email-masked]>
Sent by: [email-masked]
02/03/2005 12:16 CST

To: <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL,
"David Allan" <[email-masked]>
cc: "Adrian Farrel" <[email-masked]>, "Shahram Davari"
<[email-masked]>, <[email-masked]>
bcc:=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

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

Delivery-date: Fri, 04 Feb 2005 14:47:05 +0000
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "Mack-Crane, T. Benjamin" <[email-masked]>, David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 4 Feb 2005 06:43:51 -0800 

Dimitri,

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

Delivery-date: Fri, 04 Feb 2005 10:33:22 +0000
Content-class: urn:content-classes:message
Subject: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt 
Date: Fri, 4 Feb 2005 11:30:11 +0100
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi Adrian,

Thanks a lot for these comments

Please see inline

Regards

JL

>-----Message d'origine-----
>De : Adrian Farrel [mailto:[email-masked]]=20
>Envoy=E9 : mardi 1 f=E9vrier 2005 19:41
>=C0 : LE ROUX Jean-Louis RD-CORE-LAN
>Cc : [email-masked]
>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
><[email-masked]>
>To: <[email-masked]>
>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>

Delivery-date: Fri, 04 Feb 2005 03:34:38 +0000
Date: Fri, 04 Feb 2005 04:33:11 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Shahram Davari <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>,  David Allan <[email-masked]>, Adrian Farrel <[email-masked]>,  [email-masked]
Subject: Re: Layer 2 Switching Caps LSPs

Sharam, see in-line

Shahram Davari wrote:
> Hi Dimitri,
> 
> Thanks for your response. Please see my comments in-line.
> 
> -Shahram
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] Sent: Thursday, February
> 03, 2005 5:31 PM To: Shahram Davari Cc:
> [email-masked]'; Mack-Crane, T. Benjamin;
> [email-masked]; David Allan; Adrian Farrel;
> [email-masked] Subject: RE: Layer 2 Switching Caps LSPs 
> 
> sharam, the first issue is that you have to decouple the notion of
> ethernet with bridging,
> 
> Ethernet networks have 3 main layers:
> 
> 1) PHY = 10/100/1G/10G as explained in 802.3,
> 
> 2) MAC = 802.3
> 
> 3) Bridging = 802.1D
> 
> Without Bridging layer your device can only have a single port.
> Example is the Ethernet port of your desktop computer. Therefore if
> you want to build an Ethernet network, you need bridging layer.

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 <[email-masked]> Sent by:
> [email-masked] 02/03/2005 13:13 PST
> 
> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Mack-Crane, T.
> Benjamin" <[email-masked]> cc: [email-masked],
> David Allan <[email-masked]>, Adrian Farrel
> <[email-masked]>, [email-masked] bcc: Subject: RE: Layer 2
> Switching Caps LSPs
> 
> 
> 
> 
> Dimitri,
> 
> Unfortunately I didn't grasp completely what you are trying to
> convey. But one thing I know for sure, and that is  "Ethernet is
> Connectionless (CLS)" (like IP) and assumes shared medium, while
> GMPLS is connection-oriented (CO) and doesn't work in shared medium.
> Off course you could always configure and build an Ethernet network
> that looks like it is CO (by configuring a max of 2 ports with the
> same VLAN ID in each bridge), and by not using any shared medium. But
> then who needs GMPLS, when you already have to configure your network
> by other means?
> 
> -Shahram
> 
> 
> From: [email-masked]
> [mailto:[email-masked]] Sent: Thursday, February
> 03, 2005 3:07 PM To: Mack-Crane, T. Benjamin Cc:
> [email-masked]; [email-masked]; David
> Allan; Adrian Farrel; Shahram Davari; [email-masked] Subject: RE:
> 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" <[email-masked]> Sent by:
> [email-masked] 02/03/2005 12:16 CST
> 
> To: <[email-masked]>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan"
> <[email-masked]> cc: "Adrian Farrel"
> <[email-masked]>, "Shahram Davari"
> <[email-masked]>, <[email-masked]> bcc: Subject:
> RE: Layer 2 Switching Caps LSPs
> 
> 
> Dimitri,
> 
> Can the off-line discussion be summarized for the benefit of those on
>  the list who did not participate?  For me, the draft (and the
> current discussion on the list) have not clearly articulated the
> problem being addressed.  If a summary of the conclusions of the
> off-line discussion will do this, it would be useful.
> 
> I am also interested to know what is lacking in the current GMPLS
> RFCs with respect to ATM and Frame Relay support that necessitates
> including them in this new draft (presumably this is a part of the
> problem to be solved).
> 
> Regards, Ben
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On
> 
> Behalf
> 
>> Of dimitri papadimitriou Sent: Thursday, January 27, 2005 6:35 PM 
>> To: David Allan Cc: 'Adrian Farrel'; 'Shahram Davari';
>> [email-masked] Subject: Re: Layer 2 Switching Caps LSPs
>> 
>> dave - there was a lengthy off-line discussion suggested by the
>> chairs intended to explain you the scope of the draft and its
>> relatioship
> 
> with
> 
>> the ethernet data plane (after the question you raised during the
>> f2f meeting) - this has been done and we have explained (via a
>> lengthy exchange of e-mails) that this document and so the use of
>> gmpls to control ethernet frame flows, is not targeting control of
>> bridged ethernet environments - if this is not clear from the
>> current document introduction we would have also to work on this
>> part of the document - therefore, the below reference to MSTP is
>> not in the current scope; on the other side, the use of the term
>> "VLAN label" has created some confusion; therefore, in a next
>> release i will simply refer to a
> 
> "label"
> 
>> of 32 bits (unstructured) because the intention was (and still is)
>> to find an easy way to map the control of the ethernet frame flows
>> on
> 
> each
> 
>> device they traverses without making any assumption on how this
>> flow
> 
> is
> 
>> processed inside each node at the data plane level (note: on label 
>> values, RFC 3946 took an equivalent approach - for circuits - where
>>  sonet/sdh multiplexing structures have been used to create unique 
>> multiplex entry names i.e. labels - this concept is here applied
>> for "virtual" circuits), so, if the working group is willing to
>> enter into
> 
> a
> 
>> data plane oriented discussion to clarify the behaviour(s) onto
>> which the present approach would be potentially applicable this is
>> fine with me as long as we are within the scope of the initial
>> motivations
>> 
>> thanks, - dimitri.
>> 
>> David Allan wrote:
>> 
>>> Hi Adrian:
>>> 
>>> Your suggestion is in a way reasonable but with the caveat that
>>> in
> 
> IEEE
> 
>>> terms, a bridging topology is currently all VLANs (802.1Q single
>> 
>> spanning
>> 
>>> tree) or partitioned into specific ranges (I believe 64 in 802.1s
>>> 
>> 
>> although I
>> 
>>> do not claim to be an expert).
>>> 
>>> If the PEs were to implement a bridge function and we were using
> 
> GMPLS
> 
>> to
>> 
>>> interconnect them, then the control plane should be identifying
> 
> either
> 
>> all
>> 
>>> VLANs (single spanning tree, which I beleive the draft covers by
>> 
>> referring
>> 
>>> simply to Ethernet port) or a VLAN range to be associated with
>>> the
> 
> LSP
> 
>>> consistent with 802.1s if it is to operate to interconnect
>>> bridges
>> 
>> defined
>> 
>>> by the IEEE...
>>> 
>>> I suspect assuming any other behavior (e.g. LSP for single VLAN
>>> tag)
>> 
>> would
>> 
>>> go outside the boundary of what is currently defined...so
>>> alignment
> 
> with
> 
>>> 802.1s IMO would be a minimum requirement if we are to consider
> 
> carrying
> 
>>> VLAN information in GMPLS signalling....
>>> 
>>> cheers Dave
>>> 
>>> You wrote....
>>> 
>>> 
>>>> Hi,
>>>> 
>>>> The authors of the draft might like to clarify for the list 
>>>> exactly what data plane operations they are suggesting. To me 
>>>> it seems possible that the draft is proposing VLAN ID 
>>>> *swapping*. But an alternative is that the VLAN ID is used as a
>>>> label, but that the same label is used for the full length of
>>>> the LSP.
>>>> 
>>>> Adrian
>>> 
>>> 
>>> 
>>> .
>>> 
> 
> ============================================================ The
> information contained in this message may be privileged and
> confidential and protected from disclosure. If the reader of this
> message is not the intended recipient, or an employee or agent
> responsible for delivering this message to the intended recipient,
> you are hereby notified that any reproduction, dissemination or
> distribution of this communication is strictly prohibited. If you
> have received this communication in error, please notify us
> immediately by replying to the message and deleting it from your
> computer. Thank you. Tellabs 
> ============================================================
> 
> 

Delivery-date: Fri, 04 Feb 2005 02:15:47 +0000
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>
From: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>
To: <[email-masked]>
Cc: 
Bcc: 
Date: Fri, 4 Feb 2005 11:14:52 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCC9w726xdu8s7DoxsAsILTjtOc=?=
Subject: I-D ACTION:draft-jaihyung-ccamp-arpsignal-00.txt
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

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

------=_NextPart_000_DF33_01C50AAA.4D1F9280--

Delivery-date: Thu, 03 Feb 2005 23:38:11 +0000
From: Shahram Davari <[email-masked]>
To: Shahram Davari <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "Mack-Crane, T. Benjamin" <[email-masked]>, [email-masked], David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Thu, 3 Feb 2005 15:37:19 -0800 

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

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

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

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

Ethernet networks have 3 main layers: 

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

2) MAC = 802.3

3) Bridging = 802.1D

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

  the second is that this configuration operation can be automated - 

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

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

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

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

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

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

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

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

thanks,

- dimitri.

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

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

Dimitri,

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

-Shahram

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 03, 2005 3:07 PM
To: Mack-Crane, T. Benjamin
Cc: [email-masked]; [email-masked]; David Allan; Adrian Farrel; Shahram Davari; [email-masked]
Subject: RE: 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" <[email-masked]>
Sent by: [email-masked]
02/03/2005 12:16 CST

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

Dimitri,

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

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

------_=_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> [email-masked] 
  [mailto:[email-masked]]<B>On Behalf Of </B>Shahram 
  Davari<BR><B>Sent:</B> Thursday, February 03, 2005 6:19 PM<BR><B>To:</B> 
  [email-masked]'<BR><B>Cc:</B> Mack-Crane, T. Benjamin; 
  [email-masked]; David Allan; Adrian Farrel; 
  [email-masked]<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> 
    [email-masked] 
    [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, February 
    03, 2005 5:31 PM<BR><B>To:</B> Shahram Davari<BR><B>Cc:</B> 
    [email-masked]'; Mack-Crane, T. Benjamin; 
    [email-masked]; David Allan; Adrian Farrel; 
    [email-masked]<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;[email-masked]&gt;</B></FONT><BR><FONT size=2>Sent by: 
    [email-masked]</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;[email-masked]&gt;</FONT><BR><FONT size=2>cc:</FONT> <FONT 
    size=2>[email-masked], David Allan 
    &lt;[email-masked]&gt;, Adrian Farrel 
    &lt;[email-masked]&gt;, [email-masked]</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> 
    [email-masked] 
    [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, February 
    03, 2005 3:07 PM<BR><B>To:</B> Mack-Crane, T. Benjamin<BR><B>Cc:</B> 
    [email-masked]; [email-masked]; David Allan; 
    Adrian Farrel; Shahram Davari; [email-masked]<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;[email-masked]&gt;</B><BR>Sent by: 
    [email-masked]<BR>02/03/2005 12:16 CST<BR><BR>To:<FONT size=4> 
    </FONT>&lt;[email-masked]&gt;, Dimitri 
    PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" 
    &lt;[email-masked]&gt;<BR>cc:<FONT size=4> </FONT>"Adrian Farrel" 
    &lt;[email-masked]&gt;, "Shahram Davari" 
    &lt;[email-masked]&gt;, 
    &lt;[email-masked]&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: [email-masked] 
    [mailto:[email-masked]] 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'; 
    [email-masked]</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--

Delivery-date: Thu, 03 Feb 2005 23:20:10 +0000
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "Mack-Crane, T. Benjamin" <[email-masked]>, [email-masked], David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Thu, 3 Feb 2005 15:19:22 -0800 

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: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 03, 2005 5:31 PM
To: Shahram Davari
Cc: [email-masked]'; Mack-Crane, T. Benjamin; [email-masked]; David Allan; Adrian Farrel; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

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

Ethernet networks have 3 main layers: 

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

2) MAC = 802.3

3) Bridging = 802.1D

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

  the second is that this configuration operation can be automated - 

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

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

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

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

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

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

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

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

thanks,

- dimitri.

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

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

Dimitri,

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

-Shahram

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 03, 2005 3:07 PM
To: Mack-Crane, T. Benjamin
Cc: [email-masked]; [email-masked]; David Allan; Adrian Farrel; Shahram Davari; [email-masked]
Subject: RE: 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" <[email-masked]>
Sent by: [email-masked]
02/03/2005 12:16 CST

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

Dimitri,

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

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

------_=_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> 
  [email-masked] 
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, February 
  03, 2005 5:31 PM<BR><B>To:</B> Shahram Davari<BR><B>Cc:</B> 
  [email-masked]'; Mack-Crane, T. Benjamin; 
  [email-masked]; David Allan; Adrian Farrel; 
  [email-masked]<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;[email-masked]&gt;</B></FONT><BR><FONT size=2>Sent by: 
  [email-masked]</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;[email-masked]&gt;</FONT><BR><FONT size=2>cc:</FONT> <FONT 
  size=2>[email-masked], David Allan &lt;[email-masked]&gt;, 
  Adrian Farrel &lt;[email-masked]&gt;, [email-masked]</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> 
  [email-masked] 
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, February 
  03, 2005 3:07 PM<BR><B>To:</B> Mack-Crane, T. Benjamin<BR><B>Cc:</B> 
  [email-masked]; [email-masked]; David Allan; Adrian 
  Farrel; Shahram Davari; [email-masked]<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;[email-masked]&gt;</B><BR>Sent by: 
  [email-masked]<BR>02/03/2005 12:16 CST<BR><BR>To:<FONT size=4> 
  </FONT>&lt;[email-masked]&gt;, Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" 
  &lt;[email-masked]&gt;<BR>cc:<FONT size=4> </FONT>"Adrian Farrel" 
  &lt;[email-masked]&gt;, "Shahram Davari" 
  &lt;[email-masked]&gt;, &lt;[email-masked]&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: 
  [email-masked] [mailto:[email-masked]] 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'; 
  [email-masked]</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--

Delivery-date: Thu, 03 Feb 2005 22:32:13 +0000
To: Shahram Davari <[email-masked]>
Cc: "[email-masked]'"	 <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>, [email-masked], David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Thu, 3 Feb 2005 23:30:56 +0100

Delivery-date: Thu, 03 Feb 2005 21:14:34 +0000
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: [email-masked], David Allan <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Thu, 3 Feb 2005 13:13:23 -0800 

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

ben, 

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

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

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

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

voila, thanks,

- dimitri.

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

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

Dimitri,

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

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

------_=_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> 
[email-masked] 
[mailto:[email-masked]]<BR><B>Sent:</B> Thursday, February 03, 
2005 3:07 PM<BR><B>To:</B> Mack-Crane, T. Benjamin<BR><B>Cc:</B> 
[email-masked]; [email-masked]; David Allan; Adrian 
Farrel; Shahram Davari; [email-masked]<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;[email-masked]&gt;</B></FONT><BR><FONT size=2>Sent by: 
  [email-masked]</FONT><BR><FONT size=2>02/03/2005 12:16 
  CST</FONT><BR><BR><FONT size=2>To:</FONT> <FONT 
  size=2>&lt;[email-masked]&gt;, Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "David Allan" 
  &lt;[email-masked]&gt;</FONT><BR><FONT size=2>cc:</FONT> <FONT 
  size=2>"Adrian Farrel" &lt;[email-masked]&gt;, "Shahram Davari" 
  &lt;[email-masked]&gt;, 
  &lt;[email-masked]&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: 
  [email-masked] [mailto:[email-masked]] 
  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'; [email-masked]<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--

Delivery-date: Thu, 03 Feb 2005 20:07:59 +0000
To: "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "David Allan" <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Shahram Davari" <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Thu, 3 Feb 2005 21:07:00 +0100

Delivery-date: Thu, 03 Feb 2005 19:32:07 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Cc: "'Richard Rabbat'" <[email-masked]>, "'Rajiv Papneja'" <[email-masked]>, <[email-masked]>
Subject: new draft submission draft-shiomoto-ccamp-gmpls-addressing-00.txt
Date: Thu, 3 Feb 2005 11:30:18 -0800

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

Delivery-date: Thu, 03 Feb 2005 18:17:44 +0000
Content-class: urn:content-classes:message
Subject: RE: Layer 2 Switching Caps LSPs
Date: Thu, 3 Feb 2005 12:16:22 -0600
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "David Allan" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "Shahram Davari" <[email-masked]>, <[email-masked]>

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

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of dimitri papadimitriou
> Sent: Thursday, January 27, 2005 6:35 PM
> To: David Allan
> Cc: 'Adrian Farrel'; 'Shahram Davari'; [email-masked]
> Subject: Re: Layer 2 Switching Caps LSPs
>=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

Delivery-date: Thu, 03 Feb 2005 13:35:36 +0000
Cc: <[email-masked]>
From: JP Vasseur <[email-masked]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Thu, 3 Feb 2005 08:35:12 -0500
To: "Adrian Farrel" <[email-masked]>

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

Delivery-date: Thu, 03 Feb 2005 13:21:57 +0000
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>
From: JP Vasseur <[email-masked]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Thu, 3 Feb 2005 08:19:39 -0500
To: [email-masked]

Hi Dimitri,

On Jan 30, 2005, at 7:48 AM, [email-masked] 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
>

Delivery-date: Wed, 02 Feb 2005 13:21:19 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt 
Date: Tue, 1 Feb 2005 18:40:48 -0000

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"
<[email-masked]>
To: <[email-masked]>
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>

Delivery-date: Tue, 01 Feb 2005 19:23:27 +0000
Date: Tue, 1 Feb 2005 11:21:05 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: CCAMP 62 agenda

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

Delivery-date: Tue, 01 Feb 2005 09:50:02 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, "JP Vasseur" <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Tue, 1 Feb 2005 10:48:35 +0100

Delivery-date: Tue, 01 Feb 2005 07:23:06 +0000
Content-class: urn:content-classes:message
Subject: TR: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt 
Date: Tue, 1 Feb 2005 08:21:57 +0100
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>

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