Subject: IETF 56 CCAMP minutes - UPDATE
From: Ron Bonica <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 31 Mar 2003 22:22:56 -0500

Folks,

Please accept the following updated minutes from IETF 56 - CCAMP. There is
one minor change.

                                                   Ron

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

Kireeti: WG status
------------------

Short overview on status of WG documents as listed on web page.

Questions:
- framework for sonet/sdh control draft ready for LC? -> unclear
- LMP MIB to Last Call?
  Bert asked for checkup
  Authors will provide new version and then last call on mailing list
- non-standard sonet/sdh extensions? -> no interest in room
  Bert Wijnen: There is still no document describing what exactly
  is signaled. If that is not provided, this draft should go to wastebin.
  **no referenced document**

Wesam Alanqar: ITU liaison report
---------------------------------

ITU-T SG15 update to ccamp. This presentation has also been sent
to the mailing list.
3 liaison statements exist: ason routing, discovery, restoration/re-routing.

IETF routing experts are invited to come to next ITU meeting.

Dimitri Papadimitriou: Ext. in support of end-to-end GMPLS-based recovery
-------------------------------------------------------------------------

draft-lang-ccamp-gmpls-recovery-e2e-signaling-00

After 1 year of work: terminology starts to be widely adopted,
analysis i-d still too largely scoped.
Still needs to be covered: bulk lsp recovery, reversion (switch back)

Next steps:
next report April 03, func spec ready for LC
Functional spec to be ready for LC *in April'03*
protocol spec expected to be ready in July 03

Should the terminology doc become PS?
- AD will check whether it should be informational or PS

Peter Czezowski: recovery requirements, fault notification protocol and LMP
----------------------------------------------------------------------------

Presenting 3 drafts and changes to them:
- draft-czezowski-optical-recovery-reqs-01.txt
- draft-rabbat-fault-notification-protocol-02.txt
- draft-soumiya-lmp-fault-notification-ext-00.txt

The first 2 drafts believed to be ready. There is running code for
the third draft, but is there any interest?
Comments are requested from mailing list.

George: Changing pt-to-pt protocol to a flooding protocol is more than
	just adding a message. It results in a different implementation
	model for LMP.
Kireeti: Don't start by modifying LMP, first look into problem and
	 requirements. Need mailing list discussion whether LMP is right.
Alex: It took several net meltdowns to learn how to do flooding right.

Dimitri: draft-lang-ccamp-lmp-bootstrap-03
------------------------------------------

Changes: modified J0/J1/J2-16 string to fit within 80 bits,
	 added layer adjacency discovery
Next steps: believes all technical issues raised on the mailing list solved,
accept as wg doc?

Is this a worthwhile LMP extension (apart from questions about format
details)?

Kireeti: needs discussion on list
Jonathan Sadler: mechanism worthwhile, encoding still has problems
Dimitri: suggest to create document with common bootstrap mechanism,
	 then sonet/sdh specific doc, where sonet/sdh encoding specifics would be
specified
Jonathan Lang: is feature desired by community? find out before splitting
	       docs and put more work in it

Question to room: ~7 think it's useful, nobody against -> take to list

George: draft-ietf-ccamp-gmpls-overlay-01
-----------------------------------------

Question to room: "ready for WG LC?":
~20 yes, 0 no
-> check consensus on list
-> start WG last call after meeting

Dimitri: technology specific routing extensions to GMPLS routing
----------------------------------------------------------------

draft-mannie-ccamp-gmpls-sonet-sdh-{ospf,isis}

Changes: discussion concerning bandwidth encoding, section on scalability
and backward compatibility consideration.

Falls within Sonet/SDH basket. Some assertions have been made on list,
addressed one-by-one in the presentation.

Jonathan Sadler: need discussion on list instead of rhetorical questions
here

A layering discussion ensued.

Kireeti: need layer relationship document (refering to the mrn i-d)

Poll of the room: ~15 think it's a useful idea, ~5 against making it wg doc
Kireeti: reasonable support, take to list

Adrian Farrel: GMPLS MIBs
-------------------------

3 drafts became WG drafts in June 02, nothing happened since.
Waiting for MPLS MIBS to go to LC before republishing GMPLS MIBs.
Plan:
  wait for MPLS MIBs republication and LC
  quick editorial respin to bring in line (~4 weeks after MPLS MIBs)
  content additions, republish before Vienna
  chairs would like LC in August (but need WG feedback)

Adrian: draft-lee-ccamp-rsvp-te-exclude-route-01
------------------------------------------------

Why in gmpls?
  think is ccamp charter item, increasing interest (inter-AS/area),
  is mpls extension but is generalized and should be part of GMPLS
Why needed?
  needed where path computation is not only in one place
Changes:
  identification of new work items
Actions:
  got useful feedback
  solicit input from providers
  look for convergence with JP's draft
  WG item?

George: should talk about it in sub-ip directorate meeting

Questions to room:
~15 have read the draft
~20 find it useful
~30 think it should become wg doc in some wg
0 find it not ready

Osama Aboul-Magd: a transport view to LMP
-----------------------------------------

draft-aboulmagd-ccamp-transport-lmp-00.txt

Kireeti: What does control plane discovery mean?
         Is LMP + LMP bootstrap close enough to what this draft does?
	 Very useful spec, provides "language translation".

Malcolm Betts: progress this draft before LMP bootstrap draft

Ron Bonica: generic tunnel tracing
----------------------------------

Requirements doc is stable, WG LC complete.
Time to work on solution, IANA has assigned UDP port,
new context object added.

Solicit feedback from implementers.
Adopt as ccamp work item?

Room poll: ~10 have read the draft -> need to take to list

Ron (for Loa): MPLS and GMPLS change process
--------------------------------------------

Status: lots of lively discussion, topics:
- is this merely a reaffirmation of IETF process?
- what is the role of a liaison?
- when all approvals are not obtained? Is there any alternative
  to the dust bin?

Don Fedyk: need better understanding, common model/language

Monique Morrow: ITU/IETF need to work together

Jerry Ash: document describing liaisons?

Kireeti: there already is such as doc (may be insufficient), separate
	 from this

Bert: liaison process is wider issue (not specific to this WG)

Malcolm Betts: draft fine for IP applications, how about non-IP apps? How
	can get those requirements recognized in IETF?

Ron: requirements must be stated clearly to be understood by IETF WG

Kireeti: Draft documents how ietf process works.
	 The process may need a dust bin for bad ideas and another
	 bin for "not in IETF scope, but not really broken".
	 It is not addressed yet how to handle stuff the IETF doesn't like.

Alex: Need interest by IETF community to make things happen,
      same thing applicable to anyone coming to IETF.
      People need to be convinced.

Bert: subip area initially had problem with too many drafts,
      was fixed by requiring problem statements

Marten: Process is very mature dealing with submissions by individuals,
	but not from other organizations.
	I-Ds not suited to deal with peer standardization organization.
	ITU can't do ascii diagrams or read through mailing list
	to gather IETF opinion.
	Need a way to apply IETF protocols to non-IETF problem.

Kireeti: GMPLS work did step out of traditional ietf scope

George: coopeation would work a lot better if clear requirements would
	be communicated instead of sending in solutions
	(even applies within IETF)

Sharam Davari: another standardization organization should not have
	       same weight as an individual submission

Ron: I-D should be evaluated on its merit, author irrelevant

Kireeti: ccamp charter update
-----------------------------

- not done by WG consensus
- proposed by chairs to AD, AD takes it to IESG/IAB

Alex: correction: WG consensus *is* required but is not enough

under consideration:
- inter-area signaling and routing of generalized paths
   - crackback wrt inter-area
- inter-as on hold until tewg produces requirements
- explicitely put tunnel tracing in charter
- routing extensions for Sonet/SDH
- signaling for G.709 signaling
- further LMP extensions
- optical vpn *not* in charter

milestones:
- GMPLS MIB to WG LC in Aug 03
- protection/restoration functional spec and protocol changes
  to WG LC by Apr and Jul 03 (respectively)
- tunnel tracing protocol to WG LC by Sep 03
- set milestones for inter-area path setup when ratified as charter changes

need active discussion on list

JP: combination of inter-area and inter-as is a good idea

Kireeti: it is great if a common solution is available, but that is not
	 reason enough to put inter-as on charter

Marco: O-VPN started in ITU-T, on ppvpn charter, good chance for cooperation

Kireeti: ccamp should keep an eye on solution

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
                -- Angelo Giuseppe Roncalli

Delivery-date: Mon, 31 Mar 2003 10:30:33 -0800
content-class: urn:content-classes:message
Subject: RE: IETF 56 CCAMP Minutes
Date: Mon, 31 Mar 2003 12:29:32 -0600
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: "Ron Bonica" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, <[email-masked]>

Ron> Kireeti: ccamp charter update
Ron> -----------------------------
Ron> under consideration:
Ron> - inter-area signaling and routing of generalized paths
Ron> - inter-as on hold until tewg produces requirements
Ron> - explicitly put tunnel tracing in charter
Ron> - routing extensions for Sonet/SDH
Ron> - signaling for G.709 signaling
Ron> - further LMP extensions
Ron> - optical vpn *not* in charter

dimitri> a brief additional point looking at the points under
dimitri> charter discussion i'd like to know if "crankback"
dimitri> is within/out the scope or has to be considered only=20
dimitri> in the scope of inter-area effort (if any) ? i say=20
dimitri> this because in yokohama it was explicitly mentioned.

'crankback' was specifically mentioned on Kireeti's charter extension =
slide, so should also be included in the above list.

Thanks,
Jerry

Delivery-date: Mon, 31 Mar 2003 07:48:22 -0800
Date: Mon, 31 Mar 2003 07:46:58 -0800 (PST)
From: Fabio Ricciato <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Enhanced protection
To: Samer Lahoud <[email-masked]>, [email-masked]
Cc: [email-masked]

Hi,

this mail is in the same track about "Enhanced
protection".

We made some work about dual-fault protection,
assuming path-based (-->E2E protection) schemes.
In other words, an active LSP (say Ps) is associated
to *two* backup LSP, Pr1 and Pr2, and they are
opportunely disjoint (i.e. they do not share link /
node / SRLGs).

We also investigated the possibility of applying
sharing of backup bandwdith for such dual-fault
protection scheme.

Could this be considered a form of "enhanced
protection" w.r.t to 1+1 ? 

Fabio Ricciato
University of Rome

--- Samer Lahoud <[email-masked]>
wrote:
> Hi,
> I want to have more information about the ENHANCED
> protection level defined in the GMPLS context : 
> RFC 3471 specifies that it "indicates that a
> protection scheme that is more reliable than
> dedicated 1+1 should be used, 
> e.g., 4 fiber BLSR/MS-SPRING". What do you
> precisesly mean buy this expression (when could we
> confirm that we have enhanced protection level) and
> could i have more examples?
> 
>                                                     
>                                                     
>                                        Regards
> 

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Delivery-date: Mon, 31 Mar 2003 05:19:22 -0800
From: "Samer Lahoud" <[email-masked]>
To: <[email-masked]>
Subject: Enhanced protection
Date: Mon, 31 Mar 2003 15:17:54 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C2F798.B3AEEB30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
I want to have more information about the ENHANCED protection level =
defined in the GMPLS context :=20
RFC 3471 specifies that it "indicates that a protection scheme that is =
more reliable than dedicated 1+1 should be used,=20
e.g., 4 fiber BLSR/MS-SPRING". What do you precisesly mean buy this =
expression (when could we confirm that we have enhanced protection =
level) and could i have more examples?

                                                                         =
                                                                        =
Regards

------=_NextPart_000_000F_01C2F798.B3AEEB30
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.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I want to have more information about =
the ENHANCED=20
protection level defined in the GMPLS&nbsp;context : </FONT></DIV>
<DIV>RFC 3471 specifies that it "indicates that a protection scheme that =
is more=20
reliable than dedicated 1+1 should be used, </DIV>
<DIV>e.g., 4 fiber BLSR/MS-SPRING". What do&nbsp;you precisesly mean buy =
this=20
expression (when could we confirm that we have enhanced protection =
level) and=20
could i have more examples?</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Regards</FONT></DIV></BODY></HTML>

------=_NextPart_000_000F_01C2F798.B3AEEB30--

Delivery-date: Sun, 30 Mar 2003 18:38:14 -0800
Date: Sun, 30 Mar 2003 21:32:31 -0500
From: Ron Bonica <[email-masked]>
Subject: IETF 56 CCAMP minutes
To: [email-masked]

Folks,

I have tried to incorporate all of your comments. I will submit these
minutes along with slides that were displayed.

                                 Ron

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

Kireeti: WG status
------------------

Short overview on status of WG documents as listed on web page.

Questions:
- framework for sonet/sdh control draft ready for LC? -> unclear
- LMP MIB to Last Call?
  Bert asked for checkup
  Authors will provide new version and then last call on mailing list
- non-standard sonet/sdh extensions? -> no interest in room
  Bert Wijnen: There is still no document describing what exactly
  is signaled. If that is not provided, this draft should go to wastebin.
  **no referenced document**

Wesam Alanqar: ITU liaison report
---------------------------------

ITU-T SG15 update to ccamp. This presentation has also been sent
to the mailing list.
3 liaison statements exist: ason routing, discovery, restoration/re-routing.

IETF routing experts are invited to come to next ITU meeting.

Dimitri Papadimitriou: Ext. in support of end-to-end GMPLS-based recovery
-------------------------------------------------------------------------

draft-lang-ccamp-gmpls-recovery-e2e-signaling-00

After 1 year of work: terminology starts to be widely adopted,
analysis i-d still too largely scoped.
Still needs to be covered: bulk lsp recovery, reversion (switch back)

Next steps:
next report April 03, func spec ready for LC
Functional spec to be ready for LC *in April'03*
protocol spec expected to be ready in July 03

Should the terminology doc become PS?
- AD will check whether it should be informational or PS

Peter Czezowski: recovery requirements, fault notification protocol and LMP
----------------------------------------------------------------------------

Presenting 3 drafts and changes to them:
- draft-czezowski-optical-recovery-reqs-01.txt
- draft-rabbat-fault-notification-protocol-02.txt
- draft-soumiya-lmp-fault-notification-ext-00.txt

The first 2 drafts believed to be ready. There is running code for
the third draft, but is there any interest?
Comments are requested from mailing list.

George: Changing pt-to-pt protocol to a flooding protocol is more than
	just adding a message. It results in a different implementation
	model for LMP.
Kireeti: Don't start by modifying LMP, first look into problem and
	 requirements. Need mailing list discussion whether LMP is right.
Alex: It took several net meltdowns to learn how to do flooding right.

Dimitri: draft-lang-ccamp-lmp-bootstrap-03
------------------------------------------

Changes: modified J0/J1/J2-16 string to fit within 80 bits,
	 added layer adjacency discovery
Next steps: believes all technical issues raised on the mailing list solved,
accept as wg doc?

Is this a worthwhile LMP extension (apart from questions about format
details)?

Kireeti: needs discussion on list
Jonathan Sadler: mechanism worthwhile, encoding still has problems
Dimitri: suggest to create document with common bootstrap mechanism,
	 then sonet/sdh specific doc, where sonet/sdh encoding specifics would be
specified
Jonathan Lang: is feature desired by community? find out before splitting
	       docs and put more work in it

Question to room: ~7 think it's useful, nobody against -> take to list

George: draft-ietf-ccamp-gmpls-overlay-01
-----------------------------------------

Question to room: "ready for WG LC?":
~20 yes, 0 no
-> check consensus on list
-> start WG last call after meeting

Dimitri: technology specific routing extensions to GMPLS routing
----------------------------------------------------------------

draft-mannie-ccamp-gmpls-sonet-sdh-{ospf,isis}

Changes: discussion concerning bandwidth encoding, section on scalability
and backward compatibility consideration.

Falls within Sonet/SDH basket. Some assertions have been made on list,
addressed one-by-one in the presentation.

Jonathan Sadler: need discussion on list instead of rhetorical questions
here

A layering discussion ensued.

Kireeti: need layer relationship document (refering to the mrn i-d)

Poll of the room: ~15 think it's a useful idea, ~5 against making it wg doc
Kireeti: reasonable support, take to list

Adrian Farrel: GMPLS MIBs
-------------------------

3 drafts became WG drafts in June 02, nothing happened since.
Waiting for MPLS MIBS to go to LC before republishing GMPLS MIBs.
Plan:
  wait for MPLS MIBs republication and LC
  quick editorial respin to bring in line (~4 weeks after MPLS MIBs)
  content additions, republish before Vienna
  chairs would like LC in August (but need WG feedback)

Adrian: draft-lee-ccamp-rsvp-te-exclude-route-01
------------------------------------------------

Why in gmpls?
  think is ccamp charter item, increasing interest (inter-AS/area),
  is mpls extension but is generalized and should be part of GMPLS
Why needed?
  needed where path computation is not only in one place
Changes:
  identification of new work items
Actions:
  got useful feedback
  solicit input from providers
  look for convergence with JP's draft
  WG item?

George: should talk about it in sub-ip directorate meeting

Questions to room:
~15 have read the draft
~20 find it useful
~30 think it should become wg doc in some wg
0 find it not ready

Osama Aboul-Magd: a transport view to LMP
-----------------------------------------

draft-aboulmagd-ccamp-transport-lmp-00.txt

Kireeti: What does control plane discovery mean?
         Is LMP + LMP bootstrap close enough to what this draft does?
	 Very useful spec, provides "language translation".

Malcolm Betts: progress this draft before LMP bootstrap draft

Ron Bonica: generic tunnel tracing
----------------------------------

Requirements doc is stable, WG LC complete.
Time to work on solution, IANA has assigned UDP port,
new context object added.

Solicit feedback from implementers.
Adopt as ccamp work item?

Room poll: ~10 have read the draft -> need to take to list

Ron (for Loa): MPLS and GMPLS change process
--------------------------------------------

Status: lots of lively discussion, topics:
- is this merely a reaffirmation of IETF process?
- what is the role of a liaison?
- when all approvals are not obtained? Is there any alternative
  to the dust bin?

Don Fedyk: need better understanding, common model/language

Monique Morrow: ITU/IETF need to work together

Jerry Ash: document describing liaisons?

Kireeti: there already is such as doc (may be insufficient), separate
	 from this

Bert: liaison process is wider issue (not specific to this WG)

Malcolm Betts: draft fine for IP applications, how about non-IP apps? How
	can get those requirements recognized in IETF?

Ron: requirements must be stated clearly to be understood by IETF WG

Kireeti: Draft documents how ietf process works.
	 The process may need a dust bin for bad ideas and another
	 bin for "not in IETF scope, but not really broken".
	 It is not addressed yet how to handle stuff the IETF doesn't like.

Alex: Need interest by IETF community to make things happen,
      same thing applicable to anyone coming to IETF.
      People need to be convinced.

Bert: subip area initially had problem with too many drafts,
      was fixed by requiring problem statements

Marten: Process is very mature dealing with submissions by individuals,
	but not from other organizations.
	I-Ds not suited to deal with peer standardization organization.
	ITU can't do ascii diagrams or read through mailing list
	to gather IETF opinion.
	Need a way to apply IETF protocols to non-IETF problem.

Kireeti: GMPLS work did step out of traditional ietf scope

George: coopeation would work a lot better if clear requirements would
	be communicated instead of sending in solutions
	(even applies within IETF)

Sharam Davari: another standardization organization should not have
	       same weight as an individual submission

Ron: I-D should be evaluated on its merit, author irrelevant

Kireeti: ccamp charter update
-----------------------------

- not done by WG consensus
- proposed by chairs to AD, AD takes it to IESG/IAB

Alex: correction: WG consensus *is* required but is not enough

under consideration:
- inter-area signaling and routing of generalized paths
- inter-as on hold until tewg produces requirements
- explicitely put tunnel tracing in charter
- routing extensions for Sonet/SDH
- signaling for G.709 signaling
- further LMP extensions
- optical vpn *not* in charter

milestones:
- GMPLS MIB to WG LC in Aug 03
- protection/restoration functional spec and protocol changes
  to WG LC by Apr and Jul 03 (respectively)
- tunnel tracing protocol to WG LC by Sep 03
- set milestones for inter-area path setup when ratified as charter changes

need active discussion on list

JP: combination of inter-area and inter-as is a good idea

Kireeti: it is great if a common solution is available, but that is not
	 reason enough to put inter-as on charter

Marco: O-VPN started in ITU-T, on ppvpn charter, good chance for cooperation

Kireeti: ccamp should keep an eye on solution

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
                -- Angelo Giuseppe Roncalli

Delivery-date: Sat, 29 Mar 2003 07:39:29 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: FW: Last Call: Generalized Multi-Protocol Label Switching Archite cture to Proposed Standard
Date: Sat, 29 Mar 2003 16:36:23 +0100

FYI 

Thanks,
Bert 

-----Original Message-----
From: IANA [mailto:[email-masked]]
Sent: vrijdag 28 maart 2003 19:36
To: [email-masked]
Cc: [email-masked]
Subject: RE: Last Call: Generalized Multi-Protocol Label Switching
Architecture to Proposed Standard

IESG:

The IANA has reviewed the following Internet-Draft which is in Last
Call: <draft-ietf-ccamp-gmpls-architecture-05.txt>, and has the 
following comments with regards to the publication of this document:

 We understand this document to have no IANA Actions.

Please respond to the IANA if we have misunderstood this
document.  Failing to do so may cause delay of the approval 
and publication of your document.

Thank you.

Michelle S. Cotton
(on behalf of the IANA)

Delivery-date: Fri, 28 Mar 2003 15:59:23 -0800
Subject: Re: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
To: [email-masked] (Brungard, Deborah A, ALABS)
Date: Fri, 28 Mar 2003 15:57:44 -0800 (PST)
Cc: [email-masked] ("Wijnen, Bert (Bert)"), [email-masked], [email-masked], [email-masked]
From: Dimitri Papadimitriou <[email-masked]>

hi deborah,

since you ask fo comment/clarifications, imho your summary 
translates very precisely the current situation - it goes
really to the point - 

also concerning the ansi j1 format, i would suggest that 
you include this comment as part of the meeting response 

thanks,
- dimitri.

> 
> Bert,
> 
> Sorry for the late response, I was out for vacation and just catching =
> up.
> 
> Lacking a formal liaison process for IETF to communicate with T1X1/ITU =
> (hopefully we will have a process soon;-)), I think the best approach to =
> handle your request will be for me to upload the draft to the t1x15 =
> files. As we have a meeting next week, I will introduce the draft for =
> discussion and provide you with a response asap.
> 
> At our September meeting, Jonathan was able to attend and present the =
> IETF lmp bootstrap proposal. It was extremely helpful to have him there, =
> as we all know, the difference in our terminology can be fatal to =
> communication. Lacking LMP representation at next week's meeting, it =
> would be helpful to ensure we understand your request. My understanding =
> is your request is to understand if there are any issues with the use of =
> the sonet-sdh overhead bytes as proposed by LMP. To help T1X1.5 =
> understand the application, I've summarized as follows. Please =
> comment/clarify if I have misunderstood.
> 
> - lmp-test-sonet-sdh is a GMPLS protocol-specific method to manage GMPLS =
> control plane neighboring nodes. Management includes managing of the =
> GMPLS control channel and TE links (GMPLS control plane logical =
> constructs).
> 
> - LMP test messages are defined for link verification and correlation. =
> Two options are defined, one using the Jx bytes, the other using an =
> "out-of-band" trace correlation. The out-of-band trace correlation =
> (using the LMP control channel) has no impact on the Jx bytes, Jx use is =
> per the currently defined T1.105/G.707 Access Point Identifier =
> application. In addition, a trace monitor capability is defined to =
> detect mis-connections, this capability also uses the currently defined =
> G.707/G.783 Jx and trace mismatch process.
> 
> - "in-band" test messages using the Jx bytes are defined based on the =
> G.707 16-byte multi-frame. The test messages are used to identify GMPLS =
> links i.e. populate the GMPLS database as links available for use =
> (routing/signalling). This process is a pre-service application i.e. the =
> method is used to determine the available links to use for routing user =
> traffic (i.e. the links are not carrying user traffic during this test =
> phase). Whereas the G.707/T1.105 Jx Access Point Identifier is an =
> "in-service" application.
> 
> - an earlier draft version included the 64-byte J1 format. Was it =
> intentionally or unintentionally deleted as part of the updates to =
> remove the incorrect reference for the 64-byte J0? The 64-byte J1 is the =
> ANSI defined format. The 16-byte format support is considered optional =
> to support international applications.
> 
> - LMP link verification and correlation are GMPLS-specific i.e. =
> different application than the G.7714.1 layer adjacency discovery.
> 
> Thanks,
> Deborah
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Tuesday, March 18, 2003 6:13 PM
> To: Dimitri Papadimitriou; [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
> 
> 
> Dimitri says:
> > hi steve,
> > =20
> > > All,
> > > Bert asked me to have a look at this from an ITU-T perspective.
> >=20
> > what does that really mean ?
> >=20
> This means that I got an IETF document from one of the WGs for which
> I am the responsible AD. It also means that this document is about
> using SONET/SDH overhead bytes, which I think are under control of ITU.
> So I want to check for such type of documents if there are issues
> from the "owning SDO" with the proposed use of such overhead bytes
> 
> Seems to be doing due diligence on my part.
> 
> And since Steve is often (one of) the interface people from SG15
> to IETF (he is vice chair of SG15), that is why I asked him.
> 
> I also asked Deborah Brungard (T1X1) with the same question.
> 
> Hope this explains.
> Bert
> 
> 
> 

Delivery-date: Fri, 28 Mar 2003 14:23:46 -0800
Date: Fri, 28 Mar 2003 23:21:36 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: rizwan merchant <[email-masked]>
CC: [email-masked]
Subject: Re: How are SONET/SDH labels (SUKLM fields)  calculated.

hi,

> I would like to know that given a SONET/SDH traffic params, how would
> downstream LSR
> calculate label values (SUKLM values).

label "values" are pre-determined by the sonet/sdh multiplexing 
structure (pointing you to G.707/T1.105 here), downstream lsr 
label allocation depends on the request type

> I have gone through RFC draft-ietf-ccamp-gmpls-sonet-sdh-07.txt, but
> couldn't
> corelate the values of SUKLM fields to the traffic params.

i give you here an example in order to help when setting up 
a VC-4 over an STM-4 (like a zoom here between two nodes):

an lsr desires to setup a single VC-4 lsp, the traffic parameters
takes the following values: RCC = 0, NCC = 0, NVC = 0, MT = 1 and 
T = 0 which applies to a VC-4 elementary signal (signal type = 6), 
and for instance the label that this node will receive back takes 
the following value S=2,U=0,K=0,L=0,M=0 meaning that the second 
AUG-1 has been selected in the STM-4 multiplex structure 

> Am I missing something, or need to read some more info on SONET/SDH as I am
> new on
> this topic. In that case any pointers would definitely help.

there is a framework on the subject that may help you but you 
can also take a look at the gmpls architecture that introduces 
the protocol context (pointers available on the ccamp wg webpage)

hope this will help,
- dimitri.

> Any help would be highly appreciated.
> 
> TIA.
> 
> Best Regards,
> RA Merchant.
> 
> _________________________________________________________________
> Cricket World Cup 2003- News, Views and Match Reports.
> http://server1.msn.co.in/msnspecials/worldcup03/

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Fri, 28 Mar 2003 13:54:27 -0800
content-class: urn:content-classes:message
Subject: RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
Date: Fri, 28 Mar 2003 16:53:17 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Bert,

Sorry for the late response, I was out for vacation and just catching =
up.

Lacking a formal liaison process for IETF to communicate with T1X1/ITU =
(hopefully we will have a process soon;-)), I think the best approach to =
handle your request will be for me to upload the draft to the t1x15 =
files. As we have a meeting next week, I will introduce the draft for =
discussion and provide you with a response asap.

At our September meeting, Jonathan was able to attend and present the =
IETF lmp bootstrap proposal. It was extremely helpful to have him there, =
as we all know, the difference in our terminology can be fatal to =
communication. Lacking LMP representation at next week's meeting, it =
would be helpful to ensure we understand your request. My understanding =
is your request is to understand if there are any issues with the use of =
the sonet-sdh overhead bytes as proposed by LMP. To help T1X1.5 =
understand the application, I've summarized as follows. Please =
comment/clarify if I have misunderstood.

- lmp-test-sonet-sdh is a GMPLS protocol-specific method to manage GMPLS =
control plane neighboring nodes. Management includes managing of the =
GMPLS control channel and TE links (GMPLS control plane logical =
constructs).

- LMP test messages are defined for link verification and correlation. =
Two options are defined, one using the Jx bytes, the other using an =
"out-of-band" trace correlation. The out-of-band trace correlation =
(using the LMP control channel) has no impact on the Jx bytes, Jx use is =
per the currently defined T1.105/G.707 Access Point Identifier =
application. In addition, a trace monitor capability is defined to =
detect mis-connections, this capability also uses the currently defined =
G.707/G.783 Jx and trace mismatch process.

- "in-band" test messages using the Jx bytes are defined based on the =
G.707 16-byte multi-frame. The test messages are used to identify GMPLS =
links i.e. populate the GMPLS database as links available for use =
(routing/signalling). This process is a pre-service application i.e. the =
method is used to determine the available links to use for routing user =
traffic (i.e. the links are not carrying user traffic during this test =
phase). Whereas the G.707/T1.105 Jx Access Point Identifier is an =
"in-service" application.

- an earlier draft version included the 64-byte J1 format. Was it =
intentionally or unintentionally deleted as part of the updates to =
remove the incorrect reference for the 64-byte J0? The 64-byte J1 is the =
ANSI defined format. The 16-byte format support is considered optional =
to support international applications.

- LMP link verification and correlation are GMPLS-specific i.e. =
different application than the G.7714.1 layer adjacency discovery.

Thanks,
Deborah

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, March 18, 2003 6:13 PM
To: Dimitri Papadimitriou; [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt

Dimitri says:
> hi steve,
> =20
> > All,
> > Bert asked me to have a look at this from an ITU-T perspective.
>=20
> what does that really mean ?
>=20
This means that I got an IETF document from one of the WGs for which
I am the responsible AD. It also means that this document is about
using SONET/SDH overhead bytes, which I think are under control of ITU.
So I want to check for such type of documents if there are issues
from the "owning SDO" with the proposed use of such overhead bytes

Seems to be doing due diligence on my part.

And since Steve is often (one of) the interface people from SG15
to IETF (he is vice chair of SG15), that is why I asked him.

I also asked Deborah Brungard (T1X1) with the same question.

Hope this explains.
Bert

Delivery-date: Fri, 28 Mar 2003 09:32:17 -0800
Date: Fri, 28 Mar 2003 18:30:15 +0100
From: [email-masked]
Reply-To: [email-masked]
Organization: Alcatel
To: Ron Bonica <[email-masked]>
CC: [email-masked]
Subject: Re: IETF 56 CCAMP Minutes

--------------821950E7E76C67F3E20D2C39
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Ron and all,
Concerning the CCAMP charter update and following discussions on (inter)lay=
ering
issues,
Kireeti mentioned at the end of the session a request -to ADs- to include t=
his
topic within the charter.
(I didn't note the exact words)
May I suggest to add this helpful information for the community in the minu=
tes.

regards.

Emmanuel

Ron Bonica a =E9crit :

> Folks,
>
> Attached are IETF 56 CCAMP minutes. Thanks to Markus Jork for taking note=
s.
> If there are no objections posted to the list by next week, I will submit
> the minutes as recorded by Markus.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Kireeti: WG status
> ------------------
>
> Short overview on status of WG documents as listed on web page.
>
> Questions:
> - framework for sonet/sdh control draft ready for LC? -> unclear
> - LMP MIB to LC?
>   Some in room think it's ready (nobody disagrees) -> take to mailing list
> - non-standard sonet/sdh extensions? -> no interest in room
>   Bert Wijnen: There is still no document describing what exactly
>   is signaled. If that is not provided, this draft should go to wastebin.
>
> Wesam Alanqar: ITU liaison report
> ---------------------------------
>
> ITU-T SG15 update to ccamp. This presentation has also been sent
> to the mailing list.
> 3 liaison statements exist: ason routing, discovery, restoration/re-routi=
ng.
>
> IETF routing experts are invited to come to next ITU meeting.
>
> Dimitri Papadimitriou: Ext. in support of end-to-end GMPLS-based recovery
> -------------------------------------------------------------------------
>
> draft-lang-ccamp-gmpls-recovery-e2e-signaling-00
>
> After 1 year of work: terminology starts to be widely adopted,
> analysis i-d still too largely scoped.
> Still needs to be covered: bulk lsp recovery, reversion (switch back)
>
> Next steps:
> next report April 03, func spec ready for LC
> protocol spec expected to be ready in July
>
> Should the terminology doc become PS?
>
> Peter Czezowski: recovery requirements, fault notification protocol and L=
MP
> -------------------------------------------------------------------------=
---
>
> Presenting 3 drafts and changes to them:
> - draft-czezowski-optical-recovery-reqs-01.txt
> - draft-rabbat-fault-notification-protocol-02.txt
> - draft-soumiya-lmp-fault-notification-ext-00.txt
>
> The first 2 drafts believed to be ready. There is running code for
> the third draft, but is there any interest?
> Comments are requested from mailing list.
>
> George: Changing pt-to-pt protocol to a flooding protocol is more than
>         just adding a message. It results in a different implementation
>         model for LMP.
> Kireeti: Don't start by modfying LMP, first look into problem and
>          requirements. Need mailing list discussion whether LMP is right.
> Alex: It took several net meltdowns to learn how to do flooding right.
>
> Dimitri: draft-lang-ccamp-lmp-bootstrap-03
> ------------------------------------------
>
> Changes: modified J0/J1/J2-16 string to fit within 80 bits,
>          added layer adjacency discovery
> Next steps: believes all technical issues solved, accept as wg doc?
>
> Is this a worthwhile LMP extension (apart from questions about format
> details)?
>
> Kireeti: needs discussion on list
> Jonathan(?): mechanism worthwhile, encoding still has problems
> Dimitri: suggest to create document with common bootstrap mechanism,
>          then sonet/sdh specific doc
> Jonathan Lang: is feature desired by community? find out before splitting
>                docs and put more work in it
>
> Question to room: ~7 think it's useful, nobody against -> take to list
>
> George: draft-ietf-ccamp-gmpls-overlay-01
> -----------------------------------------
>
> Question to room: "ready for WG LC?":
> ~20 yes, 0 no
> -> check consensus on list
>
> Dimitri: technology specific routing extensions to GMPLS routing
> ----------------------------------------------------------------
>
> draft-mannie-ccamp-gmpls-sonet-sdh-{ospf,isis}
>
> Changes: discussion concerning bandwidth encoding, section on scalability
> and backward compatibility consideration.
>
> Falls within Sonet/SDH basket. Some assertions have been made on list,
> addressed one-by-one in the presentation.
>
> Jonathan(?): need discussion on list instead of rhetorical questions here
>
> A layering discussion ensued.
>
> Kireeti: need layer relationship document
>
> Poll of the room: ~15 think it's a useful idea, ~5 against making it wg d=
oc
> Kireeti: reasonable support, take to list
>
> Adrian Farell: GMPLS MIBs
> -------------------------
>
> 3 drafts became WG drafts in June 02, nothing happened since.
> Waiting for MPLS MIBS to go to LC before republishing GMPLS MIBs.
> Plan:
>   wait for MPLS MIBs republication and LC
>   quick editorial respin to bring in line (~4 weeks after MPLS MIBs)
>   content additions, republish before Vienna
>   chairs would like LC in August (but need WG feedback)
>
> Adrian: draft-lee-ccamp-rsvp-te-exclude-route-01
> ------------------------------------------------
>
> Why in gmpls?
>   think is ccmap charter item, increasing interest (inter-AS/area),
>   is mpls extension but is generalized and should be part of GMPLS
> Why needed?
>   needed where path computation is not only in one place
> Changes:
>   identification of new work items
> Actions:
>   got useful feedback
>   solicit input from providers
>   look for convergence with JP's draft
>   WG item?
>
> George: should talk about it in ??? meeting
>
> Questions to room:
> ~15 have read the draft
> ~20 find it useful
> ~30 think it should become wg doc in some wg
> 0 find it not ready
>
> Osama Aboul-Magd: a transport view to LMP
> -----------------------------------------
>
> draft-aboulmagd-ccamp-transport-lmp-00.txt
>
> Kireeti: What does control plane discovery mean?
>          Is LMP + LMP bootstrap close enough to what this draft does?
>          Very useful spec, provides "language translation".
>
> Marten: progress this draft before LMP bootstrap draft
>
> Ron Bonica: generic tunnel tracing
> ----------------------------------
>
> Requirements doc is stable, WG LC complete.
> Time to work on solution, IANA has assigned UDP port,
> new context object added.
>
> Solicit feedback from implementers.
> Adopt as ccamp work item?
>
> Room poll: ~10 have read the draft -> need to take to list
>
> Ron (for Loa): MPLS and GMPLS change process
> --------------------------------------------
>
> Status: lots of lively discussion, topics:
> - is this merely a reaffirmation of IETF process?
> - what is the role of a liaison?
> - when all approvals are not obtained? Is there any alternative
>   to the dust bin?
>
> Don Fedyk: need better understanding, common model/language
>
> Monique Morrow(?): ITU/IETF need to work together
>
> Jerry Ash: document describing liaisons?
>
> Kireeti: there already is such as doc (may be insufficient), separate
>          from this
>
> Bert: liaison process is wider issue (not specific to this WG)
>
> Marten: draft fine for IP applications, how about non-IP apps? How
>         can get those requirements recognized in IETF?
>
> Ron: requirements must be stated clearly to be understood by IETF WG
>
> Kireeti: Draft documents how ietf process works.
>          The process may need a dust bin for bad ideas and another
>          bin for "not in IETF scope, but not really broken".
>          It is not addressed yet how to handle stuff the IETF doesn't lik=
e.
>
> Alex: Need interest by IETF community to make things happen,
>       same thing applicable to anyone coming to IETF.
>       People need to be convinced.
>
> Bert: subip area initially had problem with too many drafts,
>       was fixed by requiring problem statements
>
> Marten: Process is very mature dealing with submissions by individuals,
>         but not from other organizations.
>         I-Ds not suited to deal with peer standardization organization.
>         ITU can't do ascii diagrams or read through mailing list
>         to gather IETF opinion.
>         Need a way to apply IETF protocols to non-IETF problem.
>
> Kireeti: GMPLS work did step out of traditional ietf scope
>
> George: coopeation would work a lot better if clear requirements would
>         be communicated instead of sending in solutions
>         (even applies within IETF)
>
> Sharam Davari: another standardization organization should not have
>                same weight as an individual submission
>
> Ron: I-D should be evaluated on its merit, author irrelevant
>
> Kireeti: ccamp charter update
> -----------------------------
>
> - not done by WG consensus
> - proposed by chairs to AD, AD takes it to IESG/IAB
>
> Alex: correction: WG consensus *is* required but is not enough
>
> under consideration:
> - inter-area signaling and routing of generalized paths
> - inter-as on hold until tewg produces requirements
> - explicitely put tunnel tracing in charter
> - routing extensions for Sonet/SDH
> - signaling for G.709 signaling
> - further LMP extensions
> - optical vpn *not* in charter
>
> milestones:
> - GMPLS MIB to WG LC in Aug 03
> - protection/restoration functional spec and protocol changes
>   to WG LC by Apr and Jul 03 (respectively)
> - tunnel tracing protocol to WG LC by Sep 03
> - set milestones for inter-area path setup when ratified as charter chang=
es
>
> need active discussion on list
>
> JP: combination of inter-area and inter-as is a good idea
>
> Kireeti: it is great if a common solution is available, but that is not
>          reason enough to put inter-as on charter
>
> Marco: O-VPN started in ITU-T, on ppvpn charter, good chance for cooperat=
ion
>
> Kireeti: ccamp should keep an eye on solution
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> "We are not on Earth to guard a museum, but
> to cultivate a flourishing garden of life."
>                 -- Angelo Giuseppe Roncalli

--------------821950E7E76C67F3E20D2C39
Content-Transfer-Encoding: 7bit
Content-Type: text/x-vcard; charset=us-ascii;
 name="Emmanuel.Dotaro.vcf"
Content-Description: Carte pour Emmanuel Dotaro
Content-Disposition: attachment;
 filename="Emmanuel.Dotaro.vcf"

begin:vcard 
n:Dotaro;Emmanuel
tel;fax:+33 1 69631865
tel;work:+33 1 69634723
x-mozilla-html:FALSE
org:Alcatel;CTO/Research & Innovation
adr:;;Route de Nozay;Marcoussis;;91461;FRANCE
version:2.1
email;internet:[email-masked]
fn:Emmanuel Dotaro
end:vcard

--------------821950E7E76C67F3E20D2C39--

Delivery-date: Thu, 27 Mar 2003 16:04:30 -0800
Date: Fri, 28 Mar 2003 01:01:16 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: Ron Bonica <[email-masked]>
CC: [email-masked]
Subject: Re: IETF 56 CCAMP Minutes

hi ron, all,

a brief additional point looking at the points under
charter discussion i'd like to know if "crankback"
is within/out the scope or has to be considered only 
in the scope of inter-area effort (if any) ? i say 
this because in yokohama it was explicitly mentioned.

thanks,
- dimitri.

Ron Bonica wrote:
> 
> Folks,
> 
> Attached are IETF 56 CCAMP minutes. Thanks to Markus Jork for taking notes.
> If there are no objections posted to the list by next week, I will submit
> the minutes as recorded by Markus.
> 
> ============================================
> 
> Kireeti: WG status
> ------------------
> 
> Short overview on status of WG documents as listed on web page.
> 
> Questions:
> - framework for sonet/sdh control draft ready for LC? -> unclear
> - LMP MIB to LC?
>   Some in room think it's ready (nobody disagrees) -> take to mailing list
> - non-standard sonet/sdh extensions? -> no interest in room
>   Bert Wijnen: There is still no document describing what exactly
>   is signaled. If that is not provided, this draft should go to wastebin.
> 
> Wesam Alanqar: ITU liaison report
> ---------------------------------
> 
> ITU-T SG15 update to ccamp. This presentation has also been sent
> to the mailing list.
> 3 liaison statements exist: ason routing, discovery, restoration/re-routing.
> 
> IETF routing experts are invited to come to next ITU meeting.
> 
> Dimitri Papadimitriou: Ext. in support of end-to-end GMPLS-based recovery
> -------------------------------------------------------------------------
> 
> draft-lang-ccamp-gmpls-recovery-e2e-signaling-00
> 
> After 1 year of work: terminology starts to be widely adopted,
> analysis i-d still too largely scoped.
> Still needs to be covered: bulk lsp recovery, reversion (switch back)
> 
> Next steps:
> next report April 03, func spec ready for LC
> protocol spec expected to be ready in July
> 
> Should the terminology doc become PS?
> 
> Peter Czezowski: recovery requirements, fault notification protocol and LMP
> ----------------------------------------------------------------------------
> 
> Presenting 3 drafts and changes to them:
> - draft-czezowski-optical-recovery-reqs-01.txt
> - draft-rabbat-fault-notification-protocol-02.txt
> - draft-soumiya-lmp-fault-notification-ext-00.txt
> 
> The first 2 drafts believed to be ready. There is running code for
> the third draft, but is there any interest?
> Comments are requested from mailing list.
> 
> George: Changing pt-to-pt protocol to a flooding protocol is more than
>         just adding a message. It results in a different implementation
>         model for LMP.
> Kireeti: Don't start by modfying LMP, first look into problem and
>          requirements. Need mailing list discussion whether LMP is right.
> Alex: It took several net meltdowns to learn how to do flooding right.
> 
> Dimitri: draft-lang-ccamp-lmp-bootstrap-03
> ------------------------------------------
> 
> Changes: modified J0/J1/J2-16 string to fit within 80 bits,
>          added layer adjacency discovery
> Next steps: believes all technical issues solved, accept as wg doc?
> 
> Is this a worthwhile LMP extension (apart from questions about format
> details)?
> 
> Kireeti: needs discussion on list
> Jonathan(?): mechanism worthwhile, encoding still has problems
> Dimitri: suggest to create document with common bootstrap mechanism,
>          then sonet/sdh specific doc
> Jonathan Lang: is feature desired by community? find out before splitting
>                docs and put more work in it
> 
> Question to room: ~7 think it's useful, nobody against -> take to list
> 
> George: draft-ietf-ccamp-gmpls-overlay-01
> -----------------------------------------
> 
> Question to room: "ready for WG LC?":
> ~20 yes, 0 no
> -> check consensus on list
> 
> Dimitri: technology specific routing extensions to GMPLS routing
> ----------------------------------------------------------------
> 
> draft-mannie-ccamp-gmpls-sonet-sdh-{ospf,isis}
> 
> Changes: discussion concerning bandwidth encoding, section on scalability
> and backward compatibility consideration.
> 
> Falls within Sonet/SDH basket. Some assertions have been made on list,
> addressed one-by-one in the presentation.
> 
> Jonathan(?): need discussion on list instead of rhetorical questions here
> 
> A layering discussion ensued.
> 
> Kireeti: need layer relationship document
> 
> Poll of the room: ~15 think it's a useful idea, ~5 against making it wg doc
> Kireeti: reasonable support, take to list
> 
> Adrian Farell: GMPLS MIBs
> -------------------------
> 
> 3 drafts became WG drafts in June 02, nothing happened since.
> Waiting for MPLS MIBS to go to LC before republishing GMPLS MIBs.
> Plan:
>   wait for MPLS MIBs republication and LC
>   quick editorial respin to bring in line (~4 weeks after MPLS MIBs)
>   content additions, republish before Vienna
>   chairs would like LC in August (but need WG feedback)
> 
> Adrian: draft-lee-ccamp-rsvp-te-exclude-route-01
> ------------------------------------------------
> 
> Why in gmpls?
>   think is ccmap charter item, increasing interest (inter-AS/area),
>   is mpls extension but is generalized and should be part of GMPLS
> Why needed?
>   needed where path computation is not only in one place
> Changes:
>   identification of new work items
> Actions:
>   got useful feedback
>   solicit input from providers
>   look for convergence with JP's draft
>   WG item?
> 
> George: should talk about it in ??? meeting
> 
> Questions to room:
> ~15 have read the draft
> ~20 find it useful
> ~30 think it should become wg doc in some wg
> 0 find it not ready
> 
> Osama Aboul-Magd: a transport view to LMP
> -----------------------------------------
> 
> draft-aboulmagd-ccamp-transport-lmp-00.txt
> 
> Kireeti: What does control plane discovery mean?
>          Is LMP + LMP bootstrap close enough to what this draft does?
>          Very useful spec, provides "language translation".
> 
> Marten: progress this draft before LMP bootstrap draft
> 
> Ron Bonica: generic tunnel tracing
> ----------------------------------
> 
> Requirements doc is stable, WG LC complete.
> Time to work on solution, IANA has assigned UDP port,
> new context object added.
> 
> Solicit feedback from implementers.
> Adopt as ccamp work item?
> 
> Room poll: ~10 have read the draft -> need to take to list
> 
> Ron (for Loa): MPLS and GMPLS change process
> --------------------------------------------
> 
> Status: lots of lively discussion, topics:
> - is this merely a reaffirmation of IETF process?
> - what is the role of a liaison?
> - when all approvals are not obtained? Is there any alternative
>   to the dust bin?
> 
> Don Fedyk: need better understanding, common model/language
> 
> Monique Morrow(?): ITU/IETF need to work together
> 
> Jerry Ash: document describing liaisons?
> 
> Kireeti: there already is such as doc (may be insufficient), separate
>          from this
> 
> Bert: liaison process is wider issue (not specific to this WG)
> 
> Marten: draft fine for IP applications, how about non-IP apps? How
>         can get those requirements recognized in IETF?
> 
> Ron: requirements must be stated clearly to be understood by IETF WG
> 
> Kireeti: Draft documents how ietf process works.
>          The process may need a dust bin for bad ideas and another
>          bin for "not in IETF scope, but not really broken".
>          It is not addressed yet how to handle stuff the IETF doesn't like.
> 
> Alex: Need interest by IETF community to make things happen,
>       same thing applicable to anyone coming to IETF.
>       People need to be convinced.
> 
> Bert: subip area initially had problem with too many drafts,
>       was fixed by requiring problem statements
> 
> Marten: Process is very mature dealing with submissions by individuals,
>         but not from other organizations.
>         I-Ds not suited to deal with peer standardization organization.
>         ITU can't do ascii diagrams or read through mailing list
>         to gather IETF opinion.
>         Need a way to apply IETF protocols to non-IETF problem.
> 
> Kireeti: GMPLS work did step out of traditional ietf scope
> 
> George: coopeation would work a lot better if clear requirements would
>         be communicated instead of sending in solutions
>         (even applies within IETF)
> 
> Sharam Davari: another standardization organization should not have
>                same weight as an individual submission
> 
> Ron: I-D should be evaluated on its merit, author irrelevant
> 
> Kireeti: ccamp charter update
> -----------------------------
> 
> - not done by WG consensus
> - proposed by chairs to AD, AD takes it to IESG/IAB
> 
> Alex: correction: WG consensus *is* required but is not enough
> 
> under consideration:
> - inter-area signaling and routing of generalized paths
> - inter-as on hold until tewg produces requirements
> - explicitely put tunnel tracing in charter
> - routing extensions for Sonet/SDH
> - signaling for G.709 signaling
> - further LMP extensions
> - optical vpn *not* in charter
> 
> milestones:
> - GMPLS MIB to WG LC in Aug 03
> - protection/restoration functional spec and protocol changes
>   to WG LC by Apr and Jul 03 (respectively)
> - tunnel tracing protocol to WG LC by Sep 03
> - set milestones for inter-area path setup when ratified as charter changes
> 
> need active discussion on list
> 
> JP: combination of inter-area and inter-as is a good idea
> 
> Kireeti: it is great if a common solution is available, but that is not
>          reason enough to put inter-as on charter
> 
> Marco: O-VPN started in ITU-T, on ppvpn charter, good chance for cooperation
> 
> Kireeti: ccamp should keep an eye on solution
> 
> ===========================================
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> ===========================================
> "We are not on Earth to guard a museum, but
> to cultivate a flourishing garden of life."
>                 -- Angelo Giuseppe Roncalli

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Thu, 27 Mar 2003 15:41:21 -0800
Date: Fri, 28 Mar 2003 00:37:07 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: Consensus to progress documents

1. (*) - 2. Y - 3. (**) - 4. Y

note 1 (*): i've heard different voices during the meeting and i'd
like first to clarify them :useful but encoding issues - where are 
these encoding issues ? and compared to what ? work first on an 
architecture document and then come up with a solution ? which 
architecture ? and from which perspective ?) anyway i think this 
document addresses perfectly one of the comments made during on 
applicability of discovery (see below)

note 2 (**): on 3. some sentences needs to be clarified before 
imho moving forward (they follow some of the remarks made 
by john last friday):

"LMP was developed with a IP framework in mind. However many transport 
 elements do not support IP natively and as a result the concepts of 
 LMP need to be adapted to the transport world."

-> see gmpls-arch "LMP is defined in the context of GMPLS, but is 
   specified independently of the GMPLS protocol suite [...]
   Consequently, LMP can be used in other contexts with non-GMPLS
   protocols."

"One fundamental difference between LMP and G.8080 discovery frame 
 work is the absence of the explicit separation between transport 
 and control plane names."

[...] "the TCP ID in G.7714.1 is a transport layer ID that may or 
   may not use any of those format."
 
-> this is why the data plane "name" space is part of the <TRACE> 
   object, this separation is currently delivered by lmp sonet-sdh
   (and has been extended to other technologies such as oth), when
   separation between data and control plane name space is provided 
   using for the former a value space other than IPv4/IPv6/Unnum,
   the Trace Correlation mechanism does the job

=> this relates to the comment we received "discovery as defined
   by itu is a data plane application" therefore bi-directional
   trace correlation mechanism proposed in the bootstrap i-d 
   makes perfectly the job here - this means that if the bootstrap
   doesn't fly beyond the last meeting a dedicated i-d describing 
   this method would be the way to go -

thanks,
- dimitri.
   
---

Kireeti Kompella wrote:
> 
> Hi,
> 
> As decided in the CCAMP 56 meeting, we are taking the following to
> the list for consensus to make WG documents.  Please indicate your
> response for each (Y=make it a CCAMP WG doc; N=not; -=don't care):
> 
> 1. draft-lang-ccamp-lmp-bootstrap-03.txt
> 
> 2. draft-mannie-ccamp-gmpls-sonet-sdh-{ospf,isis}
> 
> 3. draft-aboulmagd-ccamp-transport-lmp-00.txt
> 
> 4. draft-bonica-tunproto-04.txt
> 
> Thanks,
> Kireeti.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Envelope-to: [email-masked]
Delivery-date: Thu, 27 Mar 2003 11:25:13 -0800
Message-Id: <[email-masked]>
To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Generalized Multi-Protocol Label Switching  Architecture to Proposed Standard
Reply-to: [email-masked]
Date: Thu, 27 Mar 2003 14:20:45 -0500

The IESG has received a request from the Common Control and Measurement 
Plane Working Group to consider Generalized Multi-Protocol Label 
Switching Architecture <draft-ietf-ccamp-gmpls-architecture-05.txt> 
as a Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
[email-masked] or [email-masked] mailing lists by 2003-4-10.

Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-05.txt

Delivery-date: Thu, 27 Mar 2003 04:52:16 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-08.txt
Date: Thu, 27 Mar 2003 07:45:56 -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		: Link Management Protocol (LMP)
	Author(s)	: J. Lang
	Filename	: draft-ietf-ccamp-lmp-08.txt
	Pages		: 74
	Date		: 2003-3-26
	
For scalability purposes, multiple data links can be combined to 
form a single traffic engineering (TE) link.  Furthermore, the 
management of TE links is not restricted to in-band messaging, but 
instead can be done using out-of-band techniques.  This document 
specifies a link management protocol (LMP) that runs between 
neighboring nodes and is used to manage TE links.  Specifically, LMP 
will be used to maintain control channel connectivity, verify the 
physical connectivity of the data links, correlate the link property 
information, suppress downstream alarms, and localize link failures 
for protection/restoration purposes in multiple kinds of networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-lmp-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-lmp-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-lmp-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-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: Thu, 27 Mar 2003 04:52:08 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt
Date: Thu, 27 Mar 2003 07:46:05 -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		: SONET/SDH Encoding for Link Management Protocol (LMP) 
                          Test messages
	Author(s)	: J. Lang, D. Papadimitriou
	Filename	: draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt
	Pages		: 16
	Date		: 2003-3-26
	
This document details the Synchronous Optical NETwork (SONET)/ 
Synchronous Digital Hierarchy (SDH) technology specific information 
needed when sending Link Management Protocol (LMP) test messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-lmp-test-sonet-sdh-02.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--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-lmp-test-sonet-sdh-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-test-sonet-sdh-02.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, 27 Mar 2003 04:51:59 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-wdm-02.txt
Date: Thu, 27 Mar 2003 07:46:01 -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		: Link Management Protocol (LMP) for Dense Wavelength 
                          Division Multiplexing (DWDM) Optical Line Systems
	Author(s)	: A. Fredette, J. Lang
	Filename	: draft-ietf-ccamp-lmp-wdm-02.txt
	Pages		: 16
	Date		: 2003-3-26
	
The Link Management Protocol (LMP) is defined to manage traffic 
engineering (TE) links.  In its present form, LMP focuses on peer 
nodes; i.e., nodes that peer in signaling and/or routing.  In this 
document we propose extensions to LMP to allow it to be used between 
a peer node and an adjacent optical line system (OLS).  These 
extensions are intended to satisfy the 'Optical Link Interface 
Requirements' described in a companion document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-wdm-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-lmp-wdm-02.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lmp-wdm-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--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-lmp-wdm-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-wdm-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 25 Mar 2003 17:05:47 -0800
From: "rizwan merchant" <[email-masked]>
To: [email-masked]
Subject: How are SONET/SDH labels (SUKLM fields)  calculated.
Date: Tue, 25 Mar 2003 12:03:50 +0000

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi friends,

I would like to know that given a SONET/SDH traffic params, how would 
downstream LSR
calculate label values (SUKLM values).

I have gone through RFC draft-ietf-ccamp-gmpls-sonet-sdh-07.txt, but 
couldn't
corelate the values of SUKLM fields to the traffic params.

Am I missing something, or need to read some more info on SONET/SDH as I am 
new on
this topic. In that case any pointers would definitely help.

Any help would be highly appreciated.

TIA.

Best Regards,
RA Merchant.

_________________________________________________________________
Cricket World Cup 2003- News, Views and Match Reports. 
http://server1.msn.co.in/msnspecials/worldcup03/

Delivery-date: Tue, 25 Mar 2003 16:55:26 -0800
From: "Jonathan Lang" <[email-masked]>
To: "'Wijnen, Bert \(Bert\)'" <[email-masked]>, "'Ccamp-wg \(E-mail\)'" <[email-masked]>
Subject: RE: AD review of: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
Date: Tue, 25 Mar 2003 13:07:47 -0800

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Bert,
 We have addressed your comments (see inline) and have uploaded the
updated version.

-Jonathan & co-authors

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Wijnen, Bert (Bert)
> Sent: Thursday, March 13, 2003 2:12 PM
> To: Ccamp-wg (E-mail)
> Subject: AD review of: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
> 
> Here are my comments. Pls address them and do a quick
> revision. I do not intend to issue IETF Last Call before
> IETF meeting in SF is over.
> 
> - 2nd para in sect 1
>   s/is being developed/has been developed/ ??
changed to read "has been developed"

> - You have 16-bit fields for which you specify values as:
>     0x01
>     0x02
>     ...
>   And it is then not clear (to me) which bit you actually mean
>   Maybe better to do:
>    0x0001
>    0x0002
>    ...
done

> - I see a few times "Note that no change is required to the
>   TestsStatusSuccess and TestStatusFailure messages".
>   That however seems very obvious, because they will ALWAYS go
>   over the control channel. I think there is never a change to
>   those messages is there... but with making this statement, one
>   gets the impression that sometimes they will be changed.
This was meant to clarify that nothing was changed.  But, to avoid
confusion, we have removed the text.

> - sect 4.1.1.1. I see:
>        The type of the trace message.  The following values are
>        defined.  All other values are reserved and should be sent as
>        zero and ignored on receipt.
> 
>        1 = SONET Section Trace (J0 Byte)
>        2 = SONET Path Trace (J1 Byte)
>        3 = SONET Path Trace (J2 Byte)
>        4 = SDH Section Trace (J0 Byte)
>        5 = SDH Path Trace (J1 Byte)
>        6 = SDH Path Trace (J2 Byte)
> 
>   The text about "All other valies are reserved and should be sent
>   as zero..." is OK for field that have bitmasks or such, but here
>   you seem to be using the field as an integer field, no?
Thanks for catching this.  This has been changed.

> - last sentence before sect 4.1.3.1... pls check:
>      Section .            4.1.3.1
>   Actually also check the sentence before that
these are Microsoft issues that I'm trying to track down/fix.

> - page 11/12/13 I see strange formatting that causes lines to
>   go beyond col 72, and I am not sure that proper sections
>   are referenced when I see
>       Section 4.          ..1.3.1
Same as above.

> - Security considerations are unacceptable.
>   - No new security considerations compared to what?
>   - Which security considerations DO apply?
This has been modified to reference LMP security.

> - IANA considerations
>   - pls be specific as to in which name space(s) you want
>     IANA to assign code points. And within such a name space,
>     specify from which block (e.g. Consensus based? user sapce?
We have updated this.

> - copyright section has a year of 2001 !!??
Wishful thinking ;-)

It has been updated to read 2003.

> 
> 
> 
> 
> 
> Thanks,
> Bert

Delivery-date: Tue, 25 Mar 2003 15:36:21 -0800
Date: Wed, 26 Mar 2003 00:29:28 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: Ron Bonica <[email-masked]>
CC: [email-masked]
Subject: Re: IETF 56 CCAMP Minutes

hi ron, all,

some comments and remarks in-line...

hope they will help you,
- dimitri.

---

Ron Bonica wrote:
> 
> Folks,
> 
> Attached are IETF 56 CCAMP minutes. Thanks to Markus Jork for taking notes.
> If there are no objections posted to the list by next week, I will submit
> the minutes as recorded by Markus.
> 
> ============================================
> 
> Kireeti: WG status
> ------------------
> 
> Short overview on status of WG documents as listed on web page.
> 
> Questions:
> - framework for sonet/sdh control draft ready for LC? -> unclear
> - LMP MIB to LC?
>   Some in room think it's ready (nobody disagrees) -> take to mailing list

i think bert asked for a checkup before doing so

> - non-standard sonet/sdh extensions? -> no interest in room
>   Bert Wijnen: There is still no document describing what exactly
>   is signaled. If that is not provided, this draft should go to wastebin.

*no referenced* document
 
> Wesam Alanqar: ITU liaison report
> ---------------------------------
> 
> ITU-T SG15 update to ccamp. This presentation has also been sent
> to the mailing list.
> 3 liaison statements exist: ason routing, discovery, restoration/re-routing.
> 
> IETF routing experts are invited to come to next ITU meeting.
> 
> Dimitri Papadimitriou: Ext. in support of end-to-end GMPLS-based recovery
> -------------------------------------------------------------------------
> 
> draft-lang-ccamp-gmpls-recovery-e2e-signaling-00
> 
> After 1 year of work: terminology starts to be widely adopted,
> analysis i-d still too largely scoped.

note: the above are more generic statements while the below applies
to the signalling i-d only (wise to include this clarification)

> Still needs to be covered: bulk lsp recovery, reversion (switch back)
> 
> Next steps:
> next report April 03, func spec ready for LC

... funct spec to be ready for LC *in April'03*

> protocol spec expected to be ready in July

July'03
 
> Should the terminology doc become PS?

or (stay/be ?) informational, AD's will check
 
> Peter Czezowski: recovery requirements, fault notification protocol and LMP
> ----------------------------------------------------------------------------
> 
> Presenting 3 drafts and changes to them:
> - draft-czezowski-optical-recovery-reqs-01.txt
> - draft-rabbat-fault-notification-protocol-02.txt
> - draft-soumiya-lmp-fault-notification-ext-00.txt
> 
> The first 2 drafts believed to be ready. There is running code for
> the third draft, but is there any interest?
> Comments are requested from mailing list.
> 
> George: Changing pt-to-pt protocol to a flooding protocol is more than
>         just adding a message. It results in a different implementation
>         model for LMP.
> Kireeti: Don't start by modfying LMP, first look into problem and

typo: modifying

>          requirements. Need mailing list discussion whether LMP is right.

... is the right approach here

> Alex: It took several net meltdowns to learn how to do flooding right.
> 
> Dimitri: draft-lang-ccamp-lmp-bootstrap-03
> ------------------------------------------
> 
> Changes: modified J0/J1/J2-16 string to fit within 80 bits,
>          added layer adjacency discovery
> Next steps: believes all technical issues solved, accept as wg doc?

... "all technical issues raised on the mailing list" 
 
> Is this a worthwhile LMP extension (apart from questions about format
> details)?
> 
> Kireeti: needs discussion on list
> Jonathan(?): mechanism worthwhile, encoding still has problems

Jonathan Sadler... 
(note: it is unclear where these problems are anyway)

> Dimitri: suggest to create document with common bootstrap mechanism,
>          then sonet/sdh specific doc

where sonet/sdh encoding specifics would be specified

> Jonathan Lang: is feature desired by community? find out before splitting
>                docs and put more work in it

is *bootstrap* feature

> Question to room: ~7 think it's useful, nobody against -> take to list
> 
> George: draft-ietf-ccamp-gmpls-overlay-01
> -----------------------------------------
> 
> Question to room: "ready for WG LC?":
> ~20 yes, 0 no
> -> check consensus on list

add (start WG last call after meeting)

> Dimitri: technology specific routing extensions to GMPLS routing
> ----------------------------------------------------------------
> 
> draft-mannie-ccamp-gmpls-sonet-sdh-{ospf,isis}
> 
> Changes: discussion concerning bandwidth encoding, section on scalability
> and backward compatibility consideration.
> 
> Falls within Sonet/SDH basket. Some assertions have been made on list,
> addressed one-by-one in the presentation.
> 
> Jonathan(?): need discussion on list instead of rhetorical questions here

Jonathan Sadler
 
> A layering discussion ensued.
> 
> Kireeti: need layer relationship document

referring to the mrn i-d
 
> Poll of the room: ~15 think it's a useful idea, ~5 against making it wg doc
> Kireeti: reasonable support, take to list
> 
> Adrian Farell: GMPLS MIBs
> -------------------------
> 
> 3 drafts became WG drafts in June 02, nothing happened since.
> Waiting for MPLS MIBS to go to LC before republishing GMPLS MIBs.
> Plan:
>   wait for MPLS MIBs republication and LC
>   quick editorial respin to bring in line (~4 weeks after MPLS MIBs)
>   content additions, republish before Vienna
>   chairs would like LC in August (but need WG feedback)
> 
> Adrian: draft-lee-ccamp-rsvp-te-exclude-route-01
> ------------------------------------------------
> 
> Why in gmpls?
>   think is ccmap charter item, increasing interest (inter-AS/area),

typo: ccamp

>   is mpls extension but is generalized and should be part of GMPLS
> Why needed?
>   needed where path computation is not only in one place
> Changes:
>   identification of new work items
> Actions:
>   got useful feedback
>   solicit input from providers
>   look for convergence with JP's draft
>   WG item?
> 
> George: should talk about it in ??? meeting
> 
> Questions to room:
> ~15 have read the draft
> ~20 find it useful
> ~30 think it should become wg doc in some wg
> 0 find it not ready
> 
> Osama Aboul-Magd: a transport view to LMP
> -----------------------------------------
> 
> draft-aboulmagd-ccamp-transport-lmp-00.txt
> 
> Kireeti: What does control plane discovery mean?
>          Is LMP + LMP bootstrap close enough to what this draft does?
>          Very useful spec, provides "language translation".
> 
> Marten: progress this draft before LMP bootstrap draft

isn't Malcolm Betts ?
 
> Ron Bonica: generic tunnel tracing
> ----------------------------------
> 
> Requirements doc is stable, WG LC complete.
> Time to work on solution, IANA has assigned UDP port,
> new context object added.
> 
> Solicit feedback from implementers.
> Adopt as ccamp work item?
> 
> Room poll: ~10 have read the draft -> need to take to list
> 
> Ron (for Loa): MPLS and GMPLS change process
> --------------------------------------------
> 
> Status: lots of lively discussion, topics:
> - is this merely a reaffirmation of IETF process?
> - what is the role of a liaison?
> - when all approvals are not obtained? Is there any alternative
>   to the dust bin?
> 
> Don Fedyk: need better understanding, common model/language
> 
> Monique Morrow(?): ITU/IETF need to work together

yes i think so

> Jerry Ash: document describing liaisons?
> 
> Kireeti: there already is such as doc (may be insufficient), separate
>          from this

would it be possible to clarify the above sentence ?

> Bert: liaison process is wider issue (not specific to this WG)
> 
> Marten: draft fine for IP applications, how about non-IP apps? How
>         can get those requirements recognized in IETF?

Malcolm Betts (i guess)
 
> Ron: requirements must be stated clearly to be understood by IETF WG
> 
> Kireeti: Draft documents how ietf process works.
>          The process may need a dust bin for bad ideas and another
>          bin for "not in IETF scope, but not really broken".
>          It is not addressed yet how to handle stuff the IETF doesn't like.
> 
> Alex: Need interest by IETF community to make things happen,
>       same thing applicable to anyone coming to IETF.
>       People need to be convinced.
> 
> Bert: subip area initially had problem with too many drafts,
>       was fixed by requiring problem statements
> 
> Marten: Process is very mature dealing with submissions by individuals,
>         but not from other organizations.
>         I-Ds not suited to deal with peer standardization organization.
>         ITU can't do ascii diagrams or read through mailing list
>         to gather IETF opinion.
>         Need a way to apply IETF protocols to non-IETF problem.

same here ?
 
> Kireeti: GMPLS work did step out of traditional ietf scope
> 
> George: coopeation would work a lot better if clear requirements would
>         be communicated instead of sending in solutions
>         (even applies within IETF)
> 
> Sharam Davari: another standardization organization should not have
>                same weight as an individual submission
> 
> Ron: I-D should be evaluated on its merit, author irrelevant
> 
> Kireeti: ccamp charter update
> -----------------------------
> 
> - not done by WG consensus
> - proposed by chairs to AD, AD takes it to IESG/IAB
> 
> Alex: correction: WG consensus *is* required but is not enough
> 
> under consideration:
> - inter-area signaling and routing of generalized paths
> - inter-as on hold until tewg produces requirements
> - explicitely put tunnel tracing in charter
> - routing extensions for Sonet/SDH
> - signaling for G.709 signaling
> - further LMP extensions
> - optical vpn *not* in charter
> 
> milestones:
> - GMPLS MIB to WG LC in Aug 03
> - protection/restoration functional spec and protocol changes
>   to WG LC by Apr and Jul 03 (respectively)
> - tunnel tracing protocol to WG LC by Sep 03
> - set milestones for inter-area path setup when ratified as charter changes
> 
> need active discussion on list
> 
> JP: combination of inter-area and inter-as is a good idea
>
> Kireeti: it is great if a common solution is available, but that is not
>          reason enough to put inter-as on charter
> 
> Marco: O-VPN started in ITU-T, on ppvpn charter, good chance for cooperation
>
> Kireeti: ccamp should keep an eye on solution
> 
> ===========================================
> Ronald P. Bonica       Ph: 703 886 1681
> vBNS Engineering       page: 1 888 268 8021
> Ashburn, Va.
> ===========================================
> "We are not on Earth to guard a museum, but
> to cultivate a flourishing garden of life."
>                 -- Angelo Giuseppe Roncalli

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Tue, 25 Mar 2003 05:21:12 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-05.txt
Date: Tue, 25 Mar 2003 08:11:37 -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 Multi-Protocol Label Switching 
                          Architecture
	Author(s)	: E. Mannie
	Filename	: draft-ietf-ccamp-gmpls-architecture-05.txt
	Pages		: 57
	Date		: 2003-3-24
	
Future data and transmission networks will consist of elements such
as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
(PXCs), optical cross-connects (OXCs), etc. that will use
Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
provision resources and to provide network survivability using
protection and restoration techniques.
This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-architecture-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-gmpls-architecture-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-gmpls-architecture-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-architecture-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: Sun, 23 Mar 2003 22:46:55 -0800
Date: Sun, 23 Mar 2003 22:44:12 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: CCAMP WG Last Call for Overlay document

Hi,

There was reasonable support for draft-ietf-ccamp-gmpls-overlay-01
at the meeting.  So, this is a two-week WG Last Call for this doc.
It is my understanding that this is targeted as Proposed Standard.

If you have issues with the doc, please spell them out; if possible,
offer alternative text or explicit changes -- that generally is more
productive.

The Last Call ends Sunday April 6, 2003 at midnight PDT.

Thanks,
Kireeti.

Delivery-date: Sun, 23 Mar 2003 22:39:43 -0800
Date: Sun, 23 Mar 2003 22:36:13 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: Consensus to progress documents

Hi,

As decided in the CCAMP 56 meeting, we are taking the following to
the list for consensus to make WG documents.  Please indicate your
response for each (Y=make it a CCAMP WG doc; N=not; -=don't care):

1. draft-lang-ccamp-lmp-bootstrap-03.txt

2. draft-mannie-ccamp-gmpls-sonet-sdh-{ospf,isis}

3. draft-aboulmagd-ccamp-transport-lmp-00.txt

4. draft-bonica-tunproto-04.txt

Thanks,
Kireeti.

Delivery-date: Sun, 23 Mar 2003 21:52:32 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Cc: "Ccamp-wg (E-mail)" <[email-masked]>, "Ppvpn (E-mail)" <[email-masked]>, "Mpls (E-mail)" <[email-masked]>, "Tewg (E-mail)" <[email-masked]>, "Gsmp (E-mail)" <[email-masked]>, "Ipo (E-mail)" <[email-masked]>
Subject: Change of primary AD for SUB-IP WGs
Date: Mon, 24 Mar 2003 06:48:27 +0100

All,

Scott has left the IESG and Alex has volunteered 
to be co-AD for SUB-IP with Bert. IESG has approved this.
See announcement by Harald a week or so ago.

We have divided the WGs between the two of us as follows
(i.e. we act as primary AD as follows):

  For CCAMP, no change, so Bert Wijnen
  For GSMP: change Scott Bradner into Bert Wijnen
  For IPO: change Scott Bradner into Alex Zinin
  For MPLS: change Scott Bradner into Alex Zinin
  For PPVPN: change Scott Bradner into Alex Zinin
  For TEWG: no change, so Bert Wijnen

Thanks,
Bert and Alex

Delivery-date: Sun, 23 Mar 2003 18:12:39 -0800
Date: Sun, 23 Mar 2003 21:08:30 -0500
From: Ron Bonica <[email-masked]>
Subject: IETF 56 CCAMP Minutes
To: [email-masked]

Folks,

Attached are IETF 56 CCAMP minutes. Thanks to Markus Jork for taking notes.
If there are no objections posted to the list by next week, I will submit
the minutes as recorded by Markus.

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

Kireeti: WG status
------------------

Short overview on status of WG documents as listed on web page.

Questions:
- framework for sonet/sdh control draft ready for LC? -> unclear
- LMP MIB to LC?
  Some in room think it's ready (nobody disagrees) -> take to mailing list
- non-standard sonet/sdh extensions? -> no interest in room
  Bert Wijnen: There is still no document describing what exactly
  is signaled. If that is not provided, this draft should go to wastebin.

Wesam Alanqar: ITU liaison report
---------------------------------

ITU-T SG15 update to ccamp. This presentation has also been sent
to the mailing list.
3 liaison statements exist: ason routing, discovery, restoration/re-routing.

IETF routing experts are invited to come to next ITU meeting.

Dimitri Papadimitriou: Ext. in support of end-to-end GMPLS-based recovery
-------------------------------------------------------------------------

draft-lang-ccamp-gmpls-recovery-e2e-signaling-00

After 1 year of work: terminology starts to be widely adopted,
analysis i-d still too largely scoped.
Still needs to be covered: bulk lsp recovery, reversion (switch back)

Next steps:
next report April 03, func spec ready for LC
protocol spec expected to be ready in July

Should the terminology doc become PS?

Peter Czezowski: recovery requirements, fault notification protocol and LMP
----------------------------------------------------------------------------

Presenting 3 drafts and changes to them:
- draft-czezowski-optical-recovery-reqs-01.txt
- draft-rabbat-fault-notification-protocol-02.txt
- draft-soumiya-lmp-fault-notification-ext-00.txt

The first 2 drafts believed to be ready. There is running code for
the third draft, but is there any interest?
Comments are requested from mailing list.

George: Changing pt-to-pt protocol to a flooding protocol is more than
	just adding a message. It results in a different implementation
	model for LMP.
Kireeti: Don't start by modfying LMP, first look into problem and
	 requirements. Need mailing list discussion whether LMP is right.
Alex: It took several net meltdowns to learn how to do flooding right.

Dimitri: draft-lang-ccamp-lmp-bootstrap-03
------------------------------------------

Changes: modified J0/J1/J2-16 string to fit within 80 bits,
	 added layer adjacency discovery
Next steps: believes all technical issues solved, accept as wg doc?

Is this a worthwhile LMP extension (apart from questions about format
details)?

Kireeti: needs discussion on list
Jonathan(?): mechanism worthwhile, encoding still has problems
Dimitri: suggest to create document with common bootstrap mechanism,
	 then sonet/sdh specific doc
Jonathan Lang: is feature desired by community? find out before splitting
	       docs and put more work in it

Question to room: ~7 think it's useful, nobody against -> take to list

George: draft-ietf-ccamp-gmpls-overlay-01
-----------------------------------------

Question to room: "ready for WG LC?":
~20 yes, 0 no
-> check consensus on list

Dimitri: technology specific routing extensions to GMPLS routing
----------------------------------------------------------------

draft-mannie-ccamp-gmpls-sonet-sdh-{ospf,isis}

Changes: discussion concerning bandwidth encoding, section on scalability
and backward compatibility consideration.

Falls within Sonet/SDH basket. Some assertions have been made on list,
addressed one-by-one in the presentation.

Jonathan(?): need discussion on list instead of rhetorical questions here

A layering discussion ensued.

Kireeti: need layer relationship document

Poll of the room: ~15 think it's a useful idea, ~5 against making it wg doc
Kireeti: reasonable support, take to list

Adrian Farell: GMPLS MIBs
-------------------------

3 drafts became WG drafts in June 02, nothing happened since.
Waiting for MPLS MIBS to go to LC before republishing GMPLS MIBs.
Plan:
  wait for MPLS MIBs republication and LC
  quick editorial respin to bring in line (~4 weeks after MPLS MIBs)
  content additions, republish before Vienna
  chairs would like LC in August (but need WG feedback)

Adrian: draft-lee-ccamp-rsvp-te-exclude-route-01
------------------------------------------------

Why in gmpls?
  think is ccmap charter item, increasing interest (inter-AS/area),
  is mpls extension but is generalized and should be part of GMPLS
Why needed?
  needed where path computation is not only in one place
Changes:
  identification of new work items
Actions:
  got useful feedback
  solicit input from providers
  look for convergence with JP's draft
  WG item?

George: should talk about it in ??? meeting

Questions to room:
~15 have read the draft
~20 find it useful
~30 think it should become wg doc in some wg
0 find it not ready

Osama Aboul-Magd: a transport view to LMP
-----------------------------------------

draft-aboulmagd-ccamp-transport-lmp-00.txt

Kireeti: What does control plane discovery mean?
         Is LMP + LMP bootstrap close enough to what this draft does?
	 Very useful spec, provides "language translation".

Marten: progress this draft before LMP bootstrap draft

Ron Bonica: generic tunnel tracing
----------------------------------

Requirements doc is stable, WG LC complete.
Time to work on solution, IANA has assigned UDP port,
new context object added.

Solicit feedback from implementers.
Adopt as ccamp work item?

Room poll: ~10 have read the draft -> need to take to list

Ron (for Loa): MPLS and GMPLS change process
--------------------------------------------

Status: lots of lively discussion, topics:
- is this merely a reaffirmation of IETF process?
- what is the role of a liaison?
- when all approvals are not obtained? Is there any alternative
  to the dust bin?

Don Fedyk: need better understanding, common model/language

Monique Morrow(?): ITU/IETF need to work together

Jerry Ash: document describing liaisons?

Kireeti: there already is such as doc (may be insufficient), separate
	 from this

Bert: liaison process is wider issue (not specific to this WG)

Marten: draft fine for IP applications, how about non-IP apps? How
	can get those requirements recognized in IETF?

Ron: requirements must be stated clearly to be understood by IETF WG

Kireeti: Draft documents how ietf process works.
	 The process may need a dust bin for bad ideas and another
	 bin for "not in IETF scope, but not really broken".
	 It is not addressed yet how to handle stuff the IETF doesn't like.

Alex: Need interest by IETF community to make things happen,
      same thing applicable to anyone coming to IETF.
      People need to be convinced.

Bert: subip area initially had problem with too many drafts,
      was fixed by requiring problem statements

Marten: Process is very mature dealing with submissions by individuals,
	but not from other organizations.
	I-Ds not suited to deal with peer standardization organization.
	ITU can't do ascii diagrams or read through mailing list
	to gather IETF opinion.
	Need a way to apply IETF protocols to non-IETF problem.

Kireeti: GMPLS work did step out of traditional ietf scope

George: coopeation would work a lot better if clear requirements would
	be communicated instead of sending in solutions
	(even applies within IETF)

Sharam Davari: another standardization organization should not have
	       same weight as an individual submission

Ron: I-D should be evaluated on its merit, author irrelevant

Kireeti: ccamp charter update
-----------------------------

- not done by WG consensus
- proposed by chairs to AD, AD takes it to IESG/IAB

Alex: correction: WG consensus *is* required but is not enough

under consideration:
- inter-area signaling and routing of generalized paths
- inter-as on hold until tewg produces requirements
- explicitely put tunnel tracing in charter
- routing extensions for Sonet/SDH
- signaling for G.709 signaling
- further LMP extensions
- optical vpn *not* in charter

milestones:
- GMPLS MIB to WG LC in Aug 03
- protection/restoration functional spec and protocol changes
  to WG LC by Apr and Jul 03 (respectively)
- tunnel tracing protocol to WG LC by Sep 03
- set milestones for inter-area path setup when ratified as charter changes

need active discussion on list

JP: combination of inter-area and inter-as is a good idea

Kireeti: it is great if a common solution is available, but that is not
	 reason enough to put inter-as on charter

Marco: O-VPN started in ITU-T, on ppvpn charter, good chance for cooperation

Kireeti: ccamp should keep an eye on solution

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
                -- Angelo Giuseppe Roncalli

Delivery-date: Sun, 23 Mar 2003 07:08:11 -0800
Date: Sun, 23 Mar 2003 10:02:23 -0500
From: Ron Bonica <[email-masked]>
Subject: RE: draft-bonica-tunproto-04.txt
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]

Adrian,

Thanks for your comments. Response inline....

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, March 18, 2003 3:06 AM
> To: Ron Bonica
> Cc: [email-masked]
> Subject: draft-bonica-tunproto-04.txt
>
>
> Hi Ron,
>
> Some thoughts on re-reading this draft...
>
> I think the draft is long enough to need a contents table.

Will do.

>
> Although the access control function is mandatory, why is the
> Access Control
> Object mandatory on a traceProbe? If the requester has nothing to
> say and the
> reporter is happy with that, why force the object to be present?

Good idea. I will change that in the draft

>
> It wasn't clear to me until reading the section on head-end
> object timestamps
> that the traceResponse is routed back through the head of the
> tunnel. Doesn't
> this assume that you have a bidirectional tunnel?

No. It assumes only that all devices that participate in a tunnel
maintain an IP route to the tunnel's head-end.

 Apart from the
> round-trip time
> function, why wouldn't you send the traceResponse back to the
> source by a more
> direct route?

I don't want to require devices that support the tunnel interior
to maintain an IP route to the device that hosts the route-tracing
application. This is of particular concern for tunnels that support
RFC 2547 VPNs.

>
> Isn't there a problem with the TTL method of finding the next
> hop? The path of
> the tunnel may change from one probe to the next giving the
> appearance of loops
> (gaps are less important). You either need to describe apparent
> loops and how to
> prune them, or you need to use another hop identification mechanism.
>

Good point. Traditional traceroute [RFC 2151] deals with this problem by
probing each hop N times (default = 3). If the same node answers each
probe, there is no problem. If the application receives responses from
more than one node, it reports this and the user is aware that something
funny is going on.

GTTP should probably do the same thing. I will add a section describing
the problem and the proposed solution.

> Why is the Access Control Object present on the traceResponse?

Now that I think of it, it really isn't required. I will remove it.

I put it in the traceResponse to protect VPN devices from spoofed
traceResponses that originated outside of the VPN. However, we can
achieve the same thing with the Context Object.

>
> Format diagrams - all the bit counts need to right-shift by one.

Oops. I'll fix that.
>
> Is the ordering of objects in messages mandatory, suggested, optional?

Optional. I will be more specific about that.

>
> Was there a protocol version 0?

No. I guess we could call this version 0.

>
> Lengths. Message lengths appear to be inclusive, object lengths exclusive.
> Consistency would be nice. When you describe the individual
> objects the length
> values you give are actually inclusive. Note also that object
> lengths refer to a
> count of 32-bit words that follow, but are often (never?) the
> last byte in a
> 32-bit word.

I will fix this.

>
> Errors. For unknown, malformed and missing objects it is nice to
> be able to
> indicate the object type that is in error.

We can fix by adding a new field that contains the identifier of the object
that has a problem.

Note also, that if the error is
> missing object, it may not be possible to correctly format a TraceResponse
> Message.

Agreed.

>
> Addresses here are only IPv4. Would it be worth including IPv6 variants?

Let's get some experience with IPv4 and add IPv6 objects later.

>
> Need an error code for IP Header and Tunnel Object both present?

Good point.
>
> 5.2.7 missing description of hop count

Good catch.

>
> Need error needed for hop count flag set and responder address present?

Another good catch! I will add another error code.

>
> Several places say "can be 0 padded for word alignment". I think
> this should
> read "MUST".

Yes.

>
> 5.2.11 Support for unnumbered interfaces?

We should make this work exactly like traditional traceroute. I will add
some words to that effect.

>
> 5.2.12 Flags field. Which bit is bit 0? Compare Propagation
> Object where you say
> "right-most bit".

I will fix this.

>
> Tunnel type.  GRE?

I will fix this too.
>
> I think the security section needs some oomph!

Any suggestions? I am looking for input.

                    Ron

>
> Cheers,
> Adrian
>
>
>

Delivery-date: Fri, 21 Mar 2003 08:42:01 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, ccamp <[email-masked]>
Subject: RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
Date: Fri, 21 Mar 2003 08:41:19 -0800

Stephen,

I think there may be some misunderstanding about how the Jx Trace
Correlation actually works.

Normally the Test message is sent in the data plane using the various
SDH/SONET overhead bytes.  However, for backwards compatibility with all
existing SDH/SONET equipment, the Trace Correlation transport mechanism was
introduced.  When it is used, the existing pattern in the overhead bytes of
a particular data link is passed in a Test Message sent over the control
plane.  See below: 

Thanks,

John

0x08 J0-trace: J0 Section Trace Correlation 
         
                Capable of transmitting SONET/SDH Section/RS trace over 
                J0 Section/RS overhead byte as defined in ANSI 
                T1.105/ITU-T G.707. 
                 
                The Test message is not transmitted using the J0 bytes 
                (i.e., over the data link), but is sent over the 
                control channel and correlated for consistency to the 
                received J0 pattern. 
                 
                In order to get the mapping between the Interface_Id 
                over which the J0 test message is sent and the J0 
                pattern sent in-band, the transmitting node must 
                provide the correlation between this pattern and the J0 
                test message.  This correlation is done using the TRACE 
                object as defined in Section 4
.. 
                 
                The format of the test message is as follows: 
                 
                <Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> 
                <VERIFY_ID> <TRACE> 
                 
                Note that no change is required for the 
                TestStatusSuccess or TestStatusFailure messages. 

> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Monday, March 17, 2003 8:19 PM
> To: ccamp
> Subject: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
> 
> 
> All,
> Bert asked me to have a look at this from an ITU-T perspective.
> As I look back through the email archives, I see a number of issues
> that were raised that were never addressed before (or after) a WG last
> call was issued for the -00 draft this document during Dec. 2002.
> There were a number of comments raised with respect to the draft
> in particular from Sept-Nov 2002 that were not addressed. In addition,
> there is the entire thread (2002 archive) "J0/J1 encoding issues" that
> applies to this draft that was never addressed. Perhaps the December
> last call slipped by "under radar" without these issues having been
> addressed.
> 
> I think that the simplest way to resolve the issues is to align
> the draft with ITU-T G.7714.1 (as has Dimitri just did for
> draft-lang-ccamp-lmp-bootstrap-03.txt). Then we have all the documents
> aligned around the same J0/J1 format.
> 
> Once this alignment is done, I think the next question is whether
> draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt contains any extra 
> information
> over what is in ITU-T G.7714.1. If not, perhaps it can just 
> go info track
> if the normative text is in ITU-T G.7714.1.
> Regards,
> Steve
> 

Delivery-date: Fri, 21 Mar 2003 08:23:00 -0800
From: "Adrian Farrel" <[email-masked]>
To: "Guangzhi Li" <[email-masked]>, "Jonathan Lang" <[email-masked]>
Cc: <[email-masked]>, "'Cheng-Yin Lee'" <[email-masked]>, <[email-masked]>
Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt
Date: Fri, 21 Mar 2003 11:22:36 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_006B_01C2EF9C.2CBBD880
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

OK thanks.
If the two functions are orthogonal, even I don't see any value in =
trying to converge them on the same object.
Cheers,
Adrian
  ----- Original Message -----=20
  From: Guangzhi Li=20
  To: Jonathan Lang=20
  Cc: 'Adrian Farrel' ; [email-masked] ; 'Cheng-Yin Lee' ; =
[email-masked]=20
  Sent: Friday, March 21, 2003 11:22 AM
  Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt

  Just echo what Jonathan just said.

  The PPRO is not used for secondary LSP computation. It is used for =
nodes along the restoration LSP to book resouces.=20

  How to compute the secondary LSP is not the focus here.

  -- Guangzhi

  Jonathan Lang wrote:

[ post by non-subscriber.  with the massive amount of spam, it is easy =
to miss
  and therefore delete posts by non-subscribers.  if you wish to =
regularly
  post from an address that is not subscribed to this mailing list, send =
a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Adrian,
  The nodes along the path of the secondary LSP are not computing ERO
expansions, but are using the PPRO to determine if resources can be
booked (or overbooked).

Thanks,
Jonathan

 =20
-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Wednesday, March 19, 2003 8:11 PM
To: Jonathan Lang
Cc: [email-masked]; Cheng-Yin Lee; [email-masked]
Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt

Thanks Jonathan,

I have one remaining point for discussion.
How close is the PPRO to the XRO in
draft-lee-ccamp-rsvp-te-exclude-route-02.txt?

It was certainly our intention that XRO should be applicable to your
specific
e2e requirements so I'd like to understand the issues with a view to
converging
the specifications.

You said...

   =20
We read the Lee draft, but it was more restrictive than we wanted
     =20
this
 =20
to be.  We don't want the PPRO to be an "Exclude Route".  Rather, it
     =20
is
 =20
a local policy issue how to use the PPRO.
     =20
We have an option in the XRO that says whether the exclusion is
   =20
required
 =20
or
desired. A desired exclusion is clearly a policy issue at the
   =20
computing
 =20
node.

Is there something more specific that you need?

Thanks,
Adrian

   =20

 =20

--=20
Guangzhi
-------------------------------------
AT&T Labs - research
Phone 973 360 7376, Fax 973 360 8050

------=_NextPart_000_006B_01C2EF9C.2CBBD880
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><TITLE></TITLE>
<META content=3Dtext/html;charset=3DISO-8859-1 =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DCourier size=3D2>OK thanks.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>If the two functions are orthogonal, =
even I don't=20
see any value in trying to converge them on the same =
object.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Cheers,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[email-masked]" =
title=[email-masked]>Guangzhi=20
  Li</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:[email-masked]"=20
  title=[email-masked]>Jonathan Lang</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:[email-masked]"=20
  title=[email-masked]>'Adrian Farrel'</A> ; <A=20
  href=3D"mailto:[email-masked]"=20
  title=[email-masked]>[email-masked]</A> ; <A=20
  href=3D"mailto:[email-masked]"=20
  title=[email-masked]>'Cheng-Yin Lee'</A> ; <A=20
  href=3D"mailto:[email-masked]"=20
  =
title=[email-masked]>[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, March 21, 2003 =
11:22=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re:=20
  draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt</DIV>
  <DIV><BR></DIV>Just echo what Jonathan just said.<BR><BR>The PPRO is =
not used=20
  for secondary LSP computation. It is used for nodes along the =
restoration LSP=20
  to book resouces. <BR><BR>How to compute the secondary LSP is not the =
focus=20
  here.<BR><BR>-- Guangzhi<BR><BR>Jonathan Lang wrote:<BR>
  <BLOCKQUOTE =
cite=3D"[email-masked]"=20
  type=3D"cite"><PRE wrap=3D"">[ post by non-subscriber.  with the =
massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to =
regularly
  post from an address that is not subscribed to this mailing list, send =
a
  message to &lt;listname&gt;[email-masked] and ask to have the =
alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Adrian,
  The nodes along the path of the secondary LSP are not computing ERO
expansions, but are using the PPRO to determine if resources can be
booked (or overbooked).

Thanks,
Jonathan

  </PRE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">-----Original Message-----
From: Adrian Farrel [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]
Sent: Wednesday, March 19, 2003 8:11 PM
To: Jonathan Lang
Cc: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[email-masked]">[email-masked]</A>; Cheng-Yin =
Lee; <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:[email-masked]">stefaan.de_cnodder@alcatel.=
be</A>
Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt

Thanks Jonathan,

I have one remaining point for discussion.
How close is the PPRO to the XRO in
draft-lee-ccamp-rsvp-te-exclude-route-02.txt?

It was certainly our intention that XRO should be applicable to your
specific
e2e requirements so I'd like to understand the issues with a view to
converging
the specifications.

You said...

    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">We read the Lee draft, =
but it was more restrictive than we wanted
      </PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->this
  </PRE>
    <BLOCKQUOTE type=3D"cite">
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">to be.  We don't want the =
PPRO to be an "Exclude Route".  Rather, it
      </PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->is
  </PRE>
    <BLOCKQUOTE type=3D"cite">
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">a local policy issue how =
to use the PPRO.
      </PRE></BLOCKQUOTE><PRE wrap=3D"">We have an option in the XRO =
that says whether the exclusion is
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->required
  </PRE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">or
desired. A desired exclusion is clearly a policy issue at the
    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->computing
  </PRE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">node.

Is there something more specific that you need?

Thanks,
Adrian

    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->

  </PRE></BLOCKQUOTE><BR><PRE class=3Dmoz-signature =
cols=3D"$mailwrapcol">--=20
Guangzhi
-------------------------------------
AT&amp;T Labs - research
Phone 973 360 7376, Fax 973 360 8050
</PRE><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_006B_01C2EF9C.2CBBD880--

Delivery-date: Fri, 21 Mar 2003 08:21:26 -0800
Date: Fri, 21 Mar 2003 11:22:07 -0500
From: Guangzhi Li <[email-masked]>
To: Jonathan Lang <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, [email-masked], "'Cheng-Yin Lee'" <[email-masked]>, [email-masked]
Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt

--------------050905080503050804050202
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Just echo what Jonathan just said.

The PPRO is not used for secondary LSP computation. It is used for nodes 
along the restoration LSP to book resouces.

How to compute the secondary LSP is not the focus here.

-- Guangzhi

Jonathan Lang wrote:

>[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>  and therefore delete posts by non-subscribers.  if you wish to regularly
>  post from an address that is not subscribed to this mailing list, send a
>  message to <listname>[email-masked] and ask to have the alternate
>  address added to the list of addresses from which submissions are
>  automatically accepted. ]
>
>Adrian,
>  The nodes along the path of the secondary LSP are not computing ERO
>expansions, but are using the PPRO to determine if resources can be
>booked (or overbooked).
>
>Thanks,
>Jonathan
>
>  
>
>>-----Original Message-----
>>From: Adrian Farrel [mailto:[email-masked]]
>>Sent: Wednesday, March 19, 2003 8:11 PM
>>To: Jonathan Lang
>>Cc: [email-masked]; Cheng-Yin Lee; [email-masked]
>>Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt
>>
>>Thanks Jonathan,
>>
>>I have one remaining point for discussion.
>>How close is the PPRO to the XRO in
>>draft-lee-ccamp-rsvp-te-exclude-route-02.txt?
>>
>>It was certainly our intention that XRO should be applicable to your
>>specific
>>e2e requirements so I'd like to understand the issues with a view to
>>converging
>>the specifications.
>>
>>You said...
>>
>>    
>>
>>>We read the Lee draft, but it was more restrictive than we wanted
>>>      
>>>
>this
>  
>
>>>to be.  We don't want the PPRO to be an "Exclude Route".  Rather, it
>>>      
>>>
>is
>  
>
>>>a local policy issue how to use the PPRO.
>>>      
>>>
>>We have an option in the XRO that says whether the exclusion is
>>    
>>
>required
>  
>
>>or
>>desired. A desired exclusion is clearly a policy issue at the
>>    
>>
>computing
>  
>
>>node.
>>
>>Is there something more specific that you need?
>>
>>Thanks,
>>Adrian
>>
>>    
>>
>
>
>
>
>
>  
>

-- 
Guangzhi
-------------------------------------
AT&T Labs - research
Phone 973 360 7376, Fax 973 360 8050

--------------050905080503050804050202
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Just echo what Jonathan just said.<br>
<br>
The PPRO is not used for secondary LSP computation. It is used for nodes
along the restoration LSP to book resouces. <br>
<br>
How to compute the secondary LSP is not the focus here.<br>
<br>
-- Guangzhi<br>
<br>
Jonathan Lang wrote:<br>
<blockquote type="cite"
 cite="[email-masked]">
  <pre wrap="">[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to &lt;listname&gt;[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Adrian,
  The nodes along the path of the secondary LSP are not computing ERO
expansions, but are using the PPRO to determine if resources can be
booked (or overbooked).

Thanks,
Jonathan

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: Adrian Farrel [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]
Sent: Wednesday, March 19, 2003 8:11 PM
To: Jonathan Lang
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; Cheng-Yin Lee; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt

Thanks Jonathan,

I have one remaining point for discussion.
How close is the PPRO to the XRO in
draft-lee-ccamp-rsvp-te-exclude-route-02.txt?

It was certainly our intention that XRO should be applicable to your
specific
e2e requirements so I'd like to understand the issues with a view to
converging
the specifications.

You said...

    </pre>
    <blockquote type="cite">
      <pre wrap="">We read the Lee draft, but it was more restrictive than we wanted
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->this
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">to be.  We don't want the PPRO to be an "Exclude Route".  Rather, it
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->is
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">a local policy issue how to use the PPRO.
      </pre>
    </blockquote>
    <pre wrap="">We have an option in the XRO that says whether the exclusion is
    </pre>
  </blockquote>
  <pre wrap=""><!---->required
  </pre>
  <blockquote type="cite">
    <pre wrap="">or
desired. A desired exclusion is clearly a policy issue at the
    </pre>
  </blockquote>
  <pre wrap=""><!---->computing
  </pre>
  <blockquote type="cite">
    <pre wrap="">node.

Is there something more specific that you need?

Thanks,
Adrian

    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">-- 
Guangzhi
-------------------------------------
AT&amp;T Labs - research
Phone 973 360 7376, Fax 973 360 8050
</pre>
<br>
</body>
</html>

--------------050905080503050804050202--

Delivery-date: Thu, 20 Mar 2003 20:53:29 -0800
From: "Jonathan Lang" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: <[email-masked]>, "'Cheng-Yin Lee'" <[email-masked]>, <[email-masked]>
Subject: RE: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt
Date: Thu, 20 Mar 2003 20:48:44 -0800

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Adrian,
  The nodes along the path of the secondary LSP are not computing ERO
expansions, but are using the PPRO to determine if resources can be
booked (or overbooked).

Thanks,
Jonathan

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, March 19, 2003 8:11 PM
> To: Jonathan Lang
> Cc: [email-masked]; Cheng-Yin Lee; [email-masked]
> Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt
> 
> Thanks Jonathan,
> 
> I have one remaining point for discussion.
> How close is the PPRO to the XRO in
> draft-lee-ccamp-rsvp-te-exclude-route-02.txt?
> 
> It was certainly our intention that XRO should be applicable to your
> specific
> e2e requirements so I'd like to understand the issues with a view to
> converging
> the specifications.
> 
> You said...
> 
> > We read the Lee draft, but it was more restrictive than we wanted
this
> > to be.  We don't want the PPRO to be an "Exclude Route".  Rather, it
is
> > a local policy issue how to use the PPRO.
> 
> We have an option in the XRO that says whether the exclusion is
required
> or
> desired. A desired exclusion is clearly a policy issue at the
computing
> node.
> 
> Is there something more specific that you need?
> 
> Thanks,
> Adrian
> 

Delivery-date: Thu, 20 Mar 2003 18:46:42 -0800
Date: Thu, 20 Mar 2003 15:41:27 -0800
To: [email-masked]
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Inter-area cspf
Cc: "Bhaskara Peela" <[email-masked]>, [email-masked], [email-masked]

Hi Bhaskara,

At 14:21 19/03/2003 -0500, [email-masked] wrote:
>Hi Jean,
>
>The draft-vasseur-mpls-computation-rsvp-03.txt suggests overload RSVP 
>message to query path request/response between
>path server and client.  Why RSVP should be overloaded when
>it does not involve RSVP signalling.  Why can't we use some plain 
>client-server model instead of overloading RSVP in a scenario which is not 
>related to RSVP.  I came across one
>more draft-lee-mpls-path-request-04.txt which is just a plain 
>client-server model.
>
>Can you please clarify issues involving these two methods.

One comment first: this PCC-PCS draft tries to address multiple problems 
applicable to very different scenarios (inter-area, inter-AS, GMPLS, 
intra-area with off-line computation, ...). As a result, this might give 
the impression that quite a substantial number of objects are required for 
each scenario which is definitely not the case. I guess this is where your 
feeling that we "overload" RSVP might come from. So the plan is to post a 
completely new version of this draft. I'm just waiting for the CCAMP 
charter update and I'm hopping that the motivation for the choice of RSVP 
for PCC-PCS will more clearly appear.

Then, your comments on this new version will be very welcome.

>I do see draft-kompella-mpls-multiarea-te-03.txt expired.  What is the 
>status of this draft? Does any one have idea regarding the implementions 
>for multi-area TE/CSPF among vendors?

Related to draft-kompella-mpls-multiarea-te, we will resurrect it. Let's 
wait for the update on the CCAMP charter.

I won't comment on those lists on vendor implementations but yes there are 
some implementations.

JP.

>Can any one clarify?
>
>thank you
>bhaskara
>----- Original Message -----
>From: Jean Philippe Vasseur <[email-masked]>
>Date: Wed, 19 Mar 2003 00:11:12 -0800
>To: "Bhaskara Peela" <[email-masked]>
>Subject: Re: Inter-area cspf
>
> > Hi,
> >
> > FYI, if you're interested by multi-area TE, you might want to consider:
> > - 
> http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt
> > For PCS-PCC signalling (scenarios 2,4 and 5 on of the previous draft) see:
> > 
> http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt
> >
> > JP.
> >
> > At 15:06 18/03/2003 -0500, Bhaskara Peela wrote:
> > >[ post by non-subscriber.  with the massive amount of spam, it is easy 
> to miss
> > >   and therefore delete posts by non-subscribers.  if you wish to 
> regularly
> > >   post from an address that is not subscribed to this mailing list, 
> send a
> > >   message to <listname>[email-masked] and ask to have the alternate
> > >   address added to the list of addresses from which submissions are
> > >   automatically accepted. ]
> > >
> > >Hi,
> > >
> > >Can any one update me about the status of following drafts
> > >
> > >1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
> > >2)draft-lee-mpls-te-exchange-00.txt
> > >3)draft-lee-mpls-path-request-00.txt
> > >4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
> > >
> > >I would like to know what is the latest ongoing standadization process 
> for
> > >inter-area OSPF-TE LSA flooding
> > >for CSPF calculation for GMPLS or MPLS.
> > >
> > >thank you
> > >bhaskara
> > >--
> > >__________________________________________________________
> > >Sign-up for your own FREE Personalized E-mail at Mail.com
> > >http://www.mail.com/?sr=signup
> >
>
>--
>__________________________________________________________
>Sign-up for your own FREE Personalized E-mail at Mail.com
>http://www.mail.com/?sr=signup

Envelope-to: [email-masked]
Delivery-date: Wed, 19 Mar 2003 20:11:30 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Jonathan Lang" <[email-masked]>
Cc: <[email-masked]>, "Cheng-Yin Lee" <[email-masked]>, <[email-masked]>
Subject: Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt
Date: Wed, 19 Mar 2003 23:10:47 -0500

Thanks Jonathan,

I have one remaining point for discussion.
How close is the PPRO to the XRO in
draft-lee-ccamp-rsvp-te-exclude-route-02.txt?

It was certainly our intention that XRO should be applicable to your specific
e2e requirements so I'd like to understand the issues with a view to converging
the specifications.

You said...

> We read the Lee draft, but it was more restrictive than we wanted this
> to be.  We don't want the PPRO to be an "Exclude Route".  Rather, it is
> a local policy issue how to use the PPRO.

We have an option in the XRO that says whether the exclusion is required or
desired. A desired exclusion is clearly a policy issue at the computing node.

Is there something more specific that you need?

Thanks,
Adrian

Delivery-date: Wed, 19 Mar 2003 11:44:39 -0800
From: "Alanqar, Wesam I [GMG]" <[email-masked]>
To: "'Ron Bonica'" <[email-masked]>, "'kireeti'" <[email-masked]>
Cc: [email-masked]
Subject: ITU-T SG15 updates to IETF CCAMP
Date: Wed, 19 Mar 2003 11:44:15 -0600

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

Folks-

Attached is ITU-T SG15 updates to IETF CCAMP that was presented today in
IETF-56 meeting.

Thanks.

-----------------------------------------------------------------
Wesam Alanqar                         
ITU-T SG15 representative to IETF CCAMP.
Member of Technical Staff
Technology Architecture & Planning (TA&P)
Wireline Technology Development
-----------------------------------------------------------------

------_=_NextPart_000_01C2EE3F.01C63EF8
Content-Type: application/vnd.ms-powerpoint;
	name="ietf-56_ITU SG15 updates_r1.ppt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="ietf-56_ITU SG15 updates_r1.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAHAAAAcQIAAAAAAAAA
EAAAcwIAAAEAAAD+////AAAAAEYCAABHAgAASAIAAEkCAAByAgAAeQIAAPsCAAD/////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz/////////vOK83f//vb3///////////////////////////////z/////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////8///////du9y0
tLuub73////////////////////////////////8////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////8/////5OS3f//tbu1tLz/////////////////
///////////////8////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////P////+9/7W7u7y1u///////////////////////////////////
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz////D////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/////////////////////////////P//////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////P//////////
//////////////////z/////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////z/////////////////////////
///8////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////8/////////////////////////////P//////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////P////////////////////////////z/////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////z////////////////////////////8////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////8////////
/////////////////////P//////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////P//////////////////////
//////z/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////z////////////////////////////8////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////8/////////////////////////////P//////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////P////////////////////////////z/////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////8/////////////////////////////P//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////P//
//////////////////////////z/////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////P//////////////
//////////////z/////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////z////////////////////////////8
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////8/////////////////////////////P//////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////8/////////////////////////////P//////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////P////////////////////////////z/////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////z/////////
///////////////////8////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////8////////////////////////
/////P//////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////P////////////////////////////z/////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////z////////////////////////////8////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////8/////////////////////////////P//////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////P//////
//////////////////////z/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////z/////////////////////
///////8////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////8/////////////////////////////P//////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////P////////////////////////////z/////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////z////////////////////////////8////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////8////
/////////////////////////P//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////P//////////////////
//////////z/////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////z////////////////////////////8////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////8/////////////////////////////P//////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////P////////////////////////////z/////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////z/
///////////////////////////8////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////8////////////////
/////////////P//////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////P////////////////////////////z/
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////z////////////////////////////8////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////8/////////////////////////////P//////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/P////////////////////////////z/////////////////////////////////////BwcHB///
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////z/////////////
///////////////8////////////////////////////////////Pz8/P///////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////z/////////////////
///////////8////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////8/////////////////////////////P//
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////P////////////////////////////z/////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////z////////////////////////////8////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////8
/////////////////////////////P//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////P//////////////
//////////////z/////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////z////////////////////////////8
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////8/////////////////////////////P//////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////P////////////////////////////z/////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//z////////////////////////////8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

------_=_NextPart_000_01C2EE3F.01C63EF8--

Delivery-date: Wed, 19 Mar 2003 10:34:34 -0800
Date: Wed, 19 Mar 2003 10:29:22 -0800
To: "Bhaskara Peela" <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: RE: Inter-area cspf
Cc: [email-masked], [email-masked]

Fully on Yakov's side on this comment. I personally do not see any 
requirement for additional routing protocols extension for multi-area TE.

JP.

At 21:13 18/03/2003 -0500, Bhaskara Peela wrote:
>[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>[email-masked] and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
>
>Hi,
>
>Mailing list archive points me to the following message regarding 
>inter/multi area CSPF by Yokov.
>
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[email-masked]]
> > Sent: Sunday, December 22, 2002 6:29 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2
> > to Proposed Standard
> >
> >
> > Suresh,
> >
> > > > > My recommendation against using this draft as the basis for
> > > > > building further TE-extensions to inter-area and mixed networks
> > > > > was in the context of OSPF Autonomous System (AS). I also
> > > > > mentioned the draft has scalability limitations in extending this
> > > > > to inter-area and mixed networks -  also in the context of OSPF AS.
> > > > >
> > > > > Without going into the details of the "Multi-area MPLS Traffic
> > > > > Enginering" draft - The work cited in this draft as going on to
> > > > > address multi-area TE is in the MPLS signalling context, not in
> > > > > the OSPF.
> > > >
> > > > As I said in my previous e-mail quite a few scenarios described in
> > > > draft-kompella-mpls-multiarea-te-03.txt are supported with the TE
> > > > extensions that are subject to this Last Call. That is precisely
> > > > while quite a few scenarios in the "Multi-area MPLS Traffic
> > Engineering"
> > > > draft do not require any additions to what is already defined
> > > > in the katz-yeung draft.
> > > >
> > > > Yakov.
> > >
>
>Does this mean to suggest inter-area constraint based path computation 
>should follow ideas presented in draft-kompella-mpls-multiarea-te-03.txt 
>and draft-katz-yeung-ospf-traffic-09.txt ?  Or is there any active 
>alternate process going on.  Can any one update this issue.
>
>thank you
>bhaskara
>
>-----Original Message-----
>From: Bhaskara Peela [mailto:[email-masked]]
>Sent: Tuesday, March 18, 2003 12:06 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Inter-area cspf
>
>
>[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>[email-masked] and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
>
>Hi,
>
>Can any one update me about the status of following drafts
>
>1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
>2)draft-lee-mpls-te-exchange-00.txt
>3)draft-lee-mpls-path-request-00.txt
>4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
>
>I would like to know what is the latest ongoing standadization process for 
>inter-area OSPF-TE LSA flooding
>for CSPF calculation for GMPLS or MPLS.
>
>thank you
>bhaskara
>--
>__________________________________________________________
>Sign-up for your own FREE Personalized E-mail at Mail.com
>http://www.mail.com/?sr=signup

Delivery-date: Wed, 19 Mar 2003 10:22:44 -0800
Date: Wed, 19 Mar 2003 13:21:31 -0500
To: "Wijnen, Bert (Bert)" <[email-masked]>, "Ccamp-wg (E-mail)" <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: WG Last Cal for draft-ietf-ccamp-lmp-mib-04.txt

>Before you do the WG Last Call, I would urge the authors to
>- check that the MIB does comply with
>    draft-ietf-ops-mib-review-guidelines-01.txt
>- Note that since this doc has been around for a while,
>   quite a few references (plus the MIB boilerplate and
>   security considerations and such have changed as
>   a result of SNMPv3 having advanced to full STD).
>   details are in:
>      draft-ietf-ops-mib-review-guidelines-01.txt
>   and at www.ops.ietf.org

         Will do. The boilerplate is definitely out
of date.

>- note that I did not do a detailed review this time, just a quick
>   check to see if this si ready for WG Last Call.
>   I'd hope that authors and WG chairs make sure that the
>   document is in good shape as per the guidelines in
>    draft-ietf-ops-mib-review-guidelines-01.txt

         Will do.

>- make sure that the SMI syntax errors/warnings (see below)
>   are fixed/addressed
>
>
>E: f(lmp.mi2), (326,20) Index item "lmpCcId" must be defined with syntax 
>that in
>cludes a range
>W: f(lmp.mi2), (2212,20) Variable "ifIndex" in notification 
>"lmpDataLinkProperty
>Mismatch" is an index for a table
>W: f(lmp.mi2), (2265,20) Variable "ifIndex" in notification 
>"lmpTeLinkDegraded"
>is an index for a table
>W: f(lmp.mi2), (2275,20) Variable "ifIndex" in notification 
>"lmpTeLinkNotDegrade
>d" is an index for a table
>W: f(lmp.mi2), (2287,20) Variable "ifIndex" in notification 
>"lmpDataLinkVerifica
>tionFailure" is an index for a table
>W: f(lmp.mi2), (2637,19) MIN-ACCESS value identical to access specified 
>for "lmp
>CcOperStatus"
>W: f(lmp.mi2), (2690,19) MIN-ACCESS value identical to access specified 
>for "lmp
>TeLinkOperStatus"
>W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access specified 
>for "lmp
>DataLinkActiveOperStatus"
>W: f(lmp.mi2), (2767,19) MIN-ACCESS value identical to access specified 
>for "lmp DataLinkPassiveOperStatus"

         We will post a new revision based on these comments
next week.

         --Tom

>Thanks,
>Bert

Delivery-date: Wed, 19 Mar 2003 10:16:33 -0800
From: "Alanqar, Wesam I [GMG]" <[email-masked]>
To: "'Ron Bonica'" <[email-masked]>, "'kireeti'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: ITU-T SG15 updates to IETF CCAMP
Date: Wed, 19 Mar 2003 12:15:43 -0600

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

Folks-

Attached is ITU-T SG15 updates to IETF CCAMP that was presented today in
IETF-56 meeting.

Thanks.

-----------------------------------------------------------------
Wesam Alanqar                         
ITU-T SG15 representative to IETF CCAMP.
Member of Technical Staff
Technology Architecture & Planning (TA&P)
Wireline Technology Development
-----------------------------------------------------------------

------_=_NextPart_000_01C2EE43.8DC752A8
Content-Type: application/vnd.ms-powerpoint;
	name="ietf-56_ITU SG15 updates_r1.ppt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="ietf-56_ITU SG15 updates_r1.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAHAAAAcQIAAAAAAAAA
EAAAcwIAAAEAAAD+////AAAAAEYCAABHAgAASAIAAEkCAAByAgAAeQIAAPsCAAD/////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz/////////vOK83f//vb3///////////////////////////////z/////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////8///////du9y0
tLuub73////////////////////////////////8////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////8/////5OS3f//tbu1tLz/////////////////
///////////////8////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////P////+9/7W7u7y1u///////////////////////////////////
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz////D////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/////////////////////////////P//////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////P//////////
//////////////////z/////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////z/////////////////////////
///8////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////8/////////////////////////////P//////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////P////////////////////////////z/////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////z////////////////////////////8////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////8////////
/////////////////////P//////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////P//////////////////////
//////z/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////z////////////////////////////8////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////8/////////////////////////////P//////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////P////////////////////////////z/////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////8/////////////////////////////P//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////P//
//////////////////////////z/////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////P//////////////
//////////////z/////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////z////////////////////////////8
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////8/////////////////////////////P//////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////8/////////////////////////////P//////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////P////////////////////////////z/////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////z/////////
///////////////////8////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////8////////////////////////
/////P//////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////P////////////////////////////z/////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////z////////////////////////////8////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////8/////////////////////////////P//////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////P//////
//////////////////////z/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////z/////////////////////
///////8////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////8/////////////////////////////P//////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////P////////////////////////////z/////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////z////////////////////////////8////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////8////
/////////////////////////P//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////P//////////////////
//////////z/////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////z////////////////////////////8////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////8/////////////////////////////P//////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////P////////////////////////////z/////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////z/
///////////////////////////8////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////8////////////////
/////////////P//////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////P////////////////////////////z/
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////z////////////////////////////8////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////8/////////////////////////////P//////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/P////////////////////////////z/////////////////////////////////////BwcHB///
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////z/////////////
///////////////8////////////////////////////////////Pz8/P///////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////z/////////////////
///////////8////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////8/////////////////////////////P//
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////P////////////////////////////z/////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////z////////////////////////////8////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////8
/////////////////////////////P//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////P//////////////
//////////////z/////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////z////////////////////////////8
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////8/////////////////////////////P//////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////P////////////////////////////z/////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//z////////////////////////////8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8
/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

------_=_NextPart_000_01C2EE43.8DC752A8--

Delivery-date: Wed, 19 Mar 2003 10:13:29 -0800
From: "Bhaskara Peela" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 18 Mar 2003 21:13:19 -0500
Subject: RE: Inter-area cspf

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi,

Mailing list archive points me to the following message regarding inter/multi area CSPF by Yokov.  

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Sunday, December 22, 2002 6:29 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2
> to Proposed Standard
>
>
> Suresh,
>
> > > > My recommendation against using this draft as the basis for
> > > > building further TE-extensions to inter-area and mixed networks
> > > > was in the context of OSPF Autonomous System (AS). I also
> > > > mentioned the draft has scalability limitations in extending this
> > > > to inter-area and mixed networks -  also in the context of OSPF AS.
> > > >
> > > > Without going into the details of the "Multi-area MPLS Traffic
> > > > Enginering" draft - The work cited in this draft as going on to
> > > > address multi-area TE is in the MPLS signalling context, not in
> > > > the OSPF.
> > >
> > > As I said in my previous e-mail quite a few scenarios described in
> > > draft-kompella-mpls-multiarea-te-03.txt are supported with the TE
> > > extensions that are subject to this Last Call. That is precisely
> > > while quite a few scenarios in the "Multi-area MPLS Traffic
> Engineering"
> > > draft do not require any additions to what is already defined
> > > in the katz-yeung draft.
> > >
> > > Yakov.
> >

Does this mean to suggest inter-area constraint based path computation should follow ideas presented in draft-kompella-mpls-multiarea-te-03.txt and draft-katz-yeung-ospf-traffic-09.txt ?  Or is there any active alternate process going on.  Can any one update this issue.

thank you
bhaskara

-----Original Message-----
From: Bhaskara Peela [mailto:[email-masked]]
Sent: Tuesday, March 18, 2003 12:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: Inter-area cspf

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi,

Can any one update me about the status of following drafts

1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
2)draft-lee-mpls-te-exchange-00.txt
3)draft-lee-mpls-path-request-00.txt
4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt

I would like to know what is the latest ongoing standadization process for inter-area OSPF-TE LSA flooding
for CSPF calculation for GMPLS or MPLS.

thank you
bhaskara
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Delivery-date: Wed, 19 Mar 2003 10:13:07 -0800
From: "Bhaskara Peela" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 18 Mar 2003 22:09:53 -0500
Subject: Re: Inter-area cspf

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

----- Original Message -----
From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 18 Mar 2003 21:07:39 -0500
To: Bhaskara Peela <[email-masked]>
Subject: Re: Inter-area cspf

> Bhaskara,
> Regarding (2) & (3), my understanding is a more distributed approach
> described in draft-lee-ccamp-exclude-route more preferable than the
> "Path Computation Entity" approach in (3).
> You may want to take a look at this draft which will be presented by
> Adrian Farrel in CCAMP WG meeting on Wednesday. It is not limited to
> inter-area only (and does not address IGP-TE LSA flooding).
> 
> Regards,
> Cheng-Yin
> 
> Bhaskara Peela wrote:
> > 
> > [ post by non-subscriber.  with the massive amount of spam, it is easy to miss
> >   and therefore delete posts by non-subscribers.  if you wish to regularly
> >   post from an address that is not subscribed to this mailing list, send a
> >   message to <listname>[email-masked] and ask to have the alternate
> >   address added to the list of addresses from which submissions are
> >   automatically accepted. ]
> > 
> > Hi,
> > 
> > Can any one update me about the status of following drafts
> > 
> > 1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
> > 2)draft-lee-mpls-te-exchange-00.txt
> > 3)draft-lee-mpls-path-request-00.txt
> > 4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
> > 
> > I would like to know what is the latest ongoing standadization process for inter-area OSPF-TE LSA flooding
> > for CSPF calculation for GMPLS or MPLS.
> > 
> > thank you
> > bhaskara
> > --
> > __________________________________________________________
> > Sign-up for your own FREE Personalized E-mail at Mail.com
> > http://www.mail.com/?sr=signup

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Delivery-date: Wed, 19 Mar 2003 10:12:36 -0800
From: "Bhaskara Peela" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 18 Mar 2003 22:09:14 -0500
Subject: Re: Inter-area cspf

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi Cheng-Yin,

Thank you for mail.

The draft-lee-ccamp-rsvp-te-exclude-route-02.txt does only
address issues for establishing LSPs based on SRLG for different protection/divergent mechanisms.  But, to specify a SRLG/XRO/EXRS, we need to first know  or populate the TE database  across OSPF areas and AS domains.  It does not address how this SRLG can be specified or how the divergence of LSPs for protection is achived in case of inter-area or inter-domain.  Are u suggesting this information can be drawn from draft-lee-mpls-path-request-04.txt.

Please clarify.

thank you
bhaskara
----- Original Message -----
From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 18 Mar 2003 21:07:39 -0500
To: Bhaskara Peela <[email-masked]>
Subject: Re: Inter-area cspf

> Bhaskara,
> Regarding (2) & (3), my understanding is a more distributed approach
> described in draft-lee-ccamp-exclude-route more preferable than the
> "Path Computation Entity" approach in (3).
> You may want to take a look at this draft which will be presented by
> Adrian Farrel in CCAMP WG meeting on Wednesday. It is not limited to
> inter-area only (and does not address IGP-TE LSA flooding).
> 
> Regards,
> Cheng-Yin
> 
> Bhaskara Peela wrote:
> > 
> > [ post by non-subscriber.  with the massive amount of spam, it is easy to miss
> >   and therefore delete posts by non-subscribers.  if you wish to regularly
> >   post from an address that is not subscribed to this mailing list, send a
> >   message to <listname>[email-masked] and ask to have the alternate
> >   address added to the list of addresses from which submissions are
> >   automatically accepted. ]
> > 
> > Hi,
> > 
> > Can any one update me about the status of following drafts
> > 
> > 1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
> > 2)draft-lee-mpls-te-exchange-00.txt
> > 3)draft-lee-mpls-path-request-00.txt
> > 4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
> > 
> > I would like to know what is the latest ongoing standadization process for inter-area OSPF-TE LSA flooding
> > for CSPF calculation for GMPLS or MPLS.
> > 
> > thank you
> > bhaskara
> > --
> > __________________________________________________________
> > Sign-up for your own FREE Personalized E-mail at Mail.com
> > http://www.mail.com/?sr=signup

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Delivery-date: Wed, 19 Mar 2003 10:09:49 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: WG Last Cal for draft-ietf-ccamp-lmp-mib-04.txt
Date: Wed, 19 Mar 2003 18:36:08 +0100

Before you do the WG Last Call, I would urge the authors to
- check that the MIB does comply with 
   draft-ietf-ops-mib-review-guidelines-01.txt
- Note that since this doc has been around for a while,
  quite a few references (plus the MIB boilerplate and 
  security considerations and such have changed as
  a result of SNMPv3 having advanced to full STD).
  details are in:
     draft-ietf-ops-mib-review-guidelines-01.txt
  and at www.ops.ietf.org

- note that I did not do a detailed review this time, just a quick
  check to see if this si ready for WG Last Call.
  I'd hope that authors and WG chairs make sure that the
  document is in good shape as per the guidelines in
   draft-ietf-ops-mib-review-guidelines-01.txt

- make sure that the SMI syntax errors/warnings (see below) 
  are fixed/addressed

E: f(lmp.mi2), (326,20) Index item "lmpCcId" must be defined with syntax that in
cludes a range
W: f(lmp.mi2), (2212,20) Variable "ifIndex" in notification "lmpDataLinkProperty
Mismatch" is an index for a table
W: f(lmp.mi2), (2265,20) Variable "ifIndex" in notification "lmpTeLinkDegraded"
is an index for a table
W: f(lmp.mi2), (2275,20) Variable "ifIndex" in notification "lmpTeLinkNotDegrade
d" is an index for a table
W: f(lmp.mi2), (2287,20) Variable "ifIndex" in notification "lmpDataLinkVerifica
tionFailure" is an index for a table
W: f(lmp.mi2), (2637,19) MIN-ACCESS value identical to access specified for "lmp
CcOperStatus"
W: f(lmp.mi2), (2690,19) MIN-ACCESS value identical to access specified for "lmp
TeLinkOperStatus"
W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access specified for "lmp
DataLinkActiveOperStatus"
W: f(lmp.mi2), (2767,19) MIN-ACCESS value identical to access specified for "lmp
DataLinkPassiveOperStatus"

Thanks,
Bert 

Delivery-date: Wed, 19 Mar 2003 03:50:26 -0800
From: Manoj Agiwal <[email-masked]>
To: "'Ccamp (E-mail)" <[email-masked]>
Subject: Component Links
Date: Wed, 19 Mar 2003 05:43:41 -0600

Hi ,
Generalized Signaling RFC 3471 , says about component Links 
"For types 4 and 5, the Interface ID indicates a bundled component link. The
special value 0xFFFFFFFF can be used to indicate the same label is to be
valid across all component links."
How this value 0xFFFFFFFF is supposed to get used ?
How will one identify component link if value in Interface Id is 0xFFFFFFFF
?
Regards ,
Manoj

Delivery-date: Wed, 19 Mar 2003 00:14:34 -0800
Date: Wed, 19 Mar 2003 00:11:12 -0800
To: "Bhaskara Peela" <[email-masked]>
From: Jean Philippe Vasseur <[email-masked]>
Subject: Re: Inter-area cspf
Cc: [email-masked], [email-masked]

Hi,

FYI, if you're interested by multi-area TE, you might want to consider:
- http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt
For PCS-PCC signalling (scenarios 2,4 and 5 on of the previous draft) see:
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-computation-rsvp-03.txt

JP.

At 15:06 18/03/2003 -0500, Bhaskara Peela wrote:
>[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>[email-masked] and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
>
>Hi,
>
>Can any one update me about the status of following drafts
>
>1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
>2)draft-lee-mpls-te-exchange-00.txt
>3)draft-lee-mpls-path-request-00.txt
>4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
>
>I would like to know what is the latest ongoing standadization process for 
>inter-area OSPF-TE LSA flooding
>for CSPF calculation for GMPLS or MPLS.
>
>thank you
>bhaskara
>--
>__________________________________________________________
>Sign-up for your own FREE Personalized E-mail at Mail.com
>http://www.mail.com/?sr=signup

Delivery-date: Tue, 18 Mar 2003 18:10:21 -0800
Date: Tue, 18 Mar 2003 21:07:39 -0500
From: "Cheng-Yin Lee" <[email-masked]>
Reply-To: [email-masked]
To: Bhaskara Peela <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Inter-area cspf

Bhaskara,
Regarding (2) & (3), my understanding is a more distributed approach
described in draft-lee-ccamp-exclude-route more preferable than the
"Path Computation Entity" approach in (3).
You may want to take a look at this draft which will be presented by
Adrian Farrel in CCAMP WG meeting on Wednesday. It is not limited to
inter-area only (and does not address IGP-TE LSA flooding).

Regards,
Cheng-Yin

Bhaskara Peela wrote:
> 
> [ post by non-subscriber.  with the massive amount of spam, it is easy to miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>[email-masked] and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
> 
> Hi,
> 
> Can any one update me about the status of following drafts
> 
> 1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
> 2)draft-lee-mpls-te-exchange-00.txt
> 3)draft-lee-mpls-path-request-00.txt
> 4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
> 
> I would like to know what is the latest ongoing standadization process for inter-area OSPF-TE LSA flooding
> for CSPF calculation for GMPLS or MPLS.
> 
> thank you
> bhaskara
> --
> __________________________________________________________
> Sign-up for your own FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup

Delivery-date: Tue, 18 Mar 2003 15:15:10 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Dimitri Papadimitriou <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
Date: Wed, 19 Mar 2003 00:13:18 +0100

Dimitri says:
> hi steve,
>  
> > All,
> > Bert asked me to have a look at this from an ITU-T perspective.
> 
> what does that really mean ?
> 
This means that I got an IETF document from one of the WGs for which
I am the responsible AD. It also means that this document is about
using SONET/SDH overhead bytes, which I think are under control of ITU.
So I want to check for such type of documents if there are issues
from the "owning SDO" with the proposed use of such overhead bytes

Seems to be doing due diligence on my part.

And since Steve is often (one of) the interface people from SG15
to IETF (he is vice chair of SG15), that is why I asked him.

I also asked Deborah Brungard (T1X1) with the same question.

Hope this explains.
Bert

Delivery-date: Tue, 18 Mar 2003 14:51:47 -0800
From: "Jonathan Lang" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt
Date: Tue, 18 Mar 2003 11:41:43 -0800

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Adrian,
  Thanks for your comments.  See inline for responses.

Thanks,
Jonathan

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Sunday, March 16, 2003 8:22 AM
> To: [email-masked]; Yakov Rekhter
> Cc: [email-masked]; Sudheer Dharanikota (E-mail); John Drake; 
> [email-masked]; [email-masked]; 'Dimitri 
> Papadimitriou'; 'Bala Rajagopalan'; [email-masked]
> Subject: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt
> 
> Hi Recovery Team,
> 
> I'm sure you considered it, but could you explain why you did not pack

> the fields of the Protection Object so that they fit within the size 
> and structure of the existing Protection Object. This would have the 
> considerable advantage of
> being backwards compatible with existing implementations .
Basically we wanted to allow the "LSP Flags" and "Link Flags" to be
extensible (I'm not sure we've thought of all the creative
protection/restoration schemes just yet...).

> 
> There seems to be some confusion as to whether the PRRO is an explicit

> path or a recorded route. The abbreviation seems to suggest a recorded

> route and that fits
> with my understanding of how secondary LSP setup might be kept diverse
> from the
> primary path. But the text describes using the explicit route of the
> primary
> LSP - since this may include loose hops or unspecific abstract nodes,
it
> is not
> sufficiently specific.
The Primary Path Route Object (PPRO - there is a typo in the draft)
contains information about the Primary Path.  This information could be
obtained from the RRO or the ERO of the Primary Path depending on the
information.  Currently, this object may contain IPv4, IPv6, label, and
unnumbered interfaces.  (SRLGs can be obtained from the IGP database
using the link/node information.)  We can add Autonomous System number
if that is useful.

> 
> I think in this kind of diversity situation you need to be able to 
> express unnumbered links, numbered links, nodes, labels, SRLGs and 
> even (possibly) AS numbers. You don't seem to have all of these 
> covered.
> 
> When considering how to set up a diverse path I would like you to look

> at draft-lee-ccamp-rsvp-te-exclude-route-02.txt which already contains

> a mechanism to specify exclusions.
We read the Lee draft, but it was more restrictive than we wanted this
to be.  We don't want the PPRO to be an "Exclude Route".  Rather, it is
a local policy issue how to use the PPRO.

> 
> Thanks,
> Adrian
> 
> PS I notice that chunks of the text hold a striking resemblance to 
> text I wrote for draft-lang-ccamp-recovery-00/01. That's all to the 
> good, but credit would be
> nice.
Thanks.  We'll add a proper acknowledgement section to the next version.

Delivery-date: Tue, 18 Mar 2003 14:51:32 -0800
From: "Jonathan Lang" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt
Date: Tue, 18 Mar 2003 12:08:30 -0800

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Adrian,
  Thanks for your comments.  See inline for responses.

Thanks,
Jonathan

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Sunday, March 16, 2003 8:22 AM
> To: [email-masked]; Yakov Rekhter
> Cc: [email-masked]; Sudheer Dharanikota (E-mail); John Drake; 
> [email-masked]; [email-masked]; 'Dimitri 
> Papadimitriou'; 'Bala Rajagopalan'; [email-masked]
> Subject: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt
> 
> Hi Recovery Team,
> 
> I'm sure you considered it, but could you explain why you did not pack

> the fields of the Protection Object so that they fit within the size 
> and structure of the existing Protection Object. This would have the 
> considerable advantage of
> being backwards compatible with existing implementations .
Basically we wanted to allow the "LSP Flags" and "Link Flags" to be
extensible (I'm not sure we've thought of all the creative
protection/restoration schemes just yet...).

> 
> There seems to be some confusion as to whether the PRRO is an explicit

> path or a recorded route. The abbreviation seems to suggest a recorded

> route and that fits
> with my understanding of how secondary LSP setup might be kept diverse
> from the
> primary path. But the text describes using the explicit route of the
> primary
> LSP - since this may include loose hops or unspecific abstract nodes,
it
> is not
> sufficiently specific.
The Primary Path Route Object (PPRO - there is a typo in the draft)
contains information about the Primary Path.  This information could be
obtained from the RRO or the ERO of the Primary Path depending on the
information.  Currently, this object may contain IPv4, IPv6, label, and
unnumbered interfaces.  (SRLGs can be obtained from the IGP database
using the link/node information.)  We can add Autonomous System number
if that is useful.

> 
> I think in this kind of diversity situation you need to be able to 
> express unnumbered links, numbered links, nodes, labels, SRLGs and 
> even (possibly) AS numbers. You don't seem to have all of these 
> covered.
> 
> When considering how to set up a diverse path I would like you to look

> at draft-lee-ccamp-rsvp-te-exclude-route-02.txt which already contains

> a mechanism to specify exclusions.
We read the Lee draft, but it was more restrictive than we wanted this
to be.  We don't want the PPRO to be an "Exclude Route".  Rather, it is
a local policy issue how to use the PPRO.

> 
> Thanks,
> Adrian
> 
> PS I notice that chunks of the text hold a striking resemblance to 
> text I wrote for draft-lang-ccamp-recovery-00/01. That's all to the 
> good, but credit would be
> nice.
Thanks.  We'll add a proper acknowledgement section to the next version.

Delivery-date: Tue, 18 Mar 2003 14:51:20 -0800
From: "Bhaskara Peela" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 18 Mar 2003 15:06:00 -0500
Subject: Inter-area cspf

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi,

Can any one update me about the status of following drafts

1)draft-ash-ccamp-multi-area-te-reqmts-00.txt
2)draft-lee-mpls-te-exchange-00.txt
3)draft-lee-mpls-path-request-00.txt
4)draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt

I would like to know what is the latest ongoing standadization process for inter-area OSPF-TE LSA flooding
for CSPF calculation for GMPLS or MPLS.

thank you
bhaskara
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Delivery-date: Tue, 18 Mar 2003 14:01:34 -0800
Subject: Re: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
To: [email-masked] (Stephen Trowbridge)
Date: Tue, 18 Mar 2003 14:00:35 -0800 (PST)
Cc: [email-masked]
From: Dimitri Papadimitriou <[email-masked]>

hi steve,
 
> All,
> Bert asked me to have a look at this from an ITU-T perspective.

what does that really mean ?

> As I look back through the email archives, I see a number of issues
> that were raised that were never addressed before (or after) a WG last
> call was issued for the -00 draft this document during Dec. 2002.

would you please share with us this list of issues that were not
addressed

> There were a number of comments raised with respect to the draft
> in particular from Sept-Nov 2002 that were not addressed. 

we are not aware of any lmp sonet-sdh i-d comments that haven't been 
addressed since so far (even after this i-d passed the last call)
 
> In addition,
> there is the entire thread (2002 archive) "J0/J1 encoding issues" that
> applies to this draft that was never addressed. Perhaps the December
> last call slipped by "under radar" without these issues having been
> addressed.

or the people that raised these issues are satisfied with the answers

> I think that the simplest way to resolve the issues is to align
> the draft with ITU-T G.7714.1 (as has Dimitri just did for
> draft-lang-ccamp-lmp-bootstrap-03.txt). Then we have all the documents
> aligned around the same J0/J1 format.
> 
> Once this alignment is done, I think the next question is whether
> draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt contains any extra information
> over what is in ITU-T G.7714.1. If not, perhaps it can just go info track
> if the normative text is in ITU-T G.7714.1.

the IETF lmp sonet-sdh link verification is compliant with G.707

hope this clarifies,

regards,
- dimitri.

> Regards,
> Steve
> 
> 

Envelope-to: [email-masked]
Delivery-date: Tue, 18 Mar 2003 08:28:10 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ron Bonica" <[email-masked]>
Cc: <[email-masked]>
Subject: draft-bonica-tunproto-04.txt
Date: Tue, 18 Mar 2003 03:06:20 -0500

Hi Ron,

Some thoughts on re-reading this draft...

I think the draft is long enough to need a contents table.

Although the access control function is mandatory, why is the Access Control
Object mandatory on a traceProbe? If the requester has nothing to say and the
reporter is happy with that, why force the object to be present?

It wasn't clear to me until reading the section on head-end object timestamps
that the traceResponse is routed back through the head of the tunnel. Doesn't
this assume that you have a bidirectional tunnel? Apart from the round-trip time
function, why wouldn't you send the traceResponse back to the source by a more
direct route?

Isn't there a problem with the TTL method of finding the next hop? The path of
the tunnel may change from one probe to the next giving the appearance of loops
(gaps are less important). You either need to describe apparent loops and how to
prune them, or you need to use another hop identification mechanism.

Why is the Access Control Object present on the traceResponse?

Format diagrams - all the bit counts need to right-shift by one.

Is the ordering of objects in messages mandatory, suggested, optional?

Was there a protocol version 0?

Lengths. Message lengths appear to be inclusive, object lengths exclusive.
Consistency would be nice. When you describe the individual objects the length
values you give are actually inclusive. Note also that object lengths refer to a
count of 32-bit words that follow, but are often (never?) the last byte in a
32-bit word.

Errors. For unknown, malformed and missing objects it is nice to be able to
indicate the object type that is in error. Note also, that if the error is
missing object, it may not be possible to correctly format a TraceResponse
Message.

Addresses here are only IPv4. Would it be worth including IPv6 variants?

Need an error code for IP Header and Tunnel Object both present?

5.2.7 missing description of hop count

Need error needed for hop count flag set and responder address present?

Several places say "can be 0 padded for word alignment". I think this should
read "MUST".

5.2.11 Support for unnumbered interfaces?

5.2.12 Flags field. Which bit is bit 0? Compare Propagation Object where you say
"right-most bit".

Tunnel type.  GRE?

I think the security section needs some oomph!

Cheers,
Adrian

Delivery-date: Mon, 17 Mar 2003 20:20:49 -0800
Date: Mon, 17 Mar 2003 21:19:15 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: ccamp <[email-masked]>
Subject: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt

All,
Bert asked me to have a look at this from an ITU-T perspective.
As I look back through the email archives, I see a number of issues
that were raised that were never addressed before (or after) a WG last
call was issued for the -00 draft this document during Dec. 2002.
There were a number of comments raised with respect to the draft
in particular from Sept-Nov 2002 that were not addressed. In addition,
there is the entire thread (2002 archive) "J0/J1 encoding issues" that
applies to this draft that was never addressed. Perhaps the December
last call slipped by "under radar" without these issues having been
addressed.

I think that the simplest way to resolve the issues is to align
the draft with ITU-T G.7714.1 (as has Dimitri just did for
draft-lang-ccamp-lmp-bootstrap-03.txt). Then we have all the documents
aligned around the same J0/J1 format.

Once this alignment is done, I think the next question is whether
draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt contains any extra information
over what is in ITU-T G.7714.1. If not, perhaps it can just go info track
if the normative text is in ITU-T G.7714.1.
Regards,
Steve

Delivery-date: Mon, 17 Mar 2003 08:31:58 -0800
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "'Dimitri Papadimitriou'" <[email-masked]>
Cc: <[email-masked]>
Subject: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
Date: Mon, 17 Mar 2003 02:54:48 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_005F_01C2EC30.934408D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
Further to Bert's comments I have some thoughts and typos for you. Sorry =
if there is any duplication with what Bert has already said.

Cheers,
Adrian

Section 3.1 Verify Transport Mechanism Field
I think you need to clarify that the values defined here supplement =
those from other sources (e.g. LMP). You should probably turn the field =
over to IANA.

Section 3.1 J0-16
I think it would really help to show a picture. How about...
                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| resvd |Msg|I|X|   IF_ID     |X| IF_ID (cont)|X| IF_ID (cont)|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IF_ID (cont)|X| IF_ID |VerId|X| VerId (cont)|X| VerId (cont)|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerId (cont)|X| VerId (cont)|X|V| reserved  |X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Section 4 bullet 2
I'm not clear what you mean by "A node may request..."
Is this the sender requesting the receiver to report the Test Message it =
is seeing, or the receiver asking the sender what Test Message it is =
sending? Or are both allowed?

Section 4.1.3 TraceMonitorNack
Could "Invalid Trace Message" errors include the actual Trace Message =
received in the Nack message?

Section 4.1.4 TraceMismatch
ditto

Section 4.1.8 TraceReqNack
Hopefully there is a reason for sending this message :-)
What are the error codes? Just "unsupported trace type"?

Section 4.1.9 InsertTrace
Can we tell a node to stop sending the specified trace message? Do we =
care?

Section 4.1.10 InsertTraceAck
What is meant by "(i.e. no Trace Mismatch)"?=20
How could receiving an InsertTrace message generate a trace mismatch?

Section 4.1.11 InsertTraceNack
What are the specific errors here?
Error in the value presumably could map to "Invalid Trace Message" (2)
What about Trace Monitoring Not Supported. Presumably this should read =
"Trace Insertion Not Supported". Do we use "Unsupported Trace Type" (1)?

Section 6 IANA
I think you need error codes and Verify Transport Mechanism field here

Typos and Nits
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Section 1 para 1
"or they may represent a Label Switch Path"
should read "...represent one or more..."

Section 1 para 2
delete "being developed as"

Section 3 para 2
"This can be initiated..."
Implies there are other ways to initiate the verification process.

Section 4.1.1.1 Trace Message field
This definition doesn't apply to the object used in a Trace Report.

Lots of section cross-references have spurious whitespace

Section 4.1.9 para 1
"that the remote knows the mapping" insert 'node'

Section 4.1.9 penultimate para
"used to indicate a trace message occurred." insert 'error'

------=_NextPart_000_005F_01C2EC30.934408D0
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Further to Bert's comments I have =
some thoughts=20
and typos for you. Sorry if there is any duplication with what Bert has =
already=20
said.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Cheers,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 3.1 Verify Transport =
Mechanism=20
Field</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I think you need to clarify that the =
values=20
defined here supplement those from other sources (e.g. LMP). You should =
probably=20
turn the field over to IANA.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 3.1 J0-16</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I think it would really help to show =
a picture.=20
How about...</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
3</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;0 1 2 3 4 5 6&nbsp;7 8 9 0 1 2 =
3 4 5 6 7 8=20
9 0 1 2 3 4 5 6 7 8 9 0 1</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>| resvd |Msg|I|X|&nbsp; =20
IF_ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|X| IF_ID (cont)|X| IF_ID=20
(cont)|X|</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>
<DIV><FONT face=3DCourier=20
size=3D2>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>|&nbsp;IF_ID (cont)|X| IF_ID =
|VerId|X| VerId=20
(cont)|X| VerId (cont)|X|</FONT></DIV>
<DIV>
<DIV><FONT face=3DCourier=20
size=3D2>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+</FONT></DIV>|=20
VerId (cont)|X| VerId (cont)|X|V| reserved&nbsp; |X|</DIV>
<DIV>
<DIV><FONT face=3DCourier=20
size=3D2>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</FONT></DIV></=
DIV></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4 bullet 2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I'm not clear what you mean by "A =
node may=20
request..."</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Is this the sender requesting the =
receiver to=20
report the Test Message it is seeing, or the receiver asking the sender =
what=20
Test Message it is sending? Or are both allowed?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.1.3 =
TraceMonitorNack</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Could "Invalid Trace Message" errors =
include the=20
actual Trace Message received in the Nack message?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.1.4 =
TraceMismatch</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>ditto</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.1.8 =
TraceReqNack</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Hopefully there is a reason for =
sending this=20
message :-)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>What are the error codes? Just =
"unsupported trace=20
type"?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.1.9 =
InsertTrace</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Can we tell a node to stop sending =
the specified=20
trace message? Do we care?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.1.10 =
InsertTraceAck</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>What is meant by "(i.e. no Trace =
Mismatch)"?=20
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>How could receiving an InsertTrace =
message=20
generate a trace mismatch?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.1.11 =
InsertTraceNack</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>What are the specific errors =
here?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Error in the value presumably could =
map to=20
"Invalid Trace Message" (2)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>What about Trace Monitoring Not =
Supported.=20
Presumably this should read "Trace Insertion Not Supported". Do we use=20
"Unsupported Trace Type" (1)?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 6 IANA</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I think you need error codes and =
Verify Transport=20
Mechanism field here</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Typos and Nits</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 1 para 1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>"or they may represent a Label Switch =

Path"</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>should read "...represent one or=20
more..."</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 1 para 2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>delete "being developed =
as"</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 3 para 2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>"This can be =
initiated..."</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Implies there are other ways to =
initiate the=20
verification process.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.1.1.1 Trace Message =
field</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>This definition doesn't apply to the =
object used=20
in a Trace Report.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>
<DIV>Lots of section cross-references have spurious whitespace</DIV>
<DIV>&nbsp;</DIV>
<DIV>Section 4.1.9 para 1</DIV>
<DIV>"that the remote knows the mapping" insert 'node'</DIV>
<DIV>&nbsp;</DIV>
<DIV>Section 4.1.9 penultimate para</DIV>
<DIV>"used to indicate a trace message occurred." insert 'error'</DIV>
<DIV>&nbsp;</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_005F_01C2EC30.934408D0--

Envelope-to: [email-masked]
Delivery-date: Sun, 16 Mar 2003 21:05:32 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>, "Sudheer Dharanikota \(E-mail\)" <[email-masked]>, "John Drake" <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Dimitri Papadimitriou'" <[email-masked]>, "'Bala Rajagopalan'" <[email-masked]>, <[email-masked]>
Subject: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt
Date: Sun, 16 Mar 2003 11:22:21 -0500

Hi Recovery Team,

I'm sure you considered it, but could you explain why you did not pack the
fields of the Protection Object so that they fit within the size and structure
of the existing Protection Object. This would have the considerable advantage of
being backwards compatible with existing implementations .

There seems to be some confusion as to whether the PRRO is an explicit path or a
recorded route. The abbreviation seems to suggest a recorded route and that fits
with my understanding of how secondary LSP setup might be kept diverse from the
primary path. But the text describes using the explicit route of the primary
LSP - since this may include loose hops or unspecific abstract nodes, it is not
sufficiently specific.

I think in this kind of diversity situation you need to be able to express
unnumbered links, numbered links, nodes, labels, SRLGs and even (possibly) AS
numbers. You don't seem to have all of these covered.

When considering how to set up a diverse path I would like you to look at
draft-lee-ccamp-rsvp-te-exclude-route-02.txt which already contains a mechanism
to specify exclusions.

Thanks,
Adrian

PS I notice that chunks of the text hold a striking resemblance to text I wrote
for draft-lang-ccamp-recovery-00/01. That's all to the good, but credit would be
nice.

Delivery-date: Thu, 13 Mar 2003 21:44:23 -0800
Date: Thu, 13 Mar 2003 23:39:17 -0600
From: Ben Mack-Crane <[email-masked]>
To: Shahram Davari <[email-masked]>
CC: [email-masked]
Subject: Re: GMPLS question

Hi Shahram,

I'm not sure what you mean when you say "encode GMPLS messages in 
SONET/SDH overhead."  GMPLS protocol messages are carried in IP packets. 
  There is a standard for carrying IP packets over SONET/SDH DCC 
channels (G.7712) that specifies using either PPP over HDLC-like framing 
or LAP-D.

Regards,
Ben

Shahram Davari wrote:
>>Hi,
>>
>>Is there any draft/RFC that specifies how to encode GMPLS messages in SONET/SDH overhead?
>>
>>Thanks,
>>Shahram
>>
>>
> 
> 

============================================================
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: Thu, 13 Mar 2003 15:09:59 -0800
From: "Jonathan Lang" <[email-masked]>
To: "'Wijnen, Bert \(Bert\)'" <[email-masked]>, "'Ccamp-wg \(E-mail\)'" <[email-masked]>
Subject: RE: AD review of draft-ietf-ccamp-lmp-07.txt
Date: Thu, 13 Mar 2003 15:02:57 -0800

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Bert,
  Thanks for the review of this and the other 2 LMP-related documents.
We will do a quick rev to address your comments so that you can request
an IETF Last Call.

Thanks,
Jonathan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Wijnen, Bert (Bert)
> Sent: Thursday, March 13, 2003 1:16 PM
> To: Ccamp-wg (E-mail)
> Subject: AD review of draft-ietf-ccamp-lmp-07.txt
> 
> Since I do not intend to request IETF Last Call before the
> IETF meeting in SF is over, maybe the authors can do a quick
> rev to try and address the following points.
> 
> Here are my review comments
> 
> - More or less serious:
> - scenario at end of sect 3.2.2
>   WOuld it not be wise to include the "waiting for interval
>   to expire" before a resend is done? Otherwise, if people
>   forget, I can see congestion being created.
> - IANA considerations
>   - I wonder if you want "IETF Consensus" based assignments.
>     There was quite some debate as to what that means recently.
>     Maybe you mean or want "standards action" instead?
>   - I also wonder... values 0-127 are allocated by expert review,
>     while the values in this doc (and a few other lmp related
>     docs on my plate) are in that space and are on stds track,
>     so they would be "standards action" based.
>   - So pls make sure that you have documented what you want/intend
> - sect 12.1 as example (this occurs several times). It says:
>    Msg Type: 8 bits.  The following values are defined.  All other
>              values are reserved and should be sent as zero and
ignored
>              on receipt.
>   But the values seem to be integer values and not bits. So I do not
>   understand the "All other values are reserved and should be sent as
> zero.."
>   especially the "should be sent as zero" seems strange in this case.
> 
> Nits:
> - sect 1. Expand acronyms when used for first time
>   examples are DWDM, TDm, WDM. There may be others
> - When I read (2nd para pge 9)
>     LMP adjacency.  The value of the Message_Id is monotonically
>     increasing and only decreases when the value wraps.
>   Then I think I would change
>     and only decreases when the value wraps.
>   into
>     and wraps when teh max value is reached
> - 2nd para sect 3.1
>   I guess that Node-Id of two nodes can never be equal.
>   But if such happens (by error) who is then the winning node,
>   or what should the behaviour be?
> - sect 3.2.1 2nd and 3rd para
>   Is for example a 1 millisecond interval valid?
>   WOuld it possibly cause congestion (rfc2914) ??
> - sect 3.2.2 (3rd para) explains when difference can be more
>   than 1. I think that in the case of UDP packet loss, the
>   diff can slo be more then 1, no?
> - at a few places I see msoft (non-ASCII) characters
>   p48, p57, maybe other places too.
> - I see at various places 16-bit flags (or other) fields and then
>   values are shown as:
>     0x01
>     0x02
>   This may not be 100% clear as to which bits are then used.
>   Do you mean
>     0x0001
>     0x0002
>   An example is page 53
> - Last sentence of sect 18 ?? DId that sonet test stuff not go to
>   a separate document ??
> 
> Thanks,
> Bert

Delivery-date: Thu, 13 Mar 2003 14:22:36 -0800
From: "Stephen Shew" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>
Cc: Jonathan Sadler <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS  vto  Proposed Standard
Date: Thu, 13 Mar 2003 17:21:38 -0500

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_01C2E9AE.EA089ED0
Content-Type: text/plain

Kireeti, I know I've really taken my time (days) to get text to you.  The
intent is to describe the motivation for layer information and not delve
into what attributes might be added in the future (e.g., max contiguous
connections on a link) or that may be layer specific.  In fact, attributes
could be created that address several factors at once.  The text could go
into section 3 somewhere of <draft-ietf-ccamp-gmpls-routing-05.txt>.

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

Representing TE Link Capabilities

In generalizing TE links to include traditional transport (in the optical
sense) facilities, there are additional factors that influence what
information is needed about the TE link.  These arise from existing
transport layer architecture (e.g., ITU-T Recommendations G.805 and G.806)
and associated layer services.  Some of these factors are:

1.	The need for LSPs at a specific adaptation, not just a particular
bandwidth.  Clients of optical networks obtain connection services for
specific adaptations.  For example a VC-3 circuit.  This not only implies a
particular bandwidth, but how the payload is structured.  Thus the VC-3
client would not be satisfied with any LSP that offered other than 48.384
Mbit/s and with the expected structure.

2.	Enable path computation to find a layer specific path.  Following
from the first factor, path computation must be able to find a route that
would give a connection at a specific adaptation.  For example a VC-3
connection where all hops maintain the VC-3 characteristic information.
This is conceptually identical to the situation where links in a routing
database have "colour" attributes and a path of a particular "colour" is
needed.

3.	Distinguishing variable adaptation.  A resource between two OXCs
(specifically a G.805 trail) can sometimes support different adaptations at
the same time.  An example of this is described in section 4.4.8.  In this
situation, the fact that two adaptations are supported on the same trail is
important because the two layers are dependent.  When a label (channel) is
used at a particular layer, it has the effect of modifying the available
labels in other layers supported on the same link.  It is important to thus
be able to reflect the layer relationship in routing.

4.	Interlayer relationships.  In L2 MPLS, it is possible to change
encapsulations (label type) throughout an LSP without much regard for the
bandwidth supported by the link at each hop.  This is a result of the
relative ease of adaptations between packet formats.  That is, at each LSP
hop the frame can be decapsulated and the data encapsulated in another L2
format.  In contrast, transport layers have much more restrictive
adaptations than in packet layer and are structured in an adaptation
hierarchy.  This lack of flexibility compared to packet layers requires
explicit indication of layer relationships.

5.	Inheritable attributes.  When a whole multiplexing hierarchy is
supported by a TE link, a lower layer attribute may be applicable to the
upper layers.  Protection attributes are a good example of this.  If an
OC-192 link is 1+1 protected (a duplicate OC-192 exists for protection),
then an OC-3c within that OC-192 (a higher layer) would inherit the same
protection property.  Recognizing this type of attribute is thus important
in TE links.

6.	Extensibility of layers.  In addition to the existing defined
transport layers, new layers and adaptation relationships could come into
existence in the future.  Keeping this in mind for TE-link attributes is
important.

7.	Heterogeneous networks whose OXCs do not all support the same set of
layers.  In a GMPLS network, not all transport layer network elements are
expected to support the same layers.  For example, there may be switches
capable of only VC-11, VC-12, and VC-3, where as there may be others that
can only support VC-3 and VC-4.  Even though a network element cannot
support a specific layer, it should be able to know if a network element
elsewhere in the network can support an adaptation that would enable that
unsupported layer to be used.  For example, a VC-11 switch could use a VC-3
capable switch if it knew that a VC-11 path could be constructed over a VC-3
link connection.

8.	Organization of links.  Within a given layer, resources between two
OXCs may be organized as several links.  Attributes may be associated with a
set of these links (bundles).

>From the factors presented above, development of layer specific GMPLS
routing drafts should use the following principles for TE-link attributes.
1.	The attributes in a given layer are separated from attributes in
another layer.

2.	Support of inter-layer attributes (e.g., adaptation relationships).
Between a client and server layer, a general mechanism for describing the
layer relationship exists.  For example "4 client links of type X can be
supported by this server layer link".  Another example is being able to
identify when two layers share a common server layer.

3.	Support inheritable attributes.  Attributes which can be inherited
should be identified.

4.	Attributes should be represented in routing such that future layers
can be accommodated.  This is much like the notion of the generalized label.

5.	Attribute scope should be explicit.  For example, whether the
attribute applies to a set of links at the same layer.

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]] 
Sent: Monday, March 03, 2003 17:40
To: Shew, Stephen [SKY:Q850:EXCH]
Cc: Jonathan Sadler; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS
vto Proposed Standard

Hi Stephen,

On Mon, 3 Mar 2003, Stephen Shew wrote:

> I don't know if the pun was intended, but I do like Kireeti's comment 
> about "bring them to light".

You're laser sharp, Stephen! :-)

> Undoubtedly, this would be within the ITU-T (wavelength) grid! ;-)

After the discussions we've had, I wouldn't dare not comply.

> There is, I think, some commonality in the comments and the reply in 
> that the intent is to generalize the extensions needed for routing to 
> accomodate non-PSC resources.  I agree with the first 4 points that 
> Jonathan made in that I think layer information must be included in 
> routing so that important functions can be performed.

Okay.  Can you provide text?

> I believe that the use of one or two bandwidth
> values was motivated by the desire to use a "lowest common 
> denominator" attribute to generalize on path computation and avoid 
> extensive details of links.  Unfortunately, this can obscure variable 
> adaptation on a link and the ability to determine a path at a 
> particular adaptation (e.g., VC-3).

You're right on both counts (about LCD, and about obscuring info). The
thinking was (a) let's see how far we can get with just the LCD;
(b) as we learn more, we can incorporate them, ideally in the SDH routing
doc.

Thoughts?

Kireeti.

------_=_NextPart_001_01C2E9AE.EA089ED0
Content-Type: text/html
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 =
5.5.2656.31">
<TITLE>RE: Last Call: Routing Extensions in Support of Generalized MPLS =
  vto  Proposed Standard</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Kireeti, I know I've really taken my time (days) to =
get text to you.&nbsp; The intent is to describe the motivation for =
layer information and not delve into what attributes might be added in =
the future (e.g., max contiguous connections on a link) or that may be =
layer specific.&nbsp; In fact, attributes could be created that address =
several factors at once.&nbsp; The text could go into section 3 =
somewhere of &lt;draft-ietf-ccamp-gmpls-routing-05.txt&gt;.</FONT></P>

<P><FONT SIZE=3D2>----------------------</FONT>
</P>

<P><FONT SIZE=3D2>Representing TE Link Capabilities</FONT>
</P>

<P><FONT SIZE=3D2>In generalizing TE links to include traditional =
transport (in the optical sense) facilities, there are additional =
factors that influence what information is needed about the TE =
link.&nbsp; These arise from existing transport layer architecture =
(e.g., ITU-T Recommendations G.805 and G.806) and associated layer =
services.&nbsp; Some of these factors are:</FONT></P>

<P><FONT SIZE=3D2>1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The need for LSPs at =
a specific adaptation, not just a particular bandwidth.&nbsp; Clients =
of optical networks obtain connection services for specific =
adaptations.&nbsp; For example a VC-3 circuit.&nbsp; This not only =
implies a particular bandwidth, but how the payload is =
structured.&nbsp; Thus the VC-3 client would not be satisfied with any =
LSP that offered other than 48.384 Mbit/s and with the expected =
structure.</FONT></P>

<P><FONT SIZE=3D2>2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Enable path =
computation to find a layer specific path.&nbsp; Following from the =
first factor, path computation must be able to find a route that would =
give a connection at a specific adaptation.&nbsp; For example a VC-3 =
connection where all hops maintain the VC-3 characteristic =
information.&nbsp; This is conceptually identical to the situation =
where links in a routing database have "colour" attributes and a path =
of a particular "colour" is needed.</FONT></P>

<P><FONT SIZE=3D2>3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Distinguishing =
variable adaptation.&nbsp; A resource between two OXCs (specifically a =
G.805 trail) can sometimes support different adaptations at the same =
time.&nbsp; An example of this is described in section 4.4.8.&nbsp; In =
this situation, the fact that two adaptations are supported on the same =
trail is important because the two layers are dependent.&nbsp; When a =
label (channel) is used at a particular layer, it has the effect of =
modifying the available labels in other layers supported on the same =
link.&nbsp; It is important to thus be able to reflect the layer =
relationship in routing.</FONT></P>

<P><FONT SIZE=3D2>4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interlayer =
relationships.&nbsp; In L2 MPLS, it is possible to change =
encapsulations (label type) throughout an LSP without much regard for =
the bandwidth supported by the link at each hop.&nbsp; This is a result =
of the relative ease of adaptations between packet formats.&nbsp; That =
is, at each LSP hop the frame can be decapsulated and the data =
encapsulated in another L2 format.&nbsp; In contrast, transport layers =
have much more restrictive adaptations than in packet layer and are =
structured in an adaptation hierarchy.&nbsp; This lack of flexibility =
compared to packet layers requires explicit indication of layer =
relationships.</FONT></P>

<P><FONT SIZE=3D2>5.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Inheritable =
attributes.&nbsp; When a whole multiplexing hierarchy is supported by a =
TE link, a lower layer attribute may be applicable to the upper layers.&=
nbsp; Protection attributes are a good example of this.&nbsp; If an =
OC-192 link is 1+1 protected (a duplicate OC-192 exists for =
protection), then an OC-3c within that OC-192 (a higher layer) would =
inherit the same protection property.&nbsp; Recognizing this type of =
attribute is thus important in TE links.</FONT></P>

<P><FONT SIZE=3D2>6.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Extensibility of =
layers.&nbsp; In addition to the existing defined transport layers, new =
layers and adaptation relationships could come into existence in the =
future.&nbsp; Keeping this in mind for TE-link attributes is =
important.</FONT></P>

<P><FONT SIZE=3D2>7.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Heterogeneous =
networks whose OXCs do not all support the same set of layers.&nbsp; In =
a GMPLS network, not all transport layer network elements are expected =
to support the same layers.&nbsp; For example, there may be switches =
capable of only VC-11, VC-12, and VC-3, where as there may be others =
that can only support VC-3 and VC-4.&nbsp; Even though a network =
element cannot support a specific layer, it should be able to know if a =
network element elsewhere in the network can support an adaptation that =
would enable that unsupported layer to be used.&nbsp; For example, a =
VC-11 switch could use a VC-3 capable switch if it knew that a VC-11 =
path could be constructed over a VC-3 link connection.</FONT></P>

<P><FONT SIZE=3D2>8.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Organization of =
links.&nbsp; Within a given layer, resources between two OXCs may be =
organized as several links.&nbsp; Attributes may be associated with a =
set of these links (bundles).</FONT></P>

<P><FONT SIZE=3D2>From the factors presented above, development of =
layer specific GMPLS routing drafts should use the following principles =
for TE-link attributes.</FONT></P>

<P><FONT SIZE=3D2>1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The attributes in a =
given layer are separated from attributes in another layer.</FONT>
</P>

<P><FONT SIZE=3D2>2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Support of =
inter-layer attributes (e.g., adaptation relationships).&nbsp; Between =
a client and server layer, a general mechanism for describing the layer =
relationship exists.&nbsp; For example "4 client links of type X can be =
supported by this server layer link".&nbsp; Another example is being =
able to identify when two layers share a common server =
layer.</FONT></P>

<P><FONT SIZE=3D2>3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Support inheritable =
attributes.&nbsp; Attributes which can be inherited should be =
identified.</FONT>
</P>

<P><FONT SIZE=3D2>4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Attributes should be =
represented in routing such that future layers can be =
accommodated.&nbsp; This is much like the notion of the generalized =
label.</FONT></P>

<P><FONT SIZE=3D2>5.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Attribute scope =
should be explicit.&nbsp; For example, whether the attribute applies to =
a set of links at the same layer.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kireeti Kompella [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, March 03, 2003 17:40</FONT>
<BR><FONT SIZE=3D2>To: Shew, Stephen [SKY:Q850:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: Jonathan Sadler; [email-masked]; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Last Call: Routing Extensions in =
Support of Generalized MPLS vto Proposed Standard</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Stephen,</FONT>
</P>

<P><FONT SIZE=3D2>On Mon, 3 Mar 2003, Stephen Shew wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I don't know if the pun was intended, but I do =
like Kireeti's comment </FONT>
<BR><FONT SIZE=3D2>&gt; about &quot;bring them to light&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>You're laser sharp, Stephen! :-)</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Undoubtedly, this would be within the ITU-T =
(wavelength) grid! ;-)</FONT>
</P>

<P><FONT SIZE=3D2>After the discussions we've had, I wouldn't dare not =
comply.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; There is, I think, some commonality in the =
comments and the reply in </FONT>
<BR><FONT SIZE=3D2>&gt; that the intent is to generalize the extensions =
needed for routing to </FONT>
<BR><FONT SIZE=3D2>&gt; accomodate non-PSC resources.&nbsp; I agree =
with the first 4 points that </FONT>
<BR><FONT SIZE=3D2>&gt; Jonathan made in that I think layer information =
must be included in </FONT>
<BR><FONT SIZE=3D2>&gt; routing so that important functions can be =
performed.</FONT>
</P>

<P><FONT SIZE=3D2>Okay.&nbsp; Can you provide text?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I believe that the use of one or two =
bandwidth</FONT>
<BR><FONT SIZE=3D2>&gt; values was motivated by the desire to use a =
&quot;lowest common </FONT>
<BR><FONT SIZE=3D2>&gt; denominator&quot; attribute to generalize on =
path computation and avoid </FONT>
<BR><FONT SIZE=3D2>&gt; extensive details of links.&nbsp; =
Unfortunately, this can obscure variable </FONT>
<BR><FONT SIZE=3D2>&gt; adaptation on a link and the ability to =
determine a path at a </FONT>
<BR><FONT SIZE=3D2>&gt; particular adaptation (e.g., VC-3).</FONT>
</P>

<P><FONT SIZE=3D2>You're right on both counts (about LCD, and about =
obscuring info). The thinking was (a) let's see how far we can get with =
just the LCD;</FONT></P>

<P><FONT SIZE=3D2>(b) as we learn more, we can incorporate them, =
ideally in the SDH routing doc.</FONT>
</P>

<P><FONT SIZE=3D2>Thoughts?</FONT>
</P>

<P><FONT SIZE=3D2>Kireeti.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2E9AE.EA089ED0--

Delivery-date: Thu, 13 Mar 2003 14:12:59 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: AD review of: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
Date: Thu, 13 Mar 2003 23:12:11 +0100

Here are my comments. Pls address them and do a quick
revision. I do not intend to issue IETF Last Call before
IETF meeting in SF is over.

- 2nd para in sect 1 
  s/is being developed/has been developed/ ??
- You have 16-bit fields for which you specify values as:
    0x01
    0x02
    ...
  And it is then not clear (to me) which bit you actually mean
  Maybe better to do:
   0x0001
   0x0002
   ...
- I see a few times "Note that no change is required to the
  TestsStatusSuccess and TestStatusFailure messages".
  That however seems very obvious, because they will ALWAYS go 
  over the control channel. I think there is never a change to 
  those messages is there... but with making this statement, one
  gets the impression that sometimes they will be changed.
- sect 4.1.1.1. I see:
       The type of the trace message.  The following values are
       defined.  All other values are reserved and should be sent as
       zero and ignored on receipt.

       1 = SONET Section Trace (J0 Byte)
       2 = SONET Path Trace (J1 Byte)
       3 = SONET Path Trace (J2 Byte)
       4 = SDH Section Trace (J0 Byte)
       5 = SDH Path Trace (J1 Byte)
       6 = SDH Path Trace (J2 Byte)

  The text about "All other valies are reserved and should be sent
  as zero..." is OK for field that have bitmasks or such, but here 
  you seem to be using the field as an integer field, no?
- last sentence before sect 4.1.3.1... pls check:
     Section .            4.1.3.1
  Actually also check the sentence before that
- page 11/12/13 I see strange formatting that causes lines to
  go beyond col 72, and I am not sure that proper sections
  are referenced when I see 
      Section 4.          ..1.3.1  
- Security considerations are unacceptable. 
  - No new security considerations compared to what?
  - Which security considerations DO apply?
- IANA considerations
  - pls be specific as to in which name space(s) you want 
    IANA to assign code points. And within such a name space,
    specify from which block (e.g. Consensus based? user sapce?
- copyright section has a year of 2001 !!??

Thanks,
Bert 

Delivery-date: Thu, 13 Mar 2003 14:12:52 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: AD review of: draft-ietf-ccamp-lmp-wdm-01.txt
Date: Thu, 13 Mar 2003 23:12:11 +0100

I am basically OK with this document except for:

- I see no IPR statement which is required for stds track
  documents
- I see no IANA considreations section, while the document
  does need IANA to make assignments.
- You may want to add the copyright verbage at the end
  of the document.
- I suspect that security ADs may find the sec.considerations
  section weak. You may at least want to state that you recommend
  to use the same security considerations as in the [LMP] document

Maybe the authors can do a quick rev, since I do not intend
to ask for IETF Last Call before the meeting in SF is over.

Thanks,
Bert 

Delivery-date: Thu, 13 Mar 2003 14:00:07 -0800
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: GMPLS question
Date: Thu, 13 Mar 2003 13:59:06 -0800

> Hi,
> 
> Is there any draft/RFC that specifies how to encode GMPLS messages in SONET/SDH overhead?
> 
> Thanks,
> Shahram
> 
> 

Delivery-date: Thu, 13 Mar 2003 13:16:53 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: AD review of draft-ietf-ccamp-lmp-07.txt
Date: Thu, 13 Mar 2003 22:15:50 +0100

Since I do not intend to request IETF Last Call before the
IETF meeting in SF is over, maybe the authors can do a quick
rev to try and address the following points.

Here are my review comments

- More or less serious:
- scenario at end of sect 3.2.2
  WOuld it not be wise to include the "waiting for interval
  to expire" before a resend is done? Otherwise, if people
  forget, I can see congestion being created.
- IANA considerations
  - I wonder if you want "IETF Consensus" based assignments.
    There was quite some debate as to what that means recently.
    Maybe you mean or want "standards action" instead?
  - I also wonder... values 0-127 are allocated by expert review,
    while the values in this doc (and a few other lmp related
    docs on my plate) are in that space and are on stds track,
    so they would be "standards action" based.
  - So pls make sure that you have documented what you want/intend
- sect 12.1 as example (this occurs several times). It says:
   Msg Type: 8 bits.  The following values are defined.  All other
             values are reserved and should be sent as zero and ignored
             on receipt.
  But the values seem to be integer values and not bits. So I do not
  understand the "All other values are reserved and should be sent as zero.."
  especially the "should be sent as zero" seems strange in this case.

Nits:
- sect 1. Expand acronyms when used for first time
  examples are DWDM, TDm, WDM. There may be others
- When I read (2nd para pge 9)
    LMP adjacency.  The value of the Message_Id is monotonically
    increasing and only decreases when the value wraps.
  Then I think I would change 
    and only decreases when the value wraps.
  into
    and wraps when teh max value is reached
- 2nd para sect 3.1
  I guess that Node-Id of two nodes can never be equal.
  But if such happens (by error) who is then the winning node,
  or what should the behaviour be?
- sect 3.2.1 2nd and 3rd para
  Is for example a 1 millisecond interval valid?
  WOuld it possibly cause congestion (rfc2914) ??
- sect 3.2.2 (3rd para) explains when difference can be more
  than 1. I think that in the case of UDP packet loss, the
  diff can slo be more then 1, no? 
- at a few places I see msoft (non-ASCII) characters
  p48, p57, maybe other places too.
- I see at various places 16-bit flags (or other) fields and then
  values are shown as:
    0x01
    0x02
  This may not be 100% clear as to which bits are then used.
  Do you mean
    0x0001
    0x0002 
  An example is page 53
- Last sentence of sect 18 ?? DId that sonet test stuff not go to
  a separate document ??

Thanks,
Bert 

Delivery-date: Thu, 13 Mar 2003 09:48:33 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-pr oc-00.txt 
Date: Thu, 13 Mar 2003 17:47:36 -0000

William Ferrell wrote 13 March 2003 16:22
> "Since MPLS implements the same routing protocols such as 
> OSPF and BGP in
> LSRs in performing routing functions, it would have  the same
> vulnerabilities, such as routing tables being poisoned and IP 
> header fields
> being changed, as in the IP networks using regular routers in 
> routing IP
> traffic"
> 
> Same old arguement here : 
> MPLS uses LDP is that to say that it is "like " OSPF ? NO. 
> MPLS uses the
> Routing protocol to get routing information. But ultimately , 
> yes I agree
> that by useing ISIS , OSPF and BGP the routing tables are 
> suspect to attack
> and same old vulnerbilities are now transposed onto the MPLS net, but
> conversely so is the signalling and hellos in LDP.  
> 
Will,  Not really sure where you are going here but one thing you need to
think about is making sure the network itself has some form of self-checking
so that security problems don't arise as a results of network failures.  We
regard this as very important (especially for arbitrary X/MPLS client/server
relationships, eg ATMoverMPLS) so let me try and explain:

In a cnls network each/every pkt contains full SA/DA.  So you can pick a pkt
up from anywhere and drop it somewhere else and (subject to TTL exhaust) it
will find its way to the right destination.  Not true however in MPLS (any
type).

The links between MPLS nodes use link-connection identifiers, which are only
required to be unique for the link between a pair of adjacent nodes.  These
link-connection identifiers only possess networking currency when they are
allocated to a parent LSP entity at it's creation time.  Similarly, the
link-connection identifiers lose their networking currency when their parent
LSP entity is destroyed.

A specific link-connection identifier can be used: (i) on different links in
the same LSP, or (ii) on any links in other LSPs.  This means one cannot
take a packet out of a given LSP at any point and drop it into the network
at some other point and expect it to find it's way to the correct
destination.  There are 2 possible outcomes from doing this:

1	The packet will black-hole at the next receiving node if the
link-connection identifier has no currency at that node, ie it is not
allocated to some parent LSP;  or,

2	The packet will be forwarded at the next receiving node if the
link-connection identifier has currency at that node (and thereafter
forwarded on all subsequent links to the connection sink point), ie it is
allocated to some parent LSP.  Note also that this case can be *recursive*
if there are nested client/server LSP relationships....so the black-holing
or further forwarding behaviour can continue upwards in the affected client
LSPs.

Any failures that result in MPLS packets being misdirected raise traffic
integrity/security concerns.  So not only must such defects be automatically
detectable, but they must also automatically elicit the right type of
consequent actions, eg in this case squelch the traffic, as well as
informing the higher client (eg ATM) of the failure.....note that the client
network may be an external customer of the MPLS layer network
service-provider and so in a completely different management domain.

So this is why in SDH, for example, you find a trail-trace function in the
user-plane, ie a periodic identifier sent by the source to the sink so that
the sink can verify it has correct connectivity.  The same should also apply
to MPLS (or at least those versions of MPLS that are p2p.....mp2p LSPs raise
a whole raft of other issues).  The requirements for this are given in
Y.1710 and the solutions are given in Y.1711, ie we require that a
Connectivity Verification OAM packet be periodically sent in the user-plane
from the source to the sink that identifies where the pkt came from. In
doing so we can detect all failure modes, eg simple breaks, swapped LSPs,
and mismerged LSPs, and take the right consequent actions quickly.

This does not address all the security concerns of course, and its not
intended to protect against malicious attacks....it merely helps protect the
network from creating security breaches due to its own failures.

regards, Neil

Delivery-date: Thu, 13 Mar 2003 09:38:20 -0800
From: "Ferrell, William" <[email-masked]>
To: "'Jones, Mark L [GMG] '" <[email-masked]>, "''Curtis Villamizar' '" <[email-masked]>, "'Gert Grammel '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-pr oc-00.txt 
Date: Thu, 13 Mar 2003 11:22:13 -0500

"Since MPLS implements the same routing protocols such as OSPF and BGP in
LSRs in performing routing functions, it would have  the same
vulnerabilities, such as routing tables being poisoned and IP header fields
being changed, as in the IP networks using regular routers in routing IP
traffic"

Same old arguement here : 
MPLS uses LDP is that to say that it is "like " OSPF ? NO. MPLS uses the
Routing protocol to get routing information. But ultimately , yes I agree
that by useing ISIS , OSPF and BGP the routing tables are suspect to attack
and same old vulnerbilities are now transposed onto the MPLS net, but
conversely so is the signalling and hellos in LDP.  

Will 

Delivery-date: Thu, 13 Mar 2003 07:45:48 -0800
Date: Thu, 13 Mar 2003 16:45:03 +0100
Subject: =?iso-8859-1?Q?Observations_OSPF_RSVP..._?=
From: "=?iso-8859-1?Q?[email-masked]?=" <[email-masked]>
To: "=?iso-8859-1?Q?ccamp?=" <[email-masked]>

Hi all,=0D=0A=0D=0Ai see at least two advantages in using Opaque LSA inst=
ed of PathErr (quite the same for the Notifies ) in this scenario: precal=
culated and presignalled backup disjoint paths for protected LSPs in MPLS=
 Network, availability of fast detection mechanism ( from lower levels ) =
of link failure.=0D=0A=0D=0A1) Since Opaque LSAs don' t trigger an SPF ca=
lculation in the routers they cross, all the Network is soon informed abo=
ut the link failure event and IN PARALLEL each router can do the label sw=
itching on the backup LSPs ( after having controlled the presence of prot=
ected LSPs starting from it and interested by the link failure ). =0D=0A=0D=
=0A2) Since i refer to protected LPSs ( they are relatively few ), thinki=
ng in a scenario in which there should be a return to the first active LS=
P when the link failed returns to be UP ( that is a second switch from ba=
ckup LSP to the  first active LSP ), could it be not necessary to send th=
e PathTears immediately to cleanup resources? This will bring two benefic=
ts: no PathTears and ResvTear sent immediately in  the Network and no sig=
nalling messages storm when the link returns up ( after a not long period=
 ), when it's probable that all the backup LSPs will return on that link =
(the link that went down). =0D=0A=0D=0AThanks in advance for your kind an=
swers and observations.=0D=0A=0D=0AGiovanni di Giacomo=0D=0A

Delivery-date: Thu, 13 Mar 2003 07:36:15 -0800
From: "Ferrell, William" <[email-masked]>
To: "'Gert Grammel '" <[email-masked]>, "Ferrell, William" <[email-masked]>
Cc: "[email-masked] ' '" <[email-masked]>, "[email-masked] ' '" <[email-masked]>, "[email-masked] ' '" <[email-masked]>, "[email-masked] ' '" <[email-masked]>, "[email-masked] ' '" <[email-masked]>, "[email-masked] ' '" <[email-masked]>
Subject: RE: security issues on MPLS
Date: Thu, 13 Mar 2003 10:23:37 -0500

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Gert
The problem is ... seems as though there are no experts on securing MPLS.
Its always overlooked from an operations perspective.

Our scope of Securing MPLS is broad without going into SMPLS.
to me the most effective way of attacking the issue  is :
Id. MPLS overarching secuity issues from 
Access, inplementation,Operations to hardware/platforms.
keeping the LAbels, LDP , and LSP /LER attacks, through VPNs to the ISIS and
BGP routing Protocols in focus.
Each segment has its own security issues then to use them (BGP,ISIS,VPN)in
conjuction with MPLS may/maynot have a different impact. 
Again the scope is huge and there isnt a lot of research on the issue. 
Our goal is to write security requirments for each segment and the whole.

Will

-----Original Message-----
From: Gert Grammel
To: Ferrell, William
Cc: [email-masked] '; [email-masked] ';
[email-masked] '; [email-masked] '; [email-masked] ';
[email-masked] '
Sent: 3/12/03 6:50 AM
Subject: security issues on MPLS

William,

I am not an expert in security issues but (G)MPLS security in particular
rsvp is
based on RFC 2747. In and e2e case IPSEC can be used as well see (see
RFC's 2402
and RFC 2406).

Regards

Gert

"Ferrell, William" wrote:

>  Gert / All
>
>  I am Will Ferrell of Titan working at DISA on an MPLS security
> project. I have worked with Barry Raveendran Greene (Cisco) on a major
DISA
> ACL project of which he provided invaluable guidance/support/ tech
reference
> that led to the projects success.
>
> Ive checked RFC's 2547,3036,2702 et. al.  It appears that there isnt a
lot
> of interest in securing MPLS. Can you refer me to other work for MPLS
> security requirements and all phases of MPLS security to include
secure
> implementation.
>
> > > >
> > > >William Ferrell
> > > >Information Assurance Eng. CCNP
> > > >Titan Corp.
> > > >703-882-2474
>
> -----Original Message-----
> From: Gert Grammel
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Sent: 3/10/03 7:24 AM
> Subject: Re: {Possible Spam} Re: I-D
> ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Curtis,
>
> you've wrote:
>
>      It would be best if ITU members go off and waste their own time
>      pursuing ASON capabilities, just as the ATM Forum went off and
> wasted
>      their time on Q.2931 capability in UNI 3.x, 4.x, ...
>
> and I don't agree with that. In my view it would be best if ITU-T
> members were
> able to understand and accept the ideas behind GMPLS and would provide
> valuable
> input to bring this work forward.
>
> Regards
>
> Gert
>
> Curtis Villamizar wrote:
>
> > Coments inline.
> >
> > In message <[email-masked]>, Gert Grammel writes:
> > >
> > > Mark,
> > >
> > > 'improving the coordination between the IETF and ITU-T' is one of
> the
> > > things I' d like to see since years. However in my experience the
> true
> > > barrier between both groups is not so much the technology as such,
> but
> > > some ignorance about the core aspects in both organizations. To
give
> a
> > > balanced figure here:
> > >
> > >   1. You remember the thread about the non-standard SDH/SONET
> > >      extensions. Here some guys active in GMPLS tried to push
their
> > >      ideas about transparency.  Obviously this was perceived on
> ITU-T
> > >      side as a challenge on the purity of a standard (G.707). This
> one
> > >      was (almost) setteled by moving all non-standard features to
an
> > >      informal draft.
> > >
> > >   2. Now it is the other way round. Somehow ITU-T extensions got
> > >      accepted (agai n informational) in IETF which do not comply
to
> > >      the purity of RSVP-TE. Due t o the fact that this
informational
> > >      RFC was not reviewed in CCAMP before, it is perceived as an
> > >      assault.
> > >
> > > So the match is tied up 1:1 but maybe it's now the right time to
> find
> > > a solutio n on how to proceed. What I've seen so far was a
complete
> > > misperception of what i s required on either side and why.
> > >
> > >   1. ITU-T basically started by defining user services having in
> mind
> > >      layered transport platforms like OTH and SDH/SONET. Those
> > >      services can be summarized as 'Bandwidth on Demand' services
> > >      (BOND). Naturally this led to a very strong focus on UNI
> > >      interfaces and a kind of ignorance of networkin g protocols.
> You
> > >      probably remember the discussions on why not using SS7? (For
> > >      those not familar with the issue: SS7 is the signaling
protocol
> > >      between PSTN switches)
> >
> > SDH/SONET bandwidth on demand has never been deployed.  There is
> > serious question about whether this is a viable service.  The
> > technology has existed for about a decade (a little less maybe) for
> > provide ATM SVC service doing essentially the same thing.  Market
> > penetration after a decade is very close to zero for SVC.  Market
> > penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> > market seems to be shrinking as well.  FR SVC market is zero.
> > SDH/SONET does not have the bandwidth on demand capability but there
> > is ample evidence that implementing it would be a waste of time.
> >
> > ASON is a requirements document from ITU that assumes the SDH/SONET
> > BOND is a viable service.  This is an enormous leap of faith given
the
> > trends in the market.  The IETF doesn't buy into it.
> >
> > And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
> > mess, so if you want to extend TCAP to support ASON, go right ahead.
> > We in the IETF would get a real good laugh over that.
> >
> > >   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE,
> ...)
> > >      and extending their scope to L1 technologies namely SDH/SONET
> and
> > >      OTH.  Naturally this led to a very strong focus on protocol
> > >      consistency and a kind of ignorance on service aspects other
> than
> > >      those already available in MPLS. You may remember here the
> > >      discussion about whether UNI is useful at all some time ago.
> >
> > Initially IP and voice ran over TDM.  The bandwidth demands of IP
were
> > much less than voice a decade ago.  As IP penetration grew roughly
> > exponentially through the early, mid, and most of the late 1990s,
this
> > reversed and IP consumed far more bandwidth than voice.  Switched
> > services also grew but at a slower rate and in the late 1990s
> > experienced negative growth for many SPs.  One factor may have been
> > notable outages in FR (US nationwide one day at one major provider
and
> > intermittent for 10 days in another a few years later) shot a big
hole
> > in the "much more reliable than IP" story.
> >
> > Initially MPLS served as traffic enginnering strictly for IP.  With
IP
> > still growing substantially, voice growing very slowly (and losing
> > revenue) and switched services growing slowly to shrinking, there
was
> > motivation to carry voice, switched services, and leased line
services
> > over the IP and/or MPLS infrastructure and decommission older
> > SDH/SONET ADM and FR or ATM switches.  This led to the tunneling
work.
> >
> > Another factor which led to GMPLS was the (unrealized) promise/hype
of
> > optical switching in the very late 1990s.  IP over an ATM overlay
was
> > a poor design and IP providers did not want to repeat that mistake
so
> > the control of the underlying optical domain was accommodated by
what
> > has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
> > addition to FSC, LSC and PSC.
> >
> > > So putting everything together means that it is required to keep
> > > (IETF) protocol consistency but adding some (ITU-T) specific
> > > extensions to well defined service points in the network (UNI).
> > > Unfortunately service points tend to exchange messages between
> > > themselves and this would mean that an intermediate protocol would
> > > have had to support such kind of communication. What concerns the
> IETF
> > > community is probably not the fact that there is a UNI somewhere,
> but
> > > the changes and extensions to etablished protocols in order to
> achieve
> > > a collaboration between them.
> >
> > ASON was never accepted by the IETF as requirements and for very
good
> > reason.  To say that IETF must accept the ASON requirements simply
> > because they came in a liason statement and that the IETF must
> > accommodate this ITU folly is absurd.
> >
> > > I recall that this was the basic issue with the ITU-T proposal
when
> it
> > > was presented for the first time in Yokohama. The way I've got
> > > Kireeti's message there was: please authors try to let us
understand
> > > what problem you want to solve and tell us which kind of
information
> > > you have to exchange between which points to achieve it. We'll
sort
> > > out then in CCAMP what would be the most appropriate way to
> implement
> > > it, while maintaining consistency in our protocols .
> >
> > Regardless of how this was handled in Yokohama, some of the
> > fundamental premise of ASON is flawed.  It would be best if ITU
> > members go off and waste their own time pursuing ASON capabilities,
> > just as the ATM Forum went off and wasted their time on Q.2931
> > capability in UNI 3.x, 4.x, but ITU should do so without extending
> > protocols which originated in the IETF.
> >
> > > Although it didn't work the first time I still consider Kireeti's
> > > suggestion to be a wise way to move forward and perhaps the key
for
> > > harmonic collaboration.
> > >
> > > Regards
> > >
> > > Gert
> >
> > I look forward to seeing the IETF come up with a formal statement of
> > liason policy.  It would be useful to have explicitly documented
that
> > liason statements carry no more weight than any individual
> > internet-draft submission.
> >
> > Curtis
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Thu, 13 Mar 2003 06:02:33 -0800
Date: Thu, 13 Mar 2003 08:58:57 -0500
From: Ron Bonica <[email-masked]>
Subject: IETF 56 CCAMP Draft Agenda
To: [email-masked]

Common Control and Management Plan (CCAMP)
March 19, 9:00-11:30
 
9:00-9:05 Agenda Bashing
 
9:05-9:10 WG Status
	Kompella
  
9:10-9:20 ITU Liaison Report
	Alanqar
  
9:20-9:30 Protection and Restoration
	- draft-lang-ccamp-gmpls-recovery-e2e-signaling-00
	Papadimitriou

9:30-9:40 Optical Network Failure Recovery Requirements
	- draft-czezowski-optical-recovery-reqs-01.txt
	Czezowski

10:40-10:50 Fault Notification Protocol for GMPLS-Based Recovery
	- draft-rabbat-fault-notification-protocol-02.txt
	Czezowski
 
9:50-10:00 Link Management Protocol 
	- draft-lang-ccamp-lmp-bootstrap-03
	Lang
  
10:00-10:05 Overlay Draft
	- draft-ietf-ccamp-gmpls-overlay-01
	Swallow
  
10:05-10:10 Routing Extensions
	- draft-mannie-ccamp-gmpls-sonet-sdh-ospf-01.txt
	- draft-mannie-ccamp-gmpls-sonet-sdh-isis-00.txt
	Papadimitriou
 
10:10-10:15 Management
	- draft-ietf-ccamp-gmpls-te-mib-00
	- draft-ietf-ccamp-gmpls-lsr-mib-00
	Farell
  
10:15-10:20 Route Exclusion
	- draft-lee-ccamp-rsvp-te-exclude-route-01
	Farell
  
10:20-10:25 Transport Network View to LMP
	- draft-aboulmagd-ccamp-transport-lmp-00.txt
	Aboulmagd

10:25-10:30 Generic Tunnel Tracing
	draft-bonica-tunproto-04
	Bonica
 
10:30-10:45 GMPLS Change Process
	- draft-andersson-mpls-g-chng-proc-00
	Anderson
  
10:45-11:00 WG Charter
	Kompella

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021  
Ashburn, Va.
===========================================
"We are not on Earth to guard a museum, but
to cultivate a flourishing garden of life."
                -- Angelo Giuseppe Roncalli

Delivery-date: Wed, 12 Mar 2003 12:03:40 -0800
Date: Wed, 12 Mar 2003 21:02:25 +0100
Subject: =?iso-8859-1?Q?Re:Re:_Between_OSPF_RSVP...?=
From: "=?iso-8859-1?Q?[email-masked]?=" <[email-masked]>
To: "=?iso-8859-1?Q?ccamp?=" <[email-masked]>

Hi Peter hi all,=0D=0Aessentially my considerations are: if i have two pr=
e-calculated disjoint backup paths and i use opaque LSA to flood the link=
 failure information,=0D=0Ait could be a reasonable faster  way of procee=
ding instead of using RSVP if i have an intelligence in the source router=
s (routers have to be able to switch among the two LSPs if they receive t=
hat particular opaque LSA; note that for a restoration of many LSPs RSVP =
will work in series, but OSPF will work in parallel with its flooding mec=
hanism).=0D=0ASo the basic question is: is it a reasonable way the use of=
 OSPF  and opaque LSA? Is there a reason to the use of RSVP for path prot=
ection, since, i think, increasing the LSPs corrupted by one link failure=
 (if there are many active LSPs on the link that goes down) the OSPF mech=
anism of flooding is more efficient than using many RSVP messages from no=
de that detects the failure towards the LSPs senders?=0D=0A=0D=0AThanks i=
n advance for your kind answers and observations.=0D=0A=0D=0AGiovanni Di =
Giacomo=0D=0A=0D=0A=0D=0A=0D=0AGiovanni,=0D=0A=0D=0AWe also propose an ap=
proach to P/R based on "per failure" flooding. The =0D=0Aproposal was mad=
e after considering a list of requirements that included =0D=0Athe scalab=
ility and flexibility of the recovery scheme. Rather than trying =0D=0Ato=
 optimize OSPF-TE, we chose to extend LMP to provide the limited flooding=
 =0D=0Aof the failure notifications. It is documented in 3 Internet Draft=
s:=0D=0A=0D=0AOptical Network Failure Recovery Requirements=0D=0Ahttp://w=
ww.ietf.org/internet-drafts/draft-czezowski-optical-recovery-reqs-01.txt=0D=
=0AFault Notification Protocol for GMPLS-Based Recovery=0D=0Ahttp://www.i=
etf.org/internet-drafts/draft-rabbat-fault-notification-protocol-02.txt=0D=
=0AExtensions to LMP for Flooding-based Fault Notification=0D=0Ahttp://ww=
w.ietf.org/internet-drafts/draft-soumiya-lmp-fault-notification-ext-00.tx=
t=0D=0A=0D=0AAny feedback would be appreciated.=0D=0A=0D=0ARegards,=0D=0A=
Peter Czezowski=0D=0A=0D=0A=0D=0AAt 11:38 AM 3/12/03 +0100, john151@liber=
o.it wrote:=0D=0A>Hi all,=0D=0A>I' m interesting in protection/restoratio=
n (P/R) mechanisms and after =0D=0A>having read some works, i' d like to =
do some observations.=0D=0A>In a TE path protection scenario, there are w=
orks dealing with the use of =0D=0A>RSVP-TE messages to signal, in  examp=
le,=0D=0A>a link failure.=0D=0A>But could it have sense this other way of=
 recovery?=0D=0A>...After a detection of a failure, OSPF ( OSPF-TE ) uses=
 the flooding =0D=0A>mechanism to advertise the all network that one link=
 is broken=0D=0A>( ... using opaque LSA? ); then all nodes, receiving the=
 LSA with this =0D=0A>information, could compute an analysis of what LSPs=
 ( LSP having source in =0D=0A>that node ) are interested by the failure.=
 Then, in example, each node =0D=0A>that wants to do restoration in a MPL=
S scenario could make a Label =0D=0A>Switching if there is a Backup Path =
available.=0D=0A>This approach has some problem:=0D=0A>-   a faster trigg=
er on OSPF in detecting failure, since HELLO mechanism =0D=0A>is slow;=0D=
=0A>-   the prioriting of the sequence ---flooding LSA---  and  then =0D=0A=
>---computing SPF algorithm--- to do faster;=0D=0A>-   the adding of inte=
lligence in each node to do the Switching.=0D=0A>=0D=0A>I know that these=
 are only some observations containing ( i hope few ) =0D=0A>errors and t=
hat aren't complete, but since i haven' t found any P/R =0D=0A>mechanisms=
 in a TE scenario using OSPF ( or any optimized version of this =0D=0A>),=
 i' d like to make you a question:=0D=0A>is this a possible way of study =
( as an alternative to RSVP signalling ) =0D=0A>or is completely wrong an=
d out of all standards?=0D=0A>=0D=0A>Thanks in advance for your kind answ=
ers and observations.=0D=0A>=0D=0A>Giovanni Di Giacomo=0D=0A=0D=0A=0D=0A

Delivery-date: Wed, 12 Mar 2003 11:06:45 -0800
Date: Wed, 12 Mar 2003 11:06:29 -0800
To: "[email-masked]" <[email-masked]>, "ccamp" <[email-masked]>
From: Peter Czezowski <[email-masked]>
Subject: Re: Between OSPF RSVP...

Giovanni,

We also propose an approach to P/R based on "per failure" flooding. The 
proposal was made after considering a list of requirements that included 
the scalability and flexibility of the recovery scheme. Rather than trying 
to optimize OSPF-TE, we chose to extend LMP to provide the limited flooding 
of the failure notifications. It is documented in 3 Internet Drafts:

Optical Network Failure Recovery Requirements
http://www.ietf.org/internet-drafts/draft-czezowski-optical-recovery-reqs-01.txt
Fault Notification Protocol for GMPLS-Based Recovery
http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol-02.txt
Extensions to LMP for Flooding-based Fault Notification
http://www.ietf.org/internet-drafts/draft-soumiya-lmp-fault-notification-ext-00.txt

Any feedback would be appreciated.

Regards,
Peter Czezowski

At 11:38 AM 3/12/03 +0100, [email-masked] wrote:
>Hi all,
>I' m interesting in protection/restoration (P/R) mechanisms and after 
>having read some works, i' d like to do some observations.
>In a TE path protection scenario, there are works dealing with the use of 
>RSVP-TE messages to signal, in  example,
>a link failure.
>But could it have sense this other way of recovery?
>...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding 
>mechanism to advertise the all network that one link is broken
>( ... using opaque LSA? ); then all nodes, receiving the LSA with this 
>information, could compute an analysis of what LSPs ( LSP having source in 
>that node ) are interested by the failure. Then, in example, each node 
>that wants to do restoration in a MPLS scenario could make a Label 
>Switching if there is a Backup Path available.
>This approach has some problem:
>-   a faster trigger on OSPF in detecting failure, since HELLO mechanism 
>is slow;
>-   the prioriting of the sequence ---flooding LSA---  and  then 
>---computing SPF algorithm--- to do faster;
>-   the adding of intelligence in each node to do the Switching.
>
>I know that these are only some observations containing ( i hope few ) 
>errors and that aren't complete, but since i haven' t found any P/R 
>mechanisms in a TE scenario using OSPF ( or any optimized version of this 
>), i' d like to make you a question:
>is this a possible way of study ( as an alternative to RSVP signalling ) 
>or is completely wrong and out of all standards?
>
>Thanks in advance for your kind answers and observations.
>
>Giovanni Di Giacomo

Delivery-date: Wed, 12 Mar 2003 08:23:29 -0800
Date: Wed, 12 Mar 2003 17:20:45 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Why Call/Connection Separatation

Bert,

of course you are right, that the subject line should reflect the discussion. It
was however not my intention to start yet another discussion on call/connection
separation but to use it as an example on how to solve issues which seem to be
clear on one side and unclear on the other one. I repeat that in our target
should be to find a solution which is shared between IETF and ITU-T. The way
forward is in my opinions to *help* everybody to understand the issues and to be
open to consider a variety of solutions. This way however requires that the
involved folks *want* to work together and really share a common target - not
sure if we are already there.

Regards

Gert

"Wijnen, Bert (Bert)" wrote:

> It is always interesting to see how a discussion on a
> document that describes initial ideas on change control
> diverts into a discussion on other topics, in this case
> the toipic of "Why Call/Connection Separation".
>
> But people never change the subject line.
> Oh well... if you want to continue this discussion, then PLEASE
> use a proper subject line from now on.
>
> Also if you decide to switch topics again, that you also change
> the subject line.
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Gert Grammel [mailto:[email-masked]]
> > Sent: woensdag 12 maart 2003 11:08
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> >
> > Neil,
> >
> > I think you haven't got my point about call/connection
> > separation. Please have
> > also a look to my respone to Eve. There can be a discussion about
> > call/connection separation once there is a kind of shared
> > view on 'why it is
> > needed'. In
> > http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-req
> > uirements-05.txt
> > the only 'motivating sentence I could find was:
> >
> >      To support many enhanced optical services, such as
> > scheduled bandwidth
> >      on demand, diverse circuit provisioning and bundled
> > connections, a
> >      call model based on the separation of call control and connection
> >      control is essential.
> >
> > You gave some practical examples on where you see the need
> > for that. Why not
> > putting it into a document and share it with everybody?
> >
> > I also want to thank you to share with us your choice to go for a L0/1
> > functionality. This is a very clear statement.
> >
> >
> > Regards
> >
> > Gert
> >
> > [email-masked] wrote:
> >
> > > Hi Gert, I think some clarifications are in order here to
> > make the BT
> > > position (ie not just the NH position) clear.  Please see
> > below.  regards,
> > > Neil
> > >
> > > Gert Grammel wrote 11 March 2003 15:47 to Monica Lazer:
> > >
> > > <snipped>
> > > > Look at the hottest issue under discussion: We are talking a
> > > > lot about UNI
> > > > features like call/connection separation. Neither Mark nor
> > > > Neil see the UNI
> > > > becoming service relevant at any time soon - so why is it
> > > > under discussion right
> > > > now? Is this your priority 1 issue in ITU-T? Is Mark or Neil
> > > > in a minority
> > > > position in ITU-T? Referring to the Yokohama Meeting this was
> > > > basically
> > > > Kireeti's request: Please explain what you need and for
> > what purpose.
> > >
> > > NH=> A UNI at L1/0 is *not* something we see as important
> > anytime soon.  We
> > > also see no need for coupling with L2/3 (either commercially or
> > > technically).  Thus we want to be able to choose
> > best-of-breed functionality
> > > for L1/0.  We *do* want call/connection separation however,
> > and note this is
> > > independent of the UNI...here is an extract from a
> > colleague of mine on the
> > > ITU lists which sort-of explains why:
> > > "Anyone care to disagree with the notion of a call handle
> > for SPCs in the
> > > ITU-T as a means of bundling under one service instance a
> > customer record
> > > that handles
> > > multiple connections e.g. Virtual Concatenation, with or
> > without LCAS as a
> > > valid application?
> > > Anyone care to disagree that we might want to retrieve
> > information on an SPC
> > > using a single identifier (the call) that shows all
> > connections associated
> > > with that call and the performance of each connection
> > and/or start end of
> > > individual connections?
> > > Anyone care to diagree that the call/connection model
> > cannot be used for
> > > restoration of SPCs?
> > > As for those that want to do UNI on you go...but its not on
> > BT priority
> > > list."
> > > >
> > > <snipped to end>
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:[email-masked]
> >
> >
> >

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Wed, 12 Mar 2003 05:40:43 -0800
Date: Wed, 12 Mar 2003 14:37:42 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Why Call/Connection Separation

all, in order to re-initiate the discussion w/i the 
ccamp wg an "ason functional req's" i-d has been (re-) 
initiated that should (hopefully) explain the reasons/
rationales (the "why") and the expectations (the "what") 
for call-connection control separation and other 
requirements such as crank back for instance

we plan to submit it right after the meeting (subm.
deadline being over for this meeting) in order to move 
a step forward with this discussion

hint: i'd be of great interest if the user community
(in particular ops folks) could give us their view-
point here as well

thanks,
- dimitri.

"Wijnen, Bert (Bert)" wrote:
> 
> It is always interesting to see how a discussion on a
> document that describes initial ideas on change control
> diverts into a discussion on other topics, in this case
> the toipic of "Why Call/Connection Separation".
> 
> But people never change the subject line.
> Oh well... if you want to continue this discussion, then PLEASE
> use a proper subject line from now on.
> 
> Also if you decide to switch topics again, that you also change
> the subject line.
> 
> Thanks,
> Bert
> 
> > -----Original Message-----
> > From: Gert Grammel [mailto:[email-masked]]
> > Sent: woensdag 12 maart 2003 11:08
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> >
> > Neil,
> >
> > I think you haven't got my point about call/connection
> > separation. Please have
> > also a look to my respone to Eve. There can be a discussion about
> > call/connection separation once there is a kind of shared
> > view on 'why it is
> > needed'. In
> > http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-req
> > uirements-05.txt
> > the only 'motivating sentence I could find was:
> >
> >      To support many enhanced optical services, such as
> > scheduled bandwidth
> >      on demand, diverse circuit provisioning and bundled
> > connections, a
> >      call model based on the separation of call control and connection
> >      control is essential.
> >
> > You gave some practical examples on where you see the need
> > for that. Why not
> > putting it into a document and share it with everybody?
> >
> > I also want to thank you to share with us your choice to go for a L0/1
> > functionality. This is a very clear statement.
> >
> >
> > Regards
> >
> > Gert
> >
> > [email-masked] wrote:
> >
> > > Hi Gert, I think some clarifications are in order here to
> > make the BT
> > > position (ie not just the NH position) clear.  Please see
> > below.  regards,
> > > Neil
> > >
> > > Gert Grammel wrote 11 March 2003 15:47 to Monica Lazer:
> > >
> > > <snipped>
> > > > Look at the hottest issue under discussion: We are talking a
> > > > lot about UNI
> > > > features like call/connection separation. Neither Mark nor
> > > > Neil see the UNI
> > > > becoming service relevant at any time soon - so why is it
> > > > under discussion right
> > > > now? Is this your priority 1 issue in ITU-T? Is Mark or Neil
> > > > in a minority
> > > > position in ITU-T? Referring to the Yokohama Meeting this was
> > > > basically
> > > > Kireeti's request: Please explain what you need and for
> > what purpose.
> > >
> > > NH=> A UNI at L1/0 is *not* something we see as important
> > anytime soon.  We
> > > also see no need for coupling with L2/3 (either commercially or
> > > technically).  Thus we want to be able to choose
> > best-of-breed functionality
> > > for L1/0.  We *do* want call/connection separation however,
> > and note this is
> > > independent of the UNI...here is an extract from a
> > colleague of mine on the
> > > ITU lists which sort-of explains why:
> > > "Anyone care to disagree with the notion of a call handle
> > for SPCs in the
> > > ITU-T as a means of bundling under one service instance a
> > customer record
> > > that handles
> > > multiple connections e.g. Virtual Concatenation, with or
> > without LCAS as a
> > > valid application?
> > > Anyone care to disagree that we might want to retrieve
> > information on an SPC
> > > using a single identifier (the call) that shows all
> > connections associated
> > > with that call and the performance of each connection
> > and/or start end of
> > > individual connections?
> > > Anyone care to diagree that the call/connection model
> > cannot be used for
> > > restoration of SPCs?
> > > As for those that want to do UNI on you go...but its not on
> > BT priority
> > > list."
> > > >
> > > <snipped to end>
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:[email-masked]
> >
> >
> >

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Wed, 12 Mar 2003 03:52:18 -0800
Date: Wed, 12 Mar 2003 12:50:03 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: "Ferrell, William" <[email-masked]>
CC: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: security issues on MPLS

William,

I am not an expert in security issues but (G)MPLS security in particular rsvp is
based on RFC 2747. In and e2e case IPSEC can be used as well see (see RFC's 2402
and RFC 2406).

Regards

Gert

"Ferrell, William" wrote:

>  Gert / All
>
>  I am Will Ferrell of Titan working at DISA on an MPLS security
> project. I have worked with Barry Raveendran Greene (Cisco) on a major DISA
> ACL project of which he provided invaluable guidance/support/ tech reference
> that led to the projects success.
>
> Ive checked RFC's 2547,3036,2702 et. al.  It appears that there isnt a lot
> of interest in securing MPLS. Can you refer me to other work for MPLS
> security requirements and all phases of MPLS security to include secure
> implementation.
>
> > > >
> > > >William Ferrell
> > > >Information Assurance Eng. CCNP
> > > >Titan Corp.
> > > >703-882-2474
>
> -----Original Message-----
> From: Gert Grammel
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Sent: 3/10/03 7:24 AM
> Subject: Re: {Possible Spam} Re: I-D
> ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Curtis,
>
> you've wrote:
>
>      It would be best if ITU members go off and waste their own time
>      pursuing ASON capabilities, just as the ATM Forum went off and
> wasted
>      their time on Q.2931 capability in UNI 3.x, 4.x, ...
>
> and I don't agree with that. In my view it would be best if ITU-T
> members were
> able to understand and accept the ideas behind GMPLS and would provide
> valuable
> input to bring this work forward.
>
> Regards
>
> Gert
>
> Curtis Villamizar wrote:
>
> > Coments inline.
> >
> > In message <[email-masked]>, Gert Grammel writes:
> > >
> > > Mark,
> > >
> > > 'improving the coordination between the IETF and ITU-T' is one of
> the
> > > things I' d like to see since years. However in my experience the
> true
> > > barrier between both groups is not so much the technology as such,
> but
> > > some ignorance about the core aspects in both organizations. To give
> a
> > > balanced figure here:
> > >
> > >   1. You remember the thread about the non-standard SDH/SONET
> > >      extensions. Here some guys active in GMPLS tried to push their
> > >      ideas about transparency.  Obviously this was perceived on
> ITU-T
> > >      side as a challenge on the purity of a standard (G.707). This
> one
> > >      was (almost) setteled by moving all non-standard features to an
> > >      informal draft.
> > >
> > >   2. Now it is the other way round. Somehow ITU-T extensions got
> > >      accepted (agai n informational) in IETF which do not comply to
> > >      the purity of RSVP-TE. Due t o the fact that this informational
> > >      RFC was not reviewed in CCAMP before, it is perceived as an
> > >      assault.
> > >
> > > So the match is tied up 1:1 but maybe it's now the right time to
> find
> > > a solutio n on how to proceed. What I've seen so far was a complete
> > > misperception of what i s required on either side and why.
> > >
> > >   1. ITU-T basically started by defining user services having in
> mind
> > >      layered transport platforms like OTH and SDH/SONET. Those
> > >      services can be summarized as 'Bandwidth on Demand' services
> > >      (BOND). Naturally this led to a very strong focus on UNI
> > >      interfaces and a kind of ignorance of networkin g protocols.
> You
> > >      probably remember the discussions on why not using SS7? (For
> > >      those not familar with the issue: SS7 is the signaling protocol
> > >      between PSTN switches)
> >
> > SDH/SONET bandwidth on demand has never been deployed.  There is
> > serious question about whether this is a viable service.  The
> > technology has existed for about a decade (a little less maybe) for
> > provide ATM SVC service doing essentially the same thing.  Market
> > penetration after a decade is very close to zero for SVC.  Market
> > penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> > market seems to be shrinking as well.  FR SVC market is zero.
> > SDH/SONET does not have the bandwidth on demand capability but there
> > is ample evidence that implementing it would be a waste of time.
> >
> > ASON is a requirements document from ITU that assumes the SDH/SONET
> > BOND is a viable service.  This is an enormous leap of faith given the
> > trends in the market.  The IETF doesn't buy into it.
> >
> > And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
> > mess, so if you want to extend TCAP to support ASON, go right ahead.
> > We in the IETF would get a real good laugh over that.
> >
> > >   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE,
> ...)
> > >      and extending their scope to L1 technologies namely SDH/SONET
> and
> > >      OTH.  Naturally this led to a very strong focus on protocol
> > >      consistency and a kind of ignorance on service aspects other
> than
> > >      those already available in MPLS. You may remember here the
> > >      discussion about whether UNI is useful at all some time ago.
> >
> > Initially IP and voice ran over TDM.  The bandwidth demands of IP were
> > much less than voice a decade ago.  As IP penetration grew roughly
> > exponentially through the early, mid, and most of the late 1990s, this
> > reversed and IP consumed far more bandwidth than voice.  Switched
> > services also grew but at a slower rate and in the late 1990s
> > experienced negative growth for many SPs.  One factor may have been
> > notable outages in FR (US nationwide one day at one major provider and
> > intermittent for 10 days in another a few years later) shot a big hole
> > in the "much more reliable than IP" story.
> >
> > Initially MPLS served as traffic enginnering strictly for IP.  With IP
> > still growing substantially, voice growing very slowly (and losing
> > revenue) and switched services growing slowly to shrinking, there was
> > motivation to carry voice, switched services, and leased line services
> > over the IP and/or MPLS infrastructure and decommission older
> > SDH/SONET ADM and FR or ATM switches.  This led to the tunneling work.
> >
> > Another factor which led to GMPLS was the (unrealized) promise/hype of
> > optical switching in the very late 1990s.  IP over an ATM overlay was
> > a poor design and IP providers did not want to repeat that mistake so
> > the control of the underlying optical domain was accommodated by what
> > has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
> > addition to FSC, LSC and PSC.
> >
> > > So putting everything together means that it is required to keep
> > > (IETF) protocol consistency but adding some (ITU-T) specific
> > > extensions to well defined service points in the network (UNI).
> > > Unfortunately service points tend to exchange messages between
> > > themselves and this would mean that an intermediate protocol would
> > > have had to support such kind of communication. What concerns the
> IETF
> > > community is probably not the fact that there is a UNI somewhere,
> but
> > > the changes and extensions to etablished protocols in order to
> achieve
> > > a collaboration between them.
> >
> > ASON was never accepted by the IETF as requirements and for very good
> > reason.  To say that IETF must accept the ASON requirements simply
> > because they came in a liason statement and that the IETF must
> > accommodate this ITU folly is absurd.
> >
> > > I recall that this was the basic issue with the ITU-T proposal when
> it
> > > was presented for the first time in Yokohama. The way I've got
> > > Kireeti's message there was: please authors try to let us understand
> > > what problem you want to solve and tell us which kind of information
> > > you have to exchange between which points to achieve it. We'll sort
> > > out then in CCAMP what would be the most appropriate way to
> implement
> > > it, while maintaining consistency in our protocols .
> >
> > Regardless of how this was handled in Yokohama, some of the
> > fundamental premise of ASON is flawed.  It would be best if ITU
> > members go off and waste their own time pursuing ASON capabilities,
> > just as the ATM Forum went off and wasted their time on Q.2931
> > capability in UNI 3.x, 4.x, but ITU should do so without extending
> > protocols which originated in the IETF.
> >
> > > Although it didn't work the first time I still consider Kireeti's
> > > suggestion to be a wise way to move forward and perhaps the key for
> > > harmonic collaboration.
> > >
> > > Regards
> > >
> > > Gert
> >
> > I look forward to seeing the IETF come up with a formal statement of
> > liason policy.  It would be useful to have explicitly documented that
> > liason statements carry no more weight than any individual
> > internet-draft submission.
> >
> > Curtis
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Wed, 12 Mar 2003 02:53:27 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Gert Grammel <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Why Call/Connection Separatation
Date: Wed, 12 Mar 2003 11:52:31 +0100

It is always interesting to see how a discussion on a
document that describes initial ideas on change control 
diverts into a discussion on other topics, in this case
the toipic of "Why Call/Connection Separation".

But people never change the subject line.
Oh well... if you want to continue this discussion, then PLEASE
use a proper subject line from now on.

Also if you decide to switch topics again, that you also change
the subject line.

Thanks,
Bert 

> -----Original Message-----
> From: Gert Grammel [mailto:[email-masked]]
> Sent: woensdag 12 maart 2003 11:08
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Neil,
> 
> I think you haven't got my point about call/connection 
> separation. Please have
> also a look to my respone to Eve. There can be a discussion about
> call/connection separation once there is a kind of shared 
> view on 'why it is
> needed'. In
> http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-req
> uirements-05.txt
> the only 'motivating sentence I could find was:
> 
>      To support many enhanced optical services, such as 
> scheduled bandwidth
>      on demand, diverse circuit provisioning and bundled 
> connections, a
>      call model based on the separation of call control and connection
>      control is essential.
> 
> You gave some practical examples on where you see the need 
> for that. Why not
> putting it into a document and share it with everybody?
> 
> I also want to thank you to share with us your choice to go for a L0/1
> functionality. This is a very clear statement.
> 
> 
> Regards
> 
> Gert
> 
> [email-masked] wrote:
> 
> > Hi Gert, I think some clarifications are in order here to 
> make the BT
> > position (ie not just the NH position) clear.  Please see 
> below.  regards,
> > Neil
> >
> > Gert Grammel wrote 11 March 2003 15:47 to Monica Lazer:
> >
> > <snipped>
> > > Look at the hottest issue under discussion: We are talking a
> > > lot about UNI
> > > features like call/connection separation. Neither Mark nor
> > > Neil see the UNI
> > > becoming service relevant at any time soon - so why is it
> > > under discussion right
> > > now? Is this your priority 1 issue in ITU-T? Is Mark or Neil
> > > in a minority
> > > position in ITU-T? Referring to the Yokohama Meeting this was
> > > basically
> > > Kireeti's request: Please explain what you need and for 
> what purpose.
> >
> > NH=> A UNI at L1/0 is *not* something we see as important 
> anytime soon.  We
> > also see no need for coupling with L2/3 (either commercially or
> > technically).  Thus we want to be able to choose 
> best-of-breed functionality
> > for L1/0.  We *do* want call/connection separation however, 
> and note this is
> > independent of the UNI...here is an extract from a 
> colleague of mine on the
> > ITU lists which sort-of explains why:
> > "Anyone care to disagree with the notion of a call handle 
> for SPCs in the
> > ITU-T as a means of bundling under one service instance a 
> customer record
> > that handles
> > multiple connections e.g. Virtual Concatenation, with or 
> without LCAS as a
> > valid application?
> > Anyone care to disagree that we might want to retrieve 
> information on an SPC
> > using a single identifier (the call) that shows all 
> connections associated
> > with that call and the performance of each connection 
> and/or start end of
> > individual connections?
> > Anyone care to diagree that the call/connection model 
> cannot be used for
> > restoration of SPCs?
> > As for those that want to do UNI on you go...but its not on 
> BT priority
> > list."
> > >
> > <snipped to end>
> 
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]
> 
> 
> 

Delivery-date: Wed, 12 Mar 2003 02:38:49 -0800
Date: Wed, 12 Mar 2003 11:38:21 +0100
Subject: =?iso-8859-1?Q?Between_OSPF_RSVP...?=
From: "=?iso-8859-1?Q?[email-masked]?=" <[email-masked]>
To: "=?iso-8859-1?Q?ccamp?=" <[email-masked]>

Hi all,=0D=0AI' m interesting in protection/restoration (P/R) mechanisms =
and after having read some works, i' d like to do some observations.=0D=0A=
In a TE path protection scenario, there are works dealing with the use of=
 RSVP-TE messages to signal, in  example, =0D=0Aa link failure.=0D=0ABut =
could it have sense this other way of recovery?=0D=0A...After a detection=
 of a failure, OSPF ( OSPF-TE ) uses the flooding mechanism to advertise =
the all network that one link is broken=0D=0A( ... using opaque LSA? ); t=
hen all nodes, receiving the LSA with this information, could compute an =
analysis of what LSPs ( LSP having source in that node ) are interested b=
y the failure. Then, in example, each node that wants to do restoration i=
n a MPLS scenario could make a Label Switching if there is a Backup Path =
available. =0D=0AThis approach has some problem:=0D=0A-   a faster trigge=
r on OSPF in detecting failure, since HELLO mechanism is slow;=0D=0A-   t=
he prioriting of the sequence ---flooding LSA---  and  then ---computing =
SPF algorithm--- to do faster;=0D=0A-   the adding of intelligence in eac=
h node to do the Switching.=0D=0A=0D=0AI know that these are only some ob=
servations containing ( i hope few ) errors and that aren't complete, but=
 since i haven' t found any P/R mechanisms in a TE scenario using OSPF ( =
or any optimized version of this ), i' d like to make you a question:=0D=0A=
is this a possible way of study ( as an alternative to RSVP signalling ) =
or is completely wrong and out of all standards?=0D=0A=0D=0AThanks in adv=
ance for your kind answers and observations.=0D=0A=0D=0AGiovanni Di Giaco=
mo

Delivery-date: Wed, 12 Mar 2003 02:28:42 -0800
Date: Wed, 12 Mar 2003 11:27:53 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: "Jones, Mark L [GMG]" <[email-masked]>
CC: "'Curtis Villamizar'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: {Possible Spam} Re: I-D  ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Mark,

I feel sorry about your first sentence:

     I would guess that many of us who participate mostly at the ITU-T
     would support this position if it had not already proven to fail.

As been said in my first email, the match is 1:1 and I personally believe that
it would now be a good time for a second try. Anyhow it is good to hear that
there are some of us  thinking about how to come to a consented solution. Maybe
we don't share views on the concrete subject (In my view an SPC is an SPC
whether it is on L0/1 or L2/3, so what is *specific* there?). Anyhow I think
that this email discussion was helpful to understand where we are today and my
hope is that we were able to stimulate phantasy on both sides on how to proceed.

Best regards

Gert

"Jones, Mark L [GMG]" wrote:

> Curtis and Gert,
>
> I would guess that many of us who participate mostly at the ITU-T would
> support this position if it had not already proven to fail.  Many of those
> at the ITU-T do understand the reasons for the IETF consensus, but they do
> not believe it justifies adoption of the IETF solution for the ITU-T set of
> requirements.  So, what do we do?
>
> My guess is that the differences in scopes and points of view will always
> lead to differences in opinion on what and how things should be done.  Where
> a single application is being addressed, I had hoped that we could agree
> between the two organizations, who should be the lead.  For most IP and IP
> based protocols and applications, I think most see the IETF as the lead.
> However, where L0/L1 applications are concerned, that is not the case.
>
> The interest in refining procedures is simply a way of addressing the issue,
> or maintaining a reasonable working relationship between the two groups.  I
> hope your conversations at the upcoming IETF meeting help us resolve this
> issue.
>
> Regards,
>
> Mark Loyd Jones
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 10:41 AM
> To: Gert Grammel
> Cc: [email-masked]; Jones, Mark L [GMG]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: {Possible Spam} Re: I-D
> ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> [ post by non-subscriber.  with the massive amount of spam, it is easy to
> miss
>   and therefore delete posts by non-subscribers.  if you wish to regularly
>   post from an address that is not subscribed to this mailing list, send a
>   message to <listname>[email-masked] and ask to have the alternate
>   address added to the list of addresses from which submissions are
>   automatically accepted. ]
>
> In message <[email-masked]>, Gert Grammel writes:
> > Curtis,
> >
> > you've wrote:
> >
> >      It would be best if ITU members go off and waste their own time
> >      pursuing ASON capabilities, just as the ATM Forum went off and wasted
> >      their time on Q.2931 capability in UNI 3.x, 4.x, ...
> >
> > and I don't agree with that. In my view it would be best if ITU-T members
> > were able to understand and accept the ideas behind GMPLS and would
> > provide valuable input to bring this work forward.
> >
> > Regards
> >
> > Gert
>
> I absolutely agree with your statement above.
>
> If there is consensus in the IETF that ASON should not be considered
> as a set of requirements it would also be best if ITU-T members tried
> to understand why this consensus was reached rather than try to
> initiate procedural changes to allow it to be jammed through
> regardless of whether is makes technical sense.
>
> Perhaps I should have qualified my statement that if ITU-T members
> continue to behave as they are now doing, then "It would be best if
> ITU members go off and waste their own time ...".
>
> Curtis

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Wed, 12 Mar 2003 02:08:33 -0800
Date: Wed, 12 Mar 2003 11:07:55 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Neil,

I think you haven't got my point about call/connection separation. Please have
also a look to my respone to Eve. There can be a discussion about
call/connection separation once there is a kind of shared view on 'why it is
needed'. In
http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-requirements-05.txt
the only 'motivating sentence I could find was:

     To support many enhanced optical services, such as scheduled bandwidth
     on demand, diverse circuit provisioning and bundled connections, a
     call model based on the separation of call control and connection
     control is essential.

You gave some practical examples on where you see the need for that. Why not
putting it into a document and share it with everybody?

I also want to thank you to share with us your choice to go for a L0/1
functionality. This is a very clear statement.

Regards

Gert

[email-masked] wrote:

> Hi Gert, I think some clarifications are in order here to make the BT
> position (ie not just the NH position) clear.  Please see below.  regards,
> Neil
>
> Gert Grammel wrote 11 March 2003 15:47 to Monica Lazer:
>
> <snipped>
> > Look at the hottest issue under discussion: We are talking a
> > lot about UNI
> > features like call/connection separation. Neither Mark nor
> > Neil see the UNI
> > becoming service relevant at any time soon - so why is it
> > under discussion right
> > now? Is this your priority 1 issue in ITU-T? Is Mark or Neil
> > in a minority
> > position in ITU-T? Referring to the Yokohama Meeting this was
> > basically
> > Kireeti's request: Please explain what you need and for what purpose.
>
> NH=> A UNI at L1/0 is *not* something we see as important anytime soon.  We
> also see no need for coupling with L2/3 (either commercially or
> technically).  Thus we want to be able to choose best-of-breed functionality
> for L1/0.  We *do* want call/connection separation however, and note this is
> independent of the UNI...here is an extract from a colleague of mine on the
> ITU lists which sort-of explains why:
> "Anyone care to disagree with the notion of a call handle for SPCs in the
> ITU-T as a means of bundling under one service instance a customer record
> that handles
> multiple connections e.g. Virtual Concatenation, with or without LCAS as a
> valid application?
> Anyone care to disagree that we might want to retrieve information on an SPC
> using a single identifier (the call) that shows all connections associated
> with that call and the performance of each connection and/or start end of
> individual connections?
> Anyone care to diagree that the call/connection model cannot be used for
> restoration of SPCs?
> As for those that want to do UNI on you go...but its not on BT priority
> list."
> >
> <snipped to end>

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Wed, 12 Mar 2003 01:50:34 -0800
Date: Wed, 12 Mar 2003 10:48:59 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: "Varma, Eve L (Eve)" <[email-masked]>
CC: "Lazer, Monica A, ALABS" <[email-masked]>, [email-masked], [email-masked], [email-masked], "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Eve,

thank's for this comment. In the IPO document you refered to, I could only find the following
sentence as a motivator:

     To support many enhanced optical services, such as scheduled bandwidth on demand,
     diverse circuit provisioning and bundled connections, a call model based on the
     separation of call control and connection control is essential.

Probably we are in agreement when I say that from this sentence it is difficult to understand
*why* the separation is needed for these kind of services and potential others as you've
mentioned . So it could be beneficial to elaborate a bit on the question 'why is call
connection separation needed to support these kind of services'  to achieve a common
understanding and eventually agree on an implementation.

Regards

Gert

"Varma, Eve L (Eve)" wrote:

> Hi Gert,
>
> Just to clarify, the separation of calls and connections is useful for SPCs, not just UNI.
> So it would not be appropriate to draw a conclusion re disconnects on the assumption that
> call/connection separation is all about UNI.
>
> By the way, call/connection separation was also mentioned within the ipo wg document
>
> http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-requirements-05.txt
>
> Best regards,
> Eve
>
> -----Original Message-----
> From: Gert Grammel [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2003 10:47 AM
> To: Lazer, Monica A, ALABS
> Cc: [email-masked]; [email-masked];
> [email-masked]; Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Monica,
>
> there is nothing wrong with improving a solution. The key is to know where to
> start and where to go.
> You may agree that CCAMP had another starting point than ITU-T/ASON.  However my
> feeling is, that even this issue is not really understood by many of the folks
> out there. If there is no acceptance that priorities in another SDO is different
> from the own one, we won't come to an agreement at any time soon.
> Look at the hottest issue under discussion: We are talking a lot about UNI
> features like call/connection separation. Neither Mark nor Neil see the UNI
> becoming service relevant at any time soon - so why is it under discussion right
> now? Is this your priority 1 issue in ITU-T? Is Mark or Neil in a minority
> position in ITU-T? Referring to the Yokohama Meeting this was basically
> Kireeti's request: Please explain what you need and for what purpose.
>
> What I am trying to achieve is to make the priorities transparent such that
> either side can see where is the difference and where is the overlap. Otherwise
> we will endlessly continue to discuss about feature requirements and whether
> they seem to be relevant or not.
>
> In short I repeat my previous statement using some of your own words:
>
>      In my view, the main issue <snip> is about what is bringing more value
>      to a carrier's network:
>
>         * a single Control Plane Paradigm not optimized for a specific
>           Layer or
>         * a variety of control plane paradigms optimized for specific Layer
>           needs
>
> Regards
>
> Gert
>
> "Lazer, Monica A, ALABS" wrote:
>
> > Gert,
> > I have some comments, inline, below. The short of it is that I don't
> > agree with your perspective.
> > In my view, the main issue is not about taking sides in these debates,
> > but about what is bringing more value to a carrier's network.
> >
> > Monica A. Lazer
> > Network Architecture and Reliability
> >
> > 908 234 8462
> > [email-masked]
> >
> > -----Original Message-----
> > From: Gert Grammel [mailto:[email-masked]]
> > Sent: Monday, March 10, 2003 7:19 AM
> > To: Lazer, Monica A, ALABS
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; Ash, Gerald R (Jerry), ALABS; [email-masked]
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Monica,
> >
> > I think there were lots of discussions about what is best for layer XYZ
> > and also
> > Neil was arguing in this direction. This argumentation is of course
> > valid if you
> > focus on layer XYZ and look for a (new) control plane. Let's name it a
> > classical
> > ASON point ov view. What I tried to raise as an issue is, that from a
> > CCAMP
> > point of view the question is the other way round. You have already a
> > control
> > plane defined and the question is: how to apply it in the best way to
> > layer XYZ?
> > There is an issue about what is the main backwards compatibility issue
> > here, I guess. From the ccamp perspective, it seems to be compatibility
> > with the defined GMPLS work. From the network perspective, however, it
> > means compatibility with how the transport network works. It may indeed
> > be an issue of priorities.
> > So coming back to your argument. You've said correctly:
> >
> >      ... while when going from HO to LO one is within the same paradigm.
> >
> > One conclusion could be: you should use the same Control Plane paradigm
> > for
> > different layers in order to let them interoperate seamlessly. First it
> > needs to support each layer!
> >  Further more, scalability becomes a very real issue
> > To sum up a bit: in my view all the discussion about features of ASON
> > and/or
> > GMPLS is flawed right from the beginning if it is not clear what should
> > be
> > achieved:
> >
> >   1. If you focus on a single paradigm arcoss layers you should consider
> > GMPLS
> >      with all its features and limitations
> > Why must one take things with limitations, what is wrong with
> > improvements?
> > The control plane focus is on saving operations cost for the given
> > layer!
> >
> >   2. If you are interesting on getting some specialized control planes
> > for
> >      SDH/SONET you are free to choose anything.
> >
> > in ITU-T you have the choice, in IETF you have not. Do you really mean
> > this?? That seems to be a flawed attitude. Saying that in ietf there is
> > no choice, or room for improvements (your point above about accepting
> > all its limitations) seems to be a serious judgment call on this forum.
> > Are you saying that one should not even bother with problem statements
> > or requirements?
> >  For sure the choice is not
> > between transport and packet technology, the choice is your focus.
> >
> > Regards
> >
> > Gert
> >
> > "Lazer, Monica A, ALABS" wrote:
> >
> > > Gert,
> > > I think that one of the main drivers of the different needs when going
> > > from L1 to L2 is the fact L1, in SONET is TDM-based, while L2 can be
> > > packet based and have a different paradigm, while when going from HO
> > to
> > > LO one is within the same paradigm. So, point 1 indicates that one
> > > should consider using the same control plane architecture for the
> > > sublayers within L1, but it does not necessarily support the idea that
> > > the same paradigm is best for both L1 and higher layers.  Regarding
> > the
> > > backbone/regional structure, more than only 2 levels may be needed for
> > > global transport networks.
> > >
> > > Regards,
> > >
> > > Monica A. Lazer
> > > Network Architecture and Reliability
> > >
> > > 908 234 8462
> > > [email-masked]
> > >
> > > -----Original Message-----
> > > From: Gert Grammel [mailto:[email-masked]]
> > > Sent: Thursday, March 06, 2003 3:38 PM
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked]; Ash, Gerald R
> > > (Jerry), ALABS; [email-masked]
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > Mark,
> > >
> > > I am happy to read that we could find some common understanding. About
> > > your
> > > multi-layer issue you've raised, I suggest to figure out more to which
> > > extend
> > > this is an issue for UNI. Some thoughts on that:
> > >
> > >   1. Wideband Crossconnects are able to crossconnect low order
> > circuits
> > > (LO),
> > >      and put them into high order circuits (HO). Those Crossconnects
> > are
> > > managed
> > >      by one manager able to control both Layers: LO and HO. I've never
> > > heard
> > >      that an operator let one part of the organization implement HO
> > only
> > > on a
> > >      country wide basis, while another part of the organization is
> > > taking care
> > >      about LO only.
> > >   2. So rather than the pure layering, a kind of regional/backbone
> > > structure is
> > >      in place. Regional NOCs deal with HO and LO whithin the region
> > > while in
> > >      backbone you use HO only because you don't need the finer
> > > granularity
> > >      there. So what appears to be a layering from a management point
> > of
> > > view
> > >      seems to me more a regional kind of separation.
> > >
> > > To be clear: I don't want to discuss the fact that there is a layering
> > > in the
> > > network. My point is to highlight that SDH/SONET is in reality not a
> > > single
> > > layer but has at least 4 of them (RS, MS, LO, HO). In theory we should
> > > find in
> > > the network an RS-manager, an MS-Manager, a LO-Manager and a
> > HO-Manager.
> > > Moreover a single Wideband Crossconnect would have had to be managed
> > by
> > > all 4
> > > managers at the same time. Obviously this is not really practical
> > > (immagine: 4
> > > managers, one worker ;-) such that most vendors and carriers decided
> > to
> > > put all
> > > 4 layers into one management box - quite similar to what a GMPLS
> > Control
> > > Plane
> > > does with SONET/SDH control.
> > >
> > > Just to avoid misunderstandings here: I don't want to start a new
> > thread
> > > on
> > > layering issues. I just want to provide you some food for your own
> > > thoughts
> > > hoping that we can find some common understanding at some point in
> > > future.
> > >
> > > Regards
> > >
> > > Gert
> > >
> > > [email-masked] wrote:
> > >
> > > > Gert,
> > > >
> > > > Thanks for outlining the history and your current position for going
> > > > forward.  Mostly, I agree with you.
> > > >
> > > > My major point of disagreement is with your characterization of the
> > > > ITU-T direction.  Though the ITU-T ASON documents might enable
> > > > "'Bandwidth on Demand' services (BOND)" to some degree, that was not
> > > the
> > > > primary focus.  The Optical UNI was a development that came out of
> > the
> > > > OIF and not the ITU-T.  Most carriers have seen the Optical UNI as a
> > > > potential customer interface with far more realistic applications
> > > > internal to networks, i.e. between the L3/L2 elements and the L1/L0
> > > > elements.  Those who have attended the OIF in the past probably
> > > remember
> > > > my unpopular statement on the plenary floor that we were wasting out
> > > > time working on a UNI that had questionable (no?) business
> > advantages
> > > > for the carrier.
> > > >
> > > > I do support the approach you mention (from Kireeti?) that we focus
> > on
> > > > the service points and the information that needs to be exchanged
> > > > between them.  Where most of the services are of the L3/L2 variety,
> > > that
> > > > approach should be successful.  Those items should be fully covered
> > by
> > > > the IETF solutions.
> > > >
> > > > However, that doesn't address the multi-layer issue that we are
> > > > struggling to address, which is one of the root causes of this
> > > conflict
> > > > between the IETF and ITU-T.  The signaling/control for L1/L0 is
> > where
> > > > the ITU-T participants have found the IETF solutions to be
> > inadequate.
> > > > That's not necessarily because the IETF solutions wouldn't work, but
> > > > because they would not satisfy the stringent requirements and models
> > > by
> > > > which we base our management and control for L1/L0.
> > > >
> > > > This whole problem could be blamed on the IP success in the
> > industry.
> > > > If IP had not proven to be so successful, the ITU-T might have
> > chosen
> > > > the optical control plane based on extensions to SS7.  :-)  (Not
> > > meaning
> > > > to ignore the ITU-T alternative solution based on PNNI.)
> > > >
> > > > Regards,
> > > >
> > > > Mark Loyd Jones
> > > > Optical Transport and Networking
> > > > Sprint - Wireline Technology Development
> > > > 913-794-2139
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Gert.Grammel [mailto:[email-masked]]
> > > > Sent: Thursday, March 06, 2003 1:21 PM
> > > > To: Mark.Jones
> > > > Cc: ccamp; dwfedyk; gash; mpls
> > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > >
> > > > Mark,
> > > >
> > > > 'improving the coordination between the IETF and ITU-T' is one of
> > the
> > > > things I'd
> > > > like to see since years. However in my experience the true barrier
> > > > between both
> > > > groups is not so much the technology as such, but some ignorance
> > about
> > > > the core
> > > > aspects in both organizations. To give a balanced figure here:
> > > >
> > > >   1. You remember the thread about the non-standard SDH/SONET
> > > > extensions. Here
> > > >      some guys active in GMPLS tried to push their ideas about
> > > > transparency.
> > > >      Obviously this was perceived on ITU-T side as a challenge on
> > the
> > > > purity of
> > > >      a standard (G.707). This one was (almost) setteled by moving
> > all
> > > >      non-standard features to an informal draft.
> > > >   2. Now it is the other way round. Somehow ITU-T extensions got
> > > > accepted (again
> > > >      informational) in IETF which do not comply to the purity of
> > > > RSVP-TE. Due to
> > > >      the fact that this informational RFC was not reviewed in CCAMP
> > > > before, it
> > > >      is perceived as an assault.
> > > >
> > > > So the match is tied up 1:1 but maybe it's now the right time to
> > find
> > > a
> > > > solution
> > > > on how to proceed. What I've seen so far was a complete
> > misperception
> > > of
> > > > what is
> > > > required on either side and why.
> > > >
> > > >   1. ITU-T basically started by defining user services having in
> > mind
> > > > layered
> > > >      transport platforms like OTH and SDH/SONET. Those services can
> > be
> > > >      summarized as 'Bandwidth on Demand' services (BOND). Naturally
> > > this
> > > > led to
> > > >      a very strong focus on UNI interfaces and a kind of ignorance
> > of
> > > > networking
> > > >      protocols. You probably remember the discussions on why not
> > using
> > > > SS7? (For
> > > >      those not familar with the issue: SS7 is the signaling protocol
> > > > between
> > > >      PSTN switches)
> > > >   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE,
> > ...)
> > > > and
> > > >      extending their scope to L1 technologies namely SDH/SONET and
> > > OTH.
> > > >      Naturally this led to a very strong focus on protocol
> > consistency
> > > > and a
> > > >      kind of ignorance on service aspects other than those already
> > > > available in
> > > >      MPLS. You may remember here the discussion about whether UNI is
> > > > useful at
> > > >      all some time ago.
> > > >
> > > > So putting everything together means that it is required to keep
> > > (IETF)
> > > > protocol
> > > > consistency but adding some (ITU-T) specific extensions to well
> > > defined
> > > > service
> > > > points in the network (UNI).
> > > > Unfortunately service points tend to exchange messages between
> > > > themselves and
> > > > this would mean that an intermediate protocol would have had to
> > > support
> > > > such
> > > > kind of communication. What concerns the IETF community is probably
> > > not
> > > > the fact
> > > > that there is a UNI somewhere, but the changes and extensions to
> > > > etablished
> > > > protocols in order to achieve a collaboration between them.
> > > >
> > > > I recall that this was the basic issue with the ITU-T proposal when
> > it
> > > > was
> > > > presented for the first time in Yokohama. The way I've got Kireeti's
> > > > message
> > > > there was: please authors try to let us understand what problem you
> > > want
> > > > to
> > > > solve and tell us which kind of information you have to exchange
> > > between
> > > > which
> > > > points to achieve it. We'll sort out then in CCAMP what would be the
> > > > most
> > > > appropriate way to implement it, while maintaining consistency in
> > our
> > > > protocols.
> > > >
> > > > Although it didn't work the first time I still consider Kireeti's
> > > > suggestion to
> > > > be a wise way to move forward and perhaps the key for harmonic
> > > > collaboration.
> > > >
> > > > Regards
> > > >
> > > > Gert
> > > >
> > > > [email-masked] wrote:
> > > >
> > > > > Gert,
> > > > >
> > > > > I agreed with the intent in generalizing MPLS for the wide range
> > of
> > > > > expected applications.  It was my hope that it would succeed.  At
> > > this
> > > > > point, one might say that the intent has only been partially
> > > achieved.
> > > > > The problem that has come to light over the past year is the fact
> > > that
> > > > > there are finer points of the ITU-T model and requirements that
> > are
> > > > not
> > > > > supported by the current IETF GMPLS RFCs and standards track
> > drafts.
> > > > > Those aspects are considered significant enough by many carriers
> > and
> > > > > their suppliers to warrant further extensions outside of the IETF.
> > > > (My
> > > > > apologies for not understanding those points well enough to
> > clarify
> > > > them
> > > > > even in examples, but there are many people on this list would
> > could
> > > > do
> > > > > so if they thought it necessary.  To avoid any misunderstand, all
> > > > should
> > > > > know that Sprint does not yet have a company position on this.)
> > It
> > > is
> > > > > my hope that we can come up with ways of improving the
> > coordination
> > > > > between the IETF and ITU-T.  This thread of discussion is bringing
> > > out
> > > > > the issues to make that happen.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Mark Loyd Jones
> > > > > Optical Transport and Networking
> > > > > Sprint - Wireline Technology Development
> > > > > 913-794-2139
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Gert.Grammel [mailto:[email-masked]]
> > > > > Sent: Thursday, March 06, 2003 10:17 AM
> > > > > To: Mark.Jones
> > > > > Cc: dwfedyk; gash; ccamp; mpls
> > > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > > >
> > > > > Mark,
> > > > >
> > > > > please don't forget that due to the 'Generalization' of GMPLS you
> > > are
> > > > > free to do
> > > > > the split at any application level you wish. This was always the
> > > > > advantage of
> > > > > the GMPLS approach compared to the ITU-T model where initially
> > each
> > > > > layer had
> > > > > its own control plane. So the fact that in theory you could use a
> > > > single
> > > > > control
> > > > > plane for all your network means also that you are able to stop
> > > where
> > > > > you want.
> > > > > Nice feature isn't it?
> > > > >
> > > > > Regards
> > > > >
> > > > > Gert
> > > > >
> > > > > [email-masked] wrote:
> > > > >
> > > > > > I agree with the separation of GMPLS into the two applications.
> > > > There
> > > > > > does not appear to be any significant move to collapse the
> > > > management
> > > > > or
> > > > > > signaling for L3/2 and L1/0 at this time, given the different
> > > models
> > > > > > that apply for them and the infrastructures in our companies
> > that
> > > > > manage
> > > > > > them.  The plan for addressing the two applications need not be
> > > the
> > > > > > same.
> > > > > >
> > > > > > The L3/2 application is near and dear to the heart of the IETF.
> > > The
> > > > > > L1/0 application is of interest to those who wish to collapse
> > the
> > > > > > management into a single layer.  In my opinion, the IETF might
> > > also
> > > > > > address this approach, given the IETF participants are the ones
> > in
> > > > > > support of this collapsed management or at least common protocol
> > > > > > solution for what is today two signaling layers.  However, as
> > > stated
> > > > > > before, the collapse approach is not realistic today for a
> > > > > > multi-service, multi-protocol network.
> > > > > >
> > > > > > On the other hand, the L1/0 application requirements and models
> > > have
> > > > > > been defined and are best understood at the ITU-T.  Ideally, the
> > > > > > protocol expertise at the IETF would be applied to the ITU-T
> > model
> > > > and
> > > > > > requirements to address the L1/0 application, but attempts to do
> > > > that
> > > > > > have been met with great resistance in the past.  Perhaps that
> > was
> > > a
> > > > > > result of the fact that GMPLS implementations were not separated
> > > out
> > > > > > into the two different applications.  However, I don't think it
> > is
> > > > > > realistic to expect the IETF experts to be motivated to
> > understand
> > > > the
> > > > > > ITU-T models and requirements, given the application is outside
> > of
> > > > > their
> > > > > > primary area of interest.  That said, I believe the IETF should
> > > > reach
> > > > > an
> > > > > > agreement on how to work with outside groups that develop "major
> > > > > > extensions" to the protocol.
> > > > > >
> > > > > > Mark Loyd Jones
> > > > > > Optical Transport and Networking
> > > > > > Sprint - Wireline Technology Development
> > > > > > 913-794-2139
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: dwfedyk [mailto:[email-masked]]
> > > > > > Sent: Thursday, March 06, 2003 7:49 AM
> > > > > > To: gash
> > > > > > Cc: mpls; ccamp
> > > > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > > > >
> > > > > > Along the lines of Jerry's comments.
> > > > > >
> > > > > > When we put together GMPLS the first drafts were under specified
> > > > > > intentionally to capture the essence of GMPLS. We put aside many
> > > > > > arguments saying lets specify at a high level and fill in the
> > > > details
> > > > > > later. The discussions on this thread are in two major veins one
> > > > > > attempting to fill the details and the other containing and
> > > > > controlling
> > > > > > the changes. GMPLS needs to be specified more accurately and in
> > my
> > > > > > opinion it needs to be decomposed to a more layered approach.  I
> > > > think
> > > > > > if we applied GMPLS at at some layers (L3/2), (L1/L0) for
> > example,
> > > > > > independently but self similar it would offer a mechanism to
> > move
> > > > > > forward where some legacy systems could be specified to be GMPLS
> > > > > > friendly. For example signaling for Layer 3/2 can be tunneled
> > > > through
> > > > > > the a lower layer. We already have some work in this direction.
> > > > > >  Similarly traffic engineering information for L1/L0 in a TE
> > > > database
> > > > > >  would need different  attributes than a the TE database at
> > L3/2.
> > > I
> > > > > > don't think you want to burden a L3/L2 system with these
> > > attributes
> > > > in
> > > > > > an overlay model. The expertise for these layer is not all
> > > contained
> > > > > in
> > > > > > the IETF. I think we should put a plan forward to make this
> > happen
> > > > > > within the IETF process. After this was accomplished  I think
> > some
> > > > > > people are thinking of collapsing layers even more but the
> > logical
> > > > > > partitioning of layers may help keep the protocols and databases
> > > > > > simpler.   Right now were are treating GMPLS like a big bowl of
> > > > jelly
> > > > > > when it should look more like a layer cake.
> > > > > >
> > > > > > Regards,
> > > > > > Don
> > > > >
> > > > > --
> > > > > Alcatel Optical Network Division    Gert Grammel
> > > > > Network Strategy                    phone: +49 711 821 47368
> > > > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > > > D-70435 Stuttgart                   mailto:[email-masked]
> > > >
> > > > --
> > > > Alcatel Optical Network Division    Gert Grammel
> > > > Network Strategy                    phone: +49 711 821 47368
> > > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > > D-70435 Stuttgart                   mailto:[email-masked]
> > >
> > > --
> > > Alcatel Optical Network Division    Gert Grammel
> > > Network Strategy                    phone: +49 711 821 47368
> > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > D-70435 Stuttgart                   mailto:[email-masked]
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:[email-masked]
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Tue, 11 Mar 2003 17:39:58 -0800
Date: Tue, 11 Mar 2003 20:36:26 -0500
From: David Griffith <[email-masked]>
Organization: NIST
To: [email-masked]
Subject: Next Steps for P&R Effort

Hello all,

Over the past few weeks, I've been discussing possible extensions to
the protection and restoration analysis draft with that document's
editors.  There are several items that I feel would be appropriate to
include in a follow-on draft, and I have listed these below.  I am
interested in getting feedback from the group regarding these items
(level of interest in seeing them examined, relative priority of the
various items, etc.)  We have already made some progress on a number
of these (e.g. the (M:N)^n analysis and simulations to support items 1
and 2).  We would like to initiate work on these soon, in order to
maintain the momentum from the first analysis draft.

The proposed work items are the following:

1. extend recovery scheme tradeoff grid from Section 8 (for correlated
and uncorrelated failures), to include overbooking (quantitative
results would be reported elsewhere and referenced in the draft)

2. develop a classification system for failure recovery schemes (for
correlated and uncorrelated failures), such as those designed for
multiple failure events

3. produce a discussion of multiple uncorrelated failures and
mechanisms to handle them, versus multiple correlated failures

4. provide more detailed discussion of vertical hierarchies, including
an examination of tradeoffs involving top-down versus bottom-up or
coordinated recovery schemes

5. examine the performance of (M:N)^n recovery schemes

6. examine SRLG/SRG recoverability issues

This list is not intended to be exhaustive, and if there are
suggestions for additional items, I would be interested in hearing
them.  

Regards,

D. Griffith

Delivery-date: Tue, 11 Mar 2003 14:24:37 -0800
From: "Jones, Mark L [GMG]" <[email-masked]>
To: "'Curtis Villamizar'" <[email-masked]>, Gert Grammel <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-pr oc-00.txt 
Date: Tue, 11 Mar 2003 16:22:20 -0600

Curtis and Gert,

I would guess that many of us who participate mostly at the ITU-T would
support this position if it had not already proven to fail.  Many of those
at the ITU-T do understand the reasons for the IETF consensus, but they do
not believe it justifies adoption of the IETF solution for the ITU-T set of
requirements.  So, what do we do?

My guess is that the differences in scopes and points of view will always
lead to differences in opinion on what and how things should be done.  Where
a single application is being addressed, I had hoped that we could agree
between the two organizations, who should be the lead.  For most IP and IP
based protocols and applications, I think most see the IETF as the lead.
However, where L0/L1 applications are concerned, that is not the case.

The interest in refining procedures is simply a way of addressing the issue,
or maintaining a reasonable working relationship between the two groups.  I
hope your conversations at the upcoming IETF meeting help us resolve this
issue.

Regards,

Mark Loyd Jones
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 10:41 AM
To: Gert Grammel
Cc: [email-masked]; Jones, Mark L [GMG]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: {Possible Spam} Re: I-D
ACTION:draft-andersson-mpls-g-chng-proc-00.txt 

[ post by non-subscriber.  with the massive amount of spam, it is easy to
miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <[email-masked]>, Gert Grammel writes:
> Curtis,
> 
> you've wrote:
> 
>      It would be best if ITU members go off and waste their own time
>      pursuing ASON capabilities, just as the ATM Forum went off and wasted
>      their time on Q.2931 capability in UNI 3.x, 4.x, ...
> 
> and I don't agree with that. In my view it would be best if ITU-T members
> were able to understand and accept the ideas behind GMPLS and would
> provide valuable input to bring this work forward.
> 
> Regards
> 
> Gert

I absolutely agree with your statement above.

If there is consensus in the IETF that ASON should not be considered
as a set of requirements it would also be best if ITU-T members tried
to understand why this consensus was reached rather than try to
initiate procedural changes to allow it to be jammed through
regardless of whether is makes technical sense.

Perhaps I should have qualified my statement that if ITU-T members
continue to behave as they are now doing, then "It would be best if
ITU members go off and waste their own time ...".

Curtis

Delivery-date: Tue, 11 Mar 2003 13:12:20 -0800
To: Gert Grammel <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Tue, 11 Mar 2003 11:40:51 -0500
From: Curtis Villamizar <[email-masked]>

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <[email-masked]>, Gert Grammel writes:
> Curtis,
> 
> you've wrote:
> 
>      It would be best if ITU members go off and waste their own time
>      pursuing ASON capabilities, just as the ATM Forum went off and wasted
>      their time on Q.2931 capability in UNI 3.x, 4.x, ...
> 
> and I don't agree with that. In my view it would be best if ITU-T members
> were able to understand and accept the ideas behind GMPLS and would
> provide valuable input to bring this work forward.
> 
> Regards
> 
> Gert

I absolutely agree with your statement above.

If there is consensus in the IETF that ASON should not be considered
as a set of requirements it would also be best if ITU-T members tried
to understand why this consensus was reached rather than try to
initiate procedural changes to allow it to be jammed through
regardless of whether is makes technical sense.

Perhaps I should have qualified my statement that if ITU-T members
continue to behave as they are now doing, then "It would be best if
ITU members go off and waste their own time ...".

Curtis

Delivery-date: Tue, 11 Mar 2003 11:15:11 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Tue, 11 Mar 2003 19:13:29 -0000

Hi Gert, I think some clarifications are in order here to make the BT
position (ie not just the NH position) clear.  Please see below.  regards,
Neil

Gert Grammel wrote 11 March 2003 15:47 to Monica Lazer:

<snipped>
> Look at the hottest issue under discussion: We are talking a 
> lot about UNI
> features like call/connection separation. Neither Mark nor 
> Neil see the UNI
> becoming service relevant at any time soon - so why is it 
> under discussion right
> now? Is this your priority 1 issue in ITU-T? Is Mark or Neil 
> in a minority
> position in ITU-T? Referring to the Yokohama Meeting this was 
> basically
> Kireeti's request: Please explain what you need and for what purpose.

NH=> A UNI at L1/0 is *not* something we see as important anytime soon.  We
also see no need for coupling with L2/3 (either commercially or
technically).  Thus we want to be able to choose best-of-breed functionality
for L1/0.  We *do* want call/connection separation however, and note this is
independent of the UNI...here is an extract from a colleague of mine on the
ITU lists which sort-of explains why:
"Anyone care to disagree with the notion of a call handle for SPCs in the
ITU-T as a means of bundling under one service instance a customer record
that handles
multiple connections e.g. Virtual Concatenation, with or without LCAS as a
valid application?
Anyone care to disagree that we might want to retrieve information on an SPC
using a single identifier (the call) that shows all connections associated
with that call and the performance of each connection and/or start end of
individual connections?
Anyone care to diagree that the call/connection model cannot be used for
restoration of SPCs?
As for those that want to do UNI on you go...but its not on BT priority
list."
> 
<snipped to end>

Delivery-date: Tue, 11 Mar 2003 10:00:11 -0800
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Gert Grammel'" <[email-masked]>, "Lazer, Monica A, ALABS" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Tue, 11 Mar 2003 12:59:35 -0500

Hi Gert,

Just to clarify, the separation of calls and connections is useful for SPCs, not just UNI.
So it would not be appropriate to draw a conclusion re disconnects on the assumption that
call/connection separation is all about UNI.

By the way, call/connection separation was also mentioned within the ipo wg document

http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-requirements-05.txt

Best regards,
Eve

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 10:47 AM
To: Lazer, Monica A, ALABS
Cc: [email-masked]; [email-masked];
[email-masked]; Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Monica,

there is nothing wrong with improving a solution. The key is to know where to
start and where to go.
You may agree that CCAMP had another starting point than ITU-T/ASON.  However my
feeling is, that even this issue is not really understood by many of the folks
out there. If there is no acceptance that priorities in another SDO is different
from the own one, we won't come to an agreement at any time soon.
Look at the hottest issue under discussion: We are talking a lot about UNI
features like call/connection separation. Neither Mark nor Neil see the UNI
becoming service relevant at any time soon - so why is it under discussion right
now? Is this your priority 1 issue in ITU-T? Is Mark or Neil in a minority
position in ITU-T? Referring to the Yokohama Meeting this was basically
Kireeti's request: Please explain what you need and for what purpose.

What I am trying to achieve is to make the priorities transparent such that
either side can see where is the difference and where is the overlap. Otherwise
we will endlessly continue to discuss about feature requirements and whether
they seem to be relevant or not.

In short I repeat my previous statement using some of your own words:

     In my view, the main issue <snip> is about what is bringing more value
     to a carrier's network:

        * a single Control Plane Paradigm not optimized for a specific
          Layer or
        * a variety of control plane paradigms optimized for specific Layer
          needs

Regards

Gert

"Lazer, Monica A, ALABS" wrote:

> Gert,
> I have some comments, inline, below. The short of it is that I don't
> agree with your perspective.
> In my view, the main issue is not about taking sides in these debates,
> but about what is bringing more value to a carrier's network.
>
> Monica A. Lazer
> Network Architecture and Reliability
>
> 908 234 8462
> [email-masked]
>
> -----Original Message-----
> From: Gert Grammel [mailto:[email-masked]]
> Sent: Monday, March 10, 2003 7:19 AM
> To: Lazer, Monica A, ALABS
> Cc: [email-masked]; [email-masked];
> [email-masked]; Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Monica,
>
> I think there were lots of discussions about what is best for layer XYZ
> and also
> Neil was arguing in this direction. This argumentation is of course
> valid if you
> focus on layer XYZ and look for a (new) control plane. Let's name it a
> classical
> ASON point ov view. What I tried to raise as an issue is, that from a
> CCAMP
> point of view the question is the other way round. You have already a
> control
> plane defined and the question is: how to apply it in the best way to
> layer XYZ?
> There is an issue about what is the main backwards compatibility issue
> here, I guess. From the ccamp perspective, it seems to be compatibility
> with the defined GMPLS work. From the network perspective, however, it
> means compatibility with how the transport network works. It may indeed
> be an issue of priorities.
> So coming back to your argument. You've said correctly:
>
>      ... while when going from HO to LO one is within the same paradigm.
>
> One conclusion could be: you should use the same Control Plane paradigm
> for
> different layers in order to let them interoperate seamlessly. First it
> needs to support each layer!
>  Further more, scalability becomes a very real issue
> To sum up a bit: in my view all the discussion about features of ASON
> and/or
> GMPLS is flawed right from the beginning if it is not clear what should
> be
> achieved:
>
>   1. If you focus on a single paradigm arcoss layers you should consider
> GMPLS
>      with all its features and limitations
> Why must one take things with limitations, what is wrong with
> improvements?
> The control plane focus is on saving operations cost for the given
> layer!
>
>   2. If you are interesting on getting some specialized control planes
> for
>      SDH/SONET you are free to choose anything.
>
> in ITU-T you have the choice, in IETF you have not. Do you really mean
> this?? That seems to be a flawed attitude. Saying that in ietf there is
> no choice, or room for improvements (your point above about accepting
> all its limitations) seems to be a serious judgment call on this forum.
> Are you saying that one should not even bother with problem statements
> or requirements?
>  For sure the choice is not
> between transport and packet technology, the choice is your focus.
>
> Regards
>
> Gert
>
> "Lazer, Monica A, ALABS" wrote:
>
> > Gert,
> > I think that one of the main drivers of the different needs when going
> > from L1 to L2 is the fact L1, in SONET is TDM-based, while L2 can be
> > packet based and have a different paradigm, while when going from HO
> to
> > LO one is within the same paradigm. So, point 1 indicates that one
> > should consider using the same control plane architecture for the
> > sublayers within L1, but it does not necessarily support the idea that
> > the same paradigm is best for both L1 and higher layers.  Regarding
> the
> > backbone/regional structure, more than only 2 levels may be needed for
> > global transport networks.
> >
> > Regards,
> >
> > Monica A. Lazer
> > Network Architecture and Reliability
> >
> > 908 234 8462
> > [email-masked]
> >
> > -----Original Message-----
> > From: Gert Grammel [mailto:[email-masked]]
> > Sent: Thursday, March 06, 2003 3:38 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; Ash, Gerald R
> > (Jerry), ALABS; [email-masked]
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Mark,
> >
> > I am happy to read that we could find some common understanding. About
> > your
> > multi-layer issue you've raised, I suggest to figure out more to which
> > extend
> > this is an issue for UNI. Some thoughts on that:
> >
> >   1. Wideband Crossconnects are able to crossconnect low order
> circuits
> > (LO),
> >      and put them into high order circuits (HO). Those Crossconnects
> are
> > managed
> >      by one manager able to control both Layers: LO and HO. I've never
> > heard
> >      that an operator let one part of the organization implement HO
> only
> > on a
> >      country wide basis, while another part of the organization is
> > taking care
> >      about LO only.
> >   2. So rather than the pure layering, a kind of regional/backbone
> > structure is
> >      in place. Regional NOCs deal with HO and LO whithin the region
> > while in
> >      backbone you use HO only because you don't need the finer
> > granularity
> >      there. So what appears to be a layering from a management point
> of
> > view
> >      seems to me more a regional kind of separation.
> >
> > To be clear: I don't want to discuss the fact that there is a layering
> > in the
> > network. My point is to highlight that SDH/SONET is in reality not a
> > single
> > layer but has at least 4 of them (RS, MS, LO, HO). In theory we should
> > find in
> > the network an RS-manager, an MS-Manager, a LO-Manager and a
> HO-Manager.
> > Moreover a single Wideband Crossconnect would have had to be managed
> by
> > all 4
> > managers at the same time. Obviously this is not really practical
> > (immagine: 4
> > managers, one worker ;-) such that most vendors and carriers decided
> to
> > put all
> > 4 layers into one management box - quite similar to what a GMPLS
> Control
> > Plane
> > does with SONET/SDH control.
> >
> > Just to avoid misunderstandings here: I don't want to start a new
> thread
> > on
> > layering issues. I just want to provide you some food for your own
> > thoughts
> > hoping that we can find some common understanding at some point in
> > future.
> >
> > Regards
> >
> > Gert
> >
> > [email-masked] wrote:
> >
> > > Gert,
> > >
> > > Thanks for outlining the history and your current position for going
> > > forward.  Mostly, I agree with you.
> > >
> > > My major point of disagreement is with your characterization of the
> > > ITU-T direction.  Though the ITU-T ASON documents might enable
> > > "'Bandwidth on Demand' services (BOND)" to some degree, that was not
> > the
> > > primary focus.  The Optical UNI was a development that came out of
> the
> > > OIF and not the ITU-T.  Most carriers have seen the Optical UNI as a
> > > potential customer interface with far more realistic applications
> > > internal to networks, i.e. between the L3/L2 elements and the L1/L0
> > > elements.  Those who have attended the OIF in the past probably
> > remember
> > > my unpopular statement on the plenary floor that we were wasting out
> > > time working on a UNI that had questionable (no?) business
> advantages
> > > for the carrier.
> > >
> > > I do support the approach you mention (from Kireeti?) that we focus
> on
> > > the service points and the information that needs to be exchanged
> > > between them.  Where most of the services are of the L3/L2 variety,
> > that
> > > approach should be successful.  Those items should be fully covered
> by
> > > the IETF solutions.
> > >
> > > However, that doesn't address the multi-layer issue that we are
> > > struggling to address, which is one of the root causes of this
> > conflict
> > > between the IETF and ITU-T.  The signaling/control for L1/L0 is
> where
> > > the ITU-T participants have found the IETF solutions to be
> inadequate.
> > > That's not necessarily because the IETF solutions wouldn't work, but
> > > because they would not satisfy the stringent requirements and models
> > by
> > > which we base our management and control for L1/L0.
> > >
> > > This whole problem could be blamed on the IP success in the
> industry.
> > > If IP had not proven to be so successful, the ITU-T might have
> chosen
> > > the optical control plane based on extensions to SS7.  :-)  (Not
> > meaning
> > > to ignore the ITU-T alternative solution based on PNNI.)
> > >
> > > Regards,
> > >
> > > Mark Loyd Jones
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: Gert.Grammel [mailto:[email-masked]]
> > > Sent: Thursday, March 06, 2003 1:21 PM
> > > To: Mark.Jones
> > > Cc: ccamp; dwfedyk; gash; mpls
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > Mark,
> > >
> > > 'improving the coordination between the IETF and ITU-T' is one of
> the
> > > things I'd
> > > like to see since years. However in my experience the true barrier
> > > between both
> > > groups is not so much the technology as such, but some ignorance
> about
> > > the core
> > > aspects in both organizations. To give a balanced figure here:
> > >
> > >   1. You remember the thread about the non-standard SDH/SONET
> > > extensions. Here
> > >      some guys active in GMPLS tried to push their ideas about
> > > transparency.
> > >      Obviously this was perceived on ITU-T side as a challenge on
> the
> > > purity of
> > >      a standard (G.707). This one was (almost) setteled by moving
> all
> > >      non-standard features to an informal draft.
> > >   2. Now it is the other way round. Somehow ITU-T extensions got
> > > accepted (again
> > >      informational) in IETF which do not comply to the purity of
> > > RSVP-TE. Due to
> > >      the fact that this informational RFC was not reviewed in CCAMP
> > > before, it
> > >      is perceived as an assault.
> > >
> > > So the match is tied up 1:1 but maybe it's now the right time to
> find
> > a
> > > solution
> > > on how to proceed. What I've seen so far was a complete
> misperception
> > of
> > > what is
> > > required on either side and why.
> > >
> > >   1. ITU-T basically started by defining user services having in
> mind
> > > layered
> > >      transport platforms like OTH and SDH/SONET. Those services can
> be
> > >      summarized as 'Bandwidth on Demand' services (BOND). Naturally
> > this
> > > led to
> > >      a very strong focus on UNI interfaces and a kind of ignorance
> of
> > > networking
> > >      protocols. You probably remember the discussions on why not
> using
> > > SS7? (For
> > >      those not familar with the issue: SS7 is the signaling protocol
> > > between
> > >      PSTN switches)
> > >   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE,
> ...)
> > > and
> > >      extending their scope to L1 technologies namely SDH/SONET and
> > OTH.
> > >      Naturally this led to a very strong focus on protocol
> consistency
> > > and a
> > >      kind of ignorance on service aspects other than those already
> > > available in
> > >      MPLS. You may remember here the discussion about whether UNI is
> > > useful at
> > >      all some time ago.
> > >
> > > So putting everything together means that it is required to keep
> > (IETF)
> > > protocol
> > > consistency but adding some (ITU-T) specific extensions to well
> > defined
> > > service
> > > points in the network (UNI).
> > > Unfortunately service points tend to exchange messages between
> > > themselves and
> > > this would mean that an intermediate protocol would have had to
> > support
> > > such
> > > kind of communication. What concerns the IETF community is probably
> > not
> > > the fact
> > > that there is a UNI somewhere, but the changes and extensions to
> > > etablished
> > > protocols in order to achieve a collaboration between them.
> > >
> > > I recall that this was the basic issue with the ITU-T proposal when
> it
> > > was
> > > presented for the first time in Yokohama. The way I've got Kireeti's
> > > message
> > > there was: please authors try to let us understand what problem you
> > want
> > > to
> > > solve and tell us which kind of information you have to exchange
> > between
> > > which
> > > points to achieve it. We'll sort out then in CCAMP what would be the
> > > most
> > > appropriate way to implement it, while maintaining consistency in
> our
> > > protocols.
> > >
> > > Although it didn't work the first time I still consider Kireeti's
> > > suggestion to
> > > be a wise way to move forward and perhaps the key for harmonic
> > > collaboration.
> > >
> > > Regards
> > >
> > > Gert
> > >
> > > [email-masked] wrote:
> > >
> > > > Gert,
> > > >
> > > > I agreed with the intent in generalizing MPLS for the wide range
> of
> > > > expected applications.  It was my hope that it would succeed.  At
> > this
> > > > point, one might say that the intent has only been partially
> > achieved.
> > > > The problem that has come to light over the past year is the fact
> > that
> > > > there are finer points of the ITU-T model and requirements that
> are
> > > not
> > > > supported by the current IETF GMPLS RFCs and standards track
> drafts.
> > > > Those aspects are considered significant enough by many carriers
> and
> > > > their suppliers to warrant further extensions outside of the IETF.
> > > (My
> > > > apologies for not understanding those points well enough to
> clarify
> > > them
> > > > even in examples, but there are many people on this list would
> could
> > > do
> > > > so if they thought it necessary.  To avoid any misunderstand, all
> > > should
> > > > know that Sprint does not yet have a company position on this.)
> It
> > is
> > > > my hope that we can come up with ways of improving the
> coordination
> > > > between the IETF and ITU-T.  This thread of discussion is bringing
> > out
> > > > the issues to make that happen.
> > > >
> > > > Regards,
> > > >
> > > > Mark Loyd Jones
> > > > Optical Transport and Networking
> > > > Sprint - Wireline Technology Development
> > > > 913-794-2139
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Gert.Grammel [mailto:[email-masked]]
> > > > Sent: Thursday, March 06, 2003 10:17 AM
> > > > To: Mark.Jones
> > > > Cc: dwfedyk; gash; ccamp; mpls
> > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > >
> > > > Mark,
> > > >
> > > > please don't forget that due to the 'Generalization' of GMPLS you
> > are
> > > > free to do
> > > > the split at any application level you wish. This was always the
> > > > advantage of
> > > > the GMPLS approach compared to the ITU-T model where initially
> each
> > > > layer had
> > > > its own control plane. So the fact that in theory you could use a
> > > single
> > > > control
> > > > plane for all your network means also that you are able to stop
> > where
> > > > you want.
> > > > Nice feature isn't it?
> > > >
> > > > Regards
> > > >
> > > > Gert
> > > >
> > > > [email-masked] wrote:
> > > >
> > > > > I agree with the separation of GMPLS into the two applications.
> > > There
> > > > > does not appear to be any significant move to collapse the
> > > management
> > > > or
> > > > > signaling for L3/2 and L1/0 at this time, given the different
> > models
> > > > > that apply for them and the infrastructures in our companies
> that
> > > > manage
> > > > > them.  The plan for addressing the two applications need not be
> > the
> > > > > same.
> > > > >
> > > > > The L3/2 application is near and dear to the heart of the IETF.
> > The
> > > > > L1/0 application is of interest to those who wish to collapse
> the
> > > > > management into a single layer.  In my opinion, the IETF might
> > also
> > > > > address this approach, given the IETF participants are the ones
> in
> > > > > support of this collapsed management or at least common protocol
> > > > > solution for what is today two signaling layers.  However, as
> > stated
> > > > > before, the collapse approach is not realistic today for a
> > > > > multi-service, multi-protocol network.
> > > > >
> > > > > On the other hand, the L1/0 application requirements and models
> > have
> > > > > been defined and are best understood at the ITU-T.  Ideally, the
> > > > > protocol expertise at the IETF would be applied to the ITU-T
> model
> > > and
> > > > > requirements to address the L1/0 application, but attempts to do
> > > that
> > > > > have been met with great resistance in the past.  Perhaps that
> was
> > a
> > > > > result of the fact that GMPLS implementations were not separated
> > out
> > > > > into the two different applications.  However, I don't think it
> is
> > > > > realistic to expect the IETF experts to be motivated to
> understand
> > > the
> > > > > ITU-T models and requirements, given the application is outside
> of
> > > > their
> > > > > primary area of interest.  That said, I believe the IETF should
> > > reach
> > > > an
> > > > > agreement on how to work with outside groups that develop "major
> > > > > extensions" to the protocol.
> > > > >
> > > > > Mark Loyd Jones
> > > > > Optical Transport and Networking
> > > > > Sprint - Wireline Technology Development
> > > > > 913-794-2139
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: dwfedyk [mailto:[email-masked]]
> > > > > Sent: Thursday, March 06, 2003 7:49 AM
> > > > > To: gash
> > > > > Cc: mpls; ccamp
> > > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > > >
> > > > > Along the lines of Jerry's comments.
> > > > >
> > > > > When we put together GMPLS the first drafts were under specified
> > > > > intentionally to capture the essence of GMPLS. We put aside many
> > > > > arguments saying lets specify at a high level and fill in the
> > > details
> > > > > later. The discussions on this thread are in two major veins one
> > > > > attempting to fill the details and the other containing and
> > > > controlling
> > > > > the changes. GMPLS needs to be specified more accurately and in
> my
> > > > > opinion it needs to be decomposed to a more layered approach.  I
> > > think
> > > > > if we applied GMPLS at at some layers (L3/2), (L1/L0) for
> example,
> > > > > independently but self similar it would offer a mechanism to
> move
> > > > > forward where some legacy systems could be specified to be GMPLS
> > > > > friendly. For example signaling for Layer 3/2 can be tunneled
> > > through
> > > > > the a lower layer. We already have some work in this direction.
> > > > >  Similarly traffic engineering information for L1/L0 in a TE
> > > database
> > > > >  would need different  attributes than a the TE database at
> L3/2.
> > I
> > > > > don't think you want to burden a L3/L2 system with these
> > attributes
> > > in
> > > > > an overlay model. The expertise for these layer is not all
> > contained
> > > > in
> > > > > the IETF. I think we should put a plan forward to make this
> happen
> > > > > within the IETF process. After this was accomplished  I think
> some
> > > > > people are thinking of collapsing layers even more but the
> logical
> > > > > partitioning of layers may help keep the protocols and databases
> > > > > simpler.   Right now were are treating GMPLS like a big bowl of
> > > jelly
> > > > > when it should look more like a layer cake.
> > > > >
> > > > > Regards,
> > > > > Don
> > > >
> > > > --
> > > > Alcatel Optical Network Division    Gert Grammel
> > > > Network Strategy                    phone: +49 711 821 47368
> > > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > > D-70435 Stuttgart                   mailto:[email-masked]
> > >
> > > --
> > > Alcatel Optical Network Division    Gert Grammel
> > > Network Strategy                    phone: +49 711 821 47368
> > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > D-70435 Stuttgart                   mailto:[email-masked]
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:[email-masked]
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Tue, 11 Mar 2003 09:58:39 -0800
Date: Tue, 11 Mar 2003 18:57:26 +0100
From: [email-masked]
Reply-To: [email-masked]
Organization: ALCATEl - R&I
To: Kireeti Kompella <[email-masked]>, [email-masked]
Cc: [email-masked], Kohei Shiomoto <[email-masked]>
Subject: Re: CCAMP 56 agenda

Hi Kireeti, Hi Ron,

despite the multi-region approach is typically a "common" framework,
http://www.ietf.org/internet-drafts/draft-vigoureux-shiomoto-ccamp-gmpls-mr=
n-01.txt

specific implications, especially on ethernet-based L2LSPs (more
emphasized in this new version) may be discussed.
Though, with respect to recent ethernet-related e-mail exchanges,
we would like to propose a 5-10 minutes slot to have a discussion
covering these topics, and their potential impact on the charter.

Thanks,

Martin.

Kireeti Kompella a =E9crit :

> Hi,
>
> If you would like to speak at the CCAMP WG at the 56th IETF, please
> reply to this email -- that will help the chairs track requests.
> Also, please state which Internet draft(s) form the basis of the
> talk that others may come prepared.
>
> Note: these are *not* presentations, expositions, or tutorials.
> A small number of slides that say what has changed *since the
> last IETF*, issues that were raised in the interim, and resolutions
> to those issues is the ideal.  If there hasn't been a discussion
> on the mailing list, in many cases that is a sign that the topic
> isn't (yet) ready for prime time.
>
> Thanks,
> Ron and Kireeti.

Delivery-date: Tue, 11 Mar 2003 08:19:01 -0800
From: "Ferrell, William" <[email-masked]>
To: "'Gert Grammel '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: {Possible Spam} Re: I-D  ACTION:draft-andersson-mpls-g-chng-p roc-00.txt
Date: Tue, 11 Mar 2003 10:07:11 -0500

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

 Gert / All

 I am Will Ferrell of Titan working at DISA on an MPLS security 
project. I have worked with Barry Raveendran Greene (Cisco) on a major DISA
ACL project of which he provided invaluable guidance/support/ tech reference
that led to the projects success.

Ive checked RFC's 2547,3036,2702 et. al.  It appears that there isnt a lot
of interest in securing MPLS. Can you refer me to other work for MPLS
security requirements and all phases of MPLS security to include secure
implementation. 

> > > 
> > >William Ferrell 
> > >Information Assurance Eng. CCNP 
> > >Titan Corp. 
> > >703-882-2474 

-----Original Message-----
From: Gert Grammel
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Sent: 3/10/03 7:24 AM
Subject: Re: {Possible Spam} Re: I-D
ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Curtis,

you've wrote:

     It would be best if ITU members go off and waste their own time
     pursuing ASON capabilities, just as the ATM Forum went off and
wasted
     their time on Q.2931 capability in UNI 3.x, 4.x, ...

and I don't agree with that. In my view it would be best if ITU-T
members were
able to understand and accept the ideas behind GMPLS and would provide
valuable
input to bring this work forward.

Regards

Gert

Curtis Villamizar wrote:

> Coments inline.
>
> In message <[email-masked]>, Gert Grammel writes:
> >
> > Mark,
> >
> > 'improving the coordination between the IETF and ITU-T' is one of
the
> > things I' d like to see since years. However in my experience the
true
> > barrier between both groups is not so much the technology as such,
but
> > some ignorance about the core aspects in both organizations. To give
a
> > balanced figure here:
> >
> >   1. You remember the thread about the non-standard SDH/SONET
> >      extensions. Here some guys active in GMPLS tried to push their
> >      ideas about transparency.  Obviously this was perceived on
ITU-T
> >      side as a challenge on the purity of a standard (G.707). This
one
> >      was (almost) setteled by moving all non-standard features to an
> >      informal draft.
> >
> >   2. Now it is the other way round. Somehow ITU-T extensions got
> >      accepted (agai n informational) in IETF which do not comply to
> >      the purity of RSVP-TE. Due t o the fact that this informational
> >      RFC was not reviewed in CCAMP before, it is perceived as an
> >      assault.
> >
> > So the match is tied up 1:1 but maybe it's now the right time to
find
> > a solutio n on how to proceed. What I've seen so far was a complete
> > misperception of what i s required on either side and why.
> >
> >   1. ITU-T basically started by defining user services having in
mind
> >      layered transport platforms like OTH and SDH/SONET. Those
> >      services can be summarized as 'Bandwidth on Demand' services
> >      (BOND). Naturally this led to a very strong focus on UNI
> >      interfaces and a kind of ignorance of networkin g protocols.
You
> >      probably remember the discussions on why not using SS7? (For
> >      those not familar with the issue: SS7 is the signaling protocol
> >      between PSTN switches)
>
> SDH/SONET bandwidth on demand has never been deployed.  There is
> serious question about whether this is a viable service.  The
> technology has existed for about a decade (a little less maybe) for
> provide ATM SVC service doing essentially the same thing.  Market
> penetration after a decade is very close to zero for SVC.  Market
> penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> market seems to be shrinking as well.  FR SVC market is zero.
> SDH/SONET does not have the bandwidth on demand capability but there
> is ample evidence that implementing it would be a waste of time.
>
> ASON is a requirements document from ITU that assumes the SDH/SONET
> BOND is a viable service.  This is an enormous leap of faith given the
> trends in the market.  The IETF doesn't buy into it.
>
> And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
> mess, so if you want to extend TCAP to support ASON, go right ahead.
> We in the IETF would get a real good laugh over that.
>
> >   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE,
...)
> >      and extending their scope to L1 technologies namely SDH/SONET
and
> >      OTH.  Naturally this led to a very strong focus on protocol
> >      consistency and a kind of ignorance on service aspects other
than
> >      those already available in MPLS. You may remember here the
> >      discussion about whether UNI is useful at all some time ago.
>
> Initially IP and voice ran over TDM.  The bandwidth demands of IP were
> much less than voice a decade ago.  As IP penetration grew roughly
> exponentially through the early, mid, and most of the late 1990s, this
> reversed and IP consumed far more bandwidth than voice.  Switched
> services also grew but at a slower rate and in the late 1990s
> experienced negative growth for many SPs.  One factor may have been
> notable outages in FR (US nationwide one day at one major provider and
> intermittent for 10 days in another a few years later) shot a big hole
> in the "much more reliable than IP" story.
>
> Initially MPLS served as traffic enginnering strictly for IP.  With IP
> still growing substantially, voice growing very slowly (and losing
> revenue) and switched services growing slowly to shrinking, there was
> motivation to carry voice, switched services, and leased line services
> over the IP and/or MPLS infrastructure and decommission older
> SDH/SONET ADM and FR or ATM switches.  This led to the tunneling work.
>
> Another factor which led to GMPLS was the (unrealized) promise/hype of
> optical switching in the very late 1990s.  IP over an ATM overlay was
> a poor design and IP providers did not want to repeat that mistake so
> the control of the underlying optical domain was accommodated by what
> has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
> addition to FSC, LSC and PSC.
>
> > So putting everything together means that it is required to keep
> > (IETF) protocol consistency but adding some (ITU-T) specific
> > extensions to well defined service points in the network (UNI).
> > Unfortunately service points tend to exchange messages between
> > themselves and this would mean that an intermediate protocol would
> > have had to support such kind of communication. What concerns the
IETF
> > community is probably not the fact that there is a UNI somewhere,
but
> > the changes and extensions to etablished protocols in order to
achieve
> > a collaboration between them.
>
> ASON was never accepted by the IETF as requirements and for very good
> reason.  To say that IETF must accept the ASON requirements simply
> because they came in a liason statement and that the IETF must
> accommodate this ITU folly is absurd.
>
> > I recall that this was the basic issue with the ITU-T proposal when
it
> > was presented for the first time in Yokohama. The way I've got
> > Kireeti's message there was: please authors try to let us understand
> > what problem you want to solve and tell us which kind of information
> > you have to exchange between which points to achieve it. We'll sort
> > out then in CCAMP what would be the most appropriate way to
implement
> > it, while maintaining consistency in our protocols .
>
> Regardless of how this was handled in Yokohama, some of the
> fundamental premise of ASON is flawed.  It would be best if ITU
> members go off and waste their own time pursuing ASON capabilities,
> just as the ATM Forum went off and wasted their time on Q.2931
> capability in UNI 3.x, 4.x, but ITU should do so without extending
> protocols which originated in the IETF.
>
> > Although it didn't work the first time I still consider Kireeti's
> > suggestion to be a wise way to move forward and perhaps the key for
> > harmonic collaboration.
> >
> > Regards
> >
> > Gert
>
> I look forward to seeing the IETF come up with a formal statement of
> liason policy.  It would be useful to have explicitly documented that
> liason statements carry no more weight than any individual
> internet-draft submission.
>
> Curtis

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Tue, 11 Mar 2003 07:48:37 -0800
Date: Tue, 11 Mar 2003 16:47:20 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: "Lazer, Monica A, ALABS" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Monica,

there is nothing wrong with improving a solution. The key is to know where to
start and where to go.
You may agree that CCAMP had another starting point than ITU-T/ASON.  However my
feeling is, that even this issue is not really understood by many of the folks
out there. If there is no acceptance that priorities in another SDO is different
from the own one, we won't come to an agreement at any time soon.
Look at the hottest issue under discussion: We are talking a lot about UNI
features like call/connection separation. Neither Mark nor Neil see the UNI
becoming service relevant at any time soon - so why is it under discussion right
now? Is this your priority 1 issue in ITU-T? Is Mark or Neil in a minority
position in ITU-T? Referring to the Yokohama Meeting this was basically
Kireeti's request: Please explain what you need and for what purpose.

What I am trying to achieve is to make the priorities transparent such that
either side can see where is the difference and where is the overlap. Otherwise
we will endlessly continue to discuss about feature requirements and whether
they seem to be relevant or not.

In short I repeat my previous statement using some of your own words:

     In my view, the main issue <snip> is about what is bringing more value
     to a carrier's network:

        * a single Control Plane Paradigm not optimized for a specific
          Layer or
        * a variety of control plane paradigms optimized for specific Layer
          needs

Regards

Gert

"Lazer, Monica A, ALABS" wrote:

> Gert,
> I have some comments, inline, below. The short of it is that I don't
> agree with your perspective.
> In my view, the main issue is not about taking sides in these debates,
> but about what is bringing more value to a carrier's network.
>
> Monica A. Lazer
> Network Architecture and Reliability
>
> 908 234 8462
> [email-masked]
>
> -----Original Message-----
> From: Gert Grammel [mailto:[email-masked]]
> Sent: Monday, March 10, 2003 7:19 AM
> To: Lazer, Monica A, ALABS
> Cc: [email-masked]; [email-masked];
> [email-masked]; Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Monica,
>
> I think there were lots of discussions about what is best for layer XYZ
> and also
> Neil was arguing in this direction. This argumentation is of course
> valid if you
> focus on layer XYZ and look for a (new) control plane. Let's name it a
> classical
> ASON point ov view. What I tried to raise as an issue is, that from a
> CCAMP
> point of view the question is the other way round. You have already a
> control
> plane defined and the question is: how to apply it in the best way to
> layer XYZ?
> There is an issue about what is the main backwards compatibility issue
> here, I guess. From the ccamp perspective, it seems to be compatibility
> with the defined GMPLS work. From the network perspective, however, it
> means compatibility with how the transport network works. It may indeed
> be an issue of priorities.
> So coming back to your argument. You've said correctly:
>
>      ... while when going from HO to LO one is within the same paradigm.
>
> One conclusion could be: you should use the same Control Plane paradigm
> for
> different layers in order to let them interoperate seamlessly. First it
> needs to support each layer!
>  Further more, scalability becomes a very real issue
> To sum up a bit: in my view all the discussion about features of ASON
> and/or
> GMPLS is flawed right from the beginning if it is not clear what should
> be
> achieved:
>
>   1. If you focus on a single paradigm arcoss layers you should consider
> GMPLS
>      with all its features and limitations
> Why must one take things with limitations, what is wrong with
> improvements?
> The control plane focus is on saving operations cost for the given
> layer!
>
>   2. If you are interesting on getting some specialized control planes
> for
>      SDH/SONET you are free to choose anything.
>
> in ITU-T you have the choice, in IETF you have not. Do you really mean
> this?? That seems to be a flawed attitude. Saying that in ietf there is
> no choice, or room for improvements (your point above about accepting
> all its limitations) seems to be a serious judgment call on this forum.
> Are you saying that one should not even bother with problem statements
> or requirements?
>  For sure the choice is not
> between transport and packet technology, the choice is your focus.
>
> Regards
>
> Gert
>
> "Lazer, Monica A, ALABS" wrote:
>
> > Gert,
> > I think that one of the main drivers of the different needs when going
> > from L1 to L2 is the fact L1, in SONET is TDM-based, while L2 can be
> > packet based and have a different paradigm, while when going from HO
> to
> > LO one is within the same paradigm. So, point 1 indicates that one
> > should consider using the same control plane architecture for the
> > sublayers within L1, but it does not necessarily support the idea that
> > the same paradigm is best for both L1 and higher layers.  Regarding
> the
> > backbone/regional structure, more than only 2 levels may be needed for
> > global transport networks.
> >
> > Regards,
> >
> > Monica A. Lazer
> > Network Architecture and Reliability
> >
> > 908 234 8462
> > [email-masked]
> >
> > -----Original Message-----
> > From: Gert Grammel [mailto:[email-masked]]
> > Sent: Thursday, March 06, 2003 3:38 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; Ash, Gerald R
> > (Jerry), ALABS; [email-masked]
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Mark,
> >
> > I am happy to read that we could find some common understanding. About
> > your
> > multi-layer issue you've raised, I suggest to figure out more to which
> > extend
> > this is an issue for UNI. Some thoughts on that:
> >
> >   1. Wideband Crossconnects are able to crossconnect low order
> circuits
> > (LO),
> >      and put them into high order circuits (HO). Those Crossconnects
> are
> > managed
> >      by one manager able to control both Layers: LO and HO. I've never
> > heard
> >      that an operator let one part of the organization implement HO
> only
> > on a
> >      country wide basis, while another part of the organization is
> > taking care
> >      about LO only.
> >   2. So rather than the pure layering, a kind of regional/backbone
> > structure is
> >      in place. Regional NOCs deal with HO and LO whithin the region
> > while in
> >      backbone you use HO only because you don't need the finer
> > granularity
> >      there. So what appears to be a layering from a management point
> of
> > view
> >      seems to me more a regional kind of separation.
> >
> > To be clear: I don't want to discuss the fact that there is a layering
> > in the
> > network. My point is to highlight that SDH/SONET is in reality not a
> > single
> > layer but has at least 4 of them (RS, MS, LO, HO). In theory we should
> > find in
> > the network an RS-manager, an MS-Manager, a LO-Manager and a
> HO-Manager.
> > Moreover a single Wideband Crossconnect would have had to be managed
> by
> > all 4
> > managers at the same time. Obviously this is not really practical
> > (immagine: 4
> > managers, one worker ;-) such that most vendors and carriers decided
> to
> > put all
> > 4 layers into one management box - quite similar to what a GMPLS
> Control
> > Plane
> > does with SONET/SDH control.
> >
> > Just to avoid misunderstandings here: I don't want to start a new
> thread
> > on
> > layering issues. I just want to provide you some food for your own
> > thoughts
> > hoping that we can find some common understanding at some point in
> > future.
> >
> > Regards
> >
> > Gert
> >
> > [email-masked] wrote:
> >
> > > Gert,
> > >
> > > Thanks for outlining the history and your current position for going
> > > forward.  Mostly, I agree with you.
> > >
> > > My major point of disagreement is with your characterization of the
> > > ITU-T direction.  Though the ITU-T ASON documents might enable
> > > "'Bandwidth on Demand' services (BOND)" to some degree, that was not
> > the
> > > primary focus.  The Optical UNI was a development that came out of
> the
> > > OIF and not the ITU-T.  Most carriers have seen the Optical UNI as a
> > > potential customer interface with far more realistic applications
> > > internal to networks, i.e. between the L3/L2 elements and the L1/L0
> > > elements.  Those who have attended the OIF in the past probably
> > remember
> > > my unpopular statement on the plenary floor that we were wasting out
> > > time working on a UNI that had questionable (no?) business
> advantages
> > > for the carrier.
> > >
> > > I do support the approach you mention (from Kireeti?) that we focus
> on
> > > the service points and the information that needs to be exchanged
> > > between them.  Where most of the services are of the L3/L2 variety,
> > that
> > > approach should be successful.  Those items should be fully covered
> by
> > > the IETF solutions.
> > >
> > > However, that doesn't address the multi-layer issue that we are
> > > struggling to address, which is one of the root causes of this
> > conflict
> > > between the IETF and ITU-T.  The signaling/control for L1/L0 is
> where
> > > the ITU-T participants have found the IETF solutions to be
> inadequate.
> > > That's not necessarily because the IETF solutions wouldn't work, but
> > > because they would not satisfy the stringent requirements and models
> > by
> > > which we base our management and control for L1/L0.
> > >
> > > This whole problem could be blamed on the IP success in the
> industry.
> > > If IP had not proven to be so successful, the ITU-T might have
> chosen
> > > the optical control plane based on extensions to SS7.  :-)  (Not
> > meaning
> > > to ignore the ITU-T alternative solution based on PNNI.)
> > >
> > > Regards,
> > >
> > > Mark Loyd Jones
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: Gert.Grammel [mailto:[email-masked]]
> > > Sent: Thursday, March 06, 2003 1:21 PM
> > > To: Mark.Jones
> > > Cc: ccamp; dwfedyk; gash; mpls
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > Mark,
> > >
> > > 'improving the coordination between the IETF and ITU-T' is one of
> the
> > > things I'd
> > > like to see since years. However in my experience the true barrier
> > > between both
> > > groups is not so much the technology as such, but some ignorance
> about
> > > the core
> > > aspects in both organizations. To give a balanced figure here:
> > >
> > >   1. You remember the thread about the non-standard SDH/SONET
> > > extensions. Here
> > >      some guys active in GMPLS tried to push their ideas about
> > > transparency.
> > >      Obviously this was perceived on ITU-T side as a challenge on
> the
> > > purity of
> > >      a standard (G.707). This one was (almost) setteled by moving
> all
> > >      non-standard features to an informal draft.
> > >   2. Now it is the other way round. Somehow ITU-T extensions got
> > > accepted (again
> > >      informational) in IETF which do not comply to the purity of
> > > RSVP-TE. Due to
> > >      the fact that this informational RFC was not reviewed in CCAMP
> > > before, it
> > >      is perceived as an assault.
> > >
> > > So the match is tied up 1:1 but maybe it's now the right time to
> find
> > a
> > > solution
> > > on how to proceed. What I've seen so far was a complete
> misperception
> > of
> > > what is
> > > required on either side and why.
> > >
> > >   1. ITU-T basically started by defining user services having in
> mind
> > > layered
> > >      transport platforms like OTH and SDH/SONET. Those services can
> be
> > >      summarized as 'Bandwidth on Demand' services (BOND). Naturally
> > this
> > > led to
> > >      a very strong focus on UNI interfaces and a kind of ignorance
> of
> > > networking
> > >      protocols. You probably remember the discussions on why not
> using
> > > SS7? (For
> > >      those not familar with the issue: SS7 is the signaling protocol
> > > between
> > >      PSTN switches)
> > >   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE,
> ...)
> > > and
> > >      extending their scope to L1 technologies namely SDH/SONET and
> > OTH.
> > >      Naturally this led to a very strong focus on protocol
> consistency
> > > and a
> > >      kind of ignorance on service aspects other than those already
> > > available in
> > >      MPLS. You may remember here the discussion about whether UNI is
> > > useful at
> > >      all some time ago.
> > >
> > > So putting everything together means that it is required to keep
> > (IETF)
> > > protocol
> > > consistency but adding some (ITU-T) specific extensions to well
> > defined
> > > service
> > > points in the network (UNI).
> > > Unfortunately service points tend to exchange messages between
> > > themselves and
> > > this would mean that an intermediate protocol would have had to
> > support
> > > such
> > > kind of communication. What concerns the IETF community is probably
> > not
> > > the fact
> > > that there is a UNI somewhere, but the changes and extensions to
> > > etablished
> > > protocols in order to achieve a collaboration between them.
> > >
> > > I recall that this was the basic issue with the ITU-T proposal when
> it
> > > was
> > > presented for the first time in Yokohama. The way I've got Kireeti's
> > > message
> > > there was: please authors try to let us understand what problem you
> > want
> > > to
> > > solve and tell us which kind of information you have to exchange
> > between
> > > which
> > > points to achieve it. We'll sort out then in CCAMP what would be the
> > > most
> > > appropriate way to implement it, while maintaining consistency in
> our
> > > protocols.
> > >
> > > Although it didn't work the first time I still consider Kireeti's
> > > suggestion to
> > > be a wise way to move forward and perhaps the key for harmonic
> > > collaboration.
> > >
> > > Regards
> > >
> > > Gert
> > >
> > > [email-masked] wrote:
> > >
> > > > Gert,
> > > >
> > > > I agreed with the intent in generalizing MPLS for the wide range
> of
> > > > expected applications.  It was my hope that it would succeed.  At
> > this
> > > > point, one might say that the intent has only been partially
> > achieved.
> > > > The problem that has come to light over the past year is the fact
> > that
> > > > there are finer points of the ITU-T model and requirements that
> are
> > > not
> > > > supported by the current IETF GMPLS RFCs and standards track
> drafts.
> > > > Those aspects are considered significant enough by many carriers
> and
> > > > their suppliers to warrant further extensions outside of the IETF.
> > > (My
> > > > apologies for not understanding those points well enough to
> clarify
> > > them
> > > > even in examples, but there are many people on this list would
> could
> > > do
> > > > so if they thought it necessary.  To avoid any misunderstand, all
> > > should
> > > > know that Sprint does not yet have a company position on this.)
> It
> > is
> > > > my hope that we can come up with ways of improving the
> coordination
> > > > between the IETF and ITU-T.  This thread of discussion is bringing
> > out
> > > > the issues to make that happen.
> > > >
> > > > Regards,
> > > >
> > > > Mark Loyd Jones
> > > > Optical Transport and Networking
> > > > Sprint - Wireline Technology Development
> > > > 913-794-2139
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Gert.Grammel [mailto:[email-masked]]
> > > > Sent: Thursday, March 06, 2003 10:17 AM
> > > > To: Mark.Jones
> > > > Cc: dwfedyk; gash; ccamp; mpls
> > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > >
> > > > Mark,
> > > >
> > > > please don't forget that due to the 'Generalization' of GMPLS you
> > are
> > > > free to do
> > > > the split at any application level you wish. This was always the
> > > > advantage of
> > > > the GMPLS approach compared to the ITU-T model where initially
> each
> > > > layer had
> > > > its own control plane. So the fact that in theory you could use a
> > > single
> > > > control
> > > > plane for all your network means also that you are able to stop
> > where
> > > > you want.
> > > > Nice feature isn't it?
> > > >
> > > > Regards
> > > >
> > > > Gert
> > > >
> > > > [email-masked] wrote:
> > > >
> > > > > I agree with the separation of GMPLS into the two applications.
> > > There
> > > > > does not appear to be any significant move to collapse the
> > > management
> > > > or
> > > > > signaling for L3/2 and L1/0 at this time, given the different
> > models
> > > > > that apply for them and the infrastructures in our companies
> that
> > > > manage
> > > > > them.  The plan for addressing the two applications need not be
> > the
> > > > > same.
> > > > >
> > > > > The L3/2 application is near and dear to the heart of the IETF.
> > The
> > > > > L1/0 application is of interest to those who wish to collapse
> the
> > > > > management into a single layer.  In my opinion, the IETF might
> > also
> > > > > address this approach, given the IETF participants are the ones
> in
> > > > > support of this collapsed management or at least common protocol
> > > > > solution for what is today two signaling layers.  However, as
> > stated
> > > > > before, the collapse approach is not realistic today for a
> > > > > multi-service, multi-protocol network.
> > > > >
> > > > > On the other hand, the L1/0 application requirements and models
> > have
> > > > > been defined and are best understood at the ITU-T.  Ideally, the
> > > > > protocol expertise at the IETF would be applied to the ITU-T
> model
> > > and
> > > > > requirements to address the L1/0 application, but attempts to do
> > > that
> > > > > have been met with great resistance in the past.  Perhaps that
> was
> > a
> > > > > result of the fact that GMPLS implementations were not separated
> > out
> > > > > into the two different applications.  However, I don't think it
> is
> > > > > realistic to expect the IETF experts to be motivated to
> understand
> > > the
> > > > > ITU-T models and requirements, given the application is outside
> of
> > > > their
> > > > > primary area of interest.  That said, I believe the IETF should
> > > reach
> > > > an
> > > > > agreement on how to work with outside groups that develop "major
> > > > > extensions" to the protocol.
> > > > >
> > > > > Mark Loyd Jones
> > > > > Optical Transport and Networking
> > > > > Sprint - Wireline Technology Development
> > > > > 913-794-2139
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: dwfedyk [mailto:[email-masked]]
> > > > > Sent: Thursday, March 06, 2003 7:49 AM
> > > > > To: gash
> > > > > Cc: mpls; ccamp
> > > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > > >
> > > > > Along the lines of Jerry's comments.
> > > > >
> > > > > When we put together GMPLS the first drafts were under specified
> > > > > intentionally to capture the essence of GMPLS. We put aside many
> > > > > arguments saying lets specify at a high level and fill in the
> > > details
> > > > > later. The discussions on this thread are in two major veins one
> > > > > attempting to fill the details and the other containing and
> > > > controlling
> > > > > the changes. GMPLS needs to be specified more accurately and in
> my
> > > > > opinion it needs to be decomposed to a more layered approach.  I
> > > think
> > > > > if we applied GMPLS at at some layers (L3/2), (L1/L0) for
> example,
> > > > > independently but self similar it would offer a mechanism to
> move
> > > > > forward where some legacy systems could be specified to be GMPLS
> > > > > friendly. For example signaling for Layer 3/2 can be tunneled
> > > through
> > > > > the a lower layer. We already have some work in this direction.
> > > > >  Similarly traffic engineering information for L1/L0 in a TE
> > > database
> > > > >  would need different  attributes than a the TE database at
> L3/2.
> > I
> > > > > don't think you want to burden a L3/L2 system with these
> > attributes
> > > in
> > > > > an overlay model. The expertise for these layer is not all
> > contained
> > > > in
> > > > > the IETF. I think we should put a plan forward to make this
> happen
> > > > > within the IETF process. After this was accomplished  I think
> some
> > > > > people are thinking of collapsing layers even more but the
> logical
> > > > > partitioning of layers may help keep the protocols and databases
> > > > > simpler.   Right now were are treating GMPLS like a big bowl of
> > > jelly
> > > > > when it should look more like a layer cake.
> > > > >
> > > > > Regards,
> > > > > Don
> > > >
> > > > --
> > > > Alcatel Optical Network Division    Gert Grammel
> > > > Network Strategy                    phone: +49 711 821 47368
> > > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > > D-70435 Stuttgart                   mailto:[email-masked]
> > >
> > > --
> > > Alcatel Optical Network Division    Gert Grammel
> > > Network Strategy                    phone: +49 711 821 47368
> > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > D-70435 Stuttgart                   mailto:[email-masked]
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:[email-masked]
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Tue, 11 Mar 2003 07:22:15 -0800
Date: Tue, 11 Mar 2003 16:19:56 +0100
From: Genadi Velev <[email-masked]>
Subject: RE: CCAMP 56 agenda
To: Kireeti Kompella <[email-masked]>, [email-masked]
Cc: [email-masked]
Reply-to: [email-masked]

Hi Kireeti and Ron,

I would like to request a 5-10 minutes slot for discussion on the following
draft:
"Method to Setup LSP using VLAN Tag Switching"
http://www.ietf.org/internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt

This draft was intended to be submitted initially in the MPLS WG, although
after receiving some feedback, it seems that it would be better to have the
discussions in CCAMP WG.

The use of CR-LDP for signalling of VLAN-LSP will be reconsidered in a
future version of the draft.

All kinds of comments are welcome!

thanks,
Genadi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kireeti Kompella
> Sent: Sunday, March 02, 2003 6:56 AM
> To: [email-masked]
> Subject: CCAMP 56 agenda
>
>
> Hi,
>
> If you would like to speak at the CCAMP WG at the 56th IETF, please
> reply to this email -- that will help the chairs track requests.
> Also, please state which Internet draft(s) form the basis of the
> talk that others may come prepared.
>
> Note: these are *not* presentations, expositions, or tutorials.
> A small number of slides that say what has changed *since the
> last IETF*, issues that were raised in the interim, and resolutions
> to those issues is the ideal.  If there hasn't been a discussion
> on the mailing list, in many cases that is a sign that the topic
> isn't (yet) ready for prime time.
>
> Thanks,
> Ron and Kireeti.
>

Delivery-date: Tue, 11 Mar 2003 07:05:35 -0800
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Tue, 11 Mar 2003 10:03:19 -0500
From: "Lazer, Monica A, ALABS" <[email-masked]>
To: "Gert Grammel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, <[email-masked]>

Gert,
I have some comments, inline, below. The short of it is that I don't
agree with your perspective.
In my view, the main issue is not about taking sides in these debates,
but about what is bringing more value to a carrier's network.=20

Monica A. Lazer
Network Architecture and Reliability
=20
908 234 8462
[email-masked]

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]]
Sent: Monday, March 10, 2003 7:19 AM
To: Lazer, Monica A, ALABS
Cc: [email-masked]; [email-masked];
[email-masked]; Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Monica,

I think there were lots of discussions about what is best for layer XYZ
and also
Neil was arguing in this direction. This argumentation is of course
valid if you
focus on layer XYZ and look for a (new) control plane. Let's name it a
classical
ASON point ov view. What I tried to raise as an issue is, that from a
CCAMP
point of view the question is the other way round. You have already a
control
plane defined and the question is: how to apply it in the best way to
layer XYZ?
There is an issue about what is the main backwards compatibility issue
here, I guess. From the ccamp perspective, it seems to be compatibility
with the defined GMPLS work. From the network perspective, however, it
means compatibility with how the transport network works. It may indeed
be an issue of priorities.
So coming back to your argument. You've said correctly:

     ... while when going from HO to LO one is within the same paradigm.

One conclusion could be: you should use the same Control Plane paradigm
for
different layers in order to let them interoperate seamlessly. First it
needs to support each layer!
 Further more, scalability becomes a very real issue=20
To sum up a bit: in my view all the discussion about features of ASON
and/or
GMPLS is flawed right from the beginning if it is not clear what should
be
achieved:=20

  1. If you focus on a single paradigm arcoss layers you should consider
GMPLS
     with all its features and limitations
Why must one take things with limitations, what is wrong with
improvements?
The control plane focus is on saving operations cost for the given
layer!=20

  2. If you are interesting on getting some specialized control planes
for
     SDH/SONET you are free to choose anything.

in ITU-T you have the choice, in IETF you have not. Do you really mean
this?? That seems to be a flawed attitude. Saying that in ietf there is
no choice, or room for improvements (your point above about accepting
all its limitations) seems to be a serious judgment call on this forum.
Are you saying that one should not even bother with problem statements
or requirements?=20
 For sure the choice is not
between transport and packet technology, the choice is your focus.

Regards

Gert

"Lazer, Monica A, ALABS" wrote:

> Gert,
> I think that one of the main drivers of the different needs when going
> from L1 to L2 is the fact L1, in SONET is TDM-based, while L2 can be
> packet based and have a different paradigm, while when going from HO
to
> LO one is within the same paradigm. So, point 1 indicates that one
> should consider using the same control plane architecture for the
> sublayers within L1, but it does not necessarily support the idea that
> the same paradigm is best for both L1 and higher layers.  Regarding
the
> backbone/regional structure, more than only 2 levels may be needed for
> global transport networks.
>
> Regards,
>
> Monica A. Lazer
> Network Architecture and Reliability
>
> 908 234 8462
> [email-masked]
>
> -----Original Message-----
> From: Gert Grammel [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 3:38 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Ash, Gerald R
> (Jerry), ALABS; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Mark,
>
> I am happy to read that we could find some common understanding. About
> your
> multi-layer issue you've raised, I suggest to figure out more to which
> extend
> this is an issue for UNI. Some thoughts on that:
>
>   1. Wideband Crossconnects are able to crossconnect low order
circuits
> (LO),
>      and put them into high order circuits (HO). Those Crossconnects
are
> managed
>      by one manager able to control both Layers: LO and HO. I've never
> heard
>      that an operator let one part of the organization implement HO
only
> on a
>      country wide basis, while another part of the organization is
> taking care
>      about LO only.
>   2. So rather than the pure layering, a kind of regional/backbone
> structure is
>      in place. Regional NOCs deal with HO and LO whithin the region
> while in
>      backbone you use HO only because you don't need the finer
> granularity
>      there. So what appears to be a layering from a management point
of
> view
>      seems to me more a regional kind of separation.
>
> To be clear: I don't want to discuss the fact that there is a layering
> in the
> network. My point is to highlight that SDH/SONET is in reality not a
> single
> layer but has at least 4 of them (RS, MS, LO, HO). In theory we should
> find in
> the network an RS-manager, an MS-Manager, a LO-Manager and a
HO-Manager.
> Moreover a single Wideband Crossconnect would have had to be managed
by
> all 4
> managers at the same time. Obviously this is not really practical
> (immagine: 4
> managers, one worker ;-) such that most vendors and carriers decided
to
> put all
> 4 layers into one management box - quite similar to what a GMPLS
Control
> Plane
> does with SONET/SDH control.
>
> Just to avoid misunderstandings here: I don't want to start a new
thread
> on
> layering issues. I just want to provide you some food for your own
> thoughts
> hoping that we can find some common understanding at some point in
> future.
>
> Regards
>
> Gert
>
> [email-masked] wrote:
>
> > Gert,
> >
> > Thanks for outlining the history and your current position for going
> > forward.  Mostly, I agree with you.
> >
> > My major point of disagreement is with your characterization of the
> > ITU-T direction.  Though the ITU-T ASON documents might enable
> > "'Bandwidth on Demand' services (BOND)" to some degree, that was not
> the
> > primary focus.  The Optical UNI was a development that came out of
the
> > OIF and not the ITU-T.  Most carriers have seen the Optical UNI as a
> > potential customer interface with far more realistic applications
> > internal to networks, i.e. between the L3/L2 elements and the L1/L0
> > elements.  Those who have attended the OIF in the past probably
> remember
> > my unpopular statement on the plenary floor that we were wasting out
> > time working on a UNI that had questionable (no?) business
advantages
> > for the carrier.
> >
> > I do support the approach you mention (from Kireeti?) that we focus
on
> > the service points and the information that needs to be exchanged
> > between them.  Where most of the services are of the L3/L2 variety,
> that
> > approach should be successful.  Those items should be fully covered
by
> > the IETF solutions.
> >
> > However, that doesn't address the multi-layer issue that we are
> > struggling to address, which is one of the root causes of this
> conflict
> > between the IETF and ITU-T.  The signaling/control for L1/L0 is
where
> > the ITU-T participants have found the IETF solutions to be
inadequate.
> > That's not necessarily because the IETF solutions wouldn't work, but
> > because they would not satisfy the stringent requirements and models
> by
> > which we base our management and control for L1/L0.
> >
> > This whole problem could be blamed on the IP success in the
industry.
> > If IP had not proven to be so successful, the ITU-T might have
chosen
> > the optical control plane based on extensions to SS7.  :-)  (Not
> meaning
> > to ignore the ITU-T alternative solution based on PNNI.)
> >
> > Regards,
> >
> > Mark Loyd Jones
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: Gert.Grammel [mailto:[email-masked]]
> > Sent: Thursday, March 06, 2003 1:21 PM
> > To: Mark.Jones
> > Cc: ccamp; dwfedyk; gash; mpls
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Mark,
> >
> > 'improving the coordination between the IETF and ITU-T' is one of
the
> > things I'd
> > like to see since years. However in my experience the true barrier
> > between both
> > groups is not so much the technology as such, but some ignorance
about
> > the core
> > aspects in both organizations. To give a balanced figure here:
> >
> >   1. You remember the thread about the non-standard SDH/SONET
> > extensions. Here
> >      some guys active in GMPLS tried to push their ideas about
> > transparency.
> >      Obviously this was perceived on ITU-T side as a challenge on
the
> > purity of
> >      a standard (G.707). This one was (almost) setteled by moving
all
> >      non-standard features to an informal draft.
> >   2. Now it is the other way round. Somehow ITU-T extensions got
> > accepted (again
> >      informational) in IETF which do not comply to the purity of
> > RSVP-TE. Due to
> >      the fact that this informational RFC was not reviewed in CCAMP
> > before, it
> >      is perceived as an assault.
> >
> > So the match is tied up 1:1 but maybe it's now the right time to
find
> a
> > solution
> > on how to proceed. What I've seen so far was a complete
misperception
> of
> > what is
> > required on either side and why.
> >
> >   1. ITU-T basically started by defining user services having in
mind
> > layered
> >      transport platforms like OTH and SDH/SONET. Those services can
be
> >      summarized as 'Bandwidth on Demand' services (BOND). Naturally
> this
> > led to
> >      a very strong focus on UNI interfaces and a kind of ignorance
of
> > networking
> >      protocols. You probably remember the discussions on why not
using
> > SS7? (For
> >      those not familar with the issue: SS7 is the signaling protocol
> > between
> >      PSTN switches)
> >   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE,
...)
> > and
> >      extending their scope to L1 technologies namely SDH/SONET and
> OTH.
> >      Naturally this led to a very strong focus on protocol
consistency
> > and a
> >      kind of ignorance on service aspects other than those already
> > available in
> >      MPLS. You may remember here the discussion about whether UNI is
> > useful at
> >      all some time ago.
> >
> > So putting everything together means that it is required to keep
> (IETF)
> > protocol
> > consistency but adding some (ITU-T) specific extensions to well
> defined
> > service
> > points in the network (UNI).
> > Unfortunately service points tend to exchange messages between
> > themselves and
> > this would mean that an intermediate protocol would have had to
> support
> > such
> > kind of communication. What concerns the IETF community is probably
> not
> > the fact
> > that there is a UNI somewhere, but the changes and extensions to
> > etablished
> > protocols in order to achieve a collaboration between them.
> >
> > I recall that this was the basic issue with the ITU-T proposal when
it
> > was
> > presented for the first time in Yokohama. The way I've got Kireeti's
> > message
> > there was: please authors try to let us understand what problem you
> want
> > to
> > solve and tell us which kind of information you have to exchange
> between
> > which
> > points to achieve it. We'll sort out then in CCAMP what would be the
> > most
> > appropriate way to implement it, while maintaining consistency in
our
> > protocols.
> >
> > Although it didn't work the first time I still consider Kireeti's
> > suggestion to
> > be a wise way to move forward and perhaps the key for harmonic
> > collaboration.
> >
> > Regards
> >
> > Gert
> >
> > [email-masked] wrote:
> >
> > > Gert,
> > >
> > > I agreed with the intent in generalizing MPLS for the wide range
of
> > > expected applications.  It was my hope that it would succeed.  At
> this
> > > point, one might say that the intent has only been partially
> achieved.
> > > The problem that has come to light over the past year is the fact
> that
> > > there are finer points of the ITU-T model and requirements that
are
> > not
> > > supported by the current IETF GMPLS RFCs and standards track
drafts.
> > > Those aspects are considered significant enough by many carriers
and
> > > their suppliers to warrant further extensions outside of the IETF.
> > (My
> > > apologies for not understanding those points well enough to
clarify
> > them
> > > even in examples, but there are many people on this list would
could
> > do
> > > so if they thought it necessary.  To avoid any misunderstand, all
> > should
> > > know that Sprint does not yet have a company position on this.)
It
> is
> > > my hope that we can come up with ways of improving the
coordination
> > > between the IETF and ITU-T.  This thread of discussion is bringing
> out
> > > the issues to make that happen.
> > >
> > > Regards,
> > >
> > > Mark Loyd Jones
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: Gert.Grammel [mailto:[email-masked]]
> > > Sent: Thursday, March 06, 2003 10:17 AM
> > > To: Mark.Jones
> > > Cc: dwfedyk; gash; ccamp; mpls
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > Mark,
> > >
> > > please don't forget that due to the 'Generalization' of GMPLS you
> are
> > > free to do
> > > the split at any application level you wish. This was always the
> > > advantage of
> > > the GMPLS approach compared to the ITU-T model where initially
each
> > > layer had
> > > its own control plane. So the fact that in theory you could use a
> > single
> > > control
> > > plane for all your network means also that you are able to stop
> where
> > > you want.
> > > Nice feature isn't it?
> > >
> > > Regards
> > >
> > > Gert
> > >
> > > [email-masked] wrote:
> > >
> > > > I agree with the separation of GMPLS into the two applications.
> > There
> > > > does not appear to be any significant move to collapse the
> > management
> > > or
> > > > signaling for L3/2 and L1/0 at this time, given the different
> models
> > > > that apply for them and the infrastructures in our companies
that
> > > manage
> > > > them.  The plan for addressing the two applications need not be
> the
> > > > same.
> > > >
> > > > The L3/2 application is near and dear to the heart of the IETF.
> The
> > > > L1/0 application is of interest to those who wish to collapse
the
> > > > management into a single layer.  In my opinion, the IETF might
> also
> > > > address this approach, given the IETF participants are the ones
in
> > > > support of this collapsed management or at least common protocol
> > > > solution for what is today two signaling layers.  However, as
> stated
> > > > before, the collapse approach is not realistic today for a
> > > > multi-service, multi-protocol network.
> > > >
> > > > On the other hand, the L1/0 application requirements and models
> have
> > > > been defined and are best understood at the ITU-T.  Ideally, the
> > > > protocol expertise at the IETF would be applied to the ITU-T
model
> > and
> > > > requirements to address the L1/0 application, but attempts to do
> > that
> > > > have been met with great resistance in the past.  Perhaps that
was
> a
> > > > result of the fact that GMPLS implementations were not separated
> out
> > > > into the two different applications.  However, I don't think it
is
> > > > realistic to expect the IETF experts to be motivated to
understand
> > the
> > > > ITU-T models and requirements, given the application is outside
of
> > > their
> > > > primary area of interest.  That said, I believe the IETF should
> > reach
> > > an
> > > > agreement on how to work with outside groups that develop "major
> > > > extensions" to the protocol.
> > > >
> > > > Mark Loyd Jones
> > > > Optical Transport and Networking
> > > > Sprint - Wireline Technology Development
> > > > 913-794-2139
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: dwfedyk [mailto:[email-masked]]
> > > > Sent: Thursday, March 06, 2003 7:49 AM
> > > > To: gash
> > > > Cc: mpls; ccamp
> > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > >
> > > > Along the lines of Jerry's comments.
> > > >
> > > > When we put together GMPLS the first drafts were under specified
> > > > intentionally to capture the essence of GMPLS. We put aside many
> > > > arguments saying lets specify at a high level and fill in the
> > details
> > > > later. The discussions on this thread are in two major veins one
> > > > attempting to fill the details and the other containing and
> > > controlling
> > > > the changes. GMPLS needs to be specified more accurately and in
my
> > > > opinion it needs to be decomposed to a more layered approach.  I
> > think
> > > > if we applied GMPLS at at some layers (L3/2), (L1/L0) for
example,
> > > > independently but self similar it would offer a mechanism to
move
> > > > forward where some legacy systems could be specified to be GMPLS
> > > > friendly. For example signaling for Layer 3/2 can be tunneled
> > through
> > > > the a lower layer. We already have some work in this direction.
> > > >  Similarly traffic engineering information for L1/L0 in a TE
> > database
> > > >  would need different  attributes than a the TE database at
L3/2.
> I
> > > > don't think you want to burden a L3/L2 system with these
> attributes
> > in
> > > > an overlay model. The expertise for these layer is not all
> contained
> > > in
> > > > the IETF. I think we should put a plan forward to make this
happen
> > > > within the IETF process. After this was accomplished  I think
some
> > > > people are thinking of collapsing layers even more but the
logical
> > > > partitioning of layers may help keep the protocols and databases
> > > > simpler.   Right now were are treating GMPLS like a big bowl of
> > jelly
> > > > when it should look more like a layer cake.
> > > >
> > > > Regards,
> > > > Don
> > >
> > > --
> > > Alcatel Optical Network Division    Gert Grammel
> > > Network Strategy                    phone: +49 711 821 47368
> > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > D-70435 Stuttgart                   mailto:[email-masked]
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:[email-masked]
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Mon, 10 Mar 2003 08:33:25 -0800
Date: Mon, 10 Mar 2003 17:30:47 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: Ben Mack-Crane <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Label Set Object

ben,

Ben Mack-Crane wrote:
> 
> Dimitri,
> 
> As Ben stated, while 32 bit labels are (currently) the norm for CType 2,
> RFCs 3473 and 3471 indicate that the length is variable.  If this is the
> case a header is required to parse the subobjects.  If the length of
> CType 2 labels is fixed at 32 bits, the RFCs should be corrected to
> indicate this.

 each element (of the label set) is referred to as a subchannel 
 identifier and has the same format as a generalized label.

 the subchannel represents the label (wavelength, fiber ... ) which
 is eligible for allocation; each sub-field has the same format as
 described for the labels and the interpretation of the latter
 depends on the type of the link over which the label is to be used

 the point is that concomittantly any c-type 2 label values defined 
 today have a 32-bit length

thanks,
- dimitri.

> Regards,
> Ben Mack-Crane
> 
> [email-masked] wrote:
> <snip>
> >
> >>For 3 it is fixed, but for 2 it could be variable length, even though 32
> >>bits are currently the norm.
> >
> >
> > all C-Type 2 have a 32-bit length (except C-Type 3): port,
> > wavelength and tdm labels as well as generic mpls labels,
> > atm and frame relay labels are encoded right justified
> > aligned in 32 bits (4 octets)
> >
> <snip>
> 
> ============================================================
> 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
> ============================================================

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Mon, 10 Mar 2003 07:54:44 -0800
Date: Mon, 10 Mar 2003 10:54:12 -0500
To: Yakov Rekhter <[email-masked]>
From: Anca Zamfir <[email-masked]>
Subject: Re: Repost: RFC 3471: IF ID specification WRT component link. 
Cc: Sameer K <[email-masked]>, [email-masked], [email-masked]

Yakov,
At 07:37 AM 3/10/2003 -0800, Yakov Rekhter wrote:
>Anca,
>
> > Yakov,
> > What goes in the IF-ID RSVP_HOP TLVs if upstream and downstream directions
> > use different numbered component links?
>
>draft-ietf-mpls-bundle-04.txt does *not* support this.

It looks like draft-ietf-mpls-bundle-04.txt does not support different 
links (numbered or unnumbered) for the upstream and downstream directions.
On the other hand, RFC3471 seems to allow different unnumbered links for 
the upstream and downstream LSP directions, but no equivalent support for 
the numbered case, so it looks like a small inconsistency. Any reasons for 
this?

Thanks,
Anca

>Yakov.
>
> > Thanks,
> > Anca
> >
> > At 06:58 AM 3/10/2003 -0800, Yakov Rekhter wrote:
> > >Sameer,
> > >
> > > >
> > > > Reposting, as I did not get any response.  Could
> > > > someone please answer the question.
> > >
> > >from  draft-ietf-mpls-bundle-04.txt:
> > >
> > >    If the component link is numbered, the IF_ID RSVP_HOP object, or
> > >    IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6
> > >    address) TLVs (see [GMPLS-SIG]). The address carried in the TLV
> > >    identifies the link for which label allocation must be done.
> > >
> > >    If the component link is unnumbered, the IF_ID RSVP_HOP object, or
> > >    IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The
> > >    value carried in Type 3 TLV contains the identifier of the selected
> > >    component link assigned to the link by the sender of the Path/REQUEST
> > >    message. Processing this object is the same as specified in Section
> > >    "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV"
> > >    of [RSVP-UNNUM]/[CRLDP-UNNUM].
> > >
> > >Yakov.
> > >
> > > >
> > > > Thanks
> > > > - Sameer
> > > >
> > > > --- Sameer K <[email-masked]> wrote:
> > > > > Hello All,
> > > > >
> > > > > From the RFC 3471 - GMPLS Signaling Functional
> > > > > Description, Section 9.1.1, it appears that there is
> > > > > no way for upstream node, to specify component links
> > > > > that are numbered, in the IF-ID HOP object.
> > > > >
> > > > > The TLV format for IF-ID Types 4 and 5 assumes that
> > > > > the component link is always un-numbered.
> > > > >
> > > > > Is this the way it was planned to be?.  If yes, then
> > > > > what should IF-ID look like for numbered component
> > > > > link (which is a valid scenario per the Link
> > > > > Bundling
> > > > > draft).
> > > > >
> > > > > Or did I get it all wrong?
> > > > > TIA
> > > > > - Sameer
> > > > >
> > > > >
> > > > > __________________________________________________
> > > > > Do you Yahoo!?
> > > > > Yahoo! Tax Center - forms, calculators, tips, more
> > > > > http://taxes.yahoo.com/
> > > > >
> > > >
> > > >
> > > > __________________________________________________
> > > > Do you Yahoo!?
> > > > Yahoo! Tax Center - forms, calculators, tips, more
> > > > http://taxes.yahoo.com/
> > > >
> >
> > --------------------------------------------
> > Anca Zamfir                                Public Carrier IP
> > Cisco Systems, Inc.                    email: [email-masked]
> > 2000 Innovation Dr., Kanata          tel#: (613) 254-3484
> > Ontario, CANADA  K2K 3E8         fax:  (613) 254-3717
> >
> >
> >

--------------------------------------------
Anca Zamfir                                Public Carrier IP
Cisco Systems, Inc.                    email: [email-masked]
2000 Innovation Dr., Kanata          tel#: (613) 254-3484
Ontario, CANADA  K2K 3E8         fax:  (613) 254-3717

Delivery-date: Mon, 10 Mar 2003 07:38:03 -0800
To: Anca Zamfir <[email-masked]>
cc: Sameer K <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Repost: RFC 3471: IF ID specification WRT component link. 
Date: Mon, 10 Mar 2003 07:37:01 -0800
From: Yakov Rekhter <[email-masked]>

Anca,

> Yakov,
> What goes in the IF-ID RSVP_HOP TLVs if upstream and downstream directions 
> use different numbered component links?

draft-ietf-mpls-bundle-04.txt does *not* support this.

Yakov.

> Thanks,
> Anca
> 
> At 06:58 AM 3/10/2003 -0800, Yakov Rekhter wrote:
> >Sameer,
> >
> > >
> > > Reposting, as I did not get any response.  Could
> > > someone please answer the question.
> >
> >from  draft-ietf-mpls-bundle-04.txt:
> >
> >    If the component link is numbered, the IF_ID RSVP_HOP object, or
> >    IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6
> >    address) TLVs (see [GMPLS-SIG]). The address carried in the TLV
> >    identifies the link for which label allocation must be done.
> >
> >    If the component link is unnumbered, the IF_ID RSVP_HOP object, or
> >    IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The
> >    value carried in Type 3 TLV contains the identifier of the selected
> >    component link assigned to the link by the sender of the Path/REQUEST
> >    message. Processing this object is the same as specified in Section
> >    "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV"
> >    of [RSVP-UNNUM]/[CRLDP-UNNUM].
> >
> >Yakov.
> >
> > >
> > > Thanks
> > > - Sameer
> > >
> > > --- Sameer K <[email-masked]> wrote:
> > > > Hello All,
> > > >
> > > > From the RFC 3471 - GMPLS Signaling Functional
> > > > Description, Section 9.1.1, it appears that there is
> > > > no way for upstream node, to specify component links
> > > > that are numbered, in the IF-ID HOP object.
> > > >
> > > > The TLV format for IF-ID Types 4 and 5 assumes that
> > > > the component link is always un-numbered.
> > > >
> > > > Is this the way it was planned to be?.  If yes, then
> > > > what should IF-ID look like for numbered component
> > > > link (which is a valid scenario per the Link
> > > > Bundling
> > > > draft).
> > > >
> > > > Or did I get it all wrong?
> > > > TIA
> > > > - Sameer
> > > >
> > > >
> > > > __________________________________________________
> > > > Do you Yahoo!?
> > > > Yahoo! Tax Center - forms, calculators, tips, more
> > > > http://taxes.yahoo.com/
> > > >
> > >
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Tax Center - forms, calculators, tips, more
> > > http://taxes.yahoo.com/
> > >
> 
> --------------------------------------------
> Anca Zamfir                                Public Carrier IP
> Cisco Systems, Inc.                    email: [email-masked]
> 2000 Innovation Dr., Kanata          tel#: (613) 254-3484
> Ontario, CANADA  K2K 3E8         fax:  (613) 254-3717
>    
> 
> 

Delivery-date: Mon, 10 Mar 2003 07:35:23 -0800
Date: Mon, 10 Mar 2003 10:34:38 -0500
To: Yakov Rekhter <[email-masked]>
From: Anca Zamfir <[email-masked]>
Subject: Re: Repost: RFC 3471: IF ID specification WRT component link. 
Cc: Sameer K <[email-masked]>, [email-masked], [email-masked]

Yakov,
What goes in the IF-ID RSVP_HOP TLVs if upstream and downstream directions 
use different numbered component links?
Thanks,
Anca

At 06:58 AM 3/10/2003 -0800, Yakov Rekhter wrote:
>Sameer,
>
> >
> > Reposting, as I did not get any response.  Could
> > someone please answer the question.
>
>from  draft-ietf-mpls-bundle-04.txt:
>
>    If the component link is numbered, the IF_ID RSVP_HOP object, or
>    IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6
>    address) TLVs (see [GMPLS-SIG]). The address carried in the TLV
>    identifies the link for which label allocation must be done.
>
>    If the component link is unnumbered, the IF_ID RSVP_HOP object, or
>    IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The
>    value carried in Type 3 TLV contains the identifier of the selected
>    component link assigned to the link by the sender of the Path/REQUEST
>    message. Processing this object is the same as specified in Section
>    "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV"
>    of [RSVP-UNNUM]/[CRLDP-UNNUM].
>
>Yakov.
>
> >
> > Thanks
> > - Sameer
> >
> > --- Sameer K <[email-masked]> wrote:
> > > Hello All,
> > >
> > > From the RFC 3471 - GMPLS Signaling Functional
> > > Description, Section 9.1.1, it appears that there is
> > > no way for upstream node, to specify component links
> > > that are numbered, in the IF-ID HOP object.
> > >
> > > The TLV format for IF-ID Types 4 and 5 assumes that
> > > the component link is always un-numbered.
> > >
> > > Is this the way it was planned to be?.  If yes, then
> > > what should IF-ID look like for numbered component
> > > link (which is a valid scenario per the Link
> > > Bundling
> > > draft).
> > >
> > > Or did I get it all wrong?
> > > TIA
> > > - Sameer
> > >
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Tax Center - forms, calculators, tips, more
> > > http://taxes.yahoo.com/
> > >
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, more
> > http://taxes.yahoo.com/
> >

--------------------------------------------
Anca Zamfir                                Public Carrier IP
Cisco Systems, Inc.                    email: [email-masked]
2000 Innovation Dr., Kanata          tel#: (613) 254-3484
Ontario, CANADA  K2K 3E8         fax:  (613) 254-3717

Delivery-date: Mon, 10 Mar 2003 07:19:12 -0800
To: Manoj Agiwal <[email-masked]>
cc: "'Ccamp (E-mail)" <[email-masked]>
Subject: Re: Bundle Links 
Date: Mon, 10 Mar 2003 07:16:09 -0800
From: Yakov Rekhter <[email-masked]>

Manoj,

>         Consider a scenario where I am signaling the bidirectional
> connection request over a bundle link .
> 
>         Both my Upstream connection and Downstream connection are on the
> same link .
> 
>         In such a scenario what will my IF_ID RSVP_HOP object should carry .
> 
>          Will it carry object  Interface_Index ( Type = 3 ) , or  both
> Component_if_downstream  ( type 4 )and 
>           component_if_upstream ( type 5) .

>From  draft-ietf-mpls-bundle-04.txt:

   If the component link is unnumbered, the IF_ID RSVP_HOP object, or
   IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The
   value carried in Type 3 TLV contains the identifier of the selected
   component link assigned to the link by the sender of the Path/REQUEST
   message. Processing this object is the same as specified in Section
   "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV"
   of [RSVP-UNNUM]/[CRLDP-UNNUM].

Yakov.

Delivery-date: Mon, 10 Mar 2003 06:59:34 -0800
Date: Mon, 10 Mar 2003 09:58:58 -0500
To: Shahram Davari <[email-masked]>, [email-masked], [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: draft-iesg-vendor-extensions-00.txt

>Thanks, I am happy to hear that my proposal is in fact in-line with
>current IETF standardization process. However, my proposal is about allowing
>other SDOs to develop extensions to IETF protocols, even if IETF does
>not agree to those extension, while the iesg draft prohibits other SDOs from
>developing any extension to IETF protocols without IETF's approval.

         I personally happen to agree with the IESG on the last point.

         --Tom

>-Shahram
>
>
>
> >-----Original Message-----
> >From: Thomas D. Nadeau [mailto:[email-masked]]
> >Sent: Friday, March 07, 2003 12:43 PM
> >To: Shahram Davari; [email-masked]; [email-masked]
> >Subject: Re: draft-iesg-vendor-extensions-00.txt
> >
> >
> >
> >         I don't see how your proposal differs from the current
> >IETF standards process. How could extensions created by other
> >SDOs be considered IETF compliant without being passed through the
> >process within the IETF?  If they are passed through the processes and
> >are eventually approved as standards, then they are called
> >IETF compliant.
> >Where exactly do you see this as being broken and requiring
> >additional red
> >tape?
> >
> >         --Tom
> >
> >
> >>Hi All,
> >>
> >>I would like to make an alternative proposal to what is
> >proposed in this
> >>draft.
> >>I think that IETF should not prevent other SDOs from
> >developing extensions
> >>(minor or major),
> >>to IETF protocols, as long as they don't call those
> >extensions being IETF
> >>compliant.
> >>I think IETF could recommend that the other SDOs present
> >their protocol
> >>extensions
> >>to IETF (in the form of a draft). The IETF community then has
> >3 choices:
> >>1) IETF agrees with the requirements and nature of the
> >extensions and find
> >>them useful. In that case IETF could engage in technical
> >discussions with
> >>the other SDO and reach to a mutually agreeable draft, which
> >could then be
> >>advanced to Proposed Standard.
> >>
> >>2) IETF agrees with the requirement, but does not agree with
> >the proposed
> >>extension, and prefers other solutions/extensions that it thinks meet
> >>those requirements. In that case IETF could develop its solution and
> >>present it to the requesting SDO. If that SDO is satisfied with
> >>IETF's solution, then fine, otherwise nobody can prevent them from
> >>developing their own extension. If that happens then there
> >would be two
> >>solutions for the same requirements
> >>and we should let the Market decide which solution/extension
> >do they prefer.
> >>
> >>3) IETF does not agree with the requirement for such
> >extensions at all. In
> >>that case, the
> >>other SDO should be free to developed their own extension,
> >provided they
> >>don't call those extensions to be IETF compliant.
> >>
> >>
> >>
> >>Thanks,
> >>-Shahram
> >
> >

Delivery-date: Mon, 10 Mar 2003 06:59:19 -0800
To: Sameer K <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Repost: RFC 3471: IF ID specification WRT component link. 
Date: Mon, 10 Mar 2003 06:58:44 -0800
From: Yakov Rekhter <[email-masked]>

Sameer,

> 
> Reposting, as I did not get any response.  Could
> someone please answer the question.

from  draft-ietf-mpls-bundle-04.txt:

   If the component link is numbered, the IF_ID RSVP_HOP object, or 
   IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6
   address) TLVs (see [GMPLS-SIG]). The address carried in the TLV
   identifies the link for which label allocation must be done.
   
   If the component link is unnumbered, the IF_ID RSVP_HOP object, or
   IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The
   value carried in Type 3 TLV contains the identifier of the selected
   component link assigned to the link by the sender of the Path/REQUEST
   message. Processing this object is the same as specified in Section
   "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV"
   of [RSVP-UNNUM]/[CRLDP-UNNUM].

Yakov.

> 
> Thanks
> - Sameer
> 
> --- Sameer K <[email-masked]> wrote:
> > Hello All,
> > 
> > From the RFC 3471 - GMPLS Signaling Functional
> > Description, Section 9.1.1, it appears that there is
> > no way for upstream node, to specify component links
> > that are numbered, in the IF-ID HOP object.
> > 
> > The TLV format for IF-ID Types 4 and 5 assumes that
> > the component link is always un-numbered.
> > 
> > Is this the way it was planned to be?.  If yes, then
> > what should IF-ID look like for numbered component
> > link (which is a valid scenario per the Link
> > Bundling
> > draft).
> > 
> > Or did I get it all wrong?
> > TIA
> > - Sameer
> > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, more
> > http://taxes.yahoo.com/
> > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> 

Delivery-date: Mon, 10 Mar 2003 06:49:41 -0800
Date: Mon, 10 Mar 2003 08:46:10 -0600
From: Ben Mack-Crane <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Label Set Object

Dimitri,

As Ben stated, while 32 bit labels are (currently) the norm for CType 2, 
RFCs 3473 and 3471 indicate that the length is variable.  If this is the 
  case a header is required to parse the subobjects.  If the length of 
CType 2 labels is fixed at 32 bits, the RFCs should be corrected to 
indicate this.

Regards,
Ben Mack-Crane

[email-masked] wrote:
<snip>
> 
>>For 3 it is fixed, but for 2 it could be variable length, even though 32
>>bits are currently the norm.
> 
> 
> all C-Type 2 have a 32-bit length (except C-Type 3): port,
> wavelength and tdm labels as well as generic mpls labels,
> atm and frame relay labels are encoded right justified 
> aligned in 32 bits (4 octets)
> 
<snip>

============================================================
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: Mon, 10 Mar 2003 06:06:54 -0800
Date: Mon, 10 Mar 2003 23:04:39 +0900
To: [email-masked]
From: MATSUURA Nobuaki <[email-masked]>
Subject: Upstream LSPs

Hi,

According to the gmpls-rsvp standard documents, an upstream LSP is established
before RSBs are built on nodes along the path. In other words, upstream LSPs are
based on only PSBs and maintained by refresh Path massages. 
So in a case of failed RSBs, upstream LSPs that are implemented by the protocol
(not an operational policy) would remain. Is it a problem should be fixed?

I think it is rather meaningful to use this for unidirectional LSPs as a normal status.
Please take a look at
http://www.ietf.org/internet-drafts/draft-matsuura-reverse-lsp-02.txt

Thanks,

Nobuaki

Delivery-date: Mon, 10 Mar 2003 04:25:10 -0800
Date: Mon, 10 Mar 2003 13:24:06 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: {Possible Spam} Re: I-D  ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Curtis,

you've wrote:

     It would be best if ITU members go off and waste their own time
     pursuing ASON capabilities, just as the ATM Forum went off and wasted
     their time on Q.2931 capability in UNI 3.x, 4.x, ...

and I don't agree with that. In my view it would be best if ITU-T members were
able to understand and accept the ideas behind GMPLS and would provide valuable
input to bring this work forward.

Regards

Gert

Curtis Villamizar wrote:

> Coments inline.
>
> In message <[email-masked]>, Gert Grammel writes:
> >
> > Mark,
> >
> > 'improving the coordination between the IETF and ITU-T' is one of the
> > things I' d like to see since years. However in my experience the true
> > barrier between both groups is not so much the technology as such, but
> > some ignorance about the core aspects in both organizations. To give a
> > balanced figure here:
> >
> >   1. You remember the thread about the non-standard SDH/SONET
> >      extensions. Here some guys active in GMPLS tried to push their
> >      ideas about transparency.  Obviously this was perceived on ITU-T
> >      side as a challenge on the purity of a standard (G.707). This one
> >      was (almost) setteled by moving all non-standard features to an
> >      informal draft.
> >
> >   2. Now it is the other way round. Somehow ITU-T extensions got
> >      accepted (agai n informational) in IETF which do not comply to
> >      the purity of RSVP-TE. Due t o the fact that this informational
> >      RFC was not reviewed in CCAMP before, it is perceived as an
> >      assault.
> >
> > So the match is tied up 1:1 but maybe it's now the right time to find
> > a solutio n on how to proceed. What I've seen so far was a complete
> > misperception of what i s required on either side and why.
> >
> >   1. ITU-T basically started by defining user services having in mind
> >      layered transport platforms like OTH and SDH/SONET. Those
> >      services can be summarized as 'Bandwidth on Demand' services
> >      (BOND). Naturally this led to a very strong focus on UNI
> >      interfaces and a kind of ignorance of networkin g protocols. You
> >      probably remember the discussions on why not using SS7? (For
> >      those not familar with the issue: SS7 is the signaling protocol
> >      between PSTN switches)
>
> SDH/SONET bandwidth on demand has never been deployed.  There is
> serious question about whether this is a viable service.  The
> technology has existed for about a decade (a little less maybe) for
> provide ATM SVC service doing essentially the same thing.  Market
> penetration after a decade is very close to zero for SVC.  Market
> penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> market seems to be shrinking as well.  FR SVC market is zero.
> SDH/SONET does not have the bandwidth on demand capability but there
> is ample evidence that implementing it would be a waste of time.
>
> ASON is a requirements document from ITU that assumes the SDH/SONET
> BOND is a viable service.  This is an enormous leap of faith given the
> trends in the market.  The IETF doesn't buy into it.
>
> And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
> mess, so if you want to extend TCAP to support ASON, go right ahead.
> We in the IETF would get a real good laugh over that.
>
> >   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE, ...)
> >      and extending their scope to L1 technologies namely SDH/SONET and
> >      OTH.  Naturally this led to a very strong focus on protocol
> >      consistency and a kind of ignorance on service aspects other than
> >      those already available in MPLS. You may remember here the
> >      discussion about whether UNI is useful at all some time ago.
>
> Initially IP and voice ran over TDM.  The bandwidth demands of IP were
> much less than voice a decade ago.  As IP penetration grew roughly
> exponentially through the early, mid, and most of the late 1990s, this
> reversed and IP consumed far more bandwidth than voice.  Switched
> services also grew but at a slower rate and in the late 1990s
> experienced negative growth for many SPs.  One factor may have been
> notable outages in FR (US nationwide one day at one major provider and
> intermittent for 10 days in another a few years later) shot a big hole
> in the "much more reliable than IP" story.
>
> Initially MPLS served as traffic enginnering strictly for IP.  With IP
> still growing substantially, voice growing very slowly (and losing
> revenue) and switched services growing slowly to shrinking, there was
> motivation to carry voice, switched services, and leased line services
> over the IP and/or MPLS infrastructure and decommission older
> SDH/SONET ADM and FR or ATM switches.  This led to the tunneling work.
>
> Another factor which led to GMPLS was the (unrealized) promise/hype of
> optical switching in the very late 1990s.  IP over an ATM overlay was
> a poor design and IP providers did not want to repeat that mistake so
> the control of the underlying optical domain was accommodated by what
> has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
> addition to FSC, LSC and PSC.
>
> > So putting everything together means that it is required to keep
> > (IETF) protocol consistency but adding some (ITU-T) specific
> > extensions to well defined service points in the network (UNI).
> > Unfortunately service points tend to exchange messages between
> > themselves and this would mean that an intermediate protocol would
> > have had to support such kind of communication. What concerns the IETF
> > community is probably not the fact that there is a UNI somewhere, but
> > the changes and extensions to etablished protocols in order to achieve
> > a collaboration between them.
>
> ASON was never accepted by the IETF as requirements and for very good
> reason.  To say that IETF must accept the ASON requirements simply
> because they came in a liason statement and that the IETF must
> accommodate this ITU folly is absurd.
>
> > I recall that this was the basic issue with the ITU-T proposal when it
> > was presented for the first time in Yokohama. The way I've got
> > Kireeti's message there was: please authors try to let us understand
> > what problem you want to solve and tell us which kind of information
> > you have to exchange between which points to achieve it. We'll sort
> > out then in CCAMP what would be the most appropriate way to implement
> > it, while maintaining consistency in our protocols .
>
> Regardless of how this was handled in Yokohama, some of the
> fundamental premise of ASON is flawed.  It would be best if ITU
> members go off and waste their own time pursuing ASON capabilities,
> just as the ATM Forum went off and wasted their time on Q.2931
> capability in UNI 3.x, 4.x, but ITU should do so without extending
> protocols which originated in the IETF.
>
> > Although it didn't work the first time I still consider Kireeti's
> > suggestion to be a wise way to move forward and perhaps the key for
> > harmonic collaboration.
> >
> > Regards
> >
> > Gert
>
> I look forward to seeing the IETF come up with a formal statement of
> liason policy.  It would be useful to have explicitly documented that
> liason statements carry no more weight than any individual
> internet-draft submission.
>
> Curtis

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Mon, 10 Mar 2003 04:20:35 -0800
Date: Mon, 10 Mar 2003 13:18:45 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: "Lazer, Monica A, ALABS" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Monica,

I think there were lots of discussions about what is best for layer XYZ and also
Neil was arguing in this direction. This argumentation is of course valid if you
focus on layer XYZ and look for a (new) control plane. Let's name it a classical
ASON point ov view. What I tried to raise as an issue is, that from a CCAMP
point of view the question is the other way round. You have already a control
plane defined and the question is: how to apply it in the best way to layer XYZ?

So coming back to your argument. You've said correctly:

     ... while when going from HO to LO one is within the same paradigm.

One conclusion could be: you should use the same Control Plane paradigm for
different layers in order to let them interoperate seamlessly.

To sum up a bit: in my view all the discussion about features of ASON and/or
GMPLS is flawed right from the beginning if it is not clear what should be
achieved:

  1. If you focus on a single paradigm arcoss layers you should consider GMPLS
     with all its features and limitations
  2. If you are interesting on getting some specialized control planes for
     SDH/SONET you are free to choose anything.

in ITU-T you have the choice, in IETF you have not. For sure the choice is not
between transport and packet technology, the choice is your focus.

Regards

Gert

"Lazer, Monica A, ALABS" wrote:

> Gert,
> I think that one of the main drivers of the different needs when going
> from L1 to L2 is the fact L1, in SONET is TDM-based, while L2 can be
> packet based and have a different paradigm, while when going from HO to
> LO one is within the same paradigm. So, point 1 indicates that one
> should consider using the same control plane architecture for the
> sublayers within L1, but it does not necessarily support the idea that
> the same paradigm is best for both L1 and higher layers.  Regarding the
> backbone/regional structure, more than only 2 levels may be needed for
> global transport networks.
>
> Regards,
>
> Monica A. Lazer
> Network Architecture and Reliability
>
> 908 234 8462
> [email-masked]
>
> -----Original Message-----
> From: Gert Grammel [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 3:38 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Ash, Gerald R
> (Jerry), ALABS; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Mark,
>
> I am happy to read that we could find some common understanding. About
> your
> multi-layer issue you've raised, I suggest to figure out more to which
> extend
> this is an issue for UNI. Some thoughts on that:
>
>   1. Wideband Crossconnects are able to crossconnect low order circuits
> (LO),
>      and put them into high order circuits (HO). Those Crossconnects are
> managed
>      by one manager able to control both Layers: LO and HO. I've never
> heard
>      that an operator let one part of the organization implement HO only
> on a
>      country wide basis, while another part of the organization is
> taking care
>      about LO only.
>   2. So rather than the pure layering, a kind of regional/backbone
> structure is
>      in place. Regional NOCs deal with HO and LO whithin the region
> while in
>      backbone you use HO only because you don't need the finer
> granularity
>      there. So what appears to be a layering from a management point of
> view
>      seems to me more a regional kind of separation.
>
> To be clear: I don't want to discuss the fact that there is a layering
> in the
> network. My point is to highlight that SDH/SONET is in reality not a
> single
> layer but has at least 4 of them (RS, MS, LO, HO). In theory we should
> find in
> the network an RS-manager, an MS-Manager, a LO-Manager and a HO-Manager.
> Moreover a single Wideband Crossconnect would have had to be managed by
> all 4
> managers at the same time. Obviously this is not really practical
> (immagine: 4
> managers, one worker ;-) such that most vendors and carriers decided to
> put all
> 4 layers into one management box - quite similar to what a GMPLS Control
> Plane
> does with SONET/SDH control.
>
> Just to avoid misunderstandings here: I don't want to start a new thread
> on
> layering issues. I just want to provide you some food for your own
> thoughts
> hoping that we can find some common understanding at some point in
> future.
>
> Regards
>
> Gert
>
> [email-masked] wrote:
>
> > Gert,
> >
> > Thanks for outlining the history and your current position for going
> > forward.  Mostly, I agree with you.
> >
> > My major point of disagreement is with your characterization of the
> > ITU-T direction.  Though the ITU-T ASON documents might enable
> > "'Bandwidth on Demand' services (BOND)" to some degree, that was not
> the
> > primary focus.  The Optical UNI was a development that came out of the
> > OIF and not the ITU-T.  Most carriers have seen the Optical UNI as a
> > potential customer interface with far more realistic applications
> > internal to networks, i.e. between the L3/L2 elements and the L1/L0
> > elements.  Those who have attended the OIF in the past probably
> remember
> > my unpopular statement on the plenary floor that we were wasting out
> > time working on a UNI that had questionable (no?) business advantages
> > for the carrier.
> >
> > I do support the approach you mention (from Kireeti?) that we focus on
> > the service points and the information that needs to be exchanged
> > between them.  Where most of the services are of the L3/L2 variety,
> that
> > approach should be successful.  Those items should be fully covered by
> > the IETF solutions.
> >
> > However, that doesn't address the multi-layer issue that we are
> > struggling to address, which is one of the root causes of this
> conflict
> > between the IETF and ITU-T.  The signaling/control for L1/L0 is where
> > the ITU-T participants have found the IETF solutions to be inadequate.
> > That's not necessarily because the IETF solutions wouldn't work, but
> > because they would not satisfy the stringent requirements and models
> by
> > which we base our management and control for L1/L0.
> >
> > This whole problem could be blamed on the IP success in the industry.
> > If IP had not proven to be so successful, the ITU-T might have chosen
> > the optical control plane based on extensions to SS7.  :-)  (Not
> meaning
> > to ignore the ITU-T alternative solution based on PNNI.)
> >
> > Regards,
> >
> > Mark Loyd Jones
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: Gert.Grammel [mailto:[email-masked]]
> > Sent: Thursday, March 06, 2003 1:21 PM
> > To: Mark.Jones
> > Cc: ccamp; dwfedyk; gash; mpls
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Mark,
> >
> > 'improving the coordination between the IETF and ITU-T' is one of the
> > things I'd
> > like to see since years. However in my experience the true barrier
> > between both
> > groups is not so much the technology as such, but some ignorance about
> > the core
> > aspects in both organizations. To give a balanced figure here:
> >
> >   1. You remember the thread about the non-standard SDH/SONET
> > extensions. Here
> >      some guys active in GMPLS tried to push their ideas about
> > transparency.
> >      Obviously this was perceived on ITU-T side as a challenge on the
> > purity of
> >      a standard (G.707). This one was (almost) setteled by moving all
> >      non-standard features to an informal draft.
> >   2. Now it is the other way round. Somehow ITU-T extensions got
> > accepted (again
> >      informational) in IETF which do not comply to the purity of
> > RSVP-TE. Due to
> >      the fact that this informational RFC was not reviewed in CCAMP
> > before, it
> >      is perceived as an assault.
> >
> > So the match is tied up 1:1 but maybe it's now the right time to find
> a
> > solution
> > on how to proceed. What I've seen so far was a complete misperception
> of
> > what is
> > required on either side and why.
> >
> >   1. ITU-T basically started by defining user services having in mind
> > layered
> >      transport platforms like OTH and SDH/SONET. Those services can be
> >      summarized as 'Bandwidth on Demand' services (BOND). Naturally
> this
> > led to
> >      a very strong focus on UNI interfaces and a kind of ignorance of
> > networking
> >      protocols. You probably remember the discussions on why not using
> > SS7? (For
> >      those not familar with the issue: SS7 is the signaling protocol
> > between
> >      PSTN switches)
> >   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE, ...)
> > and
> >      extending their scope to L1 technologies namely SDH/SONET and
> OTH.
> >      Naturally this led to a very strong focus on protocol consistency
> > and a
> >      kind of ignorance on service aspects other than those already
> > available in
> >      MPLS. You may remember here the discussion about whether UNI is
> > useful at
> >      all some time ago.
> >
> > So putting everything together means that it is required to keep
> (IETF)
> > protocol
> > consistency but adding some (ITU-T) specific extensions to well
> defined
> > service
> > points in the network (UNI).
> > Unfortunately service points tend to exchange messages between
> > themselves and
> > this would mean that an intermediate protocol would have had to
> support
> > such
> > kind of communication. What concerns the IETF community is probably
> not
> > the fact
> > that there is a UNI somewhere, but the changes and extensions to
> > etablished
> > protocols in order to achieve a collaboration between them.
> >
> > I recall that this was the basic issue with the ITU-T proposal when it
> > was
> > presented for the first time in Yokohama. The way I've got Kireeti's
> > message
> > there was: please authors try to let us understand what problem you
> want
> > to
> > solve and tell us which kind of information you have to exchange
> between
> > which
> > points to achieve it. We'll sort out then in CCAMP what would be the
> > most
> > appropriate way to implement it, while maintaining consistency in our
> > protocols.
> >
> > Although it didn't work the first time I still consider Kireeti's
> > suggestion to
> > be a wise way to move forward and perhaps the key for harmonic
> > collaboration.
> >
> > Regards
> >
> > Gert
> >
> > [email-masked] wrote:
> >
> > > Gert,
> > >
> > > I agreed with the intent in generalizing MPLS for the wide range of
> > > expected applications.  It was my hope that it would succeed.  At
> this
> > > point, one might say that the intent has only been partially
> achieved.
> > > The problem that has come to light over the past year is the fact
> that
> > > there are finer points of the ITU-T model and requirements that are
> > not
> > > supported by the current IETF GMPLS RFCs and standards track drafts.
> > > Those aspects are considered significant enough by many carriers and
> > > their suppliers to warrant further extensions outside of the IETF.
> > (My
> > > apologies for not understanding those points well enough to clarify
> > them
> > > even in examples, but there are many people on this list would could
> > do
> > > so if they thought it necessary.  To avoid any misunderstand, all
> > should
> > > know that Sprint does not yet have a company position on this.)  It
> is
> > > my hope that we can come up with ways of improving the coordination
> > > between the IETF and ITU-T.  This thread of discussion is bringing
> out
> > > the issues to make that happen.
> > >
> > > Regards,
> > >
> > > Mark Loyd Jones
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: Gert.Grammel [mailto:[email-masked]]
> > > Sent: Thursday, March 06, 2003 10:17 AM
> > > To: Mark.Jones
> > > Cc: dwfedyk; gash; ccamp; mpls
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > Mark,
> > >
> > > please don't forget that due to the 'Generalization' of GMPLS you
> are
> > > free to do
> > > the split at any application level you wish. This was always the
> > > advantage of
> > > the GMPLS approach compared to the ITU-T model where initially each
> > > layer had
> > > its own control plane. So the fact that in theory you could use a
> > single
> > > control
> > > plane for all your network means also that you are able to stop
> where
> > > you want.
> > > Nice feature isn't it?
> > >
> > > Regards
> > >
> > > Gert
> > >
> > > [email-masked] wrote:
> > >
> > > > I agree with the separation of GMPLS into the two applications.
> > There
> > > > does not appear to be any significant move to collapse the
> > management
> > > or
> > > > signaling for L3/2 and L1/0 at this time, given the different
> models
> > > > that apply for them and the infrastructures in our companies that
> > > manage
> > > > them.  The plan for addressing the two applications need not be
> the
> > > > same.
> > > >
> > > > The L3/2 application is near and dear to the heart of the IETF.
> The
> > > > L1/0 application is of interest to those who wish to collapse the
> > > > management into a single layer.  In my opinion, the IETF might
> also
> > > > address this approach, given the IETF participants are the ones in
> > > > support of this collapsed management or at least common protocol
> > > > solution for what is today two signaling layers.  However, as
> stated
> > > > before, the collapse approach is not realistic today for a
> > > > multi-service, multi-protocol network.
> > > >
> > > > On the other hand, the L1/0 application requirements and models
> have
> > > > been defined and are best understood at the ITU-T.  Ideally, the
> > > > protocol expertise at the IETF would be applied to the ITU-T model
> > and
> > > > requirements to address the L1/0 application, but attempts to do
> > that
> > > > have been met with great resistance in the past.  Perhaps that was
> a
> > > > result of the fact that GMPLS implementations were not separated
> out
> > > > into the two different applications.  However, I don't think it is
> > > > realistic to expect the IETF experts to be motivated to understand
> > the
> > > > ITU-T models and requirements, given the application is outside of
> > > their
> > > > primary area of interest.  That said, I believe the IETF should
> > reach
> > > an
> > > > agreement on how to work with outside groups that develop "major
> > > > extensions" to the protocol.
> > > >
> > > > Mark Loyd Jones
> > > > Optical Transport and Networking
> > > > Sprint - Wireline Technology Development
> > > > 913-794-2139
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: dwfedyk [mailto:[email-masked]]
> > > > Sent: Thursday, March 06, 2003 7:49 AM
> > > > To: gash
> > > > Cc: mpls; ccamp
> > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > > >
> > > > Along the lines of Jerry's comments.
> > > >
> > > > When we put together GMPLS the first drafts were under specified
> > > > intentionally to capture the essence of GMPLS. We put aside many
> > > > arguments saying lets specify at a high level and fill in the
> > details
> > > > later. The discussions on this thread are in two major veins one
> > > > attempting to fill the details and the other containing and
> > > controlling
> > > > the changes. GMPLS needs to be specified more accurately and in my
> > > > opinion it needs to be decomposed to a more layered approach.  I
> > think
> > > > if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> > > > independently but self similar it would offer a mechanism to move
> > > > forward where some legacy systems could be specified to be GMPLS
> > > > friendly. For example signaling for Layer 3/2 can be tunneled
> > through
> > > > the a lower layer. We already have some work in this direction.
> > > >  Similarly traffic engineering information for L1/L0 in a TE
> > database
> > > >  would need different  attributes than a the TE database at L3/2.
> I
> > > > don't think you want to burden a L3/L2 system with these
> attributes
> > in
> > > > an overlay model. The expertise for these layer is not all
> contained
> > > in
> > > > the IETF. I think we should put a plan forward to make this happen
> > > > within the IETF process. After this was accomplished  I think some
> > > > people are thinking of collapsing layers even more but the logical
> > > > partitioning of layers may help keep the protocols and databases
> > > > simpler.   Right now were are treating GMPLS like a big bowl of
> > jelly
> > > > when it should look more like a layer cake.
> > > >
> > > > Regards,
> > > > Don
> > >
> > > --
> > > Alcatel Optical Network Division    Gert Grammel
> > > Network Strategy                    phone: +49 711 821 47368
> > > Lorenzstrasse 10                    fax: +49 711 821 43169
> > > D-70435 Stuttgart                   mailto:[email-masked]
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:[email-masked]
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Mon, 10 Mar 2003 02:05:46 -0800
Date: Mon, 10 Mar 2003 11:02:43 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: [email-masked]
CC: [email-masked]
Subject: Re: Label Set Object

ben,

> 2. the Label Type and Length fields from the Label Set object header imply
> the lengths of the subchannels and therefore no extra headers are needed
> for the subchannels (as is the case in ERO and RRO subobjects).

the label type field allows to know the length of each sub-entity
these values are processed wrt to the action field; also remember
that the generalized label does not identify its "type" instead, 
the nodes are expected to know from the context what type of label 
to expect
 
> What is the definition of "Label Type"?  C-types 2 and 3 for generalized
> label objects and waveband label objects respectively?

indicates the type and format of the labels carried in the object;
values match the C-Type of the appropriate rsvp_label object

only the low order 8 bits are used in this field; all info can be 
derived from this

> For 3 it is fixed, but for 2 it could be variable length, even though 32
> bits are currently the norm.

all C-Type 2 have a 32-bit length (except C-Type 3): port,
wavelength and tdm labels as well as generic mpls labels,
atm and frame relay labels are encoded right justified 
aligned in 32 bits (4 octets)

> This should be more clearly defined.

it is clearly defined i think, in brief no "extra object
header is needed"

thanks,
- dimitri.

[email-masked] wrote:
> 
> Hello,
> 
> There is currently a hot argument over the definition of "subchannel"
> text in the definition of the label set object in RFC 3473.
> 
> Does each subchannel contain a complete generalized label object with a
> complete header?  There are 2 arguments here:
> 
> 1. each generalized object is variable length field, thus each subchannel
> must have an embeded generalized label object.  This will solve the
> variable length feature.
> 
> 2. the Label Type and Length fields from the Label Set object header imply
> the lengths of the subchannels and therefore no extra headers are needed
> for the subchannels (as is the case in ERO and RRO subobjects).
> 
> What is the definition of "Label Type"?  C-types 2 and 3 for generalized
> label objects and waveband label objects respectively?
> 
> For 3 it is fixed, but for 2 it could be variable length, even though 32
> bits are currently the norm.
> 
> This should be more clearly defined.
> 
> Thanks,
> -Ben

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Sun, 09 Mar 2003 14:08:36 -0800
Date: Sun, 9 Mar 2003 17:05:15 -0500 (EST)
From: [email-masked]
To: [email-masked]
Subject: Label Set Object

Hello,

There is currently a hot argument over the definition of "subchannel"
text in the definition of the label set object in RFC 3473.

Does each subchannel contain a complete generalized label object with a
complete header?  There are 2 arguments here:

1. each generalized object is variable length field, thus each subchannel
must have an embeded generalized label object.  This will solve the
variable length feature.

2. the Label Type and Length fields from the Label Set object header imply
the lengths of the subchannels and therefore no extra headers are needed
for the subchannels (as is the case in ERO and RRO subobjects).

What is the definition of "Label Type"?  C-types 2 and 3 for generalized
label objects and waveband label objects respectively?

For 3 it is fixed, but for 2 it could be variable length, even though 32
bits are currently the norm.

This should be more clearly defined.

Thanks,
-Ben

Delivery-date: Fri, 07 Mar 2003 17:35:07 -0800
Date: Sat, 08 Mar 2003 02:32:30 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: "[email-masked]" <[email-masked]>
Subject: protection and restoration design team - status report

ccamp'ers,

the progress of the gmpls protection and restoration design
team were as follows since the last meeting:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-01.txt 

- waiting for other i-d's completion to finalize (on hold)
  => still to be provided: the definitions of protection and 
     restorations schemes (to be delivered when other documents 
     settled)
- category: info or ps (?)
- wg milestone: july'03

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-00.txt 

- editorial and text updates 
  review of section 8.4.1 and 8.4.2
  review of section 9
- category: info
- wg milestone: june'03

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-00.txt 

- editorial and text updates 
- category: ps
- wg milestone: april'03 

http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt

- describes protocol specific procedures for gmpls rsvp-te
  signaling extensions to support end-to-end lsp protection 
  and restoration  
- category: ps
- wg milestone: july'03

---

any feedback is very welcome, 
- dimiti (for the p&r dt)

Delivery-date: Fri, 07 Mar 2003 12:48:08 -0800
Date: Fri, 07 Mar 2003 12:46:47 -0800
To: [email-masked]
From: Peter Czezowski <[email-masked]>
Subject: Re: CCAMP 56 agenda

Hello Ron and Kireeti:

On behalf of the authors, I request a 10-15 minute agenda slot for the 
discussion of:

Optical Network Failure Recovery Requirements
http://www.ietf.org/internet-drafts/draft-czezowski-optical-recovery-reqs-01.txt,
Fault Notification Protocol for GMPLS-Based Recovery
http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol-02.txt,
and if it appears in the I-D repository on time (was submitted prior to -00 
deadline)
Extensions to LMP for Flooding-based Fault Notification
draft-soumiya-lmp-fault-notification-ext-00.txt

I also encourage the CCAMP'ers to send comments about these drafts to the 
mailing list.

Best regards,
Peter Czezowski

At 09:55 PM 3/1/03 -0800, Kireeti Kompella wrote:
>Hi,
>
>If you would like to speak at the CCAMP WG at the 56th IETF, please
>reply to this email -- that will help the chairs track requests.
>Also, please state which Internet draft(s) form the basis of the
>talk that others may come prepared.
>
>Note: these are *not* presentations, expositions, or tutorials.
>A small number of slides that say what has changed *since the
>last IETF*, issues that were raised in the interim, and resolutions
>to those issues is the ideal.  If there hasn't been a discussion
>on the mailing list, in many cases that is a sign that the topic
>isn't (yet) ready for prime time.
>
>Thanks,
>Ron and Kireeti.

Delivery-date: Fri, 07 Mar 2003 12:36:09 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-iwata-mpls-crankback-05.txt
Date: Fri, 07 Mar 2003 15:33:10 -0500

--NextPart

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

	Title		: Crankback Routing Extensions for MPLS Signaling
	Author(s)	: A. Farrel, A. Iwata
	Filename	: draft-iwata-mpls-crankback-05.txt
	Pages		: 29
	Date		: 2003-3-7
	
Recently, several routing protocol extensions for
advertising resource information in addition to topology
information have been proposed for use in distributed
constraint-based routing.  In such a distributed routing
environment, however, the information used to compute a
constraint-based path may be out of date.  This means
that LSP setup requests may be blocked by links or nodes
without sufficient resources.
This draft specifies crankback routing extensions for use
in Multi-Protocol Label Switching (MPLS) signaling using
RSVP-TE as defined in 'RSVP-TE: Extensions to RSVP for
LSP Tunnels', RFC3209, so that the LSP setup request can
be retried on an alternate path that detours around the
blocked link or node upon a setup failure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-iwata-mpls-crankback-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-iwata-mpls-crankback-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-iwata-mpls-crankback-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-iwata-mpls-crankback-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: Fri, 07 Mar 2003 11:57:10 -0800
Date: Fri, 07 Mar 2003 14:56:36 -0500
To: [email-masked]
From: Anca Zamfir <[email-masked]>
Subject: Re: Fwd: Re: Repost: RFC 3471: IF ID specification WRT component link.
Cc: Sameer K <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

<html>
Hi,<br>
Actually, I need to make a correction. The lack of ERO does not require
the bundled TE link Id to be specified in the IF-ID HOP since the
component link id (numbered or unnumbered) is unique per node.<br>
Thanks,<br>
Anca<br>
p.s. I corrected the text below<br>
<br>
At 02:36 PM 3/7/2003 -0500, Anca Zamfir wrote:<br>
<blockquote type=cite cite>Sameer,<br>
I think you are right, currently there is no way to specify a numbered
component link in the IF-ID HOP object. Also, AFAIK the ERO is not a
mandatory object so because of this both TE Link and component link
should be specified in the IF-ID HOP.<br>
If the following text would be added to the draft, it could IMO solve
these issues. Comments?<br>
<br>
&quot;Added in RFC-3471 - Section 9.1.1. or added to the bundle draft-
Proposed Changes:<br>
<br>
<font face="Courier, Courier">Type Length Format Description<br>
--------------------------------------------------------------------<br>
1&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4<br>
2&nbsp;&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6<br>
3&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below IF_INDEX
(Interface Index)<br>
4&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below
COMPONENT_IF_DOWNSTREAM (Component interface)<br>
5&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below
COMPONENT_IF_UPSTREAM (Component interface)<br>
<b>6&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4 -
DOWNSTREAM (Component interface)&nbsp;&nbsp;&nbsp; ---&gt; new<br>
7&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4 - UPSTREAM
(Component interface)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;
----&gt; new<br>
8&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6 - DOWNSTREAM
(Component interface)&nbsp;&nbsp;&nbsp; ----&gt; new<br>
9&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6 - UPSTREAM
(Component interface)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ----&gt; new<br>
<br>
Types 1-3 are used to identify an unbundled TE
Link<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;
----&gt; new<br>
Types 3-9 are used to identify the component interfaces in the&nbsp;
----&gt; new<br>
case of a bundled TE Link. <br>
<br>
<br>
</b></font>This being said, maybe the authors of the bundle draft and
RFC3471 could help to answer the following:<br>
&nbsp;&nbsp; - are these issues valid<br>
&nbsp;&nbsp; - is the proposed change good<br>
&nbsp;&nbsp; - how could the specification be fixed<br>
<br>
Thanks,<br>
Anca<br>
<br>
At 01:28 AM 3/7/2003 -0800, Sameer K wrote:<br>
<br>
<blockquote type=cite cite>Reposting, as I did not get any
response.&nbsp; Could<br>
someone please answer the question.<br>
<br>
Thanks<br>
- Sameer<br>
<br>
--- Sameer K &lt;[email-masked]&gt; wrote:<br>
&gt; Hello All,<br>
&gt; <br>
&gt; From the RFC 3471 - GMPLS Signaling Functional<br>
&gt; Description, Section 9.1.1, it appears that there is<br>
&gt; no way for upstream node, to specify component links<br>
&gt; that are numbered, in the IF-ID HOP object.<br>
&gt; <br>
&gt; The TLV format for IF-ID Types 4 and 5 assumes that<br>
&gt; the component link is always un-numbered.<br>
&gt; <br>
&gt; Is this the way it was planned to be?.&nbsp; If yes, then<br>
&gt; what should IF-ID look like for numbered component<br>
&gt; link (which is a valid scenario per the Link<br>
&gt; Bundling<br>
&gt; draft).<br>
&gt; <br>
&gt; Or did I get it all wrong?<br>
&gt; TIA<br>
&gt; - Sameer<br>
&gt; <br>
&gt; <br>
&gt; __________________________________________________<br>
&gt; Do you Yahoo!?<br>
&gt; Yahoo! Tax Center - forms, calculators, tips, more<br>
&gt;
<a href="http://taxes.yahoo.com/" eudora="autourl">http://taxes.yahoo.com/</a><br>
&gt; <br>
<br>
<br>
__________________________________________________<br>
Do you Yahoo!?<br>
Yahoo! Tax Center - forms, calculators, tips, more<br>
<a href="http://taxes.yahoo.com/" eudora="autourl">http://taxes.yahoo.com/</a></blockquote><br>
<font face="Courier New, Courier">--------------------------------------------<br>
</font><font face="Times New Roman CE, Times">Anca
Zamfir&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Public Carrier IP <br>
Cisco Systems,
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
email: [email-masked]<br>
2000 Innovation Dr.,
Kanata&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tel#: (613)
254-3484 <br>
Ontario, CANADA&nbsp; K2K
3E8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax:&nbsp; (613)
254-3717<br>
&nbsp; </font></blockquote><br>

<font face="Courier New, Courier">--------------------------------------------<br>
</font><font face="Times New Roman CE, Times">Anca
Zamfir&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Public Carrier IP <br>
Cisco Systems,
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
email: [email-masked]<br>
2000 Innovation Dr.,
Kanata&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tel#: (613)
254-3484 <br>
Ontario, CANADA&nbsp; K2K
3E8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax:&nbsp; (613)
254-3717<br>
&nbsp; </font></html>

Delivery-date: Fri, 07 Mar 2003 11:37:44 -0800
Date: Fri, 07 Mar 2003 14:36:12 -0500
To: Sameer K <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Anca Zamfir <[email-masked]>
Subject: Fwd: Re: Repost: RFC 3471: IF ID specification WRT component link.
Cc: [email-masked], [email-masked]

<html>
Sameer,<br>
I think you are right, currently there is no way to specify a numbered
component link in the IF-ID HOP object. Also, AFAIK the ERO is not a
mandatory object so because of this both TE Link and component link
should be specified in the IF-ID HOP.<br>
If the following text would be added to the draft, it could IMO solve
these issues. Comments?<br>
<br>
&quot;Added in RFC-3471 - Section 9.1.1. or added to the bundle draft-
Proposed Changes:<br>
<br>
<font face="Courier, Courier">Type Length Format Description<br>
--------------------------------------------------------------------<br>
1&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4<br>
2&nbsp;&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6<br>
3&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below IF_INDEX
(Interface Index)<br>
4&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below
COMPONENT_IF_DOWNSTREAM (Component interface)<br>
5&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below
COMPONENT_IF_UPSTREAM (Component interface)<br>
<b>6&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4 -
DOWNSTREAM (Component interface)&nbsp;&nbsp;&nbsp; ---&gt; new<br>
7&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4 - UPSTREAM
(Component interface)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;
----&gt; new<br>
8&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6 - DOWNSTREAM
(Component interface)&nbsp;&nbsp;&nbsp; ----&gt; new<br>
9&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6 - UPSTREAM
(Component interface)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ----&gt; new<br>
<br>
Types 1-3 are used to identify an unbundled TE
Link<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;
----&gt; new<br>
Types 3-9 are used to identify the component interfaces in the&nbsp;
----&gt; new<br>
case of a bundled TE Link. In this case both the TE Link
and&nbsp;&nbsp;&nbsp;&nbsp; ----&gt; new<br>
the component interface MUST be
specified.&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
----&gt; new<br>
<br>
<br>
<br>
</b></font>This being said, maybe the authors of the bundle draft and
RFC3471 could help to answer the following:<br>
&nbsp;&nbsp; - are these issues valid<br>
&nbsp;&nbsp; - is the proposed change good<br>
&nbsp;&nbsp; - how could the specification be fixed<br>
<br>
Thanks,<br>
Anca<br>
<br>
At 01:28 AM 3/7/2003 -0800, Sameer K wrote:<br>
<br>
<blockquote type=cite cite>Reposting, as I did not get any
response.&nbsp; Could<br>
someone please answer the question.<br>
<br>
Thanks<br>
- Sameer<br>
<br>
--- Sameer K &lt;[email-masked]&gt; wrote:<br>
&gt; Hello All,<br>
&gt; <br>
&gt; From the RFC 3471 - GMPLS Signaling Functional<br>
&gt; Description, Section 9.1.1, it appears that there is<br>
&gt; no way for upstream node, to specify component links<br>
&gt; that are numbered, in the IF-ID HOP object.<br>
&gt; <br>
&gt; The TLV format for IF-ID Types 4 and 5 assumes that<br>
&gt; the component link is always un-numbered.<br>
&gt; <br>
&gt; Is this the way it was planned to be?.&nbsp; If yes, then<br>
&gt; what should IF-ID look like for numbered component<br>
&gt; link (which is a valid scenario per the Link<br>
&gt; Bundling<br>
&gt; draft).<br>
&gt; <br>
&gt; Or did I get it all wrong?<br>
&gt; TIA<br>
&gt; - Sameer<br>
&gt; <br>
&gt; <br>
&gt; __________________________________________________<br>
&gt; Do you Yahoo!?<br>
&gt; Yahoo! Tax Center - forms, calculators, tips, more<br>
&gt;
<a href="http://taxes.yahoo.com/" eudora="autourl">http://taxes.yahoo.com/</a><br>
&gt; <br>
<br>
<br>
__________________________________________________<br>
Do you Yahoo!?<br>
Yahoo! Tax Center - forms, calculators, tips, more<br>
<a href="http://taxes.yahoo.com/" eudora="autourl">http://taxes.yahoo.com/</a></blockquote><br>

<font face="Courier New, Courier">--------------------------------------------<br>
</font><font face="Times New Roman CE, Times">Anca
Zamfir&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Public Carrier IP <br>
Cisco Systems,
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
email: [email-masked]<br>
2000 Innovation Dr.,
Kanata&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tel#: (613)
254-3484 <br>
Ontario, CANADA&nbsp; K2K
3E8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax:&nbsp; (613)
254-3717<br>
&nbsp; </font></html>

Delivery-date: Fri, 07 Mar 2003 10:31:30 -0800
Date: Fri, 07 Mar 2003 13:30:27 -0500
To: Sameer K <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Anca Zamfir <[email-masked]>
Subject: Re: Repost: RFC 3471: IF ID specification WRT component link.
Cc: [email-masked], [email-masked]

<html>
Sameer,<br>
I think you are right, currently there is no way to specify a numbered
component link in the IF-ID HOP object. Also, AFAIK the ERO is not a
mandatory object so because of this both TE Link and component link
should be specified in the IF-ID HOP.<br>
If the following text would be added to the draft, it could IMO solve
these issues. Comments?<br>
<br>
&quot;Added in RFC-3471 - Section 9.1.1. or added to the bundle draft-
Proposed Changes:<br>
<br>
<font face="Courier, Courier">Type Length Format Description<br>
--------------------------------------------------------------------<br>
1&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4<br>
2&nbsp;&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6<br>
3&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below IF_INDEX
(Interface Index)<br>
4&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below
COMPONENT_IF_DOWNSTREAM (Component interface)<br>
5&nbsp;&nbsp;&nbsp; 12&nbsp;&nbsp;&nbsp;&nbsp; See below
COMPONENT_IF_UPSTREAM (Component interface)<br>
<b>6&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4 -
DOWNSTREAM (Component interface)&nbsp;&nbsp;&nbsp; ---&gt; new<br>
7&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp; IPv4 Addr. IPv4 - UPSTREAM
(Component interface)<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;
----&gt; new<br>
8&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6 - DOWNSTREAM
(Component interface)&nbsp;&nbsp;&nbsp; ----&gt; new<br>
9&nbsp;&nbsp; 20&nbsp;&nbsp;&nbsp;&nbsp; IPv6 Addr. IPv6 - UPSTREAM
(Component interface)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ----&gt; new<br>
<br>
Types 1-3 are used to identify an unbundled TE
Link<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;
----&gt; new<br>
Types 3-9 are used to identify the component interfaces in the&nbsp;
----&gt; new<br>
case of a bundled TE Link. In this case both the TE Link
and&nbsp;&nbsp;&nbsp;&nbsp; ----&gt; new<br>
the component interface MUST be
specified.&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
----&gt; new<br>
<br>
<br>
<br>
</b></font>This being said, maybe the authors of the bundle draft and
RFC3471 could help to answer the following:<br>
&nbsp;&nbsp; - are these issues valid<br>
&nbsp;&nbsp; - is the proposed change good<br>
&nbsp;&nbsp; - how could the specification be fixed<br>
<br>
Thanks,<br>
Anca<br>
<br>
At 01:28 AM 3/7/2003 -0800, Sameer K wrote:<br>
<br>
<blockquote type=cite cite>Reposting, as I did not get any
response.&nbsp; Could<br>
someone please answer the question.<br>
<br>
Thanks<br>
- Sameer<br>
<br>
--- Sameer K &lt;[email-masked]&gt; wrote:<br>
&gt; Hello All,<br>
&gt; <br>
&gt; From the RFC 3471 - GMPLS Signaling Functional<br>
&gt; Description, Section 9.1.1, it appears that there is<br>
&gt; no way for upstream node, to specify component links<br>
&gt; that are numbered, in the IF-ID HOP object.<br>
&gt; <br>
&gt; The TLV format for IF-ID Types 4 and 5 assumes that<br>
&gt; the component link is always un-numbered.<br>
&gt; <br>
&gt; Is this the way it was planned to be?.&nbsp; If yes, then<br>
&gt; what should IF-ID look like for numbered component<br>
&gt; link (which is a valid scenario per the Link<br>
&gt; Bundling<br>
&gt; draft).<br>
&gt; <br>
&gt; Or did I get it all wrong?<br>
&gt; TIA<br>
&gt; - Sameer<br>
&gt; <br>
&gt; <br>
&gt; __________________________________________________<br>
&gt; Do you Yahoo!?<br>
&gt; Yahoo! Tax Center - forms, calculators, tips, more<br>
&gt;
<a href="http://taxes.yahoo.com/" eudora="autourl">http://taxes.yahoo.com/</a><br>
&gt; <br>
<br>
<br>
__________________________________________________<br>
Do you Yahoo!?<br>
Yahoo! Tax Center - forms, calculators, tips, more<br>
<a href="http://taxes.yahoo.com/" eudora="autourl">http://taxes.yahoo.com/</a></blockquote><br>

<font face="Courier New, Courier">--------------------------------------------<br>
</font><font face="Times New Roman CE, Times">Anca
Zamfir&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Public Carrier IP <br>
Cisco Systems,
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
email: [email-masked]<br>
2000 Innovation Dr.,
Kanata&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tel#: (613)
254-3484 <br>
Ontario, CANADA&nbsp; K2K
3E8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax:&nbsp; (613)
254-3717<br>
&nbsp; </font></html>

Delivery-date: Fri, 07 Mar 2003 09:59:31 -0800
From: Shahram Davari <[email-masked]>
To: "'Thomas D. Nadeau'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: draft-iesg-vendor-extensions-00.txt
Date: Fri, 7 Mar 2003 09:58:47 -0800 

Thanks, I am happy to hear that my proposal is in fact in-line with
current IETF standardization process. However, my proposal is about allowing 
other SDOs to develop extensions to IETF protocols, even if IETF does
not agree to those extension, while the iesg draft prohibits other SDOs from 
developing any extension to IETF protocols without IETF's approval.

-Shahram

>-----Original Message-----
>From: Thomas D. Nadeau [mailto:[email-masked]]
>Sent: Friday, March 07, 2003 12:43 PM
>To: Shahram Davari; [email-masked]; [email-masked]
>Subject: Re: draft-iesg-vendor-extensions-00.txt
>
>
>
>         I don't see how your proposal differs from the current
>IETF standards process. How could extensions created by other
>SDOs be considered IETF compliant without being passed through the
>process within the IETF?  If they are passed through the processes and
>are eventually approved as standards, then they are called 
>IETF compliant.
>Where exactly do you see this as being broken and requiring 
>additional red
>tape?
>
>         --Tom
>
>
>>Hi All,
>>
>>I would like to make an alternative proposal to what is 
>proposed in this 
>>draft.
>>I think that IETF should not prevent other SDOs from 
>developing extensions 
>>(minor or major),
>>to IETF protocols, as long as they don't call those 
>extensions being IETF 
>>compliant.
>>I think IETF could recommend that the other SDOs present 
>their protocol 
>>extensions
>>to IETF (in the form of a draft). The IETF community then has 
>3 choices:
>>1) IETF agrees with the requirements and nature of the 
>extensions and find 
>>them useful. In that case IETF could engage in technical 
>discussions with 
>>the other SDO and reach to a mutually agreeable draft, which 
>could then be 
>>advanced to Proposed Standard.
>>
>>2) IETF agrees with the requirement, but does not agree with 
>the proposed 
>>extension, and prefers other solutions/extensions that it thinks meet 
>>those requirements. In that case IETF could develop its solution and 
>>present it to the requesting SDO. If that SDO is satisfied with
>>IETF's solution, then fine, otherwise nobody can prevent them from 
>>developing their own extension. If that happens then there 
>would be two 
>>solutions for the same requirements
>>and we should let the Market decide which solution/extension 
>do they prefer.
>>
>>3) IETF does not agree with the requirement for such 
>extensions at all. In 
>>that case, the
>>other SDO should be free to developed their own extension, 
>provided they 
>>don't call those extensions to be IETF compliant.
>>
>>
>>
>>Thanks,
>>-Shahram
>
>

Delivery-date: Fri, 07 Mar 2003 09:44:25 -0800
Date: Fri, 07 Mar 2003 12:43:13 -0500
To: Shahram Davari <[email-masked]>, [email-masked], [email-masked]
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: draft-iesg-vendor-extensions-00.txt

         I don't see how your proposal differs from the current
IETF standards process. How could extensions created by other
SDOs be considered IETF compliant without being passed through the
process within the IETF?  If they are passed through the processes and
are eventually approved as standards, then they are called IETF compliant.
Where exactly do you see this as being broken and requiring additional red
tape?

         --Tom

>Hi All,
>
>I would like to make an alternative proposal to what is proposed in this 
>draft.
>I think that IETF should not prevent other SDOs from developing extensions 
>(minor or major),
>to IETF protocols, as long as they don't call those extensions being IETF 
>compliant.
>I think IETF could recommend that the other SDOs present their protocol 
>extensions
>to IETF (in the form of a draft). The IETF community then has 3 choices:
>1) IETF agrees with the requirements and nature of the extensions and find 
>them useful. In that case IETF could engage in technical discussions with 
>the other SDO and reach to a mutually agreeable draft, which could then be 
>advanced to Proposed Standard.
>
>2) IETF agrees with the requirement, but does not agree with the proposed 
>extension, and prefers other solutions/extensions that it thinks meet 
>those requirements. In that case IETF could develop its solution and 
>present it to the requesting SDO. If that SDO is satisfied with
>IETF's solution, then fine, otherwise nobody can prevent them from 
>developing their own extension. If that happens then there would be two 
>solutions for the same requirements
>and we should let the Market decide which solution/extension do they prefer.
>
>3) IETF does not agree with the requirement for such extensions at all. In 
>that case, the
>other SDO should be free to developed their own extension, provided they 
>don't call those extensions to be IETF compliant.
>
>
>
>Thanks,
>-Shahram

Delivery-date: Fri, 07 Mar 2003 09:27:45 -0800
Date: Fri, 07 Mar 2003 15:48:56 +0900
To: Kireeti Kompella <[email-masked]>, [email-masked]
From: Shimano Katsuhiro <[email-masked]>
Subject: draft-shimano-imajuku-gmpls-restoration-00
Cc: [email-masked]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Dear Ron and Kireeti,

Ie submitted a new Internet-Draft on restoration signaling on GMPLS.
I'd like to have a time slot in the next CCAMP meeting.

The abstract of the draft as follows;

Title           : RSVP extensions for gmpls restoration signaling
Author(s)       : K. Shimano, W. Imajuku
Filename        : draft-shimano-imajuku-gmpls-restoration-00.txt
Pages           : 6
Date            : 2003-3-5

There are some efforts to categorize restoration schemes
[Restoration-analysis]. We consider that pre-planned restoration has
some advantages, for instance, enhancing the quickness to reduce
downtime, extensions to recovery classes, risk management, and
totally integrated distributed control. This document describes some
requirements and extended properties for message objects on RSVP-TE
[RSVP-GMPLS], LSR procedures, and pre-planned GMPLS restoration. We
append a procedure to the recovery steps for working and restoration
setup. Some objects are additionally required with respect to
establishing working LSPs and reservation of restoration LSPs. This
document shows that restoration activation is also needed and
clarifies the required properties.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shimano-imajuku-gmpls-restoration-00.txt

---
Katsuhiro SHIMANO
NTT Network Innovation Labs.
e-mail: [email-masked]
phone: +81-468-59-4767   fax: +81-468-59-3396 

Delivery-date: Fri, 07 Mar 2003 06:51:41 -0800
From: Shahram Davari <[email-masked]>
To: "'Alex Zinin'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: draft-iesg-vendor-extensions-00.txt
Date: Fri, 7 Mar 2003 06:50:42 -0800 

I don't mind, but I followed Scott Bradner's advice.

Yours,
Shahram

>-----Original Message-----
>From: Alex Zinin [mailto:[email-masked]]
>Sent: Thursday, March 06, 2003 6:06 PM
>To: Shahram Davari
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: draft-iesg-vendor-extensions-00.txt
>
>
>Shahram,
>
>  Since the draft in subject is not specific to the CCAMP or MPLS WGs,
>  or even the SUB-IP area, may I suggest that we don't abuse the
>  mailing lists of these WGs and take the discussion to [email-masked]?
>
>-- 
>Alex
>
>Thursday, March 6, 2003, 11:35:16 AM, Shahram Davari wrote:
>> Hi All,
>
>> I would like to make an alternative proposal to what is 
>proposed in this draft.
>> I think that IETF should not prevent other SDOs from 
>developing extensions (minor or major),
>> to IETF protocols, as long as they don't call those 
>extensions being IETF compliant.
>> I think IETF could recommend that the other SDOs present 
>their protocol extensions
>> to IETF (in the form of a draft). The IETF community then 
>has 3 choices:
>
>> 1) IETF agrees with the requirements and nature of the 
>extensions and find them useful. In that case IETF could 
>engage in technical discussions with the other SDO and reach 
>to a mutually agreeable
>> draft, which could then be advanced to Proposed Standard.
>
>> 2) IETF agrees with the requirement, but does not agree with 
>the proposed extension, and prefers other solutions/extensions 
>that it thinks meet those requirements. In that case IETF could develop
>> its solution and present it to the requesting SDO. If that 
>SDO is satisfied with
>> IETF's solution, then fine, otherwise nobody can prevent 
>them from developing their own extension. If that happens then 
>there would be two solutions for the same requirements
>> and we should let the Market decide which solution/extension 
>do they prefer.
>
>> 3) IETF does not agree with the requirement for such 
>extensions at all. In that case, the
>> other SDO should be free to developed their own extension, 
>provided they don't call those extensions to be IETF compliant.
>
>
>
>> Thanks,
>> -Shahram
>

Delivery-date: Fri, 07 Mar 2003 05:32:17 -0800
From: Manoj Agiwal <[email-masked]>
To: "'Ccamp (E-mail)" <[email-masked]>
Subject: Bundle Links 
Date: Fri, 7 Mar 2003 07:26:14 -0600 

HI ,
        Consider a scenario where I am signaling the bidirectional
connection request over a bundle link .

        Both my Upstream connection and Downstream connection are on the
same link .

        In such a scenario what will my IF_ID RSVP_HOP object should carry .

         Will it carry object  Interface_Index ( Type = 3 ) , or  both
Component_if_downstream  ( type 4 )and 
          component_if_upstream ( type 5) .

         Is it necessary to include object TLV of type 4 / 5 when ever link
is a bundled link for eg. in a uni-direction connection.

Manoj

Delivery-date: Fri, 07 Mar 2003 01:28:55 -0800
Date: Fri, 7 Mar 2003 01:28:28 -0800 (PST)
From: Sameer K <[email-masked]>
Subject: Repost: RFC 3471: IF ID specification WRT component link.
To: [email-masked], [email-masked]

Reposting, as I did not get any response.  Could
someone please answer the question.

Thanks
- Sameer

--- Sameer K <[email-masked]> wrote:
> Hello All,
> 
> From the RFC 3471 - GMPLS Signaling Functional
> Description, Section 9.1.1, it appears that there is
> no way for upstream node, to specify component links
> that are numbered, in the IF-ID HOP object.
> 
> The TLV format for IF-ID Types 4 and 5 assumes that
> the component link is always un-numbered.
> 
> Is this the way it was planned to be?.  If yes, then
> what should IF-ID look like for numbered component
> link (which is a valid scenario per the Link
> Bundling
> draft).
> 
> Or did I get it all wrong?
> TIA
> - Sameer
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> 

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Delivery-date: Fri, 07 Mar 2003 01:12:31 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-pr oc-00.txt
Date: Fri, 7 Mar 2003 09:10:22 -0000 

Don, you observed 07 March 2003 05:34
<snip>
> >SDH/SONET bandwidth on demand has never been deployed.  There is
> >serious question about whether this is a viable service.  The
> >technology has existed for about a decade (a little less maybe) for
> >provide ATM SVC service doing essentially the same thing.  Market
> >penetration after a decade is very close to zero for SVC.  Market
> >penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> >market seems to be shrinking as well.  FR SVC market is zero.
> >SDH/SONET does not have the bandwidth on demand capability but there
> >is ample evidence that implementing it would be a waste of time.

NH=> Mark has said effectively the same and I can confirm this.  To make
switched services work you basically need (i) very large numbers and (ii)
knowledge of the calling-rate/holding-times.  We have neither at SDH rates
or lower (ie OTN).  However, using generalised models you can show that to
had a stab at a reasonably efficient network/service-model the expected
waiting-time for a given BW 'post demand' needs to be the same order as the
holding-time of that BW.  If the expected holding-time is the order
days/weeks/months on a relatively small network population you can see that
its a nonsense to even think about going here at this point.  Note that you
can extend this arguement to the ethernet BOD case....the fundamantal
problem is the same (you can of course address niche markets in limited
locations, but not large/general-case geographical areas).

Wrt to your other observations on ATM/FR.  Yes, its been very difficult to
justify SVCs here.  This is also due to their use as product substitution
for TDM-leased-line services (to build private networks) rather than new
services.  And from what we see, the FR market is now flat but the ATM
market is still showing fairly high growth rates.
> >
> >ASON is a requirements document from ITU that assumes the SDH/SONET
> >BOND is a viable service.  This is an enormous leap of faith 
> given the
> >trends in the market.  The IETF doesn't buy into it.
> >
> This is not correct. I have had this discussion with the authors and 
> they assure me bandwidth on demand not the expected model of 
> deployment. 
> It is not precluded true but they realize the current situation.
NH=> Again I can confirm what Don is saying is correct.  We have been
consistent on this from the start.....we never saw BOD at L1 as the main
driver.  It was those driving GMPLS who were the main group arguing for BOD
at L1 to set-up 'LSPs' at will for the IP client layer.....and I can
remember arguing with them a couple of years ago on this saying 'please
don't go there'.  In fact its really hard to justify using a control-plane
at all at L1.  The benefits are minimal in our opinion (but to be fair, I
have to admit that we have some very slick NMS/OSS solutions here).
Restoration/S-PVC-like constructs are useful.  Having a control-plane
external NNI is arguably better than a NMS-plane NNI (eg less real damange
possible from any hacking).  Any control-plane solution must play
second-fiddle to the NMS.  And given operators have multiple clients, none
of which will be 'peering' with the L1/0 networks then there is no
compelling argument to select a specific control-plane solution.....the
components can therefore be chosen based on what an operator perceives to be
best-of-breed.
> 
<snip>
> >Initially IP and voice ran over TDM.
NH=> Don, they always will in core networks.  Cct-switching is a fine way to
aggregate *any* forms of large traffic volumes, irrespective of its source
nature.  This is just a fact that any operator could confirm.

regards, Neil
<snipped to end>

Delivery-date: Thu, 06 Mar 2003 23:39:10 -0800
Reply-To: "Toshio Soumiya" <[email-masked]>
From: "Toshio Soumiya" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-czezowski-optical-recovery-reqs-01.txt
Date: Fri, 7 Mar 2003 16:37:25 +0900

Dear All,

We made requirements for fault recovery in GMPLS-based optical networks,
general implementation for fault notification and LMP base implementation.
These are;
- draft-czezowski-optical-recovery-reqs-01.txt
- draft-rabbat-fault-notification-protocol-02.txt
- draft-soumiya-lmp-fault-notification-ext-00.txt, which still is not
appeared in http://www.ietf.org/internet-drafts/ . So, I attach to this
mail.

Please comment !

Regards,
T. Soumiya
=======================================================
CCAMP Working Group                                 T. Soumiya (Editor)
Internet Draft                                     Fujitsu Laboratories
Expires: August 2003                              P. Czezowski (Editor)
                                                Fujitsu Labs of America

                                                          February 2003

          Extensions to LMP for Flooding-based Fault Notification
              draft-soumiya-lmp-fault-notification-ext-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Abstract

   This draft describes extensions to the Link Management Protocol (LMP)
   for use in flooding-based fault notification in pre-OTN networks.
   Pre-OTN networks are transport networks that have a GMPLS-based
   control plane and various transport plane technologies (such as
   Optical Cross Connects and Optical Add/Drop Multiplexers, etc.)  An
   important feature of these networks is timely recovery from failures
   - using either a protection or restoration scheme.  The recovery
   schemes should also be resource efficient and flexible to meet
   operator requirements.  Once a fault is detected, fault notification
   is one of a series of phases needed to achieve recovery.  We prefer a
   flooding-based approach to the notification phase because it may
   offer speed and flexibility advantages over using RSVP-TE signaling
   for notification.  Extending LMP to include fault notification is a
   good fit to the problem because fault management is already one of
   its features and many of its protocol objects can be reused.

Soumiya & Czezowski (Eds.)      Expires - August 2003         [Page 1]
         draft-soumiya-lmp-fault-notification-ext-00.txt February 2003

Table of Contents

   1. Overview.......................................................2
   1.1 Terminology...................................................3
   1.2 Glossary of Terms Used........................................3
   2. Fault Recovery Scenario........................................3
   3. Additional LMP Message Formats.................................5
   3.1 FaultNotify Message (Msg Type = TBD)..........................5
   3.2 FaultNotifyAck Message (Msg Type = TBD).......................6
   4. Additional LMP Object Definitions..............................6
   4.1 TTL Class (Class = TBD).......................................6
   4.2 FAULT_ID Class (Class = TBD)..................................6
   5. Priority-Based Recovery........................................7
   6. Security Considerations........................................8
   7. Conclusion.....................................................8
   References........................................................9
   Acknowledgments..................................................10
   Editors' Addresses...............................................10
   Contributing Authors.............................................10

1. Overview

   This draft describes extensions to the Link Management Protocol (LMP)
   for use in flooding-based fault notification in pre-OTN networks.
   Pre-OTN networks are transport networks that have a GMPLS-based
   control plane and various transport plane technologies (such as
   Optical Cross Connects and Optical Add/Drop Multiplexers, etc.)  An
   important feature of these networks is timely recovery from failures
   - using either a protection or restoration scheme.  The recovery
   schemes should also be resource efficient and flexible to meet
   operator requirements.  Once a fault is detected, fault notification
   is one of a series of phases needed to achieve recovery.  We prefer a
   flooding-based approach to the notification phase because it may
   offer speed and flexibility advantages over using RSVP-TE signaling
   for notification.  Extending LMP to include fault notification is a
   good fit to the problem because fault management is already one of
   its features and many of its protocol objects can be reused.

   Currently, there are several Internet Drafts related to recovery in
   networks featuring a GMPLS control-plane. They cover the topics of
   terminology [2], requirements [3], functional specification [4], and
   mechanisms analysis [5].  The requirements for control plane-based
   recovery were found to fall into four main categories:

      o Meeting timing requirements
      o Efficient usage of data plane resources
      o Efficient usage of control plane resources
      o Supporting flexible design of recovery schemes

Soumiya & Czezowski (Eds.)        Expires - August 2003       [Page 2]
         draft-soumiya-lmp-fault-notification-ext-00.txt February 2003

   That controlled flooding meets the requirements on fault notification
   mechanisms and has beneficial side effects over notification via
   GMPLS signaling is discussed in [3].  Flooding-based notification is
   also appropriate for shared mesh-based recovery schemes that are
   promoted for their resource efficiency and flexibility.  Generic
   mechanisms for implementing a flooding-based fault notification
   protocol are proposed in [6].

   In this draft, we describe the implementation of flooding-based fault
   notification in a recovery scenario, and provide the necessary
   extensions to LMP message formats and data object definitions.

1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [7].

1.2 Glossary of Terms Used

   In addition to the terminology for GMPLS-based recovery that is
   documented in [2], this draft uses the following acronyms:

      o  GMPLS:   Generalized Multiprotocol Label Switching [8]
      o  LMP:     Link Management Protocol [9]
      o  LSP:     Label Switched Path
      o  NMS:     Network Management System
      o  OTN:     Optical Transport Network
      o  RSVP-TE: Resource Reservation Protocol-Traffic Eng. [10]

2. Fault Recovery Scenario

   In this section, a fault recovery scenario is described based on
   shared mesh recovery.  Every node maintains an adjacency with each of
   its neighbors via at least one LMP control channel.  A pre-planned
   recovery path table is configured using extended GMPLS signaling
   messages or through a Network Management System (NMS).

   When a failure occurs, the following procedure is carried out:

      1. A downstream node close to the failure detects it.  This node
   is called the detecting node.  If path is bi-directional, an upstream
   node also detects it. The detecting node should report the detection
   of the failure (and becomes the reporting node).

      2. The reporting node unicasts FaultNotify messages to all its
   immediate neighbor nodes.  The node continues sending unicast

Soumiya & Czezowski (Eds.)        Expires - August 2003       [Page 3]
         draft-soumiya-lmp-fault-notification-ext-00.txt February 2003

   FaultNotify messages periodically until it receives FaultNotifyAck
   messages from its neighbors, or a timer to retry sending has expired.
   A FaultNotify message contains the node ID of the reporting node, the
   link ID of the failed link and a sequence Number. The message may
   optionally contain a TTL, failed wavelength ID, or failed SRLG ID.

      3. A neighbor node receives FaultNotify message with failure data
   and sequence number.

      4. The receiving node confirms it has not yet received the message
   about this failure.  For this purpose, it searches a database indexed
   on the failure data and sequence number.  The database stores the
   failure data and sequence numbers from the received messages.
         4a. If it has not yet received the message about this failure,
   it adds the failure data and sequence number into the database.  The
   node then unicasts FaultNotify messages to all its neighbors, except
   the node that sent the message.
         4b. If it has already received the message about this failure,
   go to 6.

      5. The receiving node possibly sets up one or more protection
   paths according to a pre-planned protection table and the failure
   data.

      6. The receiving node sends back FaultNotifyAck message to the
   node that sent the FaultNotify message.

   [Optional]: If the receiving node has set up one or more protection
   paths, it sends a ProctectionCompleteNotify message to either the
   egress node of the protection path or to the NMS. It continues
   sending ProtectionCompleteNotify messages periodically until it
   receives a ProtectionCompleteNotifyAck message or a timer to retry
   sending has expired.

   [Optional]: The receiving node at the egress of the protection path,
   or the NMS sends back ProtectionCompeteNotifyAck message.

                         [R1]---[R2]---[R3]---[R4]
                           \                  /
                           [R5]-------------[R6]
                           /  \           /   \
                        [R7]---[R8]---[R9]---[R10]

     Working LSP1:  [R1->R2->R3 >R4]   Working LSP2:  [R7->R8->R9->R10]
     Recovery LSP1: [R1->R5->R6->R4]   Recovery LSP2: [R7->R5->R6->R10]

                      Figure 1: Shared Mesh Recovery

Soumiya & Czezowski (Eds.)        Expires - August 2003       [Page 4]
         draft-soumiya-lmp-fault-notification-ext-00.txt February 2003

   Figure 1 shows an example of shared mesh-based recovery.  One working
   path, W-LSP1, runs from R1 to R4 via R2 and R3, and another working
   path, W-LSP2, runs from R7 to R10 via R8 and R9.  R1 can provide user
   traffic protection by creating a backup LSP that merges with the
   working LSP at R4.  We refer to a R-LSP1 [R1->R5->R6->R4] as the
   recovery LSP of W-LSP1.  In the same manner, we refer to R-LSP2 [R7-
   >R8->R9->R10] as recovery of W-LSP2.

   In this situation, if it can be assumed that multiple failures do not
   occur at a same time, the resource for recovering the working LSPs
   can be shared.  In other words, the resource between R5 and R6 can be
   shared between the recovery LSP1 and recovery LSP2.  By setting up
   these recovery LSPs, the spare/work capacity ratio in the network can
   be reduced.

   When a failure occurs at a link between R8 and R9 on the working W-
   LSP2, the endpoint nodes (both R8 and R9) of the link will detect the
   failure (if the link is bi-directional).  Then, the detecting nodes
   start sending FaultNotify messages in the flooding-based manner. In
   case of R9, the messages are sent to R6 and R10.  When a FaultNotify
   message is received, these nodes send back a FaultNotifyAck message
   to the sending node.  In the same manner, they flood the messages to
   their immediate neighbors.

   The FaultNotify message includes information regarding the failure
   such as FAULT_ID, etc.  When nodes on the recovery LSPs receive the
   FaultNotify message, they activate the pre-calculated recovery path.
   In this example, R-LSP2 is activated and R7 switches W-LSP2 traffic
   to be carried by R-LSP2.  Also R10 merges R-LSP2 to the original
   route.  As the result, traffic will take the path [R7->R5->R6->R10].

3. Additional LMP Message Formats

   LMP is a good candidate protocol to extend for the purposes of fault
   notification. Flooding-based fault notification is quite simple, and
   only two messages (FaultNotify and FaultNotifyAck) need to be
   defined. Furthermore, most of the necessary data objects are already
   defined in LMP [9].

3.1  FaultNotify Message (Msg Type = TBD)

   <FaultNotify Message> ::= <Common Header> <MESSAGE_ID>
                                [<TTL>] <FAULT_ID> <LOCAL_NODE_ID>
                                {<LINK_ID> [<CHANNEL_STATUS>] ...}
   or

   <FaultNotify Message> ::= <Common Header> <MESSAGE_ID>
                                <TTL> <FAULT_ID> [<SRLG ID> ...]

Soumiya & Czezowski (Eds.)        Expires - August 2003       [Page 5]
         draft-soumiya-lmp-fault-notification-ext-00.txt February 2003

3.2  FaultNotifyAck Message (Msg Type = TBD)

   <FaultNotifyAck Message> ::= <Common Header><MESSAGE_ID_ACK>

   The contents of the MESSAGE_ID_ACK object MUST be obtained from the
   FaultNotify message being acknowledged.

4. Additional LMP Object Definitions

   The formats for the Common Header at the beginning of LMP messages
   and the LMP objects used to build the messages are defined in [9].
   That document also defines the MESSAGE_ID, MESSAGE_ID_ACK,
   LOCAL_NODE_ID, and CHANNEL_STATUS data objects used in our extended
   messages. The SRLG_ID data object is defined in [11]. This leaves us
   to define data objects for TTL and FAULT_ID.

4.1 TTL Class (Class = TBD)

   o  C-Type = 1, Time to Live (= Hop Count)

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TTL       |                    Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TTL:  8 bits

      This is an unsigned integer to indicate a remaining hop count
      value.  A node receiving a FaultNotify message having a TTL of
      zero MUST silently discard the message.

   This object is non-negotiable.

4.2 FAULT_ID Class (Class = TBD)

   o  C-Type = 1, Failure Identifier

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |         FaultId               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   FaultId:  16 bits

      This MUST be a node-wide unique unsigned integer. The FaultId

Soumiya & Czezowski (Eds.)        Expires - August 2003       [Page 6]
         draft-soumiya-lmp-fault-notification-ext-00.txt February 2003

      identifies the sequence of failures.  A node increases the value
      when it detects a failure.

   This object is non-negotiable.

5. Priority-Based Recovery

   Fault recovery schemes typically assume single failure events.
   However, there may occur multiple failures in some short time
   interval.  Protection against occurrences of failure scenarios
   requires exorbitant spare capacity.  Ideally, the network should at
   least save some of the working paths in this situation.

   For example, consider figure 2, when two failures occur at a same
   time.  One failure is a link failure between R3 and R4, and the other
   failure is also link failure between R7 and R8.  In this example, R4
   detects a failure and send fault notification message using flooding
   to R6.  Also, R8 detects a failure and sends a message to R5.  At R6,
   a recovery path switches traffic from R6 to R4 because the fault
   notification message is for W-LSP1.  On the other hand, at R5, a
   recovery path switches traffic from R5 to R6 because the fault
   notification message is for W-LSP2.  As the result, an invalid
   recovery path is set to follow [R7->R5->R6->R4].

                         [R1]---[R2]---[R3]-X-[R4]
                           \                  /
                           [R5]-------------[R6]
                           /  \           /   \
                        [R7]-X-[R8]---[R9]---[R10]

     Working LSP1:  [R1->R2->R3->R4]   Working LSP2:  [R7->R8->R9->R10]
     Recovery LSP1: [R1->R5->R6->R4]   Recovery LSP2: [R7->R5->R6->R10]

                   Figure 2: Multiple failure scenario.

   Priority-based control is an effective solution for the case of
   saving specific working paths in multiple failure condition.  In the
   above example, if the priority of W-LSP1 is higher than W-LSP2, then
   the fault notification messages for W-LSP1 are preferred.  In other
   words, the system checks the priority of the protection path and
   changes the setting by priority.  In that case, the setting of R6 to
   R4 takes place over R6 to R10.  By adopting the priority-based
   control, such misbehavior can be avoided.  As the result, the high
   priority protection path is set up.  This priority should be set
   according to a network operator's policy and/or network service.

Soumiya & Czezowski (Eds.)        Expires - August 2003       [Page 7]
         draft-soumiya-lmp-fault-notification-ext-00.txt February 2003

6. Security Considerations

   Security requirements depend on the level of trust between nodes that
   exchange fault notification messages.  In general, when nodes in a
   pre-OTN network are in the same administrative domain than when
   talking to nodes in a different administrative domain, the security
   consideration may apply more relaxed.

   When flooding-based fault notification mechanism is implemented based
   on LMP [9], the security mechanisms of LMP can be adopted.  All LMP
   messages should be sent over an IPsec channel that has been either
   pre-established or is set-up on a per need basis.

   Note however that fault recovery protocol itself introduces no new
   security considerations.

7. Conclusion

   This draft describes extensions to the Link Management Protocol (LMP)
   for use in flooding-based fault notification in pre-OTN networks.
   While there are currently several Internet Drafts in the Sub-IP Area
   related to service recovery in GMPLS networks, fault notification
   method for control plane-based networks has not been specifically
   detailed in any one document.  We believe that flooding base fault
   notification method is the best way to satisfy fault recovery
   requirements.  We show how the notification functions in fault
   recovery scenarios.

Soumiya & Czezowski (Eds.)        Expires - August 2003       [Page 8]
         draft-soumiya-lmp-fault-notification-ext-00.txt February 2003

References

   [1] Bradner, S., "The Internet Standards Process -- Revision 3",
       BCP 9, RFC 2026, October 1996.

   [2] Mannie, E., et al, "Recovery (Protection and Restoration)
      Terminology for GMPLS", Internet Draft, work in progress, draft-
      ietf-ccamp-gmpls-recovery-terminology-01.txt, November 2002.

   [3] Czezowski, P., and T. Soumiya (Eds.), "Optical network failure
      recovery requirements", Internet Draft, work in progress, draft-
      czezowski-optical-recovery-reqs-01.txt, February 2003.

   [4] Lang, J.P. and B. Rajagopalan (Eds.), "Generalized MPLS Recovery
      Functional Specification", Internet Draft, work in progress,
      draft-ietf-ccamp-gmpls-recovery-functional-00.txt, January 2003.

   [5] Papadimitriou, D., et al, "Analysis of Generalized MPLS-based
      Recovery Mechanisms (including Protection and Restoration)",
      Internet draft, work in progress, draft-ietf-ccamp-gmpls-recovery-
      analysis-00.txt, January 2003.

   [6] Rabbat, R., and V. Sharma (Eds.), "Fault Notification Protocol
      for GMPLS-based Recovery", Internet Draft, work in progress,
      draft-rabbat-fault-notification-protocol-02.txt, February 2003.

   [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [8] Mannie, E. (Ed.), "Generalized Multi-Protocol Label Switching
      (GMPLS) Architecture", Internet Draft, work in progress, draft-
      ietf-ccamp-gmpls-architecture-03.txt, August 2002.

   [9] Lang, J. (Ed.), "Link Management Protocol (LMP)", Internet Draft,
      draft-ietf-ccamp-lmp-07.txt, November 2002.

   [10] Berger, L. (Ed.), "Generalized MPLS Signaling - RSVP-TE
      Extensions", Internet Draft, work in progress, draft-ietf-mpls-
      generalized-rsvp-te-09.txt", September 2002.

   [11] Fredette, A., and J. Lang (Eds.), "Link Management Protocol
      (LMP) for DWDM Optical Line Systems", Internet Draft, work in
      progress, draft-ietf-ccamp-lmp-wdm-01.txt, September 2002.

Soumiya & Czezowski (Eds.)        Expires - August 2003       [Page 9]


Acknowledgments

   The following individuals provided valuable input to this draft:
   Richard Rabbat, Ching-Fong Su and Takafumi Chujo of Fujitsu Labs of
   America, and Masafumi Katoh and Akira Chugo of Fujitsu Laboratories,
   Ltd.

Editors' Addresses

   Toshio Soumiya                    Peter Czezowski
   Fujitsu Laboratories Ltd.         Fujitsu Labs of America, Inc.
   1-1, Kamikodanaka 4-Chome         595 Lawrence Expressway
   Nakahara-ku, Kawasaki             Sunnyvale, CA 94085
   211-8588, Japan                   United States of America
   Phone: +81-44-754-2765            Phone: +1-408-530-4516
   Email: [email-masked] Email: [email-masked]

Contributing Authors

   Shinya Kanoh                      Takeo Hamada
   Fujitsu Laboratories Ltd.         Fujitsu Labs of America, Inc.
   1-1, Kamikodanaka 4-Chome         595 Lawrence Expressway
   Nakahara-ku, Kawasaki             Sunnyvale, CA 94085
   211-8588, Japan                   United States of America
   Phone: +81-44-754-2765            Phone: +1-408-530-4516
   Email: [email-masked]       Email: [email-masked]

Soumiya & Czezowski (Eds.)      Expires - August 2003        [Page 10]

----- Original Message -----
From: <[email-masked]>
To: <@IETF-Announce>
Cc: <[email-masked]>
Sent: Wednesday, March 05, 2003 8:29 PM
Subject: I-D ACTION:draft-czezowski-optical-recovery-reqs-01.txt

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

Title : Optical Network Failure Recovery Requirements
Author(s) : P. Czezowski, T. Soumiya
Filename : draft-czezowski-optical-recovery-reqs-01.txt
Pages : 12
Date : 2003-3-4

This draft describes requirements for control plane-based recovery
from data plane failures in pre-OTN networks.  pre-OTN networks are
transport networks that have a GMPLS-based control plane and various
transport plane technologies (such as Optical Cross Connects and
Optical Add/Drop Multiplexers, etc.)  An important feature of these
networks is recovery from failures - using either a protection or
restoration scheme.  Achieving recovery under strict time constraints
is a difficult problem.  Shared mesh-based recovery is especially
desirable for reducing spare capacity ratios and achieving flexible
recovery scenarios.  Following a brief overview and consideration of
the requirements, they are presented in an itemized list in section
3.4 of this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-czezowski-optical-recovery-reqs-01
.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-czezowski-optical-recovery-reqs-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-czezowski-optical-recovery-reqs-01.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Delivery-date: Thu, 06 Mar 2003 21:32:03 -0800
Date: Fri, 07 Mar 2003 00:34:25 -0500
From: Don Fedyk <[email-masked]>
To: [email-masked]
CC: Gert Grammel <[email-masked]>, [email-masked], [email-masked], "Don Fedyk" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Curtis

Some comments, inline.

Curtis Villamizar wrote:

>Coments inline.
>
>In message <[email-masked]>, Gert Grammel writes:
>  
>
>> 
>>Mark,
>> 
>>'improving the coordination between the IETF and ITU-T' is one of the
>>things I' d like to see since years. However in my experience the true
>>barrier between both groups is not so much the technology as such, but
>>some ignorance about the core aspects in both organizations. To give a
>>balanced figure here:
>> 
>>  1. You remember the thread about the non-standard SDH/SONET
>>     extensions. Here some guys active in GMPLS tried to push their
>>     ideas about transparency.  Obviously this was perceived on ITU-T
>>     side as a challenge on the purity of a standard (G.707). This one
>>     was (almost) setteled by moving all non-standard features to an
>>     informal draft.
>> 
>>  2. Now it is the other way round. Somehow ITU-T extensions got
>>     accepted (agai n informational) in IETF which do not comply to
>>     the purity of RSVP-TE. Due t o the fact that this informational
>>     RFC was not reviewed in CCAMP before, it is perceived as an
>>     assault.
>> 
>>So the match is tied up 1:1 but maybe it's now the right time to find
>>a solutio n on how to proceed. What I've seen so far was a complete
>>misperception of what i s required on either side and why.
>> 
>>  1. ITU-T basically started by defining user services having in mind
>>     layered transport platforms like OTH and SDH/SONET. Those
>>     services can be summarized as 'Bandwidth on Demand' services
>>     (BOND). Naturally this led to a very strong focus on UNI
>>     interfaces and a kind of ignorance of networkin g protocols. You
>>     probably remember the discussions on why not using SS7? (For
>>     those not familar with the issue: SS7 is the signaling protocol
>>     between PSTN switches)
>>    
>>
>
>SDH/SONET bandwidth on demand has never been deployed.  There is
>serious question about whether this is a viable service.  The
>technology has existed for about a decade (a little less maybe) for
>provide ATM SVC service doing essentially the same thing.  Market
>penetration after a decade is very close to zero for SVC.  Market
>penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
>market seems to be shrinking as well.  FR SVC market is zero.
>SDH/SONET does not have the bandwidth on demand capability but there
>is ample evidence that implementing it would be a waste of time.
>
>ASON is a requirements document from ITU that assumes the SDH/SONET
>BOND is a viable service.  This is an enormous leap of faith given the
>trends in the market.  The IETF doesn't buy into it.
>
This is not correct. I have had this discussion with the authors and 
they assure me bandwidth on demand not the expected model of deployment. 
It is not precluded true but they realize the current situation.

>
>And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
>mess, so if you want to extend TCAP to support ASON, go right ahead.
>We in the IETF would get a real good laugh over that.
>
>  
>
>>  2. IETF started with established L2/3 protocols (OSPF, RSVP-TE, ...)
>>     and extending their scope to L1 technologies namely SDH/SONET and
>>     OTH.  Naturally this led to a very strong focus on protocol
>>     consistency and a kind of ignorance on service aspects other than
>>     those already available in MPLS. You may remember here the
>>     discussion about whether UNI is useful at all some time ago.
>>    
>>
>
>Initially IP and voice ran over TDM.  The bandwidth demands of IP were
>much less than voice a decade ago.  As IP penetration grew roughly
>exponentially through the early, mid, and most of the late 1990s, this
>reversed and IP consumed far more bandwidth than voice.  Switched
>services also grew but at a slower rate and in the late 1990s
>experienced negative growth for many SPs.  One factor may have been
>notable outages in FR (US nationwide one day at one major provider and
>intermittent for 10 days in another a few years later) shot a big hole
>in the "much more reliable than IP" story.
>
We know the world is changing and that is why we are trying to reuse IP 
technology.  I think it is a big win if we reuse similar technology 
components. It won't happen overnight. But it wont happen if we don't 
move forward. There is a lot of history in optical networks and they are 
evolving and simplifying. This is similar to the early packet industry. 
We used to have many protocols for different traffic. Only with the 
advent of cheaper bandwidth could we afford IP. 

>
>  
>
<snip> History of GMPLS

>>    
>>
>
>ASON was never accepted by the IETF as requirements and for very good
>reason.  To say that IETF must accept the ASON requirements simply
>because they came in a liason statement and that the IETF must
>accommodate this ITU folly is absurd.
>
I don't think it is about accepting ASON per se. We would not have the 
ITU if that were true. It is about parallel requirements that can be 
solved by the same mechanisms. Is there a one to one mapping? In many 
cases yes. Are there differences yes again. Do we need the IETF to 
accept all the changes?  Well that is THE question. What would be great 
is if the IETF could accommodate, and filter the information that is 
relevant and suggest solutions to features that the IETF cannot see 
value in. That's what I saw happen in other WGs.  You know the ITU has 
taken a lot of technology from the IETF. It is common practice not to 
reinvent technology.

 I can't think of system that was deployed that turned out the way 
everyone thought it would. We wouldn't be deploying IP version 6 if 
there wasn't some room for changes.   There are many profitable ATM 
networks in the world. Guess what?  There are even profitable X.25 
networks still kicking.

>>I recall that this was the basic issue with the ITU-T proposal when it
>>was presented for the first time in Yokohama. The way I've got
>>Kireeti's message there was: please authors try to let us understand
>>what problem you want to solve and tell us which kind of information
>>you have to exchange between which points to achieve it. We'll sort
>>out then in CCAMP what would be the most appropriate way to implement
>>it, while maintaining consistency in our protocols .
>>    
>>
>
>Regardless of how this was handled in Yokohama, some of the
>fundamental premise of ASON is flawed.  It would be best if ITU
>members go off and waste their own time pursuing ASON capabilities,
>just as the ATM Forum went off and wasted their time on Q.2931
>capability in UNI 3.x, 4.x, but ITU should do so without extending
>protocols which originated in the IETF.
>
Your instance that they are all irrelevant and should go away is tiresome.

>>Although it didn't work the first time I still consider Kireeti's
>>suggestion to be a wise way to move forward and perhaps the key for
>>harmonic collaboration.
>> 
>>Regards
>> 
>>Gert
>>    
>>
>
>I look forward to seeing the IETF come up with a formal statement of
>liason policy.  It would be useful to have explicitly documented that
>liason statements carry no more weight than any individual
>internet-draft submission.
>
>Curtis
>
Curtis you have proven that even the weight of any individual has a 
pretty high threshold!

Don

Delivery-date: Thu, 06 Mar 2003 20:46:02 -0800
Date: Thu, 06 Mar 2003 23:40:41 -0500
From: Ron Bonica <[email-masked]>
Subject: FW: I-D ACTION:draft-bonica-tunproto-04.txt
To: [email-masked]

Folks,

Please review and comment. I believe that the protocol can be implemented at
this point. Please tell me if any crucial details have been omitted.

                Ron
                /as individual contributor

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, March 05, 2003 6:29 AM
> To: IETF-Announce:
> Subject: I-D ACTION:draft-bonica-tunproto-04.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
> 	Title		: Generic Tunnel Tracing Protocol (GTTP)
> Specification
> 	Author(s)	: R. Bonica et al.
> 	Filename	: draft-bonica-tunproto-04.txt
> 	Pages		: 0
> 	Date		: 2003-3-4
>
> This document describes the Generic Tunnel Tracing Protocol (GTTP).
> GTTP supports enhanced route-tracing applications. Network operators
> use enhanced route-tracing applications to trace the path between any
> two points on an IP network. Enhanced route-tracing applications can
> trace through a network's forwarding plane, its control plane or
> both. Furthermore, enhanced route-tracing applications can reveal
> details concerning tunnels that support the traced path. Tunnel
> details can be revealed regardless of tunneling technology. For
> example, enhanced route-tracing applications can trace through an
> MPLS LSP as well as they can trace through an IP-in-IP tunnel.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bonica-tunproto-04.txt
>
>

Delivery-date: Thu, 06 Mar 2003 15:07:28 -0800
Date: Thu, 6 Mar 2003 15:05:59 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Shahram Davari <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-iesg-vendor-extensions-00.txt

Shahram,

  Since the draft in subject is not specific to the CCAMP or MPLS WGs,
  or even the SUB-IP area, may I suggest that we don't abuse the
  mailing lists of these WGs and take the discussion to [email-masked]?

-- 
Alex

Thursday, March 6, 2003, 11:35:16 AM, Shahram Davari wrote:
> Hi All,

> I would like to make an alternative proposal to what is proposed in this draft.
> I think that IETF should not prevent other SDOs from developing extensions (minor or major),
> to IETF protocols, as long as they don't call those extensions being IETF compliant.
> I think IETF could recommend that the other SDOs present their protocol extensions
> to IETF (in the form of a draft). The IETF community then has 3 choices:

> 1) IETF agrees with the requirements and nature of the extensions and find them useful. In that case IETF could engage in technical discussions with the other SDO and reach to a mutually agreeable
> draft, which could then be advanced to Proposed Standard.

> 2) IETF agrees with the requirement, but does not agree with the proposed extension, and prefers other solutions/extensions that it thinks meet those requirements. In that case IETF could develop
> its solution and present it to the requesting SDO. If that SDO is satisfied with
> IETF's solution, then fine, otherwise nobody can prevent them from developing their own extension. If that happens then there would be two solutions for the same requirements
> and we should let the Market decide which solution/extension do they prefer.

> 3) IETF does not agree with the requirement for such extensions at all. In that case, the
> other SDO should be free to developed their own extension, provided they don't call those extensions to be IETF compliant.

> Thanks,
> -Shahram

Delivery-date: Thu, 06 Mar 2003 15:07:17 -0800
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 18:06:44 -0500
From: "Lazer, Monica A, ALABS" <[email-masked]>
To: "Gert Grammel" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Ash, Gerald R (Jerry), ALABS" <[email-masked]>, <[email-masked]>

Gert,
I think that one of the main drivers of the different needs when going
from L1 to L2 is the fact L1, in SONET is TDM-based, while L2 can be
packet based and have a different paradigm, while when going from HO to
LO one is within the same paradigm. So, point 1 indicates that one
should consider using the same control plane architecture for the
sublayers within L1, but it does not necessarily support the idea that
the same paradigm is best for both L1 and higher layers.  Regarding the
backbone/regional structure, more than only 2 levels may be needed for
global transport networks.

Regards,

Monica A. Lazer
Network Architecture and Reliability
=20
908 234 8462
[email-masked]

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 3:38 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Ash, Gerald R
(Jerry), ALABS; [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Mark,

I am happy to read that we could find some common understanding. About
your
multi-layer issue you've raised, I suggest to figure out more to which
extend
this is an issue for UNI. Some thoughts on that:

  1. Wideband Crossconnects are able to crossconnect low order circuits
(LO),
     and put them into high order circuits (HO). Those Crossconnects are
managed
     by one manager able to control both Layers: LO and HO. I've never
heard
     that an operator let one part of the organization implement HO only
on a
     country wide basis, while another part of the organization is
taking care
     about LO only.
  2. So rather than the pure layering, a kind of regional/backbone
structure is
     in place. Regional NOCs deal with HO and LO whithin the region
while in
     backbone you use HO only because you don't need the finer
granularity
     there. So what appears to be a layering from a management point of
view
     seems to me more a regional kind of separation.

To be clear: I don't want to discuss the fact that there is a layering
in the
network. My point is to highlight that SDH/SONET is in reality not a
single
layer but has at least 4 of them (RS, MS, LO, HO). In theory we should
find in
the network an RS-manager, an MS-Manager, a LO-Manager and a HO-Manager.
Moreover a single Wideband Crossconnect would have had to be managed by
all 4
managers at the same time. Obviously this is not really practical
(immagine: 4
managers, one worker ;-) such that most vendors and carriers decided to
put all
4 layers into one management box - quite similar to what a GMPLS Control
Plane
does with SONET/SDH control.

Just to avoid misunderstandings here: I don't want to start a new thread
on
layering issues. I just want to provide you some food for your own
thoughts
hoping that we can find some common understanding at some point in
future.

Regards

Gert

[email-masked] wrote:

> Gert,
>
> Thanks for outlining the history and your current position for going
> forward.  Mostly, I agree with you.
>
> My major point of disagreement is with your characterization of the
> ITU-T direction.  Though the ITU-T ASON documents might enable
> "'Bandwidth on Demand' services (BOND)" to some degree, that was not
the
> primary focus.  The Optical UNI was a development that came out of the
> OIF and not the ITU-T.  Most carriers have seen the Optical UNI as a
> potential customer interface with far more realistic applications
> internal to networks, i.e. between the L3/L2 elements and the L1/L0
> elements.  Those who have attended the OIF in the past probably
remember
> my unpopular statement on the plenary floor that we were wasting out
> time working on a UNI that had questionable (no?) business advantages
> for the carrier.
>
> I do support the approach you mention (from Kireeti?) that we focus on
> the service points and the information that needs to be exchanged
> between them.  Where most of the services are of the L3/L2 variety,
that
> approach should be successful.  Those items should be fully covered by
> the IETF solutions.
>
> However, that doesn't address the multi-layer issue that we are
> struggling to address, which is one of the root causes of this
conflict
> between the IETF and ITU-T.  The signaling/control for L1/L0 is where
> the ITU-T participants have found the IETF solutions to be inadequate.
> That's not necessarily because the IETF solutions wouldn't work, but
> because they would not satisfy the stringent requirements and models
by
> which we base our management and control for L1/L0.
>
> This whole problem could be blamed on the IP success in the industry.
> If IP had not proven to be so successful, the ITU-T might have chosen
> the optical control plane based on extensions to SS7.  :-)  (Not
meaning
> to ignore the ITU-T alternative solution based on PNNI.)
>
> Regards,
>
> Mark Loyd Jones
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: Gert.Grammel [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 1:21 PM
> To: Mark.Jones
> Cc: ccamp; dwfedyk; gash; mpls
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Mark,
>
> 'improving the coordination between the IETF and ITU-T' is one of the
> things I'd
> like to see since years. However in my experience the true barrier
> between both
> groups is not so much the technology as such, but some ignorance about
> the core
> aspects in both organizations. To give a balanced figure here:
>
>   1. You remember the thread about the non-standard SDH/SONET
> extensions. Here
>      some guys active in GMPLS tried to push their ideas about
> transparency.
>      Obviously this was perceived on ITU-T side as a challenge on the
> purity of
>      a standard (G.707). This one was (almost) setteled by moving all
>      non-standard features to an informal draft.
>   2. Now it is the other way round. Somehow ITU-T extensions got
> accepted (again
>      informational) in IETF which do not comply to the purity of
> RSVP-TE. Due to
>      the fact that this informational RFC was not reviewed in CCAMP
> before, it
>      is perceived as an assault.
>
> So the match is tied up 1:1 but maybe it's now the right time to find
a
> solution
> on how to proceed. What I've seen so far was a complete misperception
of
> what is
> required on either side and why.
>
>   1. ITU-T basically started by defining user services having in mind
> layered
>      transport platforms like OTH and SDH/SONET. Those services can be
>      summarized as 'Bandwidth on Demand' services (BOND). Naturally
this
> led to
>      a very strong focus on UNI interfaces and a kind of ignorance of
> networking
>      protocols. You probably remember the discussions on why not using
> SS7? (For
>      those not familar with the issue: SS7 is the signaling protocol
> between
>      PSTN switches)
>   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE, ...)
> and
>      extending their scope to L1 technologies namely SDH/SONET and
OTH.
>      Naturally this led to a very strong focus on protocol consistency
> and a
>      kind of ignorance on service aspects other than those already
> available in
>      MPLS. You may remember here the discussion about whether UNI is
> useful at
>      all some time ago.
>
> So putting everything together means that it is required to keep
(IETF)
> protocol
> consistency but adding some (ITU-T) specific extensions to well
defined
> service
> points in the network (UNI).
> Unfortunately service points tend to exchange messages between
> themselves and
> this would mean that an intermediate protocol would have had to
support
> such
> kind of communication. What concerns the IETF community is probably
not
> the fact
> that there is a UNI somewhere, but the changes and extensions to
> etablished
> protocols in order to achieve a collaboration between them.
>
> I recall that this was the basic issue with the ITU-T proposal when it
> was
> presented for the first time in Yokohama. The way I've got Kireeti's
> message
> there was: please authors try to let us understand what problem you
want
> to
> solve and tell us which kind of information you have to exchange
between
> which
> points to achieve it. We'll sort out then in CCAMP what would be the
> most
> appropriate way to implement it, while maintaining consistency in our
> protocols.
>
> Although it didn't work the first time I still consider Kireeti's
> suggestion to
> be a wise way to move forward and perhaps the key for harmonic
> collaboration.
>
> Regards
>
> Gert
>
> [email-masked] wrote:
>
> > Gert,
> >
> > I agreed with the intent in generalizing MPLS for the wide range of
> > expected applications.  It was my hope that it would succeed.  At
this
> > point, one might say that the intent has only been partially
achieved.
> > The problem that has come to light over the past year is the fact
that
> > there are finer points of the ITU-T model and requirements that are
> not
> > supported by the current IETF GMPLS RFCs and standards track drafts.
> > Those aspects are considered significant enough by many carriers and
> > their suppliers to warrant further extensions outside of the IETF.
> (My
> > apologies for not understanding those points well enough to clarify
> them
> > even in examples, but there are many people on this list would could
> do
> > so if they thought it necessary.  To avoid any misunderstand, all
> should
> > know that Sprint does not yet have a company position on this.)  It
is
> > my hope that we can come up with ways of improving the coordination
> > between the IETF and ITU-T.  This thread of discussion is bringing
out
> > the issues to make that happen.
> >
> > Regards,
> >
> > Mark Loyd Jones
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: Gert.Grammel [mailto:[email-masked]]
> > Sent: Thursday, March 06, 2003 10:17 AM
> > To: Mark.Jones
> > Cc: dwfedyk; gash; ccamp; mpls
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Mark,
> >
> > please don't forget that due to the 'Generalization' of GMPLS you
are
> > free to do
> > the split at any application level you wish. This was always the
> > advantage of
> > the GMPLS approach compared to the ITU-T model where initially each
> > layer had
> > its own control plane. So the fact that in theory you could use a
> single
> > control
> > plane for all your network means also that you are able to stop
where
> > you want.
> > Nice feature isn't it?
> >
> > Regards
> >
> > Gert
> >
> > [email-masked] wrote:
> >
> > > I agree with the separation of GMPLS into the two applications.
> There
> > > does not appear to be any significant move to collapse the
> management
> > or
> > > signaling for L3/2 and L1/0 at this time, given the different
models
> > > that apply for them and the infrastructures in our companies that
> > manage
> > > them.  The plan for addressing the two applications need not be
the
> > > same.
> > >
> > > The L3/2 application is near and dear to the heart of the IETF.
The
> > > L1/0 application is of interest to those who wish to collapse the
> > > management into a single layer.  In my opinion, the IETF might
also
> > > address this approach, given the IETF participants are the ones in
> > > support of this collapsed management or at least common protocol
> > > solution for what is today two signaling layers.  However, as
stated
> > > before, the collapse approach is not realistic today for a
> > > multi-service, multi-protocol network.
> > >
> > > On the other hand, the L1/0 application requirements and models
have
> > > been defined and are best understood at the ITU-T.  Ideally, the
> > > protocol expertise at the IETF would be applied to the ITU-T model
> and
> > > requirements to address the L1/0 application, but attempts to do
> that
> > > have been met with great resistance in the past.  Perhaps that was
a
> > > result of the fact that GMPLS implementations were not separated
out
> > > into the two different applications.  However, I don't think it is
> > > realistic to expect the IETF experts to be motivated to understand
> the
> > > ITU-T models and requirements, given the application is outside of
> > their
> > > primary area of interest.  That said, I believe the IETF should
> reach
> > an
> > > agreement on how to work with outside groups that develop "major
> > > extensions" to the protocol.
> > >
> > > Mark Loyd Jones
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: dwfedyk [mailto:[email-masked]]
> > > Sent: Thursday, March 06, 2003 7:49 AM
> > > To: gash
> > > Cc: mpls; ccamp
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > Along the lines of Jerry's comments.
> > >
> > > When we put together GMPLS the first drafts were under specified
> > > intentionally to capture the essence of GMPLS. We put aside many
> > > arguments saying lets specify at a high level and fill in the
> details
> > > later. The discussions on this thread are in two major veins one
> > > attempting to fill the details and the other containing and
> > controlling
> > > the changes. GMPLS needs to be specified more accurately and in my
> > > opinion it needs to be decomposed to a more layered approach.  I
> think
> > > if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> > > independently but self similar it would offer a mechanism to move
> > > forward where some legacy systems could be specified to be GMPLS
> > > friendly. For example signaling for Layer 3/2 can be tunneled
> through
> > > the a lower layer. We already have some work in this direction.
> > >  Similarly traffic engineering information for L1/L0 in a TE
> database
> > >  would need different  attributes than a the TE database at L3/2.
I
> > > don't think you want to burden a L3/L2 system with these
attributes
> in
> > > an overlay model. The expertise for these layer is not all
contained
> > in
> > > the IETF. I think we should put a plan forward to make this happen
> > > within the IETF process. After this was accomplished  I think some
> > > people are thinking of collapsing layers even more but the logical
> > > partitioning of layers may help keep the protocols and databases
> > > simpler.   Right now were are treating GMPLS like a big bowl of
> jelly
> > > when it should look more like a layer cake.
> > >
> > > Regards,
> > > Don
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:[email-masked]
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Thu, 06 Mar 2003 14:51:43 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 22:48:37 -0000 

Thanks Gert....I have tried to answer you below.  regards, Neil

Gert Grammel wrote 06 March 2003 19:57
>   1. I never understood why you were so emotional on overlay 
> models as compared
>      to peer but at the same time advocate to use PNNI (Peer 
> Network to Network
>      Interface) as an alternative.
NH=> The L1/0 networks have multiple clients....so there is no peering with
any of them in the control-plane sense.  For external NNIs to a different
operator within the *same* L1 network one would invariably use static
routings.  This is irrespective of the actual choice of signalling protocol.

>   2. The addressing issue you've raised is related to UNI 
> which was so far
>      (until recently) not part of the CCAMP work. So I don't 
> see here that you
>      were forced to use IPv4 Addresses.
NH=> It would make more sense to introduce V6 here IMO....the point on V4 is
not to start with a limited address space if there is no reason to.

>   3. About RSVP vs. PNNI I am not religious, why not using 
> SS7? In any case I
>      don't think that the IETF is the right place to discuss 
> on PNNI. Honestly I
>      don't know which one is 'better' but I don't believe 
> that it is always the
>      best protocol that will win at the end. If you have one 
> why do you need yet
>      another one (and in IETF we had already two ;-)?
NH=> There is more operational experience of pnni and in the opinion of our
signalling experts its a better choice than RSVP.

>   4. I don't see your point on running a routing protocol on 
> L1/0 why no just
>      using RSVP-TE signaling and omit OSPF?
NH=> You could do this I guess. 

>   5. About the access to centralized databases and management 
> system I believe a
>      solution could be found once the specific aplication and 
> communications
>      requrements are clear. I don't see GMPLS excluding this at all.
NH=> True.  However, hope you understand why we see the NMS as being *the*
overriding reference.
> 
> As an observation I'd like to say that all your arguments are 
> equally valid
> applicable to any Layer technology and not specific to L1/0. 
NH=> They don't apply to a cnls mode.  But I agree many of the aspects could
apply to a co pkt-sw mode.
<snipped to end>

Delivery-date: Thu, 06 Mar 2003 12:39:27 -0800
Date: Thu, 06 Mar 2003 21:38:28 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Mark,

I am happy to read that we could find some common understanding. About your
multi-layer issue you've raised, I suggest to figure out more to which extend
this is an issue for UNI. Some thoughts on that:

  1. Wideband Crossconnects are able to crossconnect low order circuits (LO),
     and put them into high order circuits (HO). Those Crossconnects are managed
     by one manager able to control both Layers: LO and HO. I've never heard
     that an operator let one part of the organization implement HO only on a
     country wide basis, while another part of the organization is taking care
     about LO only.
  2. So rather than the pure layering, a kind of regional/backbone structure is
     in place. Regional NOCs deal with HO and LO whithin the region while in
     backbone you use HO only because you don't need the finer granularity
     there. So what appears to be a layering from a management point of view
     seems to me more a regional kind of separation.

To be clear: I don't want to discuss the fact that there is a layering in the
network. My point is to highlight that SDH/SONET is in reality not a single
layer but has at least 4 of them (RS, MS, LO, HO). In theory we should find in
the network an RS-manager, an MS-Manager, a LO-Manager and a HO-Manager.
Moreover a single Wideband Crossconnect would have had to be managed by all 4
managers at the same time. Obviously this is not really practical (immagine: 4
managers, one worker ;-) such that most vendors and carriers decided to put all
4 layers into one management box - quite similar to what a GMPLS Control Plane
does with SONET/SDH control.

Just to avoid misunderstandings here: I don't want to start a new thread on
layering issues. I just want to provide you some food for your own thoughts
hoping that we can find some common understanding at some point in future.

Regards

Gert

[email-masked] wrote:

> Gert,
>
> Thanks for outlining the history and your current position for going
> forward.  Mostly, I agree with you.
>
> My major point of disagreement is with your characterization of the
> ITU-T direction.  Though the ITU-T ASON documents might enable
> "'Bandwidth on Demand' services (BOND)" to some degree, that was not the
> primary focus.  The Optical UNI was a development that came out of the
> OIF and not the ITU-T.  Most carriers have seen the Optical UNI as a
> potential customer interface with far more realistic applications
> internal to networks, i.e. between the L3/L2 elements and the L1/L0
> elements.  Those who have attended the OIF in the past probably remember
> my unpopular statement on the plenary floor that we were wasting out
> time working on a UNI that had questionable (no?) business advantages
> for the carrier.
>
> I do support the approach you mention (from Kireeti?) that we focus on
> the service points and the information that needs to be exchanged
> between them.  Where most of the services are of the L3/L2 variety, that
> approach should be successful.  Those items should be fully covered by
> the IETF solutions.
>
> However, that doesn't address the multi-layer issue that we are
> struggling to address, which is one of the root causes of this conflict
> between the IETF and ITU-T.  The signaling/control for L1/L0 is where
> the ITU-T participants have found the IETF solutions to be inadequate.
> That's not necessarily because the IETF solutions wouldn't work, but
> because they would not satisfy the stringent requirements and models by
> which we base our management and control for L1/L0.
>
> This whole problem could be blamed on the IP success in the industry.
> If IP had not proven to be so successful, the ITU-T might have chosen
> the optical control plane based on extensions to SS7.  :-)  (Not meaning
> to ignore the ITU-T alternative solution based on PNNI.)
>
> Regards,
>
> Mark Loyd Jones
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: Gert.Grammel [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 1:21 PM
> To: Mark.Jones
> Cc: ccamp; dwfedyk; gash; mpls
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Mark,
>
> 'improving the coordination between the IETF and ITU-T' is one of the
> things I'd
> like to see since years. However in my experience the true barrier
> between both
> groups is not so much the technology as such, but some ignorance about
> the core
> aspects in both organizations. To give a balanced figure here:
>
>   1. You remember the thread about the non-standard SDH/SONET
> extensions. Here
>      some guys active in GMPLS tried to push their ideas about
> transparency.
>      Obviously this was perceived on ITU-T side as a challenge on the
> purity of
>      a standard (G.707). This one was (almost) setteled by moving all
>      non-standard features to an informal draft.
>   2. Now it is the other way round. Somehow ITU-T extensions got
> accepted (again
>      informational) in IETF which do not comply to the purity of
> RSVP-TE. Due to
>      the fact that this informational RFC was not reviewed in CCAMP
> before, it
>      is perceived as an assault.
>
> So the match is tied up 1:1 but maybe it's now the right time to find a
> solution
> on how to proceed. What I've seen so far was a complete misperception of
> what is
> required on either side and why.
>
>   1. ITU-T basically started by defining user services having in mind
> layered
>      transport platforms like OTH and SDH/SONET. Those services can be
>      summarized as 'Bandwidth on Demand' services (BOND). Naturally this
> led to
>      a very strong focus on UNI interfaces and a kind of ignorance of
> networking
>      protocols. You probably remember the discussions on why not using
> SS7? (For
>      those not familar with the issue: SS7 is the signaling protocol
> between
>      PSTN switches)
>   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE, ...)
> and
>      extending their scope to L1 technologies namely SDH/SONET and OTH.
>      Naturally this led to a very strong focus on protocol consistency
> and a
>      kind of ignorance on service aspects other than those already
> available in
>      MPLS. You may remember here the discussion about whether UNI is
> useful at
>      all some time ago.
>
> So putting everything together means that it is required to keep (IETF)
> protocol
> consistency but adding some (ITU-T) specific extensions to well defined
> service
> points in the network (UNI).
> Unfortunately service points tend to exchange messages between
> themselves and
> this would mean that an intermediate protocol would have had to support
> such
> kind of communication. What concerns the IETF community is probably not
> the fact
> that there is a UNI somewhere, but the changes and extensions to
> etablished
> protocols in order to achieve a collaboration between them.
>
> I recall that this was the basic issue with the ITU-T proposal when it
> was
> presented for the first time in Yokohama. The way I've got Kireeti's
> message
> there was: please authors try to let us understand what problem you want
> to
> solve and tell us which kind of information you have to exchange between
> which
> points to achieve it. We'll sort out then in CCAMP what would be the
> most
> appropriate way to implement it, while maintaining consistency in our
> protocols.
>
> Although it didn't work the first time I still consider Kireeti's
> suggestion to
> be a wise way to move forward and perhaps the key for harmonic
> collaboration.
>
> Regards
>
> Gert
>
> [email-masked] wrote:
>
> > Gert,
> >
> > I agreed with the intent in generalizing MPLS for the wide range of
> > expected applications.  It was my hope that it would succeed.  At this
> > point, one might say that the intent has only been partially achieved.
> > The problem that has come to light over the past year is the fact that
> > there are finer points of the ITU-T model and requirements that are
> not
> > supported by the current IETF GMPLS RFCs and standards track drafts.
> > Those aspects are considered significant enough by many carriers and
> > their suppliers to warrant further extensions outside of the IETF.
> (My
> > apologies for not understanding those points well enough to clarify
> them
> > even in examples, but there are many people on this list would could
> do
> > so if they thought it necessary.  To avoid any misunderstand, all
> should
> > know that Sprint does not yet have a company position on this.)  It is
> > my hope that we can come up with ways of improving the coordination
> > between the IETF and ITU-T.  This thread of discussion is bringing out
> > the issues to make that happen.
> >
> > Regards,
> >
> > Mark Loyd Jones
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: Gert.Grammel [mailto:[email-masked]]
> > Sent: Thursday, March 06, 2003 10:17 AM
> > To: Mark.Jones
> > Cc: dwfedyk; gash; ccamp; mpls
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Mark,
> >
> > please don't forget that due to the 'Generalization' of GMPLS you are
> > free to do
> > the split at any application level you wish. This was always the
> > advantage of
> > the GMPLS approach compared to the ITU-T model where initially each
> > layer had
> > its own control plane. So the fact that in theory you could use a
> single
> > control
> > plane for all your network means also that you are able to stop where
> > you want.
> > Nice feature isn't it?
> >
> > Regards
> >
> > Gert
> >
> > [email-masked] wrote:
> >
> > > I agree with the separation of GMPLS into the two applications.
> There
> > > does not appear to be any significant move to collapse the
> management
> > or
> > > signaling for L3/2 and L1/0 at this time, given the different models
> > > that apply for them and the infrastructures in our companies that
> > manage
> > > them.  The plan for addressing the two applications need not be the
> > > same.
> > >
> > > The L3/2 application is near and dear to the heart of the IETF.  The
> > > L1/0 application is of interest to those who wish to collapse the
> > > management into a single layer.  In my opinion, the IETF might also
> > > address this approach, given the IETF participants are the ones in
> > > support of this collapsed management or at least common protocol
> > > solution for what is today two signaling layers.  However, as stated
> > > before, the collapse approach is not realistic today for a
> > > multi-service, multi-protocol network.
> > >
> > > On the other hand, the L1/0 application requirements and models have
> > > been defined and are best understood at the ITU-T.  Ideally, the
> > > protocol expertise at the IETF would be applied to the ITU-T model
> and
> > > requirements to address the L1/0 application, but attempts to do
> that
> > > have been met with great resistance in the past.  Perhaps that was a
> > > result of the fact that GMPLS implementations were not separated out
> > > into the two different applications.  However, I don't think it is
> > > realistic to expect the IETF experts to be motivated to understand
> the
> > > ITU-T models and requirements, given the application is outside of
> > their
> > > primary area of interest.  That said, I believe the IETF should
> reach
> > an
> > > agreement on how to work with outside groups that develop "major
> > > extensions" to the protocol.
> > >
> > > Mark Loyd Jones
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: dwfedyk [mailto:[email-masked]]
> > > Sent: Thursday, March 06, 2003 7:49 AM
> > > To: gash
> > > Cc: mpls; ccamp
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > Along the lines of Jerry's comments.
> > >
> > > When we put together GMPLS the first drafts were under specified
> > > intentionally to capture the essence of GMPLS. We put aside many
> > > arguments saying lets specify at a high level and fill in the
> details
> > > later. The discussions on this thread are in two major veins one
> > > attempting to fill the details and the other containing and
> > controlling
> > > the changes. GMPLS needs to be specified more accurately and in my
> > > opinion it needs to be decomposed to a more layered approach.  I
> think
> > > if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> > > independently but self similar it would offer a mechanism to move
> > > forward where some legacy systems could be specified to be GMPLS
> > > friendly. For example signaling for Layer 3/2 can be tunneled
> through
> > > the a lower layer. We already have some work in this direction.
> > >  Similarly traffic engineering information for L1/L0 in a TE
> database
> > >  would need different  attributes than a the TE database at L3/2. I
> > > don't think you want to burden a L3/L2 system with these attributes
> in
> > > an overlay model. The expertise for these layer is not all contained
> > in
> > > the IETF. I think we should put a plan forward to make this happen
> > > within the IETF process. After this was accomplished  I think some
> > > people are thinking of collapsing layers even more but the logical
> > > partitioning of layers may help keep the protocols and databases
> > > simpler.   Right now were are treating GMPLS like a big bowl of
> jelly
> > > when it should look more like a layer cake.
> > >
> > > Regards,
> > > Don
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:[email-masked]
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Thu, 06 Mar 2003 12:08:33 -0800
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Gert Grammel'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 15:07:23 -0500 

Hi,

I'm somewhat surprised that in the discussion of requirements, there's
been no reference to the ipo wg internet draft

http://www.ietf.org/internet-drafts/draft-ietf-ipo-carrier-requirements-05.txt

Eve

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 2:21 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Mark,

'improving the coordination between the IETF and ITU-T' is one of the things I'd
like to see since years. However in my experience the true barrier between both
groups is not so much the technology as such, but some ignorance about the core
aspects in both organizations. To give a balanced figure here:

  1. You remember the thread about the non-standard SDH/SONET extensions. Here
     some guys active in GMPLS tried to push their ideas about transparency.
     Obviously this was perceived on ITU-T side as a challenge on the purity of
     a standard (G.707). This one was (almost) setteled by moving all
     non-standard features to an informal draft.
  2. Now it is the other way round. Somehow ITU-T extensions got accepted (again
     informational) in IETF which do not comply to the purity of RSVP-TE. Due to
     the fact that this informational RFC was not reviewed in CCAMP before, it
     is perceived as an assault.

So the match is tied up 1:1 but maybe it's now the right time to find a solution
on how to proceed. What I've seen so far was a complete misperception of what is
required on either side and why.

  1. ITU-T basically started by defining user services having in mind layered
     transport platforms like OTH and SDH/SONET. Those services can be
     summarized as 'Bandwidth on Demand' services (BOND). Naturally this led to
     a very strong focus on UNI interfaces and a kind of ignorance of networking
     protocols. You probably remember the discussions on why not using SS7? (For
     those not familar with the issue: SS7 is the signaling protocol between
     PSTN switches)
  2. IETF started with established L2/3 protocols (OSPF, RSVP-TE, ...) and
     extending their scope to L1 technologies namely SDH/SONET and OTH.
     Naturally this led to a very strong focus on protocol consistency and a
     kind of ignorance on service aspects other than those already available in
     MPLS. You may remember here the discussion about whether UNI is useful at
     all some time ago.

So putting everything together means that it is required to keep (IETF) protocol
consistency but adding some (ITU-T) specific extensions to well defined service
points in the network (UNI).
Unfortunately service points tend to exchange messages between themselves and
this would mean that an intermediate protocol would have had to support such
kind of communication. What concerns the IETF community is probably not the fact
that there is a UNI somewhere, but the changes and extensions to etablished
protocols in order to achieve a collaboration between them.

I recall that this was the basic issue with the ITU-T proposal when it was
presented for the first time in Yokohama. The way I've got Kireeti's message
there was: please authors try to let us understand what problem you want to
solve and tell us which kind of information you have to exchange between which
points to achieve it. We'll sort out then in CCAMP what would be the most
appropriate way to implement it, while maintaining consistency in our protocols.

Although it didn't work the first time I still consider Kireeti's suggestion to
be a wise way to move forward and perhaps the key for harmonic collaboration.

Regards

Gert

[email-masked] wrote:

> Gert,
>
> I agreed with the intent in generalizing MPLS for the wide range of
> expected applications.  It was my hope that it would succeed.  At this
> point, one might say that the intent has only been partially achieved.
> The problem that has come to light over the past year is the fact that
> there are finer points of the ITU-T model and requirements that are not
> supported by the current IETF GMPLS RFCs and standards track drafts.
> Those aspects are considered significant enough by many carriers and
> their suppliers to warrant further extensions outside of the IETF.  (My
> apologies for not understanding those points well enough to clarify them
> even in examples, but there are many people on this list would could do
> so if they thought it necessary.  To avoid any misunderstand, all should
> know that Sprint does not yet have a company position on this.)  It is
> my hope that we can come up with ways of improving the coordination
> between the IETF and ITU-T.  This thread of discussion is bringing out
> the issues to make that happen.
>
> Regards,
>
> Mark Loyd Jones
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: Gert.Grammel [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 10:17 AM
> To: Mark.Jones
> Cc: dwfedyk; gash; ccamp; mpls
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Mark,
>
> please don't forget that due to the 'Generalization' of GMPLS you are
> free to do
> the split at any application level you wish. This was always the
> advantage of
> the GMPLS approach compared to the ITU-T model where initially each
> layer had
> its own control plane. So the fact that in theory you could use a single
> control
> plane for all your network means also that you are able to stop where
> you want.
> Nice feature isn't it?
>
> Regards
>
> Gert
>
> [email-masked] wrote:
>
> > I agree with the separation of GMPLS into the two applications.  There
> > does not appear to be any significant move to collapse the management
> or
> > signaling for L3/2 and L1/0 at this time, given the different models
> > that apply for them and the infrastructures in our companies that
> manage
> > them.  The plan for addressing the two applications need not be the
> > same.
> >
> > The L3/2 application is near and dear to the heart of the IETF.  The
> > L1/0 application is of interest to those who wish to collapse the
> > management into a single layer.  In my opinion, the IETF might also
> > address this approach, given the IETF participants are the ones in
> > support of this collapsed management or at least common protocol
> > solution for what is today two signaling layers.  However, as stated
> > before, the collapse approach is not realistic today for a
> > multi-service, multi-protocol network.
> >
> > On the other hand, the L1/0 application requirements and models have
> > been defined and are best understood at the ITU-T.  Ideally, the
> > protocol expertise at the IETF would be applied to the ITU-T model and
> > requirements to address the L1/0 application, but attempts to do that
> > have been met with great resistance in the past.  Perhaps that was a
> > result of the fact that GMPLS implementations were not separated out
> > into the two different applications.  However, I don't think it is
> > realistic to expect the IETF experts to be motivated to understand the
> > ITU-T models and requirements, given the application is outside of
> their
> > primary area of interest.  That said, I believe the IETF should reach
> an
> > agreement on how to work with outside groups that develop "major
> > extensions" to the protocol.
> >
> > Mark Loyd Jones
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: dwfedyk [mailto:[email-masked]]
> > Sent: Thursday, March 06, 2003 7:49 AM
> > To: gash
> > Cc: mpls; ccamp
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Along the lines of Jerry's comments.
> >
> > When we put together GMPLS the first drafts were under specified
> > intentionally to capture the essence of GMPLS. We put aside many
> > arguments saying lets specify at a high level and fill in the details
> > later. The discussions on this thread are in two major veins one
> > attempting to fill the details and the other containing and
> controlling
> > the changes. GMPLS needs to be specified more accurately and in my
> > opinion it needs to be decomposed to a more layered approach.  I think
> > if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> > independently but self similar it would offer a mechanism to move
> > forward where some legacy systems could be specified to be GMPLS
> > friendly. For example signaling for Layer 3/2 can be tunneled through
> > the a lower layer. We already have some work in this direction.
> >  Similarly traffic engineering information for L1/L0 in a TE database
> >  would need different  attributes than a the TE database at L3/2. I
> > don't think you want to burden a L3/L2 system with these attributes in
> > an overlay model. The expertise for these layer is not all contained
> in
> > the IETF. I think we should put a plan forward to make this happen
> > within the IETF process. After this was accomplished  I think some
> > people are thinking of collapsing layers even more but the logical
> > partitioning of layers may help keep the protocols and databases
> > simpler.   Right now were are treating GMPLS like a big bowl of jelly
> > when it should look more like a layer cake.
> >
> > Regards,
> > Don
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Thu, 06 Mar 2003 11:57:45 -0800
Date: Thu, 06 Mar 2003 20:56:41 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Neil,

I know that you've had a hard time in the past with your arguments. To comment
to some of them:

  1. I never understood why you were so emotional on overlay models as compared
     to peer but at the same time advocate to use PNNI (Peer Network to Network
     Interface) as an alternative.
  2. The addressing issue you've raised is related to UNI which was so far
     (until recently) not part of the CCAMP work. So I don't see here that you
     were forced to use IPv4 Addresses.
  3. About RSVP vs. PNNI I am not religious, why not using SS7? In any case I
     don't think that the IETF is the right place to discuss on PNNI. Honestly I
     don't know which one is 'better' but I don't believe that it is always the
     best protocol that will win at the end. If you have one why do you need yet
     another one (and in IETF we had already two ;-)?
  4. I don't see your point on running a routing protocol on L1/0 why no just
     using RSVP-TE signaling and omit OSPF?
  5. About the access to centralized databases and management system I believe a
     solution could be found once the specific aplication and communications
     requrements are clear. I don't see GMPLS excluding this at all.

As an observation I'd like to say that all your arguments are equally valid
applicable to any Layer technology and not specific to L1/0. I say this because
it seems to me that Mark understood that there are very specific L1/0 points
which are under 'hot discussion'. I am not aware of those, but you may want to
correct me there.

Regards

Gert

[email-masked] wrote:

> Gert....its not a nice feature if you don't want to use the forced
> functional component set.
>
> Ignoring the commercial vertical (client/server) and horizontal (same layer
> partitioning) requirements for functional decoupling, there are certain
> behaviours an operator may wish to use at L1/0 that are different to those
> the operator may wish to use in a L3/2 network.  Operators may want the
> freedom to choose what they consider (whether others agree with them or not)
> what they perceive as best-of-breed components.  For example, why should an
> operator be forced to use v4 addressing for the user-plane access points at
> L1/0?  Why should they be forced to use RSVP-TE signalling if they believe
> pnni signalling is better?  Why should they be forced to run a routing
> protocol at L1/0 (they may want discovery aspects however and the ability to
> hold a routing cache) when they need access to centralised records (eg duct
> records), and moreover they want their management system to retain
> absolute/overriding control?  It's not clear to me operators have such
> degrees of freedom here.
>
> regards, Neil
>
> > -----Original Message-----
> > From: Gert Grammel [mailto:[email-masked]]
> > Sent: 06 March 2003 16:17
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> >
> > Mark,
> >
> > please don't forget that due to the 'Generalization' of GMPLS
> > you are free to do
> > the split at any application level you wish. This was always
> > the advantage of
> > the GMPLS approach compared to the ITU-T model where
> > initially each layer had
> > its own control plane. So the fact that in theory you could
> > use a single control
> > plane for all your network means also that you are able to
> > stop where you want.
> > Nice feature isn't it?
> >
> > Regards
> >
> > Gert
> >
> > [email-masked] wrote:
> >
> > > I agree with the separation of GMPLS into the two
> > applications.  There
> > > does not appear to be any significant move to collapse the
> > management or
> > > signaling for L3/2 and L1/0 at this time, given the different models
> > > that apply for them and the infrastructures in our
> > companies that manage
> > > them.  The plan for addressing the two applications need not be the
> > > same.
> > >
> > > The L3/2 application is near and dear to the heart of the IETF.  The
> > > L1/0 application is of interest to those who wish to collapse the
> > > management into a single layer.  In my opinion, the IETF might also
> > > address this approach, given the IETF participants are the ones in
> > > support of this collapsed management or at least common protocol
> > > solution for what is today two signaling layers.  However, as stated
> > > before, the collapse approach is not realistic today for a
> > > multi-service, multi-protocol network.
> > >
> > > On the other hand, the L1/0 application requirements and models have
> > > been defined and are best understood at the ITU-T.  Ideally, the
> > > protocol expertise at the IETF would be applied to the
> > ITU-T model and
> > > requirements to address the L1/0 application, but attempts
> > to do that
> > > have been met with great resistance in the past.  Perhaps that was a
> > > result of the fact that GMPLS implementations were not separated out
> > > into the two different applications.  However, I don't think it is
> > > realistic to expect the IETF experts to be motivated to
> > understand the
> > > ITU-T models and requirements, given the application is
> > outside of their
> > > primary area of interest.  That said, I believe the IETF
> > should reach an
> > > agreement on how to work with outside groups that develop "major
> > > extensions" to the protocol.
> > >
> > > Mark Loyd Jones
> > > Optical Transport and Networking
> > > Sprint - Wireline Technology Development
> > > 913-794-2139
> > >
> > >
> > > -----Original Message-----
> > > From: dwfedyk [mailto:[email-masked]]
> > > Sent: Thursday, March 06, 2003 7:49 AM
> > > To: gash
> > > Cc: mpls; ccamp
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > > Along the lines of Jerry's comments.
> > >
> > > When we put together GMPLS the first drafts were under specified
> > > intentionally to capture the essence of GMPLS. We put aside many
> > > arguments saying lets specify at a high level and fill in
> > the details
> > > later. The discussions on this thread are in two major veins one
> > > attempting to fill the details and the other containing and
> > controlling
> > > the changes. GMPLS needs to be specified more accurately and in my
> > > opinion it needs to be decomposed to a more layered
> > approach.  I think
> > > if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> > > independently but self similar it would offer a mechanism to move
> > > forward where some legacy systems could be specified to be GMPLS
> > > friendly. For example signaling for Layer 3/2 can be
> > tunneled through
> > > the a lower layer. We already have some work in this direction.
> > >  Similarly traffic engineering information for L1/L0 in a
> > TE database
> > >  would need different  attributes than a the TE database at L3/2. I
> > > don't think you want to burden a L3/L2 system with these
> > attributes in
> > > an overlay model. The expertise for these layer is not all
> > contained in
> > > the IETF. I think we should put a plan forward to make this happen
> > > within the IETF process. After this was accomplished  I think some
> > > people are thinking of collapsing layers even more but the logical
> > > partitioning of layers may help keep the protocols and databases
> > > simpler.   Right now were are treating GMPLS like a big
> > bowl of jelly
> > > when it should look more like a layer cake.
> > >
> > > Regards,
> > > Don
> >
> > --
> > Alcatel Optical Network Division    Gert Grammel
> > Network Strategy                    phone: +49 711 821 47368
> > Lorenzstrasse 10                    fax: +49 711 821 43169
> > D-70435 Stuttgart                   mailto:[email-masked]
> >
> >
> >
> >

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Thu, 06 Mar 2003 11:53:06 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: draft-ietf-ccamp-gmpls-sonet-sdh-08.txt not yet approved
Date: Thu, 6 Mar 2003 20:52:31 +0100 

The IESG did not yet approve this document today.
The security aspects are not clear yet, and the 
Security AD(s) is/are (re-)checking.
I hope to hear their exact/detailed concerns (if any)
soon.

Thanks,
Bert 

Delivery-date: Thu, 06 Mar 2003 11:43:57 -0800
From: [email-masked]
Date: Thu, 6 Mar 2003 13:43:13 -0600
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
TO: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]

Gert,

Thanks for outlining the history and your current position for going 
forward.  Mostly, I agree with you.

My major point of disagreement is with your characterization of the 
ITU-T direction.  Though the ITU-T ASON documents might enable 
"'Bandwidth on Demand' services (BOND)" to some degree, that was not the 
primary focus.  The Optical UNI was a development that came out of the 
OIF and not the ITU-T.  Most carriers have seen the Optical UNI as a 
potential customer interface with far more realistic applications 
internal to networks, i.e. between the L3/L2 elements and the L1/L0 
elements.  Those who have attended the OIF in the past probably remember 
my unpopular statement on the plenary floor that we were wasting out 
time working on a UNI that had questionable (no?) business advantages 
for the carrier.

I do support the approach you mention (from Kireeti?) that we focus on 
the service points and the information that needs to be exchanged 
between them.  Where most of the services are of the L3/L2 variety, that 
approach should be successful.  Those items should be fully covered by 
the IETF solutions.

However, that doesn't address the multi-layer issue that we are 
struggling to address, which is one of the root causes of this conflict 
between the IETF and ITU-T.  The signaling/control for L1/L0 is where 
the ITU-T participants have found the IETF solutions to be inadequate.  
That's not necessarily because the IETF solutions wouldn't work, but 
because they would not satisfy the stringent requirements and models by 
which we base our management and control for L1/L0.

This whole problem could be blamed on the IP success in the industry.  
If IP had not proven to be so successful, the ITU-T might have chosen 
the optical control plane based on extensions to SS7.  :-)  (Not meaning 
to ignore the ITU-T alternative solution based on PNNI.)

Regards,

Mark Loyd Jones
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139

-----Original Message-----
From: Gert.Grammel [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 1:21 PM
To: Mark.Jones
Cc: ccamp; dwfedyk; gash; mpls
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Mark,

'improving the coordination between the IETF and ITU-T' is one of the 
things I'd
like to see since years. However in my experience the true barrier 
between both
groups is not so much the technology as such, but some ignorance about 
the core
aspects in both organizations. To give a balanced figure here:

  1. You remember the thread about the non-standard SDH/SONET 
extensions. Here
     some guys active in GMPLS tried to push their ideas about 
transparency.
     Obviously this was perceived on ITU-T side as a challenge on the 
purity of
     a standard (G.707). This one was (almost) setteled by moving all
     non-standard features to an informal draft.
  2. Now it is the other way round. Somehow ITU-T extensions got 
accepted (again
     informational) in IETF which do not comply to the purity of 
RSVP-TE. Due to
     the fact that this informational RFC was not reviewed in CCAMP 
before, it
     is perceived as an assault.

So the match is tied up 1:1 but maybe it's now the right time to find a 
solution
on how to proceed. What I've seen so far was a complete misperception of 
what is
required on either side and why.

  1. ITU-T basically started by defining user services having in mind 
layered
     transport platforms like OTH and SDH/SONET. Those services can be
     summarized as 'Bandwidth on Demand' services (BOND). Naturally this 
led to
     a very strong focus on UNI interfaces and a kind of ignorance of 
networking
     protocols. You probably remember the discussions on why not using 
SS7? (For
     those not familar with the issue: SS7 is the signaling protocol 
between
     PSTN switches)
  2. IETF started with established L2/3 protocols (OSPF, RSVP-TE, ...) 
and
     extending their scope to L1 technologies namely SDH/SONET and OTH.
     Naturally this led to a very strong focus on protocol consistency 
and a
     kind of ignorance on service aspects other than those already 
available in
     MPLS. You may remember here the discussion about whether UNI is 
useful at
     all some time ago.

So putting everything together means that it is required to keep (IETF) 
protocol
consistency but adding some (ITU-T) specific extensions to well defined 
service
points in the network (UNI).
Unfortunately service points tend to exchange messages between 
themselves and
this would mean that an intermediate protocol would have had to support 
such
kind of communication. What concerns the IETF community is probably not 
the fact
that there is a UNI somewhere, but the changes and extensions to 
etablished
protocols in order to achieve a collaboration between them.

I recall that this was the basic issue with the ITU-T proposal when it 
was
presented for the first time in Yokohama. The way I've got Kireeti's 
message
there was: please authors try to let us understand what problem you want 
to
solve and tell us which kind of information you have to exchange between 
which
points to achieve it. We'll sort out then in CCAMP what would be the 
most
appropriate way to implement it, while maintaining consistency in our 
protocols.

Although it didn't work the first time I still consider Kireeti's 
suggestion to
be a wise way to move forward and perhaps the key for harmonic 
collaboration.

Regards

Gert

[email-masked] wrote:

> Gert,
>
> I agreed with the intent in generalizing MPLS for the wide range of
> expected applications.  It was my hope that it would succeed.  At this
> point, one might say that the intent has only been partially achieved.
> The problem that has come to light over the past year is the fact that
> there are finer points of the ITU-T model and requirements that are 
not
> supported by the current IETF GMPLS RFCs and standards track drafts.
> Those aspects are considered significant enough by many carriers and
> their suppliers to warrant further extensions outside of the IETF.  
(My
> apologies for not understanding those points well enough to clarify 
them
> even in examples, but there are many people on this list would could 
do
> so if they thought it necessary.  To avoid any misunderstand, all 
should
> know that Sprint does not yet have a company position on this.)  It is
> my hope that we can come up with ways of improving the coordination
> between the IETF and ITU-T.  This thread of discussion is bringing out
> the issues to make that happen.
>
> Regards,
>
> Mark Loyd Jones
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: Gert.Grammel [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 10:17 AM
> To: Mark.Jones
> Cc: dwfedyk; gash; ccamp; mpls
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Mark,
>
> please don't forget that due to the 'Generalization' of GMPLS you are
> free to do
> the split at any application level you wish. This was always the
> advantage of
> the GMPLS approach compared to the ITU-T model where initially each
> layer had
> its own control plane. So the fact that in theory you could use a 
single
> control
> plane for all your network means also that you are able to stop where
> you want.
> Nice feature isn't it?
>
> Regards
>
> Gert
>
> [email-masked] wrote:
>
> > I agree with the separation of GMPLS into the two applications.  
There
> > does not appear to be any significant move to collapse the 
management
> or
> > signaling for L3/2 and L1/0 at this time, given the different models
> > that apply for them and the infrastructures in our companies that
> manage
> > them.  The plan for addressing the two applications need not be the
> > same.
> >
> > The L3/2 application is near and dear to the heart of the IETF.  The
> > L1/0 application is of interest to those who wish to collapse the
> > management into a single layer.  In my opinion, the IETF might also
> > address this approach, given the IETF participants are the ones in
> > support of this collapsed management or at least common protocol
> > solution for what is today two signaling layers.  However, as stated
> > before, the collapse approach is not realistic today for a
> > multi-service, multi-protocol network.
> >
> > On the other hand, the L1/0 application requirements and models have
> > been defined and are best understood at the ITU-T.  Ideally, the
> > protocol expertise at the IETF would be applied to the ITU-T model 
and
> > requirements to address the L1/0 application, but attempts to do 
that
> > have been met with great resistance in the past.  Perhaps that was a
> > result of the fact that GMPLS implementations were not separated out
> > into the two different applications.  However, I don't think it is
> > realistic to expect the IETF experts to be motivated to understand 
the
> > ITU-T models and requirements, given the application is outside of
> their
> > primary area of interest.  That said, I believe the IETF should 
reach
> an
> > agreement on how to work with outside groups that develop "major
> > extensions" to the protocol.
> >
> > Mark Loyd Jones
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: dwfedyk [mailto:[email-masked]]
> > Sent: Thursday, March 06, 2003 7:49 AM
> > To: gash
> > Cc: mpls; ccamp
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Along the lines of Jerry's comments.
> >
> > When we put together GMPLS the first drafts were under specified
> > intentionally to capture the essence of GMPLS. We put aside many
> > arguments saying lets specify at a high level and fill in the 
details
> > later. The discussions on this thread are in two major veins one
> > attempting to fill the details and the other containing and
> controlling
> > the changes. GMPLS needs to be specified more accurately and in my
> > opinion it needs to be decomposed to a more layered approach.  I 
think
> > if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> > independently but self similar it would offer a mechanism to move
> > forward where some legacy systems could be specified to be GMPLS
> > friendly. For example signaling for Layer 3/2 can be tunneled 
through
> > the a lower layer. We already have some work in this direction.
> >  Similarly traffic engineering information for L1/L0 in a TE 
database
> >  would need different  attributes than a the TE database at L3/2. I
> > don't think you want to burden a L3/L2 system with these attributes 
in
> > an overlay model. The expertise for these layer is not all contained
> in
> > the IETF. I think we should put a plan forward to make this happen
> > within the IETF process. After this was accomplished  I think some
> > people are thinking of collapsing layers even more but the logical
> > partitioning of layers may help keep the protocols and databases
> > simpler.   Right now were are treating GMPLS like a big bowl of 
jelly
> > when it should look more like a layer cake.
> >
> > Regards,
> > Don
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Thu, 06 Mar 2003 11:35:45 -0800
From: Shahram Davari <[email-masked]>
To: [email-masked], [email-masked]
Subject: draft-iesg-vendor-extensions-00.txt
Date: Thu, 6 Mar 2003 11:35:16 -0800 

Hi All,

I would like to make an alternative proposal to what is proposed in this draft.
I think that IETF should not prevent other SDOs from developing extensions (minor or major),
to IETF protocols, as long as they don't call those extensions being IETF compliant.
I think IETF could recommend that the other SDOs present their protocol extensions
to IETF (in the form of a draft). The IETF community then has 3 choices:

1) IETF agrees with the requirements and nature of the extensions and find them useful. In that case IETF could engage in technical discussions with the other SDO and reach to a mutually agreeable draft, which could then be advanced to Proposed Standard.

2) IETF agrees with the requirement, but does not agree with the proposed extension, and prefers other solutions/extensions that it thinks meet those requirements. In that case IETF could develop its solution and present it to the requesting SDO. If that SDO is satisfied with
IETF's solution, then fine, otherwise nobody can prevent them from developing their own extension. If that happens then there would be two solutions for the same requirements
and we should let the Market decide which solution/extension do they prefer.

3) IETF does not agree with the requirement for such extensions at all. In that case, the
other SDO should be free to developed their own extension, provided they don't call those extensions to be IETF compliant.

Thanks,
-Shahram

Delivery-date: Thu, 06 Mar 2003 11:22:23 -0800
Date: Thu, 06 Mar 2003 20:21:25 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Mark,

'improving the coordination between the IETF and ITU-T' is one of the things I'd
like to see since years. However in my experience the true barrier between both
groups is not so much the technology as such, but some ignorance about the core
aspects in both organizations. To give a balanced figure here:

  1. You remember the thread about the non-standard SDH/SONET extensions. Here
     some guys active in GMPLS tried to push their ideas about transparency.
     Obviously this was perceived on ITU-T side as a challenge on the purity of
     a standard (G.707). This one was (almost) setteled by moving all
     non-standard features to an informal draft.
  2. Now it is the other way round. Somehow ITU-T extensions got accepted (again
     informational) in IETF which do not comply to the purity of RSVP-TE. Due to
     the fact that this informational RFC was not reviewed in CCAMP before, it
     is perceived as an assault.

So the match is tied up 1:1 but maybe it's now the right time to find a solution
on how to proceed. What I've seen so far was a complete misperception of what is
required on either side and why.

  1. ITU-T basically started by defining user services having in mind layered
     transport platforms like OTH and SDH/SONET. Those services can be
     summarized as 'Bandwidth on Demand' services (BOND). Naturally this led to
     a very strong focus on UNI interfaces and a kind of ignorance of networking
     protocols. You probably remember the discussions on why not using SS7? (For
     those not familar with the issue: SS7 is the signaling protocol between
     PSTN switches)
  2. IETF started with established L2/3 protocols (OSPF, RSVP-TE, ...) and
     extending their scope to L1 technologies namely SDH/SONET and OTH.
     Naturally this led to a very strong focus on protocol consistency and a
     kind of ignorance on service aspects other than those already available in
     MPLS. You may remember here the discussion about whether UNI is useful at
     all some time ago.

So putting everything together means that it is required to keep (IETF) protocol
consistency but adding some (ITU-T) specific extensions to well defined service
points in the network (UNI).
Unfortunately service points tend to exchange messages between themselves and
this would mean that an intermediate protocol would have had to support such
kind of communication. What concerns the IETF community is probably not the fact
that there is a UNI somewhere, but the changes and extensions to etablished
protocols in order to achieve a collaboration between them.

I recall that this was the basic issue with the ITU-T proposal when it was
presented for the first time in Yokohama. The way I've got Kireeti's message
there was: please authors try to let us understand what problem you want to
solve and tell us which kind of information you have to exchange between which
points to achieve it. We'll sort out then in CCAMP what would be the most
appropriate way to implement it, while maintaining consistency in our protocols.

Although it didn't work the first time I still consider Kireeti's suggestion to
be a wise way to move forward and perhaps the key for harmonic collaboration.

Regards

Gert

[email-masked] wrote:

> Gert,
>
> I agreed with the intent in generalizing MPLS for the wide range of
> expected applications.  It was my hope that it would succeed.  At this
> point, one might say that the intent has only been partially achieved.
> The problem that has come to light over the past year is the fact that
> there are finer points of the ITU-T model and requirements that are not
> supported by the current IETF GMPLS RFCs and standards track drafts.
> Those aspects are considered significant enough by many carriers and
> their suppliers to warrant further extensions outside of the IETF.  (My
> apologies for not understanding those points well enough to clarify them
> even in examples, but there are many people on this list would could do
> so if they thought it necessary.  To avoid any misunderstand, all should
> know that Sprint does not yet have a company position on this.)  It is
> my hope that we can come up with ways of improving the coordination
> between the IETF and ITU-T.  This thread of discussion is bringing out
> the issues to make that happen.
>
> Regards,
>
> Mark Loyd Jones
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: Gert.Grammel [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 10:17 AM
> To: Mark.Jones
> Cc: dwfedyk; gash; ccamp; mpls
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Mark,
>
> please don't forget that due to the 'Generalization' of GMPLS you are
> free to do
> the split at any application level you wish. This was always the
> advantage of
> the GMPLS approach compared to the ITU-T model where initially each
> layer had
> its own control plane. So the fact that in theory you could use a single
> control
> plane for all your network means also that you are able to stop where
> you want.
> Nice feature isn't it?
>
> Regards
>
> Gert
>
> [email-masked] wrote:
>
> > I agree with the separation of GMPLS into the two applications.  There
> > does not appear to be any significant move to collapse the management
> or
> > signaling for L3/2 and L1/0 at this time, given the different models
> > that apply for them and the infrastructures in our companies that
> manage
> > them.  The plan for addressing the two applications need not be the
> > same.
> >
> > The L3/2 application is near and dear to the heart of the IETF.  The
> > L1/0 application is of interest to those who wish to collapse the
> > management into a single layer.  In my opinion, the IETF might also
> > address this approach, given the IETF participants are the ones in
> > support of this collapsed management or at least common protocol
> > solution for what is today two signaling layers.  However, as stated
> > before, the collapse approach is not realistic today for a
> > multi-service, multi-protocol network.
> >
> > On the other hand, the L1/0 application requirements and models have
> > been defined and are best understood at the ITU-T.  Ideally, the
> > protocol expertise at the IETF would be applied to the ITU-T model and
> > requirements to address the L1/0 application, but attempts to do that
> > have been met with great resistance in the past.  Perhaps that was a
> > result of the fact that GMPLS implementations were not separated out
> > into the two different applications.  However, I don't think it is
> > realistic to expect the IETF experts to be motivated to understand the
> > ITU-T models and requirements, given the application is outside of
> their
> > primary area of interest.  That said, I believe the IETF should reach
> an
> > agreement on how to work with outside groups that develop "major
> > extensions" to the protocol.
> >
> > Mark Loyd Jones
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: dwfedyk [mailto:[email-masked]]
> > Sent: Thursday, March 06, 2003 7:49 AM
> > To: gash
> > Cc: mpls; ccamp
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Along the lines of Jerry's comments.
> >
> > When we put together GMPLS the first drafts were under specified
> > intentionally to capture the essence of GMPLS. We put aside many
> > arguments saying lets specify at a high level and fill in the details
> > later. The discussions on this thread are in two major veins one
> > attempting to fill the details and the other containing and
> controlling
> > the changes. GMPLS needs to be specified more accurately and in my
> > opinion it needs to be decomposed to a more layered approach.  I think
> > if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> > independently but self similar it would offer a mechanism to move
> > forward where some legacy systems could be specified to be GMPLS
> > friendly. For example signaling for Layer 3/2 can be tunneled through
> > the a lower layer. We already have some work in this direction.
> >  Similarly traffic engineering information for L1/L0 in a TE database
> >  would need different  attributes than a the TE database at L3/2. I
> > don't think you want to burden a L3/L2 system with these attributes in
> > an overlay model. The expertise for these layer is not all contained
> in
> > the IETF. I think we should put a plan forward to make this happen
> > within the IETF process. After this was accomplished  I think some
> > people are thinking of collapsing layers even more but the logical
> > partitioning of layers may help keep the protocols and databases
> > simpler.   Right now were are treating GMPLS like a big bowl of jelly
> > when it should look more like a layer cake.
> >
> > Regards,
> > Don
>
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Thu, 06 Mar 2003 10:58:54 -0800
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 18:51:45 -0000 

Thanks Mark.....the voice of reason!  I absolutely agree with you that
whilst there is potential merit in bringing L3/2 together (if we can get a
decent specification for MPLS.....and most here are not convinced on that
one yet) there is no case at all to bring it together with L1/0.  We made
the point way back in the Freeland draft (Nov 2000) that we saw no case for
the peer-model and have been consistently ignored ever since....and it's
kind of ironic to see this realisation now dawning on others, ie the move to
the 'overlay' model'....better late than never I guess. 

regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 06 March 2003 15:14
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> I agree with the separation of GMPLS into the two 
> applications.  There 
> does not appear to be any significant move to collapse the 
> management or 
> signaling for L3/2 and L1/0 at this time, given the different models 
> that apply for them and the infrastructures in our companies 
> that manage 
> them.  The plan for addressing the two applications need not be the 
> same.
> 
> The L3/2 application is near and dear to the heart of the IETF.  The 
> L1/0 application is of interest to those who wish to collapse the 
> management into a single layer.  In my opinion, the IETF might also 
> address this approach, given the IETF participants are the ones in 
> support of this collapsed management or at least common protocol 
> solution for what is today two signaling layers.  However, as stated 
> before, the collapse approach is not realistic today for a 
> multi-service, multi-protocol network.
> 
> On the other hand, the L1/0 application requirements and models have 
> been defined and are best understood at the ITU-T.  Ideally, the 
> protocol expertise at the IETF would be applied to the ITU-T 
> model and 
> requirements to address the L1/0 application, but attempts to do that 
> have been met with great resistance in the past.  Perhaps that was a 
> result of the fact that GMPLS implementations were not separated out 
> into the two different applications.  However, I don't think it is 
> realistic to expect the IETF experts to be motivated to 
> understand the 
> ITU-T models and requirements, given the application is 
> outside of their 
> primary area of interest.  That said, I believe the IETF 
> should reach an 
> agreement on how to work with outside groups that develop "major 
> extensions" to the protocol.
> 
> Mark Loyd Jones
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>  
> 
> -----Original Message-----
> From: dwfedyk [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 7:49 AM
> To: gash
> Cc: mpls; ccamp
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Along the lines of Jerry's comments.
> 
> When we put together GMPLS the first drafts were under specified 
> intentionally to capture the essence of GMPLS. We put aside many 
> arguments saying lets specify at a high level and fill in the details 
> later. The discussions on this thread are in two major veins one 
> attempting to fill the details and the other containing and 
> controlling 
> the changes. GMPLS needs to be specified more accurately and in my 
> opinion it needs to be decomposed to a more layered approach. 
>  I think 
> if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,  
> independently but self similar it would offer a mechanism to move 
> forward where some legacy systems could be specified to be GMPLS 
> friendly. For example signaling for Layer 3/2 can be tunneled through 
> the a lower layer. We already have some work in this direction. 
>  Similarly traffic engineering information for L1/L0 in a TE database 
>  would need different  attributes than a the TE database at L3/2. I 
> don't think you want to burden a L3/L2 system with these 
> attributes in 
> an overlay model. The expertise for these layer is not all 
> contained in 
> the IETF. I think we should put a plan forward to make this happen 
> within the IETF process. After this was accomplished  I think some 
> people are thinking of collapsing layers even more but the logical 
> partitioning of layers may help keep the protocols and databases 
> simpler.   Right now were are treating GMPLS like a big bowl of jelly 
> when it should look more like a layer cake.
> 
> Regards,
> Don
> 
> 
> 
> 
> 
> 
> 

Delivery-date: Thu, 06 Mar 2003 10:58:45 -0800
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 18:51:47 -0000 

Gert....its not a nice feature if you don't want to use the forced
functional component set.

Ignoring the commercial vertical (client/server) and horizontal (same layer
partitioning) requirements for functional decoupling, there are certain
behaviours an operator may wish to use at L1/0 that are different to those
the operator may wish to use in a L3/2 network.  Operators may want the
freedom to choose what they consider (whether others agree with them or not)
what they perceive as best-of-breed components.  For example, why should an
operator be forced to use v4 addressing for the user-plane access points at
L1/0?  Why should they be forced to use RSVP-TE signalling if they believe
pnni signalling is better?  Why should they be forced to run a routing
protocol at L1/0 (they may want discovery aspects however and the ability to
hold a routing cache) when they need access to centralised records (eg duct
records), and moreover they want their management system to retain
absolute/overriding control?  It's not clear to me operators have such
degrees of freedom here.

regards, Neil

> -----Original Message-----
> From: Gert Grammel [mailto:[email-masked]]
> Sent: 06 March 2003 16:17
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Mark,
> 
> please don't forget that due to the 'Generalization' of GMPLS 
> you are free to do
> the split at any application level you wish. This was always 
> the advantage of
> the GMPLS approach compared to the ITU-T model where 
> initially each layer had
> its own control plane. So the fact that in theory you could 
> use a single control
> plane for all your network means also that you are able to 
> stop where you want.
> Nice feature isn't it?
> 
> Regards
> 
> Gert
> 
> [email-masked] wrote:
> 
> > I agree with the separation of GMPLS into the two 
> applications.  There
> > does not appear to be any significant move to collapse the 
> management or
> > signaling for L3/2 and L1/0 at this time, given the different models
> > that apply for them and the infrastructures in our 
> companies that manage
> > them.  The plan for addressing the two applications need not be the
> > same.
> >
> > The L3/2 application is near and dear to the heart of the IETF.  The
> > L1/0 application is of interest to those who wish to collapse the
> > management into a single layer.  In my opinion, the IETF might also
> > address this approach, given the IETF participants are the ones in
> > support of this collapsed management or at least common protocol
> > solution for what is today two signaling layers.  However, as stated
> > before, the collapse approach is not realistic today for a
> > multi-service, multi-protocol network.
> >
> > On the other hand, the L1/0 application requirements and models have
> > been defined and are best understood at the ITU-T.  Ideally, the
> > protocol expertise at the IETF would be applied to the 
> ITU-T model and
> > requirements to address the L1/0 application, but attempts 
> to do that
> > have been met with great resistance in the past.  Perhaps that was a
> > result of the fact that GMPLS implementations were not separated out
> > into the two different applications.  However, I don't think it is
> > realistic to expect the IETF experts to be motivated to 
> understand the
> > ITU-T models and requirements, given the application is 
> outside of their
> > primary area of interest.  That said, I believe the IETF 
> should reach an
> > agreement on how to work with outside groups that develop "major
> > extensions" to the protocol.
> >
> > Mark Loyd Jones
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: dwfedyk [mailto:[email-masked]]
> > Sent: Thursday, March 06, 2003 7:49 AM
> > To: gash
> > Cc: mpls; ccamp
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Along the lines of Jerry's comments.
> >
> > When we put together GMPLS the first drafts were under specified
> > intentionally to capture the essence of GMPLS. We put aside many
> > arguments saying lets specify at a high level and fill in 
> the details
> > later. The discussions on this thread are in two major veins one
> > attempting to fill the details and the other containing and 
> controlling
> > the changes. GMPLS needs to be specified more accurately and in my
> > opinion it needs to be decomposed to a more layered 
> approach.  I think
> > if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> > independently but self similar it would offer a mechanism to move
> > forward where some legacy systems could be specified to be GMPLS
> > friendly. For example signaling for Layer 3/2 can be 
> tunneled through
> > the a lower layer. We already have some work in this direction.
> >  Similarly traffic engineering information for L1/L0 in a 
> TE database
> >  would need different  attributes than a the TE database at L3/2. I
> > don't think you want to burden a L3/L2 system with these 
> attributes in
> > an overlay model. The expertise for these layer is not all 
> contained in
> > the IETF. I think we should put a plan forward to make this happen
> > within the IETF process. After this was accomplished  I think some
> > people are thinking of collapsing layers even more but the logical
> > partitioning of layers may help keep the protocols and databases
> > simpler.   Right now were are treating GMPLS like a big 
> bowl of jelly
> > when it should look more like a layer cake.
> >
> > Regards,
> > Don
> 
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]
> 
> 
> 
> 

Envelope-to: [email-masked]
Delivery-date: Thu, 06 Mar 2003 09:25:48 -0800
Date: Thu, 6 Mar 2003 12:24:48 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: [email-masked], [email-masked]

> Liaisons can be *generated* anywhere, but should be *sent* through a
> predictable agent. 

see 3356 - in the case of the ITU-T the sending must CC the AD so
that the ITU-T knows that the liaison is legit

Scott

Envelope-to: [email-masked]
Delivery-date: Thu, 06 Mar 2003 09:25:10 -0800
Date: Thu, 6 Mar 2003 12:21:53 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: [email-masked], [email-masked], [email-masked]

> Is the IETF process for replying to liaison statements (and of
> generating them) written down, say in some RFC?  If so, could you
> send me a pointer?

no (and thus no)

Scott

Delivery-date: Thu, 06 Mar 2003 08:38:40 -0800
From: [email-masked]
Date: Thu, 6 Mar 2003 10:38:14 -0600
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
TO: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]

Gert,

I agreed with the intent in generalizing MPLS for the wide range of 
expected applications.  It was my hope that it would succeed.  At this 
point, one might say that the intent has only been partially achieved.  
The problem that has come to light over the past year is the fact that 
there are finer points of the ITU-T model and requirements that are not 
supported by the current IETF GMPLS RFCs and standards track drafts.  
Those aspects are considered significant enough by many carriers and 
their suppliers to warrant further extensions outside of the IETF.  (My 
apologies for not understanding those points well enough to clarify them 
even in examples, but there are many people on this list would could do 
so if they thought it necessary.  To avoid any misunderstand, all should 
know that Sprint does not yet have a company position on this.)  It is 
my hope that we can come up with ways of improving the coordination 
between the IETF and ITU-T.  This thread of discussion is bringing out 
the issues to make that happen.

Regards,

Mark Loyd Jones
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139

-----Original Message-----
From: Gert.Grammel [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 10:17 AM
To: Mark.Jones
Cc: dwfedyk; gash; ccamp; mpls
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Mark,

please don't forget that due to the 'Generalization' of GMPLS you are 
free to do
the split at any application level you wish. This was always the 
advantage of
the GMPLS approach compared to the ITU-T model where initially each 
layer had
its own control plane. So the fact that in theory you could use a single 
control
plane for all your network means also that you are able to stop where 
you want.
Nice feature isn't it?

Regards

Gert

[email-masked] wrote:

> I agree with the separation of GMPLS into the two applications.  There
> does not appear to be any significant move to collapse the management 
or
> signaling for L3/2 and L1/0 at this time, given the different models
> that apply for them and the infrastructures in our companies that 
manage
> them.  The plan for addressing the two applications need not be the
> same.
>
> The L3/2 application is near and dear to the heart of the IETF.  The
> L1/0 application is of interest to those who wish to collapse the
> management into a single layer.  In my opinion, the IETF might also
> address this approach, given the IETF participants are the ones in
> support of this collapsed management or at least common protocol
> solution for what is today two signaling layers.  However, as stated
> before, the collapse approach is not realistic today for a
> multi-service, multi-protocol network.
>
> On the other hand, the L1/0 application requirements and models have
> been defined and are best understood at the ITU-T.  Ideally, the
> protocol expertise at the IETF would be applied to the ITU-T model and
> requirements to address the L1/0 application, but attempts to do that
> have been met with great resistance in the past.  Perhaps that was a
> result of the fact that GMPLS implementations were not separated out
> into the two different applications.  However, I don't think it is
> realistic to expect the IETF experts to be motivated to understand the
> ITU-T models and requirements, given the application is outside of 
their
> primary area of interest.  That said, I believe the IETF should reach 
an
> agreement on how to work with outside groups that develop "major
> extensions" to the protocol.
>
> Mark Loyd Jones
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: dwfedyk [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 7:49 AM
> To: gash
> Cc: mpls; ccamp
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Along the lines of Jerry's comments.
>
> When we put together GMPLS the first drafts were under specified
> intentionally to capture the essence of GMPLS. We put aside many
> arguments saying lets specify at a high level and fill in the details
> later. The discussions on this thread are in two major veins one
> attempting to fill the details and the other containing and 
controlling
> the changes. GMPLS needs to be specified more accurately and in my
> opinion it needs to be decomposed to a more layered approach.  I think
> if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> independently but self similar it would offer a mechanism to move
> forward where some legacy systems could be specified to be GMPLS
> friendly. For example signaling for Layer 3/2 can be tunneled through
> the a lower layer. We already have some work in this direction.
>  Similarly traffic engineering information for L1/L0 in a TE database
>  would need different  attributes than a the TE database at L3/2. I
> don't think you want to burden a L3/L2 system with these attributes in
> an overlay model. The expertise for these layer is not all contained 
in
> the IETF. I think we should put a plan forward to make this happen
> within the IETF process. After this was accomplished  I think some
> people are thinking of collapsing layers even more but the logical
> partitioning of layers may help keep the protocols and databases
> simpler.   Right now were are treating GMPLS like a big bowl of jelly
> when it should look more like a layer cake.
>
> Regards,
> Don

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Thu, 06 Mar 2003 08:30:03 -0800
Date: Thu, 06 Mar 2003 11:29:30 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

You are right on the point!

[email-masked] wrote:
> 
> I agree with the separation of GMPLS into the two applications.  There
> does not appear to be any significant move to collapse the management or
> signaling for L3/2 and L1/0 at this time, given the different models
> that apply for them and the infrastructures in our companies that manage
> them.  The plan for addressing the two applications need not be the
> same.
> 
> The L3/2 application is near and dear to the heart of the IETF.  The
> L1/0 application is of interest to those who wish to collapse the
> management into a single layer.  In my opinion, the IETF might also
> address this approach, given the IETF participants are the ones in
> support of this collapsed management or at least common protocol
> solution for what is today two signaling layers.  However, as stated
> before, the collapse approach is not realistic today for a
> multi-service, multi-protocol network.
> 
> On the other hand, the L1/0 application requirements and models have
> been defined and are best understood at the ITU-T.  Ideally, the
> protocol expertise at the IETF would be applied to the ITU-T model and
> requirements to address the L1/0 application, but attempts to do that
> have been met with great resistance in the past.  Perhaps that was a
> result of the fact that GMPLS implementations were not separated out
> into the two different applications.  However, I don't think it is
> realistic to expect the IETF experts to be motivated to understand the
> ITU-T models and requirements, given the application is outside of their
> primary area of interest.  That said, I believe the IETF should reach an
> agreement on how to work with outside groups that develop "major
> extensions" to the protocol.
> 
> Mark Loyd Jones
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
> 
> 
> -----Original Message-----
> From: dwfedyk [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 7:49 AM
> To: gash
> Cc: mpls; ccamp
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> Along the lines of Jerry's comments.
> 
> When we put together GMPLS the first drafts were under specified
> intentionally to capture the essence of GMPLS. We put aside many
> arguments saying lets specify at a high level and fill in the details
> later. The discussions on this thread are in two major veins one
> attempting to fill the details and the other containing and controlling
> the changes. GMPLS needs to be specified more accurately and in my
> opinion it needs to be decomposed to a more layered approach.  I think
> if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> independently but self similar it would offer a mechanism to move
> forward where some legacy systems could be specified to be GMPLS
> friendly. For example signaling for Layer 3/2 can be tunneled through
> the a lower layer. We already have some work in this direction.
>  Similarly traffic engineering information for L1/L0 in a TE database
>  would need different  attributes than a the TE database at L3/2. I
> don't think you want to burden a L3/L2 system with these attributes in
> an overlay model. The expertise for these layer is not all contained in
> the IETF. I think we should put a plan forward to make this happen
> within the IETF process. After this was accomplished  I think some
> people are thinking of collapsing layers even more but the logical
> partitioning of layers may help keep the protocols and databases
> simpler.   Right now were are treating GMPLS like a big bowl of jelly
> when it should look more like a layer cake.
> 
> Regards,
> Don

Delivery-date: Thu, 06 Mar 2003 08:23:48 -0800
From: Shahram Davari <[email-masked]>
To: "'Scott  Bradner'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 6 Mar 2003 08:23:11 -0800 

Scott,

What is the best mailing list to discuss this draft?

-Shahram

>-----Original Message-----
>From: Scott Bradner [mailto:[email-masked]]
>Sent: Thursday, March 06, 2003 10:49 AM
>To: [email-masked]; Shahram Davari
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
>
>> Using their veto power against IETF community's consensus, seems 
>> "a complete breakdown of relationship" between IETF 
>community and IESG.
>
>see the message I posted
>
>Scott
>

Delivery-date: Thu, 06 Mar 2003 08:19:34 -0800
Date: Thu, 06 Mar 2003 17:17:06 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Mark,

please don't forget that due to the 'Generalization' of GMPLS you are free to do
the split at any application level you wish. This was always the advantage of
the GMPLS approach compared to the ITU-T model where initially each layer had
its own control plane. So the fact that in theory you could use a single control
plane for all your network means also that you are able to stop where you want.
Nice feature isn't it?

Regards

Gert

[email-masked] wrote:

> I agree with the separation of GMPLS into the two applications.  There
> does not appear to be any significant move to collapse the management or
> signaling for L3/2 and L1/0 at this time, given the different models
> that apply for them and the infrastructures in our companies that manage
> them.  The plan for addressing the two applications need not be the
> same.
>
> The L3/2 application is near and dear to the heart of the IETF.  The
> L1/0 application is of interest to those who wish to collapse the
> management into a single layer.  In my opinion, the IETF might also
> address this approach, given the IETF participants are the ones in
> support of this collapsed management or at least common protocol
> solution for what is today two signaling layers.  However, as stated
> before, the collapse approach is not realistic today for a
> multi-service, multi-protocol network.
>
> On the other hand, the L1/0 application requirements and models have
> been defined and are best understood at the ITU-T.  Ideally, the
> protocol expertise at the IETF would be applied to the ITU-T model and
> requirements to address the L1/0 application, but attempts to do that
> have been met with great resistance in the past.  Perhaps that was a
> result of the fact that GMPLS implementations were not separated out
> into the two different applications.  However, I don't think it is
> realistic to expect the IETF experts to be motivated to understand the
> ITU-T models and requirements, given the application is outside of their
> primary area of interest.  That said, I believe the IETF should reach an
> agreement on how to work with outside groups that develop "major
> extensions" to the protocol.
>
> Mark Loyd Jones
> Optical Transport and Networking
> Sprint - Wireline Technology Development
> 913-794-2139
>
>
> -----Original Message-----
> From: dwfedyk [mailto:[email-masked]]
> Sent: Thursday, March 06, 2003 7:49 AM
> To: gash
> Cc: mpls; ccamp
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
> Along the lines of Jerry's comments.
>
> When we put together GMPLS the first drafts were under specified
> intentionally to capture the essence of GMPLS. We put aside many
> arguments saying lets specify at a high level and fill in the details
> later. The discussions on this thread are in two major veins one
> attempting to fill the details and the other containing and controlling
> the changes. GMPLS needs to be specified more accurately and in my
> opinion it needs to be decomposed to a more layered approach.  I think
> if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> independently but self similar it would offer a mechanism to move
> forward where some legacy systems could be specified to be GMPLS
> friendly. For example signaling for Layer 3/2 can be tunneled through
> the a lower layer. We already have some work in this direction.
>  Similarly traffic engineering information for L1/L0 in a TE database
>  would need different  attributes than a the TE database at L3/2. I
> don't think you want to burden a L3/L2 system with these attributes in
> an overlay model. The expertise for these layer is not all contained in
> the IETF. I think we should put a plan forward to make this happen
> within the IETF process. After this was accomplished  I think some
> people are thinking of collapsing layers even more but the logical
> partitioning of layers may help keep the protocols and databases
> simpler.   Right now were are treating GMPLS like a big bowl of jelly
> when it should look more like a layer cake.
>
> Regards,
> Don

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Envelope-to: [email-masked]
Delivery-date: Thu, 06 Mar 2003 07:50:35 -0800
Date: Thu, 6 Mar 2003 10:48:34 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

> Using their veto power against IETF community's consensus, seems 
> "a complete breakdown of relationship" between IETF community and IESG.

see the message I posted

Scott

Delivery-date: Thu, 06 Mar 2003 07:38:38 -0800
Date: Thu, 6 Mar 2003 10:37:53 -0500
From: "'Scott W Brim'" <[email-masked]>
To: Shahram Davari <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Mail-Followup-To: 'Scott W Brim' <[email-masked]>, Shahram Davari <[email-masked]>, [email-masked], [email-masked]

On Wed, Mar 05, 2003 11:54:34AM -0800, Shahram Davari allegedly wrote:
> >> > It might be a good idea to require that all IETF protocols support
> >> > vendor-specific extensions, so that they could be used by 
> >other SDOs
> >> > and for experiments.
> >> 
> >> Ouch... draft-iesg-vendor-extensions-00.txt
> >
> >But that doesn't solve the problem.  There are some protocol
> >requirements that can't be met just by extra semantics.
> >
> 
> Could you please give an example. 

Obviously, something that involves extensions to the protocol machinery.  

Delivery-date: Thu, 06 Mar 2003 07:27:00 -0800
From: [email-masked]
Date: Thu, 6 Mar 2003 09:25:10 -0600
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
TO: [email-masked], [email-masked]
CC: [email-masked], [email-masked], [email-masked]

I don't understand how the development of a "major extension" by another 
group would necessarily indicate a "complete breakdown in relationship." 
 If that were the case, then the "veto" of the ITU-T based requirements 
and models have already shown we are in that condition now.  The 
continued discussion between IETF and ITU-T now proves that is not true.

The extensions by other groups only indicates differences in 
applications, models, scope, etc.  The development of "major extensions" 
by outside SDOs will continue unless the IETF decides to accept the 
applications defined in other organizations as serious work items.  As 
long as the IETF scope is focused on supporting and enabling IP, there 
will be broader applications that require those extensions that the IETF 
participants will not be willing to address.

I hope the IETF can find a way to retain ownership of the base protocols 
like GMPLS, while recognizing the fact that other applications will 
require extensions by other groups.  Those extensions should not 
infringe on the IETF application of the protocols as long as the 
applications defined by the IETF are clearly stated.  Only if the 
outside groups decide to address the exact same application as the IETF 
would I concede that we have a "breakdown in relationship."

To work this out, there needs to be a way for the IETF to respond to 
queries by outside groups about whether the IETF will or will not 
address the precise application of concern in another SDO.  Simply not 
agreeing to that application or not acknowledging the requirements in 
not a valid response.  The IETF then will retain control over which 
applications it will work on and which ones it will pass on.  I don't 
know if this is a liaison process or discussion of an ID, but some 
mechanism is needed for other organizations to hear whether they need to 
do their own extensions or whether they can expect the IETF to address 
them.

Mark Loyd Jones
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139

-----Original Message-----
From: Shahram.Davari [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 9:10 AM
To: curtis
Cc: zinin; Mark.Jones; ccamp; mpls
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

>> 1) Is the decision on how to deal with extension requests, an IESG
>> decision or an IETF consensus is required?
>
>If it is published as an informational recommendation by the IESG,
>then no.  The IESG does have veto power over internet-drafts that are
>on the standards track, therefore it might be worth paying attention
>to their recommendations.

Using their veto power against IETF community's consensus, seems "a 
complete breakdown of relationship" between IETF community and IESG.

>
>btw- I should also point out that Scott Bradner does not make this
>stuff up without talking to the other members of the IESG.

I know. but IESG != IETF

>
>> 2) No one can stop other SDOs from extending any IETF protocol
>
>True.
>
>> 3) The draft says:
>> 
>>    "No individual, vendor, SDO or forum should be able 
>create what is viewed
>>    to be a major extension to an IETF protocol on its own and
>>    legitimately be able to claim that implementations that 
>implement the
>>    extension are compliant to the IETF specification."
>> 
>> So if the other SDOs don't claim IETF compliance, rather 
>they claim their
>> respective organizations compliance, there should not be any 
>problem. And if 
>> they mess up nobody would blame IETF for that.
>
>This would represent a complete breakdown of relationships.  I'm not
>making any value judgement, just an observation.

Why? are you saying that if an SDO wants to define a brand new protocol 
(let's say MPLSv2),
but to reuse some parts of an existing IETF protocol, then they 
shouldn't do it because
IETF will get mad at them?

-Shahram

>
>> -Shahram
>
>Curtis
>
>
>> >-----Original Message-----
>> >From: Curtis Villamizar [mailto:[email-masked]]
>> >Sent: Wednesday, March 05, 2003 5:34 PM
>> >To: Shahram Davari
>> >Cc: [email-masked]'; Alex Zinin; 
>[email-masked]';
>> >[email-masked]; [email-masked]
>> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>> >
>> >
>> >
>> >In message 
>> ><[email-masked]
>> >>, Shahram Davari writes:
>> >> Is IESG=Curtis?
>> >> 
>> >> -Shahram
>> >
>> >
>> >That looks like a cheap shot of some kind.
>> >
>> >IESG == draft-iesg-vendor-extensions-00.txt
>> >
>> >  3.  Recommendation
>> >
>> >   The following principles are the main guiding principles 
>concerning
>> >   extensions to IETF protocol:
>> >
>> >    o All major extensions to IETF protocols should be done 
>with direct
>> >      involvement of the IETF.
>> >
>> >    o The decision on whether an extension is major or 
>minor should be
>> >      done with the direct involvement of the IETF.
>> >
>> >Those words are from the IESG draft.  They are not my words.
>> >
>> >I thought that was obvious enough in my prior reply, but apparently
>> >not.
>> >
>> >Curtis
>> >
>> >
>> >> >-----Original Message-----
>> >> >From: Curtis Villamizar [mailto:[email-masked]]
>> >> >Sent: Wednesday, March 05, 2003 4:53 PM
>> >> >To: Alex Zinin
>> >> >Cc: Shahram Davari; [email-masked]'; 
>> >[email-masked];
>> >> >[email-masked]
>> >> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>> >> >
>> >> >
>> >> >
>> >> >In message <[email-masked]>, Alex 
>Zinin writes:
>> >> >> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
>> >> >> [...]
>> >> >> > It might be a good idea to require that all IETF 
>> >protocols support
>> >> >> > vendor-specific extensions, so that they could be used by 
>> >> >other SDOs
>> >> >> > and for experiments.
>> >> >> 
>> >> >> Ouch... draft-iesg-vendor-extensions-00.txt
>> >> >> 
>> >> >> Alex
>> >> >
>> >> >
>> >> >Looks like the IESG doesn't agree with Shahram on this.
>> >> >
>> >> >Curtis
>> >> >
>> >> 
>> >
>> 
>

Delivery-date: Thu, 06 Mar 2003 07:15:04 -0800
From: [email-masked]
Date: Thu, 6 Mar 2003 09:14:23 -0600
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
TO: [email-masked], [email-masked]
CC: [email-masked], [email-masked]

I agree with the separation of GMPLS into the two applications.  There 
does not appear to be any significant move to collapse the management or 
signaling for L3/2 and L1/0 at this time, given the different models 
that apply for them and the infrastructures in our companies that manage 
them.  The plan for addressing the two applications need not be the 
same.

The L3/2 application is near and dear to the heart of the IETF.  The 
L1/0 application is of interest to those who wish to collapse the 
management into a single layer.  In my opinion, the IETF might also 
address this approach, given the IETF participants are the ones in 
support of this collapsed management or at least common protocol 
solution for what is today two signaling layers.  However, as stated 
before, the collapse approach is not realistic today for a 
multi-service, multi-protocol network.

On the other hand, the L1/0 application requirements and models have 
been defined and are best understood at the ITU-T.  Ideally, the 
protocol expertise at the IETF would be applied to the ITU-T model and 
requirements to address the L1/0 application, but attempts to do that 
have been met with great resistance in the past.  Perhaps that was a 
result of the fact that GMPLS implementations were not separated out 
into the two different applications.  However, I don't think it is 
realistic to expect the IETF experts to be motivated to understand the 
ITU-T models and requirements, given the application is outside of their 
primary area of interest.  That said, I believe the IETF should reach an 
agreement on how to work with outside groups that develop "major 
extensions" to the protocol.

Mark Loyd Jones
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139

-----Original Message-----
From: dwfedyk [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 7:49 AM
To: gash
Cc: mpls; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Along the lines of Jerry's comments.

When we put together GMPLS the first drafts were under specified 
intentionally to capture the essence of GMPLS. We put aside many 
arguments saying lets specify at a high level and fill in the details 
later. The discussions on this thread are in two major veins one 
attempting to fill the details and the other containing and controlling 
the changes. GMPLS needs to be specified more accurately and in my 
opinion it needs to be decomposed to a more layered approach.  I think 
if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,  
independently but self similar it would offer a mechanism to move 
forward where some legacy systems could be specified to be GMPLS 
friendly. For example signaling for Layer 3/2 can be tunneled through 
the a lower layer. We already have some work in this direction. 
 Similarly traffic engineering information for L1/L0 in a TE database 
 would need different  attributes than a the TE database at L3/2. I 
don't think you want to burden a L3/L2 system with these attributes in 
an overlay model. The expertise for these layer is not all contained in 
the IETF. I think we should put a plan forward to make this happen 
within the IETF process. After this was accomplished  I think some 
people are thinking of collapsing layers even more but the logical 
partitioning of layers may help keep the protocols and databases 
simpler.   Right now were are treating GMPLS like a big bowl of jelly 
when it should look more like a layer cake.

Regards,
Don

Delivery-date: Thu, 06 Mar 2003 07:11:59 -0800
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: Alex Zinin <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Thu, 6 Mar 2003 07:10:19 -0800 

>> 1) Is the decision on how to deal with extension requests, an IESG
>> decision or an IETF consensus is required?
>
>If it is published as an informational recommendation by the IESG,
>then no.  The IESG does have veto power over internet-drafts that are
>on the standards track, therefore it might be worth paying attention
>to their recommendations.

Using their veto power against IETF community's consensus, seems "a complete breakdown of relationship" between IETF community and IESG.

>
>btw- I should also point out that Scott Bradner does not make this
>stuff up without talking to the other members of the IESG.

I know. but IESG != IETF

>
>> 2) No one can stop other SDOs from extending any IETF protocol
>
>True.
>
>> 3) The draft says:
>> 
>>    "No individual, vendor, SDO or forum should be able 
>create what is viewed
>>    to be a major extension to an IETF protocol on its own and
>>    legitimately be able to claim that implementations that 
>implement the
>>    extension are compliant to the IETF specification."
>> 
>> So if the other SDOs don't claim IETF compliance, rather 
>they claim their
>> respective organizations compliance, there should not be any 
>problem. And if 
>> they mess up nobody would blame IETF for that.
>
>This would represent a complete breakdown of relationships.  I'm not
>making any value judgement, just an observation.

Why? are you saying that if an SDO wants to define a brand new protocol (let's say MPLSv2),
but to reuse some parts of an existing IETF protocol, then they shouldn't do it because
IETF will get mad at them?

-Shahram

>
>> -Shahram
>
>Curtis
>
>
>> >-----Original Message-----
>> >From: Curtis Villamizar [mailto:[email-masked]]
>> >Sent: Wednesday, March 05, 2003 5:34 PM
>> >To: Shahram Davari
>> >Cc: [email-masked]'; Alex Zinin; 
>[email-masked]';
>> >[email-masked]; [email-masked]
>> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>> >
>> >
>> >
>> >In message 
>> ><[email-masked]
>> >>, Shahram Davari writes:
>> >> Is IESG=Curtis?
>> >> 
>> >> -Shahram
>> >
>> >
>> >That looks like a cheap shot of some kind.
>> >
>> >IESG == draft-iesg-vendor-extensions-00.txt
>> >
>> >  3.  Recommendation
>> >
>> >   The following principles are the main guiding principles 
>concerning
>> >   extensions to IETF protocol:
>> >
>> >    o All major extensions to IETF protocols should be done 
>with direct
>> >      involvement of the IETF.
>> >
>> >    o The decision on whether an extension is major or 
>minor should be
>> >      done with the direct involvement of the IETF.
>> >
>> >Those words are from the IESG draft.  They are not my words.
>> >
>> >I thought that was obvious enough in my prior reply, but apparently
>> >not.
>> >
>> >Curtis
>> >
>> >
>> >> >-----Original Message-----
>> >> >From: Curtis Villamizar [mailto:[email-masked]]
>> >> >Sent: Wednesday, March 05, 2003 4:53 PM
>> >> >To: Alex Zinin
>> >> >Cc: Shahram Davari; [email-masked]'; 
>> >[email-masked];
>> >> >[email-masked]
>> >> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>> >> >
>> >> >
>> >> >
>> >> >In message <[email-masked]>, Alex 
>Zinin writes:
>> >> >> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
>> >> >> [...]
>> >> >> > It might be a good idea to require that all IETF 
>> >protocols support
>> >> >> > vendor-specific extensions, so that they could be used by 
>> >> >other SDOs
>> >> >> > and for experiments.
>> >> >> 
>> >> >> Ouch... draft-iesg-vendor-extensions-00.txt
>> >> >> 
>> >> >> Alex
>> >> >
>> >> >
>> >> >Looks like the IESG doesn't agree with Shahram on this.
>> >> >
>> >> >Curtis
>> >> >
>> >> 
>> >
>> 
>

Delivery-date: Thu, 06 Mar 2003 05:47:49 -0800
Date: Thu, 06 Mar 2003 08:48:36 -0500
From: Don Fedyk <[email-masked]>
To: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Along the lines of Jerry's comments.

When we put together GMPLS the first drafts were under specified 
intentionally to capture the essence of GMPLS. We put aside many 
arguments saying lets specify at a high level and fill in the details 
later. The discussions on this thread are in two major veins one 
attempting to fill the details and the other containing and controlling 
the changes. GMPLS needs to be specified more accurately and in my 
opinion it needs to be decomposed to a more layered approach.  I think 
if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,  
independently but self similar it would offer a mechanism to move 
forward where some legacy systems could be specified to be GMPLS 
friendly. For example signaling for Layer 3/2 can be tunneled through 
the a lower layer. We already have some work in this direction. 
 Similarly traffic engineering information for L1/L0 in a TE database 
 would need different  attributes than a the TE database at L3/2. I 
don't think you want to burden a L3/L2 system with these attributes in 
an overlay model. The expertise for these layer is not all contained in 
the IETF. I think we should put a plan forward to make this happen 
within the IETF process. After this was accomplished  I think some 
people are thinking of collapsing layers even more but the logical 
partitioning of layers may help keep the protocols and databases 
simpler.   Right now were are treating GMPLS like a big bowl of jelly 
when it should look more like a layer cake.

Regards,
Don

Delivery-date: Thu, 06 Mar 2003 03:44:48 -0800
Date: Thu, 06 Mar 2003 12:44:20 +0100
From: Steffen Brockmann <[email-masked]>
Organization: Alcatel
To: [email-masked]
Subject: draft-ietf-ccamp-gmpls-overlay-01

This is a multi-part message in MIME format.
--------------38980EF9356342CA356B9640
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have a doubt on draft-ietf-ccamp-gmpls-overlay-01:

In section 2, the draft states:
'When forming a SENDER_TEMPLATE the ingress edge-node includes either
its Node-ID or the address of one of its numbered TE links.  In the
latter case the connection will only be made over this interface.'

That suggests to use the SENDER_TEMPLATE to restrict the choice of data
channel.

That however is exactly what according to RFC3471 the TLVs of the IF_ID
RSVP_HOP objects are meant for.
Instead of the SENDER_TEMPLATE object, shouldn't TLV type 1 be used?

There is also a philosophical question that comes with it:
The SENDER_TEMPLATE is meant to have end-to-end significance, whereas
the selection of the data channel is of local significance.

There is another inaccuracy in section 3.3, I believe:
'In order to support explicit label control and full identification of
the egress link an ingress edge-node may include an ERO that consists
of only the last hop. This is signaled by setting the first subobject of
the ERO to the node-ID of the egress core-node with the L-bit set.'

It is just an editorial detail, but the first subobject of the ERO sent
by the ingress edge node must point to the ingress core node. Else the
ERO check at the ingress core node will fail, according to RFC3209,
section 4.3.4.1:
'1) The node receiving the RSVP message MUST first evaluate the first
subobject.  If the node is not part of the abstract node described by
the first subobject, it has received the message in error and SHOULD
return a "Bad initial subobject" error.  If there is no first subobject,
the message is also in error and the system SHOULD return a "Bad
EXPLICIT_ROUTE object" error.'

Steffen

--------------38980EF9356342CA356B9640
Content-Type: text/x-vcard; charset=us-ascii;
 name="brockmas.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Steffen Brockmann
Content-Disposition: attachment;
 filename="brockmas.vcf"

begin:vcard 
n:Brockmann;Steffen
tel;work:+32-3-240-8615
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[email-masked]
org;quoted-printable:<table WIDTH=3D"100%" ><tr><td><center><a href=3D"http://www.alcatel.com"><img SRC=3D"http://www.cid.alcatel.com/graphics/logo_tag.gif" HSPACE=3D3 BORDER=3D0></a></center></td><td><center><font size=3D+1>System<br>&nbsp=3BArchitecture</font></center></td></tr></table>
fn:Steffen Brockmann
end:vcard

--------------38980EF9356342CA356B9640--

Delivery-date: Thu, 06 Mar 2003 03:28:13 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
Date: Thu, 06 Mar 2003 06:24:36 -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		: SONET/SDH Encoding for Link Management Protocol (LMP) 
                          Test messages
	Author(s)	: J. Lang, D. Papadimitriou
	Filename	: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
	Pages		: 16
	Date		: 2003-3-5
	
This document details the Synchronous Optical NETwork (SONET)/ 
Synchronous Digital Hierarchy (SDH) technology specific information 
needed when sending Link Management Protocol (LMP) test messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-lmp-test-sonet-sdh-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-lmp-test-sonet-sdh-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-lmp-test-sonet-sdh-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Envelope-to: [email-masked]
Delivery-date: Wed, 05 Mar 2003 17:51:42 -0800
Date: Wed, 5 Mar 2003 20:51:32 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

> In any case, problem ga is still there, and to me should at worst not be 
> repeated , and at best be solved & not repeated.

agree

Scott

Envelope-to: [email-masked]
Delivery-date: Wed, 05 Mar 2003 17:51:25 -0800
Date: Wed, 5 Mar 2003 20:50:31 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: [email-masked], [email-masked]

> btw- I should also point out that Scott Bradner does not make this
> stuff up without talking to the other members of the IESG.

this text was well discussed in the IESG before it was turned into
an ID

I expect that the IESG will do a IETF Last-Call on the ID before
publishing it as an RFC to verify if the IETF community concensus
supports the statement that this ID makes

Scott

Delivery-date: Wed, 05 Mar 2003 17:27:07 -0800
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Wed, 5 Mar 2003 20:25:13 -0500
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>

It seems that progress has been made on this thread in initiating a =
liaison process, etc.

However, a problem still not addressed is:

'problem ga': GMPLS/ASON requirements were put forward by ITU-T but did =
not get adequate attention/evaluation in IETF, with the unfortunate =
outcome that now 2 'GMPLS/ASON signaling' (RSVP-TE) standards have =
emerged, 'itu-gmpls' & 'ietf-gmpls', most likely with interoperability =
issues.

'itu-gmpls' would appear to be a 'major extension' in the context of =
http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-00.txt. =
 As such, none of the following recommendations seem to have been =
followed:

"- All major extensions to IETF protocols should be done with direct =
involvement of the IETF
-  The decision on whether an extension is major or minor should be done =
with the direct involvement of the IETF
- Extensions should be done by IETF working groups using normal IETF =
processes
- Major extensions should be ... checked by the IETF community to be =
sure that the extension does not defeat safeguards designed into the =
protocol, such as security functions, or undermine its architectural =
integrity
- No individual, vendor, SDO or forum should be able to create what is =
viewed to be a major extension to an IETF protocol on its own and =
legitimately be able to claim that implementations that implement the =
extension are compliant to the IETF specification."

Could these recommendations now be addressed, perhaps by a team of SMEs, =
to evaluate/recommend a course of action?  It doesn't matter whether or =
not this is a formally sanctioned design-team, or a self-organized team =
of SME's who represent the component SDO interests, as long as a good =
technical solution emerges.  I've observed that a 'team' of SME's has =
now 'organized' on this list (on this thread), and in a sense is =
addressing problem ga, although they're somewhat adversarial in tone at =
the moment :-).  Could this energy/creativity be targeted at positive =
technical solutions in terms of the above recommendations?

It's unclear if this kind of problem fits within the scope of the =
'problem statement' of draft-andersson-mpls-g-chng-proc, which BTW =
provides no 'problem statement' as the I-D itself requires.

In any case, problem ga is still there, and to me should at worst not be =
repeated, and at best be solved & not repeated.

Jerry Ash

Delivery-date: Wed, 05 Mar 2003 14:45:53 -0800
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: Alex Zinin <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Wed, 5 Mar 2003 14:45:05 -0800 

Thanks for your clarification. A couple of points:

1) Is the decision on how to deal with extension requests, an IESG
decision or an IETF consensus is required?

2) No one can stop other SDOs from extending any IETF protocol

3) The draft says:

   "No individual, vendor, SDO or forum should be able create what is viewed
   to be a major extension to an IETF protocol on its own and
   legitimately be able to claim that implementations that implement the
   extension are compliant to the IETF specification."

So if the other SDOs don't claim IETF compliance, rather they claim their
respective organizations compliance, there should not be any problem. And if 
they mess up nobody would blame IETF for that.

-Shahram

>-----Original Message-----
>From: Curtis Villamizar [mailto:[email-masked]]
>Sent: Wednesday, March 05, 2003 5:34 PM
>To: Shahram Davari
>Cc: [email-masked]'; Alex Zinin; [email-masked]';
>[email-masked]; [email-masked]
>Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>
>
>
>In message 
><[email-masked]
>>, Shahram Davari writes:
>> Is IESG=Curtis?
>> 
>> -Shahram
>
>
>That looks like a cheap shot of some kind.
>
>IESG == draft-iesg-vendor-extensions-00.txt
>
>  3.  Recommendation
>
>   The following principles are the main guiding principles concerning
>   extensions to IETF protocol:
>
>    o All major extensions to IETF protocols should be done with direct
>      involvement of the IETF.
>
>    o The decision on whether an extension is major or minor should be
>      done with the direct involvement of the IETF.
>
>Those words are from the IESG draft.  They are not my words.
>
>I thought that was obvious enough in my prior reply, but apparently
>not.
>
>Curtis
>
>
>> >-----Original Message-----
>> >From: Curtis Villamizar [mailto:[email-masked]]
>> >Sent: Wednesday, March 05, 2003 4:53 PM
>> >To: Alex Zinin
>> >Cc: Shahram Davari; [email-masked]'; 
>[email-masked];
>> >[email-masked]
>> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>> >
>> >
>> >
>> >In message <[email-masked]>, Alex Zinin writes:
>> >> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
>> >> [...]
>> >> > It might be a good idea to require that all IETF 
>protocols support
>> >> > vendor-specific extensions, so that they could be used by 
>> >other SDOs
>> >> > and for experiments.
>> >> 
>> >> Ouch... draft-iesg-vendor-extensions-00.txt
>> >> 
>> >> Alex
>> >
>> >
>> >Looks like the IESG doesn't agree with Shahram on this.
>> >
>> >Curtis
>> >
>> 
>

Delivery-date: Wed, 05 Mar 2003 14:15:39 -0800
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Alex Zinin <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Wed, 5 Mar 2003 14:12:59 -0800 

Is IESG=Curtis?

-Shahram

>-----Original Message-----
>From: Curtis Villamizar [mailto:[email-masked]]
>Sent: Wednesday, March 05, 2003 4:53 PM
>To: Alex Zinin
>Cc: Shahram Davari; [email-masked]'; [email-masked];
>[email-masked]
>Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>
>
>
>In message <[email-masked]>, Alex Zinin writes:
>> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
>> [...]
>> > It might be a good idea to require that all IETF protocols support
>> > vendor-specific extensions, so that they could be used by 
>other SDOs
>> > and for experiments.
>> 
>> Ouch... draft-iesg-vendor-extensions-00.txt
>> 
>> Alex
>
>
>Looks like the IESG doesn't agree with Shahram on this.
>
>Curtis
>

Delivery-date: Wed, 05 Mar 2003 12:44:29 -0800
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Wed, 5 Mar 2003 12:42:51 -0800 

>-----Original Message-----
>From: Curtis Villamizar [mailto:[email-masked]]
>Sent: Wednesday, March 05, 2003 3:27 PM
>To: Shahram Davari
>Cc: [email-masked]'; [email-masked]; [email-masked]
>Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>
>
>
>In message 
><[email-masked]
>>, Shahram Davari writes:
>> >Regardless of the process that the IETF uses to address the 
>> >contributions, network need for extensions, to address applications 
>> >outside the IETF scope, will continue to be identified.  For that 
>> >reason, there will be real network need for those extensions.  
>> 
>> It might be a good idea to require that all IETF protocols support
>> vendor-specific extensions, so that they could be used by other SDOs
>> and for experiments.
>> 
>> -Shahram
>
>
>How does a committee experiment with a protocol?  AFAIK most SDOs
>don't "experiment" they just write standards without trying them out,
>then try to mandate that everyone implement them still not knowing for
>sure if they actually work.  Its the IETF that experiments first.
>That's the "running code" thing you might have heard about.

I didn't say the SDOs want to experiment. I said the vendor-specific
could be used by both SDOs and those who want to experiment.

>
>All of the protocols support extension mechanisms.  One or more
>vendors often experiment with protocol extensions, label documents
>with TBD for codepoints and pick an unused one temporarily.  Once
>sufficient consensus is achieved that the protocol extension is at
>least worthwhile, which often follows successful limited deployment,
>the TBD is given an IANA assignment while the details are worked out.
>This works just fine.

Who guarantees that the very codepoint they are using will not 
be standardized by IETF for other use, while they are experimenting it?
And why LDP has such extension? 
  
>
>Running code and successful deployment do carry weight in the IETF but
>even that is not absolute as evident by the MPLS/ICMP extensions which
>were successfully deployed but rejected.
>
>If you mean that any committee should be able to try to mandate any
>extension they please, then I don't think its a good idea.

I think IETF should provide vendor-specific extension (like the one in LDP),
and that other SDOs need to be free to use it for any purpose they want. If
their idea is not good, people won't use their extension, period. No harm is done 
to the protocol.

-Shahram

Delivery-date: Wed, 05 Mar 2003 11:54:59 -0800
From: Shahram Davari <[email-masked]>
To: "'Scott W Brim'" <[email-masked]>, Alex Zinin <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Wed, 5 Mar 2003 11:54:34 -0800 

>> > It might be a good idea to require that all IETF protocols support
>> > vendor-specific extensions, so that they could be used by 
>other SDOs
>> > and for experiments.
>> 
>> Ouch... draft-iesg-vendor-extensions-00.txt
>
>But that doesn't solve the problem.  There are some protocol
>requirements that can't be met just by extra semantics.
>

Could you please give an example. 

-Shahram

Delivery-date: Wed, 05 Mar 2003 11:47:21 -0800
Date: Wed, 5 Mar 2003 14:46:48 -0500
From: Scott W Brim <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Shahram Davari <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Mail-Followup-To: Scott W Brim <[email-masked]>, Alex Zinin <[email-masked]>, Shahram Davari <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]

On Wed, Mar 05, 2003 11:37:34AM -0800, Alex Zinin allegedly wrote:
> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
> [...]
> > It might be a good idea to require that all IETF protocols support
> > vendor-specific extensions, so that they could be used by other SDOs
> > and for experiments.
> 
> Ouch... draft-iesg-vendor-extensions-00.txt

But that doesn't solve the problem.  There are some protocol
requirements that can't be met just by extra semantics.

Delivery-date: Wed, 05 Mar 2003 11:39:05 -0800
Date: Wed, 5 Mar 2003 11:37:34 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Shahram Davari <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, [email-masked],  <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
[...]
> It might be a good idea to require that all IETF protocols support
> vendor-specific extensions, so that they could be used by other SDOs
> and for experiments.

Ouch... draft-iesg-vendor-extensions-00.txt

Alex

Delivery-date: Wed, 05 Mar 2003 11:32:54 -0800
Date: Wed, 5 Mar 2003 11:31:26 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Jonathan Sadler <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, Stephen Trowbridge <[email-masked]>,  <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Jonathan,

  When the IETF suddenly loses its interest in one of its protocols
  and another SDO has a concentration of expertise on it, an
  individual IETF submission targeted to STD track will naturally
  receive such fast track processing.

-- 
Alex

Wednesday, March 5, 2003, 9:57:45 AM, Jonathan Sadler wrote:
> Just an observation...

> Its kind of interesting to note that this "equal weight"
> philosophy doesn't seem to extend to the IETF when sending
> things to other organizations.  Witness the recent proposal
> to ISO on IS-IS extensions:

> "IS-IS extensions submitted from the IETF to JTC1 will be
> processed under the JTC1 fast track procedure. To ensure the
> quality of such submissions, IETF SHALL apply to them the
> procedures for Proposed Standard submission according to
> [RFC2026]."

> Wouldn't it be reasonable for other SDOs that have done the
> same sort of quality check prior to sending something to the
> IETF to be given the same courtesy of "fast track"
> review/approval?

> Jonathan Sadler

> Alex Zinin wrote:

>> <regular ietf'er hat on>
>>
>> Monday, March 3, 2003, 2:26:06 PM, Kireeti Kompella wrote:
>> > Hi Steve,
>>
>> > On Mon, 3 Mar 2003, Stephen Trowbridge wrote:
>>
>> >> There is no doubt that liaisons CURRENTLY have no more wieght than
>> >> individual IDs
>>
>> > This might be a fundamental difference between the IETF and other SDOs,
>> > the ITU in particular.  However, that still doesn't mean that this
>> > policy of the IETF's is wrong.  I happen to think that taking everything
>> > at its own merit rather than considering where it came from is the most
>> > democratic, equal opportunity means of handling it -- but that's a
>> > personal philosophy, not necessarily echoed by the IETF.
>>
>> Bingo!
>>
>> It seems to me that this is the only way to ensure fairness in the
>> IETF, actually. Once we start introducing any sorts of preferences or
>> "weights", it may become a too attractive backdoor around the IETF
>> process.
>>
>> Also, what does "weight" of a liaison or an ID really mean in a
>> _consensus_ based organization? That we should suddenly have a worm
>> and fuzzy feeling about that doc? And how does this "weight" compare
>> to, for example, the weight of the consensus within the IETF to not do
>> what's proposed, if that happens?
>>
>> Alex

> ============================================================
> 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, 05 Mar 2003 11:14:26 -0800
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Wed, 5 Mar 2003 11:12:10 -0800 

>Regardless of the process that the IETF uses to address the 
>contributions, network need for extensions, to address applications 
>outside the IETF scope, will continue to be identified.  For that 
>reason, there will be real network need for those extensions.  

It might be a good idea to require that all IETF protocols support
vendor-specific extensions, so that they could be used by other SDOs
and for experiments.

-Shahram

Delivery-date: Wed, 05 Mar 2003 09:59:17 -0800
Date: Wed, 05 Mar 2003 11:57:45 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: Alex Zinin <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Just an observation...

Its kind of interesting to note that this "equal weight"
philosophy doesn't seem to extend to the IETF when sending
things to other organizations.  Witness the recent proposal
to ISO on IS-IS extensions:

"IS-IS extensions submitted from the IETF to JTC1 will be
processed under the JTC1 fast track procedure. To ensure the
quality of such submissions, IETF SHALL apply to them the
procedures for Proposed Standard submission according to
[RFC2026]."

Wouldn't it be reasonable for other SDOs that have done the
same sort of quality check prior to sending something to the
IETF to be given the same courtesy of "fast track"
review/approval?

Jonathan Sadler

Alex Zinin wrote:

> <regular ietf'er hat on>
>
> Monday, March 3, 2003, 2:26:06 PM, Kireeti Kompella wrote:
> > Hi Steve,
>
> > On Mon, 3 Mar 2003, Stephen Trowbridge wrote:
>
> >> There is no doubt that liaisons CURRENTLY have no more wieght than
> >> individual IDs
>
> > This might be a fundamental difference between the IETF and other SDOs,
> > the ITU in particular.  However, that still doesn't mean that this
> > policy of the IETF's is wrong.  I happen to think that taking everything
> > at its own merit rather than considering where it came from is the most
> > democratic, equal opportunity means of handling it -- but that's a
> > personal philosophy, not necessarily echoed by the IETF.
>
> Bingo!
>
> It seems to me that this is the only way to ensure fairness in the
> IETF, actually. Once we start introducing any sorts of preferences or
> "weights", it may become a too attractive backdoor around the IETF
> process.
>
> Also, what does "weight" of a liaison or an ID really mean in a
> _consensus_ based organization? That we should suddenly have a worm
> and fuzzy feeling about that doc? And how does this "weight" compare
> to, for example, the weight of the consensus within the IETF to not do
> what's proposed, if that happens?
>
> Alex

============================================================
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, 05 Mar 2003 07:21:43 -0800
Date: Wed, 05 Mar 2003 10:11:25 -0500
To: "David Allan" <[email-masked]>, "'Alex Zinin'" <[email-masked]>, Kireeti Kompella <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked]

         Dave,

>Alex:
>
>You are offering a compelling argument to eliminate crediting of any 
>authors on I-Ds etc.
>We can claim that there is no weight in a consensus based organization, 
>while we struggle to eliminate the practice of 20 plus authors on a draft.

         This is a completely different issue which to my knowledge
has been worked out by the IESG. If there are too many authors,
we put them in a contributors section and have a few editors.
As far as I know, IETF documents are given the same implicit weight no
matter who writes them.

         --Tom

>I would assume I'm not the only one to note this inconsistency.
>
>Cheers
>Dave
>
><snipped>
>
> >
> >Bingo!
> >
> >It seems to me that this is the only way to ensure fairness in the IETF, 
> actually. Once
> >we start introducing any sorts of preferences or "weights", it may 
> become a too
> >attractive backdoor around the IETF process.
>
> >Also, what does "weight" of a liaison or an ID really mean in a 
> _consensus_ based
> >organization? That we should suddenly have a worm and fuzzy feeling 
> about that doc? And
> >how does this "weight" compare to, for example, the weight of the 
> consensus within the
> >IETF to not do what's proposed, if that happens?
>

Delivery-date: Wed, 05 Mar 2003 03:36:06 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-01.txt
Date: Wed, 05 Mar 2003 06:27:59 -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		: GMPLS RSVP Support for the Overlay Model
	Author(s)	: G. Swallow et al.
	Filename	: draft-ietf-ccamp-gmpls-overlay-01.txt
	Pages		: 10
	Date		: 2003-3-4
	
Generalized MPLS defines both routing and signaling protocols for the
creation of Label Switched Paths (LSPs) in various transport
technologies.  These protocols can be used to support a number of
deployment scenarios.  This memo addresses the application of GMPLS
to the overlay model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-overlay-01.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-overlay-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Wed, 05 Mar 2003 03:35:58 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-czezowski-optical-recovery-reqs-01.txt
Date: Wed, 05 Mar 2003 06:29:27 -0500

--NextPart

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

	Title		: Optical Network Failure Recovery Requirements
	Author(s)	: P. Czezowski, T. Soumiya
	Filename	: draft-czezowski-optical-recovery-reqs-01.txt
	Pages		: 12
	Date		: 2003-3-4
	
This draft describes requirements for control plane-based recovery 
from data plane failures in pre-OTN networks.  pre-OTN networks are 
transport networks that have a GMPLS-based control plane and various 
transport plane technologies (such as Optical Cross Connects and 
Optical Add/Drop Multiplexers, etc.)  An important feature of these 
networks is recovery from failures - using either a protection or 
restoration scheme.  Achieving recovery under strict time constraints 
is a difficult problem.  Shared mesh-based recovery is especially 
desirable for reducing spare capacity ratios and achieving flexible 
recovery scenarios.  Following a brief overview and consideration of 
the requirements, they are presented in an itemized list in section 
3.4 of this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-czezowski-optical-recovery-reqs-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-czezowski-optical-recovery-reqs-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-czezowski-optical-recovery-reqs-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-czezowski-optical-recovery-reqs-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-czezowski-optical-recovery-reqs-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Delivery-date: Tue, 04 Mar 2003 17:38:56 -0800
Date: Tue, 04 Mar 2003 20:36:48 -0500
To: Kireeti Kompella <[email-masked]>, [email-masked]
From: Zafar Ali <[email-masked]>
Subject: Re: CCAMP 56 agenda
Cc: [email-masked], anca Zamfir <[email-masked]>, zafar Ali <[email-masked]>

--=====================_47082751==_
Content-Type: multipart/alternative;
	boundary="=====================_47082761==_.ALT"

--=====================_47082761==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

At 09:55 PM 3/1/2003 -0800, Kireeti Kompella wrote:
>Hi,
>
>If you would like to speak at the CCAMP WG at the 56th IETF, please
>reply to this email -- that will help the chairs track requests.
>Also, please state which Internet draft(s) form the basis of the
>talk that others may come prepared.

Dear Ron and Kireeti,

May we request a 5min slot for:

- " Explicit Resource Control over GMPLS Link Bundles",=20
draft-zamfir-explicit-resource-control-bundle-00.txt.

A copy of the draft is enclosed herewith. We have also requested posting of=
=20
the same copy to the Web, which should appear shortly. Abstract is provided=
=20
here for your quick reference.

Abstract

Explicit label/ resource control using the Label ERO and Label RRO=20
subobjects is defined in [RFC 3471] and [RFC 3473]. However, when TE links=
=20
are bundled, identification of label resource is not enough for the purpose=
=20
of explicit resource control. Specifically, when link bundling=20
[GMPLS-BUNDLE] is used, resource identification requires mechanisms to=20
specify the component link identifier, along the TE link identifier and=20
Label. This draft defines the extensions to RSVP [RFC2119, RFC3209] to=20
specify component link identifier for explicit resource control over GMPLS=
=20
link bundles.

Would you mind accepting this drafts within CCAMP?

Many thanks in advance.

Regards=85. Anca and Zafar

>Note: these are *not* presentations, expositions, or tutorials.
>A small number of slides that say what has changed *since the
>last IETF*, issues that were raised in the interim, and resolutions
>to those issues is the ideal.  If there hasn't been a discussion
>on the mailing list, in many cases that is a sign that the topic
>isn't (yet) ready for prime time.
>
>Thanks,
>Ron and Kireeti.

--=====================_47082761==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<font size=3D3>At 09:55 PM 3/1/2003 -0800, Kireeti Kompella wrote:<br>
<blockquote type=3Dcite cite>Hi,<br>
<br>
If you would like to speak at the CCAMP WG at the 56th IETF, please<br>
reply to this email -- that will help the chairs track requests.<br>
Also, please state which Internet draft(s) form the basis of the<br>
talk that others may come prepared.<br>
</font></blockquote><br>
<font size=3D3>Dear Ron and Kireeti,<br>
<br>
May we request a 5min slot for: <br>
<br>
- &quot; Explicit Resource Control over GMPLS Link Bundles&quot;,
draft-zamfir-explicit-resource-control-bundle-00.txt. <br>
<br>
A copy of the draft is enclosed herewith. We have also requested posting
of the same copy to the Web, which should appear shortly. Abstract is
provided here for your quick reference. <br>
<br>
Abstract<br>
<br>
Explicit label/ resource control using the Label ERO and Label RRO
subobjects is defined in [RFC 3471] and [RFC 3473]. However, when TE
links are bundled, identification of label resource is not enough for the
purpose of explicit resource control. Specifically, when link bundling
[GMPLS-BUNDLE] is used, resource identification requires mechanisms to
specify the component link identifier, along the TE link identifier and
Label. This draft defines the extensions to RSVP [RFC2119, RFC3209] to
specify component link identifier for explicit resource control over
GMPLS link bundles.<br>
<br>
Would you mind accepting this drafts within CCAMP? <br>
<br>
Many thanks in advance.<br>
<br>
Regards=85. Anca and Zafar <br>
<br>
<blockquote type=3Dcite cite>Note: these are *not* presentations,
expositions, or tutorials.<br>
A small number of slides that say what has changed *since the<br>
last IETF*, issues that were raised in the interim, and resolutions<br>
to those issues is the ideal.&nbsp; If there hasn't been a
discussion<br>
on the mailing list, in many cases that is a sign that the topic<br>
isn't (yet) ready for prime time.<br>
<br>
Thanks,<br>
Ron and Kireeti.</blockquote><br>
</font></html>

--=====================_47082761==_.ALT--

--=====================_47082751==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-zamfir-explicit-resource-control-bundle-00.txt"

   Networking Working Group                                            =20
   Internet Draft                                          Anca Zamfir,=20
                                                              Zafar Ali=20
   Document: draft-zamfir-explicit-resource-        Cisco Systems, Inc.=20
   control-bundle-00.txt=20
   Expires: October 2002                                     March 2003=20
   =20
   =20
             Explicit Resource Control over GMPLS Link Bundles=20
           draft-zamfir-explicit-resource-control-bundle-00.txt=20
   =20
   =20
Status of this Memo=20
   =20
   This document is an Internet-Draft and is in full conformance with=20
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working=20
   documents of the Internet Engineering Task Force (IETF), its areas,=20
   and its working groups.  Note that other groups may also distribute=20
   working documents as Internet-Drafts.=20
   Internet-Drafts are working documents of the Internet Engineering=20
   Task Force (IETF), its areas, and its working groups.  Note that=20
   other groups may also distribute working documents as Internet-
   Drafts.=20
   Internet-Drafts are draft documents valid for a maximum of six months=20
   and may be updated, replaced, or obsoleted by other documents at any=20
   time.  It is inappropriate to use Internet-Drafts as reference=20
   material or to cite them other than as "work in progress."=20
   The list of current Internet-Drafts can be accessed at=20
        http://www.ietf.org/ietf/1id-abstracts.txt=20
   The list of Internet-Draft Shadow Directories can be accessed at=20
        http://www.ietf.org/shadow.html.=20
   =20
   =20
Abstract=20
   =20
   Explicit label/ resource control using the Label ERO and Label RRO=20
   subobjects is defined in [RFC 3471] and [RFC 3473]. However, when TE=20
   links are bundled, identification of label resource is not enough for=20
   the purpose of explicit resource control. Specifically, when link=20
   bundling [GMPLS-BUNDLE] is used, resource identification requires=20
   mechanisms to specify the component link identifier, along the TE=20
   link identifier and Label. This draft defines the extensions to RSVP=20
   [RFC2119, RFC3209] to specify component link identifier for explicit=20
   resource control over GMPLS link bundles.=20
   =20
Conventions used in this document=20
   =20

=20
=20
 Zamfir, A., Ali, Z.                                          [Page 1]
                                   =20
 =20

=0C         draft-zamfir-explicit-resource-control-bundle-00.txt March 2003=
=20
=20
=20
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20
   this document are to be interpreted as described in RFC 2119=20
   [RFC2119].=20
   =20
Sub-IP ID Summary=20
   =20
   (This section to be removed before publication.)=20
   =20
   SUMMARY=20
   =20
      This document specifies extensions and mechanisms to RSVP-TE to=20
   provide explicit resource control over GMPLS Link Bundles.=20
   =20
   WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK?=20
   =20
      This work fits in the MPLS box. =20
   =20
   WHY IS IT TARGETED AT THIS WG?=20
      =20
      This draft is targeted at this WG, because this it specifies=20
   extensions to RSVP-TE signaling protocol for explicit resource=20
   control over GMPLS Link Bundles [GMPLS-BUNDLE].=20
   =20
   RELATED REFERENCES=20
   =20
      Please refer to the Reference Section. =20
   =20
   JUSTIFICATION=20
   =20
      Please refer to the Abstract and Introduction Sections. =20
   =20
Table of Contents=20
   =20
   1. Terminology....................................................3=20
   2. Introduction...................................................3=20
   3. Signaling Component Interface Identifier in ERO................4=20
      3.1 Processing of Component Interface Identifier ERO Subobject.5=20
   4. Component Interface Identifier RRO subobject...................6=20
      4.1 Processing of Component Interface identifier RRO Subobject.7=20
   5. Backward Compatibility Note....................................8=20
   6. Security Considerations........................................8=20
   7. Intellectual Property Considerations...........................8=20
   References........................................................8=20
   References........................................................8=20
   Author's Addresses................................................9=20
   =20
   =20

=20
=20
Zamfir, A., Ali, Z.                                           [Page 2]=20

=0C         draft-zamfir-explicit-resource-control-bundle-00.txt March 2003=
=20
=20
=20
1. Terminology=20
   =20
   TE LINK - Unless specified otherwise, it refers to a bundled Traffic=20
   Engineering link as defined in [GMPLS-BUNDLE]. Furthermore, the terms=20
   TE Link and bundled TE Link are used interchangeably. =20
   =20
   Component Interface - Refers to one of the components link in a TE=20
   link.=20
   =20
   Component Interface Identifier - Refers to an ID used to uniquely=20
   identify a component link within a TE link.=20
   =20
=20
2. Introduction=20
=20
      In classical MPLS that deals with unbundled packet switch capable=20
   TE Links, one of the types of resources that an LSP originator can=20
   control are the TE Link interfaces used by the LSP. This is done by=20
   the use of an explicit route, i.e., ERO Object. Also, there are=20
   applications where LSP initiator wishes to select resources on a=20
   given TE Link [RFC 3471]. An example where such a mechanism is=20
   desirable is when there are two LSPs to be "spliced" together, i.e.,=20
   where the tail of the first LSP is to be "spliced" into the head of=20
   the second LSP. Label ERO subobject is defined in [RFC 3473] for this=20
   purpose. Similarly, for uni-directional LSPs the Label RRO subobject=20
   is defined in [RFC3209] and is extended for bi-directional LSP in=20
   [RFC 3471], [RFC 3473]. =20
      Link Bundling introduced by [GMPLS-BUNDLE], is used to improve=20
   routing scalability by reducing the amount of TE related information=20
   that needs to be flooded and handled by IGP in a TE network. This is=20
   accomplished through aggregation and abstractization and in some=20
   cases the complete resource identification is left as a local=20
   decision. However, as described above there are cases when it is=20
   desirable that a non-local (e.g., LSP Head) node does this. =20
      When link bundling is used to aggregate multiple component links=20
   into a TE link, label is not the only resource over TE link that=20
   needs to be identified. In other words, the TE Link and the Label=20
   specified in the ERO/ RRO objects are not enough to completely=20
   identify the resource. For the bundled TE link case, in order to=20
   fully specify a resource on a link, the triplet <TE Link, Component=20
   Link, and Label> needs to be specified for the downstream direction=20
   of a unidirectional LSP. In the case of bi-directional LSPs both=20
   upstream and downstream triplets may be specified. In short, explicit=20
   resource control over a bundled TE link also requires a way to=20
   specify a component link within the TE link. References [RFC 3471],=20
   [RFC 3473] and [GMPLS-BUNDLE] are deficient for this purpose. =20
      This draft defines extensions to and describes the use of RSVP=20
   [RFC2119, RFC3209] to specify component link identifier for explicit=20
   resource control over GMPLS link bundles. Specifically, component=20
=20
=20
Zamfir, A., Ali, Z.                                           [Page 3]=20

=0C         draft-zamfir-explicit-resource-control-bundle-00.txt March 2003=
=20
=20
=20
   interface identifier ERO and RRO subobjects are defined to complement=20
   their Label ERO and RRO counterparts. Procedures for processing=20
   component interface identifier ERO and RRO subobjects and how they=20
   can co-exist with the Label ERO and RRO subobjects are also=20
   specified. If desired, it is possible to only include the component=20
   interface subobjects in the ERO.=20
      It has been also identified that the component interface=20
   identifier ERO and RRO subobjects are also useful in Classic MPLS=20
   networks with PSC TE links only.=20
   =20
3. Signaling Component Interface Identifier in ERO=20
   =20
      A new OPTIONAL subobject of the Explicit Route Object (ERO) is=20
   used to specify component interface identifier of a bundled TE Link.=20
   This subobject has the following format: =20
      Figure 1: Component Interface Identifier ERO subobject=20
   =20
       0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |L|    Type     |     Length    |U|   Reserved (MUST be zero)   |=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |  IPv4, IPv6 or unnumbered Component Interface Identifier      |=20
      |                            . . .                              |=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   =20
         L: 1 bit=20
   =20
            This bit must be set to 0.=20
   =20
         Type=20
   =20
            10 (TBD) Component Interface identifier IPv4 =20
            11 (TBD) Component Interface identifier Unnumbered=20
            12 (TBD) Component Interface identifier IPv6=20
   =20
         Length=20
   =20
             The Length contains the total length of the subobject in=20
             bytes, including the Type and Length fields. The Length is=20
             8 bytes for the Component Interface identifier types: IPv4=20
             and Component Interface identifier Unnumbered. For=20
             Component Interface identifier IPv6 type of sub-object,=20
             the length field is 20 bytes. =20
   =20
   =20
         U: 1 bit=20
             This bit indicates the direction of the component=20
          =20  interface.  It is 0 for the downstream interface.  It is=20
=20
=20
Zamfir, A., Ali, Z.                                           [Page 4]=20

=0C         draft-zamfir-explicit-resource-control-bundle-00.txt March 2003=
=20
=20
=20
             set to 1 for the upstream interface and is only used for =20
             bi-directional LSPs. =20
             =20
3.1 Processing of Component Interface Identifier ERO Subobject=20
   =20
      The Component Interface Identifier ERO subobject follows a=20
   subobject containing the IP address, or the link identifier=20
   [RFC3477], associated with the TE link on which it is to be used. It=20
   is used to identify the component of a bundled TE Link.=20
   =20
      The following SHOULD result in "Bad EXPLICIT_ROUTE object" error=20
   being sent upstream by a node processing an ERO that contains the=20
   Component Interface ID sub-object:=20
   =20
      o The first component interface identifier subobject is not=20
      preceded by a sub-object containing an IP address, or an=20
      interface identifier [RFC3477], associated with a TE link.=20
      o The Component Interface Identifier ERO subobject follows a=20
      subobject that has the L-bit set.=20
      o On unidirectional LSP setup, there is a Component Interface=20
      Identifier ERO subobject with the U-bit set.=20
      o Two Component Interface Identifier ERO subobjects with the same=20
      U-bit values exist.=20
      If a node supports the component interface identifier subobject,=20
   it must check if it represents a component interface in the bundled=20
   TE Link specified in the preceding subobject that contains the IP=20
   address or interface identifier of the TE Link. If the content of the=20
   component interface identifier subobject does not match a component=20
   interface in the TE link, a "Bad EXPLICIT_ROUTE object" error SHOULD=20
   be reported as "Routing Problem" (error code 24). =20
      If U-bit of the subobject being examined is cleared (0) and the=20
   upstream interface specified in this subobject is acceptable, then=20
   the value of the upstream component interface is copied in the TLV of=20
   the IF_ID HOP object [RFC 3471] and the local decision normally used=20
   to select the upstream component link is bypassed. If this interface=20
   is not acceptable, a "Bad EXPLICIT_ROUTE object" error SHOULD be=20
   reported as "Routing Problem" (error code 24).  =20
      =20
      If the U-bit of the subobject being examined is set (1), then the=20
   value represents the component interface to be used for upstream=20
   traffic associated with the bidirectional LSP.  Again, if this=20
   interface is not acceptable or if the request is not one for a=20
   bidirectional LSP, then a "Bad EXPLICIT_ROUTE object" error SHOULD be=20
   reported as "Routing Problem" (error code 24).  Otherwise, the=20
   component interface IP address/ identifier is copied into a TLV sub-
   object as part of the IF_ID HOP.=20
   =20
      The IF_ID HOP object constructed as above MUST be included in the=20
   corresponding outgoing Path message. =20
=20
=20
Zamfir, A., Ali, Z.                                           [Page 5]=20

=0C         draft-zamfir-explicit-resource-control-bundle-00.txt March 2003=
=20
=20
=20
   =20
      Note that, associated with a TE Link sub-object in the ERO, either=20
   the upstream component interface or the downstream component=20
   interface or both may be specified. As specified in [GMPLS-BUNDLE]=20
   there is no relationship between the TE Link type (numbered or=20
   unnumbered) and the Link type of any one of its components. =20
   =20
      The component interface identifier ERO subobject is optional.=20
   Similarly, presence of the Label ERO sub-objects is not mandatory=20
   [RFC 3471], [RFC 3473]. Furthermore, component interface identifier=20
   ERO subobject and Label ERO subobject may be included in the ERO=20
   independently of each other. When both sub-objects are absent, a node=20
   may select any appropriate component link within the TE link and any=20
   label on the selected component link. If only the Label subobject is=20
   present for a bundled link, then the selection of the component link=20
   within the bundle is a local decision and the node may select any=20
   appropriate component link, which can assume the label specified in=20
   the Label ERO. Similarly, when only the component interface=20
   identifier ERO subobject is present, a node MUST select the component=20
   interface specified in the ERO and may select any appropriate label=20
   value at the specified component link. In the case where both=20
   component interface identifier ERO subobject and Label ERO subobject=20
   are present, the node MUST select the specified component link and=20
   the specified label value on that component link. When both component=20
   interface identifier ERO subobject and Label ERO subobject are=20
   present, they may appear in any relative order to each other but they=20
   MUST appear after the TE Link sub-object that they refer to.=20
   =20
      After processing, the component interface identifier subobjects=20
   are removed from the ERO.=20
   =20
      Inferred from above, the interface subobject should never be the=20
   first subobject in a newly received message.  If the component=20
   interface subobject is the first subobject in a received ERO, then it=20
   SHOULD be treated as a "Bad strict node" error.=20
   =20
      Information to construct the Component Interface ERO subobject may=20
   come from the same mean used to populate the label ERO subobject. =20
   Procedures by which an LSR at the head-end of an LSP obtains the=20
   information needed to construct the Component Interface subobject are=20
   outside the scope of this document. However, such information=20
   typically comes from the configuration data. =20
   =20
4. Component Interface Identifier RRO subobject=20
   =20
      A new subobject of the Record Route Object (RRO) is used to record=20
   component interface identifier of a (bundled) TE Link. This subobject=20
   has the following format: =20

=20
=20
Zamfir, A., Ali, Z.                                           [Page 6]=20

=0C         draft-zamfir-explicit-resource-control-bundle-00.txt March 2003=
=20
=20
=20
      Figure 2: Component Interface Identifier RRO subobject=20
   =20
   =20
       0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |L|    Type     |     Length    |U| Reserved  (must be zero)    |=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |                Component Interface Identifier               |=20
      |                            . . .                              |=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
   =20
       0                   1                   2                   3=20
   =20
           L: 1 bit=20
   =20
            This bit must be set to 0.=20
   =20
   =20
         Type=20
   =20
            10 (TBD) Component Interface identifier IPv4 =20
            11 (TBD) Component Interface identifier Unnumbered=20
            12 (TBD) Component Interface identifier IPv6=20
   =20
         Length=20
   =20
            The Length contains the total length of the subobject in=20
            bytes, including the Type and Length fields. The Length is=20
            8 bytes for the Component Interface identifier IPv4 and=20
            Component Interface identifier Unnumbered types. For=20
            Component Interface identifier IPv6 type of sub-object, the=20
            length field is 20 bytes.=20
            =20
         U: 1 bit=20
   =20
            This bit indicates the direction of the component=20
            interface.  It is 0 for the downstream interface.  It is=20
            set to 1 for the upstream interface and is only used for=20
            bi-directional LSPs.       =20
               =20
4.1 Processing of Component Interface identifier RRO Subobject =20
    =20
      If a node desires component interface recording, then it sets the=20
   Label Recording flag in SESSION_ATTRIBUTE object as specified in=20
   [RFC3209]. In other words, when a node desires label recording, it=20
   will also receive the component interface sub-objects in the RRO for=20
   the bundled links from the nodes that implement this extension. When=20
   the Label Recording flag in SESSION_ATTRIBUTE object is set and the =20
=20
=20
Zamfir, A., Ali, Z.                                           [Page 7]=20

=0C         draft-zamfir-explicit-resource-control-bundle-00.txt March 2003=
=20
=20
=20
   outgoing TE Link is a bundled link, nodes doing route recording=20
   SHOULD include a Component Interface subobject along with the Label=20
   subobject. The Component Interface Record subobject is pushed onto=20
   the RECORD_ROUTE object prior to pushing on the node's IP address. A=20
   node MUST NOT push on a Component Interface Record subobject without=20
   also pushing on the IP address or unnumbered Interface Id subobject=20
   that identifies the TE Link.=20
   =20
      When component interfaces are recorded for bi-directional LSPs,=20
   component interface RRO subobjects for both downstream and upstream=20
   interfaces MUST be included.=20
   =20
5. Backward Compatibility Note=20
=20
      The extensions specified in this draft do not affect the=20
   processing of the ERO, RRO at nodes that do not support them. A node=20
   that receives an ERO that contains a Component Link ID subobject=20
   SHOULD send =91=91Bad EXPLICIT_ROUTE object" if it does not implement=
 this=20
   subobject. A node that does not support the Component Interface RRO=20
   subobject but that does support Label subobject SHOULD only insert=20
   the Label subobject in the RRO as per [RFC3471] and [RFC3473]. =20
   =20
6. Security Considerations=20
   =20
     This document does not introduce new security issues. The security=20
   considerations pertaining to the original RSVP protocol [RFC2205]=20
   remain relevant.  =20
   =20
7. Intellectual Property Considerations=20
   =20
      Cisco Systems may have intellectual property rights claimed in=20
   regard to some of the specification contained in this document.=20
   =20
References=20
   =20
   =20
   =20
   =20
   =20
References=20
=20
=20
   [RFC2205] " Resource ReSerVation Protocol (RSVP) - Version 1,=20
      Functional Specification", RFC 2205, Braden, et al, September=20
      1997. =20
   [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al,=20
   RFC 3209, December 2001.=20
   [GMPLS-BUNDLE] =91=91Link Bundling in MPLS Traffic Engineering=92=92,=
 draft-
      ietf-mpls-bundle-04.txt, K. Kompella, et al, January 2003.=20
=20
=20
Zamfir, A., Ali, Z.                                           [Page 8]=20

=0C         draft-zamfir-explicit-resource-control-bundle-00.txt March 2003=
=20
=20
=20
   [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS)=20
      Signaling Functional Description, RFC 3471, L. Berger, et al,=20
      January 2003.=20
   [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)=20
      Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-
      TE) Extensions", RFC 3471, L. Berger, et al, January 2003. =20
   [RFC3477] "Signaling Unnumbered Links in Resource ReSerVation=20
      Protocol - Traffic Engineering (RSVP-TE) ", RFC 3477, K. Kompella,=20
      Y. Rekhter, January 2003. =20
   [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",=20
      RFC 2119, S. Bradner, March 1997.=20
   =20
   =20
Author's Addresses=20
=20
   Anca Zamfir=20
   Cisco Systems Inc.=20
   2000 Innovation Dr., =20
   Kanata, Ontario, K2K 3E8  =20
   Canada.=20
   Phone: (613)-254-3484=20
   Email: [email-masked]=20
   =20
   Zafar Ali=20
   Cisco Systems Inc.=20
   100 South Main St. #200 =20
   Ann Arbor, MI 48104 =20
   USA. =20
   Phone: (734) 276-2459=20
   Email: [email-masked] =20
    =20

=20
=20
Zamfir, A., Ali, Z.                =20
[Page 9]=20

=0C
--=====================_47082751==_--

Delivery-date: Tue, 04 Mar 2003 15:27:47 -0800
Date: Tue, 4 Mar 2003 15:26:15 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: "David Allan" <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, Stephen Trowbridge <[email-masked]>,  <[email-masked]>, <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

David,

  What Kireeti and Curtis said, and to make things worse, I for one
  review the documents that try to make their front page more
  convincing than their substance with additional scrutiny...

-- 
Alex

Tuesday, March 4, 2003, 1:54:24 PM, David Allan wrote:
> Alex:

> You are offering a compelling argument to eliminate crediting of any authors
> on I-Ds etc. We can claim that there is no weight in a consensus based
> organization, while we struggle to eliminate the practice of 20 plus authors
> on a draft.

> I would assume I'm not the only one to note this inconsistency.

> Cheers
> Dave

> <snipped>

>>
>>Bingo!
>>
>>It seems to me that this is the only way to ensure fairness in the IETF,
> actually. Once 
>>we start introducing any sorts of preferences or "weights", it may become a
> too 
>>attractive backdoor around the IETF process.

>>Also, what does "weight" of a liaison or an ID really mean in a _consensus_
> based 
>>organization? That we should suddenly have a worm and fuzzy feeling about
> that doc? And 
>>how does this "weight" compare to, for example, the weight of the consensus
> within the 
>>IETF to not do what's proposed, if that happens?

Delivery-date: Tue, 04 Mar 2003 14:48:49 -0800
Date: Tue, 4 Mar 2003 14:48:00 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: David Allan <[email-masked]>
cc: [email-masked], "" <[email-masked]>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi Dave,

On Tue, 4 Mar 2003, David Allan wrote:

> You are offering a compelling argument to eliminate crediting of any authors
> on I-Ds etc.

Entirely orthogonal.  Every ID is given weight 1, independent of where
it came from, who the authors are or even how many authors there are.
If the ID came from a design team chosen by the WG chairs, by the ADs,
even by the IETF chair himself, the weight is still 1.

> We can claim that there is no weight in a consensus based
> organization, while we struggle to eliminate the practice of 20 plus authors
> on a draft.

If there are too many authors, they become contributors.  Simple.
No fuss, no mess, no struggle.  The main reason (I believe) is to
scale the RFC Editor process.

(To repeat, this is completely unrelated to the argument at hand,
viz., should liaisons and IDs from other SDOs have more weight than
individual submissions.)

> I would assume I'm not the only one to note this inconsistency.

You're the only one (so far) to see this as an inconsistency.  But
I'd rather not go down this (rathole) until we have settled more
important issues.

Kireeti.

Delivery-date: Tue, 04 Mar 2003 14:22:26 -0800
From: [email-masked]
Date: Tue, 4 Mar 2003 16:21:52 -0600
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
TO: [email-masked], [email-masked]
CC: [email-masked], [email-masked], [email-masked]

As someone trying to understand the IETF culture, this is probably the 
most enlightening thread I've seen.  Thanks.

I think the best description of the choices before the IETF were stated 
by Steve Trowbridge yesterday.  The processes defined by the IETF to 
accept and respond to liaisons are important to me, but perhaps less of 
a concern than hearing an agreement on the IETF procedures for 
addressing outside extensions to IP based protocols.

Ideally, each contribution can stand on its own merit or "weight."  
However, other organizations who use consensus as their mode of 
operation (using a different definition of consensus) complement that 
with a final voting process to clearly state the position of those 
organizations as a collective body.  The IETF can continue to address 
those contributions (liaisons) along with every other input as an ID, 
but because most every other organization has a clear liaison process, 
the IETF perspective will only be conveyed to those other organizations 
by the IETF drafts and RFCs.  Maybe there is agreement that that is 
sufficient, but it will probably not specifically address all liaison 
topics from outside organizations.

Regardless of the process that the IETF uses to address the 
contributions, network need for extensions, to address applications 
outside the IETF scope, will continue to be identified.  For that 
reason, there will be real network need for those extensions.  As Steve 
Trowbridge stated so clearly yesterday, the IETF must decide how it 
wants to respond to those outside applications.  This isn't necessarily 
a bad thing, but something we must come to accept.  The sooner an 
agreement is reached on the approach going forward, the sooner we can 
all get to work on the right solutions for the industry and get away 
from all this haggling over process and perspective.

Regards,

Mark Loyd Jones
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139

-----Original Message-----
From: zinin [mailto:[email-masked]]
Sent: Tuesday, March 04, 2003 2:39 PM
To: kireeti
Cc: sjtrowbridge; ccamp; mpls
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

<regular ietf'er hat on>

Monday, March 3, 2003, 2:26:06 PM, Kireeti Kompella wrote:
> Hi Steve,

> On Mon, 3 Mar 2003, Stephen Trowbridge wrote:

>> There is no doubt that liaisons CURRENTLY have no more wieght than
>> individual IDs

> This might be a fundamental difference between the IETF and other 
SDOs,
> the ITU in particular.  However, that still doesn't mean that this
> policy of the IETF's is wrong.  I happen to think that taking 
everything
> at its own merit rather than considering where it came from is the 
most
> democratic, equal opportunity means of handling it -- but that's a
> personal philosophy, not necessarily echoed by the IETF.

Bingo!

It seems to me that this is the only way to ensure fairness in the
IETF, actually. Once we start introducing any sorts of preferences or
"weights", it may become a too attractive backdoor around the IETF
process.

Also, what does "weight" of a liaison or an ID really mean in a
_consensus_ based organization? That we should suddenly have a worm
and fuzzy feeling about that doc? And how does this "weight" compare
to, for example, the weight of the consensus within the IETF to not do
what's proposed, if that happens?

Alex

Delivery-date: Tue, 04 Mar 2003 13:57:17 -0800
From: "David Allan" <[email-masked]>
To: "'Alex Zinin'" <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Tue, 4 Mar 2003 16:54:24 -0500 

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

Alex:

You are offering a compelling argument to eliminate crediting of any authors
on I-Ds etc. We can claim that there is no weight in a consensus based
organization, while we struggle to eliminate the practice of 20 plus authors
on a draft.

I would assume I'm not the only one to note this inconsistency.

Cheers
Dave

<snipped>

>
>Bingo!
>
>It seems to me that this is the only way to ensure fairness in the IETF,
actually. Once 
>we start introducing any sorts of preferences or "weights", it may become a
too 
>attractive backdoor around the IETF process.

>Also, what does "weight" of a liaison or an ID really mean in a _consensus_
based 
>organization? That we should suddenly have a worm and fuzzy feeling about
that doc? And 
>how does this "weight" compare to, for example, the weight of the consensus
within the 
>IETF to not do what's proposed, if that happens?

------_=_NextPart_001_01C2E298.9EB6D004
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 =
5.5.2656.31">
<TITLE>RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Alex:</FONT>
</P>

<P><FONT SIZE=3D2>You are offering a compelling argument to eliminate =
crediting of any authors on I-Ds etc. We can claim that there is no =
weight in a consensus based organization, while we struggle to =
eliminate the practice of 20 plus authors on a draft.</FONT></P>

<P><FONT SIZE=3D2>I would assume I'm not the only one to note this =
inconsistency.</FONT>
</P>

<P><FONT SIZE=3D2>Cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&lt;snipped&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Bingo!</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;It seems to me that this is the only way to =
ensure fairness in the IETF, actually. Once </FONT>
<BR><FONT SIZE=3D2>&gt;we start introducing any sorts of preferences or =
&quot;weights&quot;, it may become a too </FONT>
<BR><FONT SIZE=3D2>&gt;attractive backdoor around the IETF =
process.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Also, what does &quot;weight&quot; of a liaison =
or an ID really mean in a _consensus_ based </FONT>
<BR><FONT SIZE=3D2>&gt;organization? That we should suddenly have a =
worm and fuzzy feeling about that doc? And </FONT>
<BR><FONT SIZE=3D2>&gt;how does this &quot;weight&quot; compare to, for =
example, the weight of the consensus within the </FONT>
<BR><FONT SIZE=3D2>&gt;IETF to not do what's proposed, if that =
happens?</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2E298.9EB6D004--

Delivery-date: Tue, 04 Mar 2003 12:40:59 -0800
Date: Tue, 4 Mar 2003 12:38:49 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: Stephen Trowbridge <[email-masked]>, [email-masked], "" <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

<regular ietf'er hat on>

Monday, March 3, 2003, 2:26:06 PM, Kireeti Kompella wrote:
> Hi Steve,

> On Mon, 3 Mar 2003, Stephen Trowbridge wrote:

>> There is no doubt that liaisons CURRENTLY have no more wieght than
>> individual IDs

> This might be a fundamental difference between the IETF and other SDOs,
> the ITU in particular.  However, that still doesn't mean that this
> policy of the IETF's is wrong.  I happen to think that taking everything
> at its own merit rather than considering where it came from is the most
> democratic, equal opportunity means of handling it -- but that's a
> personal philosophy, not necessarily echoed by the IETF.

Bingo!

It seems to me that this is the only way to ensure fairness in the
IETF, actually. Once we start introducing any sorts of preferences or
"weights", it may become a too attractive backdoor around the IETF
process.

Also, what does "weight" of a liaison or an ID really mean in a
_consensus_ based organization? That we should suddenly have a worm
and fuzzy feeling about that doc? And how does this "weight" compare
to, for example, the weight of the consensus within the IETF to not do
what's proposed, if that happens?

Alex

Delivery-date: Tue, 04 Mar 2003 09:53:15 -0800
Date: Tue, 4 Mar 2003 09:51:39 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Stephen Shew <[email-masked]>
cc: Jonathan Sadler <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>
Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS   vto  Proposed Standard

Hi Stephen,

On Tue, 4 Mar 2003, Stephen Shew wrote:

> Kireeti, I can provide text but I need about a day to think about it and
> write it succinctly.

That's plenty quick.

> On the matter of the limitations of bandwidth value, I
> can live with your suggestions (a) and (b).

Great!

Kireeti.

Delivery-date: Tue, 04 Mar 2003 07:34:05 -0800
From: "Stephen Shew" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>
Cc: Jonathan Sadler <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS  vto  Proposed Standard
Date: Tue, 4 Mar 2003 10:33:04 -0500 

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_01C2E263.5908EEB4
Content-Type: text/plain

Kireeti, I can provide text but I need about a day to think about it and
write it succinctly.  On the matter of the limitations of bandwidth value, I
can live with your suggestions (a) and (b).

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]] 
Sent: Monday, March 03, 2003 17:40
To: Shew, Stephen [SKY:Q850:EXCH]
Cc: Jonathan Sadler; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS
vto Proposed Standard

Hi Stephen,

On Mon, 3 Mar 2003, Stephen Shew wrote:

> I don't know if the pun was intended, but I do like Kireeti's comment 
> about "bring them to light".

You're laser sharp, Stephen! :-)

> Undoubtedly, this would be within the ITU-T (wavelength) grid! ;-)

After the discussions we've had, I wouldn't dare not comply.

> There is, I think, some commonality in the comments and the reply in 
> that the intent is to generalize the extensions needed for routing to 
> accomodate non-PSC resources.  I agree with the first 4 points that 
> Jonathan made in that I think layer information must be included in 
> routing so that important functions can be performed.

Okay.  Can you provide text?

> I believe that the use of one or two bandwidth
> values was motivated by the desire to use a "lowest common 
> denominator" attribute to generalize on path computation and avoid 
> extensive details of links.  Unfortunately, this can obscure variable 
> adaptation on a link and the ability to determine a path at a 
> particular adaptation (e.g., VC-3).

You're right on both counts (about LCD, and about obscuring info). The
thinking was (a) let's see how far we can get with just the LCD;
(b) as we learn more, we can incorporate them, ideally in the SDH routing
doc.

Thoughts?

Kireeti.

------_=_NextPart_001_01C2E263.5908EEB4
Content-Type: text/html
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 =
5.5.2656.31">
<TITLE>RE: Last Call: Routing Extensions in Support of Generalized MPLS =
  vto  Proposed Standard</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Kireeti, I can provide text but I need about a day to =
think about it and write it succinctly.&nbsp; On the matter of the =
limitations of bandwidth value, I can live with your suggestions (a) =
and (b).</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kireeti Kompella [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, March 03, 2003 17:40</FONT>
<BR><FONT SIZE=3D2>To: Shew, Stephen [SKY:Q850:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: Jonathan Sadler; [email-masked]; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Last Call: Routing Extensions in =
Support of Generalized MPLS vto Proposed Standard</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Stephen,</FONT>
</P>

<P><FONT SIZE=3D2>On Mon, 3 Mar 2003, Stephen Shew wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I don't know if the pun was intended, but I do =
like Kireeti's comment </FONT>
<BR><FONT SIZE=3D2>&gt; about &quot;bring them to light&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>You're laser sharp, Stephen! :-)</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Undoubtedly, this would be within the ITU-T =
(wavelength) grid! ;-)</FONT>
</P>

<P><FONT SIZE=3D2>After the discussions we've had, I wouldn't dare not =
comply.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; There is, I think, some commonality in the =
comments and the reply in </FONT>
<BR><FONT SIZE=3D2>&gt; that the intent is to generalize the extensions =
needed for routing to </FONT>
<BR><FONT SIZE=3D2>&gt; accomodate non-PSC resources.&nbsp; I agree =
with the first 4 points that </FONT>
<BR><FONT SIZE=3D2>&gt; Jonathan made in that I think layer information =
must be included in </FONT>
<BR><FONT SIZE=3D2>&gt; routing so that important functions can be =
performed.</FONT>
</P>

<P><FONT SIZE=3D2>Okay.&nbsp; Can you provide text?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I believe that the use of one or two =
bandwidth</FONT>
<BR><FONT SIZE=3D2>&gt; values was motivated by the desire to use a =
&quot;lowest common </FONT>
<BR><FONT SIZE=3D2>&gt; denominator&quot; attribute to generalize on =
path computation and avoid </FONT>
<BR><FONT SIZE=3D2>&gt; extensive details of links.&nbsp; =
Unfortunately, this can obscure variable </FONT>
<BR><FONT SIZE=3D2>&gt; adaptation on a link and the ability to =
determine a path at a </FONT>
<BR><FONT SIZE=3D2>&gt; particular adaptation (e.g., VC-3).</FONT>
</P>

<P><FONT SIZE=3D2>You're right on both counts (about LCD, and about =
obscuring info). The thinking was (a) let's see how far we can get with =
just the LCD;</FONT></P>

<P><FONT SIZE=3D2>(b) as we learn more, we can incorporate them, =
ideally in the SDH routing doc.</FONT>
</P>

<P><FONT SIZE=3D2>Thoughts?</FONT>
</P>

<P><FONT SIZE=3D2>Kireeti.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2E263.5908EEB4--

Delivery-date: Tue, 04 Mar 2003 07:02:52 -0800
Date: Tue, 04 Mar 2003 16:00:42 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: Yangguang Xu <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

true, i took a look at

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-signaling-survey-03.txt

and i don't get you as well !

Yangguang Xu wrote:
> 
> You don't get it, do you?
> 
> BTW, this is IETF. I was talking about IETF stuff.
> 
> [email-masked] wrote:
> >
> > as from our side we are done with the oif stuff,
> > we've took the time to make some charts explaining
> > some of the issues related to this implementation
> > agreement (just to be sure that the next version
> > will be more easy to develop)
> >
> > http://psg.com/~dpapadimitriou/slides02.ppt
> >
> > Yangguang Xu wrote:
> > >
> > > Dimitri,
> > >
> > > >
> > > > ps: some of the critical oif players you refer in your
> > > > below e-mail are seriously questioning what has been done
> > > > over time ... and from this perspective only implementation
> > > > will decide about the relevance of these extensions
> > > >
> > >
> > > FYI, I've been writing code for all the time when you are talking...
> > >
> > > Yangguang
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : [email-masked]
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : +32 3 240-8491

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Tue, 04 Mar 2003 06:44:52 -0800
Date: Tue, 04 Mar 2003 09:46:17 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies ,  Optical Networking Group, MV
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

You don't get it, do you?

BTW, this is IETF. I was talking about IETF stuff.

[email-masked] wrote:
> 
> as from our side we are done with the oif stuff,
> we've took the time to make some charts explaining
> some of the issues related to this implementation
> agreement (just to be sure that the next version
> will be more easy to develop)
> 
> http://psg.com/~dpapadimitriou/slides02.ppt
> 
> Yangguang Xu wrote:
> >
> > Dimitri,
> >
> > >
> > > ps: some of the critical oif players you refer in your
> > > below e-mail are seriously questioning what has been done
> > > over time ... and from this perspective only implementation
> > > will decide about the relevance of these extensions
> > >
> >
> > FYI, I've been writing code for all the time when you are talking...
> >
> > Yangguang
> 
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491

Delivery-date: Tue, 04 Mar 2003 06:41:28 -0800
Date: Tue, 04 Mar 2003 15:38:32 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: Yangguang Xu <[email-masked]>
Cc: Zhi-Wei Lin <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

as from our side we are done with the oif stuff, 
we've took the time to make some charts explaining
some of the issues related to this implementation
agreement (just to be sure that the next version 
will be more easy to develop)

http://psg.com/~dpapadimitriou/slides02.ppt

Yangguang Xu wrote:
> 
> Dimitri,
> 
> >
> > ps: some of the critical oif players you refer in your
> > below e-mail are seriously questioning what has been done
> > over time ... and from this perspective only implementation
> > will decide about the relevance of these extensions
> >
> 
> FYI, I've been writing code for all the time when you are talking...
> 
> Yangguang

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Tue, 04 Mar 2003 05:19:49 -0800
Date: Tue, 04 Mar 2003 08:18:07 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: [email-masked]
CC: Zhi-Wei Lin <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Dimitri,

> 
> ps: some of the critical oif players you refer in your
> below e-mail are seriously questioning what has been done
> over time ... and from this perspective only implementation
> will decide about the relevance of these extensions
> 

FYI, I've been writing code for all the time when you are talking... 

Yangguang

Delivery-date: Tue, 04 Mar 2003 03:09:00 -0800
Date: Tue, 04 Mar 2003 12:06:06 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: Zhi-Wei Lin <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

zhi,

let's be very clear here, intent was to gather feedback
from the ccamp community during the yokohama meeting, i
have to say that the achieved consensus (as previously
explained was more than satisfactory imho) when you have
decided to go on the info track it has been based on the
expectation to get code points on time, now that you have
received them, i more than strongly suggest that you put 
this document over the table and that we discuss it... at 
the end i've got the impression that you don't want to 
discuss it at all anymore... is there something to hide 
here ?

ps: some of the critical oif players you refer in your
below e-mail are seriously questioning what has been done
over time ... and from this perspective only implementation
will decide about the relevance of these extensions

thanks,
- dimitri.

Zhi-Wei Lin wrote:
> 
> Hi Kireeti,
> 
> Just responding to your point (e) below. As someone pointed out in some
> previous email exchanges (seems like an age ago), when I submitted my I-D
> around the June timeframe, the IETF CCAMP WG were not particularly
> interested. However, I did work with and gotten quite good feedback
> privately. Among the folks were Adrian, Jerry, Dimitrios, Dimitri, Nick,
> Greg, Lyndon, Bala, Yangguang. Of course not everyone agreed with some of
> the particular solution but I don't think anyone questioned that there were
> technical issues with it...
> 
> And also as someone pointed out, many of the critical players in the GMPLS
> arena were also players in the OIF. I think the root cause is maybe not the
> liaison process but the intent of people working in the topic area? Just a
> guess...
> 
> Thanks
> Zhi
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of Kireeti
> > Kompella
> > Sent: Monday, March 03, 2003 5:26 PM
> > To: Stephen Trowbridge
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> >
> > Hi Steve,
> >
> > On Mon, 3 Mar 2003, Stephen Trowbridge wrote:
> >
> > > There is no doubt that liaisons CURRENTLY have no more wieght than
> > > individual IDs
> >
> > This might be a fundamental difference between the IETF and
> > other SDOs,
> > the ITU in particular.  However, that still doesn't mean that this
> > policy of the IETF's is wrong.  I happen to think that taking
> > everything
> > at its own merit rather than considering where it came from
> > is the most
> > democratic, equal opportunity means of handling it -- but that's a
> > personal philosophy, not necessarily echoed by the IETF.
> >
> > That said, if liaisons truly have lower priority than individual IDs,
> > it is more the vehicle (emails, notes posted to the liaison web page,
> > etc.) than the source or the content.  One the advice of a
> > wise person,
> > I have started (belatedly) posting to the CCAMP list that
> > such liaisons
> > exist.  Note that I don't need to do that for IDs -- the
> > authors generally
> > do that, and there is a mailing list that one can subscribe for this.
> >
> > > But it is my opinion that the lack of a liaison process is really
> > > the ROOT CAUSE of difficulties like what we saw in January.
> >
> > If we really do a root cause analysis, it comes down to this (IMO):
> > a) CCAMP gets a liaison statement stating that certain changes are
> >    requested in the GMPLS specs (doesn't get posted to the
> > list, though).
> > b) CCAMP doesn't officially respond (mechanisms not in place).
> > c) CCAMP WG gets requirements via Zhi's and Osama's drafts.
> > d) CCAMP mailing list hosts discussions about whether these
> > requirements
> >    make sense in the IETF context.
> > e) In the interest of quick allocation of code points, these two docs
> >    are made Informational, and go through without much review.
> > f) Various folks (CCAMP, RSVP, MPLS, ...) are very concerned about the
> >    changes made to RSVP and CR-LDP.
> >
> > (The intent here is not to point fingers, although I've
> > already claimed
> > my share of the blame.)
> >
> > I see (b) and (e) as the most serious breakdowns in the process.  The
> > GMPLS change doc should help alleviate (e), and hopefully help (a) as
> > well.  And if we get started on the liaison doc, that should help (b).
> >
> > Or we could keep talking :-)
> >
> > Kireeti.

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Mon, 03 Mar 2003 17:49:41 -0800
Date: Mon, 03 Mar 2003 15:57:38 -0700
From: Stephen Trowbridge <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Kireeti,

snip
> I have started (belatedly) posting to the CCAMP list that such liaisons
> exist.  Note that I don't need to do that for IDs -- the authors generally
> do that, and there is a mailing list that one can subscribe for this.
I saw this, and I think it is definitely a step in the right direction. Thanks!

> 
> > But it is my opinion that the lack of a liaison process is really
> > the ROOT CAUSE of difficulties like what we saw in January.
> 
> If we really do a root cause analysis, it comes down to this (IMO):
> a) CCAMP gets a liaison statement stating that certain changes are
>    requested in the GMPLS specs (doesn't get posted to the list, though).
Perhaps we didn't get an email out the instant something appeared in
http://www.ietf.org/IESG/liaison.html, but I think that (at least for
liaisons to ccamp from ITU-T SG15 since Oct. 2001) there was always
an email from the presenter (Wesam or myself) at the occasion of the
next IETF meeting with reminders about the location of the liaison information
and the slides presented in the meeting to explain them. So within a
window of time, I think all incoming liaisons were advertised.

> b) CCAMP doesn't officially respond (mechanisms not in place).
> c) CCAMP WG gets requirements via Zhi's and Osama's drafts.
> d) CCAMP mailing list hosts discussions about whether these requirements
>    make sense in the IETF context.
> e) In the interest of quick allocation of code points, these two docs
>    are made Informational, and go through without much review.
> f) Various folks (CCAMP, RSVP, MPLS, ...) are very concerned about the
>    changes made to RSVP and CR-LDP.
> 
> (The intent here is not to point fingers, although I've already claimed
> my share of the blame.)
> 
> I see (b) and (e) as the most serious breakdowns in the process.  The
> GMPLS change doc should help alleviate (e), and hopefully help (a) as
> well.  And if we get started on the liaison doc, that should help (b).
Personally, I think that if we had done a good job at getting the bi-
directional communication channel going at (b), we wouldn't have run
into problems at (e). Either ccamp would have been actively involved in
producing the solution, or people would have understood the reasons
why it was being done outside and been OK with it at (e).

What happened at (e) was a step to try to unblock some ITU-T work that
was stuck because we didn't get the right communication to happen at (b).
I think what some of us worry about here is that if we remove the flexibility
we had at (e) without fixing the communication problem at (b), then IETF
ends up (intentionally or unintentionally, depending on who in this thread
you believe) putting up roadblocks to the progress in other organizations.
This is why we feel that the liaison process has to be either a prerequisite
(or a co-requisite) of the change control process.

> Or we could keep talking :-)
I'm sure we'll do this anyway ...
> 
> Kireeti.

Regards,
Steve

Delivery-date: Mon, 03 Mar 2003 17:30:23 -0800
To: Stephen Trowbridge <[email-masked]>
cc: Loa Andersson <[email-masked]>, [email-masked], "Varma, Eve L (Eve)" <[email-masked]>, George Newsome <[email-masked]>, [email-masked], ccamp <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Mon, 03 Mar 2003 13:49:02 -0500
From: Curtis Villamizar <[email-masked]>

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <[email-masked]>, Stephen Trowbridge writes:
> Loa,
> (snip)
> > I don't discus liasions, simply because it
> > was and is
> > my opinion that they are not in the picture then it comes to handling
> > changes to the
> > (g)mpls protocols.
> So, if another SDO thinks that an IETF protocol (possibly with extensions)
> would be a good solution to their problem, they would ask for this how?
> Regards,
> Steve

Steve,

They would bring the topic up on the appropriate WG mailing list and
submit an internet-draft.

Your prior example of ASON is analogous IETF creating document that
change the underlying SONET model and creating extensions to SONET
outside of ITU (for example: using the loosely defined or undefined
portion of the SONET overhead) specificly to support IP and then
claiming that it was for IP so ITU should just accept it without
questioning it.  There is no reason for the IETF to accept ASON as a
requirement for MPLS/GMPLS.

Curtis

Delivery-date: Mon, 03 Mar 2003 16:59:36 -0800
Date: Mon, 3 Mar 2003 16:58:44 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Curtis Villamizar <[email-masked]>
cc: Malcolm Betts <[email-masked]>, Stephen Trowbridge <[email-masked]>, "" <[email-masked]>, ccamp <[email-masked]>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 

Hi Curtis,

On Mon, 3 Mar 2003, Curtis Villamizar wrote:

> > Kireeti, if we can agree that we have two problems and from the perspective
> > of an external SDO they are closely coupled.  One way of moving forward
> > would be to develop two IDs in parallel.  The first based on the existing
> > anderson-mpls-g-change-proc, modified to state explicitly that requests for
> > changes by external SDOs are exempt from this process.  The second draft
> > would address the liaison process.  The key issue with changes requested by
> > external SDOs is that in general they will be based on the desire to apply
> > (G)MPLS protocols to connection management of connection oriented circuit
> > switched (COCS) networks for the benefit of COCS clients - i.e. to
> > applications that are well outside the "normal" IETF problem space. To keep
> > the activity  focussed (as suggested in some earlier emails) perhaps we
> > could limit the scope to the sub ip area only (at least initially).  I think
> > that Steve Trowbridge in an earlier email (copy below) provided a good
> > summary of the objectives of the liaison process.
>
>
> This is just fine except there is no concensus either way on Steve's
> opinion that the role of liasons should be changed.

Going further, I don't think consensus in the CCAMP WG (or even in
the sub-IP area) will change this -- there *are* some things in the
IETF that don't work by consensus.

> Therefore Loa's draft should not mention exclusion of liasons, because
> changing the liason relationship is not the current intent, and
> because the liason relationship will be addressed separately as
> suggested by Scott Bradner.

Agreed.

FYI: a group of us are working on a liaison draft, mainly to put the
issue in front of the IESG.  *I* don't envision this as a sub-IP pilot,
nor do I see this coming of the the CCAMP WG (nor the ITU-T) -- it will
be an individual submission from a bunch of concerned individuals.
Then again, it's a group of us, and we need to come to consensus :-)

Kireeti.

Delivery-date: Mon, 03 Mar 2003 16:10:07 -0800
Date: Mon, 03 Mar 2003 19:08:12 -0500
From: Zhi-Wei Lin <[email-masked]>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
To: 'Kireeti Kompella' <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>
Cc: [email-masked], [email-masked]

Hi Kireeti,

Just responding to your point (e) below. As someone pointed out in some
previous email exchanges (seems like an age ago), when I submitted my I-D
around the June timeframe, the IETF CCAMP WG were not particularly
interested. However, I did work with and gotten quite good feedback
privately. Among the folks were Adrian, Jerry, Dimitrios, Dimitri, Nick,
Greg, Lyndon, Bala, Yangguang. Of course not everyone agreed with some of
the particular solution but I don't think anyone questioned that there were
technical issues with it...

And also as someone pointed out, many of the critical players in the GMPLS
arena were also players in the OIF. I think the root cause is maybe not the
liaison process but the intent of people working in the topic area? Just a
guess...

Thanks
Zhi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Kireeti
> Kompella
> Sent: Monday, March 03, 2003 5:26 PM
> To: Stephen Trowbridge
> Cc: [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
>
> Hi Steve,
>
> On Mon, 3 Mar 2003, Stephen Trowbridge wrote:
>
> > There is no doubt that liaisons CURRENTLY have no more wieght than
> > individual IDs
>
> This might be a fundamental difference between the IETF and
> other SDOs,
> the ITU in particular.  However, that still doesn't mean that this
> policy of the IETF's is wrong.  I happen to think that taking
> everything
> at its own merit rather than considering where it came from
> is the most
> democratic, equal opportunity means of handling it -- but that's a
> personal philosophy, not necessarily echoed by the IETF.
>
> That said, if liaisons truly have lower priority than individual IDs,
> it is more the vehicle (emails, notes posted to the liaison web page,
> etc.) than the source or the content.  One the advice of a
> wise person,
> I have started (belatedly) posting to the CCAMP list that
> such liaisons
> exist.  Note that I don't need to do that for IDs -- the
> authors generally
> do that, and there is a mailing list that one can subscribe for this.
>
> > But it is my opinion that the lack of a liaison process is really
> > the ROOT CAUSE of difficulties like what we saw in January.
>
> If we really do a root cause analysis, it comes down to this (IMO):
> a) CCAMP gets a liaison statement stating that certain changes are
>    requested in the GMPLS specs (doesn't get posted to the
> list, though).
> b) CCAMP doesn't officially respond (mechanisms not in place).
> c) CCAMP WG gets requirements via Zhi's and Osama's drafts.
> d) CCAMP mailing list hosts discussions about whether these
> requirements
>    make sense in the IETF context.
> e) In the interest of quick allocation of code points, these two docs
>    are made Informational, and go through without much review.
> f) Various folks (CCAMP, RSVP, MPLS, ...) are very concerned about the
>    changes made to RSVP and CR-LDP.
>
> (The intent here is not to point fingers, although I've
> already claimed
> my share of the blame.)
>
> I see (b) and (e) as the most serious breakdowns in the process.  The
> GMPLS change doc should help alleviate (e), and hopefully help (a) as
> well.  And if we get started on the liaison doc, that should help (b).
>
> Or we could keep talking :-)
>
> Kireeti.

Delivery-date: Mon, 03 Mar 2003 14:52:53 -0800
Date: Mon, 3 Mar 2003 14:52:17 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Yangguang Xu <[email-masked]>
cc: Jonathan Sadler <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto   Proposed Standard

Hi Yangguang,

On Mon, 3 Mar 2003, Yangguang Xu wrote:

> I am trying to understand what you mean about a general document.

Remember the generalized signaling documents -- a func spec, an RSVP
doc and a CR-LDP doc?  And a separate doc for SDH?  We were well-advised
by Bert that this
(a) is more in line with the COMMON part of ccamp;
(b) makes progress of the documents easier; and
(c) provides a template for future extensions.

So, the authors took out almost all the SDH related work from the
the common doc, and put it into a separate doc.  The only SDH stuff
remaining in the common doc are code points that were further developed
in the SDH doc.

The routing docs followed exactly the same paradigm.  Thus I would
prefer to see code points for SDH, but little else in the common
routing specs.

> Does a general
> document cover only "lowest common denominator" or define a flexible mechanism
> that could accommodate various situations? I think it should be the latter.

The latter.

> Then, layering and flexible layer adaptation are pretty common, I think this
> draft should define a general mechanism to deal with it. (and sure, xxx
> technology specific values can be defined in other xxx specific draft)

I've just asked Stephen Shew for text in this regard.

Kireeti.

Delivery-date: Mon, 03 Mar 2003 14:41:35 -0800
Date: Mon, 3 Mar 2003 14:41:20 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Varma, Eve L (Eve)" <[email-masked]>
cc: George Newsome <[email-masked]>, ccamp <[email-masked]>
Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS   to  Proposed Standard

On Mon, 3 Mar 2003, Varma, Eve L (Eve) wrote:

> Hi Kireeti,
>
> I thought the technical comments George made re your input to Jonathan
> were reasonable.  Would you be willing to respond to those?  Some further
> discussion would be quite useful.

Sure, Eve.  Will George repost without the intro?

Kireeti.

Delivery-date: Mon, 03 Mar 2003 14:40:29 -0800
Date: Mon, 3 Mar 2003 14:40:14 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Stephen Shew <[email-masked]>
cc: Jonathan Sadler <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>
Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS   vto  Proposed Standard

Hi Stephen,

On Mon, 3 Mar 2003, Stephen Shew wrote:

> I don't know if the pun was intended, but I do like Kireeti's comment about
> "bring them to light".

You're laser sharp, Stephen! :-)

> Undoubtedly, this would be within the ITU-T (wavelength) grid! ;-)

After the discussions we've had, I wouldn't dare not comply.

> There is, I think, some commonality in the comments and the reply in that
> the intent is to generalize the extensions needed for routing to accomodate
> non-PSC resources.  I agree with the first 4 points that Jonathan made in
> that I think layer information must be included in routing so that important
> functions can be performed.

Okay.  Can you provide text?

> I believe that the use of one or two bandwidth
> values was motivated by the desire to use a "lowest common denominator"
> attribute to generalize on path computation and avoid extensive details of
> links.  Unfortunately, this can obscure variable adaptation on a link and
> the ability to determine a path at a particular adaptation (e.g., VC-3).

You're right on both counts (about LCD, and about obscuring info).
The thinking was (a) let's see how far we can get with just the LCD;
(b) as we learn more, we can incorporate them, ideally in the SDH
routing doc.

Thoughts?

Kireeti.

Delivery-date: Mon, 03 Mar 2003 14:38:54 -0800
From: "Malcolm Betts" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, Stephen Trowbridge <[email-masked]>
Cc: [email-masked], ccamp <[email-masked]>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Mon, 3 Mar 2003 17:38:12 -0500 

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_01C2E1D3.B6CDA638
Content-Type: text/plain

Kireeti, if we can agree that we have two problems and from the perspective
of an external SDO they are closely coupled.  One way of moving forward
would be to develop two IDs in parallel.  The first based on the existing
anderson-mpls-g-change-proc, modified to state explicitly that requests for
changes by external SDOs are exempt from this process.  The second draft
would address the liaison process.  The key issue with changes requested by
external SDOs is that in general they will be based on the desire to apply
(G)MPLS protocols to connection management of connection oriented circuit
switched (COCS) networks for the benefit of COCS clients - i.e. to
applications that are well outside the "normal" IETF problem space. To keep
the activity  focussed (as suggested in some earlier emails) perhaps we
could limit the scope to the sub ip area only (at least initially).  I think
that Steve Trowbridge in an earlier email (copy below) provided a good
summary of the objectives of the liaison process.

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]] 
Sent: Monday, March 03, 2003 5:02 PM
To: Stephen Trowbridge
Cc: [email-masked]; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi Steve,

On Mon, 3 Mar 2003, Stephen Trowbridge wrote:

> Lets try to zero in on what the problem really is.

Good idea.

> I think that liaison handling (or the lack thereof) is not just a 
> problem. It is THE problem.

I disagree.  I think there are two problems, and both are important.

<snip>

<insert for Steve Trowbridge>

IETF has one set of requirements for the kinds of networks that they
envision and are within their charter. They develop an architecture and
protocol solutions to support those requirements. ITU-T has an (overlapping
but different) set of requirements for the kinds of networks they envision
(including lots of TDM & WDM traffic that doesn't necessarily carry IP,
etc.). Nobody says that the additional ITU-T requirements are valid for the
IETF application, or that IETF must solve the ITU-T requirements with IETF
developed protocols (they can choose to, but there is no obligation).

When the ITU-T brings these requirements to the IETF's attention, there are
a variety of perfectly reasonable responses:
- The IETF can say "That requirement is important for us also, let's work
  toward a common solution".
- The IETF can say "That requirement is not important for the IETF scope
  of work, but we can see how it is important for yours. From our
  experience with the protocol and our desire for sanity in the protocol
  and all of its extensions, we can offer you the following advice about
  how the protocol can best solve your problem ..."
- The IETF can say "That requirement is not important for the IETF scope
  of work and we are not particularly interested in helping with a solution
-
  you are on your own, but please assign any protocol codepoints through
  IANA and document your extensions as an info RFC so that we can prevent
  any conflict with other extensions.
They could EVEN say "We think you might have misunderstood the requirements:
do you think that the following restatement of the problem would allow your
needs to be met with the current protocols: ..."

But the answer that I would have trouble with would be the IETF saying "That
requirement is not important for the IETF scope of work, and therefore no
solution should be developed for your problem AT ALL. After all, if it is
not important for IETF, it must be irrelevant for everybody."

Of course, without a liaison process, I don't know how we get any of these
responses. Incoming liaisons seem to hit the dustbin before they get serious
consideration regarding which of the above response types might be most
appropriate. Regards, Steve

<end inserted text>

Malcolm Betts

Phone: +1 613 763 7860 (ESN 393)
FAX:   +1 613 763 6608 (ESN 393)
email: [email-masked]

------_=_NextPart_001_01C2E1D3.B6CDA638
Content-Type: text/html
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 =
5.5.2656.31">
<TITLE>RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Kireeti, if we can agree that we have two problems =
and from the perspective of an external SDO they are closely =
coupled.&nbsp; One way of moving forward would be to develop two IDs in =
parallel.&nbsp; The first based on the existing =
anderson-mpls-g-change-proc, modified to state explicitly that requests =
for changes by external SDOs are exempt from this process.&nbsp; The =
second draft would address the liaison process.&nbsp; The key issue =
with changes requested by external SDOs is that in general they will be =
based on the desire to apply (G)MPLS protocols to connection management =
of connection oriented circuit switched (COCS) networks for the benefit =
of COCS clients - i.e. to applications that are well outside the =
&quot;normal&quot; IETF problem space. To keep the activity&nbsp; =
focussed (as suggested in some earlier emails) perhaps we could limit =
the scope to the sub ip area only (at least initially).&nbsp; I think =
that Steve Trowbridge in an earlier email (copy below) provided a good =
summary of the objectives of the liaison process.</FONT></P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kireeti Kompella [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, March 03, 2003 5:02 PM</FONT>
<BR><FONT SIZE=3D2>To: Stephen Trowbridge</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; ccamp</FONT>
<BR><FONT SIZE=3D2>Subject: Re: I-D =
ACTION:draft-andersson-mpls-g-chng-proc-00.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Steve,</FONT>
</P>

<P><FONT SIZE=3D2>On Mon, 3 Mar 2003, Stephen Trowbridge wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Lets try to zero in on what the problem really =
is.</FONT>
</P>

<P><FONT SIZE=3D2>Good idea.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I think that liaison handling (or the lack =
thereof) is not just a </FONT>
<BR><FONT SIZE=3D2>&gt; problem. It is THE problem.</FONT>
</P>

<P><FONT SIZE=3D2>I disagree.&nbsp; I think there are two problems, and =
both are important.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&lt;insert for Steve Trowbridge&gt;</FONT>
</P>

<P><FONT SIZE=3D2>IETF has one set of requirements for the kinds of =
networks that they envision and are within their charter. They develop =
an architecture and protocol solutions to support those requirements. =
ITU-T has an (overlapping but different) set of requirements for the =
kinds of networks they envision (including lots of TDM &amp; WDM =
traffic that doesn't necessarily carry IP, etc.). Nobody says that the =
additional ITU-T requirements are valid for the IETF application, or =
that IETF must solve the ITU-T requirements with IETF developed =
protocols (they can choose to, but there is no obligation).</FONT></P>

<P><FONT SIZE=3D2>When the ITU-T brings these requirements to the =
IETF's attention, there are a variety of perfectly reasonable =
responses:</FONT></P>

<P><FONT SIZE=3D2>- The IETF can say &quot;That requirement is =
important for us also, let's work</FONT>
<BR><FONT SIZE=3D2>&nbsp; toward a common solution&quot;.</FONT>
<BR><FONT SIZE=3D2>- The IETF can say &quot;That requirement is not =
important for the IETF scope</FONT>
<BR><FONT SIZE=3D2>&nbsp; of work, but we can see how it is important =
for yours. From our</FONT>
<BR><FONT SIZE=3D2>&nbsp; experience with the protocol and our desire =
for sanity in the protocol</FONT>
<BR><FONT SIZE=3D2>&nbsp; and all of its extensions, we can offer you =
the following advice about</FONT>
<BR><FONT SIZE=3D2>&nbsp; how the protocol can best solve your problem =
...&quot;</FONT>
<BR><FONT SIZE=3D2>- The IETF can say &quot;That requirement is not =
important for the IETF scope</FONT>
<BR><FONT SIZE=3D2>&nbsp; of work and we are not particularly =
interested in helping with a solution -</FONT>
<BR><FONT SIZE=3D2>&nbsp; you are on your own, but please assign any =
protocol codepoints through</FONT>
<BR><FONT SIZE=3D2>&nbsp; IANA and document your extensions as an info =
RFC so that we can prevent</FONT>
<BR><FONT SIZE=3D2>&nbsp; any conflict with other extensions.</FONT>
<BR><FONT SIZE=3D2>They could EVEN say &quot;We think you might have =
misunderstood the requirements: do you think that the following =
restatement of the problem would allow your needs to be met with the =
current protocols: ...&quot;</FONT></P>

<P><FONT SIZE=3D2>But the answer that I would have trouble with would =
be the IETF saying &quot;That requirement is not important for the IETF =
scope of work, and therefore no solution should be developed for your =
problem AT ALL. After all, if it is not important for IETF, it must be =
irrelevant for everybody.&quot;</FONT></P>

<P><FONT SIZE=3D2>Of course, without a liaison process, I don't know =
how we get any of these responses. Incoming liaisons seem to hit the =
dustbin before they get serious consideration regarding which of the =
above response types might be most appropriate. Regards, =
Steve</FONT></P>

<P><FONT SIZE=3D2>&lt;end inserted text&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Malcolm Betts</FONT>
</P>

<P><FONT SIZE=3D2>Phone: +1 613 763 7860 (ESN 393)</FONT>
<BR><FONT SIZE=3D2>FAX:&nbsp;&nbsp; +1 613 763 6608 (ESN 393)</FONT>
<BR><FONT SIZE=3D2>email: [email-masked]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2E1D3.B6CDA638--

Delivery-date: Mon, 03 Mar 2003 14:31:20 -0800
Date: Mon, 03 Mar 2003 17:30:44 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: Kireeti Kompella <[email-masked]>
CC: Jonathan Sadler <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto   Proposed Standard

Kireeti,

I am trying to understand what you mean about a general document. Does a general
document cover only "lowest common denominator" or define a flexible mechanism
that could accommodate various situations? I think it should be the latter.
Then, layering and flexible layer adaptation are pretty common, I think this
draft should define a general mechanism to deal with it. (and sure, xxx
technology specific values can be defined in other xxx specific draft)

BTW, could a general document be really general without fully
studying/understanding most of xxx specific routings first? 

Thanks,

Yangguang 

> It is also not the intent of this document to provide a full description
> of routing info for SDH.  This is a *general* document.  The intent is
> to provide a code point for SDH to be expanded by another document.  This
> was the model used for signaling as well: a *general* func spec, a
> *general* doc for each protocol, and *SDH-specific* docs.  There is an
> SDH specific routing doc; detailed comments are better directed there.
> 
> >  - Sometimes layer relationships are described in an "inverted"
> >    manner*. Section 5.1 of draft-ietf-ccamp-gmpls-routing-05.txt
> >    states:
> >      "STM-16 POS Interface on a LSR
> >
> >           Interface Switching Capability Descriptor:
> >              Interface Switching Capability = PSC-1
> >              Encoding = SDH
> >              Max LSP Bandwidth[p] = 2.5 Gbps, for all p"
> >
> >    Where PSC-1 is the client of an SDH (sic) server.
> >
> >    Section 5.5 states:
> >       "Interface of an opaque OXC (SDH framed) with support for
> >        one lambda per port/interface"
> >
> >       "   Interface Switching Capability Descriptor:
> >              Interface Switching Capability = LSC
> >              Encoding = SDH"
> >
> >    In this case, SDH is a client of a wavelength server (LSC).
> >    However, unlike in section 5.1, the layer relationship is
> >    inverted.
> 
> Is this pointed out as a curiosity, or is there a question that needs
> to be addressed?
> 
> > 3. Layer specific attributes are not supported*.  Specifically:
> 
> Good points.  Please raise this with the SDH routing doc.
> 
> > 4. The "TDM" Interface Switching Capability presumably includes
> >    layers other than SONET/SDH, such as PDH* (DS1, DS3, E1, E3) and
> >    G.709.  The interaction with these layers needs to be defined.
> 
> Ditto.
> 
> > 5. In many cases, 8 levels of priority are not necessary*.  A more
> >    compact encoding that has a bitfield stating the priority levels
> >    being announced would reduce the size of the announcement.
> 
> This has been discussed elsewhere.  This is the model in the base
> TE document; it has proven reasonable in practice.  If deployment
> proves otherwise, this is easy to fix.  For now, though, I would
> leave it as is.
> 
> Thanks again for your comments,
> Kireeti.

Delivery-date: Mon, 03 Mar 2003 14:27:59 -0800
Date: Mon, 3 Mar 2003 14:26:06 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Stephen Trowbridge <[email-masked]>
cc: [email-masked], "" <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi Steve,

On Mon, 3 Mar 2003, Stephen Trowbridge wrote:

> There is no doubt that liaisons CURRENTLY have no more wieght than
> individual IDs

This might be a fundamental difference between the IETF and other SDOs,
the ITU in particular.  However, that still doesn't mean that this
policy of the IETF's is wrong.  I happen to think that taking everything
at its own merit rather than considering where it came from is the most
democratic, equal opportunity means of handling it -- but that's a
personal philosophy, not necessarily echoed by the IETF.

That said, if liaisons truly have lower priority than individual IDs,
it is more the vehicle (emails, notes posted to the liaison web page,
etc.) than the source or the content.  One the advice of a wise person,
I have started (belatedly) posting to the CCAMP list that such liaisons
exist.  Note that I don't need to do that for IDs -- the authors generally
do that, and there is a mailing list that one can subscribe for this.

> But it is my opinion that the lack of a liaison process is really
> the ROOT CAUSE of difficulties like what we saw in January.

If we really do a root cause analysis, it comes down to this (IMO):
a) CCAMP gets a liaison statement stating that certain changes are
   requested in the GMPLS specs (doesn't get posted to the list, though).
b) CCAMP doesn't officially respond (mechanisms not in place).
c) CCAMP WG gets requirements via Zhi's and Osama's drafts.
d) CCAMP mailing list hosts discussions about whether these requirements
   make sense in the IETF context.
e) In the interest of quick allocation of code points, these two docs
   are made Informational, and go through without much review.
f) Various folks (CCAMP, RSVP, MPLS, ...) are very concerned about the
   changes made to RSVP and CR-LDP.

(The intent here is not to point fingers, although I've already claimed
my share of the blame.)

I see (b) and (e) as the most serious breakdowns in the process.  The
GMPLS change doc should help alleviate (e), and hopefully help (a) as
well.  And if we get started on the liaison doc, that should help (b).

Or we could keep talking :-)

Kireeti.

Delivery-date: Mon, 03 Mar 2003 14:07:58 -0800
Date: Mon, 3 Mar 2003 14:06:57 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>
cc: Stephen Trowbridge <[email-masked]>, George Swallow <[email-masked]>, "" <[email-masked]>, Loa Andersson <[email-masked]>, "" <[email-masked]>, ccamp <[email-masked]>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi Deborah,

On Mon, 3 Mar 2003, Brungard, Deborah A, ALABS wrote:

> I think we have agreement to do a separate document on the liaison
> process? (as I'm writing, I see a mail just now from Scott saying this).

I didn't know that :-)  But nonetheless, it's a good idea -- it's a
starting point, and should give the IESG/IAB some fodder.

> Loa, not sure if you were volunteering the g-chng proc authors? They are
> probably the most appropriate. If you need support (either
> visible/ghosts), Steve (ok, Steve?) can help from the ITU perspective, I
> can help from the T1X1 side.

I'd be happy to help, and to work with Deborah, Steve and others.  One
thing I would request is to submit this ID to the problem statement WG,
and let them (or the IESG) redirect this as needed.

Kireeti.

Delivery-date: Mon, 03 Mar 2003 14:02:52 -0800
Date: Mon, 3 Mar 2003 14:02:21 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Stephen Trowbridge <[email-masked]>
cc: [email-masked], ccamp <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi Steve,

On Mon, 3 Mar 2003, Stephen Trowbridge wrote:

> Lets try to zero in on what the problem really is.

Good idea.

> I think that liaison handling (or the lack thereof) is not just a
> problem. It is THE problem.

I disagree.  I think there are two problems, and both are important.

> Does anybody really believe that the
> reason this draft exists in the first place is that there are a
> bunch of individuals going wild trying to change or extend the
> (G)MPLS protocols?

Yes, actually, I do.  Maybe not "going wild", but the necessary
review is not always done to make sure the changes are needed and
in concert with the architecture of the protocols.

> What seems to have generated most of the arguments is the handling
> (or bungling) of the communications process (or lack of process)
> with other SDOs. This is the process we need to fix.

No argument here.

> Dealing with requests from individuals to extend or change the
> protocols might be good to have a process for, but realistically,
> has any individual made such a request yet? Why is this important?

Every ID is a request from an individual.  Every ID is important
(until proven otherwise).

> Now, if we can agree that liaisons are THE problem,

We agree to disagree on that :-)

> - We can start work on a general purpose liaison process to be
> applied across the whole of IETF (revival of one of the POIS*
> working groups?).
> - We could try to develop a pilot process for sub-IP (which is
> where we seem to have a lot of the problems), and take what we
> learn from its implementation to feed into a process that would
> apply to the whole of IETF.

We (you and I) can do little (except write IDs :-)).  The ADs should
give us guidance on how to proceed.  And, from my reading, the
guidance is that the liaison problem should be solved holistically
(not piecemeal in Sub-IP) and in *some other WG*, like the problem
statement WG.

Kireeti.

Delivery-date: Mon, 03 Mar 2003 13:56:16 -0800
Date: Mon, 3 Mar 2003 13:55:49 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Genadi Velev <[email-masked]>
cc: [email-masked], "" <[email-masked]>
Subject: RE: draft-kawakami-mpls-lsp-vlan-00.txt

Hi Ganadi,

On Mon, 3 Mar 2003, Genadi Velev wrote:

> thanks for your clarification. You are right that this technology is a
> specific one, but OTOH as Dimitri pointed out it fits perfectly to the group
> of Layer-2 Switch Capable (L2SC) interfaces.

I agree that this applies to L2SC interfaces.  But CCAMP doesn't deal
with L2SC interfaces (it's not in the charter).

> I would like to ask you and Loa/George to help us to find the proper WG for
> the draft!

We'll talk to the ADs and let you know.

I understand that this may not be the answer you want; however,  In the
end, the IESG/IAB must decide what work items a particular WG can work
on.  Here, you are in the unfortunate position that there is no WG that
is chartered to do this work.

If you are going for an Informational document, things may be a bit
easier.

Kireeti.

Delivery-date: Mon, 03 Mar 2003 13:56:08 -0800
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, George Newsome <[email-masked]>
Cc: ccamp <[email-masked]>
Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS  to  Proposed Standard
Date: Mon, 3 Mar 2003 16:55:35 -0500 

Hi Kireeti,

I thought the technical comments George made re your input to Jonathan
were reasonable.  Would you be willing to respond to those?  Some further
discussion would be quite useful.

Eve

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Monday, March 03, 2003 4:46 PM
To: George Newsome
Cc: ccamp
Subject: Re: Last Call: Routing Extensions in Support of Generalized
MPLS to Proposed Standard

Hi George,

On Mon, 3 Mar 2003, George Newsome wrote:

> Just a few comments (in line) on your brush off of Jonathans remarks.

If you'd care to be more civil, I might even read your email next time.

For your information, I read Jonathan's mail diligently, and answered
it as well as I could (and in a civil fashion).  The point is not to
agree or disagree blindly with everything everyone says, but to reach
some consensus.  Reaching consensus is made much harder if the various
parties approach this task with an attitude.

Kireeti.

Delivery-date: Mon, 03 Mar 2003 13:47:01 -0800
Date: Mon, 3 Mar 2003 13:45:47 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: George Newsome <[email-masked]>
cc: ccamp <[email-masked]>
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS  to  Proposed Standard

Hi George,

On Mon, 3 Mar 2003, George Newsome wrote:

> Just a few comments (in line) on your brush off of Jonathans remarks.

If you'd care to be more civil, I might even read your email next time.

For your information, I read Jonathan's mail diligently, and answered
it as well as I could (and in a civil fashion).  The point is not to
agree or disagree blindly with everything everyone says, but to reach
some consensus.  Reaching consensus is made much harder if the various
parties approach this task with an attitude.

Kireeti.

Delivery-date: Mon, 03 Mar 2003 13:21:59 -0800
Date: Mon, 03 Mar 2003 16:18:20 -0500
From: George Newsome <[email-masked]>
To: [email-masked], Jonathan Sadler <[email-masked]>, ccamp <[email-masked]>
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS  to  Proposed Standard

Kireeti,

Just a few comments (in line) on your brush off of Jonathans remarks.

Regards

		George

Kireeti Kompella wrote:

 > Hi Jonathan,
 >
 > On Sun, 23 Feb 2003, Jonathan Sadler wrote:
 >
 >
 >
 >>==========
 >>
 >>1. In section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt, the 
operations for
 >>Packet Switch Capable (PSC) are defined.  Reference is made to 
Minimum LSP bandwidth
 >>for SDH encoding.  None of the examples in section 5 of
 >>draft-ietf-ccamp-gmpls-routing-05.txt show how this field should filled.
 >>
 >
 > Note that all possible permutations cannot possibly be addressed; 
however,
 > we will consider adding some examples here.
 >

This doesn't sound like a lack of examples, but a missing specification
of the field contents.

 >

 >>  - Relationships between PSC-n (for IP switching) and SONET/SDH are
 >>    explicitly specified on the encoding type specified in the PSC-n
 >>    announcement*.  However, SONET/SDH is not a single layer.  It
 >>    must be possible to identify if the PSC-n layer can be carried
 >>    by a VC-11 trail, a VC-12 trail, a VC-3 trail, a VC-4 trail,
 >>    or a VC-4-nc trail.
 >>
 >>    Section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt tries
 >>    to deal with this in the following paragraph:
 >>
 >>     "On a PSC interface that supports Standard SDH encoding, an
 >>      LSP at priority p could reserve any bandwidth allowed by
 >>      the branch of the SDH hierarchy, with the leaf and the root
 >>      of the branch being defined by the Minimum LSP Bandwidth
 >>      and the Maximum LSP Bandwidth at priority p."
 >>
 >>    The problem is this contradicts the following paragraph:
 >>
 >>     "The Maximum LSP Bandwidth takes the place of the Maximum
 >>      Bandwidth ([ISIS-TE], [OSPF-TE]). However, while Maximum
 >>      Bandwidth is a single fixed value (usually simply the link
 >>      capacity), Maximum LSP Bandwidth is carried per priority,
 >>      and may vary as LSPs are set up and torn down."
 >>    Specifically, how does a completely available OC-48 interface
 >>    with VC-11 over VC-3, VC-3, and VC-4 get encoded?  Based on
 >>    the first paragraph, the encoding would be MinLSPBW=1.5M, and
 >>    MaxLSPBW[p]=155M.  Ignoring the issue that VC-11 over VC-4
 >>    ends up being shown as supported, the second paragraph states
 >>    that the MaxLSPBW[p] should be 2.5G.
 >>
 >>    Knowing the OC-48 is completely available is useful information,
 >>    as multiple VC-4s could be used in an LCAS group to support
 >>    connections that need data rates over 155M*.
 >>
 >
 > It is not the intent of this document to support all possible info
 > about a link, but to support a useful *and* scalable subset.  We will
 > be guided by implementation and deployment experience to add
 > selectively to the information.  Note that the Max Reservable bandwidth
 > field remains, and in the case that the link is not a bundle, will be
 > set to ~2.5G.
 >

But it must be the intent of the document to be non contradictory.

It also seems to me to be unlikely that multiplexing structure can be 
encoded in two parameters. The actual tribs available on an OC-48 
interface depend strongly on the hardware provided, as well as on the 
agreement with whoever owns the far end. (In general, this is not the 
distant client)

 >
 >> - The mechanism does not support describing common muli-layer
 >>   relationships such as IP over DS1 over VC-11 or IP over DS3
 >>   over VC-3*.
 >>
 >
 > It is also not the intent of this document to provide a full description
 > of routing info for SDH.  This is a *general* document.  The intent is
 > to provide a code point for SDH to be expanded by another document.  This
 > was the model used for signaling as well: a *general* func spec, a
 > *general* doc for each protocol, and *SDH-specific* docs.  There is an
 > SDH specific routing doc; detailed comments are better directed there.
 >
 >
 >> - Sometimes layer relationships are described in an "inverted"
 >>   manner*. Section 5.1 of draft-ietf-ccamp-gmpls-routing-05.txt
 >>   states:
 >>     "STM-16 POS Interface on a LSR
 >>
 >>          Interface Switching Capability Descriptor:
 >>             Interface Switching Capability = PSC-1
 >>             Encoding = SDH
 >>             Max LSP Bandwidth[p] = 2.5 Gbps, for all p"
 >>
 >>   Where PSC-1 is the client of an SDH (sic) server.
 >>
 >>   Section 5.5 states:
 >>      "Interface of an opaque OXC (SDH framed) with support for
 >>       one lambda per port/interface"
 >>
 >>      "   Interface Switching Capability Descriptor:
 >>             Interface Switching Capability = LSC
 >>             Encoding = SDH"
 >>
 >>   In this case, SDH is a client of a wavelength server (LSC).
 >>   However, unlike in section 5.1, the layer relationship is
 >>   inverted.
 >>
 >
 > Is this pointed out as a curiosity, or is there a question that needs
 > to be addressed?
 >

The question that needs addressing is that layering is NOT a technology
specific concept. The fact that different technologies seem to have
different descriptions for the same concept suggests that the concept is
perhaps not understood. This is not good for a purportedly generic document.

 >
 >>3. Layer specific attributes are not supported*.  Specifically:
 >>
 >
 > Good points.  Please raise this with the SDH routing doc.
 >

The points that follow are generic. So I can understand that while
specific values are perhaps left to technology specific documents, the
concept must be covered by the framework.

 >
 >>4. The "TDM" Interface Switching Capability presumably includes
 >>   layers other than SONET/SDH, such as PDH* (DS1, DS3, E1, E3) and
 >>   G.709.  The interaction with these layers needs to be defined.
 >>
 >
 > Ditto.

Ditto

Delivery-date: Mon, 03 Mar 2003 11:25:10 -0800
Date: Mon, 03 Mar 2003 12:24:00 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
CC: Loa Andersson <[email-masked]>, "Varma, Eve L (Eve)" <[email-masked]>, George Newsome <[email-masked]>, [email-masked], ccamp <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Curtis,
I think you are missing my point.

IETF has one set of requirements for the kinds of networks that they
envision and are within their charter. They develop an architecture and
protocol solutions to support those requirements.
ITU-T has an (overlapping but different) set of requirements for the
kinds of networks they envision (including lots of TDM & WDM traffic
that doesn't necessarily carry IP, etc.).
Nobody says that the additional ITU-T requirements are valid for
the IETF application, or that IETF must solve the ITU-T requirements
with IETF developed protocols (they can choose to, but there is no obligation).

When the ITU-T brings these requirements to the IETF's attention, there
are a variety of perfectly reasonable responses:
- The IETF can say "That requirement is important for us also, let's work
  toward a common solution".
- The IETF can say "That requirement is not important for the IETF scope
  of work, but we can see how it is important for yours. From our
  experience with the protocol and our desire for sanity in the protocol
  and all of its extensions, we can offer you the following advice about
  how the protocol can best solve your problem ..."
- The IETF can say "That requirement is not important for the IETF scope
  of work and we are not particularly interested in helping with a solution -
  you are on your own, but please assign any protocol codepoints through
  IANA and document your extensions as an info RFC so that we can prevent
  any conflict with other extensions.
They could EVEN say "We think you might have misunderstood the requirements:
do you think that the following restatement of the problem would allow your
needs to be met with the current protocols: ..."

But the answer that I would have trouble with would be the IETF saying "That
requirement is not important for the IETF scope of work, and therefore no
solution should be developed for your problem AT ALL. After all, if it is not
important for IETF, it must be irrelevant for everybody."

Of course, without a liaison process, I don't know how we get any of these
responses. Incoming liaisons seem to hit the dustbin before they get serious
consideration regarding which of the above response types might be most
appropriate.
Regards,
Steve

Curtis Villamizar wrote:
> 
> In message <[email-masked]>, Stephen Trowbridge writes:
> > Loa,
> > (snip)
> > > I don't discus liasions, simply because it
> > > was and is
> > > my opinion that they are not in the picture then it comes to handling
> > > changes to the
> > > (g)mpls protocols.
> > So, if another SDO thinks that an IETF protocol (possibly with extensions)
> > would be a good solution to their problem, they would ask for this how?
> > Regards,
> > Steve
> 
> Steve,
> 
> They would bring the topic up on the appropriate WG mailing list and
> submit an internet-draft.
> 
> Your prior example of ASON is analogous IETF creating document that
> change the underlying SONET model and creating extensions to SONET
> outside of ITU (for example: using the loosely defined or undefined
> portion of the SONET overhead) specificly to support IP and then
> claiming that it was for IP so ITU should just accept it without
> questioning it.  There is no reason for the IETF to accept ASON as a
> requirement for MPLS/GMPLS.
> 
> Curtis

Delivery-date: Mon, 03 Mar 2003 10:46:15 -0800
From: "Stephen Shew" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, Jonathan Sadler <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS  vto  Proposed Standard
Date: Mon, 3 Mar 2003 13:40:34 -0500 

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_01C2E1B4.5F90F5F6
Content-Type: text/plain

I don't know if the pun was intended, but I do like Kireeti's comment about
"bring them to light".  Undoubtedly, this would be within the ITU-T
(wavelength) grid! ;-)

There is, I think, some commonality in the comments and the reply in that
the intent is to generalize the extensions needed for routing to accomodate
non-PSC resources.  I agree with the first 4 points that Jonathan made in
that I think layer information must be included in routing so that important
functions can be performed.  I believe that the use of one or two bandwidth
values was motivated by the desire to use a "lowest common denominator"
attribute to generalize on path computation and avoid extensive details of
links.  Unfortunately, this can obscure variable adaptation on a link and
the ability to determine a path at a particular adaptation (e.g., VC-3).

In variable adaptation, multiple layers can be supported on a link (actually
a G.805 trail) as mentioned in the 2nd point.  When a label (channel) is
used at a particular layer, it has the effect of modifying the available
labels in other layers supported on the same link.  It is important to thus
be able to reflect the layer relationship in routing.

For the issue of path computation at a particular layer, while bandwidth can
give a superset of possible paths, what is needed in many contexts is a path
at a specific adaptation.  Because different combinations of adaptations can
provide the same b/w, the result is that it infeasible paths can be computed
because there is no distinction between what type of adaptation can be
supported.  There are times when for example, you want to have a VC-3
connection end-to-end and not just an LSP with its equivalent bandwidth
because the service that was sold was specifically a VC-3.

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]] 
Sent: Saturday, March 01, 2003 14:29
To: Jonathan Sadler
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS
vto Proposed Standard

Hi Jonathan,

On Sun, 23 Feb 2003, Jonathan Sadler wrote:

> Please consider the following comments on these drafts:
>     draft-ietf-ccamp-gmpls-routing-05.txt
>     draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
> Many of the comments are based on implementation experience.  These 
> comments are marked with a (*).

Thanks for your comments.  Most of these would have more appropriate to
raise in the WG Last Call, but it is certainly better to bring them to light
now than never.

> ==========
>
> 1. In section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt, the 
> operations for Packet Switch Capable (PSC) are defined.  Reference is 
> made to Minimum LSP bandwidth for SDH encoding.  None of the examples 
> in section 5 of draft-ietf-ccamp-gmpls-routing-05.txt show how this 
> field should filled.

Note that all possible permutations cannot possibly be addressed; however,
we will consider adding some examples here.

> 2. The mechanism for showing relationships between server and client 
> layers is not generalized*.  Specifically:
>   - Relationships between SONET/SDH layers (ISC type: TDM) are
>     implicitly stated based on the Min and Max LSP bandwidth
>     advertised*.  To quote draft-ietf-ccamp-gmpls-routing-05.txt:
>
>      "On an interface having Standard SDH multiplexing, an LSP
>       at priority p could reserve any bandwidth allowed by the
>       branch of the SDH hierarchy, with the leaf and the root
>       of the branch being defined by the Minimum LSP Bandwidth
>       and the Maximum LSP Bandwidth at priority p."
>
>     This requires node doing the route calculation to understand
>     the G.707 multiplexing hierarchy.  Since LSP routing is source
>     routed, it could be the node doing the route calculation
>     doesn't understand G.707.

This document does *not* cover how path computation is done.  Of course, the
information is less than useful if it cannot be used effectively.  However,
it has been pointed out implicitly and explicitly in several documents that
the head end does *not* have to do the entire route computation -- this is
one reason why there are loose hops in the ERO.  See also the various drafts
on multi-area TE computation.

>   - Relationships between PSC-n (for IP switching) and SONET/SDH are
>     explicitly specified on the encoding type specified in the PSC-n
>     announcement*.  However, SONET/SDH is not a single layer.  It
>     must be possible to identify if the PSC-n layer can be carried
>     by a VC-11 trail, a VC-12 trail, a VC-3 trail, a VC-4 trail,
>     or a VC-4-nc trail.
>
>     Section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt tries
>     to deal with this in the following paragraph:
>
>      "On a PSC interface that supports Standard SDH encoding, an
>       LSP at priority p could reserve any bandwidth allowed by
>       the branch of the SDH hierarchy, with the leaf and the root
>       of the branch being defined by the Minimum LSP Bandwidth
>       and the Maximum LSP Bandwidth at priority p."
>
>     The problem is this contradicts the following paragraph:
>
>      "The Maximum LSP Bandwidth takes the place of the Maximum
>       Bandwidth ([ISIS-TE], [OSPF-TE]). However, while Maximum
>       Bandwidth is a single fixed value (usually simply the link
>       capacity), Maximum LSP Bandwidth is carried per priority,
>       and may vary as LSPs are set up and torn down."
>     Specifically, how does a completely available OC-48 interface
>     with VC-11 over VC-3, VC-3, and VC-4 get encoded?  Based on
>     the first paragraph, the encoding would be MinLSPBW=1.5M, and
>     MaxLSPBW[p]=155M.  Ignoring the issue that VC-11 over VC-4
>     ends up being shown as supported, the second paragraph states
>     that the MaxLSPBW[p] should be 2.5G.
>
>     Knowing the OC-48 is completely available is useful information,
>     as multiple VC-4s could be used in an LCAS group to support
>     connections that need data rates over 155M*.

It is not the intent of this document to support all possible info about a
link, but to support a useful *and* scalable subset.  We will be guided by
implementation and deployment experience to add selectively to the
information.  Note that the Max Reservable bandwidth field remains, and in
the case that the link is not a bundle, will be set to ~2.5G.

>  - The mechanism does not support describing common muli-layer
>    relationships such as IP over DS1 over VC-11 or IP over DS3
>    over VC-3*.

It is also not the intent of this document to provide a full description of
routing info for SDH.  This is a *general* document.  The intent is to
provide a code point for SDH to be expanded by another document.  This was
the model used for signaling as well: a *general* func spec, a
*general* doc for each protocol, and *SDH-specific* docs.  There is an SDH
specific routing doc; detailed comments are better directed there.

>  - Sometimes layer relationships are described in an "inverted"
>    manner*. Section 5.1 of draft-ietf-ccamp-gmpls-routing-05.txt
>    states:
>      "STM-16 POS Interface on a LSR
>
>           Interface Switching Capability Descriptor:
>              Interface Switching Capability = PSC-1
>              Encoding = SDH
>              Max LSP Bandwidth[p] = 2.5 Gbps, for all p"
>
>    Where PSC-1 is the client of an SDH (sic) server.
>
>    Section 5.5 states:
>       "Interface of an opaque OXC (SDH framed) with support for
>        one lambda per port/interface"
>
>       "   Interface Switching Capability Descriptor:
>              Interface Switching Capability = LSC
>              Encoding = SDH"
>
>    In this case, SDH is a client of a wavelength server (LSC).
>    However, unlike in section 5.1, the layer relationship is
>    inverted.

Is this pointed out as a curiosity, or is there a question that needs to be
addressed?

> 3. Layer specific attributes are not supported*.  Specifically:

Good points.  Please raise this with the SDH routing doc.

> 4. The "TDM" Interface Switching Capability presumably includes
>    layers other than SONET/SDH, such as PDH* (DS1, DS3, E1, E3) and
>    G.709.  The interaction with these layers needs to be defined.

Ditto.

> 5. In many cases, 8 levels of priority are not necessary*.  A more
>    compact encoding that has a bitfield stating the priority levels
>    being announced would reduce the size of the announcement.

This has been discussed elsewhere.  This is the model in the base TE
document; it has proven reasonable in practice.  If deployment proves
otherwise, this is easy to fix.  For now, though, I would leave it as is.

Thanks again for your comments,
Kireeti.

------_=_NextPart_001_01C2E1B4.5F90F5F6
Content-Type: text/html
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 =
5.5.2656.31">
<TITLE>RE: Last Call: Routing Extensions in Support of Generalized MPLS =
 vto  Proposed Standard</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I don't know if the pun was intended, but I do like =
Kireeti's comment about &quot;bring them to light&quot;.&nbsp; =
Undoubtedly, this would be within the ITU-T (wavelength) grid! =
;-)</FONT></P>

<P><FONT SIZE=3D2>There is, I think, some commonality in the comments =
and the reply in that the intent is to generalize the extensions needed =
for routing to accomodate non-PSC resources.&nbsp; I agree with the =
first 4 points that Jonathan made in that I think layer information =
must be included in routing so that important functions can be =
performed.&nbsp; I believe that the use of one or two bandwidth values =
was motivated by the desire to use a &quot;lowest common =
denominator&quot; attribute to generalize on path computation and avoid =
extensive details of links.&nbsp; Unfortunately, this can obscure =
variable adaptation on a link and the ability to determine a path at a =
particular adaptation (e.g., VC-3).</FONT></P>

<P><FONT SIZE=3D2>In variable adaptation, multiple layers can be =
supported on a link (actually a G.805 trail) as mentioned in the 2nd =
point.&nbsp; When a label (channel) is used at a particular layer, it =
has the effect of modifying the available labels in other layers =
supported on the same link.&nbsp; It is important to thus be able to =
reflect the layer relationship in routing.</FONT></P>

<P><FONT SIZE=3D2>For the issue of path computation at a particular =
layer, while bandwidth can give a superset of possible paths, what is =
needed in many contexts is a path at a specific adaptation.&nbsp; =
Because different combinations of adaptations can provide the same b/w, =
the result is that it infeasible paths can be computed because there is =
no distinction between what type of adaptation can be supported.&nbsp; =
There are times when for example, you want to have a VC-3 connection =
end-to-end and not just an LSP with its equivalent bandwidth because =
the service that was sold was specifically a VC-3.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kireeti Kompella [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Saturday, March 01, 2003 14:29</FONT>
<BR><FONT SIZE=3D2>To: Jonathan Sadler</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Last Call: Routing Extensions in =
Support of Generalized MPLS vto Proposed Standard</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Jonathan,</FONT>
</P>

<P><FONT SIZE=3D2>On Sun, 23 Feb 2003, Jonathan Sadler wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Please consider the following comments on these =
drafts:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-ccamp-gmpls-routing-05.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-ietf-ccamp-ospf-gmpls-extensions-09.txt</FONT>
<BR><FONT SIZE=3D2>&gt; Many of the comments are based on =
implementation experience.&nbsp; These </FONT>
<BR><FONT SIZE=3D2>&gt; comments are marked with a (*).</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for your comments.&nbsp; Most of these would =
have more appropriate to raise in the WG Last Call, but it is certainly =
better to bring them to light now than never.</FONT></P>

<P><FONT SIZE=3D2>&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; 1. In section 4.4.2 of =
draft-ietf-ccamp-gmpls-routing-05.txt, the </FONT>
<BR><FONT SIZE=3D2>&gt; operations for Packet Switch Capable (PSC) are =
defined.&nbsp; Reference is </FONT>
<BR><FONT SIZE=3D2>&gt; made to Minimum LSP bandwidth for SDH encoding.&=
nbsp; None of the examples </FONT>
<BR><FONT SIZE=3D2>&gt; in section 5 of =
draft-ietf-ccamp-gmpls-routing-05.txt show how this </FONT>
<BR><FONT SIZE=3D2>&gt; field should filled.</FONT>
</P>

<P><FONT SIZE=3D2>Note that all possible permutations cannot possibly =
be addressed; however, we will consider adding some examples =
here.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; 2. The mechanism for showing relationships =
between server and client </FONT>
<BR><FONT SIZE=3D2>&gt; layers is not generalized*.&nbsp; =
Specifically:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - Relationships between SONET/SDH =
layers (ISC type: TDM) are</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; implicitly stated based =
on the Min and Max LSP bandwidth</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; advertised*.&nbsp; To =
quote draft-ietf-ccamp-gmpls-routing-05.txt:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;On an =
interface having Standard SDH multiplexing, an LSP</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; at priority =
p could reserve any bandwidth allowed by the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; branch of =
the SDH hierarchy, with the leaf and the root</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the =
branch being defined by the Minimum LSP Bandwidth</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and the =
Maximum LSP Bandwidth at priority p.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This requires node =
doing the route calculation to understand</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; the G.707 multiplexing =
hierarchy.&nbsp; Since LSP routing is source</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; routed, it could be the =
node doing the route calculation</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; doesn't understand =
G.707.</FONT>
</P>

<P><FONT SIZE=3D2>This document does *not* cover how path computation =
is done.&nbsp; Of course, the information is less than useful if it =
cannot be used effectively.&nbsp; However, it has been pointed out =
implicitly and explicitly in several documents that the head end does =
*not* have to do the entire route computation -- this is one reason why =
there are loose hops in the ERO.&nbsp; See also the various drafts on =
multi-area TE computation.</FONT></P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - Relationships between PSC-n (for =
IP switching) and SONET/SDH are</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; explicitly specified on =
the encoding type specified in the PSC-n</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; announcement*.&nbsp; =
However, SONET/SDH is not a single layer.&nbsp; It</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; must be possible to =
identify if the PSC-n layer can be carried</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; by a VC-11 trail, a =
VC-12 trail, a VC-3 trail, a VC-4 trail,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; or a VC-4-nc =
trail.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Section 4.4.2 of =
draft-ietf-ccamp-gmpls-routing-05.txt tries</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; to deal with this in =
the following paragraph:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;On a PSC =
interface that supports Standard SDH encoding, an</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LSP at =
priority p could reserve any bandwidth allowed by</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the branch =
of the SDH hierarchy, with the leaf and the root</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the =
branch being defined by the Minimum LSP Bandwidth</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and the =
Maximum LSP Bandwidth at priority p.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The problem is this =
contradicts the following paragraph:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The Maximum =
LSP Bandwidth takes the place of the Maximum</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bandwidth =
([ISIS-TE], [OSPF-TE]). However, while Maximum</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bandwidth =
is a single fixed value (usually simply the link</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; capacity), =
Maximum LSP Bandwidth is carried per priority,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and may =
vary as LSPs are set up and torn down.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Specifically, how does =
a completely available OC-48 interface</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; with VC-11 over VC-3, =
VC-3, and VC-4 get encoded?&nbsp; Based on</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; the first paragraph, =
the encoding would be MinLSPBW=3D1.5M, and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; =
MaxLSPBW[p]=3D155M.&nbsp; Ignoring the issue that VC-11 over =
VC-4</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; ends up being shown as =
supported, the second paragraph states</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; that the MaxLSPBW[p] =
should be 2.5G.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Knowing the OC-48 is =
completely available is useful information,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; as multiple VC-4s could =
be used in an LCAS group to support</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; connections that need =
data rates over 155M*.</FONT>
</P>

<P><FONT SIZE=3D2>It is not the intent of this document to support all =
possible info about a link, but to support a useful *and* scalable =
subset.&nbsp; We will be guided by implementation and deployment =
experience to add selectively to the information.&nbsp; Note that the =
Max Reservable bandwidth field remains, and in the case that the link =
is not a bundle, will be set to ~2.5G.</FONT></P>

<P><FONT SIZE=3D2>&gt;&nbsp; - The mechanism does not support =
describing common muli-layer</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; relationships such as IP over =
DS1 over VC-11 or IP over DS3</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; over VC-3*.</FONT>
</P>

<P><FONT SIZE=3D2>It is also not the intent of this document to provide =
a full description of routing info for SDH.&nbsp; This is a *general* =
document.&nbsp; The intent is to provide a code point for SDH to be =
expanded by another document.&nbsp; This was the model used for =
signaling as well: a *general* func spec, a</FONT></P>

<P><FONT SIZE=3D2>*general* doc for each protocol, and *SDH-specific* =
docs.&nbsp; There is an SDH specific routing doc; detailed comments are =
better directed there.</FONT></P>

<P><FONT SIZE=3D2>&gt;&nbsp; - Sometimes layer relationships are =
described in an &quot;inverted&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; manner*. Section 5.1 of =
draft-ietf-ccamp-gmpls-routing-05.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; states:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;STM-16 POS =
Interface on a LSR</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Interface Switching Capability Descriptor:</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; Interface Switching Capability =3D PSC-1</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; Encoding =3D SDH</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; Max LSP Bandwidth[p] =3D 2.5 Gbps, for all =
p&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Where PSC-1 is the client of =
an SDH (sic) server.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Section 5.5 states:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;Interface of an opaque OXC (SDH framed) with support for</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; one =
lambda per port/interface&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;&nbsp;&nbsp; Interface Switching Capability Descriptor:</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; Interface Switching Capability =3D LSC</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; Encoding =3D SDH&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; In this case, SDH is a client =
of a wavelength server (LSC).</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; However, unlike in section =
5.1, the layer relationship is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; inverted.</FONT>
</P>

<P><FONT SIZE=3D2>Is this pointed out as a curiosity, or is there a =
question that needs to be addressed?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; 3. Layer specific attributes are not =
supported*.&nbsp; Specifically:</FONT>
</P>

<P><FONT SIZE=3D2>Good points.&nbsp; Please raise this with the SDH =
routing doc.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; 4. The &quot;TDM&quot; Interface Switching =
Capability presumably includes</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; layers other than SONET/SDH, =
such as PDH* (DS1, DS3, E1, E3) and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; G.709.&nbsp; The interaction =
with these layers needs to be defined.</FONT>
</P>

<P><FONT SIZE=3D2>Ditto.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; 5. In many cases, 8 levels of priority are not =
necessary*.&nbsp; A more</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; compact encoding that has a =
bitfield stating the priority levels</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; being announced would reduce =
the size of the announcement.</FONT>
</P>

<P><FONT SIZE=3D2>This has been discussed elsewhere.&nbsp; This is the =
model in the base TE document; it has proven reasonable in =
practice.&nbsp; If deployment proves otherwise, this is easy to =
fix.&nbsp; For now, though, I would leave it as is.</FONT></P>

<P><FONT SIZE=3D2>Thanks again for your comments,</FONT>
<BR><FONT SIZE=3D2>Kireeti.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2E1B4.5F90F5F6--

Delivery-date: Mon, 03 Mar 2003 09:51:50 -0800
Date: Mon, 03 Mar 2003 10:51:02 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Loa Andersson <[email-masked]>
CC: [email-masked], ccamp <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Loa,
Can you give me some examples of things you consider to be solutions
being proposed (by individuals) for undocumented or poorly understood
problems? I admit to following mpls only peripherally, but in ccamp
it seems like the bulk of proposals (if not ALL of the proposals)
originate from attempts to solve problems raised by other SDOs.
If I could see examples of this sort for mpls, I perhaps could
understand better why this kind of change control procedure would
be necessary.

Here is the sense in which the evaluation of the requirement must take
into consideration the source:
Evaluation of a requirement by an IETF WG (or any other body to which
a requirement is proposed) is a subjective process. The IETF WG will
interpret the requirement in the context of their charter and the kinds
of networks and technologies they are most familiar with.

Another SDO may come up with requirements related to THEIR charter and
the kinds of networks and technologies they are familiar with. These
requirements may be exceedingly critical within the application domain
for the other SDO, but may seem irrelevant or unimportant for the
application domain of the IETF WG.

So an IETF WG which is trying to maintain sanity over a protocol that
is applied by different SDOs to different application spaces DOES need
to consider requirements from different SDOs in a different way from
internal requirements. When evaluating an internal requirement, people
should understand why that requirement is important in the context of
the charter of the IETF WG. When evaluating a requirement, for example,
from ITU-T, the question should be, not why this is an important
requirement within the context of the WG charter, but to understand
why (or accept that) it is an important requirement for ITU-T and
their application space.

Regards,
Steve

Loa Andersson wrote:
> 
> Steve,
> 
> you are right that the liasion process are a problem - if anyone thinks
> it will
> do any good (AD's nod or shake your heads) I'm of course willing to help
> sort that
> out. And it might be that we can make Sub-IP a pilot (again nods or
> shakes from
> AD's). My tentative view is that this should be done as part of the
> problem statement
> work.
> 
> BUT - it is far from the only problem, in fact the very draft that we
> ougth to be
> discussing here was written with the liasion process very low on the
> horizion, it
> was definitely not triggered by getting liasion carried requirments form
> other SDOs,
> but it was triggered because, we seen more and more solutions coming in for
> undocumented or poorly understood problems. We have an increasing
> concern over the
> (g)mpls coherence and architecture in relation to these "solutions".
> 
> For the moment I'm not aware of any mpls related liasions hanging
> un-answered, there
> are a set of them for ccamp, but Kireeti and Bert, have acknowledged
> that, and I
> sincerly hope they won't try to use the change process to answer those
> liasions,
> the process was not designed to do that.
> 
> There is something in this discussion that makes me think that there is
> a drive for
> trying to take the origin of an requirement and make that an criterium
> when evaluating
> the requirment. Kind of giving a group requirment precedence over an
> individula
> requirment. I sincerly object to this, since I think ti is the technical
> merit
> that is the evaluation point.
> 
> /Loa
> 
> Stephen Trowbridge wrote:
> 
> >All,
> >Lets try to zero in on what the problem really is.
> >
> >I think that liaison handling (or the lack thereof) is not just a
> >problem. It is THE problem. Does anybody really believe that the
> >reason this draft exists in the first place is that there are a
> >bunch of individuals going wild trying to change or extend the
> >(G)MPLS protocols?
> >
> >What seems to have generated most of the arguments is the handling
> >(or bungling) of the communications process (or lack of process)
> >with other SDOs. This is the process we need to fix.
> >Dealing with requests from individuals to extend or change the
> >protocols might be good to have a process for, but realistically,
> >has any individual made such a request yet? Why is this important?
> >
> >Now, if we can agree that liaisons are THE problem,
> >there are two ways we can go:
> >- We can start work on a general purpose liaison process to be
> >applied across the whole of IETF (revival of one of the POIS*
> >working groups?).
> >- We could try to develop a pilot process for sub-IP (which is
> >where we seem to have a lot of the problems), and take what we
> >learn from its implementation to feed into a process that would
> >apply to the whole of IETF.
> >
> >While I can appreciate that a general problem should usually have
> >a general solution, there is some appeal to taking the second
> >approach because (1) we could probably get something underway
> >faster; and (2) sub-IP seems to be where the lack of such a
> >process is causing us the most pain.
> >Regards,
> >Steve
> >
> >George Swallow wrote:
> >
> >
> >>>In message <[email-masked]>, Loa Andersson writes:
> >>>
> >>>
> >>>>- I don't think it is agood idea to describe the two process in the same
> >>>>  document. the chnage-process is for our internal use, the liasion process
> >>>>  is for our commuinication with other SDOs
> >>>>
> >>>>
> >>>If we can agree on this, then we can move forward with your document.
> >>>
> >>>
> >>I think they need to be separate because the liaison draft should
> >>apply across the board to IETF / ITU interactions and this document
> >>applies only to (G)MPLS.
> >>
> >>...George
> >>
> >>==================================================================
> >>George Swallow       Cisco Systems                  (978) 497-8143
> >>                     250 Apollo Drive
> >>                     Chelmsford, Ma 01824
> >>
> >>
> >
> >
> >
> >

Delivery-date: Mon, 03 Mar 2003 09:11:47 -0800
Date: Mon, 03 Mar 2003 10:10:45 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Scott Bradner <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Scott,
There is no doubt that liaisons CURRENTLY have no more wieght than
individual IDs (perhaps even less - by the Bala flowchart, the fact
that an idea arrives via liaion may even work to the detriment of
a proposal (yes Loa, I know this is a joke!)).
But it is my opinion that the lack of a liaison process is really
the ROOT CAUSE of difficulties like what we saw in January.

There are some on this thread who seem to feel that the root cause
of the problem is that ITU-T is permitted to use or apply the IETF
protocol to their problem at all.

But I daresay that if we had had a good back-and-forth discussion
between the groups (with liaisons not only being considered seriously,
but responded to), that people would have understood far better what
the ITU-T was trying to do, and that there would not have been the
last minute arguments about whether ITU-T should be able to do it.

I have remarked on this before: some of our members (in ITU-T) are
interested in using the PNNI protcol to implement ASON instead of
the GMPLS protocols. The PNNI protocol also required extensions - it
did not meet the ASON requirements as-is.

I think that the primary reason that the job was so much easier with
PNNI and the ATM forum is not so much that PNNI is any better suited
to solving the problem, but that ATM forum took the liaison statements
seriously. They tried to understand the ITU-T problem and actively
tried to help solve it in the best way with their protocol.

If IETF ccamp had done the same (all the way back to Oct. 2001), the
arguments of January would never have happened.
Regards,
Steve

Scott Bradner wrote:
> 
> Steve,
>         Note that Loa is correct as to the impact of liasions, I-Ds
> or presentations by folk representing otehr SDOs within the IETF
> standards process - they carry just as much weight as the statemnts
> of any individual and there is currently no reason to have them
> treated as having some special status in the change-process ID.
> (see RFC 3356 sec 3.2.2 & RFC 2418 sec 1))  That said, I do think it would be
> good to mention that the use of liasion statements is common in other
> SDOs and that such statements should be not ignored when directed to
> IETF working groups.
> 
>         There are strong arguments that maybe the current assumptions
> should change butthis mailing list is not the place to discuss it - I
> would suggest that this dicussion be redirected to the problem-statement
> mailing list.
> 
> Scott

Delivery-date: Mon, 03 Mar 2003 09:11:41 -0800
Date: Mon, 3 Mar 2003 12:11:01 -0500
From: Scott W Brim <[email-masked]>
To: Scott Bradner <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Mail-Followup-To: Scott W Brim <[email-masked]>, Scott Bradner <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

On Mon, Mar 03, 2003 11:48:58AM -0500, Scott Bradner allegedly wrote:
> 	There are strong arguments that maybe the current assumptions
> should change butthis mailing list is not the place to discuss it - I 
> would suggest that this dicussion be redirected to the problem-statement 
> mailing list.

Or a new one (I hope).  Problem-statement deserves not to be de-focused.

Delivery-date: Mon, 03 Mar 2003 09:01:08 -0800
content-class: urn:content-classes:message
Subject: RE: liaisons
Date: Mon, 3 Mar 2003 11:59:54 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Stephen Trowbridge" <[email-masked]>, "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>, "Varma, Eve L (Eve)" <[email-masked]>, "George Newsome" <[email-masked]>, <[email-masked]>, "ccamp" <[email-masked]>

I changed the email thread as Loa, Scott, etc have clarified this draft =
was not intended as a liaison process. (and again, before I can finish =
typing, I see Scott has sent an email requesting the use of the problem =
statement list, this will be my last here)

I thought Loa (or someone) clarified - another SDO has two choices: =
(1)choose to go IETF standards track or (2) non-standards track =
(informational, experimental).

If the choice is standards track, they can initiate contact via a =
liaison.

The IETF Liaison process will provide guidelines on =
receiving/distribution/sending. And processing of the content. Depending =
on the request, varies actions may be appropriate, and can be clarified =
in the liaison process.

Deborah

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Monday, March 03, 2003 11:30 AM
To: Loa Andersson
Cc: [email-masked]; Varma, Eve L (Eve); George Newsome;
[email-masked]; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Loa,
(snip)
> I don't discus liasions, simply because it
> was and is
> my opinion that they are not in the picture then it comes to handling
> changes to the
> (g)mpls protocols.
So, if another SDO thinks that an IETF protocol (possibly with =
extensions)
would be a good solution to their problem, they would ask for this how?
Regards,
Steve

Envelope-to: [email-masked]
Delivery-date: Mon, 03 Mar 2003 08:50:06 -0800
Date: Mon, 3 Mar 2003 11:48:58 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Steve,
	Note that Loa is correct as to the impact of liasions, I-Ds
or presentations by folk representing otehr SDOs within the IETF
standards process - they carry just as much weight as the statemnts
of any individual and there is currently no reason to have them
treated as having some special status in the change-process ID.
(see RFC 3356 sec 3.2.2 & RFC 2418 sec 1))  That said, I do think it would be 
good to mention that the use of liasion statements is common in other
SDOs and that such statements should be not ignored when directed to
IETF working groups.

	There are strong arguments that maybe the current assumptions
should change butthis mailing list is not the place to discuss it - I 
would suggest that this dicussion be redirected to the problem-statement 
mailing list.

Scott

Delivery-date: Mon, 03 Mar 2003 08:49:30 -0800
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Brungard, Deborah A, ALABS'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, George Swallow <[email-masked]>
Cc: [email-masked], Loa Andersson <[email-masked]>, [email-masked], ccamp <[email-masked]>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Mon, 3 Mar 2003 11:48:42 -0500 

Hi all,

I'm still puzzled regarding how the separation of the liaison
process helps us solve the problem that I thought had
triggered this draft being generated.

I haven't seen any response yet to Steve's email below.

Best regards,
Eve

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Monday, March 03, 2003 9:56 AM
To: George Swallow
Cc: [email-masked]; Loa Andersson; [email-masked]; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

All,
Lets try to zero in on what the problem really is.

I think that liaison handling (or the lack thereof) is not just a
problem. It is THE problem. Does anybody really believe that the
reason this draft exists in the first place is that there are a
bunch of individuals going wild trying to change or extend the
(G)MPLS protocols?

What seems to have generated most of the arguments is the handling
(or bungling) of the communications process (or lack of process)
with other SDOs. This is the process we need to fix.
Dealing with requests from individuals to extend or change the
protocols might be good to have a process for, but realistically,
has any individual made such a request yet? Why is this important?

Now, if we can agree that liaisons are THE problem,
there are two ways we can go:
- We can start work on a general purpose liaison process to be
applied across the whole of IETF (revival of one of the POIS*
working groups?).
- We could try to develop a pilot process for sub-IP (which is
where we seem to have a lot of the problems), and take what we
learn from its implementation to feed into a process that would
apply to the whole of IETF.

While I can appreciate that a general problem should usually have
a general solution, there is some appeal to taking the second
approach because (1) we could probably get something underway
faster; and (2) sub-IP seems to be where the lack of such a
process is causing us the most pain.
Regards,
Steve

George Swallow wrote:
> 
> > In message <[email-masked]>, Loa Andersson writes:
> > >
> > > - I don't think it is agood idea to describe the two process in the same
> > >   document. the chnage-process is for our internal use, the liasion process
> > >   is for our commuinication with other SDOs
> >
> > If we can agree on this, then we can move forward with your document.
> 
> I think they need to be separate because the liaison draft should
> apply across the board to IETF / ITU interactions and this document
> applies only to (G)MPLS.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Monday, March 03, 2003 11:35 AM
To: Stephen Trowbridge; George Swallow
Cc: [email-masked]; Loa Andersson; [email-masked]; ccamp
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

I think we have agreement to do a separate document on the liaison process? (as I'm writing, I see a mail just now from Scott saying this). Loa, not sure if you were volunteering the g-chng proc authors? They are probably the most appropriate. If you need support (either visible/ghosts), Steve (ok, Steve?) can help from the ITU perspective, I can help from the T1X1 side.

Steve, I agree for SDOs, the key problem is the lack of a liaison process. Regardless, for IETF, a change process is needed. The GMPLS work is just going to rfc status and there will be both individual and SDO requests for additions/changes. For the liaison process, I think we need to distinguish the communication protocol (administrative=receive/distribution/transmit) from the processing (administrative and technical) of the liaison request. Both need to be clarified.

Considering we agree to have a separate document for a liaison process, and applying a constructive filter to the mail exchange, Lyndon's mail and my mail have direct comments on the draft, any others?

As I noted previously, to distinguish this process from the liaison process, should either remove external standards bodies from the text or clarify "individuals of external standards bodies".

Agree with Lyndon, "dustbin" should be defined for non-ietf aware, i.e. a note describing the option as non-standards track=informational or experimental rfc.

As Lyndon says, resources in all the standards groups are extremely limited, it's in the industry and our companies interests to collaborate. Let's use this week for specific comments on the draft.

Deborah

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Monday, March 03, 2003 9:56 AM
To: George Swallow
Cc: [email-masked]; Loa Andersson; [email-masked]; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

All,
Lets try to zero in on what the problem really is.

I think that liaison handling (or the lack thereof) is not just a
problem. It is THE problem. Does anybody really believe that the
reason this draft exists in the first place is that there are a
bunch of individuals going wild trying to change or extend the
(G)MPLS protocols?

What seems to have generated most of the arguments is the handling
(or bungling) of the communications process (or lack of process)
with other SDOs. This is the process we need to fix.
Dealing with requests from individuals to extend or change the
protocols might be good to have a process for, but realistically,
has any individual made such a request yet? Why is this important?

Now, if we can agree that liaisons are THE problem,
there are two ways we can go:
- We can start work on a general purpose liaison process to be
applied across the whole of IETF (revival of one of the POIS*
working groups?).
- We could try to develop a pilot process for sub-IP (which is
where we seem to have a lot of the problems), and take what we
learn from its implementation to feed into a process that would
apply to the whole of IETF.

While I can appreciate that a general problem should usually have
a general solution, there is some appeal to taking the second
approach because (1) we could probably get something underway
faster; and (2) sub-IP seems to be where the lack of such a
process is causing us the most pain.
Regards,
Steve

George Swallow wrote:
> 
> > In message <[email-masked]>, Loa Andersson writes:
> > >
> > > - I don't think it is agood idea to describe the two process in the same
> > >   document. the chnage-process is for our internal use, the liasion process
> > >   is for our commuinication with other SDOs
> >
> > If we can agree on this, then we can move forward with your document.
> 
> I think they need to be separate because the liaison draft should
> apply across the board to IETF / ITU interactions and this document
> applies only to (G)MPLS.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824

Delivery-date: Mon, 03 Mar 2003 08:35:22 -0800
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Mon, 3 Mar 2003 11:34:51 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Stephen Trowbridge" <[email-masked]>, "George Swallow" <[email-masked]>
Cc: <[email-masked]>, "Loa Andersson" <[email-masked]>, <[email-masked]>, "ccamp" <[email-masked]>

I think we have agreement to do a separate document on the liaison =
process? (as I'm writing, I see a mail just now from Scott saying this). =
Loa, not sure if you were volunteering the g-chng proc authors? They are =
probably the most appropriate. If you need support (either =
visible/ghosts), Steve (ok, Steve?) can help from the ITU perspective, I =
can help from the T1X1 side.

Steve, I agree for SDOs, the key problem is the lack of a liaison =
process. Regardless, for IETF, a change process is needed. The GMPLS =
work is just going to rfc status and there will be both individual and =
SDO requests for additions/changes. For the liaison process, I think we =
need to distinguish the communication protocol =
(administrative=3Dreceive/distribution/transmit) from the processing =
(administrative and technical) of the liaison request. Both need to be =
clarified.

Considering we agree to have a separate document for a liaison process, =
and applying a constructive filter to the mail exchange, Lyndon's mail =
and my mail have direct comments on the draft, any others?

As I noted previously, to distinguish this process from the liaison =
process, should either remove external standards bodies from the text or =
clarify "individuals of external standards bodies".

Agree with Lyndon, "dustbin" should be defined for non-ietf aware, i.e. =
a note describing the option as non-standards track=3Dinformational or =
experimental rfc.

As Lyndon says, resources in all the standards groups are extremely =
limited, it's in the industry and our companies interests to =
collaborate. Let's use this week for specific comments on the draft.

Deborah

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Monday, March 03, 2003 9:56 AM
To: George Swallow
Cc: [email-masked]; Loa Andersson; [email-masked]; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

All,
Lets try to zero in on what the problem really is.

I think that liaison handling (or the lack thereof) is not just a
problem. It is THE problem. Does anybody really believe that the
reason this draft exists in the first place is that there are a
bunch of individuals going wild trying to change or extend the
(G)MPLS protocols?

What seems to have generated most of the arguments is the handling
(or bungling) of the communications process (or lack of process)
with other SDOs. This is the process we need to fix.
Dealing with requests from individuals to extend or change the
protocols might be good to have a process for, but realistically,
has any individual made such a request yet? Why is this important?

Now, if we can agree that liaisons are THE problem,
there are two ways we can go:
- We can start work on a general purpose liaison process to be
applied across the whole of IETF (revival of one of the POIS*
working groups?).
- We could try to develop a pilot process for sub-IP (which is
where we seem to have a lot of the problems), and take what we
learn from its implementation to feed into a process that would
apply to the whole of IETF.

While I can appreciate that a general problem should usually have
a general solution, there is some appeal to taking the second
approach because (1) we could probably get something underway
faster; and (2) sub-IP seems to be where the lack of such a
process is causing us the most pain.
Regards,
Steve

George Swallow wrote:
>=20
> > In message <[email-masked]>, Loa Andersson writes:
> > >
> > > - I don't think it is agood idea to describe the two process in =
the same
> > >   document. the chnage-process is for our internal use, the =
liasion process
> > >   is for our commuinication with other SDOs
> >
> > If we can agree on this, then we can move forward with your =
document.
>=20
> I think they need to be separate because the liaison draft should
> apply across the board to IETF / ITU interactions and this document
> applies only to (G)MPLS.
>=20
> ...George
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824

Delivery-date: Mon, 03 Mar 2003 08:31:09 -0800
Date: Mon, 03 Mar 2003 09:30:29 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Loa Andersson <[email-masked]>
CC: [email-masked], "Varma, Eve L (Eve)" <[email-masked]>, George Newsome <[email-masked]>, [email-masked], ccamp <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Loa,
(snip)
> I don't discus liasions, simply because it
> was and is
> my opinion that they are not in the picture then it comes to handling
> changes to the
> (g)mpls protocols.
So, if another SDO thinks that an IETF protocol (possibly with extensions)
would be a good solution to their problem, they would ask for this how?
Regards,
Steve

Delivery-date: Mon, 03 Mar 2003 08:03:48 -0800
Date: Mon, 03 Mar 2003 09:03:02 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Loa Andersson <[email-masked]>
CC: [email-masked], ccamp <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Loa,
(I know it is a joke, but if there weren't some element of truth
to this it would not be so funny).

Let me try to explain why the interface between an individual and
IETF, and an the interaction between another SDO and IETF have to
be different:

Differences on the incoming side:
- The ID brought in by an individual represents his/her individual
opinion.
- A liaison statement from another SDO represents an approved consensus
view from that other organization. I don't so much care whether it is
in ASCII or not, but it does represent a consensus view that cannot be
claimed of the individual ID submission.

Differences on the outgoing side:
- The individual discovers the response to their proposal by participating
in the mailing list discussion, looking at the IETF web site, using the ID
tracker, etc.
- The above methods are not realistic or appropriate for other SDOs to
receive information on what is going on in IETF. It is not realistic to
think that I should get 300 people in my study group to subscribe to
ccamp and mpls and decide for themselves what IETF thinks of something
that was sent over from ITU-T. There is no way in a formal organization
like ITU-T for us to take stuff we found on email discussions or web
sites and consider this as input to a study group meeting. It is not
ITU-Ts place to be watching the email lists and judging for ourselves
what the IETF consensus reaction might be to a particular proposal
(in fact, depending on which emails one pays the most attention to, one
can get some widely varying ideas about what IETF "thinks"). It should
be up to IETF to judge the consensus and to tell ITU-T the result.

Liaison statements are a method that is widely used to communicate between
standards groups. IETF has gone for a long time without employing these.
We have had the rare case where an IESG member takes the initiative to
put a response together, but it has not been standard operating procedure
to:
1) Pay attention to incoming liaisons.
2) Make sure that any request (For Action or For Comment) gets a reply
   (Note that SDOs are not compelled do what was asked of them in an incoming
   liaison statement for Action - but whether or not they do what was asked,
   other SDOs nearly always reply and, if not doing what was asked, they
   explain why not or make a counter-proposal).
3) Generate liaison statements to inform other SDOs about work ongoing in
   IETF that the other SDO should consider when doing their work.
4) Use liaison statements to ask for an "official" position about the
   meaning or intent of standards from other organizations (I recall an
   earlier debate where different IETF participants had different
   understandings of how some T1X1/ITU-T standards were to be interpreted.
   It would have been best to cut that discussion short and just ASK
   T1X1/ITU-T what they meant. You can be sure that T1X1 and ITU-T would
   have responded!)

As the importance of IP protocols increases, and the work of IETF becomes
increasingly intertwined with the technologies and standards that are in
the domain of other SDOs, it seems to me to be ESSENTIAL that IETF begin
to incorporate the sending and receiving of liaison statements as part of
its normal operating procedure. 
Regards,
Steve

Loa Andersson wrote:
> 
> Steve,
> 
> Bala said it was a joke! And it wasn't hard to parse with a bit of humor.
> Actuall quite funny :). I guess I could make a very similar flow chart,
> in trying to discuss with some people around mpls.
> 
> But seriously claiming (you are not joking, are you?) that Balas flow
> chart demonstrates that we intend to give work "externally generated"
> a fast track to the trash I find below the level of this discussion.
> 
> The intention of the change process is to create a way for the (g)mpls
> technology area to recieve and handle new requirements and new ideas, the
> exact opposite of you are claiming.
> 
> In fact every time I send a new  ID (draft-andersson-xxxx-foo-00.txt) seen
> from the IETF and the working groups it is in some sense "external".
> What is that
> makes something that originates from "the other SDOs" so special from a
> technical
> point of view. The change process are focused on guaranteeing that new
> (g)mpls technology ideas are  evaluated based on their technical merits.
> 
> /Loa
> 
> Stephen Trowbridge wrote:
> 
> >Curtis,
> >I have no problem to seperate the liaison process from the internal process.
> >In fact, a good liaison process is needed that would have much broader
> >applicability than (G)MPLS protocols.
> >
> >However, I do disagree that we can go forward on one with out the other.
> >As Bala's flowchart shows, the effect of applying this draft to internally
> >and externally initated work alike is to give the externally initiated
> >work a fast track to the trash. Without the liaison process, this draft
> >seems to make what is already a bad problem with how we deal with input
> >from other SDOs even worse.
> >Regards,
> >Steve
> >
> >Curtis Villamizar wrote:
> >
> >
> >>In message <[email-masked]>, Loa Andersson writes:
> >>
> >>
> >>>- I don't think it is agood idea to describe the two process in the same
> >>>  document. the chnage-process is for our internal use, the liasion process
> >>>  is for our commuinication with other SDOs
> >>>
> >>>
> >>If we can agree on this, then we can move forward with your document.
> >>
> >>Curtis
> >>
> >>
> >
> >
> >
> >

Envelope-to: [email-masked]
Delivery-date: Mon, 03 Mar 2003 07:54:23 -0800
Date: Mon, 3 Mar 2003 10:51:48 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

I think that we (the IETF) do need to work on the "liaison problem"
but I do not think that a perfect liaison process would reduce the
requirement for the IETF to be sure that the extension process for
IETF protocols is clearly documented.

We have been trying to be clear in new protoocls by including 
an IANA Considerations section that says how to extend the technology.  But
many IETF protocols come from a time before we started doing that and
I think it is vital that the process gets defined for those protocols
(one example is RFC 2780, another is RFC 3427)

I expect that we will have to have a quite formal dicussion
on the "liaison problem" and think it needs to be added to the
problems list (and have been told that it will be noted in the
next version of the ID)

Scot

Delivery-date: Mon, 03 Mar 2003 06:58:07 -0800
Date: Mon, 03 Mar 2003 07:56:28 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: George Swallow <[email-masked]>
CC: [email-masked], Loa Andersson <[email-masked]>, [email-masked], ccamp <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

All,
Lets try to zero in on what the problem really is.

I think that liaison handling (or the lack thereof) is not just a
problem. It is THE problem. Does anybody really believe that the
reason this draft exists in the first place is that there are a
bunch of individuals going wild trying to change or extend the
(G)MPLS protocols?

What seems to have generated most of the arguments is the handling
(or bungling) of the communications process (or lack of process)
with other SDOs. This is the process we need to fix.
Dealing with requests from individuals to extend or change the
protocols might be good to have a process for, but realistically,
has any individual made such a request yet? Why is this important?

Now, if we can agree that liaisons are THE problem,
there are two ways we can go:
- We can start work on a general purpose liaison process to be
applied across the whole of IETF (revival of one of the POIS*
working groups?).
- We could try to develop a pilot process for sub-IP (which is
where we seem to have a lot of the problems), and take what we
learn from its implementation to feed into a process that would
apply to the whole of IETF.

While I can appreciate that a general problem should usually have
a general solution, there is some appeal to taking the second
approach because (1) we could probably get something underway
faster; and (2) sub-IP seems to be where the lack of such a
process is causing us the most pain.
Regards,
Steve

George Swallow wrote:
> 
> > In message <[email-masked]>, Loa Andersson writes:
> > >
> > > - I don't think it is agood idea to describe the two process in the same
> > >   document. the chnage-process is for our internal use, the liasion process
> > >   is for our commuinication with other SDOs
> >
> > If we can agree on this, then we can move forward with your document.
> 
> I think they need to be separate because the liaison draft should
> apply across the board to IETF / ITU interactions and this document
> applies only to (G)MPLS.
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824

Delivery-date: Mon, 03 Mar 2003 05:59:31 -0800
Date: Mon, 03 Mar 2003 14:56:38 +0100
From: Genadi Velev <[email-masked]>
Subject: RE: draft-kawakami-mpls-lsp-vlan-00.txt
To: Kireeti Kompella <[email-masked]>, [email-masked], Heiles Juergen <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-to: [email-masked]

Hi all,

as I can see, 2 different issues raised regarding this draft. (please see
inline...)

1) proper WG for this draft

> One high-level comment, and one addressing the issue that Dimitri
> raised;
>
> The CCAMP WG deals (mostly) with protocol extensions that are *common*
> across a variety of technologies, such as GMPLS signaling and routing,
> and LMP.  There are cases of doing specific technology work, such as
> SDH, only because there is no WG for that work.  The WG chairs would
> have to consult with their ADs to figure out the right home for this
> work that seems to me to be specific.
>
Kireeti,
thanks for your clarification. You are right that this technology is a
specific one, but OTOH as Dimitri pointed out it fits perfectly to the group
of Layer-2 Switch Capable (L2SC) interfaces.
I would like to ask you and Loa/George to help us to find the proper WG for
the draft!

2) employment of CR-LDP

> > thus i am bit surprised this i-d proposes the use
> > of cr-ldp, for instance:
>
> Any i-d can propose anything :-)  If it is to be a WG doc, then
> the CR-LDP parts will have to be reviewed.  If it is to be Standards
> Track, the CR-LDP parts will have to be removed -- if they stay in,
> the doc will at best be put on Info track.
>
Kireeti and Dimitri,
I didn't know about the existence of MPLS WG's consensus and RFC 3468. Now,
after your valuable comments, I realize that we - the authors of the ID -
should reconsider the employment of CR-LDP. Since 2 protocols are proposed
to setup LSP (LDP and CR-LDP), it would be possible in a future version of
the ID to specify the use of LDP only.

Our initial intention of the ID was, if the ID is accepted as WG doc, that
it can become an informational RFC, not a standard one.

thanks,
Genadi

Delivery-date: Mon, 03 Mar 2003 03:50:50 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-04.txt
Date: Mon, 03 Mar 2003 06:45:55 -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 Multi-Protocol Label Switching (GMPLS) Architecture
	Author(s)	: E. Mannie
	Filename	: draft-ietf-ccamp-gmpls-architecture-04.txt
	Pages		: 57
	Date		: 2003-2-28
	
Future data and transmission networks will consist of elements such 
as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), 
photonic cross-connects (PXCs), optical cross-connects (OXCs), etc 
that will use Generalized MPLS (GMPLS) to dynamically provision 
resources and to provide network survivability using protection and 
restoration techniques.This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SDH/SONET, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The main focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-architecture-04.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-architecture-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: Sun, 02 Mar 2003 12:57:11 -0800
Date: Sun, 02 Mar 2003 15:53:29 -0500
To: "Adrian Farrel" <[email-masked]>, "Kireeti Kompella" <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: CCAMP 56 agenda
Cc: <[email-masked]>

>Kireeti,
>The following drafts are candidates for discussion...
>
>GMPLS MIBs
>draft-ietf-ccamp-gmpls-te-mib-00.txt
>draft-ietf-ccamp-gmpls-lsr-mib-00.txt
>I am not particularly keen to say anything on this subject, but perhaps the WG
>is owed a statement on the progress (or lack of it).

         Not sure there is a reason to discuss this as part of the
agenda other than to say that these MIBs are awaiting updates
of the base MPLS MIBs.

         --Tom

>Crankback
>draft-iwata-mpls-crankback-05.txt
>Would like to get this draft into a WG even though it has more technical 
>work to
>be done.
>Rumor has it that inter-area will finally make it onto the CCAMP charter!
>The issue of crankback is raised by the ITU in ASON, and this might start to
>address their requirements.
>
>Route exclusion
>draft-lee-ccamp-rsvp-te-exclude-route-01.txt
>Route exclusion is also, perhaps, ripe for consideration. It has application
>both in single and multi-area networks.
>
>Cheers,
>Adrian
>
>
>
>
>
>----- Original Message -----
>From: "Kireeti Kompella" <[email-masked]>
>To: <[email-masked]>
>Sent: Sunday, March 02, 2003 12:55 AM
>Subject: CCAMP 56 agenda
>
>
> > Hi,
> >
> > If you would like to speak at the CCAMP WG at the 56th IETF, please
> > reply to this email -- that will help the chairs track requests.
> > Also, please state which Internet draft(s) form the basis of the
> > talk that others may come prepared.
> >
> > Note: these are *not* presentations, expositions, or tutorials.
> > A small number of slides that say what has changed *since the
> > last IETF*, issues that were raised in the interim, and resolutions
> > to those issues is the ideal.  If there hasn't been a discussion
> > on the mailing list, in many cases that is a sign that the topic
> > isn't (yet) ready for prime time.
> >
> > Thanks,
> > Ron and Kireeti.
> >

Delivery-date: Sun, 02 Mar 2003 12:57:04 -0800
Date: Sun, 02 Mar 2003 15:54:21 -0500
To: Kireeti Kompella <[email-masked]>, Adrian Farrel <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: CCAMP 56 agenda
Cc: [email-masked]

At 09:20 AM 3/2/2003 -0800, Kireeti Kompella wrote:
>Hi Adrian (and Tom et al),
>
>On Sun, 2 Mar 2003, Adrian Farrel wrote:
>
> > The following drafts are candidates for discussion...
> >
> > GMPLS MIBs
> > draft-ietf-ccamp-gmpls-te-mib-00.txt
> > draft-ietf-ccamp-gmpls-lsr-mib-00.txt
> > I am not particularly keen to say anything on this subject, but perhaps 
> the WG
> > is owed a statement on the progress (or lack of it).
>
>Can you give us an estimate for when this work would be ready to go to
>WG Last Call?  It would be good to put it explicitly on the milestones.

         The next meeting in Vienna is a good date IMHO.

         --Tom

> > Crankback
> > draft-iwata-mpls-crankback-05.txt
> > Would like to get this draft into a WG even though it has more 
> technical work to
> > be done.
> > Rumor has it that inter-area will finally make it onto the CCAMP charter!
> > The issue of crankback is raised by the ITU in ASON, and this might 
> start to
> > address their requirements.
>
>The charter is currently frozen, but when a certain WG chair behaves
>himself, the discussion will be on.
>
> > Route exclusion
> > draft-lee-ccamp-rsvp-te-exclude-route-01.txt
> > Route exclusion is also, perhaps, ripe for consideration. It has 
> application
> > both in single and multi-area networks.
>
>Noted.
>
>Kireeti.

Delivery-date: Sun, 02 Mar 2003 09:20:54 -0800
Date: Sun, 2 Mar 2003 09:20:39 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Adrian Farrel <[email-masked]>
cc: [email-masked]
Subject: Re: CCAMP 56 agenda

Hi Adrian (and Tom et al),

On Sun, 2 Mar 2003, Adrian Farrel wrote:

> The following drafts are candidates for discussion...
>
> GMPLS MIBs
> draft-ietf-ccamp-gmpls-te-mib-00.txt
> draft-ietf-ccamp-gmpls-lsr-mib-00.txt
> I am not particularly keen to say anything on this subject, but perhaps the WG
> is owed a statement on the progress (or lack of it).

Can you give us an estimate for when this work would be ready to go to
WG Last Call?  It would be good to put it explicitly on the milestones.

> Crankback
> draft-iwata-mpls-crankback-05.txt
> Would like to get this draft into a WG even though it has more technical work to
> be done.
> Rumor has it that inter-area will finally make it onto the CCAMP charter!
> The issue of crankback is raised by the ITU in ASON, and this might start to
> address their requirements.

The charter is currently frozen, but when a certain WG chair behaves
himself, the discussion will be on.

> Route exclusion
> draft-lee-ccamp-rsvp-te-exclude-route-01.txt
> Route exclusion is also, perhaps, ripe for consideration. It has application
> both in single and multi-area networks.

Noted.

Kireeti.

Delivery-date: Sun, 02 Mar 2003 09:17:19 -0800
Date: Sun, 2 Mar 2003 09:16:29 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
cc: [email-masked], Heiles Juergen <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>
Subject: Re: draft-kawakami-mpls-lsp-vlan-00.txt

Hi All,

One high-level comment, and one addressing the issue that Dimitri
raised;

The CCAMP WG deals (mostly) with protocol extensions that are *common*
across a variety of technologies, such as GMPLS signaling and routing,
and LMP.  There are cases of doing specific technology work, such as
SDH, only because there is no WG for that work.  The WG chairs would
have to consult with their ADs to figure out the right home for this
work that seems to me to be specific.

> thus i am bit surprised this i-d proposes the use
> of cr-ldp, for instance:

Any i-d can propose anything :-)  If it is to be a WG doc, then
the CR-LDP parts will have to be reviewed.  If it is to be Standards
Track, the CR-LDP parts will have to be removed -- if they stay in,
the doc will at best be put on Info track.

Kireeti.

Envelope-to: [email-masked]
Delivery-date: Sun, 02 Mar 2003 08:38:17 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: CCAMP 56 agenda
Date: Sun, 2 Mar 2003 11:36:57 -0500

Kireeti,
The following drafts are candidates for discussion...

GMPLS MIBs
draft-ietf-ccamp-gmpls-te-mib-00.txt
draft-ietf-ccamp-gmpls-lsr-mib-00.txt
I am not particularly keen to say anything on this subject, but perhaps the WG
is owed a statement on the progress (or lack of it).

Crankback
draft-iwata-mpls-crankback-05.txt
Would like to get this draft into a WG even though it has more technical work to
be done.
Rumor has it that inter-area will finally make it onto the CCAMP charter!
The issue of crankback is raised by the ITU in ASON, and this might start to
address their requirements.

Route exclusion
draft-lee-ccamp-rsvp-te-exclude-route-01.txt
Route exclusion is also, perhaps, ripe for consideration. It has application
both in single and multi-area networks.

Cheers,
Adrian

----- Original Message -----
From: "Kireeti Kompella" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, March 02, 2003 12:55 AM
Subject: CCAMP 56 agenda

> Hi,
>
> If you would like to speak at the CCAMP WG at the 56th IETF, please
> reply to this email -- that will help the chairs track requests.
> Also, please state which Internet draft(s) form the basis of the
> talk that others may come prepared.
>
> Note: these are *not* presentations, expositions, or tutorials.
> A small number of slides that say what has changed *since the
> last IETF*, issues that were raised in the interim, and resolutions
> to those issues is the ideal.  If there hasn't been a discussion
> on the mailing list, in many cases that is a sign that the topic
> isn't (yet) ready for prime time.
>
> Thanks,
> Ron and Kireeti.
>

Delivery-date: Sun, 02 Mar 2003 06:58:05 -0800
Date: Sun, 02 Mar 2003 15:53:49 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: [email-masked]
Cc: Heiles Juergen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-kawakami-mpls-lsp-vlan-00.txt

Delivery-date: Sat, 01 Mar 2003 21:57:54 -0800
Date: Sat, 1 Mar 2003 21:55:36 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: CCAMP 56 agenda

Hi,

If you would like to speak at the CCAMP WG at the 56th IETF, please
reply to this email -- that will help the chairs track requests.
Also, please state which Internet draft(s) form the basis of the
talk that others may come prepared.

Note: these are *not* presentations, expositions, or tutorials.
A small number of slides that say what has changed *since the
last IETF*, issues that were raised in the interim, and resolutions
to those issues is the ideal.  If there hasn't been a discussion
on the mailing list, in many cases that is a sign that the topic
isn't (yet) ready for prime time.

Thanks,
Ron and Kireeti.

Envelope-to: [email-masked]
Delivery-date: Sat, 01 Mar 2003 18:06:15 -0800
Date: Sat, 1 Mar 2003 21:04:27 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Rsvp] RSVP change document
Cc: [email-masked], [email-masked]

the tsvwg list will be the main venue 

I will talk with Allison to see if there is time in teh tsvwg meeting
to start the dicussion

Scott

---

>From [email-masked]  Sat Mar  1 21:00:42 2003
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
From: Kireeti Kompella <[email-masked]>
To: [email-masked], "" <[email-masked]>, "" <[email-masked]>,
   "" <[email-masked]>, "" <[email-masked]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Rsvp] RSVP change document
Sender: [email-masked]
Errors-To: [email-masked]
X-BeenThere: [email-masked]
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:[email-masked]?subject=help>
List-Archive: <http://mailman.isi.edu/pipermail/rsvp/>
Date: Sat, 1 Mar 2003 17:59:10 -0800 (PST)

Hi All,

The current venue for discussing draft-kompella-rsvp-change-00.txt
(IANA Considerations and change process for RSVP) will be in the
TSVWG (Thu 13:00-15:00 -- if not, I hope either the TSV ADs will
correct me.

For now, let's limit the discussion to the tsvwg mailing list.

Kireeti.
_______________________________________________
Rsvp mailing list
[email-masked]
http://mailman.isi.edu/mailman/listinfo/rsvp

Delivery-date: Sat, 01 Mar 2003 18:02:40 -0800
Date: Sat, 1 Mar 2003 17:59:10 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked], "" <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>
Subject: RSVP change document

Hi All,

The current venue for discussing draft-kompella-rsvp-change-00.txt
(IANA Considerations and change process for RSVP) will be in the
TSVWG (Thu 13:00-15:00 -- if not, I hope either the TSV ADs will
correct me.

For now, let's limit the discussion to the tsvwg mailing list.

Kireeti.

Envelope-to: [email-masked]
Delivery-date: Sat, 01 Mar 2003 11:50:34 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "John Drake" <[email-masked]>, <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "George Swallow" <[email-masked]>
Cc: <[email-masked]>
Subject: draft-ccamp-gmpls-overlay-00.txt
Date: Fri, 28 Feb 2003 22:56:06 -0500

Hi folks,

A couple of questions about sections 5 and 6.

Can we "restore" Notify_Request functionality on the other side of the core?
This is distinct from dropping the Notify_Request from the Path/Resv message
because we want to allow the tail part of the LSP (i.e. that part beyond the
downstream Edge Node) to send Notifies.

There would appear to be two cases.

First the core does not care about Notify messages within the core. In this case
the Notify_Request can be left in place. Core nodes can simply fail to send
Notify messages.
(The alternative - that all nodes that provide routes out of the core can fail
to forward Notifies - should be rejected because Notifies may need to be sent
across the core.)

The second case is more complicated. The core also wants to use Notifies,
reporting errors to the ingress/egress core nodes. Under normal circumstances we
would simply replace the Notify_Request on the way through, but how will we
restore the Notify function?

a. Introduce a 'stack' of Notify requests
b. Have Notifies forwarded as...
The core node next to the edge node that receives a Notify_Request from the edge
node replaces it with its own Notify_Request. Similarly, a core node that is
about to send a Notify_Request to an edge node replaces it with its own
Notify_Request. When a core node receives a Notify message from an edge node and
that Notify message is targeted at the core node, it readdresses it to the
remote core node to which it reports Notifies. When a core node next to an edge
node receives a Notify message and the reporting node is not within the core, it
readdresses it to the report-to node specified in the original Notify_Request
object.

(can we have a name for a core node adjacent to an edge node?)

In section 6, should we have some statement about PathErr with state removal or
would this always be propagated?

Also in section 6, I wonder whether the core should have liberty to use
alarm-free setup and tear-down even if the edge networks do not.  It seems
likely that the edge networks might not be concerned with alarms (possibly being
packet switched), but the core will care.

Let me know if you want text.
Cheers,
Adrian

Envelope-to: [email-masked]
Delivery-date: Sat, 01 Mar 2003 11:50:26 -0800
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "'Bala Rajagopalan'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Sudheer Dharanikota \(E-mail\)" <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Dimitri Papadimitriou'" <[email-masked]>, "Yakov Rekhter" <[email-masked]>
Subject: draft-ietf-ccamp-gmpls-recovey-funtional-00.txt
Date: Sat, 1 Mar 2003 12:19:07 -0500

Jonathan, Bala,

Thanks for this draft, and well done for getting out well before SF meeting!

I wonder if this is a key draft to actively take to the ITU for their opinions?

I have some comments. Let me know if anything is unclear.

Cheers,
Adrian

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

section 2 para 1
It would be helpful to clarify that a bidirectional LSP can utilize
unidirectional 1+1 span protection.  This comes out in section 2.1, but given
the re-use of the keyword 'unidirectional' it would be good to bring out the
difference more explicitly.

section 2 para 2
Why do you insist that M<=N? Although this may be normal and reasonable, I don't
see that there is any reason to enforce this.

section 2 para 2
The paragraph seems to fizzle out.

section 2.2, point 2, bullet 2
If the signaling procedures for 1+1 bidirectional protection are "the same as in
1+1 unidirectional" how can a service requester specify what type of protection
should be used where links are available that offer either (or both) types of
protection.

section 2.3
It might appear that the material for 1:1 protection and for extra traffic
should be split into separate sections with extra traffic building on the
functions of 1:1.  Can you add some text to explain why this is not the case?

section 2.3
I don't see anything here about setting up the low priority LSP that constitutes
the extra traffic on a protection span. Similarly, although you say,
"Pre-emption must be supported to accommodate Extra Traffic" you don't discuss
the signaling or repair of the LSP which has had its traffic displaced.

section 3.3
I think it might be useful to highlight that end-to-end M:N protection is only a
special case of shared mesh protection, and that shared mesh can equally be
applied to resource sharing on the protection paths of LSPs with distinct source
and/or destination points.

section 3.3
I think two sections need to be added.
- extra traffic (same rules as for span protection)
- "unprotected" and "protection restored" signaling to the LSPs that share the
protection resources

Tunneling
It would be helpful to consider the case where a "link" is itself an LSP with
transit nodes where resources must be managed.

Delivery-date: Sat, 01 Mar 2003 11:29:30 -0800
Date: Sat, 1 Mar 2003 11:28:48 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Jonathan Sadler <[email-masked]>
cc: [email-masked], "" <[email-masked]>, "" <[email-masked]>
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS  vto  Proposed Standard

Hi Jonathan,

On Sun, 23 Feb 2003, Jonathan Sadler wrote:

> Please consider the following comments on these drafts:
>     draft-ietf-ccamp-gmpls-routing-05.txt
>     draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
> Many of the comments are based on implementation experience.  These comments are
> marked with a (*).

Thanks for your comments.  Most of these would have more appropriate to
raise in the WG Last Call, but it is certainly better to bring them to
light now than never.

> ==========
>
> 1. In section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt, the operations for
> Packet Switch Capable (PSC) are defined.  Reference is made to Minimum LSP bandwidth
> for SDH encoding.  None of the examples in section 5 of
> draft-ietf-ccamp-gmpls-routing-05.txt show how this field should filled.

Note that all possible permutations cannot possibly be addressed; however,
we will consider adding some examples here.

> 2. The mechanism for showing relationships between server and client layers is not
> generalized*.  Specifically:
>   - Relationships between SONET/SDH layers (ISC type: TDM) are
>     implicitly stated based on the Min and Max LSP bandwidth
>     advertised*.  To quote draft-ietf-ccamp-gmpls-routing-05.txt:
>
>      "On an interface having Standard SDH multiplexing, an LSP
>       at priority p could reserve any bandwidth allowed by the
>       branch of the SDH hierarchy, with the leaf and the root
>       of the branch being defined by the Minimum LSP Bandwidth
>       and the Maximum LSP Bandwidth at priority p."
>
>     This requires node doing the route calculation to understand
>     the G.707 multiplexing hierarchy.  Since LSP routing is source
>     routed, it could be the node doing the route calculation
>     doesn't understand G.707.

This document does *not* cover how path computation is done.  Of
course, the information is less than useful if it cannot be used
effectively.  However, it has been pointed out implicitly and
explicitly in several documents that the head end does *not* have
to do the entire route computation -- this is one reason why there
are loose hops in the ERO.  See also the various drafts on multi-area
TE computation.

>   - Relationships between PSC-n (for IP switching) and SONET/SDH are
>     explicitly specified on the encoding type specified in the PSC-n
>     announcement*.  However, SONET/SDH is not a single layer.  It
>     must be possible to identify if the PSC-n layer can be carried
>     by a VC-11 trail, a VC-12 trail, a VC-3 trail, a VC-4 trail,
>     or a VC-4-nc trail.
>
>     Section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt tries
>     to deal with this in the following paragraph:
>
>      "On a PSC interface that supports Standard SDH encoding, an
>       LSP at priority p could reserve any bandwidth allowed by
>       the branch of the SDH hierarchy, with the leaf and the root
>       of the branch being defined by the Minimum LSP Bandwidth
>       and the Maximum LSP Bandwidth at priority p."
>
>     The problem is this contradicts the following paragraph:
>
>      "The Maximum LSP Bandwidth takes the place of the Maximum
>       Bandwidth ([ISIS-TE], [OSPF-TE]). However, while Maximum
>       Bandwidth is a single fixed value (usually simply the link
>       capacity), Maximum LSP Bandwidth is carried per priority,
>       and may vary as LSPs are set up and torn down."
>     Specifically, how does a completely available OC-48 interface
>     with VC-11 over VC-3, VC-3, and VC-4 get encoded?  Based on
>     the first paragraph, the encoding would be MinLSPBW=1.5M, and
>     MaxLSPBW[p]=155M.  Ignoring the issue that VC-11 over VC-4
>     ends up being shown as supported, the second paragraph states
>     that the MaxLSPBW[p] should be 2.5G.
>
>     Knowing the OC-48 is completely available is useful information,
>     as multiple VC-4s could be used in an LCAS group to support
>     connections that need data rates over 155M*.

It is not the intent of this document to support all possible info
about a link, but to support a useful *and* scalable subset.  We will
be guided by implementation and deployment experience to add
selectively to the information.  Note that the Max Reservable bandwidth
field remains, and in the case that the link is not a bundle, will be
set to ~2.5G.

>  - The mechanism does not support describing common muli-layer
>    relationships such as IP over DS1 over VC-11 or IP over DS3
>    over VC-3*.

It is also not the intent of this document to provide a full description
of routing info for SDH.  This is a *general* document.  The intent is
to provide a code point for SDH to be expanded by another document.  This
was the model used for signaling as well: a *general* func spec, a
*general* doc for each protocol, and *SDH-specific* docs.  There is an
SDH specific routing doc; detailed comments are better directed there.

>  - Sometimes layer relationships are described in an "inverted"
>    manner*. Section 5.1 of draft-ietf-ccamp-gmpls-routing-05.txt
>    states:
>      "STM-16 POS Interface on a LSR
>
>           Interface Switching Capability Descriptor:
>              Interface Switching Capability = PSC-1
>              Encoding = SDH
>              Max LSP Bandwidth[p] = 2.5 Gbps, for all p"
>
>    Where PSC-1 is the client of an SDH (sic) server.
>
>    Section 5.5 states:
>       "Interface of an opaque OXC (SDH framed) with support for
>        one lambda per port/interface"
>
>       "   Interface Switching Capability Descriptor:
>              Interface Switching Capability = LSC
>              Encoding = SDH"
>
>    In this case, SDH is a client of a wavelength server (LSC).
>    However, unlike in section 5.1, the layer relationship is
>    inverted.

Is this pointed out as a curiosity, or is there a question that needs
to be addressed?

> 3. Layer specific attributes are not supported*.  Specifically:

Good points.  Please raise this with the SDH routing doc.

> 4. The "TDM" Interface Switching Capability presumably includes
>    layers other than SONET/SDH, such as PDH* (DS1, DS3, E1, E3) and
>    G.709.  The interaction with these layers needs to be defined.

Ditto.

> 5. In many cases, 8 levels of priority are not necessary*.  A more
>    compact encoding that has a bitfield stating the priority levels
>    being announced would reduce the size of the announcement.

This has been discussed elsewhere.  This is the model in the base
TE document; it has proven reasonable in practice.  If deployment
proves otherwise, this is easy to fix.  For now, though, I would
leave it as is.

Thanks again for your comments,
Kireeti.

Delivery-date: Sat, 01 Mar 2003 11:07:51 -0800
Date: Sat, 1 Mar 2003 10:45:56 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Bala Rajagopalan <[email-masked]>
cc: [email-masked], "" <[email-masked]>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Bala,

On Thu, 27 Feb 2003, Bala Rajagopalan wrote:

> Just ran into this ID. The flow chart, as usual,
> was too complicated for me to comprehend, to I
> ran it through the decoder software that IESG
> provides to unscramble its policy statements
> (see http://www.ietf.org/iesg/policy_faq/demystify.exe).
> The flow chart was then rendered human-readable
> as follows:

Thanks, Bala -- we needed that!

It seems to be time to follow up RFC 3251 with one on "Electricity
within CCAMP" :-)

Kireeti.

Delivery-date: Sat, 01 Mar 2003 11:04:27 -0800
Date: Sat, 1 Mar 2003 11:00:28 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: liaisons

While we're on the subject, let me suggest to all who are interested
to browse http://www.ietf.org/IESG/liaison.html and especially look
at the liaison statements whose "Token" is CCAMP (and some of those
with Sub-IP).  The last four in Jan 2003 and the last one in Feb
are particularly relevant.

Kireeti.

PS: Note that it is not the job of a WG chair to point these out;
    however, I point these out in the interest of improving relations.