Re: Draft minutes from San Diego

["Adrian Farrel" <[e-mail]>]

I didn't hear any comments.
Tove, did you get any private comments?

Otherwise I'll submit the minutes at close of business today.

Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Tove Madsen" <[e-mail]>
Sent: Thursday, August 12, 2004 6:31 PM
Subject: Craft minutes from San Diego


> From Tove.
>
> Please send comments on list or direct to her.
>
> Thanks,
> Adrian
>
> Hi ccamp,
>
> Here are the minutes from our meeting in SD. Please review, feedback and
> changes are appreciated until next Thursday, thanks!
>
>  Special thanks to typers Deborah B, Susan H and Giles H!
>
> /  Tove Madsen
>
> --------------070301030408020006090705
> Content-Type: text/plain;
>  name="ccamp minutes rev02.txt"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="ccamp minutes rev02.txt"
>
> CCAMP
> -----
>
> Agenda bashing - Adrian
> -----------------------
>
> no new RFCs since Seoul.  Waiting for Aug 9th to push a bunch of stuff through.  G.709
> with Alex (AD).  Will publish 15 RFCs once done.
>
> Bunch of drafts not being covered today:
>
> JP's router capability stuff.  Need some discussion on list.
>
> JP's loose path reoptimisation.  Is this something we want?  interdomain but with
> intradomain usage. <10 hands showing have read it.  Will go to list to check we're happy
> before taking into WG.
>
> Alarm info.  Said on list a while ago that considered it done and considering WG last
> call.  anyone objecting to last call?  No.
>
> Crankback and route exclusing waiting for multi-domain.  Both have implementations.
>
> Tom and Adrian will sit down this week to work on MIBs.  Lack of interest so far. Anyone
> MIB-interested willing to help?
>
> Tunnel trace - no interest shown at all.
>
> Link bundling - perhaps needs a clarification draft to show what was intended.
>
> MPLS/GMPLS migration/interworking is something we ought to care about (will be networks
> that need to talk and perhaps gradual migration).  Needs review and comment from WG.
>
> Useful new draft on misconnection analysis.  Authors planning new rev so now's a good
time
> to comment on-list.
>
> Survey for mesh restoration.  Fair bit of input, would be useful to get feedback from
SPs
> who'd be answering the survey and from implementors (who'll want to know what to
> implement).  Feedback on list or to authors would be good.
>
> Q (Vishal). Diverse path routing draft?
>
> A (Kireeti).  Have a set of slides on inter-area strategy.
>
> Milestones - Kireeti
> --------------------
>
> Going well but got the year wrong!
>
> There will be one more revision of protection/restoration.
>
> Minor edtis needed on ASON.
>
> Will talk later on strategy for inter-whatever.
>
> GTTP is stuck.  People who were driving have driven away.  Need to poll authors and WG
to
> see if there's any interest.  if not will take off the charter.
>
> Minor edits for ASON routing reqs.
>
> Need to talk about charter.  Adrian went over much of work that needs to be done.
>
> Promised us again that MIBs will be done.  Can't progress standards work without MIBs.
> Need to close off ASON stuff, multi-region and protection/restoration.  Various misc.
docs
> that are WG docs so we need to decide whether to complete or drop.
>
> Need to realise how much work we have on our plate before we add more work.
>
> Clarification required on label allocation for different switching types.  Also on how
to
> take the switching/encoding type into consideration when doing CSPF.  Might need to
modify
> old docs, do new ones, or do "clarifications" doc.
>
> New work items
> --------------
>
> MPLS/GMPLS interworking/migration.  e.g. two ways to signal a PSC label (MPLS or GMPLS).
> Need to work it out and have migration path.  Putting on charter will help.
>
> Inter-domain signalling/routing. Already working on it.  Nice to have a work item
> explicitly saying it.
>
> Big one is L1VPN.  SG13 have said they're working on it.  Want the same relationship
with
> SG13 as we're trying to forge with SG15.  They do reqs, we do protocol work.  But who is
> "we" - just someone in IETF.  One option is a new WG.  Other option is to do in CCAMP.
If
> we do in CCAMP it will take the following (note two issues - is this a good summary of
> work to be done, is this what we want to do in which case take to ADs who hopefully will
> say no):
>
> Once we get framework/applicability done then:
>
> Do protocol work.  Will have to liase within IETF (e.g. with L3VPN WG as have VPN
> discovery and CE-PE ID exchange docs).  Also with ITU-T.  Of course if we have routing
> extensions then OSPF/ISIS will get involved.
>
> If we go down this path then we need a design team.
>
> So plan is :
>
> 1) take to list to see if have consensus in CCAMP for charter extension.
>
> seemed enough hands to take to list.
>
>
> ASON
> ----
>
> Have 3 drafts.  2 gone through AD review.  Last one on Alex's "to read" list.  Just
before
> this meeting couple of people pointed out that there's a disconnect with key ITU spec.
So
> DT needs to sit with these people and figure out what disconnect is and how significant
it
> is.  Will attempt to start discussion this week (face to face).
>
>
> Dimitri - RSVP-TE for ASON
> --------------------------
>
> refreshed since last IETF.
>
> 2 discussion points:
>
> Is the definition of link capability usable in wider scope?
>
> Can we define the notify message usage in detail?
>
> Doc has been shown to be stable.  Needs editorial review ASAP.
>
> Aim was to be ready for last call post San Diego.
>
>
> Dimitri - ASON Routing DT
> -------------------------
>
> Aim is to evaluate routing protocols against ASON routing requirements.
>
> Need to elaborate the applicability scenarios.  DT looking at two scenarios. If anyone
has
> a good scenario that needs to be addressed they can pass it to the DT.
>
> Result of evaluation will be integral part of draft.
>
> First cut at Adrian's website.
>
> ToC of reqs.
>
> Needs scenarios and needs user community to feed scenarios in.
>
> First CCAMP WG doc needed by end of this month so will have to push hard.
>
> Will be liased with SG15/OIF to get inputs before doing protocol work.  Need to focus on
> the evaluation work.
>
> Q (Zafar).  One comment regarding template.  Would recommend not having reqs section as
> already have a requirements doc.   If repeated it can become confusing.
>
> Dimitri - want at least to have pointers to the requirements. That way people have in
mind
> the scope of the architecture.  Structure of doc may change.
>
>
> Don Fedyk - Transport review of LMP.
> -----------------------------------
>
> Aim is to facilitate ITU/IETF communication.  Issue with discovery is involves databases
> used to control optical networks.
>
> LMP discovery is there to find a TE link.
>
> Documents ITU discovery terminology.
>
> Idea here is to document "secret decoder ring".
>
> changes:
>
> 1) Clarified G.7714
>
> 2) TE link definition.
>
> 3) General clarification.
>
> Think is useful for IETF people to understand where ITU-T discovery procedures are and
> vice-versa.  Hence requesting is WG doc.
>
> Q (Vishal) - any attempt to work on discovery procedures or does this just clarify
> definitions?
>
> A (Don) - just informational.  Stories on either side aren't complete yet.  So will live
> until those are solidified. Not aiming to define here.
>
> Q. (Vishal) - Think it is a good doc.  Is there any work to unify the procedures or do
> procedures here to mirror ITU work?
>
> A. (Kireeti) - first thing is identifying the secret decoder ring.  Show diffs between
ITU
> and IETF.  Second is to start series of liasons to SG15 (or whatever) to figure out if
we
> fix it, they fix it, or work together. So get better picture of how to proceed. But
right
> now need to understand each other.
>
> Adrain - have heard comment about it being good and useful from many people recently.
> fits in charter.  would like to see it as a WG doc.  show of hands!
>
> handful of hands. (Adrian thinks reasonable).  Nobody saying should not be WG doc.  Take
> to list.
>
>
> Wesam Alanqar - ITU-T SG 15
> ---------------------------
>
> Various links to liason info.
>
> Picture of optical control plane (ITU-T SG-15 Q14/Q15)
>
> ITU-T wants to thank CCAMP - especially ASON reqs DT for capturing reqs for link-state
> routing.  Q14 wants to extend this.  Analysing OSPF/IS-IS/PNNI for use in ASON.
> Encouraging work with different standards bodies to look at implications for routing
> protocols.  Have template for this.
>
> Q14 thinks a cross-body DT may be useful to look at use of IETF routing protocols.
> Similar to the ASON routing reqs. DT.  Various things to look at.
>
> Recent docs finished in ITU-T:
>
> G.7715.1 on Link state reqs for ASON
> G.7713 call connection mgmt.
>
> Meeting Nov 1-5 in Berlin.  IETF welcome to come.  Contact Kam Lan for more info by
24/9.
> Contributions by 25/10.
>
> Q. (Zafar).  Last IETF had discussions on OIF also.
> Do chairs want to comment?
>
> Kireeti - what do you want to talk about?
>
> Q. (Zafar) What's the feel of liason with OIF?  Is it progressing?
>
> Kireeti - No formal liason relationship with OIF.  Been communicating.  OIF has asked
for
> formal liason.  Figuring out what needs to be done on each side.  Most interesting is to
> synchronise routing work.  ITU relationship is good - ITU does reqs, IETF does protocol
> work and liase back.  Would like to do same with OIF either formally or not.  Form of
> relationship still to be figured out - but again want OIF to give us reqs, we do
protocol,
> they say if is good.  avoids redoing work.
>
> Q. (Monique) - OIF meeting last week.  Trend towards OIF/ITU alignment as well as
> OIF/IETF.  will be contribuition to that effect.
>
> Adrian - we'll try to nail down the lacuna in comprehension for requirements after
> meeting.
>
>
> Protection drafts - Adrian
> --------------------------
>
> 3 drafts.  Been through WG last call and marked up.  With chairs (Kireeti) to check
> markups are fine before pushing forward.
>
>
> Dimitri - RSVP-TE extns for e2e GMPLS-based recovery
> ----------------------------------------------------
>
> v01 submitted in may.
>
> have addressed issues raised on list:
>
> 1) mis-ordering during secondary LSP full instantiation (8.3)
> 2) preempt resource of lower pri LSPs when protecting LSP activated (10).
>
> Updates since v00 addressing concerns/expectation.
>
> Need to check sec 13 (external commands).
>
> Check Implementations status out there, external commands still open.
>
> Once that issue closed then we can go to last call.
>
> Also had editorial review already.
>
> Adrian - so not quite ready for last call?
>
> Dimitri - we should see whether impl. of section 13 is also there then respin with or
> without that section.
>
> Q (Zafar) - Later on will work on inter-as recovery.  would be good if this doc
addresses
> intra-region.  is that (or will it be) stated in the doc?
>
> Kireeti - base spec doesn't say so won't start now keep separate.
>
> Q (Zafar) - Issue on reoptimisation of bidirectional LSP.
>
> Adrian - not sure this draft is relevant to that.  Worth having discussion, but distinct
> from this.
>
>
> Lou Berger - Extensions to GMPLS RSVP graceful restart
> ------------------------------------------------------
>
> Arun's draft.  Lou's reordered a couple of slides.
>
> Merged draft (following consensus from Seoul). (draft-aruns and draft-rahman).
>
> Major change is addition of support for improved scalability.  In Aruns original draft
> every piece of state had to be sent.  Now can use summary refresh to decide which pieces
> to resignal.  Way this is done is that node adj. to restarting node can send back path
> message from restarting node so restarting node can recover the state it originally
> advertised.  Big step forward from (RFC)3473.  In 3473 no way for ingress to recover
> state.  As compared to prev. version only sends state that is needed. Use summary
refresh
> for this.  Have added recovery path summary refresh so restarting node can just look at
> stuff it hasn't kept across restart.  If adj nodes support this extn (can discover that)
> then can use these procedures.
>
> To do:
>
> 1) Need to agree message type
>
> 2) discussion amongst authors about adj node startarts.  If two adj nodes restart then
how
> does 2nd one know the 1st is in restart condition.  Impacts sending of path msg and
> recovery labels.  This is a broader problem than just this draft.  Applies to 3473
> independent of these extns.  So issue is both what to do and where to do it.
>
> Next steps:
>
> Authors think ready for WG doc.  Chairs?
>
> Kireeti - how many people have read this.  Scattering.
>
> How many thinks it should be WG doc - most of them
>
> How many opposed - zero.
>
> some support - take to list.
>
> Kireeti - one comment on adj node restart.  Most other protocols don't care about this.
> Idea is that if lots of nodes restart at once then your network is screwed anyhow.  With
> OSPF nodes abandon restart if that occurs.  BGP, OSPF, IS-IS and prob LDP do this.
>
> Lou - not all that difficult to do. One prob is where put recovery stuff in path msg.
> Other issue is timer adjustments if you see your neighbour restarting.  Could argue is
in
> 3473 already - may just need clarification. But good comment.
>
> Adrian - chairs in violent disagreement over Kireeti's last comment.  Highlight is that
> restart is complex as well as important.  There are people out there who do a lot with
it.
>
>
> Zafar Ali - Node ID based RSVP Hello
> ------------------------------------
>
> Incorporated feedback from mailing list and Seoul discussions.
>
> Remaining work is minimal.
>
> Draft is short/straightforward.
>
> >=5 implementations.
>
> Some inter-op testing done.
>
> want to do WG last call.
>
> Adrian - who's has not read the draft who is responsible for MPLS/GMPLS impl.  Lou.
>
> Adrian - have met all criteria to go forward.  Authors happy, draft stable, comments
dried
> up.  So will debate last call on list.
>
>
> Kireeti - Multi zone
> --------------------
>
> 2 drafts for this.  Issue is what is a zone - IGP area, AS, tech domain, protect domain.
>
> Also want to have one way to do this - esp as both drafts were RSVP-TE based.
>
> Single common doc now.  Many iterations/rewrites.  Now one mechanism with diff options.
>
> have functional docs:
>
> 1) Framework (not on slide)
> 2) signalling
> 3) path computation
> 4) (not a doc) BOF on PCE to look at other ways of doing this (run by Adrian and JP).
>
> Need more docs:
>
> 1) Applicability - what options to use for a given req.
> 2) Stitching.  Similar but different to nested LSP.  Does it become a separate doc.
> Certainly need doc on it.
>
> Debate on protection/restoration and diverse routing inter-domain.  Aim is to get base
> spec out.  Once stable work on diverse path setup across domains.
>
> Vishal - have had discussion on list.  Basic req in reqs doc is diverse path routing.
> Could do solution for single path routing that might not work at all for diverse paths.
> Suggestion is to break up items and push diverse path routing etc. into "advanced
> applications". Needs to be taken into consideration for signalling/routing.  Need to
look
> at problem together and not separate.
>
> Kireeti - what we've done (successful so far).  Did base spec for signalling and had
> separate DT to do protection/restoration.  Base spec for routing, and added on stuff
> afterwards.  If you can give us a concrete example of where this won't work then we'll
> look at it.
>
> Vishal - not just me.  SPs want to link it together.
>
> Kireeti - fine.  That's one opinion.
>
> Vishal - not resolved yet.
>
> JP - this has been taken into consideration.  scenarios 1 and 2 for path computation
> consider this, so already part of base spec.  Not true to say it has been excluded.
>
> Vishal - but not being discussed.  Draft says it is advanced application.  This
shouldn't
> be.
>
> JP - not being excluded.
>
> Kireeti - not taking off the agenda.  Will do it but want to get base spec out.  Want to
> leave room in spec for other applications (not just diverse path routing). But doesn't
> mean we have to spec that out now.  If JP's done the work to ensure it's possible then
> Kireeti's happy.
>
> Vishal - I raised Qs on list which weren't answered.  Especially regarding scalability.
Is
> not even clear how single path works.
>
> Arthi - what do you mean by "let's get base spec out"?  Currently docs aren't even WG
> docs.  I think Vishal is saying at least we need to move forward to some extent with
base
> docs.  They're just individual contributions right now.
>
> Kireeti - that's what I'm saying.  Not vishal
>
> Adrian - nobody's saying we'll take unprotected to RFC before we even look at protected
> stuff.  We're rather saying we want to understand unprotected before we understand
> protected since latter is built on former.
>
> Vishal - issue is diverse paths.  Doesn't work if you build on single path approaches.
> Diverse paths is a key issue - so consider at the beginning, don't retrofit.
>
> JP - that was the case.
>
> Zafar - to answer Vishal there are enough cases to show that base stuff works and is
> extendible for future.  Crankback is an example.  Lots of stuff needs to be done later,
> and need stake in ground for base work with enough hooks.  Nothing is excluded today.
>
> Dimitri - can we make it clear that as docs are extended they take G of GMPLS into
> account.
>
> Lou - question re stitching?
>
> Kireeti - details have to be done.  That's not a question.  Question is is this new
draft
> or existing drafts.
>
> Vishal - are we going to poll the WG?
>
> Kireeti - can I finish my slides first?
>
> Kireeti again:
>
> how to progress:
>
> Have an idea of what docs we need.
>
> Reqs came from TEWG.
>
> In light of proposed solutions should revisit the TEWG reqs. and check reqs are
> reasonable.
>
> Sep docs for sep. functions (signalling/path computation/poss. rechability).
>
> Progres each doc separately - but may send for RFC as a block.
>
> Once have base spec done will look at re-optimisation and diverse paths.  Want to do
base
> spec first.  If in our evaluation that isn't a major retrofit then will progress base
spec
> while working on rest in parallel.  If turns out is a major retrofit then will halt
> progress and retrofit first.
>
> Vishal - my point still stands.
>
> Kireeti - we've heard it several times.
>
> Vishal - so what are you going to do?
>
> Kireeti - nothing.
>
> Vishal - but WG hasn't been polled.
>
> Adrian - WG chairs exist to judge consensus.  We believe we have judged it and the right
> way to do this technically.  You're welcome to disagree and build an opinion against it.
>
> Vishal - want to get work done not build opinions.
>
> Adrian - so do we.
>
> Vishal - so what will we do about diverse paths?
>
> Adrian - keep draft alive as a private draft.  Then have basis when WG ready to take on.
> That's good.
>
> Kireeti - you might be missing that the difference in what you're saying and what we're
> saying is just sequencing.  We want to do a then b. you want to do in parallel.  If we
> find that base doc needs major retrofit then we'll halt it.
> We need to have a tech reason for doing this, and don't have a base doc yet.
>
> Vishal - so can keep individual docs going?
>
> Kireeti - yes, renew it every 5 months and 29 days.
>
>
> Adrian (with chair hat removed)
> -------------------------------
>
> Had couple of proposals for inter-region/inter-AS TE a while back.
>
> Ended up with a useful, but long, draft.
>
> Have split into diff parts.  JP and Arthi will talk about soln. specific texts.
>
> This draft is just framework to point to what you could do.
>
> Key is defn of a domain:
>
> seems necessary to extend this beyond just IGP areas and ASes to protection domains and
> zones of limited TE visibility.  So domain is a loose concept.
>
> Aim is not to recommend solution but to break problem down to show different ways of
> signalling, path computation and routing.
>
> Describes some "easy" advanced features and applicable to MPLS/GMPLS.
>
> Not attempting to look at harder issues (e.g. diversity, OAM, P2MP).
>
> Not making judgements as to why you'd pick one method rather than another (or
documenting
> those methods/solns).
>
> TEWG produced two reqs docs. had quite a bashing and rework.  Question is whether we're
> happy to freeze the docs as RFCs or keep alive as do solution work in case we find
> ambiguities/contradictions and need to fix them.  Adrian prefers to say they're done but
> keep them alive in case need to fix.
>
> Issue on GMPLS reqs (TEWG reqs were MPLS only).
>
> Issue of bringing complex functions in.  Option might be to start work on partner draft
> for framework for more complex functions.
>
> Authors are asking if we need a WG framework, if this is the right WG framework and if
> this is the time to make it WG doc.
>
> Dimitri - if we combine TEWG reqs with GMPLS reqs does that mean we have separate reqs.
> Or do we just extend TEWG reqs. for GMPLS.  Or do we merge MPLS/GMPLS drafts?
>
> Adrian (speaking as an author) - think we need to understand if GMPLS reqs are
different.
> If they're not in existing reqs drafts and are not contradictory then don't care much
> where we do them (but 3rd draft might be good for GMPLS extns to requirements - allowing
> people to do MPLS alone).  PSC will probably be done with pointer to MPLS.
>
> Richard Rabbat - interdomain OAM you're saying have reqs for LSP ping or poss. GTTP.
> Would GTTP solve problems?  Want to see if we can increase importance of GTTP in WG.
>
> Adrian - people have commented that one issue with MPLS was that OAM was left until
later
> as a req.  We need to start to look at multi-area OAM reqs.  May take us down GTTP path.
> Not clear that because we have req that anyone will want to work on GTTP.
>
> Richard Rabbat - agree but may need to keep alive.
>
> John Sadler - thanks for draft, helps identify gap on ASON.  Additional req for ASON is
> identified.  Not sure where to capture as has ramifications to signalling.
>
> Adrian - expect over time to have overlap in ASON DT and this work.
>
> Q.(?) - discussion on converging inter-area and intra-area.  WG has decided not to.  I
> support sep draft for GMPLS.  Makes docs much more scalable/readable.  2nd q - you said
> that the diversity/reoptimisation isn't part of base spec.  But should include as is
> already being talked about in converged signalling draft.
>
> Lou - for each MPLS solutionn doc (JP's)?
>
> Arthi - read more carefully.  Not all reqs are solved.  But want a single solution doc
for
> MPLS and GMPLS.
>
> Anon - liason to ITU would be good.
>
> Kireeti - how many have read?  Good number. How many like it? good number.  Only vishal
> thinks is not ready?
>
> step 1 is take to mailing list but note consensus in room.
>
> will do for other docs once presented.
>
>
> Arthi inter-domain MPLS TE RSVP-TE extns
> ----------------------------------------
>
> As requested by WG at IETF59 split doc into 3.  This is one of the solution docs
> (signalling).  JP's draft does path computation.   Will have applicability doc ready for
> IETF61.
>
> Idea was to only look at signalling aspects for interdomain TE LSP setup.  Looks at
> contiguous, nested and stitched LSPs.
>
> Domain def. is aligned with framework (i.e. very flexible).
>
> Intention was GMPLS/MPLS applicability (packet and non-packet).  May be some gaps.
>
> Cover other aspects - ERO processing, FRR, re-optimisaton (just talks about signalling
> issues wrt re-optimisation).
>
> 3 signalling methods (contig, nested, stitched).  Needs two bits to ask for contiguous
LSP
> or stitched LSP.  Latter is set by head end LSR of segment (not e2e LSP).  Has a
> corresponding bit in RRO attributes.
>
> stitching:
>
> enables packet LSP to get right label exchange between egress and penultimate nodes.
>
> don't want to have label exchange over LSP segment hop.
>
> allows ingress to be notified that egress has done the right thing.
>
> similarity to hierarchy - uses non-adj signalling and all signalling extns.  Can use
> segment as FA-LSP (but is a special case as can only carry one LSP).
>
> differences are one-to-one nature.  Lack of label exchange over segment.  no b/w
> reservation on segment.  Either have b/w or you don't - so is exact match.
>
> Need to clarify similarity/diffs in doc.
>
> 1st question is how head end can control downstream choice of signalling method.  Some
> discussion on mailing list (incl CCAMP).  Discussed in context of inter-area reqs.  No
> conclusion on thread - are we OK with that?  If not OK then what do we do?
>
> 2nd question is GMPLS.  Need to clarify this better.  Do we need any more signalling for
> it?
>
> 3rd question is whether we need a stitching draft.  Doc talks about stitching but might
> need clearer applicability.  should that be in this doc or in a sep draft.
>
> Next steps:
>
> No major changes expected as basic issues finalised so would appreciate more feedback.
>
> Since ready (bar a few clarifications) want to know if chairs/WG think is ready for WG
> doc.
>
> Vishal - good to have some clarification of stitching in this doc.  Later we can see if
> need a diff doc.  Same for GMPLS - put more stuff in for now.
>
> Adrian - thanks Vishal, you've just made the same 2 comments the chairs wanted to make.
>
> Alia -  need more detail on stitching.  perhaps in a sep section.  For instance nowhere
> does it say how you correlate intra-domain LSP to inter-domain LSP.
>
> Adrian - will ask authors to tidy up GMPLS, break stitching out into sep section. Bring
> back for consideration as a WG doc.
>
>
> JP - path computation methods
> -----------------------------
>
> Proposes two methods for packet/non-packet LSPs.
>
> Aim is to fulfil both inter-area and inter-AS reqs from TEWG.
>
> overview of two scenarios:
>
> 1) per-domain path computation - do path on per-area basis.  Head end to first ABR, 1st
> ABR to next, last ABR to egress.  Could be areas, could be ASes.  Can discover next-hop
> dynamically, using heuristics, policy etc.  Or can specify loose hops at head end or
> abstract strict hops (list of ASes etc.)
>
> 2) End to end shortest path computation using PCE.  Head-end sends request to PCE.
> Recursively construct shortest path where tree is rooted at tail end.  Welcome to come
to
> PCE BOF.  Draft talks about how to signal from head end to PCE.
>
> Note that both scenarios can work together.  So can have policy to control set of ASes
but
> use PCE intra-AS (for example).
>
> Want to restate that we don't require flooring across domains.  No impact on
scalability.
>
> Have proposed optimisation to flood inter-AS TE info.  Reduces probability of call setup
> failure (increases as load increases and as you have more ASBRs) so can reduce call
setup
> time.  ALso reduces number of ERO expansions and gives more optimal path selection.
Note
> no IGP impact.
>
> Need to elaborate more on applicability - will do this in separate draft.
>
> Again want to point out that inter-AS and inter-area are very similar (only difference
is
> inter-ASBR link in the first case).
>
> Nothing too specific on FRR except for inter-ASBR link and ABR/ASBR failures.
>
> separate draft for re-optimisation of contiguous TE LSPs based on scenario 1.  Proposing
> soln for scenario 2.
>
> For stitched/nested this is a local reoptimisation intra-domain.
>
> Will discuss more tomorrow about how to signal from head end to PCE.  3 ideas already on
> IGP-TE capability (in CCAMP, ISIS, OSPF).
>
> SPs will come up with ID for next IETF on BCP for security/confidentiality.
>
> next steps:
>
> New ID on applicability.
>
> Progress signalling and path computation IDs (and make WG docs).
>
> Q (Vishal). Not so sure that need to standardise optimisation algorithm.  Specifically
as
> long as can exchange parms between ASBRs that should be enough.  Need to discuss more on
> Thursday.
>
> JP - will discuss more on Thursday. What we want to agree is method for sending
requests.
> On PCE itself can use CSPF and various optimisation criteria.  No need to standardise.
>
> G (Vishal) - does inter-area optimisation apply to 1 and 2?
>
> JP - if you don't flood TE info between ASBRs then only have visibility to boundary
node.
> So applies to both.
>
> Dimitri - there is a PCE BOF.  What is impact on PCE BOF on CCAMP?  If doesn't get
> progressed as BOF then should we still progress.  Can we progress this independently of
> PCE BOF outcome?
>
> Adrian - yes.
>
> Q (ECI Telecom) - regarding applicability statement, will there be recommendation on
impl.
> issues (e.g centralised/distributed PCE).  Or will this stay open?  Often standards say
> which of options is most endorsed.
>
> JP - like RR for BGP can be put on a router that also does forwarding, or not.  so we're
> just describing fn of PCE - depends on your network design as to where you put it.
>
> Kireeti - so are you asking if applicability spec will recommend centralised or
> distributed.  Ideally in applicability spec will just say "here are options, and here
are
> scenarios that work for each of them".  Won't have global recommendation.
>
> Richard - your ASCII figures are hard to follow.  Can you please clean them up or do
PDF?
>
> JP - we'll fix it.
>
> Adrian - need to suspend decision on moving this forward until after PCE BoF.
>
>
> Tomohiro Otani - TE parms to be exchanged
> -----------------------------------------
>
> Summary:
>
> fits charter item on signalling/routing mechanisms for paths spanning multiple
> areas/ASes/providers.
>
> clarifies need for dynamic/static info exchange and reqs. for TE parms.
>
> SP proposal.  KDDI and NTT already interconnect at L1, L2, L3.  Need to set up paths
while
> hiding internal topology.
>
> Assumption is 2 GMPLS ASes.  AS1 knows its topology and AS2's border
routers/reachability.
>
> Once create LSP from ingress to egress.  If AS 1 only knows AS 2 reachability then how
> does it get shortest path in AS 2.  AS 2 may send back path err if constraint can't be
> met.  So may need non-shortest path in AS1 to then get to border router which meets
> constraint in AS2.
>
> Of course have whole bunch of constraints (switching capability, encoding type,
bandwidth,
> SRLG etc.)
>
> GMPLS border nodes announce end-pt reachability with the constraints met to those
> end-points.
>
> To get resilient LSPs may need globally significant SRLGs.
>
> Next steps:
>
> 1) Add GMPLS EGP reqs.  (so need BGP experts).  And will look at extra load here
> (suggested by Adrian).  May need light mechanism for dynamic exchange of info between
> ASBRs.
>
> 2) Go for WG doc (need to do 1 first).
>
> 3) Will look at any BGP extentions
>
> 4) Will look at how to get SRLGs that are globally consistent (bit assignments).
>
> Adrian - is this really limited to GMPLS?  Or can it apply to MPLS TE?
>
> Tomohiro - limited to GMPLS, but could expand to MPLS.
>
> Adrian - bit of a contradition between reqs. here and in TEWG docs.  In as much as
> discussion here on distribution of TE info inter-domain we are going to have to resolve
> the contradiction.  Adrain thinks is good.  JP doesn't.
>
> Zafar - next steps slide.  would like to tie this to GMPLS reqs before doing solution.
>
> Tomohiro - yes would like to do GMPLS reqs first.
>
> Arthi - I think we need to start discussion about whether BGP would req this for MPLS as
> well as GMPLS.
>
> JP - It's not that I think this isn't good.  Am just trying to reflect what the TE reqs
> draft says.  Aim is not to leak summarised TE info inter-domain.
>
> JP - the draft seems to flood quite a lot of unsummarised info.  Big req of SPs is to
> preserve confidentiality.  How do we sort that out?
>
> Tomohiro - we don't want to flood all info to other ASes.  So we need summarisation in
> each AS.
>
> JP - do you think can both summarise to preserve confidentiality and have enough info to
> be useful?
>
> Kireeti - as I understand it this isn't summarisation.  It's more passing switching caps
> so don't attempt what isn't possible.  Is quite useful for L1VPN. Could be used from CE
to
> CE in L1VPN.  Answers first q on leaking constraints.  RTs etc. can be used in VPN.  So
> can be used inter-AS and in L1VPN.
>
> Susan Hares - thought I heard mention of ORFs.
>
> Kireeti - no, just RTs - for L1VPN.
>
> Susan - so we haven't settled on RTs, ORFs etc.?
>
> Arthi - can we say that this is basically an optimisation to per-domain path computation
> to reduce crankback?
>
> Kireeti - yes.
>
> JP - that's exactly back to my question.  To reduce crankback you have to summarise info
> from other AS, but then you break confidentiality and scalability.
>
> Adrian - so potential tradeoffs and we need to work on them.
>
> Anon - there could be networks that want to transfer all the data across ASes (e.g.
> research networks - where 2 ASes don't mind sharing info and security is achieved in
diff
> fashion).  Providing network summary isn't sufficient.  Need to provide more info to get
> optimal path across ASes.
>
> Adrian - come to PCE BoF and we'll debate this.
>
> Vishal - are we going to work on reqs. for GMPLS TE? Is anyone doing it?
>
> Kireeti - yes, but nobody is doing it yet.
>
>
> Dimitri - GMPLS for L2LSPs
> --------------------------
>
> Changes since last version:
>
> Explain motivation for L2SC LSPs (RFC3473)
>
> Generalised to any L2 (ATM/FR/ETh etc.)
>
> New L2 TSPEC FLOWSPEC etc.
>
> L2 label spaces and encoding all details are in the doc.
>
> General feeling that's worth spending cycles on this.
>
> Think it's a good basis for the work.
>
> How is consensus wrt WG doc?
>
> Kireeti - GMPLS charter covers this implicitly, but want to make it explicit and then
take
> this to WG doc.
>
>
> L1VPNs
> ------
>
> Progressing "under care of CCAMP".  Submitted applicability.  Idea is to show how we use
> GMPLS and deltas from "normal" GMPLS.
>
> Few issues in framework.
>
> In summary existing drafts cover most of applicability.  Identified 7 items that may
need
> more work.
>
> Next steps - covered some of this at start of meeting.  But need to discuss on L1VPN
list
> and CCAMP list. Want to make L1VPN part of CCAMP.  100 subs on L1VPN list and expecting
> protocol work to be minor.  Good links to ITU-T etc.  Want feedback.
>
> Hamid - good work has been done on L1VPN for applic/framework/auto-discovery/use of
GMPLS.
>
> Anon - want to observe that am looking forward to huge market for lambda services and
more
> and seems like a good idea to do in a different WG.  Can we do that without huge admin
> overhead.   More issues will come up once this gets publicised.
>
>
> Lou - segment recovery
> ----------------------
>
> biggest change from last meeting is that draft became WG.  Also bunch of minor fixes
(some
> coming from list discussions).
>
> 2 comments not integrated:
>
> 1) more words needed on RESV processing of notify request object.  Good text for path so
> need equivalent for RESV.
>
> 2) internal discussion on FRR interaction.  Need more words there.
>
> One other comment - know of 2 implementations; various stages of maturity.  Would love
to
> hear of others.
>
> Zafar - 2 things I'd like to see:
> 1) info on local recovery
> 2) applicability for FRR.  Pros vs technique described here.
>
> Lou - if you can enumerate reqs and contribute text that'd be great.  As for applic
> statements they are in sep docs, so perhaps we need companion draft.
>
> Richard - adrian sent email re misconnections being living list against which protection
> mechanisms are tested.  Have you checked against that?
>
> Lou - no.  Might be dimitri and others have.
>
> Dimitri - is ongoing.  In next release will have conclusion.
>
>
> Zafar - graceful shutdown in MPLS-TE networks
> ---------------------------------------------
>
> reqs - this is problem that NSPs try to solve today using ad-hoc mechanisms.  Problem is
> resources in nodes/TE links.  Want to upgrade node.  So how do we divert traffic to
other
> places in network so that we can do the maintenance.  Currently SPs play with IGP
metrics
> etc.  Problem is that can be inconsistent.  Also not applicable to inter-area or
inter-AS.
> This ID puts togeher framework for existing mechanisms to do graceful shutdown of TE
link
> or node.
>
> Draft is straightforward. Talks about IGP and RSVP-TE mechanisms.  Issue is IGP isn't
> applicable to inter-area or inter-AS.  RSVP-TE only sends info to nodes along path.
>
> changes are minor and rely on existing framework.
>
> RSVP-TE mechanism
>
> IGP based mechanism.
>
> Have had feedback and will publish next rev by end of aug.
>
> can we be WG doc?
>
> Arthi - not entirely fair that this is based on existing docs.  Loose hop reoptimisation
> not defined elsewhere.  Might be better to add here than to add elsewhere and then claim
> we are using other mechanisms.  Also there are existing mechanisms which are used today
> for graceful turn-off of links at least in GMPLS networks.
>
> Zafar - all fair comments.    Can take comments re other draft offline.
>
> Adrian - let's discuss offline once have a respin and take it from there.
>
>
>
>