Subject: Re: Draft minutes from Tove

From: Ugo Monaco <[email-masked]>
Date: Fri, 03 Dec 2004 11:09:26 +0100

Hi Adrian and all,
just some notes about the minutes from Tove:

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

In the presentation
(http://home.clara.net/olddog/61/draft-achille-diverse-inter-region-path-setup-01-v3.ppt)
slide 3 the figure is actually correct because it illustrates the same 
node (head-end) on two sides of the source, to show how the ARO can be
flipped to become the ERO.

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

We want stress that ARO addresses requirements from the TEWG draft too
(draft-ietf-tewg-interas-mpls-te-req-09.txt), in particular is in
accordance with Section:

5.1.1. Inter-AS MPLS TE Operations and Interoperability
5.1.5.  Re-optimization
5.1.8. Scalability and Hierarchical LSP Support
5.1.11. Extensibility
6. Security Considerations

This was also the basis on which we got some good feedback
from the service provider community in the extensive discussions
before, during, and after Seoul.
May be we need to better point out this issue in the next version of the
draft.

Finally the phrase "need further feedback" looks not clear, who needs
feedback? -the list or the authors ?-

Best Regards
Ugo Monaco

-- 
*********************************************************************
Ugo Monaco                                              INFOCOM Dept.
Ph.D. Student                                      Via Eudossiana, 18
Phone: +39-06-47825184                             00184 Roma (Italy)
E-mail: [email-masked]               Fax: +39-06-48930606
*********************************************************************

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 4 Dec 2004 18:39:50 -0000

Hi Ugo,

Thanks for your comments.

> flipped to become the ERO.

Noted. In fact, my comment at the meeting was not to claim that there was an error in the
slide, but to draw people's attention to what was going on in the slide.

> We want stress that ARO addresses requirements from the TEWG draft too

OK. This is a punctuation error in the minutes.

"-- Differs from 11, addresses requirements from TEWG draft"

should read

"-- Differs from 11
 --Addresses requirements from TEWG draft"

We will update the minutes.

> feedback? -the list or the authors ?-

Despite the fact that both drafts have been around for some while, the level of discussion
on the ccamp list has been quite low. I also have the impression that the interest in
implementation is not (yet) very strong. As the working group moves on to specify the
problem space that we are trying to resolve, I hope that we will see more debate about the
possible solutions with a view to arriving at a single set of protocol extensions.

Adrian

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 04 Dec 2004 22:20:28 +0100

hi adrian,

a small comment:

> Adrian - Note: Node_Id based Hello has not been updated before
> deadline

i mentioned that the update of the Node_Id based Hello document has been 
effectively submitted before the deadline

thanks,
- dimitri.

Adrian Farrel wrote:

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 5 Dec 2004 12:12:57 -0000

Hi,

You're right. It was published on 26th October, but that means it must have been submitted
before then.

Can you remind me? This revision was to address all of the WG last call comments; yes?

Can you summarise the changes you made for the list, please.

Thanks,
Adrian

---

From: "Vishal Sharma" <[email-masked]>
Date: Mon, 6 Dec 2004 22:21:45 -0800

Hi Adrian,

Some comments, observations, and questions in-line,
in two successive emails.

Here's the first.

-Vishal

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Saturday, December 04, 2004 10:40 AM
> To: Ugo Monaco
> Cc: [email-masked]; Vishal Sharma; Alessio D'Achille; Daniele Alì;
> Marco Listanti; Tove Madsen

<snip>

>We will update the minutes.

I think it would be good for the minutes to then also note that
http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-0
4.txt

also directly address the requirements from the TE requirements
draft, as below.

---

From: "Vishal Sharma" <[email-masked]>
Date: Mon, 6 Dec 2004 22:21:48 -0800

Hi Adrian,

Some comments, observations, and questions in-line
in two successive emails.

Here's the second ...

-Vishal

<snip>

>Despite the fact that both drafts have been around for some while, the
level of
> discussion
>on the ccamp list has been quite low.

I think a few clarifications are rather crucial here:

-- The diverse routing draft has, in fact, received significant discussion
and debate (from all of the people involved in the inter-area work --
vendors
and providers), right during and after Seoul, from March-May 04 -- please
see
the CCAMP WG archives for about 60-70-odd emails on it. (I'm not sure
how one could classify this as "low".)

Draft-decnodder by contrast has seen much less (perhaps 2-3 emails), if any,
discussion, so clubbing the two drafts in the same category w.r.t. the
level of discussion doesn't seem appropriate.
(It has largely come from me and a couple others.)

So, I think we need to be a bit careful when evaluating the extent of
discussion.

-- There was also significant discussion of this subject in San Diego --
cf. the CCAMP WG meeting minutes again.

Since it was then clearly stated that CCAMP WG would focus on the "simple"
TE aspects first, with diverse routing deemed an "advanced" subject, so
naturally for a short while there wasn't much that could be done in
this area, as people began focussing on the "simple" aspects.

> I also have the impression that the interest in
>implementation is not (yet) very strong.

I believe implementation interest will pick up once CCAMP formally
states an intent to look at this problem (as has already happened by the
structuring of the WG meeting at D.C.).

> As the working group moves on to specify the
>problem space that we are trying to resolve, I hope that we will see more
debate about
>possible solutions with a view to arriving at a single set of protocol
extensions.

I'm not clear on what is meant by your statement above.

A number of the diverse routing/protection etc. drafts are looking
at different problems (e.g. draft-decnodder is looking at inter-area
link protection, while draft-dachille is looking at diverse inter-region
path setup), so it is not clear how a single set of protocol extensions
would serve?

---

From: "Vishal Sharma" <[email-masked]>
Date: Mon, 6 Dec 2004 22:27:22 -0800

And, I should add, that the only protocol "extension" that
draft-dachille requires is an ARO object, which is cloned
after the ERO object, and can simply be "flipped" to form
the ERO object of the second (diverse) path when setting
up that path.
(As was illustrated in the fig. on slide 3 of the D.C.
presentation.)

-Vishal

> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Monday, December 06, 2004 10:22 PM
> To: Adrian Farrel; Ugo Monaco
> Cc: [email-masked]; Alessio D'Achille; Daniele Alì; Marco Listanti;
> Tove Madsen
> Subject: RE: Draft minutes from Tove:
> draft-dachille-inter-region-path-setup-04.txt
>
>
> Hi Adrian,
>
> >Despite the fact that both drafts have been around for some
> while, the level of
> > discussion
> and debate (from all of the people involved in the inter-area
> work -- vendors
> and providers), right during and after Seoul, from March-May 04
> -- please see
> >problem space that we are trying to resolve, I hope that we will
> see more debate about
> > the

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Dec 2004 11:39:28 -0000

Vishal,

This is a good point that you should definitely be raising in the discussions about your
draft.

I can't however, update the minutes to reflect things you would have liked to have been
said at the meeting.

A

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Dec 2004 12:19:01 -0000

Vishal,

> > level of discussion on the ccamp list has been quite low.
>
> vendors and providers), right during and after Seoul, from March-May 04
> -- please see the CCAMP WG archives for about 60-70-odd emails on it.
> (I'm not sure how one could classify this as "low".)

You're right, there was some thorough debate on the detailed function as described in an
earlier version of the draft, and you have done a lot to address those issues.

What I am missing (but maybe the community doesn't care?) is a higher-level debate about
the methodology to solve what might best be described as a hard problem. In other words,
while it is fine to get into the details of how ARO works and to polish that solution, I
have not seen the debate as to whether we want to adopt ARO.

In order to pursue this, we are now in need of some effort to develop a framework for
inter-domain diverse path computation.

We're now trying to put some text together for this (if it is a small amount of text it
will go into the existing framework draft - if it turns out to be a lot of text it will go
into its own draft). I know that you, Vishal, have volunteered to get the ball rolling and
when I have your text I will add my own (politically correct) spin before putting it out
to the list for debate.

> (It has largely come from me and a couple others.)

Yes. It is not as old as a draft, and has seen less debate.

> this area, as people began focussing on the "simple" aspects.

Yes. That's good, isn't it?
And now we are ready to move on to the diverse path issues and so it is appropriate to
open up the discussions.

> structuring of the WG meeting at D.C.).

