Subject: RE: New charter

From: "Don Fedyk" <[email-masked]>
Date: Tue, 30 Nov 2004 19:17:28 -0500

Hi Kireeti

My top 4 (after improving the moral values of the Internet of course :)

1) MPLS-GMPLS migration 
2) GMPLS interoperability issues
3) L1VPNS
4) Decoder ring for addresses

Don 

Delivery-date: Tue, 30 Nov 2004 14:46:54 +0000
From: "Adrian Farrel" <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Subject: Draft minutes from Tove
Date: Tue, 30 Nov 2004 14:44:49 +0000

Hi ccamp! 

Thanks to Lyndon Ong, Deborah Brungard, and Dimitri Papadimitriou we
can now read about the ccamp meeting, IETF61. 

Please provide your comments no later than 3rd December if you miss any
important wording (or you like to change the complete meeting;-)
/ Tove 

Tove Madsen
Acreo AB
[email-masked]
=== 

61st IETF CCAMP Minutes
11/11/2004
Minutes taken by
Lyndon Ong, Deborah Brungard, Dimitri Papadimitriou 

1. Admin and agenda bash - Chairs (5 min)
Agenda bashing - no changes 

2. Status of WG drafts - Adrian (10 min) 

Drafts - now unblocked, however the removal of the MPLS bundling draft has
caused another snag. We have got two new RFCs, Architecture (3945) and
SONET/SDH Extensions (3946).  Six drafts are in the queue.  Five are in IETF
Last Call, two are in IESG review.  15 active drafts - if you want a draft
adopted as WG draft, let's finish these first!  Tunnel trace in particular
seems to have very little interest - will be discussed wrt to rechartering. 

Overall status: almost all milestones completed, should recharter or close
in March '04! 

Lou - slide does not list all 15 drafts - others are still active? In
particular Alarm_Spec 

Adrian said no intention to exclude, asked if implementation on alarm draft,
Lou said at least one, possibly two, Kireeti said only need one, so Ok to go
forward.
Adrian - Note: Node_Id based Hello has not been updated before deadline
Adrian - Milestones and re-chartering will be covered at the end of the
meeting. 

3. Link Bundling - Zafar Ali
 -- Issues with current RFCs and drafts
 -- Draft removed from the RFC editor's queue
 -- Issues with scooping type 4/5 TLVs for IF_ID_RSVP_HOP and
IF_ID_ERROR_SPEC, also recording of route
 -- Plan to address first two issues in an updated draft but component link
recording will remain outside the scope of the bundling draft.  Will allow
but recommend against use of types 4/5.
 -- Work on recording/explicit control will be done in a separate ID.  Home
in MPLS or CCAMP? 

 -> see slides 

 -- Plans
Pulled from queue (reviewed slides) 

 -- Adrian: procedure -> MPLS WG own document. Do review on what happens in
this WG
Note: speed is really important as we have multiple blocking documents in
the CCAMP WG queue. 

 -- Kireeti - this is not free for all on the bundling draft - change to be
proposed and to be sent on the list (delta only) 

George: as MPLS chair, MPLS group plans to do updates quickly - considered
as last call comments 

4. ASON Signaling Solutions - Dimitri P (5min)
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.
txt> 

<http://www.olddog.co.uk/draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt> 

 -- Mention OIF response is on the way 

 -- ASON signaling - no updates but lots of thinking esp. call setup message
naming (Notify vs. specialized message), desire not to "piggyback" call
information in the connection message.  Expect finalized draft around
Christmas time.
 -- ASON routing solutions design team 

 - Evaluation of common "pattern" has taken time, evaluation document should
be issued by end- November.
 - Model shown - use of terminology - what is TE Router ID, what is OSPF
Router ID?
 - Further considerations - control plane does not transport the actual
transport plane ids, but its view of the transport plane, using an
associated IP addressing space.
 - No internal structure is associated with an abstract node.
 - Hierarchy focus is on exchange of information between peers.
 - Representation of bandwidth needs further thought.
 -- Adrian - it seems the DT has been making good progress, CCAMP WG has
unfortunately not been aware of the progress, progress must be shown to the
group by either sending status or updating the draft.
 -- Dimitri - will mail to the list.
 -- Zafar - how does this work relate to the OSPF and ISIS groups?
 -- DP - we are evaluating what may be missing, after this evaluation we can
address protocol-specific issues.
 -- Zafar - Are you looking at existing mechanisms?
 -- Dimitri - global applicability is next step, currently looking at what
info is exchanged 

5. ITU Liaison - Lyndon Ong 

 -- ITU continues to be interested in converging the work on signaling and
routing
 -- ITU thanks CCAMP for its liaisons, and esp. Adrian for attending the last
Q14 meeting
 -- ITU is currently working on ASON management specifications and thanks
CCAMP for its liaison of the GMPLS MIB work for its review
 -- Zafar - can we also have a report of OIF status?  Chairs and LO; there is
nothing formal to report at this time that's why it was not scheduled on the
agenda.  However, liaisons will be sent to the mailing list for everyone's
review, and if something formal is made available, it will be scheduled.
 -- Lyndon - there is ongoing discussion and communication just sent back to
IETF
 -- Adrian - but not there yet (not available)
 -- Lyndon - is there a need for a permanent liaison from the OIF at the
CCAMP meeting?
 -- Adrian - if there is something to be discussed it will be considered on a
per-request/per-case basis 

6. Graceful Shutdown - Zafar Ali (10 min)
http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-0
0.txt 

 -- Intention is to support a planned shutdown, e.g., for maintenance
purposes
 -- IGP based solution does not cover Inter-AS/Area scenarios
 -- RSVP-based solution does not convey information to all nodes in the
network.
 -- Both mechanisms must complement each other
 -- Use existing sub-code of the Path Error message, then perform
make-before-break for the LSP. Proposed changes are minor and based on
existing framework.
 -- Would like to propose this ID as a WG document
Rahul- is this intra or inter?  inter-domain can use hierarchy of LSPs
(nesting/stitching) to achieve this isolation.
 -- Zafar - though recognize two mechanisms
 -- Rahul- we should clarify these aspects, as well as inter-domain TE
aspects.
 -- Zafar - can add these aspects in the document
 -- Richard Rabbat - why is this GMPLS rather than MPLS?
Zafar - could be shutting down any type of link.
 -- Adrian - in terms of problem space it is needed in both cases
 -- Igor Bryskin - this is a data plane problem followed by rerouting - why
don't we use existing mechanisms such as propagating alarms?
Zafar - distinguish this from alarms as this is not something that requires
an immediate reroute. This is not intended to tackle data plane alarms
 -- Kireeti - maintenance of the link/node - out-of-service issue is to get
traffic out of the link
Igor- alarms do not only mean "failure". Could it use alarm severity?
 -- Kireeti - not an alarm situation.
 -- Adrian - this is maintenance alarm => requires to scope the work
 -- Igor - Tools already exist to trigger the same thing, the existing tools
are more powerful than this proposed one
 -- Zafar - point to the capability of the mechanism having the indication to
perform make-before-break - also suggest put on the list what you think are
alternative mechanisms
 -- Lou Berger - says if we do this, we should use existing mechanisms such
as admin status or alarm (Arthi's suggested one, Igor's alarm admin status).
 -- Zafar - this mechanism is already in the spec - JP's re-optimization
draft
 -- Lou - other mechanisms are in RFCs. We should decide on mechanisms before
we accept as a WG draft.
 -- Kireeti - step back from the solution, so the point is to write down what
is to be achieved (take things out gracefully) -> need first to look at
requirements for what want to do.
 -- Zafar - agreement 

7. Interdomain Framework - Adrian (5min)
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework
 -00.txt>
 -- Minor changes since last time, but published as WG draft
 -- Applies to both MPLS and GMPLS, but currently limited to simpler
functions for initial work
 -- Realize need more discussion on definition of "domain" e.g. Nested
domains, ensure GMPLS included. Will take to list for discussion.
 -- This covers "simple" functions, what about "advanced" functions such as
diverse paths, mapping domain-specific constraints such as DiffServ,
pt-to-mpt, etc.?
 -- Adrian's suggestion is to keep this separate for convenience.
 -- Rahul - MPLS OAM - building blocks are in place, so it can go in this
document; P2MP is considerably less well understood.
 -- Kireeti - what about GMPLS OAM?
 -- Dimitri - need to understand what we mean by GMPLS OAM. Suggest phased
approach. 

8. Interdomain TE Requirements - Tomohiro Otani (5min)
<http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-01.t
xt> 

 -- Joint proposal from NTT/KDDI, can be used for L1VPN, MPLS-TE
 -- Changes:  added section identifying the following general requirements
 - EGP extensions for GMPLS
 - GMPLS Inter-AS signaling, path calculation and recovery
 - GMPLS interdomain TE management
 -- Remaining issues:
 - Investigate added load created by EGP extensions
 - Investigate L1VPN, use of SRLG for consistency, rechartering impacts
 - Propose WG document
 - Zafar - recommended would be a good basis for inter-domain TE framework
 -- Arthi- support effort, but has too many solutions-related aspects in it.
Also suggest separating requirements into signaling, routing and path
computation. Need to clarify what is meant by domain - refer to framework
document.
 -- Dimitri - what about reachability information exchange?  Not addressed,
but will be an important aspect.
 -- Adrian- this is solution, not requirements. Suggest to separate
requirements and solutions. General approval of the work, but need to remove
solutions. Should consider reachability as well as TE aspects.  Restructure
as Arthi suggests.
 -- Otani- agree, will separate
 -- Kireeti summarizing: separate requirements from solution and structure:
signaling from routing (in part. reachability) 

9. Summarize Status and plans of PCE BOF (JP Vasseur) (5 minutes)
 -- Scope issues
 - No intent to come up with new interdomain routing paradigm
 - Scoped applicability to a limited number of TE LSPs
 - Scoped to a "simple" topology of ASes or areas
 -- Previous BOF - clear requirements from many SPs and common theme of
problem - MPLS TE LSP path computation
 -- Architecture - comments noted global picture needed, but no
standardization of architecture.  New revision to be submitted soon in the
meantime please comments!
 -- Note agreed no intention to extend LDP, but possibly other protocols.
 -- Agreed on proposed charter and milestones, proposal to be sent out early
next week.
 -- Many in favor of new WG, none against - need IESG review and work on
charter
 -- Bijan Jabbari - what scale of LSPs?
 -- JP - no specific number, not full mesh - does this mean no scalability
concerns?
 -- Adrian - need to make the problem manageable, at least initially.
 -- Bijan - will WG be open to new architectures?
 -- Kireeti - take this to the list.
 -- Peter Toms - support this, lots of requests for this. 

10. Inter-Domain RSVP-TE extensions - Arthi Ayyangar (5min)
<http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-
te-00.txt>
 -- Changes - include separate section on stitching and required extensions,
clarifications for non-packet LSPs.
 -- Request to make it a WG document - none against, but limited number
agreeing (note: not many read the draft)- list.
 -- Adrian - stitching has wider applicability - should we pull it out into a
separate draft? 

11. Diverse Inter-region Setup - D'Achille - presented by Adrian (5 min)
<http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-
04.txt> 

 -- Adrian not that familiar with this draft. Flags one slide on message
exchange where the head end is in the center rather than at the end. Notes
several claim, explicitly claim of no new protocol seems questionable as new
objects are defined. Need further feedback.
Can't take questions as no authors present to discuss - take to list 

12. Related to 11.  Protection for Inter-AS tunnels - Decnodder - Cristel
Pelsser
<http://www.ietf.org/internet-drafts/draft-decnodder-ccamp-interas-protectio
n-00.txt>
 -- Differs from 11, addresses requirements from TEWG draft
 -- Uses RSVP-TE and FRR
 -- Adds clarifications on SRLG scope, assumed to correspond to a single AS
 -- Looking for feedback, how to generalize to GMPLS
 -- Adrian - need to apply to GMPLS if you want the draft to be in this
group.
 -- Zafar - SRLG issue - need to solve the scooping issue, applies in a
number of places.
 -- Adrian - WG should look at a framework for diverse paths, including PCE.
 -- Zafar - needs more discussion to understand, and already work in MPLS WG
on ABR protection.
 -- Adrian - authors can continue draft, would also like for CCAMP to
evaluate if PCE is appropriate, or something else
 -- JP - should include the PCE mailing list on this.
 -- Adrian - need discussion on the ccamp list. 

13. Requirements for multi-region - Kohei Shiomoto
<http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-requirem
ents-00.txt> 

 -- Region defined based on switching capability - note region is control
plane, layer is data plane
 -- Addresses pre-provisioned FA, triggered FA and no FA cases.  Plain and
hybrid type nodes.
 -- Architecture has generated requirements and solutions drafts
 -- Virtual network topology, application example
 -- Propose as WG document.
 -- Adrian - handling regions are in scope of CCAMP.
 -- Adrian - asks Dimitri to immediately present the extensions then we will
take questions
<http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-extensio
ns-00.txt> 

 -- TE metric inheritance - how to inherit or map metrics
 -- How is recovery abstracted for an FA - e.g., end2end vs. span protected?
 -- Reconvergence of VNT
 -- Handling multiple switching and adaptation capabilities
 -- Zafar - is this a good idea from TE point of view - dynamic FA creation -
need applicability statement - potential bandwidth segmentation issues - may
lose aggregation that you would normally get at the boundary - could add
oscillation.  If still considered a good idea, should it be triggered by
signaling or some other mechanism?  Document needs to list concerns.
 -- Arthi - some parts of requirements still not clear - what is needed
outside of the LSP hierarchy draft?  Need to clarify what is missing from
the existing, and reference where it's covered by existing documents.  Don't
want to reinvent terminology.  Regarding virtual FA setup can be
pre-provisioned or on demand - hierarchy draft already says this, should not
be in the requirements document but only in the solutions document.
Regarding protection - more work needs to be done in the requirements.
 -- Igor - region, layer, hierarchy level are treated interchangeably in the
draft, confusing.  Regarding stitching, this is a very general capability
and should be in LSP hierarchy instead. Kireeti - thinks this should have a
separate document.
 -- Adrian - more clarification would be good on layer/region
 -- Jonathan Sadler - good stuff in general, agree with the goal.  Concern is
that IETF framework is not well aligned to ITU concept of layered network
(G.805).  It would be good to take into account the ITU framework.  Work on
extensions is premature at this time.
 -- Deborah Brungard - authors intended to handle multiple layers as in ITU
(e.g. G.805) - limited to single domain for now, should be addressed to
GMPLS RFCs. Not intended to discuss data plane concepts. Request for more
specific comments. 

14. MPLS-to-GMPLS Migration - Kohei Shiomoto
<http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-0
4.txt> 

 -- Evolution from legacy MPLS to GMPLS -
 -- Differences: architecture (C/D separation, bidirectionality, P&R);
routing (opaque LSA); signaling (new objects, messages)
 -- Propose WG document
 -- Kireeti - question on whether this is in scope - address on charter
 -- Zafar - multi-layer comments also apply here.
 -- Richard Rabbat - supports the work, suggests looking at odd numbers
rather than even.
 -- Ping Pan - how does this differ from the overlay model?
 -- Kireeti - different, take this to the list. 

15. L1 VPN - Tomonori Takeda (10 Min)
<http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt>
<http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt
<http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05
.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt> 

 -- Mailing list - www1.ietf.org/mailman/listinfo/l1vpn
 -- Two drafts applicable, ouldbrahim and overlay - guidelines for
enhancement, deployment scenaros - added terminology refinement, security
considerations, service models
 -- Further comments solicited, planning further liaison to SG13.
 -- Applicability draft examines existing GMPLS protocols for L1 VPN
services. Has added Deborah as co-author.
 -- Concept - set up FA LSP between PEs, use stitching to connect this to
CEs.
 -- Propose to adopt as CCAMP charter item.
 -- Kireeti - supports applicability draft.  Liaison with ITU is very
important - we need to be responsive.  We will discuss this item as part of
the extension of the CCAMP charter 

16. Signaling for L2 LSPs - Dimitri Papadimitriou (10 minutes)
<http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-ls
p-03.txt> 

 -- ATM, FR, ETH, etc.  Defines label request processing, label semantics,
added security section.
 -- Security - threats analysis, attacks on the data plane, L2 LSP signaling,
attacks on control plane
 -- Ask for WG draft, no plan to respin
 -- Dave Allan - Question on Ethernet VLAN tag swapping - not defined in
IEEE.
 -- Dimitri- intended to cover GMPLS scope, not data plane.  Should not
assume tag is per port unique.
 -- Don Fedyk - is this P2P?
 -- Dimitri - Yes (as starting point).
 -- Kireeti - ok, we have a fair consensus, so I would say it's a rough
consensus point. We will take this to the list, Dave and Dimitri to work out
VLAN issue.
 -- Note that an MPLS group draft on L2 has come up 

17. Mesh Carrier Survey - Richard Rabbat (5 min)
<http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-01.tx
t> 

 -- Initially 7 carriers polled, open to others
 -- Also surveys GMPLS control plane deployment
 -- 1 has deployed, 3 within 2-3 years, 3 with no current plans
 -- Concerns with stability, signaling storms
 -- Asking for feedback, new carrier input
 -- Richard - review slides, recommend for CCAMP WG to begin work on shared
mesh restoration performance 

18. Milestone and Charter discussion - Kireeti 

 -- Current activities winding down, esp. P&R, ASON
 -- Others underway, esp. multi-domain
 -- New: migration, VPNs, control plane resilience, addressing,
implementation experience, GTTP (?)
 -- Migration
 - GMPLS supersets MPLS, but some objects are different - label request,
label, upstream label
 - Need BCP on smooth migration, what issues may occur
 -- L1 VPN
 - Should IETF do this?  Should it be in CCAMP?  Tied to UNI and Interdomain
signaling
 -- Control plane resilience - includes graceful restart but also more
 -- Addressing - transport networks use different kinds of addresses - need
decoder ring for mapping transport network address types to IP addresses -
Kireeti considers this useful
 -- Interop results - note that addressing pops up there as well.  BCPs would
be helpful.
 -- Send out request for new work items, replies due Friday 11/19.
 -- Send out checks for consensus on each item, replies due Friday 12/3
 -- Send resulting list to A-Ds, trimmed if necessary, add appropriate
milestones
 -- Consensus is a requirement but not a guarantee.
 -- Lou - how about dropping something from the existing charter -
 -- Kireeti - maybe GTTP - Lou - should note on the list also things that may
be dropped if no support.
 -- Alex - about L1 VPNs - is this research work, or practical?  Need at
least one implementation - is anyone implementing this within a year or two?
 -- Dimitri - Solutions exist provided by vendors today, but no common
framework.  Timeframe for implementation is 18-24 months.
 -- Alex reminds the group of the need for running code.
 -- Adrian - what about informational draft on how to use existing functions
to do the service?  Is there any interest from the research groups or the
real carrier deployment groups?
 -- Tomonori Takeda - NTT has interest, but not sure of protocols.  Timeframe
 - cannot say.  Testing is done.
 -- Yakov Rekhter- vendors cannot disclose future product plans...
 -- Deborah Brungard - carriers also cannot disclose plans, will see interest
by number of co-authors.
 -- Kireeti - have had carriers ask for this technology.  We don't have all
the pieces, but have implemented many of them, and as a vendor would like to
see a solution on how to do. Answer to Alex is yes.
 -- Richard Rabbat - could add this to his survey.
 -- Kireeti supports this. 

MEETING IS ADJOURNED.

Delivery-date: Tue, 30 Nov 2004 12:54:53 +0000
Reply-To: <[email-masked]>
From: <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>
Cc: <[email-masked]>
Bcc: 
Subject: RE: New charter
Date: Tue, 30 Nov 2004 21:52:24 +0900
Comment: =?ISO-8859-1?B?x9GxucD8wNrF673Fv6yxuL/4LCCxpMD8tN64wcGmvu7GwCwgtOO05w==?=
Content-Class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_12CFD_01C4D726.E071A5D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

------=_NextPart_000_12CFD_01C4D726.E071A5D0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<DIV id=3Dmsgbody style=3D"FONT-SIZE: 10pt; FONT-FAMILY: System">
<DIV>&nbsp;</DIV>
<DIV>Kireeti,</DIV>
<DIV>&nbsp;</DIV>
<DIV>1) MPLS-GMPLS migration --- Yes<BR>2) GMPLS interoperability issues =
--- Yes<BR>3a) should the IETF take on L1VPNs? --- Yes<BR>3b) if yes to =
3a, should this be done in CCAMP? --- Yes<BR>4) Waveband switching --- =
Yes<BR>5) Control plane work --- Yes<BR>6) Decoder ring for addresses =
--- included in 1) or 2)<BR>7) Deployment considerations for GMPLS --- =
included in 2)<BR>8) PCE requirements ---&nbsp;job of PCE WG (I'm not =
sure)<BR>9) QoS control --- Yes<BR></DIV>
<DIV><FONT size=3D2>Thanks,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Young</DIV></DIV><img style=3D"display:none" width=3D0 height=3D0 =
src=3D"http://umail.etri.re.kr/External_ReadCheck.aspx?email=3Dccamp@ops.=
ietf.org&name=3Dccamp%40ops.ietf.org&fromemail=[email-masked]&messag=
eid=[email-masked]%3E">
------=_NextPart_000_12CFD_01C4D726.E071A5D0--

Delivery-date: Mon, 29 Nov 2004 18:00:09 +0000
Date: Mon, 29 Nov 2004 09:58:22 -0800 (PST)
From: Arthi Ayyangar <[email-masked]>
To: Kireeti Kompella <[email-masked]>
cc: [email-masked]
Subject: Re: New charter

Kireeti,

My pick for the four most important items are:-

o 7) and in order for 7) to work out, we would need to address 1) and 2)
o 3)
o 8)
o 5)

thanks,
-arthi

> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
>
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
>
> 1) MPLS-GMPLS migration
> 2) GMPLS interoperability issues
> 3a) should the IETF take on L1VPNs?
> 3b) if yes to 3a, should this be done in CCAMP?
> 4) Waveband switching
> 5) Control plane work
> 6) Decoder ring for addresses
> 7) Deployment considerations for GMPLS
> 8) PCE requirements
> 9) QoS control
>
> A rough idea of what each of the above entails follows.
>
> 1) MPLS-GMPLS migration
> 	implementation shift from "MPLS" objects to "GMPLS" objects
> 	BCP on deployment migration for the same
>
> 2) GMPLS interoperability issues
> 	what addresses to use where
> 	nits/clarifications of the specs
> 	guidelines for path computation & constraints
> 	survay
>
> 3) L1VPN work items
> 	identify protocol extensions needed
> 	state what can already be done with what we have
> 	do the actual protocol work for requirements that are not met
> 	liaisons to SG13 as needed
>
> 5) Control plane work
> 	resiliency
> 	graceful shutdown
>
> 6) Decoder ring for addresses
> 	for each address field, identify its nature and ITU equivalent
> 	(may overlap with part of (2))
>
>
> 4, 7-9 are obvious or have been elaborated on the mailing list.
>
> Kireeti.
> -------
>
> PS: The topic of GTTP has carefully been avoided.  More later.
>

Delivery-date: Mon, 29 Nov 2004 13:21:57 +0000
Date: Mon, 29 Nov 2004 14:20:04 +0100
From: [email-masked]
Reply-To: [email-masked]
Organization: Alcatel CTO/R&I
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: New charter

This is a multi-part message in MIME format.
--------------010103010001030401060008
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

Hi,

Kireeti Kompella wrote:

>On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>
>  
>
>>If you have suggested charter updates, please send them to Adrian
>>and me.
>>    
>>
>
>Thanks all for your input.  I have the following items; for each,
>please say "Yes" (should be added to CCAMP charter), "No" (should not
>be added) or "-" (don't care).  I'll remind you once again that not
>all items will make it onto the new charter.
>
>Please keep this subject line (simply reply to this mail).  The
>deadline is Friday Dec 3, 17:00 PST.
>
>1) MPLS-GMPLS migration			YES
>2) GMPLS interoperability issues	YES
>3a) should the IETF take on L1VPNs?	YES
>3b) if yes to 3a, should this be done in CCAMP?	YES
>4) Waveband switching			YES
>5) Control plane work			YES
>6) Decoder ring for addresses		cf 2)
>7) Deployment considerations for GMPLS	YES
>8) PCE requirements			YES
>9) QoS control				YES
>  
>

top 4:
1: 1) + 2) + 7)
2: 5)
3: 3) a+b
4: 8)

then

4) and 9)

Emmanuel

>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>
>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>
>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>
>5) Control plane work
>	resiliency
>	graceful shutdown
>
>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>
>  
>

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
Kireeti Kompella wrote:<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">On Mon, 15 Nov 2004, Kireeti Kompella wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">If you have suggested charter updates, please send them to Adrian
and me.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Thanks all for your input.  I have the following items; for each,
please say "Yes" (should be added to CCAMP charter), "No" (should not
be added) or "-" (don't care).  I'll remind you once again that not
all items will make it onto the new charter.

Please keep this subject line (simply reply to this mail).  The
deadline is Friday Dec 3, 17:00 PST.

1) MPLS-GMPLS migration			YES
2) GMPLS interoperability issues	YES
3a) should the IETF take on L1VPNs?	YES
3b) if yes to 3a, should this be done in CCAMP?	YES
4) Waveband switching			YES
5) Control plane work			YES
6) Decoder ring for addresses		cf 2)
7) Deployment considerations for GMPLS	YES
8) PCE requirements			YES
9) QoS control				YES
  </pre>
</blockquote>
<br>
top 4:<br>
1: 1) + 2) + 7)<br>
2: 5)<br>
3: 3) a+b<br>
4: 8)<br>
<br>
then<br>
<br>
4) and 9)<br>
<br>
<br>
<br>
Emmanuel<br>
<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">
A rough idea of what each of the above entails follows.

1) MPLS-GMPLS migration
	implementation shift from "MPLS" objects to "GMPLS" objects
	BCP on deployment migration for the same

2) GMPLS interoperability issues
	what addresses to use where
	nits/clarifications of the specs
	guidelines for path computation &amp; constraints
	survay

3) L1VPN work items
	identify protocol extensions needed
	state what can already be done with what we have
	do the actual protocol work for requirements that are not met
	liaisons to SG13 as needed

5) Control plane work
	resiliency
	graceful shutdown

6) Decoder ring for addresses
	for each address field, identify its nature and ITU equivalent
	(may overlap with part of (2))

4, 7-9 are obvious or have been elaborated on the mailing list.

Kireeti.
-------

PS: The topic of GTTP has carefully been avoided.  More later.

  </pre>
</blockquote>
<br>
</body>
</html>

--------------010103010001030401060008--

Delivery-date: Mon, 29 Nov 2004 06:03:04 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Subject: RE: New charter
Date: Sun, 28 Nov 2004 22:00:20 -0800

Kireeti,

Responses in-line...

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Kireeti Kompella
> Sent: Tuesday, November 23, 2004 10:22 PM
> To: [email-masked]
> Subject: New charter

<snip>

> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
>
> 1) MPLS-GMPLS migration                       Yes
> 2) GMPLS interoperability issues              Yes
> 3a) should the IETF take on L1VPNs?           Yes
> 3b) if yes to 3a, should this be done in CCAMP?   Yes
> 4) Waveband switching                          --
> 5) Control plane work                          Yes
> 6) Decoder ring for addresses                  --
> 7) Deployment considerations for GMPLS         Yes
> 8) PCE requirements                           Shouldn't this be done in
PCE itself??
> 9) QoS control                                Tentative yes, depends on
what is
                                                involved.
>
> A rough idea of what each of the above entails follows.
>
> 1) MPLS-GMPLS migration
> 	implementation shift from "MPLS" objects to "GMPLS" objects
> 	BCP on deployment migration for the same
>
> 2) GMPLS interoperability issues
> 	what addresses to use where
> 	nits/clarifications of the specs
> 	guidelines for path computation & constraints
> 	survay
>
> 3) L1VPN work items
> 	identify protocol extensions needed
> 	state what can already be done with what we have
> 	do the actual protocol work for requirements that are not met
> 	liaisons to SG13 as needed
>
> 5) Control plane work
> 	resiliency
> 	graceful shutdown
>
> 6) Decoder ring for addresses
> 	for each address field, identify its nature and ITU equivalent
> 	(may overlap with part of (2))
>
>
> 4, 7-9 are obvious or have been elaborated on the mailing list.
>
> Kireeti.
> -------
>
> PS: The topic of GTTP has carefully been avoided.  More later.
>

Delivery-date: Sun, 28 Nov 2004 07:52:53 +0000
Date: Sun, 28 Nov 2004 08:48:16 +0100
From: Loa Andersson <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked], Thomas Narten <[email-masked]>
Subject: Re: New charter

  Kireeti,

definitely agree with c :). And I think that a,b and d summarizes
why I've called L1VPNs not Virtual Private Networks but Virutal
PUBLIC Networks (no I'm not suggesting a name change, just want
to point at a crtical difference in service model).

I support doing L1VP(ublic)N in ccamp.

/Loa

PS
Hmmm... no OC48's to end-hosts? Who said that 3 or 4 computers was
all the world needed? Testbeds are today known to do GE to end
stations :)

/Loa

Kireeti Kompella wrote:
> Hi Loa,
> 
> On Fri, 26 Nov 2004, Loa Andersson wrote:
> 
> 
>>there seems to be a majority for doing L1VPN in ccamp, I don't
>>particular object, but remember the arguments when we placed the
>>L3VPN and L2VPN in the Internet Area.
> 
> 
> Thanks for articulating this -- I've been thinking about this as well.
> 
> 
>>The main argument was that the Internet Area deals with end-2-end
>>services over the Interent, thus VPNs belongs in the Internet Area.
>>
>>If we decides that L1VPN don't go together with L2/L3VPNs in the
>>Internet Area we should at least have some motivation for this.
>>What is it?  Is L1VPN not an end-2-end services or is it not an
>>Internet Service?
> 
> 
> I've come up with four reasons why CCAMP is a better venue for L1VPNs:
> 
> a) L1VPNs are definitely not an end-to-end service -- I don't think
>    we'll see end-hosts with OC-48s (or even fiber GE) and GMPLS
>    signaling any time soon.  However, it is clearly possible for end
>    hosts to connect to an L2 or L3VPN.
> b) L1VPNs are not necessarily an Internet service (well, for that
>    matter, neither are L2VPNs).
> c) Most of the work for L1VPNs is done -- starting a new WG for this
>    will hinder progress, and also expand work to fill out a whole WG.
>    The bulk of the work is documenting what we already have that works.
> d) L1VPNs are distinctly different from L2 and L3 VPNs -- in the
>    latter, the PEs do all the heavy lifting, and the CEs are then
>    immediately connected.  In L1VPNs, the PEs do discovery and
>    information exchange, but the *CEs* must do the signaling to set up
>    the (currently) desired CE topology.  To do the signaling, the CEs
>    must exchange information with the PEs.
> 
> This last part requires tight coordination with the CCAMP WG, both for
> signaling (GMPLS UNI), and also for information exchange (pretty much
> the same as for GMPLS inter-domain).  This is for me the most
> important reason why this work should be kept in CCAMP rather than
> creating up a new WG.
> 
> Kireeti.
> -------
> 
> 
> 

-- 
Loa Andersson

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

Delivery-date: Sat, 27 Nov 2004 22:57:25 +0000
content-class: urn:content-classes:message
Subject: RE: New charter
Date: Sat, 27 Nov 2004 22:56:58 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Scott....good remarks, a couple of observations below:

Scott wrote 27 November 2004 13:13

> On Fri, Nov 26, 2004 02:37:37PM +0100, Loa Andersson allegedly wrote:
> > All,
> >=20
> > there seems to be a majority for doing L1VPN in
> > ccamp, I don't particular object, but remember the arguments when we

> > placed the L3VPN and L2VPN in the Internet Area. The main argument=20
> > was that the Internet Area deals with end-2-end services
> > over the Interent, thus VPNs belongs in the
> > Internet Area.
> >=20
> > If we decides that L1VPN don't go together with
> > L2/L3VPNs in the Internet Area we should at least
> > have some motivation for this. What is it?
> > Is L1VPN not an end-2-end services or is it not
> > an Internet Service?
> >=20
> > /Loa
>=20
> Is it that L2 and L3 VPNs are services on top of the
> infrastructure provided by the network, but L1VPNs can=20
> allocate the infrastructure resources themselves?
NH=3D> I think we as an industry need to start to decoupling ourselves
from this L1/2/3 classification as it has no value.  Any network that
has addressing and routing functional components is a layer network (in
the obsolete/restricted OSI L3 meaning of 'network layer').  IP is a
layer network, and it belongs to the cl-ps mode...which is great.  FR,
ATM and MPLS are layer networks, and these all belong to the co-ps
mode...which is also great.  PDH, SDH and OTNs are also layer networks,
and these all belong to the co-cs mode...and this too is great.  But the
3 network modes are different and trying to apply a 1 size fits all
solution simply won't work.  Indeed, it is the modal differences that
are actually THE important bits, this is where the real value
lies.....so we should not knock this.  If folks want to classify layer
networks they should use these 3 modes and the G.805/809 methods of
describing them.  This is the only classification that makes any logical
and practical sense.

> L1VPNs=20
> aren't (necessarily) "over" anything?
NH=3D> To be accurate we can put any X (layer network/mode) over any Y
(layer network/mode).  Whether its makes real sense to do this (and/or
how many times such transitions should be allowed in some global
reference model) is another question.

>  In G.805-speak, unlike=20
> L2 and L3 VPNs, they aren't necessarily path layer networks.
NH=3D> Scott...when we create a layer network (any) the link connections
in that layer network are invariably formed/supported by trails (which
are end-end entities) in some server layer network.  In turn, the
link-connectines of these server layer trails are supported by even
lower level layer network trails.  This is a recursive behaviour until
we hit the duct.
=20
> It is an end-to-end service, but not necessarily an Internet=20
> service (the control of it is)?
NH=3D> I think some folks have a weird notion of what end-end actually
means. In a layer network end-end means between access points (which are
closely bound to trail termination points).  So one guys end-end network
is some other guys link-connection, ie a 'network builder service' for
example.  End-end is in the eye of the layer network beholder when we
talk of layer networks.  There are 2 end-stops of layer network
recursion however...the duct (obviously) and the customer end-system
applications (like voice, Email, whatever).  But between the application
and the duct there can, and are, many layer networks.

regards, Neil=20

Delivery-date: Sat, 27 Nov 2004 17:51:31 +0000
Date: Sat, 27 Nov 2004 09:48:43 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Scott W Brim <[email-masked]>
cc: Loa Andersson <[email-masked]>, [email-masked], Thomas Narten <[email-masked]>
Subject: Re: New charter

On Sat, 27 Nov 2004, Scott W Brim wrote:

> Is it that L2 and L3 VPNs are services on top of the infrastructure
> provided by the network, but L1VPNs can allocate the infrastructure
> resources themselves?

That's a good way of putting it.

> L1VPNs aren't (necessarily) "over" anything?  In G.805-speak, unlike
> L2 and L3 VPNs, they aren't necessarily path layer networks.  It is
> an end-to-end service, but

You'll have to define "end-to-end service" ...

> not necessarily an Internet service (the control of it is)?

Yes, that's also true.

Kireeti.
-------

Delivery-date: Sat, 27 Nov 2004 13:15:03 +0000
Date: Sat, 27 Nov 2004 08:12:47 -0500
From: Scott W Brim <[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: [email-masked], Thomas Narten <[email-masked]>, Kireeti Kompella <[email-masked]>
Subject: Re: New charter
Mail-Followup-To: Scott W Brim <[email-masked]>, Loa Andersson <[email-masked]>, [email-masked], Thomas Narten <[email-masked]>, Kireeti Kompella <[email-masked]>

On Fri, Nov 26, 2004 02:37:37PM +0100, Loa Andersson allegedly wrote:
> All,
> 
> there seems to be a majority for doing L1VPN in
> ccamp, I don't particular object, but remember the
> arguments when we placed the L3VPN and L2VPN in
> the Internet Area. The main argument was that
> the Internet Area deals with end-2-end services
> over the Interent, thus VPNs belongs in the
> Internet Area.
> 
> If we decides that L1VPN don't go together with
> L2/L3VPNs in the Internet Area we should at least
> have some motivation for this. What is it?
> Is L1VPN not an end-2-end services or is it not
> an Internet Service?
> 
> /Loa

Is it that L2 and L3 VPNs are services on top of the infrastructure
provided by the network, but L1VPNs can allocate the infrastructure
resources themselves?  L1VPNs aren't (necessarily) "over" anything?  In
G.805-speak, unlike L2 and L3 VPNs, they aren't necessarily path layer
networks.  It is an end-to-end service, but not necessarily an Internet
service (the control of it is)?

Delivery-date: Sat, 27 Nov 2004 03:14:28 +0000
Date: Fri, 26 Nov 2004 19:11:46 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Loa Andersson <[email-masked]>
cc: [email-masked], Thomas Narten <[email-masked]>
Subject: Re: New charter

Hi Loa,

On Fri, 26 Nov 2004, Loa Andersson wrote:

> there seems to be a majority for doing L1VPN in ccamp, I don't
> particular object, but remember the arguments when we placed the
> L3VPN and L2VPN in the Internet Area.

Thanks for articulating this -- I've been thinking about this as well.

> The main argument was that the Internet Area deals with end-2-end
> services over the Interent, thus VPNs belongs in the Internet Area.
>
> If we decides that L1VPN don't go together with L2/L3VPNs in the
> Internet Area we should at least have some motivation for this.
> What is it?  Is L1VPN not an end-2-end services or is it not an
> Internet Service?

I've come up with four reasons why CCAMP is a better venue for L1VPNs:

a) L1VPNs are definitely not an end-to-end service -- I don't think
   we'll see end-hosts with OC-48s (or even fiber GE) and GMPLS
   signaling any time soon.  However, it is clearly possible for end
   hosts to connect to an L2 or L3VPN.
b) L1VPNs are not necessarily an Internet service (well, for that
   matter, neither are L2VPNs).
c) Most of the work for L1VPNs is done -- starting a new WG for this
   will hinder progress, and also expand work to fill out a whole WG.
   The bulk of the work is documenting what we already have that works.
d) L1VPNs are distinctly different from L2 and L3 VPNs -- in the
   latter, the PEs do all the heavy lifting, and the CEs are then
   immediately connected.  In L1VPNs, the PEs do discovery and
   information exchange, but the *CEs* must do the signaling to set up
   the (currently) desired CE topology.  To do the signaling, the CEs
   must exchange information with the PEs.

This last part requires tight coordination with the CCAMP WG, both for
signaling (GMPLS UNI), and also for information exchange (pretty much
the same as for GMPLS inter-domain).  This is for me the most
important reason why this work should be kept in CCAMP rather than
creating up a new WG.

Kireeti.
-------

Delivery-date: Fri, 26 Nov 2004 13:41:22 +0000
Date: Fri, 26 Nov 2004 14:37:37 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked]
CC: Thomas Narten <[email-masked]>, Kireeti Kompella <[email-masked]>
Subject: Re: New charter

All,

there seems to be a majority for doing L1VPN in
ccamp, I don't particular object, but remember the
arguments when we placed the L3VPN and L2VPN in
the Internet Area. The main argument was that
the Internet Area deals with end-2-end services
over the Interent, thus VPNs belongs in the
Internet Area.

If we decides that L1VPN don't go together with
L2/L3VPNs in the Internet Area we should at least
have some motivation for this. What is it?
Is L1VPN not an end-2-end services or is it not
an Internet Service?

/Loa

>3a) should the IETF take on L1VPNs? 
> yes.
> 
> 
>>3b) if yes to 3a, should this be done in CCAMP?
> yes.
> 
> Yakov.
> 
> 
> 

-- 
Loa Andersson

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

Delivery-date: Fri, 26 Nov 2004 03:41:43 +0000
Date: Fri, 26 Nov 2004 12:39:10 +0900
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
From: Wataru Imajuku <[email-masked]>
Subject: Re: New charter

Hi, Kiretti and all

  I think most important issues are

1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3a) should the IETF take on L1VPNs?
3b) if yes to 3a, should this be done in CCAMP?
5) Control plane work
9) QoS control

Next important thing is
4) Waveband switching

  Also, I think we should address to scalability issues.
  Especially for restoration.

  But I'm neutral for following issues,
7) Deployment consi derations for GMPLS
8) PCE requirements

Best Regards,
Wataru

---------------------------------
Wataru Imajuku, Ph.D.
@NTT Network Innovation Labs.
TEL +81-46-859-4315
FAX +81-46-859-5541 

Delivery-date: Thu, 25 Nov 2004 20:23:27 +0000
To: Kireeti Kompella <[email-masked]>
cc: [email-masked]
Subject: Re: New charter 
Date: Thu, 25 Nov 2004 12:22:52 -0800
From: Yakov Rekhter <[email-masked]>

Kireeti,

> > If you have suggested charter updates, please send them to Adrian
> > and me.
> 
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
> 
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.

Top four:

> 1) MPLS-GMPLS migration

yes.

> 2) GMPLS interoperability issues

yes.

> 3a) should the IETF take on L1VPNs?

yes.

> 3b) if yes to 3a, should this be done in CCAMP?

yes.

Yakov.

Delivery-date: Thu, 25 Nov 2004 19:51:49 +0000
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, [email-masked], Bill Fenner <[email-masked]>, Scott Bradner <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Liaison to ITU-T Q14/15 - Comparison of LMP and ASON Discover y
Date: Thu, 25 Nov 2004 14:49:45 -0500

Dear Mr. Farrel,

Thank you for the Liaison Statement on Comparison of LMP and ASON Discovery. We appreciate the opportunity to provide input to the work. Q14/15 will address the LS in its upcoming meeting next week.

Regards,
Kam Lam, Q14/15 Rapporteur

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Thursday, November 25, 2004 9:09 AM
> To: Lam, Hing-Kam (Kam)
> Cc: 'Kireeti Kompella'; [email-masked]; Bill Fenner; Scott Bradner;
> [email-masked]; [email-masked]
> Subject: Liaison to ITU-T Q14/15 - Comparison of LMP and ASON 
> Discovery
> 
> 
> To:           Mr. Kam Lam, Rapporteur for Question 14 of 
> ITU-T Study Group 15.
> From:         Adrian Farrel and Kireeti Kompella
>               Co-chairs of the CCAMP Working Group of the IETF
> Cc:           Alex Zinin and Bill Fenner, Routing Area 
> Directors of the IETF
>               Scott Bradner, IETF/ITU-T Liaison Coordinator
> For:          Action
> Deadline:     15th December 2004
> Subject:      Comparison of LMP and ASON Discovery
> 
> Dear Mr. Lam,
> 
> The IETF's CCAMP Working Group has been working on a draft to 
> compare LMP as used in a
> GMPLS system with the concept of 'discovery' as expressed in 
> ASON. Many of the people
> actively working on this draft are participants in the ITU-T 
> study groups.
> 
> The abstract of this draft is as follows:
>    The Link Management Protocol (LMP) has been developed as part of
>    the Generalized MPLS (GMPLS) protocol suite to manage Traffic
>    Engineering (TE) links. The GMPLS control plane (routing and
>    signaling) uses TE links for establishing Label Switched Paths
>    (LSPs). This memo describes the relationship of the LMP procedures
>    to 'discovery' as defined in the International Telecommunication
>    Union (ITU), i.e. G.8080, G.7714, and G.7714.1, and on-going ITU-T
>    work. This document provides an overview of LMP in the context of
>    the ITU-T Automatically Switched Optical Networks (ASON) [G.8080]
>    and transport network [G.805] terminology and relates it to the
>    ITU-T discovery work to promote a common understanding for
>    progressing the work of IETF and ITU-T.
> 
> The current version of the draft can be found at
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport
-lmp-00.txt

The CCAMP working group intends to carry out a "Working Group Last Call" on this draft.
The Working Group would welcome input from SG15 on this work.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Delivery-date: Thu, 25 Nov 2004 16:29:43 +0000
From: "Marco Carugi" <[email-masked]>
To: [email-masked]
Cc: Kireeti Kompella <[email-masked]>
Subject: RE: New charter
Date: Thu, 25 Nov 2004 17:28:50 +0100

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_01C4D30B.D8BD66AE
Content-Type: text/plain

Hello Kireeti.

Top 4:

1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3) L1VPNs (in CCAMP)
8) PCE requirements

Regards, Marco

------_=_NextPart_001_01C4D30B.D8BD66AE
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.2">
<TITLE>RE: New charter</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hello Kireeti.</FONT>
</P>

<P><FONT SIZE=2>Top 4:</FONT>
</P>

<P><FONT SIZE=2>1) MPLS-GMPLS migration</FONT>
<BR><FONT SIZE=2>2) GMPLS interoperability issues</FONT>
<BR><FONT SIZE=2>3) L1VPNs (in CCAMP)</FONT>
<BR><FONT SIZE=2>8) PCE requirements</FONT>
</P>

<P><FONT SIZE=2>Regards, Marco</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4D30B.D8BD66AE--

Delivery-date: Thu, 25 Nov 2004 15:48:28 +0000
Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Subject: Re: New charter
Date: Thu, 25 Nov 2004 11:09:51 +0100

> 1) yes  MPLS-GMPLS migration
> 2) yes  GMPLS interoperability issues
> 3a) no should the IETF take on L1VPNs?
> 3b) no  if yes to 3a, should this be done in CCAMP?
> 4) no   Waveband switching
> 5) yes  Control plane work
> 6) no   Decoder ring for addresses
> 7) yes  Deployment considerations for GMPLS
> 8) no   PCE requirements
> 9) no   QoS control
> 

Tom Petch
NW Networks

Delivery-date: Thu, 25 Nov 2004 14:19:42 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lam, Hing-Kam (Kam)" <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>, "Scott Bradner" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Liaison to ITU-T Q14/15 - Comparison of LMP and ASON Discovery
Date: Thu, 25 Nov 2004 14:09:05 -0000

To:           Mr. Kam Lam, Rapporteur for Question 14 of ITU-T Study Group 15.
From:         Adrian Farrel and Kireeti Kompella
              Co-chairs of the CCAMP Working Group of the IETF
Cc:           Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
              Scott Bradner, IETF/ITU-T Liaison Coordinator
For:          Action
Deadline:     15th December 2004
Subject:      Comparison of LMP and ASON Discovery

Dear Mr. Lam,

The IETF's CCAMP Working Group has been working on a draft to compare LMP as used in a
GMPLS system with the concept of 'discovery' as expressed in ASON. Many of the people
actively working on this draft are participants in the ITU-T study groups.

The abstract of this draft is as follows:
   The Link Management Protocol (LMP) has been developed as part of
   the Generalized MPLS (GMPLS) protocol suite to manage Traffic
   Engineering (TE) links. The GMPLS control plane (routing and
   signaling) uses TE links for establishing Label Switched Paths
   (LSPs). This memo describes the relationship of the LMP procedures
   to 'discovery' as defined in the International Telecommunication
   Union (ITU), i.e. G.8080, G.7714, and G.7714.1, and on-going ITU-T
   work. This document provides an overview of LMP in the context of
   the ITU-T Automatically Switched Optical Networks (ASON) [G.8080]
   and transport network [G.805] terminology and relates it to the
   ITU-T discovery work to promote a common understanding for
   progressing the work of IETF and ITU-T.

The current version of the draft can be found at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-00.txt

The CCAMP working group intends to carry out a "Working Group Last Call" on this draft.
The Working Group would welcome input from SG15 on this work.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Delivery-date: Thu, 25 Nov 2004 14:19:34 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Working group last call on draft-ietf-ccamp-tranport-lmp-00.txt
Date: Thu, 25 Nov 2004 14:08:04 -0000

Hi,

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-transport-lmp-00.txt

The authors tell me that this draft is cooked.
There may be future changes in the ITU-T that would require to be reflected in this work,
but at the moment it is the opinion of the authors that the I-D reflects the current set
of consented recommendations within the ITU-T.

I am liaising the current version of the I-D to ITU-T Study Group 15, Question 14 that has
responsibility for ASON Discovery, and I hope that they will spot any discrepancies that
may exist.

This email begins an elongated WG last call that will end on December 17th at noon GMT.
The unusually long last call period is to allow the ITU-T to return its comments.

Please review and comment on the draft with a view to accuracy, clarity and usability.

Thanks,
Adrian

Envelope-to: [email-masked]
Delivery-date: Thu, 25 Nov 2004 13:56:12 +0000
Message-ID: <[email-masked]>
From: "Hamid Ould-Brahim" <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: RE: New charter
Date: Thu, 25 Nov 2004 08:54:34 -0500

Top 4:

3) L1VPNs (in CCAMP)
8) PCE requirements
1) MPLS-GMPLS migration
2) GMPLS interoperability issues

Hamid.

Delivery-date: Thu, 25 Nov 2004 10:39:40 +0000
Date: Thu, 25 Nov 2004 19:40:09 +0900
From: Tomohiro Otani <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: Re: New charter

Hi Kireeti,

I support them rechartered in CCAMP WG and am personally
interested in MPLS/GMPLS migration and deployment consideration
of GMPLS to accelerate actual GMPLS deployment.

CCAMP WG is suitable for discussing about L1VPN.

With best regards,

tomo

----------------------------------
Tomohiro Otani
KDDI R&D Laboratories, Inc.
----------------------------------

Kireeti Kompella wrote:

>On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>
>> If you have suggested charter updates, please send them to Adrian
>> and me.
>
>Thanks all for your input.  I have the following items; for each,
>please say "Yes" (should be added to CCAMP charter), "No" (should not
>be added) or "-" (don't care).  I'll remind you once again that not
>all items will make it onto the new charter.
>
>Please keep this subject line (simply reply to this mail).  The
>deadline is Friday Dec 3, 17:00 PST.
>
>1) MPLS-GMPLS migration
>2) GMPLS interoperability issues
>3a) should the IETF take on L1VPNs?
>3b) if yes to 3a, should this be done in CCAMP?
>4) Waveband switching
>5) Control plane work
>6) Decoder ring for addresses
>7) Deployment considerations for GMPLS
>8) PCE requirements
>9) QoS control
>
>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>
>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>
>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>
>5) Control plane work
>	resiliency
>	graceful shutdown
>
>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>
>  
>

Delivery-date: Thu, 25 Nov 2004 10:39:18 +0000
Date: Thu, 25 Nov 2004 19:38:50 +0900
From: Tomohiro Otani <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Cc: [email-masked]
Subject: Re: New charter

Hi Kireeti,

I support them rechartered in CCAMP WG and am personally
intereted in MPLS/GMPLS migration and deployment consideration
of GMPLS to accelarate actualGMPLS deployment.

CCAMP WG is suitable for discussing about L1VPN.

With best regards,

tomo

----------------------------------
Tomohiro Otani
KDDI R&D Laboratories, Inc.
----------------------------------

Kireeti Kompella wrote:

>On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>
>> If you have suggested charter updates, please send them to Adrian
>> and me.
>
>Thanks all for your input.  I have the following items; for each,
>please say "Yes" (should be added to CCAMP charter), "No" (should not
>be added) or "-" (don't care).  I'll remind you once again that not
>all items will make it onto the new charter.
>
>Please keep this subject line (simply reply to this mail).  The
>deadline is Friday Dec 3, 17:00 PST.
>
>1) MPLS-GMPLS migration
>2) GMPLS interoperability issues
>3a) should the IETF take on L1VPNs?
>3b) if yes to 3a, should this be done in CCAMP?
>4) Waveband switching
>5) Control plane work
>6) Decoder ring for addresses
>7) Deployment considerations for GMPLS
>8) PCE requirements
>9) QoS control
>
>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>
>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>
>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>
>5) Control plane work
>	resiliency
>	graceful shutdown
>
>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>
>  
>

Delivery-date: Thu, 25 Nov 2004 08:55:59 +0000
To: "Ong, Lyndon" <[email-masked]>
Cc: "'Igor Bryskin'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: [email-masked]
Subject: RE: RS-DT Wrap-Up Statements
Date: Thu, 25 Nov 2004 09:55:20 +0100

Delivery-date: Thu, 25 Nov 2004 08:24:18 +0000
Date: Thu, 25 Nov 2004 17:22:51 +0900
From: Eiji Oki <[email-masked]>
To: Kireeti Kompella <[email-masked]>
Subject: Re: New charter
Cc: [email-masked]

Hi Kireeti and all, 

Most important items: 
1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3) L1VPNs in CCAMP
8) PCE requirements

Next important items: 
7) Deployment considerations for GMPLS

Thank you.
Eiji

On Tue, 23 Nov 2004 22:22:19 -0800 (PST)
Kireeti Kompella <[email-masked]> wrote:

> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
> 
> > If you have suggested charter updates, please send them to Adrian
> > and me.
> 
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
> 
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
> 
> 1) MPLS-GMPLS migration
> 2) GMPLS interoperability issues
> 3a) should the IETF take on L1VPNs?
> 3b) if yes to 3a, should this be done in CCAMP?
> 4) Waveband switching
> 5) Control plane work
> 6) Decoder ring for addresses
> 7) Deployment considerations for GMPLS
> 8) PCE requirements
> 9) QoS control
> 
> A rough idea of what each of the above entails follows.
> 
> 1) MPLS-GMPLS migration
> 	implementation shift from "MPLS" objects to "GMPLS" objects
> 	BCP on deployment migration for the same
> 
> 2) GMPLS interoperability issues
> 	what addresses to use where
> 	nits/clarifications of the specs
> 	guidelines for path computation & constraints
> 	survay
> 
> 3) L1VPN work items
> 	identify protocol extensions needed
> 	state what can already be done with what we have
> 	do the actual protocol work for requirements that are not met
> 	liaisons to SG13 as needed
> 
> 5) Control plane work
> 	resiliency
> 	graceful shutdown
> 
> 6) Decoder ring for addresses
> 	for each address field, identify its nature and ITU equivalent
> 	(may overlap with part of (2))
> 
> 
> 4, 7-9 are obvious or have been elaborated on the mailing list.
> 
> Kireeti.
> -------
> 
> PS: The topic of GTTP has carefully been avoided.  More later.

Delivery-date: Thu, 25 Nov 2004 04:44:59 +0000
Date: Thu, 25 Nov 2004 13:44:29 +0900
To: Kireeti Kompella <[email-masked]>
From: Tomonori TAKEDA <[email-masked]>
Subject: Re: New charter
Cc: [email-masked]

Hi,

IMO, all items are important, but here is my vote.

Top four:
1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3) L1VPNs (and yes in CCAMP)
8) PCE requirements

Next:
5) Control plane work

At 08:21 04/11/24 -0800, Kireeti Kompella wrote:
>On Wed, 24 Nov 2004, Loa Andersson wrote:
>
> > not entirely happy to let the IESG do the pruning,
>
>Okay, Loa -- you are right.
>
>All: instead of Yes/No, can you pick the four most important items
>from your point of view?  Thanks!
>
>(To those who already replied, sorry to make you do this again!)
>
>Kireeti.
>-------

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: +81-422-59-7434

Delivery-date: Thu, 25 Nov 2004 02:06:37 +0000
Date: Thu, 25 Nov 2004 11:05:39 +0900
From: Kohei Shiomoto <[email-masked]>
Organization: NTT
To: Kireeti Kompella <[email-masked]>
CC: [email-masked]
Subject: Re: New charter

Hi Kireeti and all,

All items look important but I would propose the following items.
----- top four ----------
1+7 (they are related)
2+6* (they seem related)
3 (within CCAMP)
8
*note 5 seems related to 2+6
----- next ---------------
9 if 8 is done in PCE-WG.

-------------------
1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3a) should the IETF take on L1VPNs?
3b) if yes to 3a, should this be done in CCAMP?
4) Waveband switching
5) Control plane work
6) Decoder ring for addresses
7) Deployment considerations for GMPLS
8) PCE requirements
9) QoS control

Kind regards

---
Kohei Shiomoto, NTT

Kireeti Kompella wrote:

>On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>
>  
>
>>If you have suggested charter updates, please send them to Adrian
>>and me.
>>    
>>
>
>Thanks all for your input.  I have the following items; for each,
>please say "Yes" (should be added to CCAMP charter), "No" (should not
>be added) or "-" (don't care).  I'll remind you once again that not
>all items will make it onto the new charter.
>
>Please keep this subject line (simply reply to this mail).  The
>deadline is Friday Dec 3, 17:00 PST.
>
>1) MPLS-GMPLS migration
>2) GMPLS interoperability issues
>3a) should the IETF take on L1VPNs?
>3b) if yes to 3a, should this be done in CCAMP?
>4) Waveband switching
>5) Control plane work
>6) Decoder ring for addresses
>7) Deployment considerations for GMPLS
>8) PCE requirements
>9) QoS control
>
>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>
>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>
>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>
>5) Control plane work
>	resiliency
>	graceful shutdown
>
>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>
>  
>

-- 
Kohei Shiomoto, Ph.D
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone +81 422 59 4402    Fax +81 422 59 4549

Delivery-date: Thu, 25 Nov 2004 01:11:31 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'Igor Bryskin' <[email-masked]>, [email-masked],  [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: RS-DT Wrap-Up Statements
Date: Wed, 24 Nov 2004 20:16:42 -0500

Hi Igor,

I support you on both points, and I believe
Dimitri's writeup is intended to allow the
separation of routing and signaling controllers.

The issue of the router ID or link ID being 
routable seems to be ingrained in 3477, at
the same time I am also uncomfortable about
this requirement, if the transport node
does not support PSC.

Cheers,

Lyndon

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: Wednesday, November 24, 2004 8:29 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: RS-DT Wrap-Up Statements

dimitri, see in-line

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 24, 2004 11:02 AM
Subject: Re: RS-DT Wrap-Up Statements

> igor - see in-line:
>
> Igor Bryskin wrote:
>
> > Dimitri,
> >
> > Do you think it is reasonable/practical to separate routing controller
from
> > signaling controller and consider scenarios such as a single routing
> > controller manages (provides advertisements) for several transport nodes
> > with each of the latter having a dedicated signaling controller for TE
> > tunnel provisioning?
>
> this is a "functional" separation - in the basic association Si <-> Ri
> <-> i, we retrieve the canonical LSR (note i will change the word "can"
> by "may" in the below informational statement)

IB>> Separation could be physical, not just functional. Consider, for
instance, a transport network built of WXCs that do not have own control
plane. In this case a routing controller managing one or several such WXCs
could advertise their resources, while separate signaling controllers with
the help of PCE(s) could compute and signal TE paths for them.

>
> > Also, how in your opinion a signaling controller knows which address to
send
> > Path message for the next hop along the path.
> > Possible options:
> > a) ID of a numbered link is routable or RouterID in unnumbered ERO
> > sub-object (which is transport node ID) is routable;
>
> several points here:
> 1. we refer to a "TE Router_ID" per RFC 3477 recommendation
> 2. we should indicate these "identifiers" are TE reachable in the scope
>     of the covered application
> 3. even if relevant the scope of this is related to routing
>
> > b) necessary binding (neighbor linkID=> neighbor signaling address,
neighbor
> > nodeID=> neighbor signaling address) is provided via LMP
>
> in the case of multiple association an additional information is
> required that falls beyond the scope of routing and that could be
> achieved using LMP
>

IB>> Personally, I don't like the assumption that transport node IDs and
linkIDs of numbered links are routable (especially in the context of non-PSC
networks) and prefer relying on LMP or some other neighbor auto--discovery
mechanism.

Igor

> hope this clarifies,
> - thanks.
> > Thanks,
> > Igor

Delivery-date: Thu, 25 Nov 2004 00:25:37 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>
Cc: "'Brungard, Deborah A, ALABS'" <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Second incoming communication from the OIF
Date: Wed, 24 Nov 2004 19:30:45 -0500

Hi Kireeti,

I respect your opinion, but I suspect that the changes that
you would ask from ITU would amount to dropping G.7713.2
entirely.  It would probably be difficult to get agreement
on this (but that's up to ITU in any case).

There has certainly been an attempt to work cooperatively
in the routing protocol area, and hopefully this will be
mutually productive.  I wouldn't be overly pessimistic 
about convergence in the signaling area, although it's
obviously harder since documents have been approved and
implementations done and tested.

Cheers and Happy Thanksgiving,

Lyndon

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Wednesday, November 24, 2004 8:35 AM
To: Ong, Lyndon
Cc: 'Brungard, Deborah A, ALABS'; Adrian Farrel; [email-masked]
Subject: RE: Second incoming communication from the OIF

Hi Lyndon,

On Tue, 23 Nov 2004, Ong, Lyndon wrote:

> I'm reading into your email a concern with the use of "ASON" in the title
> of the project.  The interworking project is likely to cover ITU-T
> G.7713.2 as the ASON signaling standard at the UNI and E-NNI, taking into
> account experiences that members have had implementing and testing
> protocols.

Our concern is with the project as a whole.  There are several
deficiencies in G.7713.2 and the OIF UNI; these have been pointed out
many times by CCAMP, and liaised to the ITU, but we are not aware of
any significant changes that have been made to the OIF UNI or to
G.7713.2 to address these problems.  In view of this, it seems
premature to expend effort attempting to build networks that interwork
the OIF UNI with GMPLS since future work to fix the OIF UNI is likely
to have considerable impact on any interworking specifications.  The
real problem (namely, the ASON signaling requirements as well as a UNI
and E-NNI) have also been addressed by CCAMP; to continue work on
G.7713.2, and in fact to use it as the ASON signaling standard at the
UNI and E-NNI seems to us very shortsighted indeed.

The communication says, "We expect the OIF, ITU-T and IETF will
continue to work together to minimize or eliminate differences between
control plane signaling protocols."

Certainly a laudable goal.  Persisting with G.7713.2 and the OIF UNI
without any willingness to adapt these specifications clashes with
this goal.  Working together implies converging -- the IETF took a big
step in this direction by acceding to the ASON signaing requirements
as stated; it doesn't seem that the ITU-T or OIF are willing to take
similar steps.

> As you note, GMPLS is being extended to support ASON
> as well.  It sounds reasonable to comment that some clarification of
> the project definition may be helpful.

And very importantly, to state the need for more work on this front,
rather than beginning work on convergence at once.

> This also raises a good point about GMPLS continuing to evolve beyond
> RFC 3473.  As the work on GMPLS extensions to support ASON functionality
> continues to develop, this will need to be taken into account.

At what stage?  It seems that instead of converging, the object seems
to develop a full suite of competing protocols, and only then take the
GMPLS suite into account.

Kireeti.
-------

Delivery-date: Wed, 24 Nov 2004 23:43:29 +0000
From: "Ong, Lyndon" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: New charter
Date: Wed, 24 Nov 2004 18:48:44 -0500

Hmm, following the current procedure I would vote for:

(2) GMPLS interop issues
(6) address decoder ring
(8) PCE requirements
(3) L1 VPN

in that order, noting that (6) and (2) are closely related.

Cheers,

Lyndon

Delivery-date: Wed, 24 Nov 2004 23:28:02 +0000
From: "Ong, Lyndon" <[email-masked]>
To: 'Adrian Farrel' <[email-masked]>
Cc: [email-masked]
Subject: RE: Second incoming communication from the OIF
Date: Wed, 24 Nov 2004 18:32:26 -0500

Hi Adrian,

These would be very good comments back to OIF.  I believe the
main interest has been G.7713.2 and RFC 3473, but the project
proposal (as you might expect) is worded broadly so that other
work might be done if there is sufficient interest.

Cheers,

Lyndon

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Wednesday, November 24, 2004 9:59 AM
To: Ong, Lyndon
Cc: [email-masked]
Subject: Re: Second incoming communication from the OIF

Lyndon,
On another, but related, thread from this communication...

Do you know whether
  The project will result in a design guideline document to assist vendors
  and carriers in optical networks where signaling interworking is required
  between OIF/ITU-T ASON and GMPLS RSVP-TE.
refers to just a subset of the ITU-T ASON or to the whole of it?

For example, there is a basic discrepancy between (for example) G.7713.2 and
G.7713.3 in
terms of how Call setup is managed. Since the architecture is intended to be
entirely
abstract, the initiating UNI-C cannot know whether the responding UNI-C
expects to see
independent or piggy-backed Call setup. This same issue applies at E-NNI
reference points.

Although it is possible to conceive of ways of managing this type of problem
within
network nodes (for example, at the UNI-N) I should think that a basic
requirement before
documenting interworking between OIF/ITU-T ASON and GMPLS RSVP-TE is to
document
interworking between OIF and ITU-T ASON.

Thanks,
Adrian

Delivery-date: Wed, 24 Nov 2004 19:24:19 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Subject: Re: New charter
Date: Wed, 24 Nov 2004 14:23:58 -0500

Four most important:
1), 3), 5) and 8)

Next two:
2) and 7)

Igor

----- Original Message ----- 
From: "Kireeti Kompella" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 24, 2004 1:22 AM
Subject: New charter

> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
> 
> > If you have suggested charter updates, please send them to Adrian
> > and me.
> 
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
> 
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
> 
> 1) MPLS-GMPLS migration
> 2) GMPLS interoperability issues
> 3a) should the IETF take on L1VPNs?
> 3b) if yes to 3a, should this be done in CCAMP?
> 4) Waveband switching
> 5) Control plane work
> 6) Decoder ring for addresses
> 7) Deployment considerations for GMPLS
> 8) PCE requirements
> 9) QoS control
> 
> A rough idea of what each of the above entails follows.
> 
> 1) MPLS-GMPLS migration
> implementation shift from "MPLS" objects to "GMPLS" objects
> BCP on deployment migration for the same
> 
> 2) GMPLS interoperability issues
> what addresses to use where
> nits/clarifications of the specs
> guidelines for path computation & constraints
> survay
> 
> 3) L1VPN work items
> identify protocol extensions needed
> state what can already be done with what we have
> do the actual protocol work for requirements that are not met
> liaisons to SG13 as needed
> 
> 5) Control plane work
> resiliency
> graceful shutdown
> 
> 6) Decoder ring for addresses
> for each address field, identify its nature and ITU equivalent
> (may overlap with part of (2))
> 
> 
> 4, 7-9 are obvious or have been elaborated on the mailing list.
> 
> Kireeti.
> -------
> 
> PS: The topic of GTTP has carefully been avoided.  More later.
> 

Delivery-date: Wed, 24 Nov 2004 19:16:50 +0000
content-class: urn:content-classes:message
Subject: RE: New charter
Date: Wed, 24 Nov 2004 11:03:19 -0600
From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>

> All: instead of Yes/No, can you pick the four most important items
> from your point of view?

Top 4:
1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3) L1VPNs (in CCAMP)
8) PCE requirements

Thanks,
Jerry

Delivery-date: Wed, 24 Nov 2004 18:38:26 +0000
Date: Wed, 24 Nov 2004 18:46:40 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel OND
CC: [email-masked]
Subject: Re: New charter

Hi Kireeti,

>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>  
>
yes

>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>  
>
yes

>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>  
>
yes

>5) Control plane work
>	resiliency
>	graceful shutdown
yes

>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>  
>
-

>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>  
>

Delivery-date: Wed, 24 Nov 2004 18:37:21 +0000
Date: Wed, 24 Nov 2004 19:37:09 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To:  [email-masked],  [email-masked]
CC: Kireeti Kompella <[email-masked]>,  [email-masked]
Subject: Re: New charter

all items have their importance - but as there is a poll for the most 
urgent items:

1. 1) + 2) + 7) - all related(*)
2. 8)
3. 9)
4. 3a) (and yes in CCAMP)

note: 5) will follow sooner or later

dimitri papadimitriou wrote:

> hi kireeti,
> 
>  > 1) MPLS-GMPLS migration
> 
> yes
> 
>  > 2) GMPLS interoperability issues
> 
> yes
> 
>  > 3a) should the IETF take on L1VPNs?
> 
> yes
> 
>  > 3b) if yes to 3a, should this be done in CCAMP?
> 
> as first option (note: with the current standpoint, could this done 
> elsewhere ?)
> 
>  > 4) Waveband switching
> 
> yes (note: need more support as rather limited since so far)
> 
>  > 5) Control plane work
> 
> yes ("document" CP resiliency and GS)
> 
>  > 6) Decoder ring for addresses
> 
> part of this work is in (2) and other should be part of the ongoing ASON 
> work
> 
>  > 7) Deployment considerations for GMPLS
> 
> is this an embryon of "gmplsops" ? in favor
> 
>  > 8) PCE requirements
> 
> yes
> 
>  > 9) QoS control
> 
> yes
> 
> ---
> 
> Kireeti Kompella wrote:
> 
>> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>>
>>
>>> If you have suggested charter updates, please send them to Adrian
>>> and me.
>>
>>
>>
>> Thanks all for your input.  I have the following items; for each,
>> please say "Yes" (should be added to CCAMP charter), "No" (should not
>> be added) or "-" (don't care).  I'll remind you once again that not
>> all items will make it onto the new charter.
>>
>> Please keep this subject line (simply reply to this mail).  The
>> deadline is Friday Dec 3, 17:00 PST.
>>
>> 1) MPLS-GMPLS migration
>> 2) GMPLS interoperability issues
>> 3a) should the IETF take on L1VPNs?
>> 3b) if yes to 3a, should this be done in CCAMP?
>> 4) Waveband switching
>> 5) Control plane work
>> 6) Decoder ring for addresses
>> 7) Deployment considerations for GMPLS
>> 8) PCE requirements
>> 9) QoS control
>>
>> A rough idea of what each of the above entails follows.
>>
>> 1) MPLS-GMPLS migration
>>     implementation shift from "MPLS" objects to "GMPLS" objects
>>     BCP on deployment migration for the same
>>
>> 2) GMPLS interoperability issues
>>     what addresses to use where
>>     nits/clarifications of the specs
>>     guidelines for path computation & constraints
>>     survay
>>
>> 3) L1VPN work items
>>     identify protocol extensions needed
>>     state what can already be done with what we have
>>     do the actual protocol work for requirements that are not met
>>     liaisons to SG13 as needed
>>
>> 5) Control plane work
>>     resiliency
>>     graceful shutdown
>>
>> 6) Decoder ring for addresses
>>     for each address field, identify its nature and ITU equivalent
>>     (may overlap with part of (2))
>>
>>
>> 4, 7-9 are obvious or have been elaborated on the mailing list.
>>
>> Kireeti.
>> -------
>>
>> PS: The topic of GTTP has carefully been avoided.  More later.
>>
>>
>> .
>>
> 

Delivery-date: Wed, 24 Nov 2004 18:34:34 +0000
Date: Wed, 24 Nov 2004 19:32:08 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Igor Bryskin <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: RS-DT Wrap-Up Statements

igor,

>>>Do you think it is reasonable/practical to separate routing controller
>>>from 
>>>signaling controller and consider scenarios such as a single routing
>>>controller manages (provides advertisements) for several transport nodes
>>>with each of the latter having a dedicated signaling controller for TE
>>>tunnel provisioning?
>>
>>this is a "functional" separation - in the basic association Si <-> Ri
>><-> i, we retrieve the canonical LSR (note i will change the word "can"
>>by "may" in the below informational statement)
> 
> IB>> Separation could be physical, not just functional. Consider, for
> instance, a transport network built of WXCs that do not have own control
> plane. In this case a routing controller managing one or several such WXCs
> could advertise their resources, while separate signaling controllers with
> the help of PCE(s) could compute and signal TE paths for them.

there is a difference between functionally separate Si from Ri and 
physically separate the RDB from the path computation function (i am not 
covering the latter - per scope of the document) - the document covers 
routing information exchange between Ri (over routing adjacencies)

>>>Also, how in your opinion a signaling controller knows which address to
> 
> send
> 
>>>Path message for the next hop along the path.
>>>Possible options:
>>>a) ID of a numbered link is routable or RouterID in unnumbered ERO
>>>sub-object (which is transport node ID) is routable;
>>
>>several points here:
>>1. we refer to a "TE Router_ID" per RFC 3477 recommendation
>>2. we should indicate these "identifiers" are TE reachable in the scope
>>    of the covered application
>>3. even if relevant the scope of this is related to routing
>>
>>
>>>b) necessary binding (neighbor linkID=> neighbor signaling address,
> 
> neighbor
> 
>>>nodeID=> neighbor signaling address) is provided via LMP
>>
>>in the case of multiple association an additional information is
>>required that falls beyond the scope of routing and that could be
>>achieved using LMP
>> 
> IB>> Personally, I don't like the assumption that transport node IDs and
> linkIDs of numbered links are routable (especially in the context of non-PSC
> networks) and prefer relying on LMP or some other neighbor auto--discovery
> mechanism.

example: if you take gmpls-overlay that mentions "An edge-node is 
identified by either a single IP address representing its Node-ID, or by 
one or more numbered TE links that connect the edge-node to the core- 
nodes." there is nothing specifically different here compared to this 
approach

> Igor
> 
> 
>>hope this clarifies,
>>- thanks.
>>
>>
>>>Thanks,
>>>Igor
>>>
>>>
>>>----- Original Message ----- 
>>>From: "dimitri papadimitriou" <[email-masked]>
>>>To: <[email-masked]>
>>>Sent: Wednesday, November 24, 2004 4:25 AM
>>>Subject: RS-DT Wrap-Up Statements
>>>
>>>
>>>
>>>
>>>>folks -
>>>>
>>>>The initial evaluation phase of existing routing protocols required
>>>>definition of a common pattern. The definition of this pattern last
>>>>until beginning of november (input from several parties) now that pieces
>>>>are in place needs to move a step further.
>>>>
>>>>The evaluation document will be issued by end-november to close this
>>>>first phase. The content of this document will be articulated around the
>>>>below terminology, scenarios and features.
>>>>
>>>>1. Terminology:
>>>>--------------
>>>>
>>>>- Pi is a physical node (bearer/data/transport plane) node
>>>>- Li is a logical control plane identifier that is associated to a
>>>>  single data plane (abstract) node
>>>>  Li = logical node id or "TE router id" i.e. for
>>>>  . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
>>>>  . RFC 3784: Traffic Engineering Router ID TLV (Type 134)
>>>>- Ri is a control plane "router" e.g. (advertising) Router_ID i.e.
>>>>  . RFC 2328: Router ID (32-bit)
>>>>  . RFC 1195: IS-IS System ID (48-bit)
>>>>
>>>>Note: in the below Figure 1.
>>>>- R3 represents an LSR with all components collocated.
>>>>- R2 shows how the "router" component may be disjoint from the node
>>>>- R1 shows how a single "router" may manage multiple nodes
>>>>
>>>>The Router_ID (represented by Ri) does not enter into the identification
>>>>of the logical entities representing the data plane resources such as
>>>>links. The Routing DataBase (RDB) is associated to the Ri.
>>>>
>>>>Note: the "signaling controller" i.e. the control plane entity that
>>>>processes the signaling messages (referred to as Si) is not represented
>>>>in these Figures. Multiple signalling controllers can be associated to
>>>>one Ri and make use of the path computation function associated to the
> 
> Ri.
> 
>>>>2. Mechanisms:
>>>>-------------
>>>>
>>>>Focus is on routing information exchange between Ri entities (through
>>>>routing adjacencies) within single hierarchical level. Routing
>>>>information mapping between levels may require specific guidelines.
>>>>
>>>>The control plane does not transport Pi information as these are data
>>>>plane addresses for which the the Li/Pi mapping is kept (link) local -
>>>>see for instance the transport LMP document where such exchange is
>>>>described. Example: the transport plane identifier is the Pi (the
>>>>identifier assigned to the physical element) be for instance
>>>>"666B.F999.AF10.222C", the control plane identifier is the Li (the
>>>>identifier assigned by the control plane), be for instance "1.1.1.1".
>>>>The control plane exchanges the control plane identifier information but
>>>>not the transport plane identifier information (i.e. not
>>>>"666B.F999.AF10.222C" but only "1.1.1.1"), The mapping Li/Pi is kept
>>>>local. So, when the Si receives a control plane message requesting the
>>>>use of "1.1.1.1", Si knows locally that this information refers to the
>>>>data plane entity identified by the transport plane identifier
>>>>"666B.F999.AF10.222C".
>>>>
>>>>The control plane carries:
>>>>1) its view of the data plane link end-points and other link connection
>>>>end-points - note: advertisement of reachability can be achieved using
>>>>the techniques described in
>>
>>><http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt>
>>>
>>>>2) the identifiers scoped by the Li's i.e. we speak about an associated
>>>>IPv4/IPv6 addressing space;
>>>>
>>>>Evalution Scenarios:
>>>>-------------------
>>>>
>>>>The scenarios are the following: resp. case 1), 2) and 3)
>>>>
>>>>             -------------------     ------
>>>>            |R1                 |   |R2     |
>>>>            |                   |   |       |    ------
>>>>            |  L1    L2    L3   |   |   L4  |   |R3    |
>>>>            |   :     :     :   |   |   :   |   |      |
>>>>            |   :     :     :   |   |   :   |   |  L5  |
>>>>Control      ---+-----+-----+---     ---+---    |   :  |
>>>>Plane           :     :     :           :       |   :  |
>>>>----------------+-----+-----+-----------+-------+---+--+-
>>>>Data            :     :     :           :       |   :  |
>>>>Plane          --     :    --          --       |  --  |
>>>>          ----|P1|--------|P3|--------|P4|------+-|P5|-+-
>>>>               -- \   :  / --          --       |  --  |
>>>>                   \ -- /                       |      |
>>>>                    |P2|                         ------
>>>>                     --
>>>>
>>>>case 1) as represented either direct links between edges or "logical
>>>>links" as per below figure (or any combination of them)
>>>>
>>>>                ------                        ------
>>>>               |      |                      |      |
>>>>               |  L1  |                      |  L2  |
>>>>               |  :   |                      |  :   |
>>>>               |  : R1|                      |  : R2|
>>>>Control Plane   --+---                        --+---
>>>>Elements          :                             :
>>>>------------------+-----------------------------+------------------
>>>>Data Plane        :                             :
>>>>Elements          :                             :
>>>>              ----+-----------------------------+-----
>>>>             |    :                             :     |
>>>>             |   ---            ---            ---    |
>>>>             |  |   |----------| P |----------|   |   |
>>>>          ---+--|   |           ---           |   |---+---
>>>>             |  |   |                         |   |   |
>>>>             |  | P1|-------------------------| P2|   |
>>>>             |   ---                           ---    |
>>>>              ----------------------------------------
>>>>
>>>>Another case is constituted by the Abstract Node as represented in the
>>>>below figure. There is no internal structure associated to the abstract
>>>>node.
>>>>
>>>>                    --------------
>>>>                   |R4            |
>>>>                   |              |
>>>>                   |      L6      |
>>>>                   |       :      |
>>>>                   |    ......    |
>>>>                    ---:------:---
>>>>Control Plane          :      :
>>>>                +------+------+------+
>>>>Data Plane             :      :
>>>>                    ---:------:---
>>>>                   |P8 :      :   |
>>>>                   |  --      --  |
>>>>                 --+-|P |----|P |-+--
>>>>                   |  --      --  |
>>>>                    --------------
>>>>
>>>>Note: base scenarios (being not combinations or decomposition of
>>>>entities) can further complete this set
>>>>
>>>>4. Specific Considerations
>>>>   -----------------------
>>>>
>>>>Representation of bandwidth requires further analysis i.e. GMPLS Routing
>>>>defines an Interface Switching Capability Descriptor (ISCD) that
>>>>delivers information about the (maximum/minimum) bandwidth per priority
>>>>an LSP can make use of. In the ASON context, other representations are
>>>>possible, e.g. in terms of a set of tuples <signal_type; number of
>>>>unallocated timeslots>. The latter also may require definition of
>>>>additional signal types (from those defined in RFC 3496) to represent
>>>>contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64,
>>>
>>>256.
>>>
>>>
>>>>The GMPLS routing method proposed in GMPLS Routing is the most
>>>>straightforward without requiring any bandwidth accounting change from
>>>>an LSR perspective. However, it introduces some lost of information.
>>>>This lost of information affects the number of signals that can be used
>>>>but not the range they cover. On the other hand, if additional
>>>>technology specific information (such as capabilities) are advertised a
>>>>finer grained resource countdown and accounting can be performed
>>>>allowing for network wide resource allocation in Sonet/SDH environments.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>
> 
> 
> 
> .
> 

Delivery-date: Wed, 24 Nov 2004 18:34:26 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Second incoming communication from the OIF
Date: Wed, 24 Nov 2004 17:59:28 -0000

Lyndon,
On another, but related, thread from this communication...

Do you know whether
  The project will result in a design guideline document to assist vendors
  and carriers in optical networks where signaling interworking is required
  between OIF/ITU-T ASON and GMPLS RSVP-TE.
refers to just a subset of the ITU-T ASON or to the whole of it?

For example, there is a basic discrepancy between (for example) G.7713.2 and G.7713.3 in
terms of how Call setup is managed. Since the architecture is intended to be entirely
abstract, the initiating UNI-C cannot know whether the responding UNI-C expects to see
independent or piggy-backed Call setup. This same issue applies at E-NNI reference points.

Although it is possible to conceive of ways of managing this type of problem within
network nodes (for example, at the UNI-N) I should think that a basic requirement before
documenting interworking between OIF/ITU-T ASON and GMPLS RSVP-TE is to document
interworking between OIF and ITU-T ASON.

Thanks,
Adrian
----- Original Message ----- 
From: "Kireeti Kompella" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>
Cc: "'Brungard, Deborah A, ALABS'" <[email-masked]>; "Adrian Farrel"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, November 24, 2004 4:34 PM
Subject: RE: Second incoming communication from the OIF

> Hi Lyndon,
>
> On Tue, 23 Nov 2004, Ong, Lyndon wrote:
>
> > I'm reading into your email a concern with the use of "ASON" in the title
> > of the project.  The interworking project is likely to cover ITU-T
> > G.7713.2 as the ASON signaling standard at the UNI and E-NNI, taking into
> > account experiences that members have had implementing and testing
> > protocols.
>
> Our concern is with the project as a whole.  There are several
> deficiencies in G.7713.2 and the OIF UNI; these have been pointed out
> many times by CCAMP, and liaised to the ITU, but we are not aware of
> any significant changes that have been made to the OIF UNI or to
> G.7713.2 to address these problems.  In view of this, it seems
> premature to expend effort attempting to build networks that interwork
> the OIF UNI with GMPLS since future work to fix the OIF UNI is likely
> to have considerable impact on any interworking specifications.  The
> real problem (namely, the ASON signaling requirements as well as a UNI
> and E-NNI) have also been addressed by CCAMP; to continue work on
> G.7713.2, and in fact to use it as the ASON signaling standard at the
> UNI and E-NNI seems to us very shortsighted indeed.
>
> The communication says, "We expect the OIF, ITU-T and IETF will
> continue to work together to minimize or eliminate differences between
> control plane signaling protocols."
>
> Certainly a laudable goal.  Persisting with G.7713.2 and the OIF UNI
> without any willingness to adapt these specifications clashes with
> this goal.  Working together implies converging -- the IETF took a big
> step in this direction by acceding to the ASON signaing requirements
> as stated; it doesn't seem that the ITU-T or OIF are willing to take
> similar steps.
>
> > As you note, GMPLS is being extended to support ASON
> > as well.  It sounds reasonable to comment that some clarification of
> > the project definition may be helpful.
>
> And very importantly, to state the need for more work on this front,
> rather than beginning work on convergence at once.
>
> > This also raises a good point about GMPLS continuing to evolve beyond
> > RFC 3473.  As the work on GMPLS extensions to support ASON functionality
> > continues to develop, this will need to be taken into account.
>
> At what stage?  It seems that instead of converging, the object seems
> to develop a full suite of competing protocols, and only then take the
> GMPLS suite into account.
>
> Kireeti.
> -------
>
>

Delivery-date: Wed, 24 Nov 2004 16:47:00 +0000
From: "Zafar Ali" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, "'Loa Andersson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: New charter
Date: Wed, 24 Nov 2004 11:46:29 -0500

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Kireeti Kompella
>Sent: Wednesday, November 24, 2004 11:21 AM
>To: Loa Andersson
>Cc: [email-masked]
>Subject: Re: New charter
>
>
>On Wed, 24 Nov 2004, Loa Andersson wrote:
>
>> not entirely happy to let the IESG do the pruning,
>
>Okay, Loa -- you are right.
>
>All: instead of Yes/No, can you pick the four most important 
>items from your point of view?  Thanks!
>
>(To those who already replied, sorry to make you do this again!)
>

Hi Kireeti, 

My pick for the four items is (in this order),

- PCE requirements
- GMPLS interoperability issues (incl. MPLS-GMPLS migration), as "GMPLS
interoperability issues" and "MPLS-GMPLS migration" are overlapping in
nature. 
- Control plane work
- L1VPN

N.b. Items (in this order)... waveband switching, QoS control and Decoder
ring for addresses are lowest priority (don't care) for me.  

Thanks

Regards... Zafar 

><snip>
>>
>>1) MPLS-GMPLS migration
>
>Yes, .... You may like to rename it as from name it appears 
>that there is a lot of overlap of this with "7) Deployment 
>considerations for GMPLS". 
>

Important, 

>>2) GMPLS interoperability issues
>
>Yes, 

Very important, 

>
>>3a) should the IETF take on L1VPNs?
>
>Yes, 

Important, 

>
>>3b) if yes to 3a, should this be done in CCAMP?
>
>Yes, 

Important, 

>>4) Waveband switching

Don't care, 

>>5) Control plane work
>
>Yes, but the name is too board, may like to rename it, e.g., 
>Control plane resiliency and GS. 
>

Very Important. 

>>6) Decoder ring for addresses

Don't care, 

>>7) Deployment considerations for GMPLS
>
>Yes, 

Important, 

>>8) PCE requirements
>Yes, 

Very important, 

>>9) QoS control

Don't care, 

<snip>

Delivery-date: Wed, 24 Nov 2004 16:39:41 +0000
Content-class: urn:content-classes:message
Subject: RE : New charter
Date: Wed, 24 Nov 2004 17:39:17 +0100
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>

All listed items seem really important, but if you need the four=20
most important, IMHO here they are

1) + 7) (as both are intimately linked)
2)=20
8)=20
9)=20

JL

>-----Message d'origine-----
>De : [email-masked]=20
>[mailto:[email-masked]] De la part de Kireeti Kompella
>Envoy=E9 : mercredi 24 novembre 2004 17:21
>=C0 : Loa Andersson
>Cc : [email-masked]
>Objet : Re: New charter
>
>
>On Wed, 24 Nov 2004, Loa Andersson wrote:
>
>> not entirely happy to let the IESG do the pruning,
>
>Okay, Loa -- you are right.
>
>All: instead of Yes/No, can you pick the four most important=20
>items from your point of view?  Thanks!
>
>(To those who already replied, sorry to make you do this again!)
>
>Kireeti.
>-------
>
>

Delivery-date: Wed, 24 Nov 2004 16:35:25 +0000
Date: Wed, 24 Nov 2004 08:34:56 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>
cc: "'Brungard, Deborah A, ALABS'" <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Second incoming communication from the OIF

Hi Lyndon,

On Tue, 23 Nov 2004, Ong, Lyndon wrote:

> I'm reading into your email a concern with the use of "ASON" in the title
> of the project.  The interworking project is likely to cover ITU-T
> G.7713.2 as the ASON signaling standard at the UNI and E-NNI, taking into
> account experiences that members have had implementing and testing
> protocols.

Our concern is with the project as a whole.  There are several
deficiencies in G.7713.2 and the OIF UNI; these have been pointed out
many times by CCAMP, and liaised to the ITU, but we are not aware of
any significant changes that have been made to the OIF UNI or to
G.7713.2 to address these problems.  In view of this, it seems
premature to expend effort attempting to build networks that interwork
the OIF UNI with GMPLS since future work to fix the OIF UNI is likely
to have considerable impact on any interworking specifications.  The
real problem (namely, the ASON signaling requirements as well as a UNI
and E-NNI) have also been addressed by CCAMP; to continue work on
G.7713.2, and in fact to use it as the ASON signaling standard at the
UNI and E-NNI seems to us very shortsighted indeed.

The communication says, "We expect the OIF, ITU-T and IETF will
continue to work together to minimize or eliminate differences between
control plane signaling protocols."

Certainly a laudable goal.  Persisting with G.7713.2 and the OIF UNI
without any willingness to adapt these specifications clashes with
this goal.  Working together implies converging -- the IETF took a big
step in this direction by acceding to the ASON signaing requirements
as stated; it doesn't seem that the ITU-T or OIF are willing to take
similar steps.

> As you note, GMPLS is being extended to support ASON
> as well.  It sounds reasonable to comment that some clarification of
> the project definition may be helpful.

And very importantly, to state the need for more work on this front,
rather than beginning work on convergence at once.

> This also raises a good point about GMPLS continuing to evolve beyond
> RFC 3473.  As the work on GMPLS extensions to support ASON functionality
> continues to develop, this will need to be taken into account.

At what stage?  It seems that instead of converging, the object seems
to develop a full suite of competing protocols, and only then take the
GMPLS suite into account.

Kireeti.
-------

Delivery-date: Wed, 24 Nov 2004 16:29:44 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: RS-DT Wrap-Up Statements
Date: Wed, 24 Nov 2004 11:29:26 -0500

dimitri, see in-line

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 24, 2004 11:02 AM
Subject: Re: RS-DT Wrap-Up Statements

> igor - see in-line:
>
> Igor Bryskin wrote:
>
> > Dimitri,
> >
> > Do you think it is reasonable/practical to separate routing controller
from
> > signaling controller and consider scenarios such as a single routing
> > controller manages (provides advertisements) for several transport nodes
> > with each of the latter having a dedicated signaling controller for TE
> > tunnel provisioning?
>
> this is a "functional" separation - in the basic association Si <-> Ri
> <-> i, we retrieve the canonical LSR (note i will change the word "can"
> by "may" in the below informational statement)

IB>> Separation could be physical, not just functional. Consider, for
instance, a transport network built of WXCs that do not have own control
plane. In this case a routing controller managing one or several such WXCs
could advertise their resources, while separate signaling controllers with
the help of PCE(s) could compute and signal TE paths for them.

>
> > Also, how in your opinion a signaling controller knows which address to
send
> > Path message for the next hop along the path.
> > Possible options:
> > a) ID of a numbered link is routable or RouterID in unnumbered ERO
> > sub-object (which is transport node ID) is routable;
>
> several points here:
> 1. we refer to a "TE Router_ID" per RFC 3477 recommendation
> 2. we should indicate these "identifiers" are TE reachable in the scope
>     of the covered application
> 3. even if relevant the scope of this is related to routing
>
> > b) necessary binding (neighbor linkID=> neighbor signaling address,
neighbor
> > nodeID=> neighbor signaling address) is provided via LMP
>
> in the case of multiple association an additional information is
> required that falls beyond the scope of routing and that could be
> achieved using LMP
>

IB>> Personally, I don't like the assumption that transport node IDs and
linkIDs of numbered links are routable (especially in the context of non-PSC
networks) and prefer relying on LMP or some other neighbor auto--discovery
mechanism.

Igor

> hope this clarifies,
> - thanks.
>
> > Thanks,
> > Igor
> >
> >
> > ----- Original Message ----- 
> > From: "dimitri papadimitriou" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Wednesday, November 24, 2004 4:25 AM
> > Subject: RS-DT Wrap-Up Statements
> >
> >
> >
> >>folks -
> >>
> >>The initial evaluation phase of existing routing protocols required
> >>definition of a common pattern. The definition of this pattern last
> >>until beginning of november (input from several parties) now that pieces
> >>are in place needs to move a step further.
> >>
> >>The evaluation document will be issued by end-november to close this
> >>first phase. The content of this document will be articulated around the
> >>below terminology, scenarios and features.
> >>
> >>1. Terminology:
> >>--------------
> >>
> >>- Pi is a physical node (bearer/data/transport plane) node
> >>- Li is a logical control plane identifier that is associated to a
> >>   single data plane (abstract) node
> >>   Li = logical node id or "TE router id" i.e. for
> >>   . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
> >>   . RFC 3784: Traffic Engineering Router ID TLV (Type 134)
> >>- Ri is a control plane "router" e.g. (advertising) Router_ID i.e.
> >>   . RFC 2328: Router ID (32-bit)
> >>   . RFC 1195: IS-IS System ID (48-bit)
> >>
> >>Note: in the below Figure 1.
> >>- R3 represents an LSR with all components collocated.
> >>- R2 shows how the "router" component may be disjoint from the node
> >>- R1 shows how a single "router" may manage multiple nodes
> >>
> >>The Router_ID (represented by Ri) does not enter into the identification
> >>of the logical entities representing the data plane resources such as
> >>links. The Routing DataBase (RDB) is associated to the Ri.
> >>
> >>Note: the "signaling controller" i.e. the control plane entity that
> >>processes the signaling messages (referred to as Si) is not represented
> >>in these Figures. Multiple signalling controllers can be associated to
> >>one Ri and make use of the path computation function associated to the
Ri.
> >>
> >>2. Mechanisms:
> >>-------------
> >>
> >>Focus is on routing information exchange between Ri entities (through
> >>routing adjacencies) within single hierarchical level. Routing
> >>information mapping between levels may require specific guidelines.
> >>
> >>The control plane does not transport Pi information as these are data
> >>plane addresses for which the the Li/Pi mapping is kept (link) local -
> >>see for instance the transport LMP document where such exchange is
> >>described. Example: the transport plane identifier is the Pi (the
> >>identifier assigned to the physical element) be for instance
> >>"666B.F999.AF10.222C", the control plane identifier is the Li (the
> >>identifier assigned by the control plane), be for instance "1.1.1.1".
> >>The control plane exchanges the control plane identifier information but
> >>not the transport plane identifier information (i.e. not
> >>"666B.F999.AF10.222C" but only "1.1.1.1"), The mapping Li/Pi is kept
> >>local. So, when the Si receives a control plane message requesting the
> >>use of "1.1.1.1", Si knows locally that this information refers to the
> >>data plane entity identified by the transport plane identifier
> >>"666B.F999.AF10.222C".
> >>
> >>The control plane carries:
> >>1) its view of the data plane link end-points and other link connection
> >>end-points - note: advertisement of reachability can be achieved using
> >>the techniques described in
>
>><http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt>
> >>
> >>2) the identifiers scoped by the Li's i.e. we speak about an associated
> >>IPv4/IPv6 addressing space;
> >>
> >>Evalution Scenarios:
> >>-------------------
> >>
> >>The scenarios are the following: resp. case 1), 2) and 3)
> >>
> >>              -------------------     ------
> >>             |R1                 |   |R2     |
> >>             |                   |   |       |    ------
> >>             |  L1    L2    L3   |   |   L4  |   |R3    |
> >>             |   :     :     :   |   |   :   |   |      |
> >>             |   :     :     :   |   |   :   |   |  L5  |
> >>Control      ---+-----+-----+---     ---+---    |   :  |
> >>Plane           :     :     :           :       |   :  |
> >>----------------+-----+-----+-----------+-------+---+--+-
> >>Data            :     :     :           :       |   :  |
> >>Plane          --     :    --          --       |  --  |
> >>           ----|P1|--------|P3|--------|P4|------+-|P5|-+-
> >>                -- \   :  / --          --       |  --  |
> >>                    \ -- /                       |      |
> >>                     |P2|                         ------
> >>                      --
> >>
> >>case 1) as represented either direct links between edges or "logical
> >>links" as per below figure (or any combination of them)
> >>
> >>                 ------                        ------
> >>                |      |                      |      |
> >>                |  L1  |                      |  L2  |
> >>                |  :   |                      |  :   |
> >>                |  : R1|                      |  : R2|
> >>Control Plane   --+---                        --+---
> >>Elements          :                             :
> >>------------------+-----------------------------+------------------
> >>Data Plane        :                             :
> >>Elements          :                             :
> >>               ----+-----------------------------+-----
> >>              |    :                             :     |
> >>              |   ---            ---            ---    |
> >>              |  |   |----------| P |----------|   |   |
> >>           ---+--|   |           ---           |   |---+---
> >>              |  |   |                         |   |   |
> >>              |  | P1|-------------------------| P2|   |
> >>              |   ---                           ---    |
> >>               ----------------------------------------
> >>
> >>Another case is constituted by the Abstract Node as represented in the
> >>below figure. There is no internal structure associated to the abstract
> >>node.
> >>
> >>                     --------------
> >>                    |R4            |
> >>                    |              |
> >>                    |      L6      |
> >>                    |       :      |
> >>                    |    ......    |
> >>                     ---:------:---
> >>Control Plane          :      :
> >>                 +------+------+------+
> >>Data Plane             :      :
> >>                     ---:------:---
> >>                    |P8 :      :   |
> >>                    |  --      --  |
> >>                  --+-|P |----|P |-+--
> >>                    |  --      --  |
> >>                     --------------
> >>
> >>Note: base scenarios (being not combinations or decomposition of
> >>entities) can further complete this set
> >>
> >>4. Specific Considerations
> >>    -----------------------
> >>
> >>Representation of bandwidth requires further analysis i.e. GMPLS Routing
> >>defines an Interface Switching Capability Descriptor (ISCD) that
> >>delivers information about the (maximum/minimum) bandwidth per priority
> >>an LSP can make use of. In the ASON context, other representations are
> >>possible, e.g. in terms of a set of tuples <signal_type; number of
> >>unallocated timeslots>. The latter also may require definition of
> >>additional signal types (from those defined in RFC 3496) to represent
> >>contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64,
> >
> > 256.
> >
> >>The GMPLS routing method proposed in GMPLS Routing is the most
> >>straightforward without requiring any bandwidth accounting change from
> >>an LSR perspective. However, it introduces some lost of information.
> >>This lost of information affects the number of signals that can be used
> >>but not the range they cover. On the other hand, if additional
> >>technology specific information (such as capabilities) are advertised a
> >>finer grained resource countdown and accounting can be performed
> >>allowing for network wide resource allocation in Sonet/SDH environments.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> > .
> >
>

Delivery-date: Wed, 24 Nov 2004 16:21:53 +0000
Date: Wed, 24 Nov 2004 08:21:16 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Loa Andersson <[email-masked]>
cc: [email-masked]
Subject: Re: New charter

On Wed, 24 Nov 2004, Loa Andersson wrote:

> not entirely happy to let the IESG do the pruning,

Okay, Loa -- you are right.

All: instead of Yes/No, can you pick the four most important items
from your point of view?  Thanks!

(To those who already replied, sorry to make you do this again!)

Kireeti.
-------

Delivery-date: Wed, 24 Nov 2004 16:03:39 +0000
Date: Wed, 24 Nov 2004 17:02:53 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Igor Bryskin <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: RS-DT Wrap-Up Statements

igor - see in-line:

Igor Bryskin wrote:

> Dimitri,
> 
> Do you think it is reasonable/practical to separate routing controller from
> signaling controller and consider scenarios such as a single routing
> controller manages (provides advertisements) for several transport nodes
> with each of the latter having a dedicated signaling controller for TE
> tunnel provisioning?

this is a "functional" separation - in the basic association Si <-> Ri 
<-> i, we retrieve the canonical LSR (note i will change the word "can" 
by "may" in the below informational statement)

> Also, how in your opinion a signaling controller knows which address to send
> Path message for the next hop along the path.
> Possible options:
> a) ID of a numbered link is routable or RouterID in unnumbered ERO
> sub-object (which is transport node ID) is routable;

several points here:
1. we refer to a "TE Router_ID" per RFC 3477 recommendation
2. we should indicate these "identifiers" are TE reachable in the scope
    of the covered application
3. even if relevant the scope of this is related to routing

> b) necessary binding (neighbor linkID=> neighbor signaling address, neighbor
> nodeID=> neighbor signaling address) is provided via LMP

in the case of multiple association an additional information is 
required that falls beyond the scope of routing and that could be 
achieved using LMP

hope this clarifies,
- thanks.

> Thanks,
> Igor
> 
> 
> ----- Original Message ----- 
> From: "dimitri papadimitriou" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, November 24, 2004 4:25 AM
> Subject: RS-DT Wrap-Up Statements
> 
> 
> 
>>folks -
>>
>>The initial evaluation phase of existing routing protocols required
>>definition of a common pattern. The definition of this pattern last
>>until beginning of november (input from several parties) now that pieces
>>are in place needs to move a step further.
>>
>>The evaluation document will be issued by end-november to close this
>>first phase. The content of this document will be articulated around the
>>below terminology, scenarios and features.
>>
>>1. Terminology:
>>--------------
>>
>>- Pi is a physical node (bearer/data/transport plane) node
>>- Li is a logical control plane identifier that is associated to a
>>   single data plane (abstract) node
>>   Li = logical node id or "TE router id" i.e. for
>>   . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
>>   . RFC 3784: Traffic Engineering Router ID TLV (Type 134)
>>- Ri is a control plane "router" e.g. (advertising) Router_ID i.e.
>>   . RFC 2328: Router ID (32-bit)
>>   . RFC 1195: IS-IS System ID (48-bit)
>>
>>Note: in the below Figure 1.
>>- R3 represents an LSR with all components collocated.
>>- R2 shows how the "router" component may be disjoint from the node
>>- R1 shows how a single "router" may manage multiple nodes
>>
>>The Router_ID (represented by Ri) does not enter into the identification
>>of the logical entities representing the data plane resources such as
>>links. The Routing DataBase (RDB) is associated to the Ri.
>>
>>Note: the "signaling controller" i.e. the control plane entity that
>>processes the signaling messages (referred to as Si) is not represented
>>in these Figures. Multiple signalling controllers can be associated to
>>one Ri and make use of the path computation function associated to the Ri.
>>
>>2. Mechanisms:
>>-------------
>>
>>Focus is on routing information exchange between Ri entities (through
>>routing adjacencies) within single hierarchical level. Routing
>>information mapping between levels may require specific guidelines.
>>
>>The control plane does not transport Pi information as these are data
>>plane addresses for which the the Li/Pi mapping is kept (link) local -
>>see for instance the transport LMP document where such exchange is
>>described. Example: the transport plane identifier is the Pi (the
>>identifier assigned to the physical element) be for instance
>>"666B.F999.AF10.222C", the control plane identifier is the Li (the
>>identifier assigned by the control plane), be for instance "1.1.1.1".
>>The control plane exchanges the control plane identifier information but
>>not the transport plane identifier information (i.e. not
>>"666B.F999.AF10.222C" but only "1.1.1.1"), The mapping Li/Pi is kept
>>local. So, when the Si receives a control plane message requesting the
>>use of "1.1.1.1", Si knows locally that this information refers to the
>>data plane entity identified by the transport plane identifier
>>"666B.F999.AF10.222C".
>>
>>The control plane carries:
>>1) its view of the data plane link end-points and other link connection
>>end-points - note: advertisement of reachability can be achieved using
>>the techniques described in
>><http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt>
>>
>>2) the identifiers scoped by the Li's i.e. we speak about an associated
>>IPv4/IPv6 addressing space;
>>
>>Evalution Scenarios:
>>-------------------
>>
>>The scenarios are the following: resp. case 1), 2) and 3)
>>
>>              -------------------     ------
>>             |R1                 |   |R2     |
>>             |                   |   |       |    ------
>>             |  L1    L2    L3   |   |   L4  |   |R3    |
>>             |   :     :     :   |   |   :   |   |      |
>>             |   :     :     :   |   |   :   |   |  L5  |
>>Control      ---+-----+-----+---     ---+---    |   :  |
>>Plane           :     :     :           :       |   :  |
>>----------------+-----+-----+-----------+-------+---+--+-
>>Data            :     :     :           :       |   :  |
>>Plane          --     :    --          --       |  --  |
>>           ----|P1|--------|P3|--------|P4|------+-|P5|-+-
>>                -- \   :  / --          --       |  --  |
>>                    \ -- /                       |      |
>>                     |P2|                         ------
>>                      --
>>
>>case 1) as represented either direct links between edges or "logical
>>links" as per below figure (or any combination of them)
>>
>>                 ------                        ------
>>                |      |                      |      |
>>                |  L1  |                      |  L2  |
>>                |  :   |                      |  :   |
>>                |  : R1|                      |  : R2|
>>Control Plane   --+---                        --+---
>>Elements          :                             :
>>------------------+-----------------------------+------------------
>>Data Plane        :                             :
>>Elements          :                             :
>>               ----+-----------------------------+-----
>>              |    :                             :     |
>>              |   ---            ---            ---    |
>>              |  |   |----------| P |----------|   |   |
>>           ---+--|   |           ---           |   |---+---
>>              |  |   |                         |   |   |
>>              |  | P1|-------------------------| P2|   |
>>              |   ---                           ---    |
>>               ----------------------------------------
>>
>>Another case is constituted by the Abstract Node as represented in the
>>below figure. There is no internal structure associated to the abstract
>>node.
>>
>>                     --------------
>>                    |R4            |
>>                    |              |
>>                    |      L6      |
>>                    |       :      |
>>                    |    ......    |
>>                     ---:------:---
>>Control Plane          :      :
>>                 +------+------+------+
>>Data Plane             :      :
>>                     ---:------:---
>>                    |P8 :      :   |
>>                    |  --      --  |
>>                  --+-|P |----|P |-+--
>>                    |  --      --  |
>>                     --------------
>>
>>Note: base scenarios (being not combinations or decomposition of
>>entities) can further complete this set
>>
>>4. Specific Considerations
>>    -----------------------
>>
>>Representation of bandwidth requires further analysis i.e. GMPLS Routing
>>defines an Interface Switching Capability Descriptor (ISCD) that
>>delivers information about the (maximum/minimum) bandwidth per priority
>>an LSP can make use of. In the ASON context, other representations are
>>possible, e.g. in terms of a set of tuples <signal_type; number of
>>unallocated timeslots>. The latter also may require definition of
>>additional signal types (from those defined in RFC 3496) to represent
>>contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64,
> 
> 256.
> 
>>The GMPLS routing method proposed in GMPLS Routing is the most
>>straightforward without requiring any bandwidth accounting change from
>>an LSR perspective. However, it introduces some lost of information.
>>This lost of information affects the number of signals that can be used
>>but not the range they cover. On the other hand, if additional
>>technology specific information (such as capabilities) are advertised a
>>finer grained resource countdown and accounting can be performed
>>allowing for network wide resource allocation in Sonet/SDH environments.
>>
>>
>>
>>
>>
>>
>>
>>
> 
> 
> 
> 
> .
> 

Delivery-date: Wed, 24 Nov 2004 15:46:44 +0000
Date: Wed, 24 Nov 2004 16:45:23 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked]
CC: George Swallow <[email-masked]>, Alex Zinin <[email-masked]>, Bill Fenner <[email-masked]>, [email-masked]
Subject: MPLS wg last call on re-spun bundling draft

Working group,

this is to initiate a 2 weeks working group last call on
<draft-ietf-mpls-bundle-05.txt>

The CCAMP working is copied on this MPLS working group last,
since there are interdependencies between specifications from
both working groups. Pleae use the MPLS mailing list for
comments, cross-publishing is not necessary.

Background: This draft was reviewed by the IESG and approved
for publication. During implementation there were some issues
found and it was decided to pull the draft from the RFC Editors
queue. This wg last call is limited to these issues and how
they been addressed only.

The list of issues and how the authors has addresed has been
sent to the mailing list(s). That text is also included in this
mail.

For the record please note that I've asked the authors to
update some ID-nits, those are not part of the wg last call.
But has been included just to make it easier to progress the
document through IESG review.

This working group last call ends on EOB December 10 PST.

/Loa

------- issues and how they been addressed -------------
Here is the summary:

draft-ietf-mpls-bundle-05.txt has been updated to reflect
the comments made in the MPLS WG and on the list.  The issues
raised are:

1. Scope of component identifiers is open to interpretation
    (i.e., node vs link)
2. No way to specify different upstream and downstream components
    then using TLV types 1, 2 and 3
3. Ambiguity of contents of the IP address field in TLV types 3, 4, 5
4. Lack of IPv6 support for types 3, 4, and 5.
5. Ambiguity of when to use types 4 and 5 and when to use type 3.
6. No coverage of ERO and RRO implications

These issues have been addressed in the following ways:

Issue 1:  The -05 document states that all component link TLV types
           have Node/IP scope
Issue 2: -05 Tightly defines support for different components in each
           direction (for bidirectional LSPs, and for all TLV types)
Issue 3: Format of the Value field for types 3, 4 and 5 now has the
           identical format as the contents of the C-Type 1
           LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477].
Issue 4: Based on the previous change, support of IPv6 unnumbered
           components is now tied to, and the same as, the support of
           IPv6 unnumber TE links.
Issue 5: -05 allows, but recommend against use of types 4 and 5
Issue 6: EROs, RROs remain out of scope of bundling document

Current planned changes are:
- Fix nits found by Adrian and Loa
- Insert a Table of Contents
- Section numbering will remain unchanged so as not to break
   any potentially existing references to the draft

Yakov.
-------------------- end of included text --------------------

Loa Andersson

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

Delivery-date: Wed, 24 Nov 2004 15:37:59 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: RS-DT Wrap-Up Statements
Date: Wed, 24 Nov 2004 10:37:32 -0500

Dimitri,

Do you think it is reasonable/practical to separate routing controller from
signaling controller and consider scenarios such as a single routing
controller manages (provides advertisements) for several transport nodes
with each of the latter having a dedicated signaling controller for TE
tunnel provisioning?

Also, how in your opinion a signaling controller knows which address to send
Path message for the next hop along the path.
Possible options:
a) ID of a numbered link is routable or RouterID in unnumbered ERO
sub-object (which is transport node ID) is routable;
b) necessary binding (neighbor linkID=> neighbor signaling address, neighbor
nodeID=> neighbor signaling address) is provided via LMP

Thanks,
Igor

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 24, 2004 4:25 AM
Subject: RS-DT Wrap-Up Statements

> folks -
>
> The initial evaluation phase of existing routing protocols required
> definition of a common pattern. The definition of this pattern last
> until beginning of november (input from several parties) now that pieces
> are in place needs to move a step further.
>
> The evaluation document will be issued by end-november to close this
> first phase. The content of this document will be articulated around the
> below terminology, scenarios and features.
>
> 1. Terminology:
> --------------
>
> - Pi is a physical node (bearer/data/transport plane) node
> - Li is a logical control plane identifier that is associated to a
>    single data plane (abstract) node
>    Li = logical node id or "TE router id" i.e. for
>    . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
>    . RFC 3784: Traffic Engineering Router ID TLV (Type 134)
> - Ri is a control plane "router" e.g. (advertising) Router_ID i.e.
>    . RFC 2328: Router ID (32-bit)
>    . RFC 1195: IS-IS System ID (48-bit)
>
> Note: in the below Figure 1.
> - R3 represents an LSR with all components collocated.
> - R2 shows how the "router" component may be disjoint from the node
> - R1 shows how a single "router" may manage multiple nodes
>
> The Router_ID (represented by Ri) does not enter into the identification
> of the logical entities representing the data plane resources such as
> links. The Routing DataBase (RDB) is associated to the Ri.
>
> Note: the "signaling controller" i.e. the control plane entity that
> processes the signaling messages (referred to as Si) is not represented
> in these Figures. Multiple signalling controllers can be associated to
> one Ri and make use of the path computation function associated to the Ri.
>
> 2. Mechanisms:
> -------------
>
> Focus is on routing information exchange between Ri entities (through
> routing adjacencies) within single hierarchical level. Routing
> information mapping between levels may require specific guidelines.
>
> The control plane does not transport Pi information as these are data
> plane addresses for which the the Li/Pi mapping is kept (link) local -
> see for instance the transport LMP document where such exchange is
> described. Example: the transport plane identifier is the Pi (the
> identifier assigned to the physical element) be for instance
> "666B.F999.AF10.222C", the control plane identifier is the Li (the
> identifier assigned by the control plane), be for instance "1.1.1.1".
> The control plane exchanges the control plane identifier information but
> not the transport plane identifier information (i.e. not
> "666B.F999.AF10.222C" but only "1.1.1.1"), The mapping Li/Pi is kept
> local. So, when the Si receives a control plane message requesting the
> use of "1.1.1.1", Si knows locally that this information refers to the
> data plane entity identified by the transport plane identifier
> "666B.F999.AF10.222C".
>
> The control plane carries:
> 1) its view of the data plane link end-points and other link connection
> end-points - note: advertisement of reachability can be achieved using
> the techniques described in
> <http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt>
>
> 2) the identifiers scoped by the Li's i.e. we speak about an associated
> IPv4/IPv6 addressing space;
>
> Evalution Scenarios:
> -------------------
>
> The scenarios are the following: resp. case 1), 2) and 3)
>
>               -------------------     ------
>              |R1                 |   |R2     |
>              |                   |   |       |    ------
>              |  L1    L2    L3   |   |   L4  |   |R3    |
>              |   :     :     :   |   |   :   |   |      |
>              |   :     :     :   |   |   :   |   |  L5  |
> Control      ---+-----+-----+---     ---+---    |   :  |
> Plane           :     :     :           :       |   :  |
> ----------------+-----+-----+-----------+-------+---+--+-
> Data            :     :     :           :       |   :  |
> Plane          --     :    --          --       |  --  |
>            ----|P1|--------|P3|--------|P4|------+-|P5|-+-
>                 -- \   :  / --          --       |  --  |
>                     \ -- /                       |      |
>                      |P2|                         ------
>                       --
>
> case 1) as represented either direct links between edges or "logical
> links" as per below figure (or any combination of them)
>
>                  ------                        ------
>                 |      |                      |      |
>                 |  L1  |                      |  L2  |
>                 |  :   |                      |  :   |
>                 |  : R1|                      |  : R2|
> Control Plane   --+---                        --+---
> Elements          :                             :
> ------------------+-----------------------------+------------------
> Data Plane        :                             :
> Elements          :                             :
>                ----+-----------------------------+-----
>               |    :                             :     |
>               |   ---            ---            ---    |
>               |  |   |----------| P |----------|   |   |
>            ---+--|   |           ---           |   |---+---
>               |  |   |                         |   |   |
>               |  | P1|-------------------------| P2|   |
>               |   ---                           ---    |
>                ----------------------------------------
>
> Another case is constituted by the Abstract Node as represented in the
> below figure. There is no internal structure associated to the abstract
> node.
>
>                      --------------
>                     |R4            |
>                     |              |
>                     |      L6      |
>                     |       :      |
>                     |    ......    |
>                      ---:------:---
> Control Plane          :      :
>                  +------+------+------+
> Data Plane             :      :
>                      ---:------:---
>                     |P8 :      :   |
>                     |  --      --  |
>                   --+-|P |----|P |-+--
>                     |  --      --  |
>                      --------------
>
> Note: base scenarios (being not combinations or decomposition of
> entities) can further complete this set
>
> 4. Specific Considerations
>     -----------------------
>
> Representation of bandwidth requires further analysis i.e. GMPLS Routing
> defines an Interface Switching Capability Descriptor (ISCD) that
> delivers information about the (maximum/minimum) bandwidth per priority
> an LSP can make use of. In the ASON context, other representations are
> possible, e.g. in terms of a set of tuples <signal_type; number of
> unallocated timeslots>. The latter also may require definition of
> additional signal types (from those defined in RFC 3496) to represent
> contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64,
256.
>
> The GMPLS routing method proposed in GMPLS Routing is the most
> straightforward without requiring any bandwidth accounting change from
> an LSR perspective. However, it introduces some lost of information.
> This lost of information affects the number of signals that can be used
> but not the range they cover. On the other hand, if additional
> technology specific information (such as capabilities) are advertised a
> finer grained resource countdown and accounting can be performed
> allowing for network wide resource allocation in Sonet/SDH environments.
>
>
>
>
>
>
>
>

Delivery-date: Wed, 24 Nov 2004 15:24:28 +0000
content-class: urn:content-classes:message
Subject: RE: New charter
Date: Wed, 24 Nov 2004 09:24:13 -0600
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>

Yes to all (also see (6) as part of (2), and not sure title of (2) is
interoperability issues or more appropriately clarification (e.g. the
egress control draft)).
Deborah=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kireeti Kompella
Sent: Wednesday, November 24, 2004 1:22 AM
To: [email-masked]
Subject: New charter

On Mon, 15 Nov 2004, Kireeti Kompella wrote:

> If you have suggested charter updates, please send them to Adrian
> and me.

Thanks all for your input.  I have the following items; for each,
please say "Yes" (should be added to CCAMP charter), "No" (should not
be added) or "-" (don't care).  I'll remind you once again that not
all items will make it onto the new charter.

Please keep this subject line (simply reply to this mail).  The
deadline is Friday Dec 3, 17:00 PST.

1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3a) should the IETF take on L1VPNs?
3b) if yes to 3a, should this be done in CCAMP?
4) Waveband switching
5) Control plane work
6) Decoder ring for addresses
7) Deployment considerations for GMPLS
8) PCE requirements
9) QoS control

A rough idea of what each of the above entails follows.

1) MPLS-GMPLS migration
	implementation shift from "MPLS" objects to "GMPLS" objects
	BCP on deployment migration for the same

2) GMPLS interoperability issues
	what addresses to use where
	nits/clarifications of the specs
	guidelines for path computation & constraints
	survay

3) L1VPN work items
	identify protocol extensions needed
	state what can already be done with what we have
	do the actual protocol work for requirements that are not met
	liaisons to SG13 as needed

5) Control plane work
	resiliency
	graceful shutdown

6) Decoder ring for addresses
	for each address field, identify its nature and ITU equivalent
	(may overlap with part of (2))

4, 7-9 are obvious or have been elaborated on the mailing list.

Kireeti.
-------

PS: The topic of GTTP has carefully been avoided.  More later.

Envelope-to: [email-masked]
Delivery-date: Wed, 24 Nov 2004 15:19:18 +0000
Message-ID: <B258A372CEA20246A363BB86753DB536E2C458@zrtphxm2>
From: "Don Fedyk" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: New charter
Date: Wed, 24 Nov 2004 10:18:19 -0500

Hi Kireeti

See Inline

<snip>
>Please keep this subject line (simply reply to this mail).  The
>deadline is Friday Dec 3, 17:00 PST.
>
>1) MPLS-GMPLS migration 
Yes

>2) GMPLS interoperability issues 
Yes

>3a) should the IETF take on L1VPNs? 
yes (as you outlined below)

>3b) if yes to 3a, should this be done in CCAMP?  
yes 

>4) Waveband switching 
I suppose Protocol aspects

>5) Control plane work
Yes

>6) Decoder ring for addresses
Is this IETF -> ITU or ITU -> IETF or both ? I think should be both. 

>7) Deployment considerations for GMPLS
Yes

>8) PCE requirements 
Depends on if there is PCE WG. Why not in PCE WG? 
  
>9) QoS control
Not sure what this is ? I missed it.
 
>
>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration implementation shift from "MPLS" objects
>to "GMPLS" objects BCP on deployment migration for the same
>
>2) GMPLS interoperability issues what addresses to use where
>nits/clarifications of the specs guidelines for path computation
>& constraints survay
>
>3) L1VPN work items identify protocol extensions needed state
>what can already be done with what we have do the actual
>protocol work for requirements that are not met liaisons to SG13
>as needed
>
>5) Control plane work resiliency graceful shutdown
>
>6) Decoder ring for addresses for each address field, identify
>its nature and ITU equivalent (may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.  -------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>
>
Regards,
Don 

Envelope-to: [email-masked]
Delivery-date: Wed, 24 Nov 2004 15:02:15 +0000
Message-ID: <[email-masked]>
From: "Hamid Ould-Brahim" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: RE: New charter
Date: Wed, 24 Nov 2004 10:01:44 -0500

Kireeti,

> 1) MPLS-GMPLS migration

Yes.

> 2) GMPLS interoperability issues

Yes.

> 3a) should the IETF take on L1VPNs?

Definitely Yes.

> 3b) if yes to 3a, should this be done in CCAMP?

Yes.

> 4) Waveband switching
> 5) Control plane work
> 6) Decoder ring for addresses
> 7) Deployment considerations for GMPLS
> 8) PCE requirements
> 9) QoS control
> 

Yes to all.

Hamid.

Delivery-date: Wed, 24 Nov 2004 14:56:32 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Subject: Re: New charter
Date: Wed, 24 Nov 2004 09:55:57 -0500

My vote is in-line.
Igor

----- Original Message ----- 
From: "Kireeti Kompella" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 24, 2004 1:22 AM
Subject: New charter

> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
> 
> > If you have suggested charter updates, please send them to Adrian
> > and me.
> 
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
> 
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
> 
> 1) MPLS-GMPLS migration
Yes

> 2) GMPLS interoperability issues
Yes

> 3a) should the IETF take on L1VPNs?
Yes

> 3b) if yes to 3a, should this be done in CCAMP?
Yes

> 4) Waveband switching

> 5) Control plane work
Yes, but should be stated more clearly.
In addition to waht other people said I'd like to add:
Managing of control plane partitioned LSPs 

> 6) Decoder ring for addresses

> 7) Deployment considerations for GMPLS
Yes,

> 8) PCE requirements
Yes, and I'd like it not to be limited by inter-domain LSPs

> 9) QoS control
I am not sure about that. Isn't MPLS/GMPLS is mostly about already ?

> 
> A rough idea of what each of the above entails follows.
> 
> 1) MPLS-GMPLS migration
> implementation shift from "MPLS" objects to "GMPLS" objects
> BCP on deployment migration for the same
> 
> 2) GMPLS interoperability issues
> what addresses to use where
> nits/clarifications of the specs
> guidelines for path computation & constraints
> survay
> 
> 3) L1VPN work items
> identify protocol extensions needed
> state what can already be done with what we have
> do the actual protocol work for requirements that are not met
> liaisons to SG13 as needed
> 
> 5) Control plane work
> resiliency
> graceful shutdown
> 
> 6) Decoder ring for addresses
> for each address field, identify its nature and ITU equivalent
> (may overlap with part of (2))
> 
> 
> 4, 7-9 are obvious or have been elaborated on the mailing list.
> 
> Kireeti.
> -------
> 
> PS: The topic of GTTP has carefully been avoided.  More later.
> 

Delivery-date: Wed, 24 Nov 2004 14:04:29 +0000
Date: Wed, 24 Nov 2004 15:03:09 +0100
From: Loa Andersson <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: New charter

Kireeti,

not entirely happy to let the IESG do the pruning,
so the most important to me is 5 (control plane)
and 8 (PCE requirments)

/Loa

Kireeti Kompella wrote:

> Hi Loa,
> 
> On Wed, 24 Nov 2004, Loa Andersson wrote:
> 
> 
>>I tend to agree with Dimitri, one concern is that
>>this could be rather big, do we want to prioritize
>>or is that implied in the numbering
> 
> 
> It is rather big, as I am trying to capture all the ideas of the
> community.  I don't expect that all the proposals will get enough
> support for "rough consensus"; in any case, even if all of them did,
> the IESG would very quickly prune the list :-)
> 
> There is *no* intended priority in the numbering!
> 
> Kireeti.
> -------
> 
> 

-- 
Loa Andersson

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

Delivery-date: Wed, 24 Nov 2004 14:03:13 +0000
From: "Zafar Ali" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>
Subject: RE: New charter
Date: Wed, 24 Nov 2004 09:01:49 -0500

Kireeti, 

Reply in-lined.

Thanks

Regards... Zafar

<snip>
>1) MPLS-GMPLS migration

Yes, .... You may like to rename it as from name it appears that there is a
lot of overlap of this with "7) Deployment considerations for GMPLS". 

>2) GMPLS interoperability issues

Yes, 

>3a) should the IETF take on L1VPNs?

Yes, 

>3b) if yes to 3a, should this be done in CCAMP?

Yes, 

>4) Waveband switching
>5) Control plane work

Yes, but the name is too board, may like to rename it, e.g., Control plane
resiliency and GS. 

>6) Decoder ring for addresses
>7) Deployment considerations for GMPLS

Yes, 

>8) PCE requirements

Yes, 

>9) QoS control
>
>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>
>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>
>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>
>5) Control plane work
>	resiliency
>	graceful shutdown
>
>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>

Delivery-date: Wed, 24 Nov 2004 12:19:00 +0000
content-class: urn:content-classes:message
Subject: RE: New charter
Date: Wed, 24 Nov 2004 06:17:47 -0600
From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>

> please say "Yes" (should be added to CCAMP charter),=20
> "No" (should not be added) or "-" (don't care).

Yes to all.

Jerry

Delivery-date: Wed, 24 Nov 2004 11:53:21 +0000
Cc: [email-masked]
From: JP Vasseur <[email-masked]>
Subject: Re: New charter
Date: Wed, 24 Nov 2004 06:45:42 -0500
To: Kireeti Kompella <[email-masked]>

Hi Kireeti,

On Nov 24, 2004, at 1:22 AM, Kireeti Kompella wrote:

> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>
>> If you have suggested charter updates, please send them to Adrian
>> and me.
>
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
>
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
>
> 1) MPLS-GMPLS migration
>
yes
> 2) GMPLS interoperability issues
>
yes
> 3a) should the IETF take on L1VPNs?
> 3b) if yes to 3a, should this be done in CCAMP?
>
yes
> 4) Waveband switching
yes
> 5) Control plane work
yes
> 6) Decoder ring for addresses
>
-
> 7) Deployment considerations for GMPLS
>
yes
> 8) PCE requirements
More precisely "PCE requirements for Inter-domain" which is the main 
objective of the potential future WG.
Other PCE requirements amy either be done in the PCE WG or may come 
from other WG in the future,
> 9) QoS control
yes

JP.

> A rough idea of what each of the above entails follows.
>
> 1) MPLS-GMPLS migration
> 	implementation shift from "MPLS" objects to "GMPLS" objects
> 	BCP on deployment migration for the same
>
> 2) GMPLS interoperability issues
> 	what addresses to use where
> 	nits/clarifications of the specs
> 	guidelines for path computation & constraints
> 	survay
>
> 3) L1VPN work items
> 	identify protocol extensions needed
> 	state what can already be done with what we have
> 	do the actual protocol work for requirements that are not met
> 	liaisons to SG13 as needed
>
> 5) Control plane work
> 	resiliency
> 	graceful shutdown
>
> 6) Decoder ring for addresses
> 	for each address field, identify its nature and ITU equivalent
> 	(may overlap with part of (2))
>
>
> 4, 7-9 are obvious or have been elaborated on the mailing list.
>
> Kireeti.
> -------
>
> PS: The topic of GTTP has carefully been avoided.  More later.
>
>

Delivery-date: Wed, 24 Nov 2004 10:54:52 +0000
Date: Wed, 24 Nov 2004 02:53:44 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Loa Andersson <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: New charter

Hi Loa,

On Wed, 24 Nov 2004, Loa Andersson wrote:

> I tend to agree with Dimitri, one concern is that
> this could be rather big, do we want to prioritize
> or is that implied in the numbering

It is rather big, as I am trying to capture all the ideas of the
community.  I don't expect that all the proposals will get enough
support for "rough consensus"; in any case, even if all of them did,
the IESG would very quickly prune the list :-)

There is *no* intended priority in the numbering!

Kireeti.
-------

Delivery-date: Wed, 24 Nov 2004 09:50:47 +0000
Date: Wed, 24 Nov 2004 10:48:01 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked]
CC: Kireeti Kompella <[email-masked]>, [email-masked]
Subject: Re: New charter

Kireeti,

I tend to agree with Dimitri, one concern is that
this could be rather big, do we want to prioritize
or is that implied in the numbering

/Loa

dimitri papadimitriou wrote:

> hi kireeti,
> 
>  > 1) MPLS-GMPLS migration
> 
> yes
> 
>  > 2) GMPLS interoperability issues
> 
> yes
> 
>  > 3a) should the IETF take on L1VPNs?
> 
> yes
> 
>  > 3b) if yes to 3a, should this be done in CCAMP?
> 
> as first option (note: with the current standpoint, could this done 
> elsewhere ?)
> 
>  > 4) Waveband switching
> 
> yes (note: need more support as rather limited since so far)
> 
>  > 5) Control plane work
> 
> yes ("document" CP resiliency and GS)
> 
>  > 6) Decoder ring for addresses
> 
> part of this work is in (2) and other should be part of the ongoing ASON 
> work
> 
>  > 7) Deployment considerations for GMPLS
> 
> is this an embryon of "gmplsops" ? in favor
> 
>  > 8) PCE requirements
> 
> yes
> 
>  > 9) QoS control
> 
> yes
> 
> ---
> 
> Kireeti Kompella wrote:
> 
>> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>>
>>
>>> If you have suggested charter updates, please send them to Adrian
>>> and me.
>>
>>
>>
>> Thanks all for your input.  I have the following items; for each,
>> please say "Yes" (should be added to CCAMP charter), "No" (should not
>> be added) or "-" (don't care).  I'll remind you once again that not
>> all items will make it onto the new charter.
>>
>> Please keep this subject line (simply reply to this mail).  The
>> deadline is Friday Dec 3, 17:00 PST.
>>
>> 1) MPLS-GMPLS migration
>> 2) GMPLS interoperability issues
>> 3a) should the IETF take on L1VPNs?
>> 3b) if yes to 3a, should this be done in CCAMP?
>> 4) Waveband switching
>> 5) Control plane work
>> 6) Decoder ring for addresses
>> 7) Deployment considerations for GMPLS
>> 8) PCE requirements
>> 9) QoS control
>>
>> A rough idea of what each of the above entails follows.
>>
>> 1) MPLS-GMPLS migration
>>     implementation shift from "MPLS" objects to "GMPLS" objects
>>     BCP on deployment migration for the same
>>
>> 2) GMPLS interoperability issues
>>     what addresses to use where
>>     nits/clarifications of the specs
>>     guidelines for path computation & constraints
>>     survay
>>
>> 3) L1VPN work items
>>     identify protocol extensions needed
>>     state what can already be done with what we have
>>     do the actual protocol work for requirements that are not met
>>     liaisons to SG13 as needed
>>
>> 5) Control plane work
>>     resiliency
>>     graceful shutdown
>>
>> 6) Decoder ring for addresses
>>     for each address field, identify its nature and ITU equivalent
>>     (may overlap with part of (2))
>>
>>
>> 4, 7-9 are obvious or have been elaborated on the mailing list.
>>
>> Kireeti.
>> -------
>>
>> PS: The topic of GTTP has carefully been avoided.  More later.
>>
>>
>> .
>>
> 
> 
> 

-- 
Loa Andersson

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

Delivery-date: Wed, 24 Nov 2004 09:25:30 +0000
Date: Wed, 24 Nov 2004 10:25:20 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked]
To:  [email-masked]
Subject: RS-DT Wrap-Up Statements

folks -

The initial evaluation phase of existing routing protocols required
definition of a common pattern. The definition of this pattern last
until beginning of november (input from several parties) now that pieces 
are in place needs to move a step further.

The evaluation document will be issued by end-november to close this
first phase. The content of this document will be articulated around the
below terminology, scenarios and features.

1. Terminology:
--------------

- Pi is a physical node (bearer/data/transport plane) node
- Li is a logical control plane identifier that is associated to a
   single data plane (abstract) node
   Li = logical node id or "TE router id" i.e. for
   . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
   . RFC 3784: Traffic Engineering Router ID TLV (Type 134)
- Ri is a control plane "router" e.g. (advertising) Router_ID i.e.
   . RFC 2328: Router ID (32-bit)
   . RFC 1195: IS-IS System ID (48-bit)

Note: in the below Figure 1.
- R3 represents an LSR with all components collocated.
- R2 shows how the "router" component may be disjoint from the node
- R1 shows how a single "router" may manage multiple nodes

The Router_ID (represented by Ri) does not enter into the identification
of the logical entities representing the data plane resources such as
links. The Routing DataBase (RDB) is associated to the Ri.

Note: the "signaling controller" i.e. the control plane entity that
processes the signaling messages (referred to as Si) is not represented
in these Figures. Multiple signalling controllers can be associated to
one Ri and make use of the path computation function associated to the Ri.

2. Mechanisms:
-------------

Focus is on routing information exchange between Ri entities (through
routing adjacencies) within single hierarchical level. Routing
information mapping between levels may require specific guidelines.

The control plane does not transport Pi information as these are data
plane addresses for which the the Li/Pi mapping is kept (link) local -
see for instance the transport LMP document where such exchange is
described. Example: the transport plane identifier is the Pi (the
identifier assigned to the physical element) be for instance
"666B.F999.AF10.222C", the control plane identifier is the Li (the
identifier assigned by the control plane), be for instance "1.1.1.1".
The control plane exchanges the control plane identifier information but
not the transport plane identifier information (i.e. not
"666B.F999.AF10.222C" but only "1.1.1.1"), The mapping Li/Pi is kept
local. So, when the Si receives a control plane message requesting the
use of "1.1.1.1", Si knows locally that this information refers to the
data plane entity identified by the transport plane identifier
"666B.F999.AF10.222C".

The control plane carries:
1) its view of the data plane link end-points and other link connection
end-points - note: advertisement of reachability can be achieved using
the techniques described in
<http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt>
	
2) the identifiers scoped by the Li's i.e. we speak about an associated
IPv4/IPv6 addressing space;

Evalution Scenarios:
-------------------

The scenarios are the following: resp. case 1), 2) and 3)

              -------------------     ------
             |R1                 |   |R2     |
             |                   |   |       |    ------
             |  L1    L2    L3   |   |   L4  |   |R3    |
             |   :     :     :   |   |   :   |   |      |
             |   :     :     :   |   |   :   |   |  L5  |
Control      ---+-----+-----+---     ---+---    |   :  |
Plane           :     :     :           :       |   :  |
----------------+-----+-----+-----------+-------+---+--+-
Data            :     :     :           :       |   :  |
Plane          --     :    --          --       |  --  |
           ----|P1|--------|P3|--------|P4|------+-|P5|-+-
                -- \   :  / --          --       |  --  |
                    \ -- /                       |      |
                     |P2|                         ------
                      --

case 1) as represented either direct links between edges or "logical
links" as per below figure (or any combination of them)

                 ------                        ------
                |      |                      |      |
                |  L1  |                      |  L2  |
                |  :   |                      |  :   |
                |  : R1|                      |  : R2|
Control Plane   --+---                        --+---
Elements          :                             :
------------------+-----------------------------+------------------
Data Plane        :                             :
Elements          :                             :
               ----+-----------------------------+-----
              |    :                             :     |
              |   ---            ---            ---    |
              |  |   |----------| P |----------|   |   |
           ---+--|   |           ---           |   |---+---
              |  |   |                         |   |   |
              |  | P1|-------------------------| P2|   |
              |   ---                           ---    |
               ----------------------------------------

Another case is constituted by the Abstract Node as represented in the
below figure. There is no internal structure associated to the abstract
node.

                     --------------
                    |R4            |
                    |              |
                    |      L6      |
                    |       :      |
                    |    ......    |
                     ---:------:---
Control Plane          :      :
                 +------+------+------+
Data Plane             :      :
                     ---:------:---
                    |P8 :      :   |
                    |  --      --  |
                  --+-|P |----|P |-+--
                    |  --      --  |
                     --------------

Note: base scenarios (being not combinations or decomposition of
entities) can further complete this set

4. Specific Considerations
    -----------------------

Representation of bandwidth requires further analysis i.e. GMPLS Routing
defines an Interface Switching Capability Descriptor (ISCD) that
delivers information about the (maximum/minimum) bandwidth per priority
an LSP can make use of. In the ASON context, other representations are
possible, e.g. in terms of a set of tuples <signal_type; number of
unallocated timeslots>. The latter also may require definition of
additional signal types (from those defined in RFC 3496) to represent
contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.

The GMPLS routing method proposed in GMPLS Routing is the most
straightforward without requiring any bandwidth accounting change from
an LSR perspective. However, it introduces some lost of information.
This lost of information affects the number of signals that can be used
but not the range they cover. On the other hand, if additional
technology specific information (such as capabilities) are advertised a
finer grained resource countdown and accounting can be performed
allowing for network wide resource allocation in Sonet/SDH environments.

Delivery-date: Wed, 24 Nov 2004 09:22:21 +0000
Date: Wed, 24 Nov 2004 10:20:29 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Kireeti Kompella <[email-masked]>
CC:  [email-masked]
Subject: Re: New charter

hi kireeti,

 > 1) MPLS-GMPLS migration

yes

 > 2) GMPLS interoperability issues

yes

 > 3a) should the IETF take on L1VPNs?

yes

 > 3b) if yes to 3a, should this be done in CCAMP?

as first option (note: with the current standpoint, could this done 
elsewhere ?)

 > 4) Waveband switching

yes (note: need more support as rather limited since so far)

 > 5) Control plane work

yes ("document" CP resiliency and GS)

 > 6) Decoder ring for addresses

part of this work is in (2) and other should be part of the ongoing ASON 
work

 > 7) Deployment considerations for GMPLS

is this an embryon of "gmplsops" ? in favor

 > 8) PCE requirements

yes

 > 9) QoS control

yes

---

Kireeti Kompella wrote:

> On Mon, 15 Nov 2004, Kireeti Kompella wrote:
> 
> 
>>If you have suggested charter updates, please send them to Adrian
>>and me.
> 
> 
> Thanks all for your input.  I have the following items; for each,
> please say "Yes" (should be added to CCAMP charter), "No" (should not
> be added) or "-" (don't care).  I'll remind you once again that not
> all items will make it onto the new charter.
> 
> Please keep this subject line (simply reply to this mail).  The
> deadline is Friday Dec 3, 17:00 PST.
> 
> 1) MPLS-GMPLS migration
> 2) GMPLS interoperability issues
> 3a) should the IETF take on L1VPNs?
> 3b) if yes to 3a, should this be done in CCAMP?
> 4) Waveband switching
> 5) Control plane work
> 6) Decoder ring for addresses
> 7) Deployment considerations for GMPLS
> 8) PCE requirements
> 9) QoS control
> 
> A rough idea of what each of the above entails follows.
> 
> 1) MPLS-GMPLS migration
> 	implementation shift from "MPLS" objects to "GMPLS" objects
> 	BCP on deployment migration for the same
> 
> 2) GMPLS interoperability issues
> 	what addresses to use where
> 	nits/clarifications of the specs
> 	guidelines for path computation & constraints
> 	survay
> 
> 3) L1VPN work items
> 	identify protocol extensions needed
> 	state what can already be done with what we have
> 	do the actual protocol work for requirements that are not met
> 	liaisons to SG13 as needed
> 
> 5) Control plane work
> 	resiliency
> 	graceful shutdown
> 
> 6) Decoder ring for addresses
> 	for each address field, identify its nature and ITU equivalent
> 	(may overlap with part of (2))
> 
> 
> 4, 7-9 are obvious or have been elaborated on the mailing list.
> 
> Kireeti.
> -------
> 
> PS: The topic of GTTP has carefully been avoided.  More later.
> 
> 
> .
> 

Delivery-date: Wed, 24 Nov 2004 07:27:01 +0000
Content-class: urn:content-classes:message
Subject: RE : New charter
Date: Wed, 24 Nov 2004 08:25:49 +0100
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>

Hi Kireeti and all

Yes to all, except 3b: Don't care

JL

>-----Message d'origine-----
>De : [email-masked]=20
>[mailto:[email-masked]] De la part de Kireeti Kompella
>Envoy=E9 : mercredi 24 novembre 2004 07:22
>=C0 : [email-masked]
>Objet : New charter
>
>
>On Mon, 15 Nov 2004, Kireeti Kompella wrote:
>
>> If you have suggested charter updates, please send them to=20
>Adrian and=20
>> me.
>
>Thanks all for your input.  I have the following items; for=20
>each, please say "Yes" (should be added to CCAMP charter),=20
>"No" (should not be added) or "-" (don't care).  I'll remind=20
>you once again that not all items will make it onto the new charter.
>
>Please keep this subject line (simply reply to this mail). =20
>The deadline is Friday Dec 3, 17:00 PST.
>
>1) MPLS-GMPLS migration
>2) GMPLS interoperability issues
>3a) should the IETF take on L1VPNs?
>3b) if yes to 3a, should this be done in CCAMP?
>4) Waveband switching
>5) Control plane work
>6) Decoder ring for addresses
>7) Deployment considerations for GMPLS
>8) PCE requirements
>9) QoS control
>
>A rough idea of what each of the above entails follows.
>
>1) MPLS-GMPLS migration
>	implementation shift from "MPLS" objects to "GMPLS" objects
>	BCP on deployment migration for the same
>
>2) GMPLS interoperability issues
>	what addresses to use where
>	nits/clarifications of the specs
>	guidelines for path computation & constraints
>	survay
>
>3) L1VPN work items
>	identify protocol extensions needed
>	state what can already be done with what we have
>	do the actual protocol work for requirements that are not met
>	liaisons to SG13 as needed
>
>5) Control plane work
>	resiliency
>	graceful shutdown
>
>6) Decoder ring for addresses
>	for each address field, identify its nature and ITU equivalent
>	(may overlap with part of (2))
>
>
>4, 7-9 are obvious or have been elaborated on the mailing list.
>
>Kireeti.
>-------
>
>PS: The topic of GTTP has carefully been avoided.  More later.
>
>

Delivery-date: Wed, 24 Nov 2004 06:23:36 +0000
Date: Tue, 23 Nov 2004 22:22:19 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: New charter

On Mon, 15 Nov 2004, Kireeti Kompella wrote:

> If you have suggested charter updates, please send them to Adrian
> and me.

Thanks all for your input.  I have the following items; for each,
please say "Yes" (should be added to CCAMP charter), "No" (should not
be added) or "-" (don't care).  I'll remind you once again that not
all items will make it onto the new charter.

Please keep this subject line (simply reply to this mail).  The
deadline is Friday Dec 3, 17:00 PST.

1) MPLS-GMPLS migration
2) GMPLS interoperability issues
3a) should the IETF take on L1VPNs?
3b) if yes to 3a, should this be done in CCAMP?
4) Waveband switching
5) Control plane work
6) Decoder ring for addresses
7) Deployment considerations for GMPLS
8) PCE requirements
9) QoS control

A rough idea of what each of the above entails follows.

1) MPLS-GMPLS migration
	implementation shift from "MPLS" objects to "GMPLS" objects
	BCP on deployment migration for the same

2) GMPLS interoperability issues
	what addresses to use where
	nits/clarifications of the specs
	guidelines for path computation & constraints
	survay

3) L1VPN work items
	identify protocol extensions needed
	state what can already be done with what we have
	do the actual protocol work for requirements that are not met
	liaisons to SG13 as needed

5) Control plane work
	resiliency
	graceful shutdown

6) Decoder ring for addresses
	for each address field, identify its nature and ITU equivalent
	(may overlap with part of (2))

4, 7-9 are obvious or have been elaborated on the mailing list.

Kireeti.
-------

PS: The topic of GTTP has carefully been avoided.  More later.

Delivery-date: Wed, 24 Nov 2004 05:12:34 +0000
Reply-To: <[email-masked]>
From: <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: 
Bcc: 
Subject: RE: charter update
Date: Wed, 24 Nov 2004 14:11:06 +0900
Comment: =?iso-8859-1?B?x9GxucD8wNrF673Fv6yxuL/4LCCxpMD8tN64wcGmvu7GwCwgtOO05w==?=
Content-Class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_5A04_01C4D22F.70807860
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

------=_NextPart_000_5A04_01C4D22F.70807860
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

------=_NextPart_000_5A04_01C4D22F.70807860--

Delivery-date: Tue, 23 Nov 2004 21:51:12 +0000
From: "Ong, Lyndon" <[email-masked]>
To: "'Brungard, Deborah A, ALABS'" <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Second incoming communication from the OIF
Date: Tue, 23 Nov 2004 16:54:57 -0500

Hi Deborah,

Just to clear up any potential misunderstanding:

There hasn't been any recent decision on the part of OIF to freeze
its work (as UNI 1.0 goes back to 2001, it's already pretty cold ;o)
The interworking proposal came up very recently, and it was understood that
IETF and ITU-T have no plans to document interworking at this time.

I'm reading into your email a concern with the use of "ASON" in the title
of the project.  The interworking project is likely to cover ITU-T 
G.7713.2 as the ASON signaling standard at the UNI and E-NNI, taking into
account experiences that members have had implementing and testing
protocols.  As you note, GMPLS is being extended to support ASON
as well.  It sounds reasonable to comment that some clarification of
the project definition may be helpful.

This also raises a good point about GMPLS continuing to evolve beyond
RFC 3473.  As the work on GMPLS extensions to support ASON functionality 
continues to develop, this will need to be taken into account.

Cheers,

Lyndon

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Monday, November 22, 2004 1:36 PM
To: Adrian Farrel; [email-masked]
Subject: RE: Second incoming communication from the OIF

Hi Adrian,

While this liaison may be considered "for information", it communicates
OIF's recognition and concern regarding the incompatibility problems of
G7713.2/UNI1.0 (SONET/SDH) with GMPLS, and regretfully (for operators
and vendors), it seems OIF is choosing to freeze it's work. While G8080
recognizes multiple protocols may exist, it does not encourage redundant
(same) protocol mechanisms for the same capability, and proliferation of
interworking functions. Here's a suggested response...
-----------------
It is regretful that you consider your SONET/SDH implementation
agreements frozen. Considering the (published) UNI1.0 statement: "since
the intent of OIF is to develop UNI protocols in close alignment with
the IETF work, any changes in GMPLS/LMP proposed standards that could be
incorporated in UNI signaling specifications will be included in future
versions", we had hoped to cooperatively work with you to minimize the
divergence between OIF IA on SONET/SDH and RFC3473 in the best interests
for the industry.

Noting your lack of a definition of "domain" at this time (re. your 2nd
liaison regarding OIF demo results), we question your interpretation
(below) of RFC3473 and the title "interworking of ASON-GMPLS network
domains". Per G8080, domains are based on functionality e.g. signaling,
routing. RFC3473 is a standard signaling interface for use between
different vendor equipment and different signaling domains (i.e. ENNI
and INNI). Recent work extended to UNI support. And as previously
communicated, CCAMP is progressing standards-track ASON-GMPLS (in
cooperation with ITU-T) in support of the full set of G8080 call
functionalities (i.e. independent call/connection setup and support of
multiple connections per call).

For your interworking design guidelines, we recommend for you to clarify
when referencing a non-standard signaling implementation or standard
RFC3473. As a basis for your work, we recommend use of our ASON-GMPLS
work to ensure proper interpretation of standard RFC3473's capabilities
in support of G8080. We can understand OIF operators' concerns on the
potential for mis-interpretation and the need for design guidelines
considering the multiplicity of protocols "based on RSVP". Hopefully, as
you progress this work, you will reconsider using UNI1.0 protocol
mechanisms based on standards-track modifications of RSVP. We look
forward to working with you on OIF UNI2.0 using CCAMP's standards track
work.
-----------

Regards,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Friday, November 19, 2004 2:09 PM
To: [email-masked]
Subject: Second incoming communication from the OIF

A second communication from Jim Jones, Chair of the OIF Technical
Committee, lands on my
e-doorstep.

This communication is helpfully in two files with different formats (one
PDF and one
PowerPoint). I have reproduced the text below.

Again, the real copy can be found at
http://www.olddog.co.uk/incoming.htm

Adrian

===

November 5, 2004
Mr. Adrian Farrel, [email-masked], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [email-masked], IETF, CCAMP Working Group
Chair
Re: New OIF Project on Interworking of ASON - GMPLS Network Domains

Dear Adrian and Kireeti,

I want to inform you of a new work project that was proposed and adopted
by the OIF
members at our 4Q Technical Committee meetings that took place October
26-28. The
project will result in a design guideline document to assist vendors and
carriers
in optical networks where signaling interworking is required between
OIF/ITU-T ASON
and GMPLS RSVP-TE.

As we have seen in interoperability trials and initial deployments,
vendor
implementations sometimes use different control plane protocols,
depending on the
NE requirements and function within a network. The OIF and ASON control
plane
requirements were written with the knowledge that a network composed of
multiple
domains could support a heterogeneous set of protocols. An NE that
exists at a
boundary between network domains may support a different protocol on
either side
of the boundary (for example OIF UNI on the client side and GMPLS I-NNI
on the
network side).

An interworking design guideline was cited as a high priority by OIF
member companies,
both carriers and vendors. It is also our understanding that an
interworking guide is
not currently within the work scope of either IETF CCAMP or ITU-T SG15.
An outline of
the project plan is provided in the document oif2004.442.01. Although
the proposal
illustrates an example network configuration (featuring GMPLS as INNI
protocol), this
is an example only and not meant to restrict interworking considerations
to this model.

In contrast to OIF Implementation Agreements (IAs), the design guideline
will define
optional interworking methods between existing optical control plane
protocols. This
will allow software stack vendors and system vendors to map information,
messages and
behaviors between different protocols while preserving the required
functionality on
each side of the interface.

We expect the OIF, ITU-T and IETF will continue to work together to
minimize or
eliminate differences between control plane signaling protocols. Given
that different
protocols currently exist to meet different requirements, an
interworking guide can
help ensure straightforward protocol interoperation. We welcome your
input on this
project and look forward to future collaboration.

Sincerely,
Jim Jones
OIF Technical Committee Chair
cc: [email-masked]

====
Slide1

Project proposal for interworking of G.8080 - RFC 3473 network domains

Contribution Number: oif2004.442.00
Working Group:  Architecture & Signaling
Title: Project proposal for interworking of G.8080 - RFC 3473 network
domains
Meeting: 4Q2004
Source:  Eve Varma Monica Lazer
Hans-Martin Foisel Satoru Okamoto
Jonathan Sadler Vishnu Shukla
Lyndon Ong Date: October 28, 2004
Abstract:  This contribution proposes to initiate a project with the
intention of
publishing a design guideline document for interworking between
OIF/ITU-T ASON control
plane interfaces (UNI, E-NNI) and IETF/GMPLS network domains.
Notice: This contribution has been created to assist the Optical
Internetworking Forum
(OIF).  This document is offered to the OIF solely as a basis for
discussion and is not a
binding proposal on the companies listed as resources above. Each
company in the source
list, and the OIF, reserves the rights to at any time to add, amend, or
withdraw
statements contained herein.
This Working Text represents work in progress by the OIF, and must not
be construed as an
official OIF Technical Report.  Nothing in this document is in any way
binding on the OIF
or any of its members.  The document is offered as a basis for
discussion and
communication, both within and without the OIF.
For additional information contact:
The Optical Internetworking Forum, 39355 California Street,
Suite 307, Fremont, CA 94538
510-608-5990 phone F [email-masked]
(c) 2001 Optical Internetworking Forum
===
Slide2

Contributors and Supporters
Alcatel, Jim Jones
AT&T - Monica Lazer
Avici - Amy Wang
Ciena - Lyndon Ong
Cisco - Richard Bradford
Deutsche Telekom - Hans-Martin Foisel
Lucent - Eve Varma
NTT - Satoru Okamoto
Tellabs - Jonathan Sadler
Verizon - Vishnu Shukla
.
===
Slide3

Network graph
===
Slide4

Project Start

Objective:
Generate an design guideline document for the interoperability of
OIF/ITU-T ASON and
IETF/GMPLS network domains

Scope
E-NNI, I-NNI(GMPLS) and UNI interoperability among these different
network architecture
approaches

Expected Output
Design guideline document (technical report) on this topic; not an
Implementation
Agreement

Interaction with other forums and standards bodies
Close cooperation with IETF/CCAMP and ITU-T,Q14/SG15
MTNM

Interaction with other OIF WG
Carrier, OAM&P, Interoperability

Why the OIF?
Interworking and interoperability among different standardization bodies
specifications
and standards approaches is a key goal of the Optical Internetworking
Forum
===
Slide5

Project Timeline

Project Start: This meeting (Oct 2004)
Liaison to ITU and IETF describing project scope and soliciting
interest: until next
meeting
Solicit and receive contributions for 2 quarterly meetings
Baseline draft 2nd Quarter 2005
Proposed editor: Hans-Martin Foisel
Straw ballot 3rd quarter 2005
Principal ballot 1st quarter 2006
===
Slide6

Motivation: Why Now?

Broad vendor and carrier support
- Strong request from the carrier and vendor members for interworking
among network
  domains, which may use IETF or OIF/ITU-T standards and specifications.
Current activities at IETF CCAMP design teams could benefit from this
document
This document will be based not only on available standards and
specifications but also on
first practical testing experiences
===
Slide7

References to Standards Contributions

RFC 3471, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Functional
Description"
RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS)Signaling
Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions".
RFC 3630, "Traffic Engineering (TE) Extensions to OSPF Version 2 ".
"Routing Extensions in Support of Generalized Multi-Protocol Label
Switching",
draft-ietf-ccamp-gmpls-routing-09.txt, work in progress..
OIF-UNI 1.0 Release 2, "OIF-UNI-01.0-R2-Common - User Network Interface
(UNI) 1.0
Signaling Specification, Release 2: Common Part" and
"OIF-UNI-01.0-R2-RSVP - RSVP
Extensions for User Network Interface (UNI) 1.0 Signaling, Release 2"
OIF E-NNI 1.0 Signaling, "OIF-E-NNI-Sig-01.0 - Intra-Carrier E-NNI
Signaling
 Specification"
===
Slide8

References to Standards Contributions

ITU-T G.8080/Y.1304, "Architecture for the Automatically Switched
Optical Network (ASON)"
ITU-T G.7713, "Distributed Call And Connection Management (DCM)".ITU-T
ITU-T G.7713.1, "Distributed Call and Connection Management (DCM) based
on PNNI".ITU-T
ITU-T G.7713.2, "Distributed Call and Connection Management: Signalling
mechanism using
GMPLS RSVP-TE".ITU-T
ITU-T G.7713.3, "Distributed Call and Connection Management: Signalling
mechanism using
GMPLS CR-LDP"
ITU-T G.7715, "Architecture and Requirements for Routing in the
Automatic Switched Optical
Networks".ITU-T
ITU-T G.7715.1, "ASON Routing Architecture and Requirements for Link
State Protocols"
===
Slide9

References to Standards Contributions

oif2004.435: Discussion points from routing solutions design team
oif2004.383: Project proposal for interworking to RFC 3473
oif2004.357: Interworking of OIF UNI/E-NNI with RFC 3473 GMPLS
oif2004.303: IETF draft with comparison of GMPLS and ASON signaling

Delivery-date: Mon, 22 Nov 2004 21:36:28 +0000
content-class: urn:content-classes:message
Subject: RE: Second incoming communication from the OIF
Date: Mon, 22 Nov 2004 15:35:35 -0600
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Adrian,

While this liaison may be considered "for information", it communicates
OIF's recognition and concern regarding the incompatibility problems of
G7713.2/UNI1.0 (SONET/SDH) with GMPLS, and regretfully (for operators
and vendors), it seems OIF is choosing to freeze it's work. While G8080
recognizes multiple protocols may exist, it does not encourage redundant
(same) protocol mechanisms for the same capability, and proliferation of
interworking functions. Here's a suggested response...
-----------------
It is regretful that you consider your SONET/SDH implementation
agreements frozen. Considering the (published) UNI1.0 statement: "since
the intent of OIF is to develop UNI protocols in close alignment with
the IETF work, any changes in GMPLS/LMP proposed standards that could be
incorporated in UNI signaling specifications will be included in future
versions", we had hoped to cooperatively work with you to minimize the
divergence between OIF IA on SONET/SDH and RFC3473 in the best interests
for the industry.

Noting your lack of a definition of "domain" at this time (re. your 2nd
liaison regarding OIF demo results), we question your interpretation
(below) of RFC3473 and the title "interworking of ASON-GMPLS network
domains". Per G8080, domains are based on functionality e.g. signaling,
routing. RFC3473 is a standard signaling interface for use between
different vendor equipment and different signaling domains (i.e. ENNI
and INNI). Recent work extended to UNI support. And as previously
communicated, CCAMP is progressing standards-track ASON-GMPLS (in
cooperation with ITU-T) in support of the full set of G8080 call
functionalities (i.e. independent call/connection setup and support of
multiple connections per call).

For your interworking design guidelines, we recommend for you to clarify
when referencing a non-standard signaling implementation or standard
RFC3473. As a basis for your work, we recommend use of our ASON-GMPLS
work to ensure proper interpretation of standard RFC3473's capabilities
in support of G8080. We can understand OIF operators' concerns on the
potential for mis-interpretation and the need for design guidelines
considering the multiplicity of protocols "based on RSVP". Hopefully, as
you progress this work, you will reconsider using UNI1.0 protocol
mechanisms based on standards-track modifications of RSVP. We look
forward to working with you on OIF UNI2.0 using CCAMP's standards track
work.
-----------

Regards,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Friday, November 19, 2004 2:09 PM
To: [email-masked]
Subject: Second incoming communication from the OIF

A second communication from Jim Jones, Chair of the OIF Technical
Committee, lands on my
e-doorstep.

This communication is helpfully in two files with different formats (one
PDF and one
PowerPoint). I have reproduced the text below.

Again, the real copy can be found at
http://www.olddog.co.uk/incoming.htm

Adrian

=3D=3D=3D

November 5, 2004
Mr. Adrian Farrel, [email-masked], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [email-masked], IETF, CCAMP Working Group
Chair
Re: New OIF Project on Interworking of ASON - GMPLS Network Domains

Dear Adrian and Kireeti,

I want to inform you of a new work project that was proposed and adopted
by the OIF
members at our 4Q Technical Committee meetings that took place October
26-28. The
project will result in a design guideline document to assist vendors and
carriers
in optical networks where signaling interworking is required between
OIF/ITU-T ASON
and GMPLS RSVP-TE.

As we have seen in interoperability trials and initial deployments,
vendor
implementations sometimes use different control plane protocols,
depending on the
NE requirements and function within a network. The OIF and ASON control
plane
requirements were written with the knowledge that a network composed of
multiple
domains could support a heterogeneous set of protocols. An NE that
exists at a
boundary between network domains may support a different protocol on
either side
of the boundary (for example OIF UNI on the client side and GMPLS I-NNI
on the
network side).

An interworking design guideline was cited as a high priority by OIF
member companies,
both carriers and vendors. It is also our understanding that an
interworking guide is
not currently within the work scope of either IETF CCAMP or ITU-T SG15.
An outline of
the project plan is provided in the document oif2004.442.01. Although
the proposal
illustrates an example network configuration (featuring GMPLS as INNI
protocol), this
is an example only and not meant to restrict interworking considerations
to this model.

In contrast to OIF Implementation Agreements (IAs), the design guideline
will define
optional interworking methods between existing optical control plane
protocols. This
will allow software stack vendors and system vendors to map information,
messages and
behaviors between different protocols while preserving the required
functionality on
each side of the interface.

We expect the OIF, ITU-T and IETF will continue to work together to
minimize or
eliminate differences between control plane signaling protocols. Given
that different
protocols currently exist to meet different requirements, an
interworking guide can
help ensure straightforward protocol interoperation. We welcome your
input on this
project and look forward to future collaboration.

Sincerely,
Jim Jones
OIF Technical Committee Chair
cc: [email-masked]

=3D=3D=3D=3D
Slide1

Project proposal for interworking of G.8080 - RFC 3473 network domains

Contribution Number: oif2004.442.00
Working Group:  Architecture & Signaling
Title: Project proposal for interworking of G.8080 - RFC 3473 network
domains
Meeting: 4Q2004
Source:  Eve Varma Monica Lazer
Hans-Martin Foisel Satoru Okamoto
Jonathan Sadler Vishnu Shukla
Lyndon Ong Date: October 28, 2004
Abstract:  This contribution proposes to initiate a project with the
intention of
publishing a design guideline document for interworking between
OIF/ITU-T ASON control
plane interfaces (UNI, E-NNI) and IETF/GMPLS network domains.
Notice: This contribution has been created to assist the Optical
Internetworking Forum
(OIF).  This document is offered to the OIF solely as a basis for
discussion and is not a
binding proposal on the companies listed as resources above. Each
company in the source
list, and the OIF, reserves the rights to at any time to add, amend, or
withdraw
statements contained herein.
This Working Text represents work in progress by the OIF, and must not
be construed as an
official OIF Technical Report.  Nothing in this document is in any way
binding on the OIF
or any of its members.  The document is offered as a basis for
discussion and
communication, both within and without the OIF.
For additional information contact:
The Optical Internetworking Forum, 39355 California Street,
Suite 307, Fremont, CA 94538
510-608-5990 phone F [email-masked]
(c) 2001 Optical Internetworking Forum
=3D=3D=3D
Slide2

Contributors and Supporters
Alcatel, Jim Jones
AT&T - Monica Lazer
Avici - Amy Wang
Ciena - Lyndon Ong
Cisco - Richard Bradford
Deutsche Telekom - Hans-Martin Foisel
Lucent - Eve Varma
NTT - Satoru Okamoto
Tellabs - Jonathan Sadler
Verizon - Vishnu Shukla
.
=3D=3D=3D
Slide3

Network graph
=3D=3D=3D
Slide4

Project Start

Objective:
Generate an design guideline document for the interoperability of
OIF/ITU-T ASON and
IETF/GMPLS network domains

Scope
E-NNI, I-NNI(GMPLS) and UNI interoperability among these different
network architecture
approaches

Expected Output
Design guideline document (technical report) on this topic; not an
Implementation
Agreement

Interaction with other forums and standards bodies
Close cooperation with IETF/CCAMP and ITU-T,Q14/SG15
MTNM

Interaction with other OIF WG
Carrier, OAM&P, Interoperability

Why the OIF?
Interworking and interoperability among different standardization bodies
specifications
and standards approaches is a key goal of the Optical Internetworking
Forum
=3D=3D=3D
Slide5

Project Timeline

Project Start: This meeting (Oct 2004)
Liaison to ITU and IETF describing project scope and soliciting
interest: until next
meeting
Solicit and receive contributions for 2 quarterly meetings
Baseline draft 2nd Quarter 2005
Proposed editor: Hans-Martin Foisel
Straw ballot 3rd quarter 2005
Principal ballot 1st quarter 2006
=3D=3D=3D
Slide6

Motivation: Why Now?

Broad vendor and carrier support
- Strong request from the carrier and vendor members for interworking
among network
  domains, which may use IETF or OIF/ITU-T standards and specifications.
Current activities at IETF CCAMP design teams could benefit from this
document
This document will be based not only on available standards and
specifications but also on
first practical testing experiences
=3D=3D=3D
Slide7

References to Standards Contributions

RFC 3471, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Functional
Description"
RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS)Signaling
Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions".
RFC 3630, "Traffic Engineering (TE) Extensions to OSPF Version 2 ".
"Routing Extensions in Support of Generalized Multi-Protocol Label
Switching",
draft-ietf-ccamp-gmpls-routing-09.txt, work in progress..
OIF-UNI 1.0 Release 2, "OIF-UNI-01.0-R2-Common - User Network Interface
(UNI) 1.0
Signaling Specification, Release 2: Common Part" and
"OIF-UNI-01.0-R2-RSVP - RSVP
Extensions for User Network Interface (UNI) 1.0 Signaling, Release 2"
OIF E-NNI 1.0 Signaling, "OIF-E-NNI-Sig-01.0 - Intra-Carrier E-NNI
Signaling
 Specification"
=3D=3D=3D
Slide8

References to Standards Contributions

ITU-T G.8080/Y.1304, "Architecture for the Automatically Switched
Optical Network (ASON)"
ITU-T G.7713, "Distributed Call And Connection Management (DCM)".ITU-T
ITU-T G.7713.1, "Distributed Call and Connection Management (DCM) based
on PNNI".ITU-T
ITU-T G.7713.2, "Distributed Call and Connection Management: Signalling
mechanism using
GMPLS RSVP-TE".ITU-T
ITU-T G.7713.3, "Distributed Call and Connection Management: Signalling
mechanism using
GMPLS CR-LDP"
ITU-T G.7715, "Architecture and Requirements for Routing in the
Automatic Switched Optical
Networks".ITU-T
ITU-T G.7715.1, "ASON Routing Architecture and Requirements for Link
State Protocols"
=3D=3D=3D
Slide9

References to Standards Contributions

oif2004.435: Discussion points from routing solutions design team
oif2004.383: Project proposal for interworking to RFC 3473
oif2004.357: Interworking of OIF UNI/E-NNI with RFC 3473 GMPLS
oif2004.303: IETF draft with comparison of GMPLS and ASON signaling

Delivery-date: Mon, 22 Nov 2004 21:35:34 +0000
Date: Fri, 19 Nov 2004 10:30:49 +0900
To: Kireeti Kompella <[email-masked]>, [email-masked]
From: Tomonori TAKEDA <[email-masked]>
Subject: Re: charter update

Hi,

- L1VPNs:
     Define control and measurement plane mechanisms to support L1VPNs.
     Analize applicability of these mechanisms.

As we discussed in CCAMP WG, the work would be expected to be around the 
use and application of GMPLS protocols to support L1VPN services. (Note: 
services does not necessary mean to external customers, can be applicable 
to internal usage as well.) There may be minor protocol extensions needed 
for this.

- Implementation/Interoprability experience

Best regards,

At 07:51 04/11/15 -0800, Kireeti Kompella wrote:
>Hi All,
>
>If you have suggested charter updates, please send them to Adrian and
>me.  Please keep this subject line (simply reply to this mail).
>
>The deadline is Friday Nov 19, 17:00 PST.
>
>Thanks,
>Kireeti.
>-------

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: +81-422-59-7434

Delivery-date: Mon, 22 Nov 2004 19:41:33 +0000
To: "Adrian Farrel" <[email-masked]>
cc: [email-masked], [email-masked], "Kireeti Kompella" <[email-masked]>, [email-masked]
Subject: [mpls] New version of Bundling Draft
Date: Mon, 22 Nov 2004 11:38:50 -0800
From: Yakov Rekhter <[email-masked]>

Adrian,

> Thank you for the new version of this draft. I assume that the
> changes are to address the issues raised at the MPLS WG meeting in
> Washington.
> 
> Since the draft was already through WG and IETF last call, I wonder
> if you would be kind enough to summarize the issues you were
> addressing and what changes you made to the draft.

Here is the summary:

draft-ietf-mpls-bundle-05.txt has been updated to reflect the comments made
in the MPLS WG and on the list.  The issues raised are:

1. Scope of component identifiers is open to interpretation (i.e., node vs
link)
2. No way to specify different upstream and downstream components then
using TLV types 1, 2 and 3
3. Ambiguity of contents of the IP address field in TLV types 3, 4, 5
4. Lack of IPv6 support for types 3, 4, and 5.
5. Ambiguity of when to use types 4 and 5 and when to use type 3.
6. No coverage of ERO and RRO implications

These issues have been addressed in the following ways:

Issue 1:  The -05 document states that all component link TLV types
          have Node/IP scope
Issue 2: -05 Tightly defines support for different components in each
          direction (for bidirectional LSPs, and for all TLV types)
Issue 3: Format of the Value field for types 3, 4 and 5 now has the
          identical format as the contents of the C-Type 1
          LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477].
Issue 4: Based on the previous change, support of IPv6 unnumbered
          components is now tied to, and the same as, the support of 
          IPv6 unnumber TE links.
Issue 5: -05 allows, but recommend against use of types 4 and 5
Issue 6: EROs, RROs remain out of scope of bundling document

Current planned changes are:
- Fix nits found by Adrian and Loa
- Insert a Table of Contents
- Section numbering will remain unchanged so as not to break any
potentially existing references to the draft

Yakov.

Delivery-date: Mon, 22 Nov 2004 15:39:49 +0000
Date: Mon, 22 Nov 2004 07:37:53 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: =?ks_c_5601-1987?B?sei/tcit?= <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: charter update

Hi Young,

On Fri, 19 Nov 2004, [ks_c_5601-1987] =B1=E8=BF=B5=C8=AD wrote:

> In addition to those Zafar said,
=2E..
> - QoS Control for GMPLS, if we find this item outside the current
> scope.

Could you elaborate on this?

Thanks,
Kireeti.
-------

Delivery-date: Mon, 22 Nov 2004 14:59:34 +0000
Date: Mon, 22 Nov 2004 09:55:52 -0500
To: "Adrian Farrel" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: New version of Bundling Draft
Cc: "Berger, Lou" <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, <[email-masked]>, <[email-masked]>

Adrian,
         Loa has asked for the same thing.  We should have it out this week.
Lou

At 10:44 AM 11/20/2004, Adrian Farrel wrote:

>Hi,
>
>Thank you for the new version of this draft. I assume that the changes are 
>to address the
>issues raised at the MPLS WG meeting in Washington.
>
>Since the draft was already through WG and IETF last call, I wonder if you 
>would be kind
>enough to summarize the issues you were addressing and what changes you 
>made to the draft.
>
>Thanks,
>Adrian

Delivery-date: Sat, 20 Nov 2004 18:08:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Registry of bits in the Admin_Status object
Date: Sat, 20 Nov 2004 18:08:09 -0000

All,

I have created a temporary registry of bits in the Admin_Status object to track these
until they get under the care of IANA. Hopefully this will avoid drafts competing for the
bits.

Please let me know when you are pursuing the use of a new bit. Priority will be given to
drafts that choose bit names in such a way as to spell interesting words :-)

Look at http://www.olddog.co.uk/admin-status.txt

Cheers,
Adrian

Delivery-date: Sat, 20 Nov 2004 17:20:34 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, "Yakov Rekhter" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: New version of Bundling Draft
Date: Sat, 20 Nov 2004 15:44:03 -0000

Hi,

Thank you for the new version of this draft. I assume that the changes are to address the
issues raised at the MPLS WG meeting in Washington.

Since the draft was already through WG and IETF last call, I wonder if you would be kind
enough to summarize the issues you were addressing and what changes you made to the draft.

Thanks,
Adrian

PS.
A few nits.

"Status of this Memo" and "Abstract" should not be numbered.
"Specification of Requirements" is not now usually numbered.

Abstract must not contain citations except through full naming.

Notwithstanding RFC3471 section 4, I think you would be wise to enhance your use of
"downstream data channel" etc. with some text like "i.e., from initiator to terminator"

Section 4.2
   Once a bundled link is determined to be alive, it can
be advertised
--->formatting

Section 4.3
   Although SHOULD NOT be used, when used, the type 5 TLV MUST NOT be
"Although it SHOULD NOT"
   the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV.

Section 5.9
   The Resource Classes for a bundled link are the same as those of the
   component link
s.
---> formatting

Section 8.1
   [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS
   Extensions in Support of Generalized MPLS", draft-ietf-ibis-gmpls-
   extensions-11.txt (work in progress)
"ibis"?

Delivery-date: Sat, 20 Nov 2004 14:37:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Incoming communication from the OIF
Date: Sat, 20 Nov 2004 14:32:55 -0000

You're right Dimitri,

There are only a couple of small points to respond to.
I'd welcome suggestions of text.

> 1. issue of loss of RSVP signaling adjacency to trigger procedure of
> draft-ietf-ccamp-ospf-gmpls-extensions

My view is that no change to the base spec is needed or appropriate, but we'd be happy to
see ann Applicability I-D if someone want to write one.

> 2. and the reachability advertisement

I admit to being confused by the prospect of summarising TNAs.

Adrian

Delivery-date: Fri, 19 Nov 2004 23:37:46 +0000
Date: Sat, 20 Nov 2004 00:36:17 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: "Brungard, Deborah A, ALABS" <[email-masked]>
CC:  [email-masked],  Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: Incoming communication from the OIF

hi deborah,

Brungard, Deborah A, ALABS wrote:
> Hi Adrian,
> 
> On the second last item, even though "informational", it is very
> encouraging to hear that OIF has chosen to base it's UNI 2.0 IA on
> CCAMP's existing solution work. We should respond noting that we welcome
> the opportunity to collaborate with them and provide the updated status
> regarding GMPLS-UNI (which includes support of Ethernet and G709),
> GMPLS-G709, GMPLS-ASON, etc.

you mean bringing them the following documents:
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-08.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt>

could be also good to provide them with the details of RFC 3946 since it 
covers sub STS-1 signal types (hint: why only SONET is mentioned in the 
OIF liaison ?) and Ethernet (note: for the latter, i don't know if this 
is possible)

> Regards,
> Deborah
> 
> 
>>however planned UNI 2.0 features include
>>support of additional services including G.709, sub-STS-1 signal types
> 
> and Ethernet
> 
>>interfaces (using the same solutions from existing CCAMP documents).
> 
> 
> 
> .
> 

Delivery-date: Fri, 19 Nov 2004 23:05:51 +0000
From: Payam Torab <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, [email-masked],  [email-masked]
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: charter update
Date: Fri, 19 Nov 2004 18:00:35 -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_01C4CE8B.943E2736
Content-Type: text/plain;
	charset="iso-8859-1"

Kireeti, Adrian -

We support waveband switching as described in
draft-douville-ccamp-gmpls-waveband-extensions-05.txt, and would like to see
waveband switching explicitly added to the charter, if not in the charter at
this time.

We believe this work plugs a hole in the GMPLS architecture- in particular
the need to recognize waveband switch capable (WBSC) interfaces. We indeed
have interfaces that are WBSC and not LSC or FSC.

Regards,

Payam Torab
Lambda OpticalSystems Corp.

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]]  On
Behalf Of Kireeti Kompella
Sent:	Monday, November 15, 2004 10:51 AM
To:	[email-masked]
Subject:	charter update

Hi All,

If you have suggested charter updates, please send them to Adrian and
me.  Please keep this subject line (simply reply to this mail).

The deadline is Friday Nov 19, 17:00 PST.

Thanks,
Kireeti.
-------

------_=_NextPart_001_01C4CE8B.943E2736
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.2657.73">
<TITLE>RE: charter update</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Kireeti, Adrian -</FONT>
</P>

<P><FONT SIZE=3D2>We support waveband switching as described in =
draft-douville-ccamp-gmpls-waveband-extensions-05.txt, and would like =
to see waveband switching explicitly added to the charter, if not in =
the charter at this time.</FONT></P>

<P><FONT SIZE=3D2>We believe this work plugs a hole in the GMPLS =
architecture- in particular the need to recognize waveband switch =
capable (WBSC) interfaces. We indeed have interfaces that are WBSC and =
not LSC or FSC.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Payam Torab</FONT>
<BR><FONT SIZE=3D2>Lambda OpticalSystems Corp.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]&nbsp; On Behalf Of Kireeti Kompella</FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Monday, November 15, 2004 10:51 =
AM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
charter update</FONT>
</P>

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

<P><FONT SIZE=3D2>If you have suggested charter updates, please send =
them to Adrian and</FONT>
<BR><FONT SIZE=3D2>me.&nbsp; Please keep this subject line (simply =
reply to this mail).</FONT>
</P>

<P><FONT SIZE=3D2>The deadline is Friday Nov 19, 17:00 PST.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Kireeti.</FONT>
<BR><FONT SIZE=3D2>-------</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4CE8B.943E2736--

Delivery-date: Fri, 19 Nov 2004 22:18:23 +0000
content-class: urn:content-classes:message
Subject: RE: Incoming communication from the OIF
Date: Fri, 19 Nov 2004 16:15:58 -0600
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>

Hi Adrian,

On the second last item, even though "informational", it is very
encouraging to hear that OIF has chosen to base it's UNI 2.0 IA on
CCAMP's existing solution work. We should respond noting that we welcome
the opportunity to collaborate with them and provide the updated status
regarding GMPLS-UNI (which includes support of Ethernet and G709),
GMPLS-G709, GMPLS-ASON, etc.

Regards,
Deborah

> however planned UNI 2.0 features include
> support of additional services including G.709, sub-STS-1 signal types
and Ethernet
> interfaces (using the same solutions from existing CCAMP documents).

Delivery-date: Fri, 19 Nov 2004 19:10:49 +0000
Date: Fri, 19 Nov 2004 20:10:05 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC:  [email-masked]
Subject: Re: Incoming communication from the OIF

hi adrian - thanks for fwd'íng - reading here between the lines i guess 
there are two points to be addressed (others be "informational")

1. issue of loss of RSVP signaling adjacency to trigger procedure of 
draft-ietf-ccamp-ospf-gmpls-extensions

2. and the reachability advertisement

thanks,
- dimitri.

Adrian Farrel wrote:

> We have received the following communication from Jim Jones, chair of the Technical
> Committee of the OIF.
> 
> You can see the original version at http://www.olddog.co.uk/incoming.htm
> 
> Cheers,
> Adrian
> 
> ========
> 
> November 5, 2004
> Mr. Adrian Farrel, [email-masked], IETF, CCAMP Working Group Chair
> Mr. Kireeti Kompella, [email-masked], IETF, CCAMP Working Group Chair
> Re: IETF Response to Results from OIF World Interoperability Demo
> 
> Dear Adrian and Kireeti,
> Thank you for your responses to our liaison regarding our Supercomm Interoperability
> Demo. We appreciate the time and effort that was spent reviewing our liaison and your
> detailed reply, and hope for continued cooperation between our groups.
> 
> In response to your questions, we have the following information:
> - Regarding compliance with ASON: there are no compliance "tests" for ASON,
> however OIF has established a close liaison relationship with ITU-T over the past few
> years and has aligned its specifications closely with the ITU-T ASON specifications,
> especially G.8080, G.7713 and G.7713.1/2/3. We worked with ITU-T leading up to the
> Demo to make sure that our activities were considered supportive of ASON and
> welcomed by ITU-T.
> - Regarding the use of the term "domain": we have been following ITU-T G.8080 in the
> use of the term "domain". We are aware that an amendment to G.8080 is in progress in
> ITU-T. We are following work on refinements to the definition of "domain" in G.8080
> and expect that this work will also be liaised to IETF when complete.
> - Regarding the issue of loss of RSVP signaling adjacency: we thank IETF for the
> suggestion to utilize the procedures in draft-ietf-ccamp-ospf-gmpls-extensions for
> this case, which would result in the associated link being made unavailable for new
> connection requests. However, we note that the trigger identified in that draft is the
> restart of an OSPF instance, which is an independent event from loss of RSVP signaling
> adjacency due to DCN failure. Consequently we request that IETF consider the addition
> of loss of RSVP signaling adjacency as a trigger for the procedures identified in
> draft-ietf-ccamp-ospf-gmpls-extensions.
> - Regarding reachability advertisement: we also thank IETF for the suggestion to use
> the reachability advertisement document referenced in the liaison response, and would
> request also that each address entry be supplemented to include a mask length, as the
> reachable endpoints addresses may be summarizable. Including a mask would also
> allow for address packing as shown for the Extended IP Reachability TLV in RFC 3784.
> - Regarding the scope of OIF work, the existing Implementation Agreements for the
> UNI and E-NNI are SONET/SDH oriented, however planned UNI 2.0 features include
> support of additional services including G.709, sub-STS-1 signal types and Ethernet
> interfaces (using the same solutions from existing CCAMP documents). We understand
> that the ASON architecture itself is applicable to any layer network, existing and
> future, and are phasing our work based on input from our carrier members on
> capabilities that are of greatest importance to them.
> - As a clarification, all Implementation Agreements represent fully ratified
> documents, and are published on the OIF website after being voted on and approved by
> the OIF membership. Current Implementation Agreements include the UNI 1.0R2 and the
> Intra-Carrier E-NNI Signaling 1.0 specifications, available for open public access at
> http://oiforum.com/public/impagreements.html.
> 
> Sincerely,
> Jim Jones
> OIF Technical Committee Chair
> cc: [email-masked]
> 
> 
> 
> .
> 

Delivery-date: Fri, 19 Nov 2004 19:09:14 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Second incoming communication from the OIF
Date: Fri, 19 Nov 2004 19:08:47 -0000

A second communication from Jim Jones, Chair of the OIF Technical Committee, lands on my
e-doorstep.

This communication is helpfully in two files with different formats (one PDF and one
PowerPoint). I have reproduced the text below.

Again, the real copy can be found at http://www.olddog.co.uk/incoming.htm

Adrian

===

November 5, 2004
Mr. Adrian Farrel, [email-masked], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [email-masked], IETF, CCAMP Working Group Chair
Re: New OIF Project on Interworking of ASON - GMPLS Network Domains

Dear Adrian and Kireeti,

I want to inform you of a new work project that was proposed and adopted by the OIF
members at our 4Q Technical Committee meetings that took place October 26-28. The
project will result in a design guideline document to assist vendors and carriers
in optical networks where signaling interworking is required between OIF/ITU-T ASON
and GMPLS RSVP-TE.

As we have seen in interoperability trials and initial deployments, vendor
implementations sometimes use different control plane protocols, depending on the
NE requirements and function within a network. The OIF and ASON control plane
requirements were written with the knowledge that a network composed of multiple
domains could support a heterogeneous set of protocols. An NE that exists at a
boundary between network domains may support a different protocol on either side
of the boundary (for example OIF UNI on the client side and GMPLS I-NNI on the
network side).

An interworking design guideline was cited as a high priority by OIF member companies,
both carriers and vendors. It is also our understanding that an interworking guide is
not currently within the work scope of either IETF CCAMP or ITU-T SG15. An outline of
the project plan is provided in the document oif2004.442.01. Although the proposal
illustrates an example network configuration (featuring GMPLS as INNI protocol), this
is an example only and not meant to restrict interworking considerations to this model.

In contrast to OIF Implementation Agreements (IAs), the design guideline will define
optional interworking methods between existing optical control plane protocols. This
will allow software stack vendors and system vendors to map information, messages and
behaviors between different protocols while preserving the required functionality on
each side of the interface.

We expect the OIF, ITU-T and IETF will continue to work together to minimize or
eliminate differences between control plane signaling protocols. Given that different
protocols currently exist to meet different requirements, an interworking guide can
help ensure straightforward protocol interoperation. We welcome your input on this
project and look forward to future collaboration.

Sincerely,
Jim Jones
OIF Technical Committee Chair
cc: [email-masked]

====
Slide1

Project proposal for interworking of G.8080 - RFC 3473 network domains

Contribution Number: oif2004.442.00
Working Group:  Architecture & Signaling
Title: Project proposal for interworking of G.8080 - RFC 3473 network domains
Meeting: 4Q2004
Source:  Eve Varma Monica Lazer
Hans-Martin Foisel Satoru Okamoto
Jonathan Sadler Vishnu Shukla
Lyndon Ong Date: October 28, 2004
Abstract:  This contribution proposes to initiate a project with the intention of
publishing a design guideline document for interworking between OIF/ITU-T ASON control
plane interfaces (UNI, E-NNI) and IETF/GMPLS network domains.
Notice: This contribution has been created to assist the Optical Internetworking Forum
(OIF).  This document is offered to the OIF solely as a basis for discussion and is not a
binding proposal on the companies listed as resources above. Each company in the source
list, and the OIF, reserves the rights to at any time to add, amend, or withdraw
statements contained herein.
This Working Text represents work in progress by the OIF, and must not be construed as an
official OIF Technical Report.  Nothing in this document is in any way binding on the OIF
or any of its members.  The document is offered as a basis for discussion and
communication, both within and without the OIF.
For additional information contact:
The Optical Internetworking Forum, 39355 California Street,
Suite 307, Fremont, CA 94538
510-608-5990 phone F [email-masked]
© 2001 Optical Internetworking Forum
===
Slide2

Contributors and Supporters
Alcatel, Jim Jones
AT&T - Monica Lazer
Avici - Amy Wang
Ciena - Lyndon Ong
Cisco - Richard Bradford
Deutsche Telekom - Hans-Martin Foisel
Lucent - Eve Varma
NTT - Satoru Okamoto
Tellabs - Jonathan Sadler
Verizon - Vishnu Shukla
.
===
Slide3

Network graph
===
Slide4

Project Start

Objective:
Generate an design guideline document for the interoperability of OIF/ITU-T ASON and
IETF/GMPLS network domains

Scope
E-NNI, I-NNI(GMPLS) and UNI interoperability among these different network architecture
approaches

Expected Output
Design guideline document (technical report) on this topic; not an Implementation
Agreement

Interaction with other forums and standards bodies
Close cooperation with IETF/CCAMP and ITU-T,Q14/SG15
MTNM

Interaction with other OIF WG
Carrier, OAM&P, Interoperability

Why the OIF?
Interworking and interoperability among different standardization bodies specifications
and standards approaches is a key goal of the Optical Internetworking Forum
===
Slide5

Project Timeline

Project Start: This meeting (Oct 2004)
Liaison to ITU and IETF describing project scope and soliciting interest: until next
meeting
Solicit and receive contributions for 2 quarterly meetings
Baseline draft 2nd Quarter 2005
Proposed editor: Hans-Martin Foisel
Straw ballot 3rd quarter 2005
Principal ballot 1st quarter 2006
===
Slide6

Motivation: Why Now?

Broad vendor and carrier support
- Strong request from the carrier and vendor members for interworking among network
  domains, which may use IETF or OIF/ITU-T standards and specifications.
Current activities at IETF CCAMP design teams could benefit from this document
This document will be based not only on available standards and specifications but also on
first practical testing experiences
===
Slide7

References to Standards Contributions

RFC 3471, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional
Description"
RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS)Signaling Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions".
RFC 3630, "Traffic Engineering (TE) Extensions to OSPF Version 2 ".
"Routing Extensions in Support of Generalized Multi-Protocol Label Switching",
draft-ietf-ccamp-gmpls-routing-09.txt, work in progress..
OIF-UNI 1.0 Release 2, "OIF-UNI-01.0-R2-Common - User Network Interface (UNI) 1.0
Signaling Specification, Release 2: Common Part" and "OIF-UNI-01.0-R2-RSVP - RSVP
Extensions for User Network Interface (UNI) 1.0 Signaling, Release 2"
OIF E-NNI 1.0 Signaling, "OIF-E-NNI-Sig-01.0 - Intra-Carrier E-NNI Signaling
 Specification"
===
Slide8

References to Standards Contributions

ITU-T G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)"
ITU-T G.7713, "Distributed Call And Connection Management (DCM)".ITU-T
ITU-T G.7713.1, "Distributed Call and Connection Management (DCM) based on PNNI".ITU-T
ITU-T G.7713.2, "Distributed Call and Connection Management: Signalling mechanism using
GMPLS RSVP-TE".ITU-T
ITU-T G.7713.3, "Distributed Call and Connection Management: Signalling mechanism using
GMPLS CR-LDP"
ITU-T G.7715, "Architecture and Requirements for Routing in the Automatic Switched Optical
Networks".ITU-T
ITU-T G.7715.1, "ASON Routing Architecture and Requirements for Link State Protocols"
===
Slide9

References to Standards Contributions

oif2004.435: Discussion points from routing solutions design team
oif2004.383: Project proposal for interworking to RFC 3473
oif2004.357: Interworking of OIF UNI/E-NNI with RFC 3473 GMPLS
oif2004.303: IETF draft with comparison of GMPLS and ASON signaling

Delivery-date: Fri, 19 Nov 2004 18:58:35 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Incoming communication from the OIF
Date: Fri, 19 Nov 2004 18:57:00 -0000

We have received the following communication from Jim Jones, chair of the Technical
Committee of the OIF.

You can see the original version at http://www.olddog.co.uk/incoming.htm

Cheers,
Adrian

========

November 5, 2004
Mr. Adrian Farrel, [email-masked], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [email-masked], IETF, CCAMP Working Group Chair
Re: IETF Response to Results from OIF World Interoperability Demo

Dear Adrian and Kireeti,
Thank you for your responses to our liaison regarding our Supercomm Interoperability
Demo. We appreciate the time and effort that was spent reviewing our liaison and your
detailed reply, and hope for continued cooperation between our groups.

In response to your questions, we have the following information:
- Regarding compliance with ASON: there are no compliance "tests" for ASON,
however OIF has established a close liaison relationship with ITU-T over the past few
years and has aligned its specifications closely with the ITU-T ASON specifications,
especially G.8080, G.7713 and G.7713.1/2/3. We worked with ITU-T leading up to the
Demo to make sure that our activities were considered supportive of ASON and
welcomed by ITU-T.
- Regarding the use of the term "domain": we have been following ITU-T G.8080 in the
use of the term "domain". We are aware that an amendment to G.8080 is in progress in
ITU-T. We are following work on refinements to the definition of "domain" in G.8080
and expect that this work will also be liaised to IETF when complete.
- Regarding the issue of loss of RSVP signaling adjacency: we thank IETF for the
suggestion to utilize the procedures in draft-ietf-ccamp-ospf-gmpls-extensions for
this case, which would result in the associated link being made unavailable for new
connection requests. However, we note that the trigger identified in that draft is the
restart of an OSPF instance, which is an independent event from loss of RSVP signaling
adjacency due to DCN failure. Consequently we request that IETF consider the addition
of loss of RSVP signaling adjacency as a trigger for the procedures identified in
draft-ietf-ccamp-ospf-gmpls-extensions.
- Regarding reachability advertisement: we also thank IETF for the suggestion to use
the reachability advertisement document referenced in the liaison response, and would
request also that each address entry be supplemented to include a mask length, as the
reachable endpoints addresses may be summarizable. Including a mask would also
allow for address packing as shown for the Extended IP Reachability TLV in RFC 3784.
- Regarding the scope of OIF work, the existing Implementation Agreements for the
UNI and E-NNI are SONET/SDH oriented, however planned UNI 2.0 features include
support of additional services including G.709, sub-STS-1 signal types and Ethernet
interfaces (using the same solutions from existing CCAMP documents). We understand
that the ASON architecture itself is applicable to any layer network, existing and
future, and are phasing our work based on input from our carrier members on
capabilities that are of greatest importance to them.
- As a clarification, all Implementation Agreements represent fully ratified
documents, and are published on the OIF website after being voted on and approved by
the OIF membership. Current Implementation Agreements include the UNI 1.0R2 and the
Intra-Carrier E-NNI Signaling 1.0 specifications, available for open public access at
http://oiforum.com/public/impagreements.html.

Sincerely,
Jim Jones
OIF Technical Committee Chair
cc: [email-masked]

Delivery-date: Fri, 19 Nov 2004 12:15:16 +0000
Date: Fri, 19 Nov 2004 21:12:57 +0900
To: Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
From: Tomonori TAKEDA <[email-masked]>
Subject: Re: charter update
Cc: [email-masked]

Hi,

The email I posted seems get lost. Sorry if this is a redundant email...

- L1VPNs:
     Define control and measurement plane mechanisms to support L1VPNs.
     Analyze applicability of these mechanisms.

As we discussed in CCAMP WG, the work would be expected to be around the 
use and application of GMPLS protocols to support L1VPN services. (Note: 
services does not necessary mean to external customers, can be applicable 
to internal usage as well.) There may be minor protocol extensions needed 
for this.

- Implementation/Interoperability experience

Best regards,

At 07:51 04/11/15 -0800, Kireeti Kompella wrote:
>Hi All,
>
>If you have suggested charter updates, please send them to Adrian and
>me.  Please keep this subject line (simply reply to this mail).
>
>The deadline is Friday Nov 19, 17:00 PST.
>
>Thanks,
>Kireeti.
>-------

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: +81-422-59-7434

Delivery-date: Fri, 19 Nov 2004 00:40:03 +0000
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: [email-masked], Bill Fenner <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, Scott Bradner <[email-masked]>, The IETF Secretariat <[email-masked]>, [email-masked]
Subject: RE: Liaison to ITU-T Q14 of SG15 on Crankback in GMPLS Systems
Date: Thu, 18 Nov 2004 19:37:46 -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_01C4CDCF.FD8B84C0
Content-Type: text/plain;
	charset="iso-8859-1"

Dear Mr. Farrel,

Thank you for the Liaison Statement on Crankback in GMPLS Systems. We appreciate the opportunity to provide input to the work. Q14/15 will address the LS in its upcoming meeting.

Regards,

Kam Lam, Q14/15 Rapporteur

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Thursday, November 18, 2004 8:24 AM
To: Lam, Hing-Kam (Kam)
Cc: [email-masked]; Bill Fenner; 'Kireeti Kompella'; Scott Bradner; The IETF Secretariat; [email-masked]
Subject: Liaison to ITU-T Q14 of SG15 on Crankback in GMPLS Systems

To:           Mr. Kam Lam, Rapporteur for Question 14 of ITU-T Study Group 15.
From:         Adrian Farrel and Kireeti Kompella
              Co-chairs of the CCAMP Working Group of the IETF
Cc:           Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
              Scott Bradner, IETF/ITU-T Liaison Coordinator
For:          Action
Deadline:     15th December 2004
Subject:      Crankback in GMPLS Systems

Dear Mr. Lam,

The IETF's CCAMP Working Group notes that recent contributions to your question in SG15
have proposed adding the requirements, architecture and solutions for crankback
routing/signaling to your scope of work.

We would like to draw your attention to the work already done in the CCAMP Working Group
on this topic. The attached draft includes a discussion of requirements and solutions for
crankback within GMPLS systems.

The CCAMP Working Group would welcome input from SG15 on this work.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Att/
draft-ietf-ccamp-crankback-03.txt 

------_=_NextPart_001_01C4CDCF.FD8B84C0
Content-Type: text/html;
	charset="iso-8859-1"

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

<META content="MSHTML 6.00.2800.1476" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>
<P><FONT face=Arial color=#0000ff size=2>Dear Mr. Farrel,</FONT></P>
<P><FONT face=Arial color=#0000ff size=2>Thank you for the Liaison Statement 
on&nbsp;<SPAN class=969465623-18112004>Crankback in GMPLS Systems</SPAN>. We 
appreciate the opportunity to provide input to the work. Q14/15 will address the 
LS in its<SPAN class=969465623-18112004> up</SPAN>coming meeting.</FONT></P>
<P><FONT face=Arial color=#0000ff size=2>Regards,</FONT></P>
<P><FONT face=Arial color=#0000ff size=2>Kam Lam, Q14/15 
Rapporteur</FONT></P></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Adrian Farrel 
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, November 18, 2004 8:24 
  AM<BR><B>To:</B> Lam, Hing-Kam (Kam)<BR><B>Cc:</B> [email-masked]; Bill Fenner; 
  'Kireeti Kompella'; Scott Bradner; The IETF Secretariat; 
  [email-masked]<BR><B>Subject:</B> Liaison to ITU-T Q14 of SG15 on 
  Crankback in GMPLS Systems<BR><BR></FONT></DIV><FONT face=Courier 
  size=2>To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mr. Kam 
  Lam, Rapporteur for Question 14 of ITU-T Study Group 
  15.<BR>From:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Adrian Farrel and 
  Kireeti 
  Kompella<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Co-chairs of the CCAMP Working Group of the 
  IETF<BR>Cc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Alex 
  Zinin and Bill Fenner, Routing Area Directors of the 
  IETF<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Scott Bradner, IETF/ITU-T Liaison 
  Coordinator<BR>For:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Action<BR>Deadline:&nbsp;&nbsp;&nbsp;&nbsp; 15th December 
  2004<BR>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Crankback in GMPLS 
  Systems<BR><BR>Dear Mr. Lam,<BR><BR>The IETF's CCAMP Working Group notes that 
  recent contributions to your question in SG15<BR>have proposed adding the 
  requirements, architecture and solutions for crankback<BR>routing/signaling to 
  your scope of work.<BR><BR>We would like to draw your attention to the work 
  already done in the CCAMP Working Group<BR>on this topic. The attached draft 
  includes a discussion of requirements and solutions for<BR>crankback within 
  GMPLS systems.<BR><BR>The CCAMP Working Group would welcome input from SG15 on 
  this work.<BR><BR>Sincerely,<BR>Kireeti Kompella &amp; Adrian Farrel, CCAMP WG 
  chairs<BR><BR>Att/<BR>draft-ietf-ccamp-crankback-03.txt</FONT> 
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4CDCF.FD8B84C0--

Delivery-date: Thu, 18 Nov 2004 15:02:29 +0000
Reply-To: =?ks_c_5601-1987?B?sei/tcit?= <[email-masked]>
From: =?ks_c_5601-1987?B?sei/tcit?= <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: 
Bcc: 
Subject: RE: charter update
Date: Fri, 19 Nov 2004 00:01:06 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCCxpMD8tN64wcGmvu7GwCwgtOM=?= =?ks_c_5601-1987?B?tOc=?=
Content-Class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_0785_01C4CDCA.DE0AE3C0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_0785_01C4CDCA.DE0AE3C0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_0785_01C4CDCA.DE0AE3C0--

Delivery-date: Thu, 18 Nov 2004 13:56:01 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lam, Hing-Kam (Kam)" <[email-masked]>
Cc: <[email-masked]>, "Bill Fenner" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "Scott Bradner" <[email-masked]>, "The IETF Secretariat" <[email-masked]>, <[email-masked]>
Subject: Liaison to ITU-T Q14 of SG15 on Crankback in GMPLS Systems
Date: Thu, 18 Nov 2004 13:24:24 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0380_01C4CD71.EBB34750
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0381_01C4CD71.EBB34750"

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

To:           Mr. Kam Lam, Rapporteur for Question 14 of ITU-T Study =
Group 15.
From:         Adrian Farrel and Kireeti Kompella
              Co-chairs of the CCAMP Working Group of the IETF
Cc:           Alex Zinin and Bill Fenner, Routing Area Directors of the =
IETF
              Scott Bradner, IETF/ITU-T Liaison Coordinator
For:          Action
Deadline:     15th December 2004
Subject:      Crankback in GMPLS Systems

Dear Mr. Lam,

The IETF's CCAMP Working Group notes that recent contributions to your =
question in SG15
have proposed adding the requirements, architecture and solutions for =
crankback
routing/signaling to your scope of work.

We would like to draw your attention to the work already done in the =
CCAMP Working Group
on this topic. The attached draft includes a discussion of requirements =
and solutions for
crankback within GMPLS systems.

The CCAMP Working Group would welcome input from SG15 on this work.

Sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Att/
draft-ietf-ccamp-crankback-03.txt 
------=_NextPart_001_0381_01C4CD71.EBB34750
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DCourier=20
size=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Mr. Kam=20
Lam, Rapporteur for Question 14 of ITU-T Study Group=20
15.<BR>From:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Adrian =
Farrel and=20
Kireeti=20
Kompella<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
Co-chairs of the CCAMP Working Group of the=20
IETF<BR>Cc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Alex=20
Zinin and Bill Fenner, Routing Area Directors of the=20
IETF<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
Scott Bradner, IETF/ITU-T Liaison=20
Coordinator<BR>For:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
Action<BR>Deadline:&nbsp;&nbsp;&nbsp;&nbsp; 15th December=20
2004<BR>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Crankback in GMPLS=20
Systems<BR><BR>Dear Mr. Lam,<BR><BR>The IETF's CCAMP Working Group notes =
that=20
recent contributions to your question in SG15<BR>have proposed adding =
the=20
requirements, architecture and solutions for =
crankback<BR>routing/signaling to=20
your scope of work.<BR><BR>We would like to draw your attention to the =
work=20
already done in the CCAMP Working Group<BR>on this topic. The attached =
draft=20
includes a discussion of requirements and solutions for<BR>crankback =
within=20
GMPLS systems.<BR><BR>The CCAMP Working Group would welcome input from =
SG15 on=20
this work.<BR><BR>Sincerely,<BR>Kireeti Kompella &amp; Adrian Farrel, =
CCAMP WG=20
chairs<BR><BR>Att/<BR>draft-ietf-ccamp-crankback-03.txt</FONT> =
</BODY></HTML>

------=_NextPart_001_0381_01C4CD71.EBB34750--

------=_NextPart_000_0380_01C4CD71.EBB34750
Content-Type: text/plain;
	name="draft-ietf-ccamp-crankback-03.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-ccamp-crankback-03.txt"

Network Working Group                             Adrian Farrel (editor)
Internet Draft                                        Old Dog Consulting
Category: Standards Track
Expires: April 2005                                   Arun Satyanarayana
                                                    Movaz Networks, Inc.

                                                           Atsushi Iwata
                                                         Norihito Fujita
                                                         NEC Corporation

                                                    Gerald R. Ash (AT&T)

                                                            October 2004

           Crankback Signaling Extensions for MPLS Signaling
                 <draft-ietf-ccamp-crankback-03.txt>

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   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

   In a distributed, constraint-based routing environment, the
   information used to compute a path may be out of date. This means
   that Multiprotocol Label Switching (MPLS) label switched path (LSP)
   setup requests may be blocked by links or nodes without sufficient
   resources. Crankback is a scheme whereby setup failure information is
   returned from the point of failure to allow new setup attempts to be
   made avoiding the blocked resources. Crankback can also be applied to
   LSP restoration to indicate the location of the failed link or node.

   This document specifies crankback signaling extensions for use in
   MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
   RSVP for LSP Tunnels", RFC3209, so that the LSP setup request can be
   retried on an alternate path that detours around blocked links or
   nodes. This offers significant improvements in the successful setup
   and recovery ratios for LSPs, especially in situations where a large
   number of setup requests are triggered at the same time.

A. Farrel et al.                                                  Page 1
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

Table of Contents

   Section A : Problem Statement

   1. Terminology......................................................3
   2. Introduction and Framework.......................................3
   2.1. Background.....................................................3
   2.2. Repair and Restoration.........................................4
   3. Discussion: Explicit Versus Implicit Re-routing Indications......5
   4. Required Operation...............................................6
   4.1. Resource Failure or Unavailability.............................6
   4.2. Computation of an Alternate Path...............................6
   4.2.1 Information Required for Re-routing...........................7
   4.2.2 Signaling a New Route.........................................7
   4.3. Persistence of Error Information...............................7
   4.4. Handling Re-route Failure......................................7
   4.5. Limiting Re-routing Attempts...................................8
   5. Existing Protocol Support for Crankback Re-routing...............8
   5.1. RSVP-TE [RFC 3209].............................................9
   5.2. GMPLS-RSVP-TE [RFC 3473].......................................9

   Section B : Solution

   6. Control of Crankback Operation..................................10
   6.1. Requesting Crankback and Controlling In-Network Re-routing....10
   6.2. Action on Detecting a Failure.................................11
   6.3. Limiting Re-routing Attempts..................................11
   6.3.1 New Status Codes for Re-routing..............................11
   6.4. Protocol Control of Re-routing Behavior.......................11
   7. Reporting Crankback Information.................................12
   7.1. Required Information..........................................12
   7.2. Protocol Extensions...........................................12
   7.3 Guidance for Use of IF_ID Error Spec TLVs......................16
   7.3.1 General Principles...........................................16
   7.3.2 Error Report TLVs............................................17
   7.3.3 Fundamental Crankback TLVs...................................17
   7.3.4 Additional Crankback TLVs....................................18
   7.3.5 Grouping TLVs by Failure Location............................19
   7.3.6 Alternate Path identification................................20
   7.4. Action on Receiving Crankback Information.....................20
   7.4.1 Re-route Attempts............................................20
   7.4.2 Location Identifiers of Blocked Links or Nodes...............20
   7.4.3 Locating Errors within Loose or Abstract Nodes...............21
   7.4.4 When Re-routing Fails........................................21
   7.4.5 Aggregation of Crankback Information.........................21
   7.5. Notification of Errors........................................22
   7.5.1 ResvErr Processing...........................................22
   7.5.2 Notify Message Processing....................................22
   7.6. Error Values..................................................23
   7.7. Backward Compatibility........................................23
   8. Routing Protocol Interactions...................................23
   9. LSP Restoration Considerations..................................24
   9.1. Upstream of the Fault.........................................24
   9.2. Downstream of the Fault.......................................25
   10. IANA Considerations............................................25

A. Farrel et al.                                                  Page 2
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   10.1. Error Codes..................................................25
   10.2. IF_ID_ERROR_SPEC TLVs........................................25
   10.3. LSP_ATTRIBUTES Object........................................25
   11. Security Considerations........................................26
   12. Acknowledgments................................................26
   13. Intellectual Property Considerations...........................26
   14. Normative References...........................................26
   15. Informational References.......................................27
   16. Authors' Addresses.............................................28
   17. Disclaimer of Validity.........................................29
   18. Full Copyright Statement.......................................29
   A.  Experience of Crankback in TDM-based Networks..................30

Section A : Problem Statement

0. Changes

(This section to be removed before publication as an RFC.)

0.1 Changes from 01 to 02, and 02 to 03 Versions

   - Update IPR and copyright
   - Update references

0.2 Changes from 00 to 01 Versions

   - Removal of background descriptive material pertaining to TDM
     network experience from section 3 to an Appendix.
   - Removal of definition of Error Spec TLVs for unnumbered bundled
     links from section 7.2 to a separate document.
   - More detailed guidance on which Error Spec TLVs to use when.
   - Change LSP_ATTRIBUTE flags from hex values to bit numbers.
   - Typographic errors fixed.
   - Update references.

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 [RFC2119].

2. Introduction and Framework

2.1. Background

   RSVP-TE (RSVP Extensions for LSP Tunnels) [RFC3209] can be
   used for establishing explicitly routed LSPs in an MPLS
   network. Using RSVP-TE, resources can also be reserved
   along a path to guarantee or control QoS for traffic
   carried on the LSP. To designate an explicit path that
   satisfies QoS constraints, it is necessary to discern the
   resources available to each link or node in the network.
   For the collection of such resource information, routing
   protocols, such as OSPF and IS-IS , can be extended to
   distribute additional state information [RFC2702].

A. Farrel et al.                                                  Page 3
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   Explicit paths can be computed based on the distributed
   information at the LSR initiating an LSP and signaled as
   Explicit Routes during LSP establishment. Explicit Routes
   may contain 'loose hops' and 'abstract nodes' that convey
   routing through any of a collection of nodes. This
   mechanism may be used to devolve parts of the path
   computation to intermediate nodes such as area border LSRs.

   In a distributed routing environment, however, the
   resource information used to compute a constraint-based
   path may be out of date. This means that a setup request
   may be blocked, for example, because a link or node along
   the selected path has insufficient resources.

   In RSVP-TE, a blocked LSP setup may result in a PathErr
   message sent to the initiator, or a ResvErr sent to the
   terminator (egress LSR). These messages may result in the
   LSP setup being abandoned. In Generalized MPLS [RC3473]
   the Notify message may additionally be used to expedite
   notification of LSP failures to ingress and egress LSRs,
   or to a specific "repair point".

   These existing mechanisms provide a certain amount of
   information about the path of the failed LSP.

2.2. Repair and Restoration

   If the ingress LSR or intermediate area border LSR knows
   the location of the blocked link or node, the LSR can
   designate an alternate path and then reissue the setup
   request. Determination of the identity of the blocked
   link or node can be achieved by the mechanism known as
   crankback routing [PNNI, ASH1]. In RSVP-TE, crankback
   signaling requires notifying an upstream LSR of the
   location of the blocked link or node. In some cases this
   requires more information than is currently available in
   the signaling protocols.

   On the other hand, various restoration schemes for link
   or node failures have been proposed in [RFC3469] and
   include fast restoration. These schemes rely on
   the existence of a backup LSP to protect the primary, but
   if both the primary and backup paths fail it is necessary
   to re-establish the LSP on an end-to-end basis avoiding
   the known failures. Similarly, fast restoration by
   establishing a restoration path on demand after failure
   requires computation of a new LSP that avoids the known
   failures. End-to-end restoration for alternate routing
   requires the location of the failed link or node.
   Crankback routing schemes could be used to notify
   upstream LSRs of the location of the failure.

   Furthermore, in situations where many link or node
   failures occur at the same time, the difference between
   the distributed routing information and the real-time

A. Farrel et al.                                                  Page 4
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   network state becomes much greater than in normal LSP
   setups. LSP restoration might, therefore, be performed
   with inaccurate information, which is likely to cause
   setup blocking. Crankback routing could improve failure
   recovery in these situations.

   Generalized MPLS [RFC3471] extends MPLS into networks
   that manage Layer 2, TDM and lambda resources. In a
   network without wavelength converters, setup requests are
   likely to be blocked more often than in a conventional
   MPLS environment because the same wavelength must be
   allocated at each Optical Cross-Connect on an end-to-end
   explicit path. Furthermore, end-to-end restoration is the
   only way to recover LSP failures. This implies that
   crankback routing would also be useful in a GMPLS
   network, in particular in dynamic LSP re-routing cases
   (no backup LSP pre-establishment).

3. Discussion: Explicit Versus Implicit Re-routing Indications

   There have been problems in service provider networks
   when "inferring" from indirect information that re-routing
   is allowed. This document proposes the use of an explicit
   re-routing indication that explicitly authorizes re-routing.

   Various existing protocol options and exchanges including
   the error values of PathErr message [RFC2205, RFC3209]
   and the Notify message [RFC3473] allow an implementation
   to infer a situation where re-routing can be done. This
   allows for recovery from network errors or resource
   contention.

   However, such inference of recovery signaling is not always
   desirable since it may be doomed to failure.  For example,
   experience of using release messages in TDM-based networks for
   analogous implicit and explicit re-routing indications purposes
   provides some guidance. This background information is given in
   Appendix A."

   It is certainly the case that with topology exchange,
   such as OSPF, the ingress LSR could infer the re-routing
   condition. However, convergence of routing information is
   typically slower than the expected LSP setup times. One of
   the reasons for crankback is to avoid the overhead of
   available-link-bandwidth flooding, and to more efficiently
   use local state information to direct alternate routing
   at the ingress-LSR.

   [ASH1] shows how event-dependent-routing can just use crankback,
   and not available-link-bandwidth flooding, to decide on the
   re-route path in the network through "learning models". Reducing
   this flooding reduces overhead and can lead to the ability to
   support much larger AS sizes.

A. Farrel et al.                                                  Page 5
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   Therefore, the alternate routing should be indicated based on
   an explicit indication, and it is best to know the following
   information separately:

   - where blockage/congestion occurred
   - whether alternate routing "should" be attempted.

4. Required Operation

   Section 2 identifies some of the circumstances under which
   crankback may be useful. Crankback routing is performed as
   described in the following procedures, when an LSP setup
   request is blocked along the path, or when an existing LSP fails.

4.1. Resource Failure or Unavailability

   When an LSP setup request is blocked due to unavailable
   resources, an error message response with the location
   identifier of the blockage should be returned to the LSR
   initiating the LSP setup (ingress LSR), the area border
   LSR, the AS border LSR, or to some other repair point.

   This error message carries an error specification
   according to [RFC3209] - this indicates the cause of the
   error and the node/link on which the error occurred.
   Crankback operation may require further information as
   detailed in sections 4.2.1 and 7.

4.2. Computation of an Alternate Path

   In a flat network without partitioning, when the ingress
   LSR receives the error message it computes an alternate
   path around the blocked link or node to satisfy QoS
   constraints using link state information about the network.
   If an alternate path is found, a new LSP setup request is
   sent over this path.

   On the other hand, in a network partitioned into areas
   such as with hierarchical OSPF, an area border LSR may
   intercept and terminate the error response, and perform
   alternate (re-)routing within the downstream area.

   In a third scenario, any node within an area may act as a
   repair point. In this case, each LSR behaves much as an
   area border LSR as described above. It can intercept and
   terminate the error response, and perform alternate
   routing. This may be particularly useful where domains of
   computation are applied within the network, however if
   all nodes in the network perform re-routing it is
   possible to spend excessive network and CPU resources on
   re-routing attempts that would be better made only at
   designated re-routing nodes. This scenario is somewhat
   like 'MPLS fast re-route' [FASTRR], in which any node in
   the MPLS domain can establish 'local repair' LSPs after
   failure notification.

A. Farrel et al.                                                  Page 6
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

4.2.1 Information Required for Re-routing

   In order to correctly compute a route that avoids the
   blocking problem, a repair point LSR must gather as much
   crankback information as possible. Ideally, the repair
   node will be given the node, link and reason for the
   failure.

   However, this information may not be enough to help with
   re-computation. Consider for instance an explicit route
   that contains a non-explicit abstract node or a loose
   hop. In this case, the failed node and link is not
   necessarily enough to tell the repair point which hop in
   the explicit route has failed. The crankback information
   needs to provide the context into the explicit route.

4.2.2 Signaling a New Route

   If the crankback information can be used to compute a new
   route avoiding the blocking problem, the route can be
   signaled as an Explicit Route.

   However, it may be that the repair point does not have
   sufficient topology information to compute an Explicit
   Route that is guaranteed to avoid the failed link or
   node. In this case, Route Exclusions [EXCLUDE] may be
   particularly helpful. To achieve this, [EXCLUDE] allows
   the crankback information to be presented as route exclusions
   to force avoidance of the failed node, link or resource.

4.3. Persistence of Error Information

   The repair point LSR that computes the alternate path
   should store the location identifiers of the blockages
   indicated in the error message until the LSP is
   successfully established or until the LSR abandons re-routing
   attempts. Since crankback routing may happen more than once
   while establishing a specific LSP, a history table of all
   experienced blockages for this LSP SHOULD be maintained (at
   least until the routing protocol updates the state of this
   information) to perform an accurate path computation to
   detour all blockages.

   If a second error response is received by a repair point (while
   it is performing crankback re-routing) it should update the
   history table that lists all experienced blockages, and use the
   entire gathered information when making a further re-routing attempt.

4.4. Handling Re-route Failure

   Multiple blockages (for the same LSP) may occur, and successive
   setup retry attempts may fail. Retaining error information from
   previous attempts ensures that there is no thrashing of setup
   attempts, and knowledge of the blockages increases with each
   attempt.

A. Farrel et al.                                                  Page 7
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   It may be that after several retries, a given repair point is
   unable to compute a path to the destination (that is, the egress
   of the LSP) that avoids all of the blockages. In this case, it
   must pass the error indication upstream. It is most useful to the
   upstream nodes (and in particular the ingress LSR) that may,
   themselves, attempt new routes for the LSP setup, if the error
   indication in this case identifies all of the downstream blockages
   and also the node that has been unable to compute an alternate path.

4.5. Limiting Re-routing Attempts

   It is important to prevent an endless repetition of LSP
   setup attempts using crankback routing information after
   error conditions are signaled, or during periods of high
   congestion. It may also be useful to reduce the number of
   retries, since failed retries will increase setup latency
   and degrade performance.

   The maximum number of crankback re-routing attempts
   allowed may be limited in a variety of ways. The number
   may be limited by LSP, by node, by area or by AS. Control
   of the limit may be applied as a configuration item per
   LSP, per node, per area or per AS.

   When the number of retries at a particular node, area or
   AS is exceeded, the LSR handling the current failure
   reports the failure upstream to the next node, area or AS
   where further re-routing attempts may be attempted. It is
   important that the crankback information provided
   indicates that routing back through this node, area or AS
   will not succeed - this situation is similar to that in
   section 4.4. Note that in some circumstances, such a
   report will also mean that no further re-routing attempts
   can possibly succeed - for example, when the egress node
   is within the failed area.

   When the maximum number of retries for a specific LSP has
   been exceeded, the LSR handling the current failure
   should send an error message upstream indicating "Maximum
   number of re-routings exceeded". This error will be
   passed back to the ingress LSR with no further re-routing
   attempts. The ingress LSR may choose to retry the LSP
   setup according to local policy and might choose to re-use
   its original path or seek to compute a path that avoids
   the blocked resources. In the latter case, it may be
   useful to indicate the blocked resource in this error
   message.

5. Existing Protocol Support for Crankback Re-routing

   Crankback re-routing is appropriate for use with RSVP-TE.

   1) LSP establishment may fail because of an inability to
      route, perhaps because links are down. In this case a
      PathErr message is returned to the initiator.

A. Farrel et al.                                                  Page 8
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   2) LSP establishment may fail because resources are
      unavailable. This is particularly relevant in GMPLS where
      explicit label control may be in use. Again, a PathErr
      message is returned to the initiator.

   3) Resource reservation may fail during LSP establishment,
      as the Resv is processed. If
      resources are not available on the required link or at a
      specific node, a ResvErr message is returned to the egress
      node indicating "Admission Control failure" [RFC2205]. The
      egress is allowed to change the FLOWSPEC and try again, but
      in the event that this is not practical or not supported
      (particularly in the GMPLS context), the egress LSR may
      choose to take any one of the following actions.

      - Ignore the situation and allow recovery to happen through
        Path refresh message and refresh timeout [RFC2205].
      - Send a PathErr message towards the initiator indicating
        "Admission Control failure".
      - Send a ResvTear message towards the initiator to abort
        the LSP setup.

      Note that in multi-area/AS networks, the ResvErr might be
      intercepted and acted on at an area/AS border router.

   4) It is also possible to make resource reservations on the forward
      path as the Path message is processed. This choice is compatible
      with LSP setup in GMPLS networks [RFC3471]. In this case if
      resources are not available, a PathErr message is returned to
      initiator indicating "Admission Control failure".

   Crankback information would be useful to an upstream node (such as
   the ingress) if it is supplied on a PathErr or a Notify message that
   is sent upstream.

5.1. RSVP-TE [RFC 3209]

   In RSVP-TE a failed LSP setup attempt results in a PathErr
   message returned upstream. The PathErr message carries an
   ERROR_SPEC object, which indicates the node or interface
   reporting the error and the reason for the failure.

   Crankback re-routing can be performed explicitly avoiding
   the node or interface reported.

5.2. GMPLS-RSVP-TE [RFC 3473]

   GMPLS extends the error reporting described above by
   allowing LSRs to report the interface that is in error in
   addition to the identity of the node reporting the error.
   This further enhances the ability of a re-computing node
   to route around the error.

   GMPLS introduces a targeted Notify message that may be used to
   report LSP failures direct to a selected node. This message carries

A. Farrel et al.                                                  Page 9
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   the same error reporting facilities as described above. The Notify
   message may be used to expedite the propagation of error
   notifications, but in a network that offers crankback routing at
   multiple nodes there would need to be some agreement between LSRs
   as to whether PathErr or Notify provides the stimulus for crankback
   operation. Otherwise, multiple nodes might attempt to repair the LSP
   at the same time, because

   1) these messages can flow through different paths before
      reaching the ingress LSR, and
   2) the destination of the Notify message might not be the
      ingress LSR.

Section B : Solution

6. Control of Crankback Operation

6.1. Requesting Crankback and Controlling In-Network Re-routing

   When a request is made to set up an LSP tunnel, the ingress LSR
   should specify whether it wants crankback information to be collected
   in the event of a failure, and whether it requests re-routing
   attempts by any or specific intermediate nodes. For this purpose, a
   Re-routing Flag field is added to the protocol setup request
   messages. The corresponding values are mutually exclusive.

   No Re-routing          The ingress node MAY attempt re-routing after
                          failure. Intermediate nodes SHOULD NOT attempt
                          re-routing after failure. Nodes detecting
                          failures MUST report an error and MAY supply
                          crankback information. This is the default
                          and backwards compatible option.

   End-to-end Re-routing  The ingress node MAY attempt re-routing after
                          failure. Intermediate nodes SHOULD NOT attempt
                          re-routing after failure. Nodes detecting
                          failures MUST report an error and SHOULD
                          supply crankback information.

   Boundary Re-routing    Intermediate nodes MAY attempt re-routing
                          after failure only if they are Area Border
                          Routers or AS Border Routers. The boundary
                          (ABR/ASBR) can either decide to forward the
                          error message upstream to the ingress
                          LSR or try to select another egress boundary
                          LSR. Other intermediate nodes SHOULD NOT
                          attempt re-routing. Nodes detecting failures
                          MUST report an error and SHOULD supply
                          crankback information.

A. Farrel et al.                                                 Page 10
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   Segment-based Re-routing
                          All nodes MAY attempt re-routing after
                          failure. Nodes detecting failures MUST report
                          an error and SHOULD supply full crankback
                          information.

6.2. Action on Detecting a Failure

   A node that detects the failure to setup an LSP or the failure of an
   established LSP SHOULD act according to the Re-routing Flag passed on
   the LSP setup request.

   If Segment-based Re-routing is allowed, or if Boundary Re-routing is
   allowed and the detecting node is an ABR or ASBR, the detecting node
   MAY immediately attempt to re-route.

   If End-to-end Re-routing is indicated, or if Segment-based or
   Boundary Re-routing is allowed and the detecting node chooses
   not to make re-routing attempts (or has exhausted all possible
   re-routing attempts), the detecting node MUST return a protocol
   error indication and SHOULD include full crankback information.

6.3. Limiting Re-routing Attempts

   Each repair point SHOULD apply a locally configurable
   limit to the number of attempts it makes to re-route an
   LSP. This helps to prevent excessive network usage in the
   event of significant faults, and allows back-off to other
   repair points which may have a better chance of routing
   around the problem.

6.3.1 New Status Codes for Re-routing

   An error code/value of "Routing Problem"/"Re-routing
   limit exceeded" (24/TBD) is used to identify that a node
   has abandoned crankback re-routing because it has reached
   a threshold for retry attempts.

   A node receiving an error response with this status code
   MAY also attempt crankback re-routing, but it is RECOMMENDED
   that such attempts be limited to the ingress LSR.

6.4. Protocol Control of Re-routing Behavior

   The Session Attributes Object in RSVP-TE is used on Path
   messages to indicate the capabilities and attributes of the
   session. This object contains an 8-bit flag field which is
   used to signal individual Boolean capabilities or attributes.
   The Re-Routing Flag described in section 5.1 would fit
   naturally into this field, but there is a scarcity of bits, so
   use is made of the new LSP_ATTRIBUTES object defined in
   [LSP-ATTRIB]. Three bits are defined for inclusion in the LSP
   Attributes TLV as follows. The bit numbers below are suggested
   and actual values are TBD by IETF consensus.

A. Farrel et al.                                                 Page 11
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   Bit     Name and Usage
   Number

      1    End-to-end re-routing desired.
           This flag indicates the end-to-end re-routing behavior
           for an LSP under establishment. This MAY also be used
           for specifying the behavior of end-to-end LSP restoration
           for established LSPs.

      2    Boundary re-routing desired.
           This flag indicates the boundary re-routing
           behavior for an LSP under establishment.
           This MAY also be used for specifying the
           segment-based (hierarchical) LSP restoration
           for established LSPs. The boundary ABR/ASBR
           can either decide to forward the PathErr
           message upstream to the Head-end LSR or try
           to select another egress boundary LSR.

      3    Segment-based re-routing desired.
           This flag indicates the segment-based
           re-routing behavior for an LSP under
           establishment. This MAY also be used
           for specifying the segment-based LSP
           restoration for established LSPs.

7. Reporting Crankback Information

7.1. Required Information

   As described above, full crankback information SHOULD
   indicate the node, link and other resources, which have
   been attempted but have failed because of allocation
   issues or network failure.

   The default crankback information SHOULD include the
   interface and the node address.

7.2. Protocol Extensions

   [RFC3473] defines an IF_ID ERROR_SPEC object that can be
   used on PathErr, ResvErr and Notify messages to convey
   the information carried in the Error Spec Object defined
   in [RFC 3209]. Additionally, the IF_ID ERROR_SPEC Object
   has scope for carrying TLVs that identify the link
   associated with the error.

   The TLVs for use with this object are defined in [RFC3471], and
   are listed below. They are used to identify links in the IF_ID
   PHOP Object and in the IF_ID ERROR_SPEC object to identify the
   failed resource which is usually the downstream resource from
   the reporting node.

A. Farrel et al.                                                 Page 12
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   Type Length Format     Description
   --------------------------------------------------------------------
    1      8   IPv4 Addr. IPv4                    (Interface address)
    2     20   IPv6 Addr. IPv6                    (Interface address)
    3     12   Compound   IF_INDEX                (Interface index)
    4     12   Compound   COMPONENT_IF_DOWNSTREAM (Component interface)
    5     12   Compound   COMPONENT_IF_UPSTREAM   (Component interface)

   Two further TLVs are defined in [TE-BUNDLE] for use in the IF_ID
   PHOP Object and in the IF_ID ERROR_SPEC object to identify component
   links of unnumbered interfaces. Note that the Type values shown here
   are only suggested values in [TE-BUNDLE] - final values are TBD and
   to be determined by IETF consensus.

   Type Length Format     Description
   --------------------------------------------------------------------
    6     16   Compound   UNUM_COMPONENT_IF_DOWN  (Component interface)
    7     16   Compound   UNUM_COMPONENT_IF_UP    (Component interface)

   In order to facilitate reporting of crankback information, the
   following additional TLVs are defined. Note that the Type values
   shown here are only suggested values - final values are TBD and to be
   determined by IETF consensus.

   Type Length Format     Description
   --------------------------------------------------------------------
    8    var   See below  DOWNSTREAM_LABEL        (GMPLS label)
    9    var   See below  UPSTREAM_LABEL          (GMPLS label)
   10      8   See below  NODE_ID                 (Router Id)
   11      x   See below  OSPF_AREA               (Area Id)
   12      x   See below  ISIS_AREA               (Area Id)
   13      8   See below  AUTONOMOUS_SYSTEM       (Autonomous system)
   14    var   See below  ERO_CONTEXT             (ERO subobject)
   15    var   See below  ERO_NEXT_CONTEXT        (ERO subobjects)
   16      8   IPv4 Addr. PREVIOUS_HOP_IPv4       (Node address)
   17     20   IPv6 Addr. PREVIOUS_HOP_IPv6       (Node address)
   18      8   IPv4 Addr. INCOMING_IPv4           (Interface address)
   19     20   IPv6 Addr. INCOMING_IPv6           (Interface address)
   20     12   Compound   INCOMING_IF_INDEX       (Interface index)
   21     12   Compound   INCOMING_COMP_IF_DOWN   (Component interface)
   22     12   Compound   INCOMING_COMP_IF_UP     (Component interface)
   23     16   See below  INCOMING_UNUM_COMP_DOWN (Component interface)
   24     16   See below  INCOMING_UNUM_COMP_UP   (Component interface)
   25    var   See below  INCOMING_DOWN_LABEL     (GMPLS label)
   26    var   See below  INCOMING_UP_LABEL       (GMPLS label)
   27      8   See below  REPORTING_NODE_ID       (Router Id)
   28      x   See below  REPORTING_OSPF_AREA     (Area Id)
   29      x   See below  REPORTING_ISIS_AREA     (Area Id)
   30      8   See below  REPORTING_AS            (Autonomous system)
   31    var   See below  PROPOSED_ERO            (ERO subobjects)
   32    var   See below  NODE_EXCLUSIONS         (List of nodes)
   33    var   See below  LINK_EXCLUSIONS         (List of interfaces)

A. Farrel et al.                                                 Page 13
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   For types 1, 2, 3, 4 and 5, the format of the Value field
   is already defined in [RFC3471].

   For types 6 and 7 the format of the Value field is already
   defined in [TE-BUNDLE].

   For types 16 and 18, they format of the Value field is
   the same as for type 1.

   For types 17 and 19, the format of the Value field is the
   same as for type 2.

   For types 20, 21 and 22, the formats of the Value fields
   are the same as for types 3, 4 and 5 respectively.

   For types 23 and 24 the Value field is the same as for
   types 6 and 7 respectively.

   For types 8, 9, 25 and 26 the length field is variable
   and the Value field is a label as defined in [RFC3471].
   As with all uses of labels, it is assumed that any node
   that can process the label information knows the syntax
   and semantics of the label from the context. Note that
   all TLVs are zero-padded to a multiple four octets so
   that if a label is not itself a multiple of four octets
   it must be disambiguated from the trailing zero pads by
   knowledge derived from the context.
   For types 10 and 27 the Value field has the format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Router Id                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Router Id: 32 bits

          The Router Id used to identify the node within the IGP.

   For types 11 and 28 the Value field has the format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     OSPF Area Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       OSPF Area Identifier

          The 4-octet area identifier for the node. In the case of
          ABRs, this identifies the area where the failure has occurred.

A. Farrel et al.                                                 Page 14
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   For types 12 and 29 the Value field has the format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Length      |     ISIS Area Identifier                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                     ISIS Area Identifier (continued)          ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Length

          Length of the actual (non-padded) ISIS Area Identifier
          in octets. Valid values are from 2 to 11 inclusive.

       ISIS Area Identifier

          The variable-length ISIS area identifier. Padded with
          trailing zeroes to a four-octet boundary.

   For types 13 and 30 the Value field has the format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Autonomous System Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Autonomous System Number: 32 bits

          The AS Number of the associated Autonomous System. Note
          that if 16-bit AS numbers are in use, the low order bits
          (16 through 31) should be used and the high order bits
          (0 through 15) should be set to zero.

   For types 14, 15 and 31 the Value field has the format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                       ERO Subobjects                          ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       ERO Subobjects:

          A sequence of ERO subobjects. Any ERO subobjects are
          allowed whether defined in [RFC3209], [RFC3473] or other
          documents. Note that ERO subobjects contain their own
          type and length fields.

A. Farrel et al.                                                 Page 15
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   For type 32 the Value field has the format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                       Node Identifiers                        ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Node Identifiers:

          A sequence of TLVs as defined here of types 1, 2 or 10
          that indicates downstream nodes that have already
          participated in crankback attempts and have been declared
          unusable for the current LSP setup attempt.

   For type 33 the Value field has the format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                       Link Identifiers                        ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Link Identifiers:

          A sequence of TLVs as defined here of types 3, 4, 5, 6 or 7
          that indicates incoming interfaces at downstream nodes that
          have already participated in crankback attempts and have
          been declared unusable for the current LSP setup attempt.

7.3 Guidance for Use of IF_ID ERROR_SPEC TLVs

7.3.1 General Principles

   If crankback is not being used but an IF-ID ERROR_SPEC
   object is included in a PathErr, ResvErr or Notify
   message, the sender SHOULD include one of the TLVs of
   type 1 through 5 as described in [RFC3473]. A sender that
   wishes to report an error with a component link of an
   unnumbered bundle SHOULD use the new TLVs of type 6 or 7
   as defined in this document. A sender MAY include
   additional TLVs from the range 8 through 33 to report
   crankback information, although this information will at
   most only be used for logging.

   If crankback is being used, the sender of a PathErr,
   ResvErr or Notify message MUST use the IF_ID ERROR_SPEC
   object and MUST include at least one of the TLVs in the
   range 1 through 7 as described in [RFC3473] and the
   previous paragraph. Additional TLVs SHOULD also be
   included to report further information. The following

A. Farrel et al.                                                 Page 16
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   section gives advice on which TLVs should be used under
   different circumstances, and which TLVs must be supported
   by LSRs.

   Note that all such TLVs are optional and MAY be omitted.
   Inclusion of the optional TLVs SHOULD be performed where
   doing so helps to facilitate error reporting and crankback.
   The TLVs fall into three categories: those that are essential
   to report the error, those that provide additional information
   that is or may be fundamental to the utility of crankback, and
   those that provide additional information that may be useful for
   crankback in some circumstances.

   Note that all LSRs MUST be prepared to receive and forward any
   TLV as per [RFC3473]. There is, however, no requirement for an
   LSR to actively process any but the error report TLVs. An LSR
   that proposes to perform crankback re-routing SHOULD support
   receipt and processing of all of the fundamental crankback TLVs,
   and is RECOMMENDED to support the receipt and processing of
   the additional crankback TLVs.

   It should be noted, however, that some assumptions about the
   TLVs that will be used MAY be made based on the deployment
   scenarios. For example, a router that is deployed in a
   single-area network does not need to support the receipt and
   processing of TLV types 28 and 29. Those TLVs might be inserted
   in an IF_ID ERROR_SPEC object, but would not need to be processed
   by the receiver of a PathErr message.

7.3.2 Error Report TLVs

   Error Report TLVs are those in the range 1 through 7.

   As stated above, when crankback information is reported,
   the IF_ID ERROR_SPEC object MUST be used. When the IF_ID
   ERROR_SPEC object is used, at least one of the TLVs in
   the range 1 through 7 MUST be present. The choice of which
   TLV to use will be dependent on the circumstance of the error
   and device capabilities. For example, a device that does not
   support IPv6 will not need the ability to create a TLV of type
   2. Note, however, that such a device MUST still be prepared
   to receive and process all error report TLVs.

7.3.3 Fundamental Crankback TLVs

   Many of the TLVs report the specific resource that has
   failed. For example, TLV type 1 can be used to report that
   the setup attempt was blocked by some form of resource
   failure on a specific interface identified by the IP
   address supplied. TLVs in this category are 1 through 13.

   These TLVs SHOULD be supplied whenever the node detecting
   and reporting the failure with crankback information has
   the information available.

A. Farrel et al.                                                 Page 17
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   The use of TLVs of type 10, 11, 12 and 13, MAY, however, be
   omitted according to local policy and relevance of the
   information.

7.3.4 Additional Crankback TLVs

   Some TLVs help to locate the fault within the context of
   the path of the LSP that was being set up. TLVs of types
   14, 15, 16 and 17 help to set the context of the error
   within the scope of an explicit path that has loose hops
   or non-precise abstract nodes. The ERO context
   information is not always a requirement, but a node may
   notice that it is a member of the next hop in the ERO
   (such as a loose or non-specific abstract node) and
   deduce that its upstream neighbor may have selected the
   path using next hop routing. In this case, providing the
   ERO context will be useful to the node further that
   performs re-routing.

   Reporting nodes SHOULD also supply TLVs from the range 14
   through 26 as appropriate for reporting the error. The
   reporting nodes MAY also supply TLVs from the range 27
   through 33.

   Note that in deciding whether a TLV in the range 14
   through 26 "is appropriate", the reporting node should
   consider amongst other things, whether the information is
   pertinent to the cause of the failure. For example, when
   a cross-connection fails it may be that the outgoing
   interface is faulted, in which case only the interface
   (for example, TLV type 1) needs to be reported, but if
   the problem is that the incoming interface cannot be
   connected to the outgoing interface because of temporary
   or permanent cross-connect limitations, the node should
   also include reference to the incoming interface (for
   example, TLV type 18).

   Four TLVs (27, 28, 29 and 30) allow the location of the
   reporting node to be expanded upon. These TLVs would not
   be included if the information is not of use within the
   local system, but might be added by ABRs relaying the
   error. Note that the Reporting Node Id (TLV 27) need not
   be included if the IP address of the reporting node as
   indicated in the ERROR_SPEC itself, is sufficient to
   fully identify the node.

   The last three TLVs (31, 32, and 33) provide additional
   information for recomputation points. The reporting node
   (or some node forwarding the error) may supply
   suggestions about the ERO that could have been used to
   avoid the error. As the error propagates back upstream
   and as crankback routing is attempted and fails, it is
   beneficial to collect lists of failed nodes and links so
   that they will not be included in further computations

A. Farrel et al.                                                 Page 18
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   performed at upstream nodes. Theses lists may also be
   factored into route exclusions [EXCLUDE].

   Note that there is no ordering requirement on any of the
   TLVs within the IF_ID Error Spec, and no implication
   should be drawn from the ordering of the TLVs in a
   received IF_ID Error Spec.

   It is left as an implementation detail precisely when to
   include each of the TLVs according to the capabilities of
   the system reporting the error.

7.3.5 Grouping TLVs by Failure Location

   Further guidance as to the inclusion of crankback TLVs can be given
   by grouping the TLVs according to the location of the failure and
   the context within which it is reported. For example, a TLV that
   reports an area identifier would only need to be included as the
   crankback error report transits an area boundary.

   Although discussion of aggregation of crankback information is out
   of the scope of this document, it should be noted that this topic is
   closely aligned to the information presented here.

   Resource Failure
            8      DOWNSTREAM_LABEL
            9      UPSTREAM_LABEL
   Interface failures
            1      IPv4
            2      IPv6
            3      IF_INDEX
            4      COMPONENT_IF_DOWNSTREAM
            5      COMPONENT_IF_UPSTREAM
            6      UNUM_COMPONENT_IF_DOWN
            7      UNUM_COMPONENT_IF_UP
           14      ERO_CONTEXT
           15      ERO_NEXT_CONTEXT
           16      PREVIOUS_HOP_IPv4
           17      PREVIOUS_HOP_IPv6
           18      INCOMING_IPv4
           19      INCOMING_IPv6
           20      INCOMING_IF_INDEX
           21      INCOMING_COMP_IF_DOWN
           22      INCOMING_COMP_IF_UP
           23      INCOMING_UNUM_COMP_DOWN
           24      INCOMING_UNUM_COMP_UP
           25      INCOMING_DOWN_LABEL
           26      INCOMING_UP_LABEL
   Node failures
           10      NODE_ID
           27      REPORTING_NODE_ID
   Area failures
           11      OSPF_AREA
           12      ISIS_AREA
           28      REPORTING_OSPF_AREA

A. Farrel et al.                                                 Page 19
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

           29      REPORTING_ISIS_AREA
           31      PROPOSED_ERO
           32      NODE_EXCLUSIONS
           33      LINK_EXCLUSIONS
   AS failures
           13      AUTONOMOUS_SYSTEM
           30      REPORTING_AS

7.3.6 Alternate Path identification

   No new object is used to distinguish between Path/Resv messages
   for an alternate LSP. Thus, the alternate LSP uses the same
   SESSION and SENDER_TEMPLATE/FILTER_SPEC objects as the ones used
   for the initial LSP under re-routing.

7.4. Action on Receiving Crankback Information

7.4.1 Re-route Attempts

   As described in section 3, a node receiving crankback information
   in a PathErr must first check to see whether it is allowed to
   perform re-routing. This is indicated by the Re-routing Flags in
   the SESSION_ATTRIBUTE object during LSP setup request.

   If a node is not allowed to perform re-routing it should
   forward the PathErr message, or if it is the ingress
   report the LSP as having failed.

   If re-routing is allowed, the node should attempt to compute a path
   to the destination using the original (received) explicit path and
   excluding the failed/blocked node/link. The new path should be added
   to an LSP setup request as an explicit route and signaled.

   LSRs performing crankback re-routing should store all received
   crankback information for an LSP until the LSP is successfully
   established or until the node abandons its attempts to re-route
   the LSP. This allows the combination of crankback information
   from multiple failures when computing an alternate path.

   It is an implementation decision whether the crankback
   information is discarded immediately upon successful LSP
   establishment or retained for a period in case the LSP fails.

7.4.2 Location Identifiers of Blocked Links or Nodes

   In order to compute an alternate path by crankback re-routing,
   it is necessary to identify the blocked links or nodes and
   their locations. The common identifier of each link or node
   in an MPLS network should be specified. Both
   protocol-independent and protocol- dependent identifiers
   may be specified. Although a general identifier that is
   independent of other protocols is preferable, there are a
   couple of restrictions on its use as described in the
   following subsection.

A. Farrel et al.                                                 Page 20
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   In link state protocols such as OSPF and IS-IS , each
   link and node in a network can be uniquely identified.
   For example, by the context of a Router ID and the Link
   ID. If the topology and resource information obtained by
   OSPF advertisements is used to compute a constraint-based
   path, the location of a blockage can be represented by
   such identifiers.

   Note that, when the routing-protocol-specific link
   identifiers are used, the Re-routing Flag on the LSP
   setup request must have been set to show support for
   boundary or segment-based re-routing.

   In this document, we specify routing protocol specific
   link and node identifiers for OSPFv2 for IPv4, IS-IS for
   IPv4, OSPF for IPv6, and IS-IS for IPv6. These
   identifiers may only be used if segment-based re-routing
   is supported, as indicated by the Routing Behavior flag
   on the LSP setup request.

7.4.3 Locating Errors within Loose or Abstract Nodes

   The explicit route on the original LSP setup request may
   contain a loose or an Abstract Node. In these cases, the
   crankback information may refer to links or nodes that
   were not in the original explicit route.

   In order to compute a new path, the repair point may need
   to identify the pair of hops (or nodes) in the explicit
   route between which the error/blockage occurred.

   To assist this, the crankback information reports the top
   two hops of the explicit route as received at the
   reporting node. The first hop will likely identify the
   node or the link, the second hop will identify a 'next'
   hop from the original explicit route.

7.4.4 When Re-routing Fails

   When a node cannot or chooses not to perform crankback
   re-routing it must forward the PathErr message further upstream.

   However, when a node was responsible for expanding or
   replacing the explicit route as the LSP setup was
   processed it MUST update the crankback information with
   regard to the explicit route that it received. Only if
   this is done will the upstream nodes stand a chance of
   successfully routing around the problem.

7.4.5 Aggregation of Crankback Information

   When a setup blocking error or an error in an established
   LSP occurs and crankback information is sent in an error
   notification message, some node upstream may choose to
   attempt crankback re-routing. If that node's attempts at

A. Farrel et al.                                                 Page 21
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   re-routing fail the node will accumulate a set of failure
   information. When the node gives up it must propagate the
   failure message further upstream and include crankback
   information when it does so.

   There is not scope in the protocol extensions described
   in this document to supply a full list of all of the
   failures that have occurred. Such a list would be
   indefinitely long and would include more detail than is
   required. However, TLVs 32 and 33 allow lists of unusable
   links and nodes to be accumulated as the failure is
   passed back upstream.

   Aggregation may involve reporting all links from a node
   as unusable by flagging the node as unusable, or flagging
   an ABR as unusable when there is no downstream path
   available, and so on. The precise details of how
   aggregation of crankback information is performed are
   beyond the scope of this document.

7.5. Notification of Errors

7.5.1 ResvErr Processing

   As described above, the resource allocation failure for
   RSVP-TE may occur on the reverse path when the Resv
   message is being processed. In this case, it is still
   useful to return the received crankback information to
   the ingress LSR. However, when the egress LSR receives
   the ResvErr message, per RFC 2205 it still has the option
   of re-issuing the Resv with different resource
   requirements (although not on an alternate path).

   When a ResvErr carrying crankback information is received at
   an egress LSR, the egress LSR MAY ignore this object and
   perform the same actions as for any other ResvErr. However,
   if the egress LSR supports the crankback extensions defined
   in this document, and after all local recovery procedures
   have failed, it SHOULD generate a PathErr message carrying
   the crankback information and send it to the ingress LSR.

   If a ResvErr reports on more than one FILTER_SPEC
   (because the Resv carried more than one FILTER_SPEC) then
   only one set of crankback information should be present
   in the ResvErr and it should apply to all FILTER_SPEC
   carried. In this case, it may be necessary per [RFC 2205]
   to generate more than one PathErr.

7.5.2 Notify Message Processing

   [RFC3473] defines the Notify message to enhance error
   reporting in RSVP-TE networks. This message is not
   intended to replace the PathErr and ResvErr messages. The
   Notify message is sent to addresses requested on the Path
   and Resv messages. These addresses could (but need not)

A. Farrel et al.                                                 Page 22
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   identify the ingress and egress LSRs respectively.

   When a network error occurs, such as the failure of link
   hardware, the LSRs that detect the error MAY send Notify
   messages to the requested addresses. The type of error
   that causes a Notify message to be sent is an
   implementation detail.

   In the event of a failure, an LSR that supports [RFC3473]
   and the crankback extensions defined in this document MAY
   choose to send a Notify message carrying crankback
   information. This would ensure a speedier report of the
   error to the ingress/egress LSRs.

7.6. Error Values

   Error values for the Error Code "Admission Control
   Failure" are defined in [RFC2205]. Error values for the
   error code "Routing Problem" are defined in [RFC 3209]
   and [RFC 3473].

   A new error value is defined for the error code "Routing
   Problem". "Re-routing limit exceeded" indicates that re-routing
   has failed because the number of crankback re-routing attempts
   has gone beyond the predetermined threshold at an individual LSR.

7.7. Backward Compatibility

   It is recognized that not all nodes in an RSVP-TE network
   will support the extensions defined in this document. It
   is important that an LSR that does not support these
   extensions can continue to process a PathErr, ResvErr or
   Notify message even if it carries the newly defined IF_ID
   ERROR_SPEC information (TLVs).

8. Routing Protocol Interactions

   If the routing-protocol-specific link or node identifiers
   are used in the Link and Node IF_ID ERROR_SPEC TLVs
   defined above, the signaling has to interact with the
   OSPF/IS-IS routing protocol.

   For example, when an intermediate LSR issues a PathErr
   message, the signaling module of the intermediate LSR
   should interact with the routing logic to determine the
   routing-protocol-specific link or node ID where the
   blockage or fault occurred and carry this information
   onto the Link TLV and Node TLV inside the IF_ID
   ERROR_SPEC object. The ingress LSR, upon receiving the
   error message, should interact with the routing logic to
   compute an alternate path by pruning the specified link
   ID or node ID in the routing database.

   Procedures concerning these protocol interactions are out
   of scope of this document.

A. Farrel et al.                                                 Page 23
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

9. LSP Restoration Considerations

   LSP restoration is performed to recover an established
   LSP when a failure occurs along the path. In the case of
   LSP restoration, the extensions for crankback re-routing
   explained above can be applied for improving performance.
   This section gives an example of applying the above
   extensions to LSP restoration. The goal of this example
   is to give a general overview of how this might work, and
   not to give a detailed procedure for LSP restoration.

   Although there are several techniques for LSP
   restoration, this section explains the case of on-demand
   LSP restoration, which attempts to set up a new LSP on
   demand after detecting an LSP failure.

9.1. Upstream of the Fault

   When an LSR detects a fault on an adjacent downstream
   link or node, a PathErr message is sent upstream. In
   GMPLS, the ERROR_SPEC object may carry a
   Path_State_Remove_Flag indication. Each LSR receiving the
   message then releases the corresponding LSP. (Note that
   if the state removal indication is not present on the
   PathErr message, the ingress node must issue a PathTear
   message to cause the resources to be released.) If the
   failed LSP has to be restored at an upstream LSR, the
   IF_ID ERROR SPEC that includes the location information
   of the failed link or node is included in the PathErr
   message. The ingress, intermediate area border LSR, or
   indeed any repair point permitted by the Re-routing
   Flags, that receives the PathErr message can terminate
   the message and then perform alternate routing.

   In a flat network, when the ingress LSR receives the
   PathErr message with the IF_ID ERROR_SPEC TLVs, it
   computes an alternate path around the blocked link or
   node satisfying the QoS constraints. If an alternate path
   is found, a new Path message is sent over this path
   toward the egress LSR.

   In a network segmented into areas, the following
   procedures can be used. As explained in Section 8.2, the
   LSP restoration behavior is indicated in the Flags field
   of the SESSION_ATTRIBUTE object of the Path message. If
   the Flags indicate "End-to-end re-routing", the PathErr
   message is returned all the way back to the ingress LSR,
   which may then issue a new Path message along another
   path, which is the same procedure as in the flat network
   case above.

   If the Flags field indicates Boundary re-routing, the
   ingress area border LSR MAY terminate the PathErr message
   and then perform alternate routing within the area for
   which the area border LSR is the ingress LSR.

A. Farrel et al.                                                 Page 24
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   If the Flags field indicates segment-based re-routing, any node
   MAY apply the procedures described above for Boundary re-routing.

9.2. Downstream of the Fault

   This section only applies to errors that occur after an
   LSP has been established. Note that an LSR that generates
   a PathErr with Path_State_Remove Flag SHOULD also send a
   PathTear downstream to clean up the LSP.

   A node that detects a fault and is downstream of the
   fault MAY send a PathErr or Notify message containing an
   IF_ID ERROR SPEC that includes the location information
   of the failed link or node, and MAY send a PathTear to
   clean up the LSP at all other downstream nodes. However,
   if the reservation style for the LSP is Shared Explicit (SE)
   the detecting LSR MAY choose not to send a PathTear - this
   leaves the downstream LSP state in place and facilitates
   make-before-break repair of the LSP re-utilizing downstream
   resources. Note that if the detecting node does not send a
   PathTear immediately then unused sate will timeout according
   to the normal rules of [RFC2205].

   At a well-known merge point, an ABR or an ASBR, a similar
   decision might also be made so as to better facilitate
   make-before-break repair. In this case a received
   PathTear might be 'absorbed' and not propagated further
   downstream for an LSP that has SE reservation style.
   Note, however, that this is a divergence from the protocol
   and might severely impact normal tear-down of LSPs.

10. IANA Considerations

10.1 Error Codes

   A new error value is defined for the RSVP-TE "Routing
   Problem" error code that is defined in [RFC3209].

   TBD     Re-routing limit exceeded.

10.2 IF_ID_ERROR_SPEC TLVs

   Note that the IF_ID_ERROR_SPEC TLV type values are not
   currently tracked by IANA. This might be a good
   opportunity to move them under IANA control. The values
   proposed by this document are found in section 7.2.

10.3 LSP_ATTRIBUTES Object

   Three bits are defined for inclusion in the LSP Attributes TLV of
   the LSP_ATTRIBUTES object in section 6.4. Suggested values are
   supplied. IANA is requested to assign those bits.

A. Farrel et al.                                                 Page 25
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

11. Security Considerations

   It should be noted that while the extensions in this document
   introduce no new security holes in the protocols, should a malicious
   user gain protocol access to the network, the crankback information
   might be used to prevent establishment of valid LSPs.

   The implementation of re-routing attempt thresholds are
   particularly important in this context.

   The crankback routing extensions and procedures for LSP restoration
   as applied to RSVP-TE introduce no further new security
   considerations. Refer to [RFC2205], [RFC3209] and [RFC3473] for a
   description of applicable security considerations.

12. Acknowledgments

   We would like to thank Juha Heinanen and Srinivas Makam
   for their review and comments, and Zhi-Wei Lin for his
   considered opinions. Thanks, too, to John Drake for
   encouraging us to resurrect this document and consider
   the use of the IF-ID ERROR SPEC object. Thanks for a
   welcome and very thorough review by Dimitri Papadimitriou.

   Simon Marshall-Unitt made contributions to this draft.

13. Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at ietf-
   [email-masked].

14. Normative References

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

A. Farrel et al.                                                 Page 26
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   [RFC2205]    R. Braden, et al., "Resource ReSerVation Protocol (RSVP)
                Version 1 Functional Specification", RFC2205, September
                1997.

   [RFC3209]    D. Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP
                Tunnels", RFC3209, December 2001.

   [RFC3471]    P. Ashwood-Smith and L. Berger, et al., "Generalized
                MPLS - Signaling Functional Description", RFC 3471,
                January 2003.

   [RFC3473]    L. Berger, et al., "Generalized MPLS Signaling - RSVP-TE
                Extensions", RFC 3473, January 2003.

   [LSP-ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of
                Attributes for Multiprotocol Label Switching (MPLS)
                Label Switched Path (LSP) Establishment Using RSVP-TE",
                draft-ietf-mpls-rsvpte-attributes-04.txt, July 2004,
                work in progress.

   [ASON-REQ]   D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong,
                "Requirements for Generalized MPLS (GMPLS) Signaling
                Usage and Extensions for Automatically Switched Optical
                Network (ASON)", daft-ietf-ccamp-gmpls-ason-reqts-07.txt
                October 2004, work in progress.

15. Informational References

   [ASH1]       G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS
                Routing & Related Traffic Engineering Methods for IP-,
                ATM-, & TDM-Based Multiservice Networks", May, 2002.

   [FASTRR]     Ping Pan, et al., "Fast Reroute Extensions to RSVP-TE
                for LSP Tunnels",
                draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt, May 2004
                (work in progress).

   [G8080]      ITU-T Recommendation G.808/Y.1304, Architecture for the
                Automatically Switched Optical Network (ASON), November
                2001. For information on the availability of this
                document, please see http://www.itu.int.

   [EXCLUDE]    C-Y. Lee, A. Farrel and S De Cnodder, "Exclude Routes -
                Extension to RSVP-TE",
                draft-ietf-ccamp-rsvp-te-exclude-route-02.txt, July 2004
                (work in progress).

   [PNNI]       ATM Forum, "Private Network-Network Interface
                Specification Version 1.0 (PNNI 1.0)",
                <af-pnni-0055.000>, May 1996.

   [RFC2702]    D. Awduche, et al., "Requirements for Traffic
                Engineering Over MPLS", RFC2702, September 1999.

A. Farrel et al.                                                 Page 27
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

   [RFC3469]    V. Sharma, et al., "Framework for MPLS-based Recovery",
                RFC 3469, February 2003.

   [TE-BUNDLE]  Z. Ali, A. Farrel, D. Papadimitriou, A. Satyanarayana,
                and A. Zamfir, "Generalized Multi-Protocol Label
                Switching (GMPLS) RSVP-TE signaling using Bundled
                Traffic Engineering (TE) Links",
                draft-dimitri-ccamp-gmpls-rsvp-te-bundled-links-00.txt,
                May 2004, work in progress.

16. Authors' Addresses

   Adrian Farrel (editor)
   Old Dog Consulting
   Phone:  +44 (0) 1978 860944
   EMail:  [email-masked]

   Arun Satyanarayana
   Movaz Networks, Inc.
   7926 Jones Branch Drive, Suite 615
   McLean, VA 22102
   Phone:  (+1) 703-847-1785
   EMail:  [email-masked]

   Atsushi Iwata
   NEC Corporation
   Networking Research Laboratories
   1-1, Miyazaki, 4-Chome, Miyamae-ku,
   Kawasaki, Kanagawa, 216-8555, JAPAN
   Phone: +81-(44)-856-2123
   Fax:   +81-(44)-856-2230
   EMail: [email-masked]

   Norihito Fujita
   NEC Corporation
   Networking Research Laboratories
   1-1, Miyazaki, 4-Chome, Miyamae-ku,
   Kawasaki, Kanagawa, 216-8555, JAPAN
   Phone: +81-(44)-856-2123
   Fax:   +81-(44)-856-2230
   EMail: [email-masked]

   Gerald R. Ash
   AT&T
   Room MT D5-2A01
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: (+1) 732-420-4578
   Fax:   (+1) 732-368-8659
   EMail: [email-masked]

A. Farrel et al.                                                 Page 28
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

17. Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

18. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

A. Farrel et al.                                                 Page 29
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

Appendix A. Experience of Crankback in TDM-based Networks

   Experience of using release messages in TDM-based networks for
   analogous repair and re-routing purposes provides some guidance.

   One can use the receipt of a release message with a cause value (CV)
   indicating "link congestion" to trigger a re-routing attempt at the
   originating node. However, this sometimes leads to problems.

       *--------------------*  *-----------------*
       |                    |  |                 |
       |  N2 ----------- N3-|--|----- AT--- EO2  |
       |  |              | \|  |    / |          |
       |  |              |  |--|-  /  |          |
       |  |              |  |  | \/   |          |
       |  |              |  |  | /\   |          |
       |  |              |  |--|-  \  |          |
       |  |              | /|  |    \ |          |
       |  N1 ----------- N4-|--|----- EO1        |
       |                    |  |                 |
       *--------------------*  *-----------------*
                A-1                  A-2

           Figure 1. Example of network topology

   Figure 1 illustrates four examples based on service-provider
   experiences with respect to crankback (i.e., explicit indication)
   versus implicit indication through a release with CV. In this
   example, N1, N2,N3, and N4 are located in one area (A-1), and AT,
   EO1, and EO2 are in another area (A-2).

   Note that two distinct areas are used in this example to expose the
   issues clearly. In fact, the issues are not limited to multi-area
   networks, but arise whenever path computation is distributed
   throughout the network. For example where loose routes, AS routes or
   path computation domains are used.

   1. A connection request from node N1 to EO1 may route to N4 and then
      find "all circuits busy". N4 returns a release message to N1 with
      CV34 indicating all circuits busy. Normally, a node such as N1 is
      programmed to block a connection request when receiving CV34,
      although there is good reason to try to alternate route the
      connection request via N2 and N3.

      Some service providers have implemented a technique called route
      advance (RA), where if a node that is RA capable receives a
      release message with CV34, it will use this as an implicit
      re-route indication and try to find an alternate route for the
      connection request if possible. In this example, alternate route
      N1-N2-N3-EO1 can be tried and may well succeed.

   2. Suppose a connection request goes from N2 to N3 to AT trying to
      reach EO2 and is blocked at link AT-EO2. Node AT returns a CV34
      and with RA, N2 may try to re-route N2-N1-N4-AT-EO2, but of
      course this fails again. The problem is that N2 does not realize

A. Farrel et al.                                                 Page 30
=0C
draft-ietf-ccamp-crankback-03.txt                           October 2004

      where this blocking occurred based on the CV34, and in this case
      there is no point in further alternate routing.

   3. However, in another case of a connection request from N2 to E02,
      suppose that link N3-AT is blocked. In this case N3 should return
      crankback information (and not CV34) so that N2 can alternate
      route to N1-N4-AT-EO2, which may well be successful.

   4. In a final example, for a connection request from EO1 to N2, EO1
      first tries to route the connection request directly to N3.
      However, node N3 may reject the connection request even if there
      is bandwidth available on link N3-EO1 (perhaps for priority
      routing considerations, e.g., reserving bandwidth for high
      priority connection requests). However, when N3 returns CV34 in
      the release message, EO1 blocks the connection request (a normal
      response to CV34 especially if E01-N4 is already known blocked)
      rather than trying to alternate route through AT-N3-N2, which
      might be successful. If N3 returns crankback information, EO1
      could respond by trying the alternate route.

   It is certainly the case that with topology exchange, such as OSPF,
   the ingress LSR could infer the re-routing condition. However,
   convergence of routing information is typically slower than the
   expected LSP setup times. One of the reasons for crankback is to
   avoid the overhead of available-link-bandwidth flooding, and to more
   efficiently use local state information to direct alternate routing
   at the ingress-LSR.

   [ASH1] shows how event-dependent-routing can just use crankback,
   and not available-link-bandwidth flooding, to decide on the
   re-route path in the network through "learning models". Reducing
   this flooding reduces overhead and can lead to the ability to
   support much larger AS sizes.

   Therefore, the alternate routing should be indicated based on
   an explicit indication (as in examples 3 and 4), and it is best
   to know the following information separately:

     a) where blockage/congestion occurred (as in examples 1-2),

        and

     b) whether alternate routing "should" be attempted even if
        there is no "blockage" (as in example 4).

A. Farrel et al.                                                 Page 31
=0C

------=_NextPart_000_0380_01C4CD71.EBB34750--

Delivery-date: Thu, 18 Nov 2004 13:55:38 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Stephen Shew" <[email-masked]>, <[email-masked]>
Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Thu, 18 Nov 2004 12:00:10 -0000

Stephen,

Thanks for the heads-up on the extensions to G.8080. It is good news that ITU-T is
considering how to handle interlayer call setup. Can you clarify whether this work covers
only calls or also includes connections?

It would certainly be good to have this work liaised to the IETF. It might even be nice if
it was liaised for discussion before it is consented although I realise that is not within
your personal remit.

Regards,
Adrian

> > Thank you for the pointer to G.805 and G.809.  It is very
> > important to attempt to align the terminologies so that we
> > can discover whether the architectures are the same and
> > whether they are trying to address the same problem space. It
> > is also always good to try not to reinvent the wheel.
> >
> > As you have no doubt noticed, the GMPLS architecture and
> > problem space require the capability to signal and route
> > across multiple instances of what the ITU-T terms a transport
> > layer. We would gladly look at any architecture you have in
> > this space. Can you point us at the ITU-T document(s) that
> > describe the architecture and solutions for routing and
> > signaling across multiple layers?
>
> In ITU-T Q12/15, there is recent work on extending G.8080 to cover
> interlayer call setup.  It is the aim of Q12 to have this work consented at
> the upcoming SG15 meeting (Nov.29 - Dec.3).  If completed, I will ask the
> Rapporteur to liaise this to the IETF so that the document can be shared.

[SNIP]

> I understand that GMPLS architecture does
> separate control from bearer and so I would hope that "multi-layer" remains
> a bearer term as that is understanding in ITU-T.  I think the I-D uses that
> semantic too.  As far a "region", I think the equivalent ITU-T G.8080 term
> is "domain", of which there can be different types depending on  the control
> function.  For example, a "routing domain", or "signalling domain".  It is
> my understanding from reading the draft that "region" does not distinguish
> between routing and signalling, and if so it may be helpful for creating
> multi-service networks where the extent of the services does not have to be
> the same while they may all use the multi-region path computation
> capability.

Right. The region distinguishes only the switching capability.

Adrian

Delivery-date: Thu, 18 Nov 2004 13:55:32 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Nic Neate" <[email-masked]>, <[email-masked]>
Subject: Re: GMPLS topics and issues of study
Date: Thu, 18 Nov 2004 12:34:30 -0000

This is a multi-part message in MIME format.

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

Nic,

> Following on from Richard's comments, as implementers we'd love to see
> something on the new charter for some BCPs based on GMPLS
> interop/implemenation experience.

Noted.

> In particular, we have also recently hit some issues related to the
> Interface IDs and Label Sub-object used in EROs stemming from =
confusion over
> how to interpret RFC 3473.  If anyone can clarify what is and what is =
not
> either allowed or common practice, that would be very useful.

Of course, you have to return to basics with the processing rules of =
section 4.3.4 in RFC3209 in order to understand what is expected. I =
agree wholeheartedly that this could be clearer.

> We would like to work with the following simple example, where node A =
is not
> the ingress, but C is the egress.  We've done some interop testing, =
and
> found that in some cases EROs which we considered valid did not work, =
while
> others produced unexpected results.
>=20
> Nodes:      A--------B--------C
> Interfaces:  A1    B1 B2    C1 =20
> D/S Labels     L1       L2
>=20
> Which of the following EROs, received in a Path message by Node A, =
would
> produce the LSP pictured?
>=20
> (a) {A1,L1};{B2,L2}

This is acceptable because (we assume) the Session identifies C as the =
destination. It might, however, be construed as unhelpful to prematurely =
terminate the ERO.
We can treat it exactly as case (b)

> (b) {A1,L1};{B2,L2};{C1}
> (c) {B1,L1};{C1,L2}

Note that this is illegal according to RFC3209 4.3.4.1 1)
      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.=20
The ERO received by A MUST contain a first subobject that identifies A =
in some manner.
This is policed by A.

> (d) {A1,L1};{B1,L1};{B2,L2};{C1,L2}

With the exception that it would be good for the ERO to begin with an =
incoming interface on A or some other expression of A (for example {A}), =
this qualifies as the belts and braces (aka suspenders) approach. Note, =
however, that it is not necessary to duplicate the labels because they =
will be processed on the upstream node (creating a Label Set object).
Thus {A};{A1,L1};{B1};{B2,L2};{C1} might be nice.

> Further, if some of these configurations are not allowed, where is =
that
> typically policed? =20
>=20
> Regarding option (c), it appears that some vendors expect this =
construction,
> but we're not clear how it can be accurately interpreted.  If it is =
valid,
> how can node A know whether B1 is the incoming or outgoing interface =
on node
> B (and therefore whether is has to process label L1)?  If it is not =
valid,
> can this be policed?

In order the discuss this, we must assume that the ERO looked like =
{A};{B1,L1};{C1,L2}
A's job is to route to the abstract node identified by the next =
subobject.
Thus, it must route to B1. One may assume that in a normal topology it =
will not try to do this through B2.
Further, A is not supposed to look beyond the first non-local =
sub-object. Therefore, the DS label will not be processed until the ERO =
reaches B. This is not the end of the world because it is a DS label and =
is in the purview of node B.

It is, however, perhaps easier to consider the case where upstream =
labels are used as well. This makes life a little clearer, because the =
US label MUST be processed by the US node. So the ERO =
{A};{B1,L1,L1'};etc. would not cut the mustard.

In fact, RFC3473 is quite clear in the intention that label subobjects =
(for DS labels) should be mapped to Label Set objects. This means that =
they must be processed by the US node. This in turn means that they must =
be present in a subobject immediately following an outgoing interfcase =
subobject.

So, option (c) will not (perhaps!) achieve the required results. This is =
not a matter for policing, since the ERO is valid in its way.

> Also, is an explicit hop to the egress always required (omitted in =
option
> (a)).  Does it make sense to include a label on that hop, and if so =
what
> processing should the egress node do?  In option (d) it could arguably =
just
> ignore the label, but that probably is not the case in (c).

As above:
1. It is helpful to include the destination in the ERO.
2. The label subobject is not supposed to be processed by the DS node.

Please note that if any work is done to clarify all of this it MUST =
follow the "conservative on what you send, liberal on what you receive" =
principle. We cannot have a set of rules developed that will break =
existing implementations. Rather we should seek rules that cause future =
implementations to converge while stating how existing implementations =
will understand each other.

Adrian
------=_NextPart_000_031D_01C4CD6A.F30B7BA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Nic,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; Following on from Richard's =
comments, as=20
implementers we'd love to see<BR>&gt; something on the new charter for =
some BCPs=20
based on GMPLS<BR>&gt; interop/implemenation experience.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Noted.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT><FONT face=3DCourier =
size=3D2></FONT><BR><FONT=20
face=3DCourier size=3D2>&gt; In particular, we have also recently hit =
some issues=20
related to the<BR>&gt; Interface IDs and Label Sub-object used in EROs =
stemming=20
from confusion over<BR>&gt; how to interpret RFC 3473.&nbsp; If anyone =
can=20
clarify what is and what is not<BR>&gt; either allowed or common =
practice, that=20
would be very useful.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Of course, you have to return to =
basics with the=20
processing rules of section 4.3.4 in&nbsp;RFC3209 in order to understand =
what is=20
expected. I agree wholeheartedly that this could be =
clearer.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV><FONT =
face=3DCourier size=3D2>
<DIV><BR>&gt; We would like to work with the following simple example, =
where=20
node A is not<BR>&gt; the ingress, but C is the egress.&nbsp; We've done =
some=20
interop testing, and<BR>&gt; found that in some cases EROs which we =
considered=20
valid did not work, while<BR>&gt; others produced unexpected =
results.<BR>&gt;=20
<BR>&gt; Nodes:&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;A--------B--------C<BR>&gt;=20
Interfaces:&nbsp; A1&nbsp;&nbsp;&nbsp; B1 B2&nbsp;&nbsp;&nbsp; C1&nbsp; =
<BR>&gt;=20
D/S Labels&nbsp;&nbsp;&nbsp;&nbsp; =
L1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
L2<BR>&gt; <BR>&gt; Which of the following EROs, received in a Path =
message by=20
Node A, would<BR>&gt; produce the LSP pictured?<BR>&gt; <BR>&gt; (a)=20
{A1,L1};{B2,L2}</DIV>
<DIV>&nbsp;</DIV>
<DIV>This is acceptable because (we assume) the Session identifies C as =
the=20
destination. It might, however, be construed as unhelpful to prematurely =

terminate the ERO.</DIV>
<DIV>We can treat it exactly as case (b)</DIV>
<DIV><BR>&gt; (b) {A1,L1};{B2,L2};{C1}</DIV>
<DIV>&gt; (c) {B1,L1};{C1,L2}</DIV>
<DIV>&nbsp;</DIV>
<DIV>Note that this is illegal according to RFC3209 4.3.4.1 1)</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the node is not part of the =
abstract node=20
described<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; by the first subobject, it =
has=20
received the message in error and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SHOULD=20
return a "Bad initial subobject" error. </DIV>
<DIV>The ERO received by A MUST contain a first subobject that =
identifies A in=20
some manner.</DIV>
<DIV>This is policed by A.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; (d) {A1,L1};{B1,L1};{B2,L2};{C1,L2}</DIV>
<DIV>&nbsp;</DIV>
<DIV>With the exception that it would be good for the ERO to begin with =
an=20
incoming interface on A or some other expression of A (for example {A}), =
this=20
qualifies as the belts and braces (aka suspenders) approach. Note, =
however, that=20
it is not necessary to duplicate the labels because they will be =
processed on=20
the upstream node (creating a Label Set object).</DIV>
<DIV>Thus {A};{A1,L1};{B1};{B2,L2};{C1} might be nice.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; Further, if some of these configurations are not allowed, =
where is=20
that<BR>&gt; typically policed?&nbsp; <BR>&gt; <BR>&gt; Regarding option =
(c), it=20
appears that some vendors expect this construction,<BR>&gt; but we're =
not clear=20
how it can be accurately interpreted.&nbsp; If it is valid,<BR>&gt; how =
can node=20
A know whether B1 is the incoming or outgoing interface on node<BR>&gt; =
B (and=20
therefore whether is has to process label L1)?&nbsp; If it is not =
valid,<BR>&gt;=20
can this be policed?</DIV>
<DIV>&nbsp;</DIV>
<DIV>In order the discuss this, we must assume that the ERO looked=20
like&nbsp;{A};{B1,L1};{C1,L2}</DIV>
<DIV>A's job is to route to the abstract node identified by the next=20
subobject.</DIV>
<DIV>Thus, it must route to B1. One may assume that in a normal topology =
it will=20
not try to do this through B2.</DIV>
<DIV>Further, A is not supposed to look beyond the first non-local =
sub-object.=20
Therefore, the DS label will not be processed until the ERO reaches B. =
This is=20
not the end of the world because it is a DS label and is in the purview =
of node=20
B.</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is, however, perhaps easier to consider the case where upstream =
labels=20
are used as well. This makes life a little clearer, because the US label =
MUST be=20
processed by the US node. So the ERO {A};{B1,L1,L1'};etc. would not cut =
the=20
mustard.</DIV>
<DIV>&nbsp;</DIV>
<DIV>In fact, RFC3473 is quite clear in the intention that label =
subobjects (for=20
DS labels) should be mapped to Label Set objects. This means that they =
must be=20
processed by the US node. This in turn means that they must be present =
in a=20
subobject immediately following an outgoing interfcase subobject.</DIV>
<DIV>&nbsp;</DIV>
<DIV>So, option (c) will not (perhaps!) achieve the required results. =
This is=20
not a matter for policing, since the ERO is valid in its way.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; Also, is an explicit hop to the egress always required =
(omitted in=20
option<BR>&gt; (a)).&nbsp; Does it make sense to include a label on that =
hop,=20
and if so what<BR>&gt; processing should the egress node do?&nbsp; In =
option (d)=20
it could arguably just<BR>&gt; ignore the label, but that probably is =
not the=20
case in (c).<BR></DIV>
<DIV>As above:</DIV>
<DIV>1. It is helpful to include the destination in the ERO.</DIV>
<DIV>2. The label subobject is not supposed to be processed by the DS=20
node.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Please note that if any work is done to clarify all of this it MUST =
follow=20
the "conservative on what you send, liberal on what you receive" =
principle. We=20
cannot have a set of rules developed that will break existing =
implementations.=20
Rather we should seek rules that cause future implementations to =
converge while=20
stating how existing implementations will understand each other.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Adrian</DIV></FONT></BODY></HTML>

------=_NextPart_000_031D_01C4CD6A.F30B7BA0--

Delivery-date: Thu, 18 Nov 2004 00:34:25 +0000
From: [email-masked]
To: [email-masked]
Subject: your file
Date: Thu, 18 Nov 2004 11:30:12 +1100

This is a multi-part message in MIME format.

------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

Your document.

++++ Attachment: No Virus found
++++ Norman AntiVirus - www.norman.com

------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: application/octet-stream;
	name="file_ccamp.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="file_ccamp.zip"

------=_NextPart_000_0016----=_NextPart_000_0016--

Delivery-date: Wed, 17 Nov 2004 15:32:49 +0000
From: "Zafar Ali" <[email-masked]>
To: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>
Subject: RE: charter update
Date: Wed, 17 Nov 2004 10:29:59 -0500

Hi Kireeti,=20

- L1 VPN (Re: Alex question on this subject at CCAMP WG meeting, due to =
lake
of time I was not able to come to microphone but I would like to take =
this
opportunity to mention that we do see interest in this work from the SPs =
and
IMO CCAMP should add this work to the CCAMP Charter).=20

- PCE Requirements.=20

- Graceful shutdown of TE resources, if we find it outside the current
scope.

- Deployment consideration for GMPLS, if we find it outside the current
scope.=20

- MPLS/ GMPLS interworking, if we find it outside the current scope.=20

Thanks

Regards... Zafar

>-----Original Message-----
>From: [email-masked]=20
>[mailto:[email-masked]] On Behalf Of Kireeti Kompella
>Sent: Monday, November 15, 2004 10:51 AM
>To: [email-masked]
>Subject: charter update
>
>
>Hi All,
>
>If you have suggested charter updates, please send them to=20
>Adrian and me.  Please keep this subject line (simply reply to=20
>this mail).
>
>The deadline is Friday Nov 19, 17:00 PST.
>
>Thanks,
>Kireeti.
>-------
>

Delivery-date: Tue, 16 Nov 2004 21:14:43 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-02.txt
Date: Tue, 16 Nov 2004 16:12:30 -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 - Communication of Alarm Information
	Author(s)	: L. Berger
	Filename	: draft-ietf-ccamp-gmpls-alarm-spec-02.txt
	Pages		: 18
	Date		: 2004-11-16
	
This document describes an extension to Generalized MPLS (Multi-
Protocol Label Switching) signaling to support communication of alarm
information.  GMPLS signaling already supports the control of alarm
reporting, but not the communication of alarm information.  This
document presents both a functional description and GMPLS-RSVP
specifics of such an extension.  This document also proposes
modification of the RSVP ERROR_SPEC object.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-alarm-spec-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, 16 Nov 2004 02:05:16 +0000
Date: Tue, 16 Nov 2004 11:02:05 +0900
From: Kohei Shiomoto <[email-masked]>
Organization: NTT
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

Hi Neil, all

INMO, resources in multiple regions could be optimized using GMPLS=20
protocols (note: region means the domain in which the same switching=20
technology is used). The time-scale of optimization is based on=20
carriers' policy.

See inline for additional response.

[email-masked] wrote:

>Hi Jean-Loius,
> =20
>
>>Hi Neil, all
>>
>>We do not reinvent GMPLS here, we just list a set of=20
>>functional reqs, that may lead=20
>>to minor protocol extensions.
>>By the way it seems that some of your objections applies to=20
>>GMPLS in general...
>>   =20
>>
>NH=3D>  Not really.  The co-cs mode forces some good behaviours in GMPLS=
 which we fully agree with, eg
>-	OOB control/management
>-	cannot violate connectivity requirements of the traffic data-plane
>-	fixed/known hierachy
>
>The latter forced requirement of the co-cs mode means one can have funct=
ional decoupling between the layer networks.  It also means one can choos=
e best-of-breed functional components for things like addressing, signall=
ing, OAM, etc.  'Choose' is the key word here.
>
>All of this becomes rather important when different operators wish to le=
ase capacity off each other in a client/server relationship.
For the time being, the intra operator is the first target.

> =20
>
>>Regarding one of your previous comments, please note that=20
>>dynamic capacity update is a key requirement for many SPs.=20
>>Here is a simple motivation example:
>>Let's assume for instance that a SP owns two IP networks, one=20
>>for business trafic (VPNs) and another for DSL aggregation,=20
>>both supported by the same transmission network; these two=20
>>networks are not loaded during the same time along the day,=20
>>and it would be highly useful to share transport capacity=20
>>between them and reallocate bandwidth dynamically (with a=20
>>period of several hours).
>>   =20
>>
>NH=3D> I don't dispute this at all.  The key things are:
>-	the timescales over which topology changes are effected (ie closer to =
the duct the slower the TE time-constants).....but in any case we are tal=
king S-PVCs here IMO and not SVCs (at least for the forseeable future).
>-	whether we are talking intra-operator or inter-operator.  As a represe=
ntative of FT I would expect you to fully understand that what is adverti=
sed and/or allowed to be controlled in your network(s) is a very differen=
t issue in these 2 cases.
As replied above, the intra operator is the first target. But as you=20
said, confidentiality is a issue when we go further into the=20
inter-operator case.

>>Note that the term "Toplogy" is relative. When you signal a=20
>>new TDM LSP between two routers, you may update the "IP=20
>>topology", as you setup a new IP link. This is just a=20
>>question of terminology.
>>   =20
>>
>NH=3D> Well, maybe....depends on how you are looking at this compared to=
 myself.  As per your example, when you signal a new SDH VC4 layer networ=
k trail say between 2 nodes in the IP layer network (ie a link connection=
 here) then of course you are changing the IP layer network topology.  Wh=
at I am arguing is that you cannot simply create topology on the fly (ie =
as some top level demand rippling right down to the optics/duct say) in a=
ny viable commercial manner.....esp in the inter-operator case.  That is,=
 one would create the link-connection in the client topology as a consequ=
ence of longer-term trends in traffic behaviour in the client....and when=
 we start getting down the stack, with all the will in the world, it will=
 be not possible to create a link connection where physical infrastructur=
e does not exist.  So at what the level and to what degree is a priori pr=
ovisioning done becomes a key question.  Further, I also firmly believe t=
hat strong functio
>nal decoupling is is important when we have a client/server relationship=
 between 2 different operators.....and I'd be amazed if FT held any diffe=
rent view here.
> =20
When considering the intra-operator case, optimizing resources in=20
multiple regions should be easier than inter-operator case. Again we=20
should note here that the term "Toplogy" is relative. When you set up or =

tear down a new TDM (or LSC, FSC)  LSP for instance between IP routers,=20
you may reconfigure the "IP topology". How and when the "topology" is=20
reconfigured depends on carrier's policy.

Such optimization of resources in multiple regions is feasible using=20
GMPLS-based unified control plane (note again: region means the domain=20
in which the same switching technology/capability is used). I think that =

it is worth to seek

Thank you for your comments.

--=20
Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone +81 422 59 4402    Fax +81 422 59 4549

>regards, Neil
> =20
>
>>Best Regards,
>>
>>JL
>>
>>   =20
>>
>>>-----Message d'origine-----
>>>De : [email-masked]
>>>[mailto:[email-masked]] De la part de=20
>>>     =20
>>>
>>[email-masked]
>>   =20
>>
>>>Envoy=E9 : lundi 15 novembre 2004 11:36
>>>=C0 : [email-masked]; [email-masked];=20
>>>[email-masked]; [email-masked]
>>>Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>>>
>>>
>>>John,
>>>
>>><snipped>
>>>     =20
>>>
>>>>>.....in fact a large supplier of ours recently admitted
>>>>>         =20
>>>>>
>>>>(after 3 years
>>>>       =20
>>>>
>>>>>of trying to persuade us otherwise) that they now agree=20
>>>>>         =20
>>>>>
>>with us on=20
>>   =20
>>
>>>>>this.
>>>>>         =20
>>>>>
>>>><John Drake>
>>>>
>>>>It's not unusual for a vendor that is incapable of building=20
>>>><something> to assert that <something> is a Bad IdeaTM.
>>>>       =20
>>>>
>>>NH=3D> Well, one could also look at this differently.....given
>>>we worked out the facts several years ago on our own and=20
>>>nothing has happened since to show we were wrong, then one=20
>>>could say that we know this vendor is now at least trying to=20
>>>be honest with us on this issue.
>>>     =20
>>>
>>>>>Those who think they can 'create topology on the fly' can
>>>>>         =20
>>>>>
>>>>believe in
>>>>       =20
>>>>
>>>>>this stuff if they like.....you will convince me the day I see a=20
>>>>>routing protocol lay a duct and light some fibre, till=20
>>>>>         =20
>>>>>
>>then we'll=20
>>   =20
>>
>>>>>stick with what we know is true.
>>>>>         =20
>>>>>
>>>><John Drake>
>>>>
>>>>We never said that GMPLS had a backhoe option.
>>>>       =20
>>>>
>>>NH=3D> Try this logic.....and this is only one example of a
>>>given layered network sequence:
>>>-	to run the ducts we need the back-hoe
>>>-	to run the fibre we need the ducts in place
>>>-	to run the SDH MS/RS we need the fibre in place
>>>-	to run the SDH VC4 layer network we need the SDH MS/RS in place
>>>-	to run IP/MPLS layer networks we need the VC4 layer network in
>>>place.
>>>
>>>Do you see the logical dependency?  Put simply, one cannot
>>>create topology on the fly....at some point in the above you=20
>>>are going have to assume some 'already in place/fixed'=20
>>>topology.  But it's not even as simple as that.......
>>>
>>>Let's consider some of the commercial issues here as they are
>>>rather important.  Ever tried figuring out the design rules=20
>>>required in some co-cs transport network (like SDH VC4 or OTNs=20
>>>say) so that one can 'create a trail at will' (an SVC by any=20
>>>other name)....or at least to some acceptable GoS (Grade of=20
>>>Service), ie probability of capacity being available within an=20
>>>acceptable (to the client) time period post making demand?
>>>
>>>Folks should try it some time as the results are rather
>>>illuminating. We did this with our traffic engineering maths=20
>>>group at the labs a few years ago.  Without going into the=20
>>>detail, if you want to be able to 'turn-up' seriously large BW=20
>>>trails on demand between various locations you are going to=20
>>>have a build a network that runs largely empty for most of its=20
>>>working life....now try getting a business case for this past=20
>>>the products/services/financial people ;-).
>>>
>>>And once one turns up a trail in some lower layer network, do
>>>you seriously expect we operators will turn it off?
>>>
>>>Bottom-line...as one gets closer to the duct the holding time
>>>of trails/topology must increase.
>>>
>>>Note - These issues are over/above the requirement for
>>>commercial/functional isolation between different operating=20
>>>parties in a client/server layer network relationship.
>>>
>>>regards, Neil
>>>
>>>
>>>     =20
>>>
>
>
> =20
>

Delivery-date: Mon, 15 Nov 2004 20:48:25 +0000
From: "Stephen Shew" <[email-masked]>
To: [email-masked]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Mon, 15 Nov 2004 15:46:52 -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_01C4CB54.3C5B9CC3
Content-Type: text/plain

See comments below:

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Thursday, November 11, 2004 21:18
> To: [email-masked]
> Cc: Shew, Stephen [CAR:QT00:EXCH]
> Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 
> Hi Stephen,
> 
> > I was not able to be at the CCAMP meeting today but do have some 
> > comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> Glad you were able to review the draft. Thanks for taking the 
> time. The slides for this and the other CCAMP drafts 
> discussed at the meeting can be found at 
> http://www.olddog.co.uk/61/ccamp.htm

Thanks, I've read them now.

> 
> > It seems that the 
> goals of the draft could be accomplished more simply 
> > by adopting the layer architecture as defined in ITU-T 
> Recommendations 
> > G.805 and G.809.  By doing this, the specific boundaries 
> between TDM, 
> > LSC, etc. don't have to be articulated as they are just layer 
> > networks.  Also, the designation of TDM does not include 
> the notions 
> > of the layers within that (e.g., DS3, STS-1, VC4, etc.) which are 
> > important to transport equipment. Adopting the layer 
> architecture also 
> > enables a client layer to be supported by an inverse 
> multipling layer 
> > such as provided by Virtual Concatenation. Here a layer of finer 
> > granularity is use to support a layer of coarser granularity.
> 
> Thank you for the pointer to G.805 and G.809.  It is very 
> important to attempt to align the terminologies so that we 
> can discover whether the architectures are the same and 
> whether they are trying to address the same problem space. It 
> is also always good to try not to reinvent the wheel.
> 
> As you have no doubt noticed, the GMPLS architecture and 
> problem space require the capability to signal and route 
> across multiple instances of what the ITU-T terms a transport 
> layer. We would gladly look at any architecture you have in 
> this space. Can you point us at the ITU-T document(s) that 
> describe the architecture and solutions for routing and 
> signaling across multiple layers?

In ITU-T Q12/15, there is recent work on extending G.8080 to cover
interlayer call setup.  It is the aim of Q12 to have this work consented at
the upcoming SG15 meeting (Nov.29 - Dec.3).  If completed, I will ask the
Rapporteur to liaise this to the IETF so that the document can be shared.
In discussions at the previous SG15 meeting, two important interlayer cases
were identified which I think are of architectural importance.  First, the
case where a server layer connection is created that is then presented to a
client layer as a new client layer link.  I think this is exactly how FAs
from a "lower" switching capability are handled in the draft.  In transport
networks (with or without control planes), this is commonly done (e.g.,
creating an STS-192 trail from a DWDM path).  The second case is more subtle
and involves an adaptation of the client layer into a server layer without a
new client layer link being created.  For example, a virtual concatenation
layer over a regular SDH layer (e.g., VC3-3v over VC-3).  Here there are no
VC-3-3v links or switching points at all in the network.

As of the Q12/15 interim meeting (Oct.25-29, 2004), the G.8080 interlayer
material describes how a server layer call can support a client layer call
in a similar manner as a client connection would support a client call.  The
model recurses with G.805 layers and is in fact parallel to a TeleManagement
Forum TMF814 construct called the Physical Termination Point (a network
management construct that is most useful at the edge of a network) which
contains a "stack" of adaptations.

At this point, there isn't any interlayer routing work I am aware of in the
ITU-T and draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt certainly tackles that
head on.

My original comment was made to simply the description (and hopefully
solution) of the multi-layer problem.  In particular, inverse multiplexing
capabilities are probably important and the bearer architectures suggested
really do help this.  With virtual concatentation and TDM over pseudo-wires,
there isn't going to be a strict ordering of fine to coarse granularity in
multi-layer networks.  Adopting the suggested models accomodates inverse
multiplexing as well as future layer networks.

> Thanks,
> Adrian
> 
> PS As pointed out by several people in other emails, I'm not 
> sure if we mean exactly the same thing when we say 
> multi-region and multi-layer. It would be valuable if you 
> could read the GMPLS architecture RFC and the hierarchy draft 
> and comment on whether you see these terms in the IETF 
> context as matching perfectly with ITU-T terms.

OK, I shall look at them.  I understand that GMPLS architecture does
separate control from bearer and so I would hope that "multi-layer" remains
a bearer term as that is understanding in ITU-T.  I think the I-D uses that
semantic too.  As far a "region", I think the equivalent ITU-T G.8080 term
is "domain", of which there can be different types depending on  the control
function.  For example, a "routing domain", or "signalling domain".  It is
my understanding from reading the draft that "region" does not distinguish
between routing and signalling, and if so it may be helpful for creating
multi-service networks where the extent of the services does not have to be
the same while they may all use the multi-region path computation
capability.

------_=_NextPart_001_01C4CB54.3C5B9CC3
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.2">
<TITLE>RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>See comments below:</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Adrian Farrel [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, November 11, 2004 21:18</FONT>
<BR><FONT SIZE=2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Cc: Shew, Stephen [CAR:QT00:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Stephen,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I was not able to be at the CCAMP meeting today but do have some </FONT>
<BR><FONT SIZE=2>&gt; &gt; comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Glad you were able to review the draft. Thanks for taking the </FONT>
<BR><FONT SIZE=2>&gt; time. The slides for this and the other CCAMP drafts </FONT>
<BR><FONT SIZE=2>&gt; discussed at the meeting can be found at </FONT>
<BR><FONT SIZE=2>&gt; <A HREF="http://www.olddog.co.uk/61/ccamp.htm" TARGET="_blank">http://www.olddog.co.uk/61/ccamp.htm</A></FONT>
</P>

<P><FONT SIZE=2>Thanks, I've read them now.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; It seems that the </FONT>
<BR><FONT SIZE=2>&gt; goals of the draft could be accomplished more simply </FONT>
<BR><FONT SIZE=2>&gt; &gt; by adopting the layer architecture as defined in ITU-T </FONT>
<BR><FONT SIZE=2>&gt; Recommendations </FONT>
<BR><FONT SIZE=2>&gt; &gt; G.805 and G.809.&nbsp; By doing this, the specific boundaries </FONT>
<BR><FONT SIZE=2>&gt; between TDM, </FONT>
<BR><FONT SIZE=2>&gt; &gt; LSC, etc. don't have to be articulated as they are just layer </FONT>
<BR><FONT SIZE=2>&gt; &gt; networks.&nbsp; Also, the designation of TDM does not include </FONT>
<BR><FONT SIZE=2>&gt; the notions </FONT>
<BR><FONT SIZE=2>&gt; &gt; of the layers within that (e.g., DS3, STS-1, VC4, etc.) which are </FONT>
<BR><FONT SIZE=2>&gt; &gt; important to transport equipment. Adopting the layer </FONT>
<BR><FONT SIZE=2>&gt; architecture also </FONT>
<BR><FONT SIZE=2>&gt; &gt; enables a client layer to be supported by an inverse </FONT>
<BR><FONT SIZE=2>&gt; multipling layer </FONT>
<BR><FONT SIZE=2>&gt; &gt; such as provided by Virtual Concatenation. Here a layer of finer </FONT>
<BR><FONT SIZE=2>&gt; &gt; granularity is use to support a layer of coarser granularity.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thank you for the pointer to G.805 and G.809.&nbsp; It is very </FONT>
<BR><FONT SIZE=2>&gt; important to attempt to align the terminologies so that we </FONT>
<BR><FONT SIZE=2>&gt; can discover whether the architectures are the same and </FONT>
<BR><FONT SIZE=2>&gt; whether they are trying to address the same problem space. It </FONT>
<BR><FONT SIZE=2>&gt; is also always good to try not to reinvent the wheel.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; As you have no doubt noticed, the GMPLS architecture and </FONT>
<BR><FONT SIZE=2>&gt; problem space require the capability to signal and route </FONT>
<BR><FONT SIZE=2>&gt; across multiple instances of what the ITU-T terms a transport </FONT>
<BR><FONT SIZE=2>&gt; layer. We would gladly look at any architecture you have in </FONT>
<BR><FONT SIZE=2>&gt; this space. Can you point us at the ITU-T document(s) that </FONT>
<BR><FONT SIZE=2>&gt; describe the architecture and solutions for routing and </FONT>
<BR><FONT SIZE=2>&gt; signaling across multiple layers?</FONT>
</P>

<P><FONT SIZE=2>In ITU-T Q12/15, there is recent work on extending G.8080 to cover interlayer call setup.&nbsp; It is the aim of Q12 to have this work consented at the upcoming SG15 meeting (Nov.29 - Dec.3).&nbsp; If completed, I will ask the Rapporteur to liaise this to the IETF so that the document can be shared.&nbsp; In discussions at the previous SG15 meeting, two important interlayer cases were identified which I think are of architectural importance.&nbsp; First, the case where a server layer connection is created that is then presented to a client layer as a new client layer link.&nbsp; I think this is exactly how FAs from a &quot;lower&quot; switching capability are handled in the draft.&nbsp; In transport networks (with or without control planes), this is commonly done (e.g., creating an STS-192 trail from a DWDM path).&nbsp; The second case is more subtle and involves an adaptation of the client layer into a server layer without a new client layer link being creat!
 ed.&nbsp; For example, a virtual concatenation layer over a regular SDH layer (e.g., VC3-3v over VC-3).&nbsp; Here there are no VC-3-3v links or switching points at all in the network.</FONT></P>

<P><FONT SIZE=2>As of the Q12/15 interim meeting (Oct.25-29, 2004), the G.8080 interlayer material describes how a server layer call can support a client layer call in a similar manner as a client connection would support a client call.&nbsp; The model recurses with G.805 layers and is in fact parallel to a TeleManagement Forum TMF814 construct called the Physical Termination Point (a network management construct that is most useful at the edge of a network) which contains a &quot;stack&quot; of adaptations.</FONT></P>

<P><FONT SIZE=2>At this point, there isn't any interlayer routing work I am aware of in the ITU-T and draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt certainly tackles that head on.</FONT></P>

<P><FONT SIZE=2>My original comment was made to simply the description (and hopefully solution) of the multi-layer problem.&nbsp; In particular, inverse multiplexing capabilities are probably important and the bearer architectures suggested really do help this.&nbsp; With virtual concatentation and TDM over pseudo-wires, there isn't going to be a strict ordering of fine to coarse granularity in multi-layer networks.&nbsp; Adopting the suggested models accomodates inverse multiplexing as well as future layer networks.</FONT></P>

<P><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; Adrian</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; PS As pointed out by several people in other emails, I'm not </FONT>
<BR><FONT SIZE=2>&gt; sure if we mean exactly the same thing when we say </FONT>
<BR><FONT SIZE=2>&gt; multi-region and multi-layer. It would be valuable if you </FONT>
<BR><FONT SIZE=2>&gt; could read the GMPLS architecture RFC and the hierarchy draft </FONT>
<BR><FONT SIZE=2>&gt; and comment on whether you see these terms in the IETF </FONT>
<BR><FONT SIZE=2>&gt; context as matching perfectly with ITU-T terms.</FONT>
</P>

<P><FONT SIZE=2>OK, I shall look at them.&nbsp; I understand that GMPLS architecture does separate control from bearer and so I would hope that &quot;multi-layer&quot; remains a bearer term as that is understanding in ITU-T.&nbsp; I think the I-D uses that semantic too.&nbsp; As far a &quot;region&quot;, I think the equivalent ITU-T G.8080 term is &quot;domain&quot;, of which there can be different types depending on&nbsp; the control function.&nbsp; For example, a &quot;routing domain&quot;, or &quot;signalling domain&quot;.&nbsp; It is my understanding from reading the draft that &quot;region&quot; does not distinguish between routing and signalling, and if so it may be helpful for creating multi-service networks where the extent of the services does not have to be the same while they may all use the multi-region path computation capability.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C4CB54.3C5B9CC3--

Delivery-date: Mon, 15 Nov 2004 17:14:38 +0000
From: Nic Neate <[email-masked]>
To: [email-masked]
Cc: 'Richard Rabbat' <[email-masked]>
Subject: RE: GMPLS topics and issues of study
Date: Mon, 15 Nov 2004 17:13:22 -0000

Hi all,

Following on from Richard's comments, as implementers we'd love to see
something on the new charter for some BCPs based on GMPLS
interop/implemenation experience.

In particular, we have also recently hit some issues related to the
Interface IDs and Label Sub-object used in EROs stemming from confusion over
how to interpret RFC 3473.  If anyone can clarify what is and what is not
either allowed or common practice, that would be very useful.

We would like to work with the following simple example, where node A is not
the ingress, but C is the egress.  We've done some interop testing, and
found that in some cases EROs which we considered valid did not work, while
others produced unexpected results.

	Nodes: 	A--------B--------C
	Interfaces:	 A1    B1 B2    C1  
	D/S Labels	    L1       L2

Which of the following EROs, received in a Path message by Node A, would
produce the LSP pictured?

(a)	{A1,L1};{B2,L2}
(b)	{A1,L1};{B2,L2};(C1}
(c)	{B1,L1};(C1,L2}
(d)	{A1,L1};{B1,L1};{B2,L2};(C1,L2}

Further, if some of these configurations are not allowed, where is that
typically policed?  

Regarding option (c), it appears that some vendors expect this construction,
but we're not clear how it can be accurately interpreted.  If it is valid,
how can node A know whether B1 is the incoming or outgoing interface on node
B (and therefore whether is has to process label L1)?  If it is not valid,
can this be policed?

Also, is an explicit hop to the egress always required (omitted in option
(a)).  Does it make sense to include a label on that hop, and if so what
processing should the egress node do?  In option (d) it could arguably just
ignore the label, but that probably is not the case in (c).

Thanks,

Nic

-----Original Message-----
From: Richard Rabbat [mailto:[email-masked]]
Sent: 10 November 2004 21:46
To: [email-masked]
Cc: 'Richard Rabbat'
Subject: RE: GMPLS topics and issues of study

Please note that the list under "Addressing" that we compiled and sent out
is based on the Isocore interoperability testing.
The other items:
--
RSVP message contents:
1: ERO/RRO: choice of outgoing vs. incoming interface ID
2: Forwarding destination of Path message with ERO
Control channel:
1: Best practice where multiple IP hops lie between adjacent nodes
--
are from another source so we can combine these issues as well.
Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Rabbat
Sent: Wednesday, November 10, 2004 11:27 AM
To: [email-masked]
Cc: 'Rajiv Papneja'; 'Ashok Narayanan'; 'Eiji Oki'; 'Pandian, Vijay'; 'Ong,
Lyndon'; 'Hari Rakotoranto'; [email-masked];
[email-masked]; [email-masked]
Subject: GMPLS topics and issues of study

Hi all,

Based on Isocore interoperability testing results from the past few months,
we've found the following issues to have caused some confusion and
differences in implementation.  We'll list them here in no specific order
under 3 major headings.

Addressing:
1. relationship between TE Router ID and OSPF router ID 
1.1 where to use TE Router ID, OSPF Router ID and IPCC Address 

2: IP reachability (what ID's are reachable IP addresses)

3: what address is used in the signaling message in the ERO/RRO

4: what is used in in the IF_ID_RSVP_HOP
4.1: IP v4 Next/Previous Hop address
4.2: IPv4 address in the value field

5:  what is used in the destination IPv4 address in the session object 

6:  what is used in the sender IPv4 address in sender object template

7:  what is used as the Router ID in LSP_TUNNEL_INTERFACE_ID

RSVP message contents:

1: ERO/RRO: choice of outgoing vs. incoming interface ID

2: Forwarding destination of Path message with ERO

Control channel:

1: Best practice where multiple IP hops lie between adjacent nodes

2: use of redundant/multiple IPCC. best practices 
 
We're in the process of putting together what we hope to be a comprehensive
list of topics that may cause interop concerns. If people have thoughts
about other concerns as well, it would be great if you can email them to the
list or contact us directly.

Yumiko Kawashima
Ashok Narayanan
Eiji Oki
Lyndon Ong
Vijay Pandian
Rajiv Papneja   
Richard Rabbat
Hari Rakotoranto
Kohei Shiomoto
Tomonori Takeda

Delivery-date: Mon, 15 Nov 2004 15:51:14 +0000
Date: Mon, 15 Nov 2004 07:51:02 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: charter update

Hi All,

If you have suggested charter updates, please send them to Adrian and
me.  Please keep this subject line (simply reply to this mail).

The deadline is Friday Nov 19, 17:00 PST.

Thanks,
Kireeti.
-------

Delivery-date: Mon, 15 Nov 2004 15:48:24 +0000
Date: Mon, 15 Nov 2004 16:47:39 +0100
From: [email-masked]
Reply-To: [email-masked]
Organization: ALCATEL - R&I
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

All,

few comments on this,

[email-masked] a =E9crit :

<snipped>

> >
> > Regarding one of your previous comments, please note that
> > dynamic capacity update is a key requirement for many SPs.
> > Here is a simple motivation example:
> > Let's assume for instance that a SP owns two IP networks, one
> > for business trafic (VPNs) and another for DSL aggregation,
> > both supported by the same transmission network; these two
> > networks are not loaded during the same time along the day,
> > and it would be highly useful to share transport capacity
> > between them and reallocate bandwidth dynamically (with a
> > period of several hours).
> NH=3D> I don't dispute this at all.  The key things are:
> -       the timescales over which topology changes are effected
> (ie closer to the duct the slower the TE time-constants).....but in
> any case we are talking S-PVCs here IMO and not SVCs (at least for
> the forseeable future).

MRN gives you the capability to take wise decisions
regardless of the time you need to take them.

> -       whether we are talking intra-operator or inter-operator.

AS JL said, intra, for the moment.

> As a representative of FT I would expect you to fully understand
> that what is advertised and/or allowed to be controlled in your
> network(s) is a very different issue in these 2 cases.
> >
> > Note that the term "Toplogy" is relative. When you signal a
> > new TDM LSP between two routers, you may update the "IP
> > topology", as you setup a new IP link. This is just a
> > question of terminology.
> NH=3D> Well, maybe....depends on how you are looking at this compared
> to myself.  As per your example, when you signal a new SDH VC4 layer
> network trail say between 2 nodes in the IP layer network (ie a
> link connection here) then of course you are changing the IP layer
> network topology.  What I am arguing is that you cannot simply create
> topology on the fly (ie as some top level demand rippling right down
> to the optics/duct say) in any viable commercial manner.....esp in the
> inter-operator case.

I think there is sort of a misunderstanding here,
MRN does not mandates traffic driven connection establishment
(which is what I understand by "on the fly")
I gives the operator the full view of its switching capabilities so as
to intelligently trigger (if needed) additional resources.
But more generally, why are we focusing on triggering here,
MRN is, but is also much more than an enabler for intelligent
triggering through regions.

> That is, one would create the link-connection in the client topology
> as a consequence of longer-term trends in traffic behaviour in the
> client....and when we start getting down the stack, with all the will
> in the world, it will be not possible to create a link connection
> where physical infrastructure does not exist.  So at what the level
> and to what degree is a priori provisioning done becomes a key
> question.  Further, I also firmly believe that strong functional
> decoupling is is important
> when we have a client/server relationship between 2 different
> operators.....and I'd be amazed if FT held any different view here.

On the other hand, decoupling and region isolation would go against
efficient network engineering especially in intra-operator case
and distributed CP environment.

Finally I think that the topics covered here are more
in the scope of operational processes, which in turn=20
are outside the scope of the mrn-reqs document.

Regards,

Martin
>=20
> regards, Neil
> >
> > Best Regards,
> >
> > JL
> >
> > >-----Message d'origine-----
> > >De : [email-masked]
> > >[mailto:[email-masked]] De la part de
> > [email-masked]
> > >Envoy=E9 : lundi 15 novembre 2004 11:36
> > >=C0 : [email-masked]; [email-masked];
> > >[email-masked]; [email-masked]
> > >Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> > >
> > >
> > >John,
> > >
> > ><snipped>
> > >> > .....in fact a large supplier of ours recently admitted
> > >> (after 3 years
> > >> > of trying to persuade us otherwise) that they now agree
> > with us on
> > >> > this.
> > >> <John Drake>
> > >>
> > >> It's not unusual for a vendor that is incapable of building
> > >> <something> to assert that <something> is a Bad IdeaTM.
> > >NH=3D> Well, one could also look at this differently.....given
> > >we worked out the facts several years ago on our own and
> > >nothing has happened since to show we were wrong, then one
> > >could say that we know this vendor is now at least trying to
> > >be honest with us on this issue.
> > >>
> > >> > Those who think they can 'create topology on the fly' can
> > >> believe in
> > >> > this stuff if they like.....you will convince me the day I see a
> > >> > routing protocol lay a duct and light some fibre, till
> > then we'll
> > >> > stick with what we know is true.
> > >> <John Drake>
> > >>
> > >> We never said that GMPLS had a backhoe option.
> > >NH=3D> Try this logic.....and this is only one example of a
> > >given layered network sequence:
> > >-    to run the ducts we need the back-hoe
> > >-    to run the fibre we need the ducts in place
> > >-    to run the SDH MS/RS we need the fibre in place
> > >-    to run the SDH VC4 layer network we need the SDH MS/RS in place
> > >-    to run IP/MPLS layer networks we need the VC4 layer network in
> > >place.
> > >
> > >Do you see the logical dependency?  Put simply, one cannot
> > >create topology on the fly....at some point in the above you
> > >are going have to assume some 'already in place/fixed'
> > >topology.  But it's not even as simple as that.......
> > >
> > >Let's consider some of the commercial issues here as they are
> > >rather important.  Ever tried figuring out the design rules
> > >required in some co-cs transport network (like SDH VC4 or OTNs
> > >say) so that one can 'create a trail at will' (an SVC by any
> > >other name)....or at least to some acceptable GoS (Grade of
> > >Service), ie probability of capacity being available within an
> > >acceptable (to the client) time period post making demand?
> > >
> > >Folks should try it some time as the results are rather
> > >illuminating. We did this with our traffic engineering maths
> > >group at the labs a few years ago.  Without going into the
> > >detail, if you want to be able to 'turn-up' seriously large BW
> > >trails on demand between various locations you are going to
> > >have a build a network that runs largely empty for most of its
> > >working life....now try getting a business case for this past
> > >the products/services/financial people ;-).
> > >
> > >And once one turns up a trail in some lower layer network, do
> > >you seriously expect we operators will turn it off?
> > >
> > >Bottom-line...as one gets closer to the duct the holding time
> > >of trails/topology must increase.
> > >
> > >Note - These issues are over/above the requirement for
> > >commercial/functional isolation between different operating
> > >parties in a client/server layer network relationship.
> > >
> > >regards, Neil
> > >
> > >
> >

Delivery-date: Mon, 15 Nov 2004 15:16:02 +0000
Date: Mon, 15 Nov 2004 16:14:36 +0100
From: [email-masked]
Reply-To: [email-masked]
Organization: Alcatel CTO/R&I
To: LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: RE : RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

--------------080605000808010105050905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Gentlemens (following agreement on JL comment),
please focus on the drafts contents and not on "particular" nor=20
"architectural" vision of network operations.
To be clear if one wants to apply policies to maintain blind and=20
inefficient operations from one SC to the other it's still possible with=20
MRN ! (BTW nothing in MRN mandate traffic-driven-only operations as=20
assumed in some emails)
MRN just gives the *control plane* (nothing to be redefined) extensions=20
for integrated opeartions but does not mandate any policies.

Emmanuel

LE ROUX Jean-Louis RD-CORE-LAN wrote:

>Hi Neil
>
>Not sure this discussion will help, actually this is out of the scope of t=
his ID,=20
>nevermind, see inline,
>
>JL
>
> =20
>
>>-----Message d'origine-----
>>De : [email-masked] [mailto:[email-masked]]=20
>>Envoy=E9 : lundi 15 novembre 2004 14:17
>>=C0 : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked];=20
>>[email-masked]; [email-masked]; [email-masked]
>>Objet : RE: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>>
>>
>>Hi Jean-Loius,
>>   =20
>>
>>>Hi Neil, all
>>>
>>>We do not reinvent GMPLS here, we just list a set of
>>>functional reqs, that may lead=20
>>>to minor protocol extensions.
>>>By the way it seems that some of your objections applies to=20
>>>GMPLS in general...
>>>     =20
>>>
>>NH=3D>  Not really.  The co-cs mode forces some good behaviours=20
>>in GMPLS which we fully agree with, eg
>>-	OOB control/management
>>-	cannot violate connectivity requirements of the traffic=20
>>data-plane
>>-	fixed/known hierachy
>>
>>The latter forced requirement of the co-cs mode means one can=20
>>have functional decoupling between the layer networks.  It=20
>>also means one can choose best-of-breed functional components=20
>>for things like addressing, signalling, OAM, etc.  'Choose' is=20
>>the key word here.
>>
>>All of this becomes rather important when different operators=20
>>wish to lease capacity off each other in a client/server relationship.
>>   =20
>>
>>>Regarding one of your previous comments, please note that
>>>dynamic capacity update is a key requirement for many SPs.=20
>>>Here is a simple motivation example:
>>>Let's assume for instance that a SP owns two IP networks, one=20
>>>for business trafic (VPNs) and another for DSL aggregation,=20
>>>both supported by the same transmission network; these two=20
>>>networks are not loaded during the same time along the day,=20
>>>and it would be highly useful to share transport capacity=20
>>>between them and reallocate bandwidth dynamically (with a=20
>>>period of several hours).
>>>     =20
>>>
>>NH=3D> I don't dispute this at all.  The key things are:
>>-	the timescales over which topology changes are effected=20
>>(ie closer to the duct the slower the TE=20
>>time-constants).....but in any case we are talking S-PVCs here=20
>>IMO and not SVCs (at least for the forseeable future).
>>   =20
>>
>
>No, why such restriction to S-PVCs, SVCs are largely envisageable in
>an intra-operator case.
>
> =20
>
>>-	whether we are talking intra-operator or=20
>>inter-operator.  As a representative of FT I would expect you=20
>>to fully understand that what is advertised and/or allowed to=20
>>be controlled in your network(s) is a very different issue in=20
>>these 2 cases.
>>   =20
>>
>
>Be sure I fully understand the distinction...
>Here in this example I was talking intra-operator.=20
>By the way, note that current MRN requirements focus on intra operator cas=
e.=20
>
> =20
>
>>>Note that the term "Toplogy" is relative. When you signal a
>>>new TDM LSP between two routers, you may update the "IP=20
>>>topology", as you setup a new IP link. This is just a=20
>>>question of terminology.
>>>     =20
>>>
>>NH=3D> Well, maybe....depends on how you are looking at this=20
>>compared to myself.  As per your example, when you signal a=20
>>new SDH VC4 layer network trail say between 2 nodes in the IP=20
>>layer network (ie a link connection here) then of course you=20
>>are changing the IP layer network topology.  What I am arguing=20
>>is that you cannot simply create topology on the fly (ie as=20
>>some top level demand rippling right down to the optics/duct=20
>>say) in any viable commercial manner.....esp in the=20
>>inter-operator case. =20
>>   =20
>>
>
>And what about the INTRA OPERATOR case ????
>
>That is, one would create the=20
> =20
>
>>link-connection in the client topology as a consequence of=20
>>longer-term trends in traffic behaviour in the client....and=20
>>when we start getting down the stack, with all the will in the=20
>>world, it will be not possible to create a link connection=20
>>where physical infrastructure does not exist. =20
>>   =20
>>
>
>Please could you point where did you see such statement "to create a link =
connection=20
>where physical infrastructure does not exist" in our draft ?=20
>
>
>So at what the=20
> =20
>
>>level and to what degree is a priori provisioning done becomes=20
>>a key question.  Further, I also firmly believe that strong=20
>>functional decoupling is is important when we have a=20
>>client/server relationship between 2 different=20
>>operators.....and I'd be amazed if FT held any different view here.
>>
>>   =20
>>
>
>Sure but who is talking about two operators here ?????
>I think you missed something here. What about cases were both IP and trans=
port are under the control of the same entity ????
>
>Best Regards,
>
>Jean-Louis
>
>
>
>
> =20
>
>>regards, Neil
>>   =20
>>
>>>Best Regards,
>>>
>>>JL
>>>
>>>     =20
>>>
>>>>-----Message d'origine-----
>>>>De : [email-masked]
>>>>[mailto:[email-masked]] De la part de=20
>>>>       =20
>>>>
>>>[email-masked]
>>>     =20
>>>
>>>>Envoy=E9 : lundi 15 novembre 2004 11:36
>>>>=C0 : [email-masked]; [email-masked];=20
>>>>[email-masked]; [email-masked]
>>>>Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>>>>
>>>>
>>>>John,
>>>>
>>>><snipped>
>>>>       =20
>>>>
>>>>>>.....in fact a large supplier of ours recently admitted
>>>>>>           =20
>>>>>>
>>>>>(after 3 years
>>>>>         =20
>>>>>
>>>>>>of trying to persuade us otherwise) that they now agree=20
>>>>>>           =20
>>>>>>
>>>with us on=20
>>>     =20
>>>
>>>>>>this.
>>>>>>           =20
>>>>>>
>>>>><John Drake>
>>>>>
>>>>>It's not unusual for a vendor that is incapable of building=20
>>>>><something> to assert that <something> is a Bad IdeaTM.
>>>>>         =20
>>>>>
>>>>NH=3D> Well, one could also look at this differently.....given
>>>>we worked out the facts several years ago on our own and=20
>>>>nothing has happened since to show we were wrong, then one=20
>>>>could say that we know this vendor is now at least trying to=20
>>>>be honest with us on this issue.
>>>>       =20
>>>>
>>>>>>Those who think they can 'create topology on the fly' can
>>>>>>           =20
>>>>>>
>>>>>believe in
>>>>>         =20
>>>>>
>>>>>>this stuff if they like.....you will convince me the=20
>>>>>>           =20
>>>>>>
>>day I see a=20
>>   =20
>>
>>>>>>routing protocol lay a duct and light some fibre, till=20
>>>>>>           =20
>>>>>>
>>>then we'll=20
>>>     =20
>>>
>>>>>>stick with what we know is true.
>>>>>>           =20
>>>>>>
>>>>><John Drake>
>>>>>
>>>>>We never said that GMPLS had a backhoe option.
>>>>>         =20
>>>>>
>>>>NH=3D> Try this logic.....and this is only one example of a
>>>>given layered network sequence:
>>>>-	to run the ducts we need the back-hoe
>>>>-	to run the fibre we need the ducts in place
>>>>-	to run the SDH MS/RS we need the fibre in place
>>>>-	to run the SDH VC4 layer network we need the SDH MS/RS in place
>>>>-	to run IP/MPLS layer networks we need the VC4 layer network in
>>>>place.
>>>>
>>>>Do you see the logical dependency?  Put simply, one cannot
>>>>create topology on the fly....at some point in the above you=20
>>>>are going have to assume some 'already in place/fixed'=20
>>>>topology.  But it's not even as simple as that.......
>>>>
>>>>Let's consider some of the commercial issues here as they are
>>>>rather important.  Ever tried figuring out the design rules=20
>>>>required in some co-cs transport network (like SDH VC4 or OTNs=20
>>>>say) so that one can 'create a trail at will' (an SVC by any=20
>>>>other name)....or at least to some acceptable GoS (Grade of=20
>>>>Service), ie probability of capacity being available within an=20
>>>>acceptable (to the client) time period post making demand?
>>>>
>>>>Folks should try it some time as the results are rather
>>>>illuminating. We did this with our traffic engineering maths=20
>>>>group at the labs a few years ago.  Without going into the=20
>>>>detail, if you want to be able to 'turn-up' seriously large BW=20
>>>>trails on demand between various locations you are going to=20
>>>>have a build a network that runs largely empty for most of its=20
>>>>working life....now try getting a business case for this past=20
>>>>the products/services/financial people ;-).
>>>>
>>>>And once one turns up a trail in some lower layer network, do
>>>>you seriously expect we operators will turn it off?
>>>>
>>>>Bottom-line...as one gets closer to the duct the holding time
>>>>of trails/topology must increase.
>>>>
>>>>Note - These issues are over/above the requirement for
>>>>commercial/functional isolation between different operating=20
>>>>parties in a client/server layer network relationship.
>>>>
>>>>regards, Neil
>>>>
>>>>
>>>>       =20
>>>>
>
>
> =20
>

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Gentlemens (following agreement on JL comment), <br>
please focus on the drafts contents and not on "particular" nor
"architectural" vision of network operations.<br>
To be clear if one wants to apply policies to maintain blind and
inefficient operations from one SC to the other it's still possible
with MRN ! (BTW nothing in MRN mandate traffic-driven-only operations
as assumed in some emails)<br>
MRN just gives the *control plane* (nothing to be redefined) extensions
for integrated opeartions but does not mandate any policies.<br>
<br>
Emmanuel<br>
<br>
<br>
LE ROUX Jean-Louis RD-CORE-LAN wrote:<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">Hi Neil

Not sure this discussion will help, actually this is out of the scope of this ID, 
nevermind, see inline,

JL

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Message d'origine-----
De : <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] 
Envoy&eacute; : lundi 15 novembre 2004 14:17
&Agrave; : LE ROUX Jean-Louis RD-CORE-LAN; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; 
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Objet : RE: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

Hi Jean-Loius,
    </pre>
    <blockquote type="cite">
      <pre wrap="">Hi Neil, all

We do not reinvent GMPLS here, we just list a set of
functional reqs, that may lead 
to minor protocol extensions.
By the way it seems that some of your objections applies to 
GMPLS in general...
      </pre>
    </blockquote>
    <pre wrap="">NH=&gt;  Not really.  The co-cs mode forces some good behaviours 
in GMPLS which we fully agree with, eg
-	OOB control/management
-	cannot violate connectivity requirements of the traffic 
data-plane
-	fixed/known hierachy

The latter forced requirement of the co-cs mode means one can 
have functional decoupling between the layer networks.  It 
also means one can choose best-of-breed functional components 
for things like addressing, signalling, OAM, etc.  'Choose' is 
the key word here.

All of this becomes rather important when different operators 
wish to lease capacity off each other in a client/server relationship.
    </pre>
    <blockquote type="cite">
      <pre wrap="">Regarding one of your previous comments, please note that
dynamic capacity update is a key requirement for many SPs. 
Here is a simple motivation example:
Let's assume for instance that a SP owns two IP networks, one 
for business trafic (VPNs) and another for DSL aggregation, 
both supported by the same transmission network; these two 
networks are not loaded during the same time along the day, 
and it would be highly useful to share transport capacity 
between them and reallocate bandwidth dynamically (with a 
period of several hours).
      </pre>
    </blockquote>
    <pre wrap="">NH=&gt; I don't dispute this at all.  The key things are:
-	the timescales over which topology changes are effected 
(ie closer to the duct the slower the TE 
time-constants).....but in any case we are talking S-PVCs here 
IMO and not SVCs (at least for the forseeable future).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
No, why such restriction to S-PVCs, SVCs are largely envisageable in
an intra-operator case.

  </pre>
  <blockquote type="cite">
    <pre wrap="">-	whether we are talking intra-operator or 
inter-operator.  As a representative of FT I would expect you 
to fully understand that what is advertised and/or allowed to 
be controlled in your network(s) is a very different issue in 
these 2 cases.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Be sure I fully understand the distinction...
Here in this example I was talking intra-operator. 
By the way, note that current MRN requirements focus on intra operator case. 

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">Note that the term "Toplogy" is relative. When you signal a
new TDM LSP between two routers, you may update the "IP 
topology", as you setup a new IP link. This is just a 
question of terminology.
      </pre>
    </blockquote>
    <pre wrap="">NH=&gt; Well, maybe....depends on how you are looking at this 
compared to myself.  As per your example, when you signal a 
new SDH VC4 layer network trail say between 2 nodes in the IP 
layer network (ie a link connection here) then of course you 
are changing the IP layer network topology.  What I am arguing 
is that you cannot simply create topology on the fly (ie as 
some top level demand rippling right down to the optics/duct 
say) in any viable commercial manner.....esp in the 
inter-operator case.  
    </pre>
  </blockquote>
  <pre wrap=""><!---->
And what about the INTRA OPERATOR case ????

That is, one would create the 
  </pre>
  <blockquote type="cite">
    <pre wrap="">link-connection in the client topology as a consequence of 
longer-term trends in traffic behaviour in the client....and 
when we start getting down the stack, with all the will in the 
world, it will be not possible to create a link connection 
where physical infrastructure does not exist.  
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Please could you point where did you see such statement "to create a link connection 
where physical infrastructure does not exist" in our draft ? 

So at what the 
  </pre>
  <blockquote type="cite">
    <pre wrap="">level and to what degree is a priori provisioning done becomes 
a key question.  Further, I also firmly believe that strong 
functional decoupling is is important when we have a 
client/server relationship between 2 different 
operators.....and I'd be amazed if FT held any different view here.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
Sure but who is talking about two operators here ?????
I think you missed something here. What about cases were both IP and transport are under the control of the same entity ????

Best Regards,

Jean-Louis

  </pre>
  <blockquote type="cite">
    <pre wrap="">regards, Neil
    </pre>
    <blockquote type="cite">
      <pre wrap="">Best Regards,

JL

      </pre>
      <blockquote type="cite">
        <pre wrap="">-----Message d'origine-----
De : <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] De la part de 
        </pre>
      </blockquote>
      <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
      </pre>
      <blockquote type="cite">
        <pre wrap="">Envoy&eacute; : lundi 15 novembre 2004 11:36
&Agrave; : <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; 
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

John,

&lt;snipped&gt;
        </pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">.....in fact a large supplier of ours recently admitted
            </pre>
          </blockquote>
          <pre wrap="">(after 3 years
          </pre>
          <blockquote type="cite">
            <pre wrap="">of trying to persuade us otherwise) that they now agree 
            </pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">with us on 
      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">this.
            </pre>
          </blockquote>
          <pre wrap="">&lt;John Drake&gt;

It's not unusual for a vendor that is incapable of building 
&lt;something&gt; to assert that &lt;something&gt; is a Bad IdeaTM.
          </pre>
        </blockquote>
        <pre wrap="">NH=&gt; Well, one could also look at this differently.....given
we worked out the facts several years ago on our own and 
nothing has happened since to show we were wrong, then one 
could say that we know this vendor is now at least trying to 
be honest with us on this issue.
        </pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">Those who think they can 'create topology on the fly' can
            </pre>
          </blockquote>
          <pre wrap="">believe in
          </pre>
          <blockquote type="cite">
            <pre wrap="">this stuff if they like.....you will convince me the 
            </pre>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">day I see a 
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">routing protocol lay a duct and light some fibre, till 
            </pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">then we'll 
      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">stick with what we know is true.
            </pre>
          </blockquote>
          <pre wrap="">&lt;John Drake&gt;

We never said that GMPLS had a backhoe option.
          </pre>
        </blockquote>
        <pre wrap="">NH=&gt; Try this logic.....and this is only one example of a
given layered network sequence:
-	to run the ducts we need the back-hoe
-	to run the fibre we need the ducts in place
-	to run the SDH MS/RS we need the fibre in place
-	to run the SDH VC4 layer network we need the SDH MS/RS in place
-	to run IP/MPLS layer networks we need the VC4 layer network in
place.

Do you see the logical dependency?  Put simply, one cannot
create topology on the fly....at some point in the above you 
are going have to assume some 'already in place/fixed' 
topology.  But it's not even as simple as that.......

Let's consider some of the commercial issues here as they are
rather important.  Ever tried figuring out the design rules 
required in some co-cs transport network (like SDH VC4 or OTNs 
say) so that one can 'create a trail at will' (an SVC by any 
other name)....or at least to some acceptable GoS (Grade of 
Service), ie probability of capacity being available within an 
acceptable (to the client) time period post making demand?

Folks should try it some time as the results are rather
illuminating. We did this with our traffic engineering maths 
group at the labs a few years ago.  Without going into the 
detail, if you want to be able to 'turn-up' seriously large BW 
trails on demand between various locations you are going to 
have a build a network that runs largely empty for most of its 
working life....now try getting a business case for this past 
the products/services/financial people ;-).

And once one turns up a trail in some lower layer network, do
you seriously expect we operators will turn it off?

Bottom-line...as one gets closer to the duct the holding time
of trails/topology must increase.

Note - These issues are over/above the requirement for
commercial/functional isolation between different operating 
parties in a client/server layer network relationship.

regards, Neil

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

  </pre>
</blockquote>
<br>
</body>
</html>

--------------080605000808010105050905--

Delivery-date: Mon, 15 Nov 2004 13:53:12 +0000
Content-class: urn:content-classes:message
Subject: RE : RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Mon, 15 Nov 2004 14:47:50 +0100
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Neil

Not sure this discussion will help, actually this is out of the scope of =
this ID,=20
nevermind, see inline,

JL

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]]=20
>Envoy=E9 : lundi 15 novembre 2004 14:17
>=C0 : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked];=20
>[email-masked]; [email-masked]; [email-masked]
>Objet : RE: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>
>
>Hi Jean-Loius,
>>=20
>> Hi Neil, all
>>=20
>> We do not reinvent GMPLS here, we just list a set of
>> functional reqs, that may lead=20
>> to minor protocol extensions.
>> By the way it seems that some of your objections applies to=20
>> GMPLS in general...
>NH=3D>  Not really.  The co-cs mode forces some good behaviours=20
>in GMPLS which we fully agree with, eg
>-	OOB control/management
>-	cannot violate connectivity requirements of the traffic=20
>data-plane
>-	fixed/known hierachy
>
>The latter forced requirement of the co-cs mode means one can=20
>have functional decoupling between the layer networks.  It=20
>also means one can choose best-of-breed functional components=20
>for things like addressing, signalling, OAM, etc.  'Choose' is=20
>the key word here.
>
>All of this becomes rather important when different operators=20
>wish to lease capacity off each other in a client/server relationship.
>>=20
>> Regarding one of your previous comments, please note that
>> dynamic capacity update is a key requirement for many SPs.=20
>> Here is a simple motivation example:
>> Let's assume for instance that a SP owns two IP networks, one=20
>> for business trafic (VPNs) and another for DSL aggregation,=20
>> both supported by the same transmission network; these two=20
>> networks are not loaded during the same time along the day,=20
>> and it would be highly useful to share transport capacity=20
>> between them and reallocate bandwidth dynamically (with a=20
>> period of several hours).
>NH=3D> I don't dispute this at all.  The key things are:
>-	the timescales over which topology changes are effected=20
>(ie closer to the duct the slower the TE=20
>time-constants).....but in any case we are talking S-PVCs here=20
>IMO and not SVCs (at least for the forseeable future).

No, why such restriction to S-PVCs, SVCs are largely envisageable in
an intra-operator case.

>-	whether we are talking intra-operator or=20
>inter-operator.  As a representative of FT I would expect you=20
>to fully understand that what is advertised and/or allowed to=20
>be controlled in your network(s) is a very different issue in=20
>these 2 cases.

Be sure I fully understand the distinction...
Here in this example I was talking intra-operator.=20
By the way, note that current MRN requirements focus on intra operator =
case.=20

>>=20
>> Note that the term "Toplogy" is relative. When you signal a
>> new TDM LSP between two routers, you may update the "IP=20
>> topology", as you setup a new IP link. This is just a=20
>> question of terminology.
>NH=3D> Well, maybe....depends on how you are looking at this=20
>compared to myself.  As per your example, when you signal a=20
>new SDH VC4 layer network trail say between 2 nodes in the IP=20
>layer network (ie a link connection here) then of course you=20
>are changing the IP layer network topology.  What I am arguing=20
>is that you cannot simply create topology on the fly (ie as=20
>some top level demand rippling right down to the optics/duct=20
>say) in any viable commercial manner.....esp in the=20
>inter-operator case. =20

And what about the INTRA OPERATOR case ????

That is, one would create the=20
>link-connection in the client topology as a consequence of=20
>longer-term trends in traffic behaviour in the client....and=20
>when we start getting down the stack, with all the will in the=20
>world, it will be not possible to create a link connection=20
>where physical infrastructure does not exist. =20

Please could you point where did you see such statement "to create a =
link connection=20
where physical infrastructure does not exist" in our draft ?=20

So at what the=20
>level and to what degree is a priori provisioning done becomes=20
>a key question.  Further, I also firmly believe that strong=20
>functional decoupling is is important when we have a=20
>client/server relationship between 2 different=20
>operators.....and I'd be amazed if FT held any different view here.
>

Sure but who is talking about two operators here ?????
I think you missed something here. What about cases were both IP and =
transport are under the control of the same entity ????

Best Regards,

Jean-Louis

>regards, Neil
>>=20
>> Best Regards,
>>=20
>> JL
>>=20
>> >-----Message d'origine-----
>> >De : [email-masked]
>> >[mailto:[email-masked]] De la part de=20
>> [email-masked]
>> >Envoy=E9 : lundi 15 novembre 2004 11:36
>> >=C0 : [email-masked]; [email-masked];=20
>> >[email-masked]; [email-masked]
>> >Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>> >
>> >
>> >John,
>> >
>> ><snipped>
>> >> > .....in fact a large supplier of ours recently admitted
>> >> (after 3 years
>> >> > of trying to persuade us otherwise) that they now agree=20
>> with us on=20
>> >> > this.
>> >> <John Drake>
>> >>=20
>> >> It's not unusual for a vendor that is incapable of building=20
>> >> <something> to assert that <something> is a Bad IdeaTM.
>> >NH=3D> Well, one could also look at this differently.....given
>> >we worked out the facts several years ago on our own and=20
>> >nothing has happened since to show we were wrong, then one=20
>> >could say that we know this vendor is now at least trying to=20
>> >be honest with us on this issue.
>> >>=20
>> >> > Those who think they can 'create topology on the fly' can
>> >> believe in
>> >> > this stuff if they like.....you will convince me the=20
>day I see a=20
>> >> > routing protocol lay a duct and light some fibre, till=20
>> then we'll=20
>> >> > stick with what we know is true.
>> >> <John Drake>
>> >>=20
>> >> We never said that GMPLS had a backhoe option.
>> >NH=3D> Try this logic.....and this is only one example of a
>> >given layered network sequence:
>> >-	to run the ducts we need the back-hoe
>> >-	to run the fibre we need the ducts in place
>> >-	to run the SDH MS/RS we need the fibre in place
>> >-	to run the SDH VC4 layer network we need the SDH MS/RS in place
>> >-	to run IP/MPLS layer networks we need the VC4 layer network in
>> >place.
>> >
>> >Do you see the logical dependency?  Put simply, one cannot
>> >create topology on the fly....at some point in the above you=20
>> >are going have to assume some 'already in place/fixed'=20
>> >topology.  But it's not even as simple as that.......
>> >
>> >Let's consider some of the commercial issues here as they are
>> >rather important.  Ever tried figuring out the design rules=20
>> >required in some co-cs transport network (like SDH VC4 or OTNs=20
>> >say) so that one can 'create a trail at will' (an SVC by any=20
>> >other name)....or at least to some acceptable GoS (Grade of=20
>> >Service), ie probability of capacity being available within an=20
>> >acceptable (to the client) time period post making demand?
>> >
>> >Folks should try it some time as the results are rather
>> >illuminating. We did this with our traffic engineering maths=20
>> >group at the labs a few years ago.  Without going into the=20
>> >detail, if you want to be able to 'turn-up' seriously large BW=20
>> >trails on demand between various locations you are going to=20
>> >have a build a network that runs largely empty for most of its=20
>> >working life....now try getting a business case for this past=20
>> >the products/services/financial people ;-).
>> >
>> >And once one turns up a trail in some lower layer network, do
>> >you seriously expect we operators will turn it off?
>> >
>> >Bottom-line...as one gets closer to the duct the holding time
>> >of trails/topology must increase.
>> >
>> >Note - These issues are over/above the requirement for
>> >commercial/functional isolation between different operating=20
>> >parties in a client/server layer network relationship.
>> >
>> >regards, Neil
>> >
>> >
>>=20
>

Delivery-date: Mon, 15 Nov 2004 13:17:07 +0000
content-class: urn:content-classes:message
Subject: RE: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Mon, 15 Nov 2004 13:17:03 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Jean-Loius,
>=20
> Hi Neil, all
>=20
> We do not reinvent GMPLS here, we just list a set of=20
> functional reqs, that may lead=20
> to minor protocol extensions.
> By the way it seems that some of your objections applies to=20
> GMPLS in general...
NH=3D>  Not really.  The co-cs mode forces some good behaviours in GMPLS =
which we fully agree with, eg
-	OOB control/management
-	cannot violate connectivity requirements of the traffic data-plane
-	fixed/known hierachy

The latter forced requirement of the co-cs mode means one can have =
functional decoupling between the layer networks.  It also means one can =
choose best-of-breed functional components for things like addressing, =
signalling, OAM, etc.  'Choose' is the key word here.

All of this becomes rather important when different operators wish to =
lease capacity off each other in a client/server relationship.
>=20
> Regarding one of your previous comments, please note that=20
> dynamic capacity update is a key requirement for many SPs.=20
> Here is a simple motivation example:
> Let's assume for instance that a SP owns two IP networks, one=20
> for business trafic (VPNs) and another for DSL aggregation,=20
> both supported by the same transmission network; these two=20
> networks are not loaded during the same time along the day,=20
> and it would be highly useful to share transport capacity=20
> between them and reallocate bandwidth dynamically (with a=20
> period of several hours).
NH=3D> I don't dispute this at all.  The key things are:
-	the timescales over which topology changes are effected (ie closer to =
the duct the slower the TE time-constants).....but in any case we are =
talking S-PVCs here IMO and not SVCs (at least for the forseeable =
future).
-	whether we are talking intra-operator or inter-operator.  As a =
representative of FT I would expect you to fully understand that what is =
advertised and/or allowed to be controlled in your network(s) is a very =
different issue in these 2 cases.
>=20
> Note that the term "Toplogy" is relative. When you signal a=20
> new TDM LSP between two routers, you may update the "IP=20
> topology", as you setup a new IP link. This is just a=20
> question of terminology.
NH=3D> Well, maybe....depends on how you are looking at this compared to =
myself.  As per your example, when you signal a new SDH VC4 layer =
network trail say between 2 nodes in the IP layer network (ie a link =
connection here) then of course you are changing the IP layer network =
topology.  What I am arguing is that you cannot simply create topology =
on the fly (ie as some top level demand rippling right down to the =
optics/duct say) in any viable commercial manner.....esp in the =
inter-operator case.  That is, one would create the link-connection in =
the client topology as a consequence of longer-term trends in traffic =
behaviour in the client....and when we start getting down the stack, =
with all the will in the world, it will be not possible to create a link =
connection where physical infrastructure does not exist.  So at what the =
level and to what degree is a priori provisioning done becomes a key =
question.  Further, I also firmly believe that strong functional =
decoupling is is important when we have a client/server relationship =
between 2 different operators.....and I'd be amazed if FT held any =
different view here.

regards, Neil
>=20
> Best Regards,
>=20
> JL
>=20
> >-----Message d'origine-----
> >De : [email-masked]
> >[mailto:[email-masked]] De la part de=20
> [email-masked]
> >Envoy=E9 : lundi 15 novembre 2004 11:36
> >=C0 : [email-masked]; [email-masked];=20
> >[email-masked]; [email-masked]
> >Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> >
> >
> >John,
> >
> ><snipped>
> >> > .....in fact a large supplier of ours recently admitted
> >> (after 3 years
> >> > of trying to persuade us otherwise) that they now agree=20
> with us on=20
> >> > this.
> >> <John Drake>
> >>=20
> >> It's not unusual for a vendor that is incapable of building=20
> >> <something> to assert that <something> is a Bad IdeaTM.
> >NH=3D> Well, one could also look at this differently.....given
> >we worked out the facts several years ago on our own and=20
> >nothing has happened since to show we were wrong, then one=20
> >could say that we know this vendor is now at least trying to=20
> >be honest with us on this issue.
> >>=20
> >> > Those who think they can 'create topology on the fly' can
> >> believe in
> >> > this stuff if they like.....you will convince me the day I see a=20
> >> > routing protocol lay a duct and light some fibre, till=20
> then we'll=20
> >> > stick with what we know is true.
> >> <John Drake>
> >>=20
> >> We never said that GMPLS had a backhoe option.
> >NH=3D> Try this logic.....and this is only one example of a
> >given layered network sequence:
> >-	to run the ducts we need the back-hoe
> >-	to run the fibre we need the ducts in place
> >-	to run the SDH MS/RS we need the fibre in place
> >-	to run the SDH VC4 layer network we need the SDH MS/RS in place
> >-	to run IP/MPLS layer networks we need the VC4 layer network in
> >place.
> >
> >Do you see the logical dependency?  Put simply, one cannot
> >create topology on the fly....at some point in the above you=20
> >are going have to assume some 'already in place/fixed'=20
> >topology.  But it's not even as simple as that.......
> >
> >Let's consider some of the commercial issues here as they are
> >rather important.  Ever tried figuring out the design rules=20
> >required in some co-cs transport network (like SDH VC4 or OTNs=20
> >say) so that one can 'create a trail at will' (an SVC by any=20
> >other name)....or at least to some acceptable GoS (Grade of=20
> >Service), ie probability of capacity being available within an=20
> >acceptable (to the client) time period post making demand?
> >
> >Folks should try it some time as the results are rather
> >illuminating. We did this with our traffic engineering maths=20
> >group at the labs a few years ago.  Without going into the=20
> >detail, if you want to be able to 'turn-up' seriously large BW=20
> >trails on demand between various locations you are going to=20
> >have a build a network that runs largely empty for most of its=20
> >working life....now try getting a business case for this past=20
> >the products/services/financial people ;-).
> >
> >And once one turns up a trail in some lower layer network, do
> >you seriously expect we operators will turn it off?
> >
> >Bottom-line...as one gets closer to the duct the holding time
> >of trails/topology must increase.
> >
> >Note - These issues are over/above the requirement for
> >commercial/functional isolation between different operating=20
> >parties in a client/server layer network relationship.
> >
> >regards, Neil
> >
> >
>=20

Delivery-date: Mon, 15 Nov 2004 11:26:23 +0000
Content-class: urn:content-classes:message
Subject: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Mon, 15 Nov 2004 12:22:42 +0100
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Neil, all

We do not reinvent GMPLS here, we just list a set of functional reqs, =
that may lead=20
to minor protocol extensions.
By the way it seems that some of your objections applies to GMPLS in =
general...

Regarding one of your previous comments, please note that dynamic =
capacity update is a key requirement for many SPs.=20
Here is a simple motivation example:
Let's assume for instance that a SP owns two IP networks, one for =
business trafic (VPNs)
and another for DSL aggregation, both supported by the same transmission =
network;
these two networks are not loaded during the same time along the day, =
and it would be highly useful to share transport capacity between them =
and reallocate bandwidth dynamically
(with a period of several hours).=20

Note that the term "Toplogy" is relative. When you signal a new TDM LSP =
between two routers, you may update the "IP topology", as you setup a =
new IP link. This is just a question of terminology.

Best Regards,

JL

>-----Message d'origine-----
>De : [email-masked]=20
>[mailto:[email-masked]] De la part de [email-masked]
>Envoy=E9 : lundi 15 novembre 2004 11:36
>=C0 : [email-masked]; [email-masked];=20
>[email-masked]; [email-masked]
>Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>
>
>John,
>
><snipped>
>> > .....in fact a large supplier of ours recently admitted
>> (after 3 years
>> > of trying to persuade us otherwise) that they now agree with us on
>> > this.
>> <John Drake>
>>=20
>> It's not unusual for a vendor that is incapable of building
>> <something> to assert that <something> is a Bad IdeaTM.
>NH=3D> Well, one could also look at this differently.....given=20
>we worked out the facts several years ago on our own and=20
>nothing has happened since to show we were wrong, then one=20
>could say that we know this vendor is now at least trying to=20
>be honest with us on this issue.
>>=20
>> > Those who think they can 'create topology on the fly' can
>> believe in
>> > this stuff if they like.....you will convince me the day I see a
>> > routing protocol lay a duct and light some fibre, till then we'll=20
>> > stick with what we know is true.
>> <John Drake>
>>=20
>> We never said that GMPLS had a backhoe option.
>NH=3D> Try this logic.....and this is only one example of a=20
>given layered network sequence:
>-	to run the ducts we need the back-hoe
>-	to run the fibre we need the ducts in place
>-	to run the SDH MS/RS we need the fibre in place
>-	to run the SDH VC4 layer network we need the SDH MS/RS in place
>-	to run IP/MPLS layer networks we need the VC4 layer network in
>place.
>
>Do you see the logical dependency?  Put simply, one cannot=20
>create topology on the fly....at some point in the above you=20
>are going have to assume some 'already in place/fixed'=20
>topology.  But it's not even as simple as that.......
>
>Let's consider some of the commercial issues here as they are=20
>rather important.  Ever tried figuring out the design rules=20
>required in some co-cs transport network (like SDH VC4 or OTNs=20
>say) so that one can 'create a trail at will' (an SVC by any=20
>other name)....or at least to some acceptable GoS (Grade of=20
>Service), ie probability of capacity being available within an=20
>acceptable (to the client) time period post making demand?
>
>Folks should try it some time as the results are rather=20
>illuminating. We did this with our traffic engineering maths=20
>group at the labs a few years ago.  Without going into the=20
>detail, if you want to be able to 'turn-up' seriously large BW=20
>trails on demand between various locations you are going to=20
>have a build a network that runs largely empty for most of its=20
>working life....now try getting a business case for this past=20
>the products/services/financial people ;-).
>
>And once one turns up a trail in some lower layer network, do=20
>you seriously expect we operators will turn it off?
>
>Bottom-line...as one gets closer to the duct the holding time=20
>of trails/topology must increase.
>
>Note - These issues are over/above the requirement for=20
>commercial/functional isolation between different operating=20
>parties in a client/server layer network relationship.
>
>regards, Neil
>
>

Delivery-date: Mon, 15 Nov 2004 10:36:56 +0000
content-class: urn:content-classes:message
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Mon, 15 Nov 2004 10:35:35 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

John,

<snipped>
> > .....in fact a large supplier of ours recently admitted=20
> (after 3 years=20
> > of trying to persuade us otherwise) that they now agree with us on=20
> > this.
> <John Drake>
>=20
> It's not unusual for a vendor that is incapable of building=20
> <something> to assert that <something> is a Bad IdeaTM.
NH=3D> Well, one could also look at this differently.....given we worked
out the facts several years ago on our own and nothing has happened
since to show we were wrong, then one could say that we know this vendor
is now at least trying to be honest with us on this issue.
>=20
> > Those who think they can 'create topology on the fly' can=20
> believe in=20
> > this stuff if they like.....you will convince me the day I see a=20
> > routing protocol lay a duct and light some fibre, till then we'll=20
> > stick with what we know is true.
> <John Drake>
>=20
> We never said that GMPLS had a backhoe option.
NH=3D> Try this logic.....and this is only one example of a given =
layered
network sequence:
-	to run the ducts we need the back-hoe
-	to run the fibre we need the ducts in place
-	to run the SDH MS/RS we need the fibre in place
-	to run the SDH VC4 layer network we need the SDH MS/RS in place
-	to run IP/MPLS layer networks we need the VC4 layer network in
place.

Do you see the logical dependency?  Put simply, one cannot create
topology on the fly....at some point in the above you are going have to
assume some 'already in place/fixed' topology.  But it's not even as
simple as that.......

Let's consider some of the commercial issues here as they are rather
important.  Ever tried figuring out the design rules required in some
co-cs transport network (like SDH VC4 or OTNs say) so that one can
'create a trail at will' (an SVC by any other name)....or at least to
some acceptable GoS (Grade of Service), ie probability of capacity being
available within an acceptable (to the client) time period post making
demand?

Folks should try it some time as the results are rather illuminating.
We did this with our traffic engineering maths group at the labs a few
years ago.  Without going into the detail, if you want to be able to
'turn-up' seriously large BW trails on demand between various locations
you are going to have a build a network that runs largely empty for most
of its working life....now try getting a business case for this past the
products/services/financial people ;-).

And once one turns up a trail in some lower layer network, do you
seriously expect we operators will turn it off?

Bottom-line...as one gets closer to the duct the holding time of
trails/topology must increase.

Note - These issues are over/above the requirement for
commercial/functional isolation between different operating parties in a
client/server layer network relationship.

regards, Neil

Delivery-date: Sat, 13 Nov 2004 17:33:25 +0000
From: John Drake <[email-masked]>
To: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Sat, 13 Nov 2004 09:30:48 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, November 12, 2004 8:29 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> Hi Deborah,
> 
> Just to reassure you, I can confirm we fully understand what func arch is
> and why its important (we had a big hand in doing it).  And we also
> understand what GMPLS and MPLS are, what the 3 networking modes are, and
> how they are and are not related.
<John Drake>

Then I'm sure you are aware that the concept of a multi-region network (nee
the peer model) was an integral part of GMPLS from its inception, and that
it solves a very real problem with layered networks, viz, the problem of IGP
flooding in mesh networks.  I'm also sure you are aware that the deployment
of a layered network (nee the overlay model) or a multi-region network is at
the sole discretion of the owner of that network.

> One cannot functionally crunch the
> modes from 'IP to optics', it will simply not work either technically or
> commercially
<John Drake>

Late breaking news from Neil.  I better update my customers.

> .....in fact a large supplier of ours recently admitted (after
> 3 years of trying to persuade us otherwise) that they now agree with us on
> this.
<John Drake>

It's not unusual for a vendor that is incapable of building <something> to
assert that <something> is a Bad IdeaTM.

> Those who think they can 'create topology on the fly' can believe
> in this stuff if they like.....you will convince me the day I see a
> routing protocol lay a duct and light some fibre, till then we'll stick
> with what we know is true.
<John Drake>

We never said that GMPLS had a backhoe option.

> 
> regards, Neil
> 
> 
>  -----Original Message-----
> From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
> Sent: 12 November 2004 15:23
> To: Harrison,N,Neil,IKR2 R; [email-masked]; [email-masked]
> Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 
> 
> 	Hi Neil,
> 
> 	As I said in my previous mail, there seems to be confusion for those
> not familiar with GMPLS terminology. LSP is control plane. Nothing new
> here in this draft. I would suggest those concerned should discuss via the
> ITU-T SG 15 Q12/Q14 lists as the same choices were made for ITU's DCM
> (G7713.2 and G.7713.3) protocols.
> 
> 	Deborah
> 
> 
> 
> ________________________________
> 
> 	From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> 	Sent: Friday, November 12, 2004 8:41 AM
> 	To: [email-masked]; [email-masked]
> 	Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 
> 	Folks should take note of this advice.  We are fully in agreement
> with you on this issue Stephen.
> 
> 	BTW - G.805/809 stuff is not something dreamed-up in ITU just for
> the sake of it.....in fact its really nothing to do with ITU as its simply
> a formal way of capturing/defining the nature of real networks.
> 
> 	regards, Neil
> 
> 		-----Original Message-----
> 		From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Stephen Shew
> 		Sent: 11 November 2004 20:02
> 		To: [email-masked]
> 		Subject: Comment on
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 
> 		I was not able to be at the CCAMP meeting today but do have
> some comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 		It seems that the goals of the draft could be accomplished
> more simply by adopting the layer architecture as defined in ITU-T
> Recommendations G.805 and G.809.  By doing this, the specific boundaries
> between TDM, LSC, etc. don't have to be articulated as they are just layer
> networks.  Also, the designation of TDM does not include the notions of
> the layers within that (e.g., DS3, STS-1, VC4, etc.) which are important
> to transport equipment.  Adopting the layer architecture also enables a
> client layer to be supported by an inverse multipling layer such as
> provided by Virtual Concatenation.  Here a layer of finer granularity is
> use to support a layer of coarser granularity.
> 
> 
> 		Stephen Shew         Voice: 613-763-2462  Fax: 613-763-8385
> 		Nortel - Optical Networks  email: [email-masked]
> 		P.O. Box 3511, Station C
> 		Ottawa, ON K1Y 4H7
> 
> 

Delivery-date: Fri, 12 Nov 2004 16:28:54 +0000
content-class: urn:content-classes:message
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Fri, 12 Nov 2004 16:28:56 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

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

Hi Deborah,
=20
Just to reassure you, I can confirm we fully understand what func arch
is and why its important (we had a big hand in doing it).  And we also
understand what GMPLS and MPLS are, what the 3 networking modes are, and
how they are and are not related.  One cannot functionally crunch the
modes from 'IP to optics', it will simply not work either technically or
commercially.....in fact a large supplier of ours recently admitted
(after 3 years of trying to persuade us otherwise) that they now agree
with us on this.  Those who think they can 'create topology on the fly'
can believe in this stuff if they like.....you will convince me the day
I see a routing protocol lay a duct and light some fibre, till then
we'll stick with what we know is true.
=20
regards, Neil
=20
=20
 -----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]=20
Sent: 12 November 2004 15:23
To: Harrison,N,Neil,IKR2 R; [email-masked];
[email-masked]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

Hi Neil,
=20
As I said in my previous mail, there seems to be confusion for those not
familiar with GMPLS terminology. LSP is control plane. Nothing new here
in this draft. I would suggest those concerned should discuss via the
ITU-T SG 15 Q12/Q14 lists as the same choices were made for ITU's DCM
(G7713.2 and G.7713.3) protocols.
=20
Deborah
=20
=20

  _____ =20

From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, November 12, 2004 8:41 AM
To: [email-masked]; [email-masked]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

Folks should take note of this advice.  We are fully in agreement with
you on this issue Stephen.
=20
BTW - G.805/809 stuff is not something dreamed-up in ITU just for the
sake of it.....in fact its really nothing to do with ITU as its simply a
formal way of capturing/defining the nature of real networks.
=20
regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Shew
Sent: 11 November 2004 20:02
To: [email-masked]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

I was not able to be at the CCAMP meeting today but do have some
comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt    =20
=20
It seems that the goals of the draft could be accomplished more simply
by adopting the layer architecture as defined in ITU-T Recommendations
G.805 and G.809.  By doing this, the specific boundaries between TDM,
LSC, etc. don't have to be articulated as they are just layer networks.
Also, the designation of TDM does not include the notions of the layers
within that (e.g., DS3, STS-1, VC4, etc.) which are important to
transport equipment.  Adopting the layer architecture also enables a
client layer to be supported by an inverse multipling layer such as
provided by Virtual Concatenation.  Here a layer of finer granularity is
use to support a layer of coarser granularity.
=20

Stephen Shew         Voice: 613-763-2462  Fax: 613-763-8385
Nortel - Optical Networks  email: [email-masked]=20
P.O. Box 3511, Station C=20
Ottawa, ON K1Y 4H7=20

=20

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D574481516-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Hi Deborah,</FONT></SPAN></DIV>
<DIV><SPAN class=3D574481516-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D574481516-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Just to reassure you, I can confirm we fully understand what =
func arch is=20
and why its important (we had a big hand in doing it).&nbsp; And we also =

understand what GMPLS and MPLS are, what the 3 networking modes are, and =
how=20
they are and are not related.&nbsp; One cannot functionally crunch the =
modes=20
from 'IP to optics', it will simply not work either technically or=20
commercially.....in fact a large supplier of ours recently admitted =
(after 3=20
years of trying to persuade us otherwise) that they now agree with us on =

this.&nbsp; Those who think they can 'create topology on the fly' can =
believe in=20
this stuff if they like.....you will convince me the day I see a routing =

protocol lay a duct and light some fibre, till then we'll stick with =
what we=20
know is true.</FONT></SPAN></DIV>
<DIV><SPAN class=3D574481516-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D574481516-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV>
<DIV><SPAN class=3D574481516-12112004></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D574481516-12112004></SPAN><FONT face=3DTahoma><FONT =
size=3D2><SPAN=20
class=3D574481516-12112004><FONT face=3D"Comic Sans MS"=20
color=3D#800000>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
class=3D574481516-12112004>&nbsp;</SPAN>-----Original =
Message-----<BR><B>From:</B>=20
Brungard, Deborah A, ALABS [mailto:[email-masked]] <BR><B>Sent:</B> =
12=20
November 2004 15:23<BR><B>To:</B> Harrison,N,Neil,IKR2 R;=20
[email-masked]; [email-masked]<BR><B>Subject:</B> RE: =
Comment on=20
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Hi Neil,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>As I said in my previous mail, there seems to =
be=20
  confusion for those not familiar with GMPLS terminology. LSP is =
control plane.=20
  Nothing new here in this draft. I would suggest those concerned should =
discuss=20
  via the ITU-T SG 15 Q12/Q14 lists as the same choices were made for =
ITU's DCM=20
  (G7713.2 and G.7713.3) protocols.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV><BR>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of=20
  </B>[email-masked]<BR><B>Sent:</B> Friday, November 12, 2004 =
8:41=20
  AM<BR><B>To:</B> [email-masked];=20
  [email-masked]<BR><B>Subject:</B> RE: Comment on=20
  draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2>Folks should take note of this advice.&nbsp; We are fully in =
agreement=20
  with you on this issue Stephen.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2>BTW - G.805/809 stuff is not something dreamed-up in ITU just =
for the=20
  sake of it.....in fact its really nothing to do with ITU as&nbsp;its =
simply a=20
  formal way of capturing/defining the nature of real=20
  networks.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2></FONT></SPAN><SPAN class=3D702164712-12112004><FONT =
face=3D"Comic Sans MS"=20
  color=3D#800000 size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
  size=3D2>regards, Neil</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
    [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
    </B>Stephen Shew<BR><B>Sent:</B> 11 November 2004 =
20:02<BR><B>To:</B>=20
    [email-masked]<BR><B>Subject:</B> Comment on=20
    draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR><BR></FONT></DIV>
    <DIV><FONT color=3D#000080 size=3D2><SPAN =
class=3D687015119-11112004>I was not=20
    able to be at the CCAMP meeting today but do have some comments on =
<FONT=20
    color=3D#000000 size=3D3><FONT=20
    =
size=3D2>draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>&nbsp;&nbsp;&nb=
sp;&nbsp;=20
    </FONT></SPAN></FONT></DIV>
    <DIV><FONT color=3D#000080 size=3D2><SPAN=20
    class=3D687015119-11112004></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=3D#000080 size=3D2><SPAN =
class=3D687015119-11112004>It seems that=20
    the goals of the draft could be accomplished more simply by adopting =
the=20
    layer architecture as defined in ITU-T Recommendations G.805 and=20
    G.809.&nbsp; By doing this, the specific boundaries between TDM, =
LSC, etc.=20
    don't have to be articulated as they are just layer networks.&nbsp; =
Also,=20
    the designation of TDM does not include the notions of the layers =
within=20
    that (e.g., DS3, STS-1, VC4, etc.) which are important to transport=20
    equipment.&nbsp; Adopting the layer architecture also enables a =
client layer=20
    to be supported by an inverse multipling layer such as provided by =
Virtual=20
    Concatenation.&nbsp; Here a layer of finer granularity is use to =
support a=20
    layer of coarser granularity.</SPAN></FONT></DIV>
    <DIV>&nbsp;</DIV>
    <P dir=3Dltr align=3Dleft><FONT color=3D#000080 size=3D2>Stephen=20
    Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Voice:=20
    613-763-2462&nbsp; Fax: 613-763-8385</FONT><BR><FONT color=3D#000080 =

    size=3D2>Nortel - Optical Networks&nbsp; email:=20
    [email-masked]</FONT> <BR><FONT color=3D#000080 =
size=3D2>P.O. Box=20
    3511, Station C</FONT> <BR><FONT color=3D#000080 size=3D2>Ottawa, ON =
K1Y=20
    4H7</FONT> </P>
    <DIV>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4C8D4.B4BE5EC2--

Delivery-date: Fri, 12 Nov 2004 15:24:39 +0000
content-class: urn:content-classes:message
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Fri, 12 Nov 2004 09:23:25 -0600
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C8CB.8DDF4F26
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Neil,
=20
As I said in my previous mail, there seems to be confusion for those not
familiar with GMPLS terminology. LSP is control plane. Nothing new here
in this draft. I would suggest those concerned should discuss via the
ITU-T SG 15 Q12/Q14 lists as the same choices were made for ITU's DCM
(G7713.2 and G.7713.3) protocols.
=20
Deborah
=20
=20

  _____ =20

From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, November 12, 2004 8:41 AM
To: [email-masked]; [email-masked]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

Folks should take note of this advice.  We are fully in agreement with
you on this issue Stephen.
=20
BTW - G.805/809 stuff is not something dreamed-up in ITU just for the
sake of it.....in fact its really nothing to do with ITU as its simply a
formal way of capturing/defining the nature of real networks.
=20
regards, Neil

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Shew
	Sent: 11 November 2004 20:02
	To: [email-masked]
	Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
=09
=09
	I was not able to be at the CCAMP meeting today but do have some
comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt    =20
	=20
	It seems that the goals of the draft could be accomplished more
simply by adopting the layer architecture as defined in ITU-T
Recommendations G.805 and G.809.  By doing this, the specific boundaries
between TDM, LSC, etc. don't have to be articulated as they are just
layer networks.  Also, the designation of TDM does not include the
notions of the layers within that (e.g., DS3, STS-1, VC4, etc.) which
are important to transport equipment.  Adopting the layer architecture
also enables a client layer to be supported by an inverse multipling
layer such as provided by Virtual Concatenation.  Here a layer of finer
granularity is use to support a layer of coarser granularity.
	=20

	Stephen Shew         Voice: 613-763-2462  Fax: 613-763-8385
	Nortel - Optical Networks  email: [email-masked]=20
	P.O. Box 3511, Station C=20
	Ottawa, ON K1Y 4H7=20

	=20

------_=_NextPart_001_01C4C8CB.8DDF4F26
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Neil,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>As I said in my previous mail, there seems to =
be confusion=20
for those not familiar with GMPLS terminology. LSP is control plane. =
Nothing new=20
here in this draft. I would suggest those concerned should discuss via =
the ITU-T=20
SG 15 Q12/Q14 lists as the same choices were made for ITU's DCM (G7713.2 =
and=20
G.7713.3) protocols.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D469411515-12112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of=20
</B>[email-masked]<BR><B>Sent:</B> Friday, November 12, 2004 =
8:41=20
AM<BR><B>To:</B> [email-masked];=20
[email-masked]<BR><B>Subject:</B> RE: Comment on=20
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Folks should take note of this advice.&nbsp; We are fully in =
agreement=20
with you on this issue Stephen.</FONT></SPAN></DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>BTW - G.805/809 stuff is not something dreamed-up in ITU just =
for the=20
sake of it.....in fact its really nothing to do with ITU as&nbsp;its =
simply a=20
formal way of capturing/defining the nature of real=20
networks.</FONT></SPAN></DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN><SPAN class=3D702164712-12112004><FONT =
face=3D"Comic Sans MS"=20
color=3D#800000 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
  </B>Stephen Shew<BR><B>Sent:</B> 11 November 2004 20:02<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Comment on=20
  draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR><BR></FONT></DIV>
  <DIV><FONT color=3D#000080 size=3D2><SPAN class=3D687015119-11112004>I =
was not able=20
  to be at the CCAMP meeting today but do have some comments on <FONT=20
  color=3D#000000 size=3D3><FONT=20
  =
size=3D2>draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>&nbsp;&nbsp;&nb=
sp;&nbsp;=20
  </FONT></SPAN></FONT></DIV>
  <DIV><FONT color=3D#000080 size=3D2><SPAN=20
  class=3D687015119-11112004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#000080 size=3D2><SPAN =
class=3D687015119-11112004>It seems that=20
  the goals of the draft could be accomplished more simply by adopting =
the layer=20
  architecture as defined in ITU-T Recommendations G.805 and =
G.809.&nbsp; By=20
  doing this, the specific boundaries between TDM, LSC, etc. don't have =
to be=20
  articulated as they are just layer networks.&nbsp; Also, the =
designation of=20
  TDM does not include the notions of the layers within that (e.g., DS3, =
STS-1,=20
  VC4, etc.) which are important to transport equipment.&nbsp; Adopting =
the=20
  layer architecture also enables a client layer to be supported by an =
inverse=20
  multipling layer such as provided by Virtual Concatenation.&nbsp; Here =
a layer=20
  of finer granularity is use to support a layer of coarser=20
  granularity.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <P dir=3Dltr align=3Dleft><FONT color=3D#000080 size=3D2>Stephen=20
  Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Voice: =
613-763-2462&nbsp;=20
  Fax: 613-763-8385</FONT><BR><FONT color=3D#000080 size=3D2>Nortel - =
Optical=20
  Networks&nbsp; email: [email-masked]</FONT> <BR><FONT =
color=3D#000080=20
  size=3D2>P.O. Box 3511, Station C</FONT> <BR><FONT color=3D#000080 =
size=3D2>Ottawa,=20
  ON K1Y 4H7</FONT> </P>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4C8CB.8DDF4F26--

Delivery-date: Fri, 12 Nov 2004 13:41:24 +0000
content-class: urn:content-classes:message
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Fri, 12 Nov 2004 13:40:40 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C8BD.33266BD6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Folks should take note of this advice.  We are fully in agreement with
you on this issue Stephen.
=20
BTW - G.805/809 stuff is not something dreamed-up in ITU just for the
sake of it.....in fact its really nothing to do with ITU as its simply a
formal way of capturing/defining the nature of real networks.
=20
regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Shew
Sent: 11 November 2004 20:02
To: [email-masked]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

I was not able to be at the CCAMP meeting today but do have some
comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt    =20
=20
It seems that the goals of the draft could be accomplished more simply
by adopting the layer architecture as defined in ITU-T Recommendations
G.805 and G.809.  By doing this, the specific boundaries between TDM,
LSC, etc. don't have to be articulated as they are just layer networks.
Also, the designation of TDM does not include the notions of the layers
within that (e.g., DS3, STS-1, VC4, etc.) which are important to
transport equipment.  Adopting the layer architecture also enables a
client layer to be supported by an inverse multipling layer such as
provided by Virtual Concatenation.  Here a layer of finer granularity is
use to support a layer of coarser granularity.
=20

Stephen Shew         Voice: 613-763-2462  Fax: 613-763-8385
Nortel - Optical Networks  email: [email-masked]=20
P.O. Box 3511, Station C=20
Ottawa, ON K1Y 4H7=20

=20

------_=_NextPart_001_01C4C8BD.33266BD6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Folks should take note of this advice.&nbsp; We are fully in =
agreement=20
with you on this issue Stephen.</FONT></SPAN></DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>BTW - G.805/809 stuff is not something dreamed-up in ITU just =
for the=20
sake of it.....in fact its really nothing to do with ITU as&nbsp;its =
simply a=20
formal way of capturing/defining the nature of real=20
networks.</FONT></SPAN></DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN><SPAN class=3D702164712-12112004><FONT =
face=3D"Comic Sans MS"=20
color=3D#800000 size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D702164712-12112004><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
  </B>Stephen Shew<BR><B>Sent:</B> 11 November 2004 20:02<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Comment on=20
  draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR><BR></FONT></DIV>
  <DIV><FONT color=3D#000080 size=3D2><SPAN class=3D687015119-11112004>I =
was not able=20
  to be at the CCAMP meeting today but do have some comments on <FONT=20
  color=3D#000000 size=3D3><FONT=20
  =
size=3D2>draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>&nbsp;&nbsp;&nb=
sp;&nbsp;=20
  </FONT></SPAN></FONT></DIV>
  <DIV><FONT color=3D#000080 size=3D2><SPAN=20
  class=3D687015119-11112004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#000080 size=3D2><SPAN =
class=3D687015119-11112004>It seems that=20
  the goals of the draft could be accomplished more simply by adopting =
the layer=20
  architecture as defined in ITU-T Recommendations G.805 and =
G.809.&nbsp; By=20
  doing this, the specific boundaries between TDM, LSC, etc. don't have =
to be=20
  articulated as they are just layer networks.&nbsp; Also, the =
designation of=20
  TDM does not include the notions of the layers within that (e.g., DS3, =
STS-1,=20
  VC4, etc.) which are important to transport equipment.&nbsp; Adopting =
the=20
  layer architecture also enables a client layer to be supported by an =
inverse=20
  multipling layer such as provided by Virtual Concatenation.&nbsp; Here =
a layer=20
  of finer granularity is use to support a layer of coarser=20
  granularity.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <P dir=3Dltr align=3Dleft><FONT color=3D#000080 size=3D2>Stephen=20
  Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Voice: =
613-763-2462&nbsp;=20
  Fax: 613-763-8385</FONT><BR><FONT color=3D#000080 size=3D2>Nortel - =
Optical=20
  Networks&nbsp; email: [email-masked]</FONT> <BR><FONT =
color=3D#000080=20
  size=3D2>P.O. Box 3511, Station C</FONT> <BR><FONT color=3D#000080 =
size=3D2>Ottawa,=20
  ON K1Y 4H7</FONT> </P>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4C8BD.33266BD6--

Delivery-date: Fri, 12 Nov 2004 02:31:16 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Varma, Eve L (Eve)" <[email-masked]>
Cc: "'Stephen Shew'" <[email-masked]>, <[email-masked]>
Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Fri, 12 Nov 2004 02:25:22 -0000

Hi Eve,

As you know, those of us who do not work for ITU affiliate companies can only access three
ITU recommendations a year without paying for them. This makes it very hard for us to
consider all of the architecture documents.

I wonder if you could forward CCAMP a copy of G.809 (G.805 is well-known in this
community) so that we can include it in our discussions.

Thanks,
Adrian

----- Original Message ----- 
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Stephen Shew'" <[email-masked]>; <[email-masked]>
Sent: Thursday, November 11, 2004 9:09 PM
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

> Stephen,  What you say makes alot of sense to me.
>
> Eve
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Stephen
Shew
> Sent: Thursday, November 11, 2004 3:02 PM
> To: [email-masked]
> Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>
>
> I was not able to be at the CCAMP meeting today but do have some comments on
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
>
> It seems that the goals of the draft could be accomplished more simply by adopting the
layer architecture as defined in ITU-T Recommendations G.805 and G.809.  By doing this,
the specific boundaries between TDM, LSC, etc. don't have to be articulated as they are
just layer networks.  Also, the designation of TDM does not include the notions of the
layers within that (e.g., DS3, STS-1, VC4, etc.) which are important to transport
equipment.  Adopting the layer architecture also enables a client layer to be supported by
an inverse multipling layer such as provided by Virtual Concatenation.  Here a layer of
finer granularity is use to support a layer of coarser granularity.
>
>
> Stephen Shew         Voice: 613-763-2462  Fax: 613-763-8385
> Nortel - Optical Networks  email: [email-masked]
> P.O. Box 3511, Station C
> Ottawa, ON K1Y 4H7
>
>
>
>

Delivery-date: Fri, 12 Nov 2004 02:20:37 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Stephen Shew" <[email-masked]>
Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Fri, 12 Nov 2004 02:17:52 -0000

Hi Stephen,

> I was not able to be at the CCAMP meeting today but do have some comments on
> draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

Glad you were able to review the draft. Thanks for taking the time.
The slides for this and the other CCAMP drafts discussed at the meeting can be found at
http://www.olddog.co.uk/61/ccamp.htm

> It seems that the goals of the draft could be accomplished more simply by
> adopting the layer architecture as defined in ITU-T Recommendations G.805
> and G.809.  By doing this, the specific boundaries between TDM, LSC, etc.
> don't have to be articulated as they are just layer networks.  Also, the
> designation of TDM does not include the notions of the layers within that
> (e.g., DS3, STS-1, VC4, etc.) which are important to transport equipment.
> Adopting the layer architecture also enables a client layer to be supported
> by an inverse multipling layer such as provided by Virtual Concatenation.
> Here a layer of finer granularity is use to support a layer of coarser
> granularity.

Thank you for the pointer to G.805 and G.809.  It is very important to attempt to align
the terminologies so that we can discover whether the architectures are the same and
whether they are trying to address the same problem space. It is also always good to try
not to reinvent the wheel.

As you have no doubt noticed, the GMPLS architecture and problem space require the
capability to signal and route across multiple instances of what the ITU-T terms a
transport layer. We would gladly look at any architecture you have in this space. Can you
point us at the ITU-T document(s) that describe the architecture and solutions for routing
and signaling across multiple layers?

Thanks,
Adrian

PS As pointed out by several people in other emails, I'm not sure if we mean exactly the
same thing when we say multi-region
and multi-layer. It would be valuable if you could read the GMPLS architecture RFC and the
hierarchy draft and comment on whether you see these terms in the IETF context as matching
perfectly with ITU-T terms.

Delivery-date: Thu, 11 Nov 2004 22:25:39 +0000
content-class: urn:content-classes:message
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Thu, 11 Nov 2004 16:24:16 -0600
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Stephen Shew" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C83D.2E58A73C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Stephen,
=20
Thanks for your comments, we are glad to see the interest our draft is
receiving considering the original draft
(draft-vigoureux-shiomoto-ccamp-gmpls-mrn) submitted multiple times
since early 2003 did not;-) Our decision to split the document is
proving to have been a good move.
=20
We had no intention in this draft to introduce any new terminology, we
are using the terminology from the base GMPLS documents and
draft-ietf-mpls-lsp-hierarchy. RFC3471 and lsp-hierarchy (Section 7.1)
defines LSP regions and boundaries i.e. control plane boundaries based
on the (GMPLS) interface switching type (i.e. PSC, L2SC, TDM, LSC, FCS).
We have adopted the ITU terminology of layer when referring to data
(transport) plane (also in the GMPLS base documents).
=20
We asked at the meeting for comments to provide specific text pointers
(can send either privately or via the exploder).
=20
I am not sure the meaning of your comment "adopt the layer architecture
of ITU"? As a similar comment was made at the meeting "GMPLS switching
capabilities are not aligned with ITU layering" and in a follow-up mail
by Eve, we repeat our response, this draft is not defining (new) GMPLS
switching capabilities (or architecture). The definition of GMPLS
switching capabilities is not within the scope of this draft - they are
defined in the base GMPLS documents. Any concerns should target the
appropriate document (RFC3473, ...).=20
=20
Deborah

  _____ =20

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Shew
Sent: Thursday, November 11, 2004 3:02 PM
To: [email-masked]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

I was not able to be at the CCAMP meeting today but do have some
comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt    =20
=20
It seems that the goals of the draft could be accomplished more simply
by adopting the layer architecture as defined in ITU-T Recommendations
G.805 and G.809.  By doing this, the specific boundaries between TDM,
LSC, etc. don't have to be articulated as they are just layer networks.
Also, the designation of TDM does not include the notions of the layers
within that (e.g., DS3, STS-1, VC4, etc.) which are important to
transport equipment.  Adopting the layer architecture also enables a
client layer to be supported by an inverse multipling layer such as
provided by Virtual Concatenation.  Here a layer of finer granularity is
use to support a layer of coarser granularity.
=20

Stephen Shew         Voice: 613-763-2462  Fax: 613-763-8385
Nortel - Optical Networks  email: [email-masked]=20
P.O. Box 3511, Station C=20
Ottawa, ON K1Y 4H7=20

=20

------_=_NextPart_001_01C4C83D.2E58A73C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Stephen,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks for your comments, we are glad to see =
the interest=20
our draft is receiving considering the original draft=20
(draft-vigoureux-shiomoto-ccamp-gmpls-mrn) submitted multiple times =
since early=20
2003 did not;-) Our decision to split the document is proving to have =
been a=20
good move.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We had no intention in this draft to introduce =
any new=20
terminology, we are using the terminology from the base GMPLS documents =
and=20
draft-ietf-mpls-lsp-hierarchy. RFC3471 and&nbsp;lsp-hierarchy (Section =
7.1)=20
defines LSP regions and boundaries i.e. control plane boundaries based =
on the=20
(GMPLS) interface switching type (i.e. PSC, L2SC, TDM, LSC, FCS).=20
</FONT></SPAN><SPAN class=3D470535320-11112004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>We have adopted the ITU terminology of layer when referring to =
data=20
(transport) plane (also in the GMPLS base =
documents).</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We asked at the meeting&nbsp;for =
comments&nbsp;to=20
provide&nbsp;specific text pointers (can send either privately or via =
the=20
exploder).</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I am not sure&nbsp;the&nbsp;meaning of =
your&nbsp;comment=20
"adopt the layer architecture of ITU"? As a similar comment was made at =
the=20
meeting "GMPLS switching capabilities&nbsp;are not aligned with ITU =
layering"=20
and&nbsp;in a&nbsp;follow-up mail by Eve, we&nbsp;repeat our response, =
this=20
draft is not defining (new) GMPLS switching capabilities (or =
architecture).=20
The&nbsp;definition of GMPLS switching capabilities is not within the =
scope of=20
this draft - they are defined in the base GMPLS documents.&nbsp;Any =
concerns=20
should target the appropriate document (RFC3473, ...). =
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D470535320-11112004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Stephen=20
Shew<BR><B>Sent:</B> Thursday, November 11, 2004 3:02 PM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> Comment on=20
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT color=3D#000080 size=3D2><SPAN class=3D687015119-11112004>I =
was not able to=20
be at the CCAMP meeting today but do have some comments on <FONT =
color=3D#000000=20
size=3D3><FONT=20
size=3D2>draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>&nbsp;&nbsp;&nb=
sp;&nbsp;=20
</FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#000080 size=3D2><SPAN=20
class=3D687015119-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000080 size=3D2><SPAN class=3D687015119-11112004>It =
seems that the=20
goals of the draft could be accomplished more simply by adopting the =
layer=20
architecture as defined in ITU-T Recommendations G.805 and G.809.&nbsp; =
By doing=20
this, the specific boundaries between TDM, LSC, etc. don't have to be=20
articulated as they are just layer networks.&nbsp; Also, the designation =
of TDM=20
does not include the notions of the layers within that (e.g., DS3, =
STS-1, VC4,=20
etc.) which are important to transport equipment.&nbsp; Adopting the =
layer=20
architecture also enables a client layer to be supported by an inverse=20
multipling layer such as provided by Virtual Concatenation.&nbsp; Here a =
layer=20
of finer granularity is use to support a layer of coarser=20
granularity.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<P dir=3Dltr align=3Dleft><FONT color=3D#000080 size=3D2>Stephen=20
Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Voice: =
613-763-2462&nbsp;=20
Fax: 613-763-8385</FONT><BR><FONT color=3D#000080 size=3D2>Nortel - =
Optical=20
Networks&nbsp; email: [email-masked]</FONT> <BR><FONT =
color=3D#000080=20
size=3D2>P.O. Box 3511, Station C</FONT> <BR><FONT color=3D#000080 =
size=3D2>Ottawa, ON=20
K1Y 4H7</FONT> </P>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C4C83D.2E58A73C--

Delivery-date: Thu, 11 Nov 2004 21:47:16 +0000
Date: Thu, 11 Nov 2004 22:46:35 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To: [email-masked],  [email-masked]
To: Stephen Shew <[email-masked]>
CC: [email-masked]
Subject: Re: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

stephen, just to clarify, the slides discussed during this morning 
meeting explain the document'scope = multi-REGION-networks

where REGIONs are based on Switching Capability (SC) as being defined in 
the LSP hierarchy document:

<http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-08.txt>

the discussion is not about data plane layering/relationship or other 
specific aspects related to the data plane layer architecture (ex: 
G.805), in brief, the discussion is all about control plane -> in the 
present context a multiple SC control plane

note: for those that where not present at the meeting the slides 
discussed can be found at:

<http://home.clara.net/olddog/61/draft-shiomoto-ccamp-gmpls-mrn-reqs-00.ppt>
---

Stephen Shew wrote:

> I was not able to be at the CCAMP meeting today but do have some comments on
> draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt     
>  
> It seems that the goals of the draft could be accomplished more simply by
> adopting the layer architecture as defined in ITU-T Recommendations G.805
> and G.809.  By doing this, the specific boundaries between TDM, LSC, etc.
> don't have to be articulated as they are just layer networks.  Also, the
> designation of TDM does not include the notions of the layers within that
> (e.g., DS3, STS-1, VC4, etc.) which are important to transport equipment.
> Adopting the layer architecture also enables a client layer to be supported
> by an inverse multipling layer such as provided by Virtual Concatenation.
> Here a layer of finer granularity is use to support a layer of coarser
> granularity.
>  
> 
> Stephen Shew         Voice: 613-763-2462  Fax: 613-763-8385
> Nortel - Optical Networks  email: [email-masked] 
> P.O. Box 3511, Station C 
> Ottawa, ON K1Y 4H7 
> 
>  
> 

Delivery-date: Thu, 11 Nov 2004 21:21:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Thu, 11 Nov 2004 15:20:51 -0600
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: "Stephen Shew" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C834.528365E3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stephen,

=20

This sounds like a good practical approach.

=20

Ben

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Shew
Sent: Thursday, November 11, 2004 2:02 PM
To: [email-masked]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

=20

I was not able to be at the CCAMP meeting today but do have some
comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt    =20

=20

It seems that the goals of the draft could be accomplished more simply
by adopting the layer architecture as defined in ITU-T Recommendations
G.805 and G.809.  By doing this, the specific boundaries between TDM,
LSC, etc. don't have to be articulated as they are just layer networks.
Also, the designation of TDM does not include the notions of the layers
within that (e.g., DS3, STS-1, VC4, etc.) which are important to
transport equipment.  Adopting the layer architecture also enables a
client layer to be supported by an inverse multipling layer such as
provided by Virtual Concatenation.  Here a layer of finer granularity is
use to support a layer of coarser granularity.

=20

Stephen Shew         Voice: 613-763-2462  Fax: 613-763-8385
Nortel - Optical Networks  email: [email-masked]=20
P.O. Box 3511, Station C=20
Ottawa, ON K1Y 4H7=20

=20

------_=_NextPart_001_01C4C834.528365E3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<title>Message</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>This sounds like a good practical
approach.</span></font></p>

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

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

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
[email-masked]
[mailto:[email-masked]] <b><span style=3D'font-weight:bold'>On =
Behalf
Of </span></b>Stephen Shew<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, November =
11, 2004
2:02 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Comment on
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</span></font></p>

</div>

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

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>I was not able to be at the CCAMP =
meeting
today but do have some comments on </span></font><font size=3D2 =
color=3Dblack><span
style=3D'font-size:10.0pt;color:black'>draft-shiomoto-ccamp-gmpls-mrn-req=
s-00.txt</span></font><font
color=3Dblack><span style=3D'color:black'>&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>It seems that the goals of the =
draft could
be accomplished more simply by adopting the layer architecture as =
defined in
ITU-T Recommendations G.805 and G.809.&nbsp; By doing this, the specific
boundaries between TDM, LSC, etc. don't have to be articulated as they =
are just
layer networks.&nbsp; Also, the designation of TDM does not include the =
notions
of the layers within that (e.g., DS3, STS-1, VC4, etc.) which are =
important to
transport equipment.&nbsp; Adopting the layer architecture also enables =
a
client layer to be supported by an inverse multipling layer such as =
provided by
Virtual Concatenation.&nbsp; Here a layer of finer granularity is use to
support a layer of coarser granularity.</span></font></p>

</div>

<div>

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

</div>

<p><font size=3D2 color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:navy'>Stephen Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Voice:
613-763-2462&nbsp; Fax: 613-763-8385</span></font><br>
<font size=3D2 color=3Dnavy><span =
style=3D'font-size:10.0pt;color:navy'>Nortel -
Optical Networks&nbsp; email: [email-masked]</span></font> =
<br>
<font size=3D2 color=3Dnavy><span =
style=3D'font-size:10.0pt;color:navy'>P.O. Box
3511, Station C</span></font> <br>
<font size=3D2 color=3Dnavy><span =
style=3D'font-size:10.0pt;color:navy'>Ottawa, ON
K1Y 4H7</span></font> </p>

<div>

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

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C4C834.528365E3--

Delivery-date: Thu, 11 Nov 2004 21:10:51 +0000
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Stephen Shew'" <[email-masked]>, [email-masked]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Thu, 11 Nov 2004 16:09:26 -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_01C4C832.8D1C485C
Content-Type: text/plain

Stephen,  What you say makes alot of sense to me.
 
Eve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Stephen Shew
Sent: Thursday, November 11, 2004 3:02 PM
To: [email-masked]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

I was not able to be at the CCAMP meeting today but do have some comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt     
 
It seems that the goals of the draft could be accomplished more simply by adopting the layer architecture as defined in ITU-T Recommendations G.805 and G.809.  By doing this, the specific boundaries between TDM, LSC, etc. don't have to be articulated as they are just layer networks.  Also, the designation of TDM does not include the notions of the layers within that (e.g., DS3, STS-1, VC4, etc.) which are important to transport equipment.  Adopting the layer architecture also enables a client layer to be supported by an inverse multipling layer such as provided by Virtual Concatenation.  Here a layer of finer granularity is use to support a layer of coarser granularity.

Stephen Shew         Voice: 613-763-2462  Fax: 613-763-8385
Nortel - Optical Networks  email: [email-masked] 
P.O. Box 3511, Station C 
Ottawa, ON K1Y 4H7 

------_=_NextPart_001_01C4C832.8D1C485C
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1458" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=278090821-11112004><FONT face=Arial color=#0000ff 
size=2>Stephen,&nbsp; </FONT></SPAN><SPAN class=278090821-11112004><FONT 
face=Arial color=#0000ff size=2>What you say makes alot of sense to 
me.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV><SPAN class=278090821-11112004><FONT face=Arial color=#0000ff 
size=2>Eve</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> [email-masked] 
  [mailto:[email-masked]]<B>On Behalf Of </B>Stephen 
  Shew<BR><B>Sent:</B> Thursday, November 11, 2004 3:02 PM<BR><B>To:</B> 
  [email-masked]<BR><B>Subject:</B> Comment on 
  draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt<BR><BR></FONT></DIV>
  <DIV><FONT color=#000080 size=2><SPAN class=687015119-11112004>I was not able 
  to be at the CCAMP meeting today but do have some comments on <FONT 
  color=#000000 size=3><FONT 
  size=2>draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>&nbsp;&nbsp;&nbsp;&nbsp; 
  </FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#000080 size=2><SPAN 
  class=687015119-11112004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#000080 size=2><SPAN class=687015119-11112004>It seems that 
  the goals of the draft could be accomplished more simply by adopting the layer 
  architecture as defined in ITU-T Recommendations G.805 and G.809.&nbsp; By 
  doing this, the specific boundaries between TDM, LSC, etc. don't have to be 
  articulated as they are just layer networks.&nbsp; Also, the designation of 
  TDM does not include the notions of the layers within that (e.g., DS3, STS-1, 
  VC4, etc.) which are important to transport equipment.&nbsp; Adopting the 
  layer architecture also enables a client layer to be supported by an inverse 
  multipling layer such as provided by Virtual Concatenation.&nbsp; Here a layer 
  of finer granularity is use to support a layer of coarser 
  granularity.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <P dir=ltr align=left><FONT color=#000080 size=2>Stephen 
  Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Voice: 613-763-2462&nbsp; 
  Fax: 613-763-8385</FONT><BR><FONT color=#000080 size=2>Nortel - Optical 
  Networks&nbsp; email: [email-masked]</FONT> <BR><FONT color=#000080 
  size=2>P.O. Box 3511, Station C</FONT> <BR><FONT color=#000080 size=2>Ottawa, 
  ON K1Y 4H7</FONT> </P>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4C832.8D1C485C--

Delivery-date: Thu, 11 Nov 2004 20:04:56 +0000
From: "Stephen Shew" <[email-masked]>
To: [email-masked]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
Date: Thu, 11 Nov 2004 15:02:26 -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_01C4C829.5DAE5487
Content-Type: text/plain

I was not able to be at the CCAMP meeting today but do have some comments on
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt     
 
It seems that the goals of the draft could be accomplished more simply by
adopting the layer architecture as defined in ITU-T Recommendations G.805
and G.809.  By doing this, the specific boundaries between TDM, LSC, etc.
don't have to be articulated as they are just layer networks.  Also, the
designation of TDM does not include the notions of the layers within that
(e.g., DS3, STS-1, VC4, etc.) which are important to transport equipment.
Adopting the layer architecture also enables a client layer to be supported
by an inverse multipling layer such as provided by Virtual Concatenation.
Here a layer of finer granularity is use to support a layer of coarser
granularity.

Stephen Shew         Voice: 613-763-2462  Fax: 613-763-8385
Nortel - Optical Networks  email: [email-masked] 
P.O. Box 3511, Station C 
Ottawa, ON K1Y 4H7 

------_=_NextPart_001_01C4C829.5DAE5487
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1476" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#000080 size=2><SPAN class=687015119-11112004>I was not able to 
be at the CCAMP meeting today but do have some comments on <FONT color=#000000 
size=3><FONT 
size=2>draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt</FONT>&nbsp;&nbsp;&nbsp;&nbsp; 
</FONT></SPAN></FONT></DIV>
<DIV><FONT color=#000080 size=2><SPAN 
class=687015119-11112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#000080 size=2><SPAN class=687015119-11112004>It seems that the 
goals of the draft could be accomplished more simply by adopting the layer 
architecture as defined in ITU-T Recommendations G.805 and G.809.&nbsp; By doing 
this, the specific boundaries between TDM, LSC, etc. don't have to be 
articulated as they are just layer networks.&nbsp; Also, the designation of TDM 
does not include the notions of the layers within that (e.g., DS3, STS-1, VC4, 
etc.) which are important to transport equipment.&nbsp; Adopting the layer 
architecture also enables a client layer to be supported by an inverse 
multipling layer such as provided by Virtual Concatenation.&nbsp; Here a layer 
of finer granularity is use to support a layer of coarser 
granularity.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<P dir=ltr align=left><FONT color=#000080 size=2>Stephen 
Shew&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Voice: 613-763-2462&nbsp; 
Fax: 613-763-8385</FONT><BR><FONT color=#000080 size=2>Nortel - Optical 
Networks&nbsp; email: [email-masked]</FONT> <BR><FONT color=#000080 
size=2>P.O. Box 3511, Station C</FONT> <BR><FONT color=#000080 size=2>Ottawa, ON 
K1Y 4H7</FONT> </P>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C4C829.5DAE5487--

Delivery-date: Wed, 10 Nov 2004 21:48:26 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Cc: "'Richard Rabbat'" <[email-masked]>
Subject: RE: GMPLS topics and issues of study
Date: Wed, 10 Nov 2004 13:46:02 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C4C72B.9EB59D00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please note that the list under "Addressing" that we compiled and sent =
out
is based on the Isocore interoperability testing.
The other items:
--
RSVP message contents:
1: ERO/RRO: choice of outgoing vs. incoming interface ID
2: Forwarding destination of Path message with ERO
Control channel:
1: Best practice where multiple IP hops lie between adjacent nodes
--
are from another source so we can combine these issues as well.
Richard
=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf
Of Richard Rabbat
Sent: Wednesday, November 10, 2004 11:27 AM
To: [email-masked]
Cc: 'Rajiv Papneja'; 'Ashok Narayanan'; 'Eiji Oki'; 'Pandian, Vijay'; =
'Ong,
Lyndon'; 'Hari Rakotoranto'; [email-masked];
[email-masked]; [email-masked]
Subject: GMPLS topics and issues of study

Hi all,
=20
Based on Isocore interoperability testing results from the past few =
months,
we've found the following issues to have caused some confusion and
differences in implementation.  We'll list them here in no specific =
order
under 3 major headings.
=20
Addressing:
1. relationship between TE Router ID and OSPF router ID=20
1.1 where to use TE Router ID, OSPF Router ID and IPCC Address=20
=20
2: IP reachability (what ID's are reachable IP addresses)
=20
3: what address is used in the signaling message in the ERO/RRO
=20
4: what is used in in the IF_ID_RSVP_HOP
4.1: IP v4 Next/Previous Hop address
4.2: IPv4 address in the value field
=20
5:  what is used in the destination IPv4 address in the session object=20
=20
6:  what is used in the sender IPv4 address in sender object template
=20
7:  what is used as the Router ID in LSP_TUNNEL_INTERFACE_ID
=20
RSVP message contents:
=20
1: ERO/RRO: choice of outgoing vs. incoming interface ID
=20
2: Forwarding destination of Path message with ERO
=20
Control channel:
=20
1: Best practice where multiple IP hops lie between adjacent nodes
=20
2: use of redundant/multiple IPCC. best practices=20
=20
We're in the process of putting together what we hope to be a =
comprehensive
list of topics that may cause interop concerns. If people have thoughts
about other concerns as well, it would be great if you can email them to =
the
list or contact us directly.
=20
Yumiko Kawashima
Ashok Narayanan
Eiji Oki
Lyndon Ong
Vijay Pandian
Rajiv Papneja  =20
Richard Rabbat
Hari Rakotoranto
Kohei Shiomoto
Tomonori Takeda

------=_NextPart_000_0011_01C4C72B.9EB59D00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D516003921-10112004><SPAN=20
class=3D186554421-10112004>Please note that </SPAN>t</SPAN><SPAN=20
class=3D516003921-10112004>he list under "Addressing" that&nbsp;we =
compiled and=20
sent out is based on the Isocore interoperability=20
testing.</SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D516003921-10112004><FONT face=3DArial =
size=3D2>The<SPAN=20
class=3D186554421-10112004> other</SPAN>&nbsp;items:</FONT></SPAN></DIV>
<DIV><SPAN class=3D516003921-10112004><FONT face=3DArial=20
size=3D2>--</FONT></SPAN></DIV>
<DIV><SPAN class=3D516003921-10112004>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>RSVP message contents:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>1: ERO/RRO: choice of outgoing =
vs. incoming=20
interface ID</FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2>2: Forwarding destination of Path =
message with=20
ERO</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Control channel:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>1: Best practice where multiple IP hops =
lie between=20
adjacent nodes</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D516003921-10112004>--</SPAN></FONT></DIV></SPAN></DIV>
<DIV><SPAN class=3D516003921-10112004><FONT face=3DArial size=3D2>are =
from another=20
source so we can combine these issues as well.</FONT></SPAN></DIV>
<DIV><SPAN class=3D516003921-10112004><FONT face=3DArial=20
size=3D2>Richard</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
  </B>Richard Rabbat<BR><B>Sent:</B> Wednesday, November 10, 2004 11:27=20
  AM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> 'Rajiv Papneja'; =
'Ashok=20
  Narayanan'; 'Eiji Oki'; 'Pandian, Vijay'; 'Ong, Lyndon'; 'Hari =
Rakotoranto';=20
  [email-masked]; [email-masked];=20
  [email-masked]<BR><B>Subject:</B> GMPLS topics and =
issues of=20
  study<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Based on Isocore interoperability =
testing results=20
  from the past few months,&nbsp; we've found the following issues to =
have=20
  caused some confusion and differences in implementation.&nbsp; We'll =
list them=20
  here in no specific order<SPAN class=3D874271519-10112004> under 3 =
major=20
  headings</SPAN>.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Addressing:<BR>1. relationship =
between TE Router=20
  ID and OSPF router ID <BR>1.1 where to use TE Router ID, OSPF Router =
ID and=20
  IPCC Address </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>2: IP reachability (what ID's are =
reachable IP=20
  addresses)</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>3: what address is used in the =
signaling message=20
  in the ERO/RRO</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>4: what is used in in the =
IF_ID_RSVP_HOP<BR>4.1:=20
  IP v4 Next/Previous Hop address<BR>4.2: IPv4 address in the value=20
  field</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>5:&nbsp; what is used in the =
destination IPv4=20
  address in the session object </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>6:&nbsp; what is used in the sender =
IPv4 address=20
  in sender object template</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>7:&nbsp; what is used as the Router =
ID in=20
  LSP_TUNNEL_INTERFACE_ID</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>RSVP message contents:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>1: ERO/RRO: choice of outgoing vs. =
incoming=20
  interface ID</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>2: Forwarding destination of Path =
message with=20
  ERO</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Control channel:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>1: Best practice where multiple IP =
hops lie=20
  between adjacent nodes</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>2: use of redundant/multiple IPCC. =
best practices=20
  <BR>&nbsp;<BR>We're in the process of putting together what we hope to =
be a=20
  comprehensive list of topics that may cause interop concerns. If =
people have=20
  thoughts about other concerns as well, it would be great if you can =
email them=20
  to the list or contact us directly.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Yumiko Kawashima<BR>Ashok =
Narayanan<BR>Eiji=20
  Oki<BR>Lyndon Ong<BR>Vijay Pandian<BR>Rajiv Papneja&nbsp;&nbsp; =
<BR>Richard=20
  Rabbat<BR>Hari Rakotoranto<BR>Kohei Shiomoto<BR>Tomonori=20
Takeda</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0011_01C4C72B.9EB59D00--

Delivery-date: Wed, 10 Nov 2004 19:29:00 +0000
From: "Richard Rabbat" <[email-masked]>
To: <[email-masked]>
Cc: "'Rajiv Papneja'" <[email-masked]>, "'Ashok Narayanan'" <[email-masked]>, "'Eiji Oki'" <[email-masked]>, "'Pandian, Vijay'" <[email-masked]>, "'Ong, Lyndon'" <[email-masked]>, "'Hari Rakotoranto'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: GMPLS topics and issues of study
Date: Wed, 10 Nov 2004 11:27:10 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01C4C718.3B0AC2C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,
=20
Based on Isocore interoperability testing results from the past few =
months,
we've found the following issues to have caused some confusion and
differences in implementation.  We'll list them here in no specific =
order
under 3 major headings.
=20
Addressing:
1. relationship between TE Router ID and OSPF router ID=20
1.1 where to use TE Router ID, OSPF Router ID and IPCC Address=20
=20
2: IP reachability (what ID's are reachable IP addresses)
=20
3: what address is used in the signaling message in the ERO/RRO
=20
4: what is used in in the IF_ID_RSVP_HOP
4.1: IP v4 Next/Previous Hop address
4.2: IPv4 address in the value field
=20
5:  what is used in the destination IPv4 address in the session object=20
=20
6:  what is used in the sender IPv4 address in sender object template
=20
7:  what is used as the Router ID in LSP_TUNNEL_INTERFACE_ID
=20
RSVP message contents:
=20
1: ERO/RRO: choice of outgoing vs. incoming interface ID
=20
2: Forwarding destination of Path message with ERO
=20
Control channel:
=20
1: Best practice where multiple IP hops lie between adjacent nodes
=20
2: use of redundant/multiple IPCC. best practices=20
=20
We're in the process of putting together what we hope to be a =
comprehensive
list of topics that may cause interop concerns. If people have thoughts
about other concerns as well, it would be great if you can email them to =
the
list or contact us directly.
=20
Yumiko Kawashima
Ashok Narayanan
Eiji Oki
Lyndon Ong
Vijay Pandian
Rajiv Papneja  =20
Richard Rabbat
Hari Rakotoranto
Kohei Shiomoto
Tomonori Takeda

------=_NextPart_000_002A_01C4C718.3B0AC2C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Based on Isocore interoperability =
testing results=20
from the past few months,&nbsp; we've found the following issues to have =
caused=20
some confusion and differences in implementation.&nbsp; We'll list them =
here in=20
no specific order<SPAN class=3D874271519-10112004> under 3 major=20
headings</SPAN>.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Addressing:<BR>1. relationship between =
TE Router ID=20
and OSPF router ID <BR>1.1 where to use TE Router ID, OSPF Router ID and =
IPCC=20
Address </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2: IP reachability (what ID's are =
reachable IP=20
addresses)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3: what address is used in the =
signaling message in=20
the ERO/RRO</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>4: what is used in in the =
IF_ID_RSVP_HOP<BR>4.1: IP=20
v4 Next/Previous Hop address<BR>4.2: IPv4 address in the value=20
field</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>5:&nbsp; what is used in the =
destination IPv4=20
address in the session object </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>6:&nbsp; what is used in the sender =
IPv4 address in=20
sender object template</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>7:&nbsp; what is used as the Router ID =
in=20
LSP_TUNNEL_INTERFACE_ID</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>RSVP message contents:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1: ERO/RRO: choice of outgoing vs. =
incoming=20
interface ID</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2: Forwarding destination of Path =
message with=20
ERO</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Control channel:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1: Best practice where multiple IP hops =
lie between=20
adjacent nodes</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2: use of redundant/multiple IPCC. best =
practices=20
<BR>&nbsp;<BR>We're in the process of putting together what we hope to =
be a=20
comprehensive list of topics that may cause interop concerns. If people =
have=20
thoughts about other concerns as well, it would be great if you can =
email them=20
to the list or contact us directly.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Yumiko Kawashima<BR>Ashok =
Narayanan<BR>Eiji=20
Oki<BR>Lyndon Ong<BR>Vijay Pandian<BR>Rajiv Papneja&nbsp;&nbsp; =
<BR>Richard=20
Rabbat<BR>Hari Rakotoranto<BR>Kohei Shiomoto<BR>Tomonori=20
Takeda</FONT></DIV></BODY></HTML>

------=_NextPart_000_002A_01C4C718.3B0AC2C0--

Delivery-date: Wed, 10 Nov 2004 15:33:23 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Agenda updates on line
Date: Wed, 10 Nov 2004 15:32:31 -0000

Hi,

Agenda at http://www.olddog.co.uk/61/ccamp.htm has pointers to drafts and most slides in
place.

Further updates soon.

Adrian

Delivery-date: Wed, 10 Nov 2004 07:39:37 +0000
From: =?euc-kr?B?sei/tcit?= <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: A mismatch between the procedure and the message format in LMP
Date: Wed, 10 Nov 2004 16:37:30 +0900

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_01C4C6F8.225CB3CA
Content-Type: text/plain;
	charset="euc-kr"

Hi, ccampers

I found a mismatch description between the procedure and the message format
in LMP.
The LMP document that I have read is draft-ietf-ccamp-lmp-10.txt.
The procedure is of the link connectivity verification.
If you see the section 5.1, "Example of Link Connectivity Verification",
the section is now describing as follows:

****************************************************************************
************
	In the section, 5.1,

     o  A sends a BeginVerify message over the control channel to B
        indicating it will begin verifying the ports that form the TE
        link.  The LOCAL_LINK_ID object carried in the BeginVerify
        message carries the identifier (IP address or interface index)
        that A assigns to the link.
     o  Upon receipt of the BeginVerify message, B creates a Verify_Id
        and binds it to the TE Link from A. This binding is used later
        when B receives the Test messages from A, and these messages
        carry the Verify_Id. B discovers the identifier (IP address or
        interface index) that A assigns to the TE link by examining the
        LOCAL_LINK_ID object carried in the received BeginVerify
        message. (If the data ports are not yet assigned to the TE
        Link, the binding is limited to the Node_Id of A.) In response
        to the BeginVerify message, B sends to A the BeginVerifyAck
        message. The LOCAL_LINK_ID object carried in the BeginVerifyAck
        message is used to carry the identifier (IP address or
        interface index) that B assigns to the TE link. The
        REMOTE_LINK_ID object carried in the BeginVerifyAck message is
        used to bind the Link_Ids assigned by both A and B. The
        Verify_Id is returned to A in the BeginVerifyAck message over
        the control channel.

	In the section, 12.5.1,

   <BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
                             <MESSAGE_ID> [<REMOTE_LINK_ID>]
                             <BEGIN_VERIFY>

   The above transmission order SHOULD be followed.

   To limit the scope of Link Verification to a particular TE Link, the
   Link_Id field of the LOCAL_LINK_ID object MUST be non-zero. If this
   field is zero, the data links can span multiple TE links and/or they
   may comprise a TE link that is yet to be configured. In the special
   case where the local Link_Id field is zero, the "Verify all Links"
   flag of the BEGIN_VERIFY object is used to distinguish between data
   links that span multiple TE links and those that have not yet been
   assigned to a TE link (see Section 5).

   The REMOTE_LINK_ID object may be included if the local/remote
   Link_Id mapping is known.

   The Link_Id field of the REMOTE_LINK_ID object MUST be non-zero if
   included.

	In the section, 12.5.2,

   <BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
                                <MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
                                <VERIFY_ID>

   The above transmission order SHOULD be followed.

   The LOCAL_LINK_ID object may be included if the local/remote Link_Id
   mapping is known or learned through the BeginVerify message.
****************************************************************************
************

There is a discrepancy about the remote Link_id between the text and the
format.
In the text, the remote Link_id has been included in the BeginVerifyAck
message.
But, in the format, the remote Link_id has been included in the BeginVerify
message, not in BeginVerifyAck message.
I think that the text is correct, and the format is not correct.
I'm not sure that I would be reading an old document of LMP.

What do you think of this?

Thanks,

Young.

------_=_NextPart_001_01C4C6F8.225CB3CA
Content-Type: text/html;
	charset="euc-kr"
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=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>A mismatch between the procedure and the message format in =
LMP</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I found a mismatch description between the procedure =
and the message format in LMP.</FONT>
<BR><FONT SIZE=3D2>The LMP document that I have read is =
draft-ietf-ccamp-lmp-10.txt.</FONT>
<BR><FONT SIZE=3D2>The procedure is of the link connectivity =
verification.</FONT>
<BR><FONT SIZE=3D2>If you see the section 5.1, &quot;Example of Link =
Connectivity Verification&quot;, the section is now describing as =
follows:</FONT>
</P>

<P><FONT =
SIZE=3D2>***************************************************************=
*************************</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>In the =
section, 5.1,</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; o&nbsp; A sends a =
BeginVerify message over the control channel to B</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
indicating it will begin verifying the ports that form the TE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
link.&nbsp; The LOCAL_LINK_ID object carried in the BeginVerify</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message =
carries the identifier (IP address or interface index)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that A =
assigns to the link.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp; o&nbsp; Upon receipt of the =
BeginVerify message, B creates a Verify_Id</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and binds =
it to the TE Link from A. This binding is used later</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; when B =
receives the Test messages from A, and these messages</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; carry the =
Verify_Id. B discovers the identifier (IP address or</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interface =
index) that A assigns to the TE link by examining the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
LOCAL_LINK_ID object carried in the received BeginVerify</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message. =
(If the data ports are not yet assigned to the TE</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Link, the =
binding is limited to the Node_Id of A.) In response</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to the =
BeginVerify message, B sends to A the BeginVerifyAck</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message. =
The LOCAL_LINK_ID object carried in the BeginVerifyAck</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message =
is used to carry the identifier (IP address or</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interface =
index) that B assigns to the TE link. The</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
REMOTE_LINK_ID object carried in the BeginVerifyAck message is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used to =
bind the Link_Ids assigned by both A and B. The</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Verify_Id =
is returned to A in the BeginVerifyAck message over</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
control channel.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>In the =
section, 12.5.1,</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; &lt;BeginVerify Message&gt; ::=3D =
&lt;Common Header&gt; &lt;LOCAL_LINK_ID&gt;</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;MESSAGE_ID&gt; =
[&lt;REMOTE_LINK_ID&gt;]</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;BEGIN_VERIFY&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The above transmission order SHOULD be =
followed.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; To limit the scope of Link Verification =
to a particular TE Link, the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Link_Id field of the LOCAL_LINK_ID =
object MUST be non-zero. If this</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; field is zero, the data links can span =
multiple TE links and/or they</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; may comprise a TE link that is yet to =
be configured. In the special</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; case where the local Link_Id field is =
zero, the &quot;Verify all Links&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; flag of the BEGIN_VERIFY object is used =
to distinguish between data</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; links that span multiple TE links and =
those that have not yet been</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; assigned to a TE link (see Section =
5).</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The REMOTE_LINK_ID object may be =
included if the local/remote</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Link_Id mapping is known.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The Link_Id field of the REMOTE_LINK_ID =
object MUST be non-zero if</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; included.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>In the =
section, 12.5.2,</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; &lt;BeginVerifyAck Message&gt; ::=3D =
&lt;Common Header&gt; [&lt;LOCAL_LINK_ID&gt;]</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;MESSAGE_ID_ACK&gt; &lt;BEGIN_VERIFY_ACK&gt;</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;VERIFY_ID&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The above transmission order SHOULD be =
followed.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The LOCAL_LINK_ID object may be included =
if the local/remote Link_Id</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; mapping is known or learned through the =
BeginVerify message.</FONT>
<BR><FONT =
SIZE=3D2>***************************************************************=
*************************</FONT>
</P>

<P><FONT SIZE=3D2>There is a discrepancy about the remote Link_id =
between the text and the format.</FONT>
<BR><FONT SIZE=3D2>In the text, the remote Link_id has been included in =
the BeginVerifyAck message.</FONT>
<BR><FONT SIZE=3D2>But, in the format, the remote Link_id has been =
included in the BeginVerify message, not in BeginVerifyAck =
message.</FONT>
<BR><FONT SIZE=3D2>I think that the text is correct, and the format is =
not correct.</FONT>
<BR><FONT SIZE=3D2>I'm not sure that I would be reading an old document =
of LMP.</FONT>
</P>

<P><FONT SIZE=3D2>What do you think of this?</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C4C6F8.225CB3CA--

Delivery-date: Tue, 09 Nov 2004 17:12:00 +0000
Date: Tue, 09 Nov 2004 15:10:13 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

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

<html><body>
<img src="cid:duifgpmtae.jpeg">  <br>
</body></html>

----------zuerbjwdsawkxvvrysuj
Content-Type: image/jpeg; name="duifgpmtae.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="duifgpmtae.jpeg"
Content-ID: 

----------zuerbjwdsawkxvvrysuj
Content-Type: application/octet-stream; name="Cool_MP3.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Cool_MP3.zip"

----------zuerbjwdsawkxvvrysuj--

Delivery-date: Tue, 09 Nov 2004 15:19:35 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Slides please!
Date: Tue, 9 Nov 2004 15:18:48 -0000

Don't forget to send me your slides for CCAMP.

Thanks,
Adrian

Delivery-date: Tue, 09 Nov 2004 14:27:17 +0000
Content-class: urn:content-classes:message
Subject: RE: LMP mib and Sonet-SDH draft mis-alignment
Date: Tue, 9 Nov 2004 08:24:30 -0600
From: "Shiba, Sidney" <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>

Tom, Adrian,

I do realize the scope. Thanks for the clarification.=20

Sidney

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Tuesday, November 09, 2004 6:58 AM
To: Shiba, Sidney
Cc: Adrian Farrel; [email-masked]
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment

	I don't understand your question either. :P  The LMP protocol
is defined in the LMP specification. The MIB merely reflects
a way of viewing/controlling that information. Adrian's earlier
point was that the bits in the MIB need not reflect the
precise ordering as in the LMP specification, as long as
all cases (bits) are covered.  The agent can then do the
translation back and forth.

	--tom

> Adrian,
>
> I'm not sure I understand your statement. As a bit of Verify Transport =

> Mechanism
> is used to indicate the remote node which mechanism is going to be=20
> used for test
> messages, I was just wondering how can we guarantee interoperability=20
> if a common
> definition is not shared among vendors.
>
> In short, which one do you suggest vendors support, the bit definition =

> in
> draft-ietf-ccamp-lmp-mib-10.txt or=20
> draft-ietf-ccamp-lmp-test-soned-sdh-04.txt?
> Is there a sort of implementation agreement in the IETF world?
>
> Thanks,
>
> Sidney
>
> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, November 08, 2004 2:11 PM
> To: Shiba, Sidney; [email-masked]
> Subject: Re: LMP mib and Sonet-SDH draft mis-alignment
>
>
> Sidney,
>
> The bit flags in MIB modules are configuration indications and need=20
> not match the actual
> protocol elements bit for bit.
>
> In this particular case one might expect the implementation to map=20
> between what is
> configured and what is sent on the wire in the protocol.
>
> History dictates that LMP Test Sonet has some reserved bits on the=20
> wire, but there is no
> need to reflect this in the MIB module.
>
> OK?
>
> Adrian
>
> ----- Original Message -----
> From: "Shiba, Sidney" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, November 08, 2004 5:13 PM
> Subject: LMP mib and Sonet-SDH draft mis-alignment
>
>
> All,
>
> Can somebody let me know if there is a mib being specified for the
> draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
> Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the=20
> definitions for SONET/SDH in
> it.
>
> lmpLinkVerifyTransportMechanism OBJECT-TYPE
>    SYNTAX        BITS {
>                      -- All encoding types:
>                      payload(0),
>                      -- SONET/SDH encoding type:
>                      dccSectionOverheadBytes(1),
>                      dccLineOverheadBytes(2),
>                      j0Trace(3),
>                      j1Trace(4),
>                      j2Trace(5)
>                  }
>
> While, the bit definition in=20
> draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt don't match for J1
> and J2.
> See below:
>
>         0x0001 : Reserved
>         0x0002 DCCS: Test Message over the Section/RS DCC
>         0x0004 DCCL: Test Message over the Line/MS DCC
>         0x0008 J0-trace: J0 Section Trace Correlation
>   -->   0x0010:  Reserved
>   -->   0x0020:  Reserved
>   -->   0x0040 J1-trace: J1 Path Trace Correlation
>   -->   0x0080 J2-trace: J2 Section Trace Correlation
>
> Are both documents correct and if so, how the Verify Transport=20
> Mechanism should
> be interpreted for J1 and J2?
>
> Thanks,
>
> Sidney Shiba
>
>
>

Delivery-date: Tue, 09 Nov 2004 13:18:15 +0000
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment
Date: Tue, 9 Nov 2004 07:57:52 -0500
To: "Shiba, Sidney" <[email-masked]>

	I don't understand your question either. :P  The LMP protocol
is defined in the LMP specification. The MIB merely reflects
a way of viewing/controlling that information. Adrian's earlier
point was that the bits in the MIB need not reflect the
precise ordering as in the LMP specification, as long as
all cases (bits) are covered.  The agent can then do the
translation back and forth.

	--tom

> Adrian,
>
> I'm not sure I understand your statement. As a bit of Verify Transport 
> Mechanism
> is used to indicate the remote node which mechanism is going to be 
> used for test
> messages, I was just wondering how can we guarantee interoperability 
> if a common
> definition is not shared among vendors.
>
> In short, which one do you suggest vendors support, the bit definition 
> in
> draft-ietf-ccamp-lmp-mib-10.txt or 
> draft-ietf-ccamp-lmp-test-soned-sdh-04.txt?
> Is there a sort of implementation agreement in the IETF world?
>
> Thanks,
>
> Sidney
>
> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, November 08, 2004 2:11 PM
> To: Shiba, Sidney; [email-masked]
> Subject: Re: LMP mib and Sonet-SDH draft mis-alignment
>
>
> Sidney,
>
> The bit flags in MIB modules are configuration indications and need 
> not match the actual
> protocol elements bit for bit.
>
> In this particular case one might expect the implementation to map 
> between what is
> configured and what is sent on the wire in the protocol.
>
> History dictates that LMP Test Sonet has some reserved bits on the 
> wire, but there is no
> need to reflect this in the MIB module.
>
> OK?
>
> Adrian
>
> ----- Original Message -----
> From: "Shiba, Sidney" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, November 08, 2004 5:13 PM
> Subject: LMP mib and Sonet-SDH draft mis-alignment
>
>
> All,
>
> Can somebody let me know if there is a mib being specified for the
> draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
> Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the 
> definitions for SONET/SDH in
> it.
>
> lmpLinkVerifyTransportMechanism OBJECT-TYPE
>    SYNTAX        BITS {
>                      -- All encoding types:
>                      payload(0),
>                      -- SONET/SDH encoding type:
>                      dccSectionOverheadBytes(1),
>                      dccLineOverheadBytes(2),
>                      j0Trace(3),
>                      j1Trace(4),
>                      j2Trace(5)
>                  }
>
> While, the bit definition in 
> draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt don't match for J1
> and J2.
> See below:
>
>         0x0001 : Reserved
>         0x0002 DCCS: Test Message over the Section/RS DCC
>         0x0004 DCCL: Test Message over the Line/MS DCC
>         0x0008 J0-trace: J0 Section Trace Correlation
>   -->   0x0010:  Reserved
>   -->   0x0020:  Reserved
>   -->   0x0040 J1-trace: J1 Path Trace Correlation
>   -->   0x0080 J2-trace: J2 Section Trace Correlation
>
> Are both documents correct and if so, how the Verify Transport 
> Mechanism should
> be interpreted for J1 and J2?
>
> Thanks,
>
> Sidney Shiba
>
>
>

Delivery-date: Mon, 08 Nov 2004 20:37:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Shiba, Sidney" <[email-masked]>, <[email-masked]>
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment
Date: Mon, 8 Nov 2004 20:37:10 -0000

Well, in my turn, I don't understand your question.

There is only one definition of the bits to send on the wire in LMP. It is defined in
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt

What other definitions do you see?

The bits in draft-ietf-ccamp-lmp-mib-10.txt are used in SNMP and are not used in LMP. They
*do* define what is sent/seen on the wire, and they *do* have an exact one-to-one
relationship, but they are *not* sent on the wire.

A

----- Original Message ----- 
From: "Shiba, Sidney" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Monday, November 08, 2004 8:24 PM
Subject: RE: LMP mib and Sonet-SDH draft mis-alignment

Adrian,

I'm not sure I understand your statement. As a bit of Verify Transport Mechanism
is used to indicate the remote node which mechanism is going to be used for test
messages, I was just wondering how can we guarantee interoperability if a common
definition is not shared among vendors.

In short, which one do you suggest vendors support, the bit definition in
draft-ietf-ccamp-lmp-mib-10.txt or draft-ietf-ccamp-lmp-test-soned-sdh-04.txt?
Is there a sort of implementation agreement in the IETF world?

Thanks,

Sidney

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Monday, November 08, 2004 2:11 PM
To: Shiba, Sidney; [email-masked]
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment

Sidney,

The bit flags in MIB modules are configuration indications and need not match the actual
protocol elements bit for bit.

In this particular case one might expect the implementation to map between what is
configured and what is sent on the wire in the protocol.

History dictates that LMP Test Sonet has some reserved bits on the wire, but there is no
need to reflect this in the MIB module.

OK?

Adrian

----- Original Message ----- 
From: "Shiba, Sidney" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 08, 2004 5:13 PM
Subject: LMP mib and Sonet-SDH draft mis-alignment

All,

Can somebody let me know if there is a mib being specified for the
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the definitions for SONET/SDH in
it.

lmpLinkVerifyTransportMechanism OBJECT-TYPE
   SYNTAX        BITS {
                     -- All encoding types:
                     payload(0),
                     -- SONET/SDH encoding type:
                     dccSectionOverheadBytes(1),
                     dccLineOverheadBytes(2),
                     j0Trace(3),
                     j1Trace(4),
                     j2Trace(5)
                 }

While, the bit definition in draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt don't match for J1
and J2.
See below:

        0x0001 : Reserved
        0x0002 DCCS: Test Message over the Section/RS DCC
        0x0004 DCCL: Test Message over the Line/MS DCC
        0x0008 J0-trace: J0 Section Trace Correlation
  -->   0x0010:  Reserved
  -->   0x0020:  Reserved
  -->   0x0040 J1-trace: J1 Path Trace Correlation
  -->   0x0080 J2-trace: J2 Section Trace Correlation

Are both documents correct and if so, how the Verify Transport Mechanism should
be interpreted for J1 and J2?

Thanks,

Sidney Shiba

Delivery-date: Mon, 08 Nov 2004 20:26:22 +0000
Content-class: urn:content-classes:message
Subject: RE: LMP mib and Sonet-SDH draft mis-alignment
Date: Mon, 8 Nov 2004 14:24:59 -0600
From: "Shiba, Sidney" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Adrian,

I'm not sure I understand your statement. As a bit of Verify Transport =
Mechanism
is used to indicate the remote node which mechanism is going to be used =
for test=20
messages, I was just wondering how can we guarantee interoperability if =
a common
definition is not shared among vendors.

In short, which one do you suggest vendors support, the bit definition =
in
draft-ietf-ccamp-lmp-mib-10.txt or =
draft-ietf-ccamp-lmp-test-soned-sdh-04.txt?
Is there a sort of implementation agreement in the IETF world?

Thanks,

Sidney

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Monday, November 08, 2004 2:11 PM
To: Shiba, Sidney; [email-masked]
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment

Sidney,

The bit flags in MIB modules are configuration indications and need not =
match the actual
protocol elements bit for bit.

In this particular case one might expect the implementation to map =
between what is
configured and what is sent on the wire in the protocol.

History dictates that LMP Test Sonet has some reserved bits on the wire, =
but there is no
need to reflect this in the MIB module.

OK?

Adrian

----- Original Message -----=20
From: "Shiba, Sidney" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 08, 2004 5:13 PM
Subject: LMP mib and Sonet-SDH draft mis-alignment

All,

Can somebody let me know if there is a mib being specified for the
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the =
definitions for SONET/SDH in
it.

lmpLinkVerifyTransportMechanism OBJECT-TYPE
   SYNTAX        BITS {
                     -- All encoding types:
                     payload(0),
                     -- SONET/SDH encoding type:
                     dccSectionOverheadBytes(1),
                     dccLineOverheadBytes(2),
                     j0Trace(3),
                     j1Trace(4),
                     j2Trace(5)
                 }

While, the bit definition in draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt =
don't match for J1
and J2.
See below:

        0x0001 : Reserved
        0x0002 DCCS: Test Message over the Section/RS DCC
        0x0004 DCCL: Test Message over the Line/MS DCC
        0x0008 J0-trace: J0 Section Trace Correlation
  -->   0x0010:  Reserved
  -->   0x0020:  Reserved
  -->   0x0040 J1-trace: J1 Path Trace Correlation
  -->   0x0080 J2-trace: J2 Section Trace Correlation

Are both documents correct and if so, how the Verify Transport Mechanism =
should
be interpreted for J1 and J2?

Thanks,

Sidney Shiba

Delivery-date: Mon, 08 Nov 2004 20:12:16 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Shiba, Sidney" <[email-masked]>, <[email-masked]>
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment
Date: Mon, 8 Nov 2004 20:11:26 -0000

Sidney,

The bit flags in MIB modules are configuration indications and need not match the actual
protocol elements bit for bit.

In this particular case one might expect the implementation to map between what is
configured and what is sent on the wire in the protocol.

History dictates that LMP Test Sonet has some reserved bits on the wire, but there is no
need to reflect this in the MIB module.

OK?

Adrian

----- Original Message ----- 
From: "Shiba, Sidney" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 08, 2004 5:13 PM
Subject: LMP mib and Sonet-SDH draft mis-alignment

All,

Can somebody let me know if there is a mib being specified for the
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the definitions for SONET/SDH in
it.

lmpLinkVerifyTransportMechanism OBJECT-TYPE
   SYNTAX        BITS {
                     -- All encoding types:
                     payload(0),
                     -- SONET/SDH encoding type:
                     dccSectionOverheadBytes(1),
                     dccLineOverheadBytes(2),
                     j0Trace(3),
                     j1Trace(4),
                     j2Trace(5)
                 }

While, the bit definition in draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt don't match for J1
and J2.
See below:

        0x0001 : Reserved
        0x0002 DCCS: Test Message over the Section/RS DCC
        0x0004 DCCL: Test Message over the Line/MS DCC
        0x0008 J0-trace: J0 Section Trace Correlation
  -->   0x0010:  Reserved
  -->   0x0020:  Reserved
  -->   0x0040 J1-trace: J1 Path Trace Correlation
  -->   0x0080 J2-trace: J2 Section Trace Correlation

Are both documents correct and if so, how the Verify Transport Mechanism should
be interpreted for J1 and J2?

Thanks,

Sidney Shiba

Delivery-date: Mon, 08 Nov 2004 17:15:52 +0000
Content-class: urn:content-classes:message
Subject: LMP mib and Sonet-SDH draft mis-alignment
Date: Mon, 8 Nov 2004 11:13:09 -0600
From: "Shiba, Sidney" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4C5B6.3834778C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All,

Can somebody let me know if there is a mib being specified for the =
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the =
definitions for SONET/SDH in it.

lmpLinkVerifyTransportMechanism OBJECT-TYPE
   SYNTAX        BITS {
                     -- All encoding types:
                     payload(0),
                     -- SONET/SDH encoding type:
                     dccSectionOverheadBytes(1),
                     dccLineOverheadBytes(2),
                     j0Trace(3),
                     j1Trace(4),
                     j2Trace(5)
                 }

While, the bit definition in draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt =
don't match for J1 and J2.
See below:

        0x0001 : Reserved
        0x0002 DCCS: Test Message over the Section/RS DCC
        0x0004 DCCL: Test Message over the Line/MS DCC
        0x0008 J0-trace: J0 Section Trace Correlation
  -->   0x0010:  Reserved
  -->   0x0020:  Reserved
  -->   0x0040 J1-trace: J1 Path Trace Correlation
  -->   0x0080 J2-trace: J2 Section Trace Correlation

Are both documents correct and if so, how the Verify Transport Mechanism =
should
be interpreted for J1 and J2?

Thanks,

Sidney Shiba

------_=_NextPart_001_01C4C5B6.3834778C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>LMP mib and Sonet-SDH draft mis-alignment</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

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

<P><FONT SIZE=3D2 FACE=3D"Arial">Can somebody let me know if there is a =
mib being specified for the =
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Currently, the =
draft-ietf-ccamp-lmp-mib-10.txt still have the definitions for SONET/SDH =
in it.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">lmpLinkVerifyTransportMechanism =
OBJECT-TYPE</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BITS {</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- All encoding =
types:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; payload(0),</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- SONET/SDH =
encoding type:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
dccSectionOverheadBytes(1),</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
dccLineOverheadBytes(2),</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; j0Trace(3),</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; j1Trace(4),</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; j2Trace(5)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; }</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">While, the bit definition in =
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt don't match for J1 and =
J2.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">See below:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0001 : Reserved</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0002 DCCS: Test =
Message over the Section/RS DCC</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0004 DCCL: Test =
Message over the Line/MS DCC</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x0008 J0-trace: J0 =
Section Trace Correlation</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; --&gt;&nbsp;&nbsp; =
0x0010:&nbsp; Reserved</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; --&gt;&nbsp;&nbsp; =
0x0020:&nbsp; Reserved</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; --&gt;&nbsp;&nbsp; 0x0040 =
J1-trace: J1 Path Trace Correlation</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; --&gt;&nbsp;&nbsp; 0x0080 =
J2-trace: J2 Section Trace Correlation</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Are both documents correct and if so, =
how the Verify Transport Mechanism should</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">be interpreted for J1 and J2?</FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Sidney Shiba</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4C5B6.3834778C--

Delivery-date: Thu, 04 Nov 2004 19:18:07 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Marco Carugi" <[email-masked]>, <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>, "Scott Bradner" <[email-masked]>, <[email-masked]>, "The IETF Secretariat" <[email-masked]>
Subject: Liaison on Procedures for Modifying the Resource reSerVation Protocol (RSVP)
Date: Thu, 4 Nov 2004 13:01:29 -0000

To:      Mr. Y. Maeda, Chairman of ITU-T Working Party 3/13
         Mr. Marco Carugi, Rapporteur for ITU-T Question 11/13
From:    Adrian Farrel and Kireeti Kompella
            Co-chairs of the CCAMP Working Group of the IETF
Cc:      Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
         Scott Bradner, IETF liaison with the ITU-T
         CCAMP Working Group
For:     Information
Subject: Procedures for Modifying the Resource reSerVation Protocol (RSVP)

Dear Mr. Maeda and Mr. Carugi,

We would like to draw your attention to a recent IETF publication that may be of relevance
to your organisation in its work with MPLS and GMPLS signaling protocols.

"Procedures for Modifying the Resource reSerVation Protocol (RSVP)" has been published as
RFC 3936 and accepted by the IESG as a Best Common Practice (BCP 96).

The abstract of this document reads as follows:
    This memo specifies procedures for modifying the Resource reSerVation
    Protocol (RSVP).  This memo also lays out new assignment guidelines
    for number spaces for RSVP messages, object classes, class-types, and
    sub-objects.

    This document specifies an Internet Best Current Practices for the
    Internet Community, and requests discussion and suggestions for
    improvements.  Distribution of this memo is unlimited.

The full document can be found at http://www.ietf.org/rfc/rfc3936.txt

Yours sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Delivery-date: Thu, 04 Nov 2004 19:17:59 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Olivier Bonaventure" <[email-masked]>, "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>, "Scott Bradner" <[email-masked]>, "The IETF Secretariat" <[email-masked]>, <[email-masked]>
Subject: Liaison on Procedures for Modifying the Resource reSerVation Protocol (RSVP)
Date: Thu, 4 Nov 2004 13:04:03 -0000

To:      Mr. Gastone Bonaventura, Chairman of ITU-T Working Party 4/15
         Mr. Kam Lam, Rapporteur for ITU-T Question 14/15
From:    Adrian Farrel and Kireeti Kompella
            Co-chairs of the CCAMP Working Group of the IETF
Cc:      Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
         Scott Bradner, IETF liaison with the ITU-T
         CCAMP Working Group
For:     Information
Subject: Procedures for Modifying the Resource reSerVation Protocol (RSVP)

Dear Mr. Bonaventura and Mr. Lam,

We would like to draw your attention to a recent IETF publication that may of relevance to
your organisation in its work with MPLS and GMPLS signaling protocols.

"Procedures for Modifying the Resource reSerVation Protocol (RSVP)" has been published as
RFC 3936 and accepted by the IESG as a Best Common Practice (BCP 96).

The abstract of this document reads as follows:
     This memo specifies procedures for modifying the Resource reSerVation
     Protocol (RSVP).  This memo also lays out new assignment guidelines
     for number spaces for RSVP messages, object classes, class-types, and
     sub-objects.

     This document specifies an Internet Best Current Practices for the
     Internet Community, and requests discussion and suggestions for
     improvements.  Distribution of this memo is unlimited.

The full document can be found at http://www.ietf.org/rfc/rfc3936.txt

Yours sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Delivery-date: Thu, 04 Nov 2004 19:17:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Jim Jones" <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>, <[email-masked]>
Subject: Communication on Procedures for Modifying the Resource reSerVation Protocol (RSVP)
Date: Thu, 4 Nov 2004 13:02:31 -0000

To:      Mr. Jim Jones, Technical Chair, OIF
From:    Adrian Farrel and Kireeti Kompella
            Co-chairs of the CCAMP Working Group of the IETF
Cc:      Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
         CCAMP Working Group
For:     Information
Subject: Procedures for Modifying the Resource reSerVation Protocol (RSVP)

Dear Mr. Jones,

We would like to draw your attention to a recent IETF publication that may be of relevance
to your organisation in its work with MPLS and GMPLS signaling protocols.

"Procedures for Modifying the Resource reSerVation Protocol (RSVP)" has been published as
RFC 3936 and accepted by the IESG as a Best Common Practice (BCP 96).

The abstract of this document reads as follows:
    This memo specifies procedures for modifying the Resource reSerVation
    Protocol (RSVP).  This memo also lays out new assignment guidelines
    for number spaces for RSVP messages, object classes, class-types, and
    sub-objects.

    This document specifies an Internet Best Current Practices for the
    Internet Community, and requests discussion and suggestions for
    improvements.  Distribution of this memo is unlimited.

The full document can be found at http://www.ietf.org/rfc/rfc3936.txt

Yours sincerely,
Kireeti Kompella & Adrian Farrel, CCAMP WG chairs

Envelope-to: [email-masked]
Delivery-date: Thu, 04 Nov 2004 16:38:19 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>,  ccamp mailing list <[email-masked]>, ccamp chair  <[email-masked]>, ccamp chair <[email-masked]> 
Subject: Protocol Action: 'Link Management Protocol Management  Information Base' to Proposed Standard 
Message-Id: <[email-masked]>
Date: Thu, 04 Nov 2004 11:24:53 -0500

The IESG has approved the following document:

- 'Link Management Protocol Management Information Base '
   <draft-ietf-ccamp-lmp-mib-10.txt> as a Proposed Standard

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

The IESG contact persons are Bert Wijnen and Bill Fenner.

Technical Summary
 
  This memo defines a portion of the Management Information Base (MIB)
  for use with network management protocols in the Internet community.
  In particular, it describes managed objects for modeling the Link
  Management Protocol (LMP).
 
Working Group Summary
 
  The Working Group has consensus to publish this document as an RFC
  at Proposed Standard level.
 
Protocol Quality
 
  This document was reviewed for the IESG by Bert Wijnen

RFC-Editor note:

1. Pleas clarify text. Section 2, 2nd sentence

OLD:
         Along with Generalized MPLS (GMPLS) [RFC3471], the Link Management
    Protocol [LMP], which primary purpose is to manage traffic engineering
    (TE) links, is one of the key components of this stan dardization
    activity.

NEW:
         Generalized MPLS (GMPLS) [RFC3471] and the Link Management Protocol
    [LMP] are key components of this standardization activity. The primary
    purpose of LMP is to manage traffic engineering (TE) links.

Delivery-date: Wed, 03 Nov 2004 17:17:41 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Agenda available on-line
Date: Wed, 3 Nov 2004 17:17:05 -0000

A more accurate draft agenda can be seen at http://www.olddog.co.uk/61/ccamp.htm

Slides will be added as I get them.

Adrian

Delivery-date: Wed, 03 Nov 2004 15:29:12 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: Provisional agenda for CCAMP
Date: Wed, 3 Nov 2004 15:28:11 -0000

As usual, a lot of business, but there looks to be enough time that we will be able to
discuss the material.

Please send comments ASAP.

Speakers:
- Please have your slides to me by Tuesday noon Washington DC time.
- Recall that you want to leave some time for discussion. Don't have too many slides.

Thanks,
Adrian

====

Group Admin
  Chairs
    Admin and agenda bash (5 mins)
  Adrian
    Status of WG drafts (10 mins)
  Milestones and re-chartering at the end of the meeting

Bundling (Zafar Ali) (10 minutes)
  - Issues with current RFCs and drafts
  - Plans

ASON Solutions
  Mention OIF response is on the way
  ASON Signaling Solutions (Dimitri Papadimitriou) (5 mins)
    http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt
  ASON Routing Solutions Design Team status (Dimitri Papadimitriou) (5 mins)
    http://www.olddog.co.uk/draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt
  ITU liaison (Wesam Alanqar) (5 minutes)

Graceful Shutdown
  Graceful shutdown (Zafar Ali) (10 minutes)
  http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-00.txt

Inter-Area/AS
  Inter-domain Framework (Adrian) (5 minutes)
    http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-00.txt

  Inter-AS TE requirements for GMPLS (Tomohiro Otani) (5 minutes)
    http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-01.txt

  Status and plans of PCE BOF (JP Vasseur) (5 minutes)

  Inter-domain TE LSP path computation methods (JP Vasseur) (5 minutes)
    http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-inter-domain-path-comp-00.txt

  Inter-domain RSVP-TE (Arthi Ayyangar) (5 minutes)
    http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt

  Multi-region/multi-layer (Kohei Shiomoto and Dimitri Papadimitriou) (15 minutes)
    http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-requirements-00.txt
    http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-extensions-00.txt

  Diverse path inter-area/AS
    Inter-region Path Setup (???) (5 minutes)
      http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-04.txt
    Inter-AS protection path establishment (Cristel Pelsser) (5 minutes)
      http://www.ietf.org/internet-drafts/draft-decnodder-ccamp-interas-protection-00.txt
    Discussion (5 minutes)

MPLS/GMPLS migration (Kohei Shiomot/Eiji Oki) (10 minutes)
  http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-04.txt

Layer 1 VPN Updates (Tomonori Takeda) (10 mins)
  http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt
  http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt
  http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt
  http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt

Layer 2 Switching Capabilities (Dimitri Papadimitriou) (10 minutes)
  http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt

Mesh protection carrier survey (Richard Rabbat) (5 minutes)
  http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-01.txt

Milestones and Rechartering (Kireeti) (10 minutes)

Delivery-date: Wed, 03 Nov 2004 09:59:13 +0000
Date: Wed, 03 Nov 2004 06:57:46 -0300
To: "Ccamp" <[email-masked]>
From: "Kireeti" <[email-masked]>
Subject: Re:

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

<html><body>
<img src="cid:wuawtszmtf.gif"> <br>
</body></html>

----------vbntqgbuzbefqzcdcaqn
Content-Type: image/gif; name="wuawtszmtf.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="wuawtszmtf.gif"
Content-ID: 

----------vbntqgbuzbefqzcdcaqn
Content-Type: application/octet-stream; name="New_MP3_Player.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="New_MP3_Player.zip"

----------vbntqgbuzbefqzcdcaqn--

Envelope-to: [email-masked]
Delivery-date: Tue, 02 Nov 2004 20:05:06 +0000
To: IETF-Announce <[email-masked]> 
From: The IESG <[email-masked]>
Subject: Last Call: 'Generalized Multi-Protocol Label Switching (GMPLS)  Recovery Functional Specification' to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Message-Id: <[email-masked]>
Date: Tue, 02 Nov 2004 14:51:40 -0500

The IESG has received a request from the Common Control and Measurement Plane 
WG to consider the following documents:

- 'Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional 
   Specification '
   <draft-ietf-ccamp-gmpls-recovery-functional-03.txt> as a Proposed Standard
- 'Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based 
   Recovery Mechanisms (including Protection and Restoration) '
   <draft-ietf-ccamp-gmpls-recovery-analysis-04.txt> as an Informational RFC
- 'Recovery (Protection and Restoration) Terminology for Generalized 
   Multi-Protocol Label Switching (GMPLS) '
   <draft-ietf-ccamp-gmpls-recovery-terminology-05.txt> as an Informational RFC

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 2004-11-30.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-0
3.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-analysis-04.
txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-
05.txt

Delivery-date: Tue, 02 Nov 2004 08:32:49 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: L1VPN mailing list archives
Date: Tue, 2 Nov 2004 08:28:39 -0000

Sorry, forwarded the wrong message.
I raised trouble tickets for each list.
A

> Your subject says L1VPN archives... and by golly you're
> right there too! Those are down, I just checked, so a
> trouble ticket for this is probably needed as well.
> 
> -Vishal
> 
> > -----Original Message-----
> > From: Adrian Farrel [mailto:[email-masked]]
> > Sent: Sunday, October 31, 2004 1:24 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: L1VPN mailing list archives
> > 
> > 
> > Hi Vishal, 
> > 
> > Thanks for flagging this. I raised the problem with the 
> > Secretariat some six 
> > weeks ago, but I didn't follow up. I have raised a new trouble ticket. 
> > 
> > Adrian 
> > 
> > > Hi Adrian, 
> > > 
> > > The link to the PCE archives on the PCE signup page does
> > > not seem to work. Are there no archives of the PCE
> > > mailing list? 
> > > 
> > > -Vishal
> >  
> > 
> 
> 
> 

Delivery-date: Mon, 01 Nov 2004 17:18:01 +0000
To: [email-masked]
Subject: RFC 3946 on Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Mon, 01 Nov 2004 09:14:26 -0800

--NextPart

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

        RFC 3946

        Title:      Generalized Multi-Protocol Label Switching (GMPLS)
                    Extensions for Synchronous Optical Network (SONET)
                    and Synchronous Digital Hierarchy (SDH) Control
        Author(s):  E. Mannie, D. Papadimitriou
        Status:     Standards Track
        Date:       October 2004
        Mailbox:    [email-masked],
                    [email-masked]
        Pages:      26
        Characters: 52205
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ccamp-gmpls-sonet-sdh-08.txt

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

This document is a companion to the Generalized Multi-Protocol
Label Switching (GMPLS) signaling.  It defines the Synchronous
Optical Network (SONET)/Synchronous Digital Hierarchy (SDH)
technology specific information needed when using GMPLS signaling.

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

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

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

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

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

...

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

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3946

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

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

--OtherAccess--
--NextPart--

Delivery-date: Mon, 01 Nov 2004 17:15:29 +0000
To: [email-masked]
Subject: RFC 3945 on Generalized Multi-Protocol Label Switching (GMPLS) Architecture
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Mon, 01 Nov 2004 09:12:30 -0800

--NextPart

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

        RFC 3945

        Title:      Generalized Multi-Protocol Label Switching (GMPLS)
                    Architecture
        Author(s):  E. Mannie, Ed.
        Status:     Standards Track
        Date:       October 2004
        Mailbox:    [email-masked]
        Pages:      69
        Characters: 166700
        Updates/Obsoletes/SeeAlso:    None

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

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

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.

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

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

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

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

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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

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

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

...

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

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3945

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

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

--OtherAccess--
--NextPart--

Delivery-date: Mon, 01 Nov 2004 17:07:17 +0000
Reply-To: <[email-masked]>
From: "Vishal Sharma" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: L1VPN mailing list archives
Date: Mon, 1 Nov 2004 09:05:55 -0800

Hi Adrian,

Your subject says L1VPN archives... and by golly you're
right there too! Those are down, I just checked, so a
trouble ticket for this is probably needed as well.

-Vishal

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Sunday, October 31, 2004 1:24 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: L1VPN mailing list archives
> 
> 
> Hi Vishal, 
> 
> Thanks for flagging this. I raised the problem with the 
> Secretariat some six 
> weeks ago, but I didn't follow up. I have raised a new trouble ticket. 
> 
> Adrian 
> 
> > Hi Adrian, 
> > 
> > The link to the PCE archives on the PCE signup page does
> > not seem to work. Are there no archives of the PCE
> > mailing list? 
> > 
> > -Vishal
>  
> 

Delivery-date: Mon, 01 Nov 2004 15:21:38 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Scott Bradner" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "Tove Madsen" <[email-masked]>
Subject: Flurry of liaisons
Date: Mon, 1 Nov 2004 15:18:11 -0000

Hi,

Over the next few days you will see a bunch of liaisons chiefly to ITU-T SG15 Question 14.

Hopefully there is nothing controversial about this. We are simply trying to open up the
process and make sure that our colleagues in the ITU-T are aware of the work that has been
going on in CCAMP and are letting them see copies of relevant drafts. Of course, any
feedback we get as a result will all be grist to our mill.

Please speak up if there are any issues with this.

Thanks,
Adrian

Delivery-date: Mon, 01 Nov 2004 13:13:17 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Consensus on value of PCE for inter-domain
Date: Mon, 1 Nov 2004 13:11:35 -0000

Hi,

Thanks to those who responded.

What I think I am hearing is that many people, especially SPs, consider that PCE may be an
appropriate technique to solve some of the path computation issues associated with
inter-domain MPLS TE. It would, perhaps, be nice to hear from one or two more vendors on
this.

I also heard one or two reservations based (IMHO) on the fact that the PCE architecture
and applicability have not been fully thought-out and written down. Clearly we are not
asking for an absolute statement that PCE *WILL* be used in the inter-domain environment,
but we are looking for an opinion that PCE *MIGHT* be appropriate.

I will take this as input to the PCE BOF and as a commitment that if the PCE BOF leads to
a working group, CCAMP (as the WG responsible for inter-domain MPLS-TE) will help to
generate requirements for PCE in an inter-domain environment.

If anyone believes strongly that this is not the case, please speak up in the next couple
of days.

Thanks,
Adrian

Delivery-date: Mon, 01 Nov 2004 02:25:02 +0000
Date: Mon, 01 Nov 2004 11:23:49 +0900
From: "K. Miyazaki" <[email-masked]>
To: [email-masked]
Subject: iPOP2005 Call for Presentation and Exhibition

CALL FOR PRESENTATION AND EXHIBITION
****************************************************************
The International Conference on IP + Optical Network (iPOP 2005)
****************************************************************

GMPLS Interoperability Public Demonstration,
Exhibition and Conference$B!!(B
Tokyo,$B!!(BJapan,
February 21-22, 2005

http://www.pilab.org/ipop2005/

Sponsored by PIL(Photonic Internet Lab),
ISOCORE, and PIF(Photonic Internet Forum)

-----------------------------------------------------------------------
The international conference on IP + Optical network (iPOP 2005) will
be held at the Tokyo Fashion Town (TFT) Hall in Tokyo, Japan, from
February 21 to February 22, 2005.
The conference is intended to share among the industry and the academia
communities, the knowledge, new findings, and experience on the
state-of-the art of IP and optical networking technologies.
It features a public demonstration of GMPLS interoperability showcase
by world-wide vendors, including Protection/Restoration and Multi-layer
interworking, novel GMPLS product exhibitions, and technical sessions.
The opportunity to participate in the showcase is open to all vendors.
-----------------------------------------------------------------------

=============================================
CALL FOR GMPLS INTEROPERABILITY PARTICIPATORS
=============================================

iPOP 2005 is soliciting participation proposals for its GMPLS
interoperability showcase, in addition to PIL and ISOCORE member companies.
The topics of the interoperability will include the following:

* GMPLS Signaling and Routing
* GMPLS-based Protection and Restoration
* Multi-region/layer Interworking, such as Optical and Packet Networks

Please contact

mailto:[email-masked]

for additional information.

=====================
CALL FOR PRESENTATION
=====================
The Technical Program Committee for iPOP 2005 is soliciting presentation
proposals for this conference. Protocol design, experiment, theory,
implementation, and operational experiences are solicited.
The topics of the conference will include the following, but will not be
limited to:

* GMPLS, ASON, OUNI
* Protection & restoration
* Multi-region network
* Inter-area/Inter-AS network
* Routing wavelength assignment
* Impairment/management in all optical network
* Traffic engineering
* Network management, OA&M
* Software/Hardware implementation, interoperability
* Testbed, field trial
* Optical burst switching
* Optical service, such as L1VPN, Bandwidth on Demand, and Photonic Grid
* Application with high-bandwidth demand

If you wish to propose a particular topic for consideration,
please send a one page summary (less than 400 words),
including speaker's name, affiliation, and contact information
to the Technical Program Committee at:

mailto:[email-masked].

See

http://www.pilab.org/ipop2005/

for more details.

Important Dates+++++++++++++++++++++++++++++++++++++++++++++++
$B!!(BNovember 15, 2004 --- Deadline of submission (extended)
$B!!(BDecember 15, 2004 --- Notification of acceptance
$B!!(BJanuary 8, 2005 --- Final camera ready copy
$B!!(BJanuary 31, 2005 --- Deadline of conference pre-registration
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

============================
CALL FOR EXHIBITOR PROPOSALS
============================

You are invited to exhibit at the international conference
on IP + Optical network (iPOP 2005), February 21-22, 2005,
at the Tokyo Fashion Town (TFT) Hall in Tokyo, Japan.

The conference is intended to share among the industry and
the academia communities, the knowledge, new findings, and
experience on the state-of-the-art of
"IP and Optical Networking technologies".
Within this theme we intend to demonstrate GMPLS network equipment
(IP routers, SONET/SDH XCs, Optical/Photonic XCs), GMPLS protocol
test equipment, GMPLS network operation support tools,
Optical Switches, and other related issues. Additionally, we will
provide a showcase for GMPLS interoperability.

iPOP 2005 anticipates a draw of over 200 attendees, made up of
network operators, service providers, and equipment vendors.

Join us and other industry leaders in the IP + Optical network
technologies and leading source of industry information for GMPLS
technologies.
The early bird deadline for exhibitors is November 1, 2004.
Please contact

mailto:[email-masked]

for additional exhibitor prospectus information.

Exhibit space is limited and will be committed on a first-come
first-serve basis.

LOCATION++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The Tokyo Fashion Town (TFT) Hall is located in Tokyo$B!G(Bs newly developed
sea-front area known as Odaiba. It is easily accessible by public
transport from downtown Tokyo and Narita International Airport.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

**************************
iPOP2005 COMMITTEE MEMBERS
**************************

General Chairs:Tomonori Aoyama, University of Tokyo,
and Bijan Jabbari, ISOCORE.

Technical Program Committee
Chairs: Tadanobu Okada, NTT, Japan,
and (TBD).
Vice Chairs: Kohei Shiomoto, NTT, Japan,
and Akira Chugo, Fujitsu, Japan.
Secretary: Keiji Miyazaki, Fujitsu, Japan.

Organization Committee
Chair: Naoaki Yamanaka, Keio University, Japan.
Secretary: Akira Misawa, NTT, Japan.
Treasurer: Shinya Nakamura, NEC, Japan.
Local Arrangement: Hiroyuki Sakamoto, Oki Electric, Japan.
Publication: Shoichiro Seno, Mitsubishi Electric, Japan.

Exhibition Committee
Chair: Satoru Okamoto, NTT, Japan.
Vice Chairs: Shoji Fukutomi, Furukawa Electric, Japan,
and Hideaki Tsushima, Hitachi Communication Technology, Japan.
Secretary: Kazumasa Morita, Furukawa Electric, Japan,
and Naomichi Nonaka, Hitachi, Japan.

***********
SPONSORSHIP
***********

iPOP 2005 is sponsored by PIL and ISOCORE,
and technically co-sponsored by PIF.

------------------------------------------------------------------
PIL
(Photonic Internet Lab, http://www.pilab.org),
founded by 6 vendors and 1 service provider in 2002,
is promoting R&D on next-generation photonic network
control protocols based on photonic technologies
for managed networks.
------------------------------------------------------------------
ISOCORE
(Isocore Internetworking Lab, http://www.isocore.com)
is the leading technology validation lab in the next
generation IP and optical networking.
Its goal is to advance internetworking through technology
validation and product verification and to promote development
and rapid deployment of innovative networking technologies.
------------------------------------------------------------------
PIF
(Photonic Internet Forum, http://www.scat.or.jp/photonic/english/)
is a non-profit organization contributing to the progress of
info-communication technology to realize all optical
ultra-high-speed networks.
------------------------------------------------------------------