[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.