What I mean is that I do not hear from providers (or vendors) that they are currently
trying to solve this problem in deployed networks. At the moment, they are still
struggling with simple, unprotected inter-AS TE.

> >As the working group moves on to specify the problem space that we
> >are trying to resolve, I hope that we will see more debate about the

I mean that we should aim to have a single protocol solution if it can be applied to a
wide variety of scenarios, rather than a set of different protocol extensions that are
applicable to specific subsets of the problem. Perhaps, in answer to your point below, it
is not clear why a single set of protocol extensions could not be found to serve in both
(all) cases. If that means that neither of the existing drafts is sufficient, that sits
well with me.

> path setup), so it is not clear how a single set of protocol extensions

Do you really mean inter-region? It seems to me that inter-region is really covered by the
region transit work covered in the two MRN drafts. It is relatively unlikely that an LSP
will start in one region and end in another - the encapsulation and adaptation rules to
achieve that don't look nice. But, perhaps someone has a requirement to deploy this?

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Dec 2004 12:24:49 -0000

> (As was illustrated in the fig. on slide 3 of the D.C.

We're in agreement.
There is a protocol extension and consequent increase in signaling load.
It is not a substantial increase.

Cheers,
Adrian

---

From: "Vishal Sharma" <[email-masked]>
Date: Tue, 7 Dec 2004 07:53:37 -0800

Hi Adrian,

Continuing on the thread of my previous email, of discussing
some of the points raised below one-by-one ...

-Vishal

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 07, 2004 4:19 AM
> To: [email-masked]; Ugo Monaco
> Cc: [email-masked]; Alessio D'Achille; Daniele Alì; Marco Listanti
> Subject: Re: Draft minutes from Tove:

Sure, great. I know I've promised this, and we need to discuss
some of this to know just how much we should write.
I guess we'll talk off-line and come up with something that
nicely captures the essense of the diverse path computation
issue for the framework draft (or another one).

---

From: "Vishal Sharma" <[email-masked]>
Date: Tue, 7 Dec 2004 07:53:33 -0800

Adrian,

Thanks for the observations. I have several things I'd want
to discuss with respect to your note below, and will take
them one-by-one in different emails to break the discussion
down to small, manageable emails that folks can read easily.

-Vishal

<snip>

> requirement to deploy this?

Wait a minute... there seems a fundamental contradiction above.

So, first things first ...
If what you say is true (that LSPs are unlikely to start in one
region and end in another), why are all of us in
CCAMP working on inter-region LSP issues?

---

From: "Vishal Sharma" <[email-masked]>
Date: Tue, 7 Dec 2004 07:53:30 -0800

Adrian,

> Sent: Tuesday, December 07, 2004 4:25 AM

I'm not sure why a protocol extension should lead necessarily to an increase
in signalling load?

Is the load you're talking about simply that an additional
ARO object needs to be carried during the setting up of the first
of the two LSPs? Or, do you mean something else?

Then again, if one is trying to set up two paths, clearly some
additional signaling will be required (beyond that required
for one path) in any approach.

The main benefit of the ARO approach is the fact that it achieves
this with minimal modifications to the signaling protocol and with
minimal overhead, and without requiring new protocols to be defined
or new uses of existing protocols to be defined.

-Vishal

---

From: "Vishal Sharma" <[email-masked]>
Date: Tue, 7 Dec 2004 08:04:31 -0800

Hi Adrian,

A bit more discussion ...

-Vishal

<snip>

> Yes. It is not as old as a draft, and has seen less debate.

Not to belabor the point or beat on draft-decnodder, but I think it's
important to keep the records straight.

draft-decnodder (in earlier versions) predates by _a year_ draft-dachille,
having
been first released in February 2003, whereas draft-dachille was
first released only in January 2004.

See ...

http://www.potaroo.net/ietf/all-ids/draft-decnodder-mpls-interas-protection-
00.txt

But, yes, it true that this draft has not seen any debate as such.
(I am not quite sure why though, as the subject is an important one, and I
did initiate debate on it in March 04.)

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Dec 2004 16:05:41 -0000

Hi,

> down to small, manageable emails that folks can read easily.

Fair enough.

> CCAMP working on inter-region LSP issues?

I think this is just a terminology issue.
"Region" got stolen by the hierarchy draft.
   The information carried in the Interface Switching Capabilities is
   used to construct LSP regions, and determine regions' boundaries as
   follows.
draft-ietf-mpls-lsp-hierarchy-08.txt section 7.

This is confirmed in draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

Thus, when trying to consolidate the work within CCAMP I picked "domain" which seemed to
be largely unused around GMPLS. In draft-ietf-ccamp-inter-domain-framework-00.txt we
have...
   For the purposes of this document, a domain is considered to be any
   collection of network elements within a common sphere of address
   management or path computational responsibility. Examples of such
   domains include IGP areas and Autonomous Systems.

As an aside, nested domains are currently out of scope of
draft-ietf-ccamp-inter-domain-framework-00.txt because they are simply treated using FAs.
There is, therefore a clear overlap between nested domains and regions.

A

---

From: "Vishal Sharma" <[email-masked]>
Date: Tue, 7 Dec 2004 08:30:58 -0800

Adrian,

Continuing on ...

<snip>

> struggling with simple, unprotected inter-AS TE.

I'm not sure why you say that. As far as I can see, both Cisco
and Juniper have been working on various versions of solutions for
the inter-region (inter-domain, which ever is more appropriate)
space for quite a while.

And, 7-odd providers have, after quite some debate, distilled the
requirements for inter-area and inter-AS TE that have come from the
TE WG, so I assume they are interested in having those requirements
be met.

I agree that providers and vendors may currently be focusing on
simple, inter-AS (inter-domain) TE, but the fact that we have
requirements for diverse path routing articulated in the inter-area
and inter-AS requirements documents suggests that this is a problem
they would like to have solutions for.

-Vishal

---

From: "Vishal Sharma" <[email-masked]>
Date: Tue, 7 Dec 2004 08:31:01 -0800

Adrian,

A few last comments on your note ...

<snip>

> And now we are ready to move on to the diverse path issues and so

Sure, I agree that it is good to discuss the subject again now.

(Although, the conclusion at San Diego, did put a bit of a damper
on work in this area, at least in so far as discussion on CCAMP goes.
Of course, that did not actually stop progress on the work, as is
evident from the additional simulation results presented during
the presentation of draft-dachille in D.C. last month.)

<snip>

> (all) cases. If that means that neither of the existing drafts is

I agree that the fewer enhancements to a protocol we make the
better it is. However, we have to also keep in mind that some
of the drafts (in particular, draft-dachille and draft-decnodder)
are solving somewhat different problems, so it may be infeasible to
find a single extension to serve both cases.

That is, the single extension may end-up being more complicated than
two different extensions (which might be simple and easily decomposable
based on the specific application each addresses).

I don't think having different extensions/enhancements is by
itself a bad thing,
as long as we are not trying to achieve the exact same thing by two
or more means.

The different extensions may not all be used at the
same time, and may serve distinct functions, so they don't overload the
signalling protocol.

-Vishal

---

From: "Vishal Sharma" <[email-masked]>
Date: Tue, 7 Dec 2004 08:36:39 -0800

Adrian,

Great, thanks for the clarification. I do agree that it
seems a terminology issue. In that case, what we mean is
inter-domain.

I think we picked "inter-region" because somewhere along
the line (around Seoul, I think) some discussions occurred
at the IETF and the ML, where it appeared that one should use "inter-region"
to cover both inter-area and inter-AS.

I guess if "inter-domain" is the preferred terminology, we are
happy to do that, since that is what we have meant all along.

Thanks,
-Vishal

> Sent: Tuesday, December 07, 2004 8:06 AM
> To: [email-masked]
> Cc: [email-masked]
> be largely unused around GMPLS. In
> draft-ietf-ccamp-inter-domain-framework-00.txt we
> have...

---

From: "Vishal Sharma" <[email-masked]>
Date: Tue, 7 Dec 2004 07:53:26 -0800

Adrian,

That draft-dachille directly addresses TE WG requirements
is a point that is the basis of the draft itself! And,
finds mention in the introduction of draft-dachille.

And, it has been raised in the extensive discussions on this
draft after Seoul.

I mentioned that the current minutes reflect this, since it
appeared a bit strange that the minutes mentioned that for
draft decnodder, while not stating that for draft-dachille.

It may leave a reader looking at the minutes (which I assume
is a lot of the people on the list) with the impression that draft-dachille
does not address TEWG requirements. In fact, quite the
contrary!

-Vishal

> Sent: Tuesday, December 07, 2004 3:39 AM

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 08 Dec 2004 15:18:59 +0100

hi adrian:

> You're right. It was published on 26th October, but that means it
> must have been submitted before then.
> 

yes - it was

> Can you summarise the changes you made for the list, please.

these are the following:

1. clarify the node-id based Hellos usage when there is more than one 
link between a pair of node and the GMPLS PSC vs MPLS applicability - 
this has been performed by adding the following paragraph:

"  Even in the case of packet switching capable end-points, when link
    failure detection is performed by some means other than RSVP Hello
    messages (e.g., [BFD]), the use of Node-ID based Hello sessions is
    also optimal for detection of signaling adjacency failures for GMPLS-
    /RSVP-TE when there is more than one link between a pair of nodes. "

2. in an IPv6 network, provide "Node ID" details

"  For IPv6, the Node-ID refers to the Router_IPv6_Address for OSPFv3
    [OSPFv3-TE] and the IPv6 TE Router_ID for IS-IS [IS-ISv6-TE]. This
    section formalizes a procedure for establishing Node-ID based Hello
    sessions."

3. justify the compatibility statement of section 4:

"  The procedure presented in this document is backward compatible with
    both [RFC3209] and [RFC3473].

    Per [RFC 3209], the Hello mechanism is intended for use between
    immediate neighbors and Hello messages are by default sent between
    direct RSVP neighbors. This document does not modify this behavior as
    it uses as "local node_id" the IPv4/IPv6 source address of the
    sending node and as "remote node_id" the IPv4/IPv6 destination
    address of the neighbor node. TTL/Hop Limit setting and processing
    are also left unchanged.

    Moreover, this document does not modify the use of Hello Processing
    for State Recovery as defined in Section 9.3 of [RFC 3473] (including
    definition and processing of the RESTART_CAP object). "

4. justify *why* no new security issues are introduced (as part of the 
section 5)

"  As this document does not modify or extend the RSVP Hello messages
    exchange between immediate RSVP neighbors, it does not introduce new
    security considerations.

    The security considerations pertaining to the original [RFC3209]
    remain relevant. RSVP message security is described in [RFC2747] and
    provides Hello message integrity and authentication of the Node-ID
    ownership."

5. a bunch of editorial issues

- IPR boilerplate
- remove the "Routing Area ID Summary"
- remove Table of Contents
- spurious double space
- spurious question mark
- consistency between "Hello" vs "hello" and "node-id" vs "node id"
- formatting of the references

thanks,
- dimitri.

> Thanks, Adrian ----- Original Message ----- From: "dimitri
> papadimitriou" <[email-masked]> To: "Adrian Farrel"
> <[email-masked]> Cc: <[email-masked]> Sent: Saturday,
> December 04, 2004 9:20 PM Subject: Re: Draft minutes from Tove
> 
> 
> 
>> hi adrian,
>> 
>> a small comment:
>> 
>> 
>> i mentioned that the update of the Node_Id based Hello document has
>> been effectively submitted before the deadline
>> 
>> thanks, - dimitri.
>> 
>> Adrian Farrel wrote:
>> 
>> 
>>> 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
>>> 
>>> -- 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 
>>> 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) 
>>> -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) 
>>> 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)
>>>  
>>> 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) 
>>> 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 
>>> 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 
>>> 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 
>>> 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.
>>> 
>>> 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) 
>>>  -- 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) 
>>> 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) 
>>> 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.
>>> 
>>> 
>>> .
>>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> .
>