The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

Working Group,

Giles took excellent notes from the MPLS working group meeting
in Chicago, thanks Giles!

There are a few edits and clarifications need, e.g. there are
some names missing and some comments that weren't captured.

If you know you said something at the mike can you review the notes
and send clarifying comments to me. If I have these comments timely
I'll try to send the notes in later this week.

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson@acreo.se
                                           loa@pi.se

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com

MPLS WG minutes - IETF 69, Chicago, July 23rd 2007
----------------------------------------------------------------------------

wG Status (Loa)
----------------------------------------------------------------------------

1) 4 RFCs since last IETF + one on MPLS/GMPLS change process (RFC4929 - as
BCP129).  Will be liased to other orgs.

2) ICMP draft in AUTH48.

3) 3 drafts in rfc-ed Q - Ina to respond to RRFC editor for LDP spec.
(3036bis-04).  Need security section for LDP experience and survey drafts. 

4) 1 draft in IESG review

5) Many WG drafts - 2 on agenda. LDP typed wildcard gone through last call.
Issue of refs to old LDP spec not new.  LDP capabilities - authors want WG
last call.

6) 2 expired drafts (Loa's fault for letting them expire)

7) 1 doc accepted as WG but not yet issued (decraene-mpls-ldp-interarea).


Liason (Loa)
----------------------------------------------------------------------------

incoming liason from ITU-T SG15 on G8110.1.  Will discuss in PWE3, not here.
Please read and take part in discussion (this is T-MPLS/MPLS relationship)

upcoming liason on T-MPLS codepoints.


T-MPLS background (Stewart Bryant)
----------------------------------------------------------------------------

T-MPLS from SG15 Q12.  Series of G8.1xx recommendations.  Liased to IETF
post consent.  Basically Ethernet PWE over MPLS over Ethernet.  OAM is
extended from Y.1711.  Currently statically configured by a central NMS.
Looking at a control plane.  Using a formal language (proprietary to SG15)
to describe how MPLS PWEs work.

ITU-T SG15 say MPLS/T-MPLS are disjoint layers - goal is to use existing kit
to carry T-MPLS using MPLS codepoint.  So no need for new codepoint as no
intention of interop between higher layer MPLS and lower layer T-MPLS.  But
at last ITU-T meet there was a specific contribution on interop.

Liason statements sent expressing our concern.

IETF concerns are that T-MPLS or its extensions may break MPLS or a future
extension of MPLS.  Key issue is shared codepoints with different specs -
may well collide.

experience tells us that scoping rules never stay fixed and limits always
grow.

may have massive interop issues down the road.

plans to implement other sorts of PWE that duplicate IETF work (so not just
Ethernet over MPLS, but many other types too).

will be more discussion in PWE3 this afternoon (most liason to/from there).
So come to PWE3!

Loa - I stepped down as IETF liasion to ITU for MPLS issues, Stewart now
doing it.

Ross - would like to thank Stewart for being willing to take it on.

Ross - meeting on Saturday between senior ITU reps, IAB, IESG plus some
extras (e.g. the IETF to ITU liasons).  Various issues discussed - including
T-MPLS.  Subsequent to the meet IESG met on Sunday morning.  Major chunk of
discussion was on T-MPLS.  This morning the IAB and IESG discussed T-MPLS,
MPLs and GMPLS over an early breakfast.  First time I've seen the IAB and
IESG in complete agreement on anything!  Quite definitely this issue has
helped to foster co-operation inside IETF.  Planning to write a document
explaining our understanding of the ITU requirements, of MPLS, T-MPLS, and
of how they may interoperate or clash.  One part will be our concern about
T-MPLS using the same data plane and control plane codepoints as MPLS and
GMPLS.  Document will come forward as an Internet draft intended to be RFC.
But to get to RFC needs to be discussed in IETF so will take a while to
produce.  in the meantime intent is to send liason to ITU-T expressing our
concern about T-MPLS using the same codepoint.  We know WGs have already
done so, but this will be from the IAB and IESG and their chairs (IESG chair
is IETF chair).  So will request that they use different codepoints. Plan is
to get it out this week.  But do we have time to get IETF to look at text
this week?  Generally takes longer to do that (last call typically takes 2
weeks or longer).  Large chunk of discussion was about mechanics of who can
do the doc this week.  Intent is to send out quickly and to do work on a
more detailed document (in a spirit of co-operation) that will put down our
concerns about having two set of protocol work using the same codepoints,
and likelihood of collision based on future work or config errors.

George - what level of the ITU is this being sent to?

Ross - since is coming from top leadership of IETF think should go to top
leadership of ITU.  Would make sense to send to SG15 and all layers of
leadership above that.

Yaakov - need to send to SG13 as well as SG15 as they're working on it too.

Mark Townsley - needs to go above as had WG to WG liason already.

George - I wrote last liason and got smiles but not much action, so agreed
we need to go to top leve..

Ross - I don't know where/when next ITU-T meet is, but if I can go am happy
to go and to tell them of our level of concern from IAB/IESG.  Would like to
know of IETF has the same level of concern (in general).

Italo Bussi - next ITU-T meeting is 10-14 Sept in Stuttgart. Interim meet.

Yaakov - that's interim meet, not leadership meet, so not right place to go.

Loa - we'll figure that out...


P2MP bypass tunnels for P2MP LSPs (JL)
----------------------------------------------------------------------------

Issues using P2P bypasses to protect P2MP LSPs (inefficient replication).
So need to do P2MP bypass to fix that.  So get scalability of label stacking
whilst avoiding inefficient replication.  So during failure tunnel using 1
or more P2MP bypass tunnel towards set of merge points.  Inner label is
backup LSP label.  outer is bypass label.  To avoid replication the PLR
needs to assign the inner label to all MPs using upstream assignment.

changes:
1) adopted as WG doc in May
2) clarified no PHP behaviour.  Can't do PHP as need context identification
at MP.  Can send the no-PHP using Zafar's draft.
3) Reversion must entirely rely on FRR RFC (1490).  So two modes - global
and local.
4) added section on PLR location.  May be local to failure or somewhere
remote that is 2 or more hops upstream.
5) added section on using a mix of P2P and P2MP bypass LSPs for backwards
compatibility.
6) clarified link protection procedures.
7) clarified bypass tunnel selection options
8) added section on partial protection.
9) general rewording etc. for clarity.

focus on 5-8.

1) P2P/P2MP mix.

P2P use RFC4875 procedures, P2MP use this doc.  No need for upstream label
in P2P case.  So backwards compatible with LSRs that can't support upstream
assign.

2) P2MP selection options.

can have exact match to set of MPs.  Superset (in which case leaves which
are not MPs will drop traffic), or multiple tunnels.

different tradeoffs in terms of control plane/data plane optimisation.  So
choices there and in terms of operational complexity.

3) link protection.

In RFC4875 rely on P2P bypass tunnel.  In some cases it may traverse another
downstream link of the P2MP LSP.  optional procedure uses P2MP bypass for
link protection (originally was designed for node protection).  So may use
P2MP bypass that protects all MPs downsteam of PLR (even if not downstream
of protected link).  So if there's a failure will stop sending on protected
LSP and will just sent on bypass LSP.

4) partial protection.

new feature in this rev - so need WG feedback.  What happens if can't find a
P2MP bypass that covers all MPs.  This may happen - e.g. if there are
bandwidth limitations.  In this case when FRR is activated some leaves won't
receive traffic.  Default procedure would be that LSP is either fully
protected or not protected (by FRR).  But now have option to have partial
protection.  So can signal that if can't get full protection we're willing
to accept partial protection.  Need feedback.

To conclude:

1) need to align this draft with the upstream assignment architecture draft.
PLR should assign upstream labels from a single label space.

2) need WG feedback

3) will submit new rev before Vancouver.


Zafar - why can't you consider P2MP as a special case of P2P.

JL - can't do that in case where one MP isn't upstream capable.  So can't
consider the pair of bypass LSPs as one.

George - one's doing PHP with no context label, and the other is doing
no-PHP and using context.

Zafar - this non-upstream capable attribute?

JL - there's an RSVP-TE attribute and it's described in the upstream label
draft.

Dimitri - what you're doing in the link failure case means you're disrupting
traffic for a branch that shouldn't be affected.  Is it a requirement not to
interrupt branches that should not be affected by such failures

JL - to mitigate your comment will only lose or mis-sequence one or two
packets as you update your FIB.

Dimitri - we need to be aware of tradeoffs we have (and document them).

JL - we'll do that in next rev.


P2MP LDP (Ice)
----------------------------------------------------------------------------

covering chnages in this draft:

1) Root-Node Redundancy.  Similar to MP2MP case.  Multiple LSPs to the
different roots. Only one root can forward packets.  root selection is out
of scope.

2) added capabilities for MP2MP and Make before Break.

3) MP status TLV.  Signals extra info related to MP LSP.  May be in label
mapping or notification. The TLV is opaque to LDP so only LDP MP needs to
look at it.  Used for MBB, but can use for other stuff in the future.

4) upstream label allocation for MP2MP LSPs.  Uses MPLS upstream draft for
context label (for Ethernet interface) and LDP upstream procedures to
advertise the label.

presented diagram of upstream label allocation.  Packets use 2 labels -
context label and LSP label.  downstream routers look at context and then
LSP label in 2nd lookup.  as defined in 2 drafts mentioned already.  No
difference between P2P LSP and P2MP LSP in this case.

Upstream traffic diagram - router will create label state for context and
for LSP.  So don't see difference in packets going upstream, or going
downstream.  So no extra labels needed to forward packets upstream.

so downstream traffic is same as for P2MP LSP.  downstream uses context and
upstream's LSP label to send traffic upstream.

MBB - more detailed in this draft.  noted use of MP notification - used to
signal that the LSP has been established.

Loa - seems we're getting various drafts using the upstream procedures.  Are
there any mutual dependences?

Ice - MP2MP procedures are in the LDP draft.  but should be in one of the
upstream label allocation drafts.

Rahul - The first problem is with the upstream architecture draft. this
little piece on MP2MP LSPs on a LAN needs to be defined as to where it
resides.  But if upstream progresses then next step is the LDP upstream
draft.  Then this draft can use that.  Architecture draft must go first.

Ice - should we add this to LDP P2MP draft?

Rahul - I've got no problem if you want that.  but need to discuss.  Yakov
just reminded me that we need to progress the encapsulation draft.

Loa - you're co-author on both.  What's the status?

Rahul - arch draft needs one rev before last call.

Loa - how far out is architecture draft's next rev.

Rahul - before next IETF.

Loa - this is critical as we're getting drafts stuck which can't progress as
waiting for other drafts.

Rahul - encaps draft is pretty mature.

Rahul - got one Q on LAN slides.  If there are multiple routers on LAN and
they pick different upstreams to get to the root then what happens?
(downstreams will get packets from unexpected upstreams)

Ice - downstreams will only install context for the intended upstreams.  So
even if the "wrong" Upstream sends packets the downstream will drop them.

Rahul - good clarification to add (not that I've read the draft).

Bob - does LDP upstream assignment draft depend on LDP capabilities?

Rahul - have upstream label assignment arch.  MPLS multicast encaps.  Need
to progress at same time.  Then have LDP upstream assignment draft.  Think
can progress only with the LDP capabilities.


MPLS/GMPLS security framework (Luyann)
----------------------------------------------------------------------------

status update.

draft will stay in MPLS WG but be presented at MPLS and CCAMP.  Not yet
extended to other WGs.  Draft been updated before this IETF.  Looking for WG
status this time...

so why doing this now?  Issue is that security ADs and reviewers have been
raising comments on drafts.

so aim is to have one doc to amerliorate need for detailed security section
in individual drafts.  So then other drafts can reference this and build on
it.

various comments on 00 draft.  Some from Rich (Graveman), Sam, Adrian etc.
Important work so encouraged to be WG.  Still need input as to whether scope
is correct.  Aim is not to say e.g. that protocol A is better than protocol
B - but to document the nature of different protocols.

lots of stuff on DoS in doc.  you can't prevent, but can do your best.  So
issues of e.g. line-rate filtering and access restrictions.

encryption statement.  comment is that not so true now, so modified it.  But
may not need encryption but just integrity checks (much less expensive).
Big issue on key management.  Was missing in the 00 draft.  So doc needs to
spend more time on key management - or you can't do integrity checks.

more comments - e.g. on OSPF and ISIS.  We're in the trusted zone here, but
issue of how you prove it, what you're allowed to do if inside/outside, what
you can assume that everyone does inside the zone (e.g. do all members do
same per-interface security?)

also minor structure changes.

good guidelines on DoS attacks.

need to decide if scope is right, and also what depth we cover here vs
individual drafts.  May also be that individual protocols (e.g. RSVP-TE)
need to address their own specific security considerations...

Dimitri - did you identify key security issues that exist in operating MPLS
networks.  So then you can pick those issues and then go into the details.
Otherwise you end up with very broad scope.

Luyann - good comment.  JL did lab tests - e.g. what happens if don't have
good security and unauthorised signalling comes in.  Router CPU gets
hammered.  So these are practical considerations.

Dimitri - would be interesting to see what has highest priority to user
community at large.

Luyann - do we need examples from e.g. L1, PCE, etc.

Loa - who has read?  Who thinks is WG-ready? Seems to be the same hands, but
will ask the list to confirm...


LSP trace over MPLS tunnels (Nitin Bahadur)
----------------------------------------------------------------------------

recently submitted.

simple example of LDP/RSVP.  May or may not wish to allow tracing of RSVP-TE
LSP from the LDP layer.  So you may see LDP path, or full path including
RSVP hops.  In former case may be unable to see why the LDP trace has failed
if the inner LSP is broken.  Also may have issues e.g. where RSVP-TE LSP is
up but LDP LSP is not taking the right path (control plane/forwarding plane
mismatch).

Current problem is that the RSVP-TE only hops don't know anything about the
LDP FEC - so you'll get an error (even if the whole path is up).

George - there is info there, and it is workable with the existing draft.
Your draft also adds some new functionality, but need to agree if it is
needed.

Nitin - as George mentioned there may be ways to skip control plane
validations, as you know the ILM.  But RSVP-TE only node will only look at
outer label.  So can't do control plane validation.

George - that statement is correct.

Nitin - we're solving that by having full control plane validation...  But
don't want to make it a requirement that the intermediate routers expose all
info (so want to allow hiding).

how does it work?  ingress LDP/RSVP edge can tell upstream that it has a FEC
stack.  So ingress can then use that FEC stack when sending to RSVP-TE only
nodes.  So those nodes see the correct FEC and can do full control plane
validations.  Egress LDP/RSVP edge will tell ingress that it is the egress
for the RSVP-TE stack.  So now can just do LDP trace to downstream nodes
beyond the tunnel.

so basically getting intermediate routers to provide info to the ingress on
the start of new tunnels (but can choose to hide that).  Much better than
having no validation.  Most logic is at the ingress application to do the
trace.

TLV changes proposed (building on LSP ping).  New TLV is added (Downstream
FEC stack).  Used to associate to a DSMAP.

can we have feedback, and is this worth being WG doc?

Tom Nadeau - have you thought of solving this using remote ping/trace?

Nitin - yes.  could do that if you encounter a problem?

Tom - if you implemented code to understand responses correctly then you
could understand if there was a problem and then choose to do remote trace.

Nitin - but you wouldn't have the correct FEC stack from the intermediate
router so can't catch that.

Kireeti - this is a specific problem that this technique solves, but also
solves more general problems (e.g. end to end LSP that is stitched together,
e.g. RSVP-TE to eBGP to LDP from inter-AS VPN).  So yes, you can solve some
problems using remote ping/trace, but not all problems.  Nice thing here is
that the FEC stack is doing what the LSP is doing (pushing/popping labels
etc.)

Ina - this is an enhancement for trace.  trace is diagnostic tool.  So we
want maximum clarity.  if we ignore e.g. an error in RSVP-TE LSP that
defeats the purpose of being diagnostic tool

Vach - another case is bypass tunnels.  Why not solve that also here?  So
extend what you have to cover the case where the PLR knows it will use a
bypass.  We do what George is saying, but can we extend this approach to
cover bypass tunnels. 

George - I believe this approach would if I understand it correctly.

Kireeti - yes it would (in the control plane) but the problem is the data
plane will go on main path unless the bypass kicks in.

George - this is data trace, not control plane, so don't see use for that.

Adrian - rather concerned at empty security section.  Confidentiality
matters.  Need the ability to hide tunnel info from nodes outside the tunnel.

Nitin - can use nil FEC entry to hide things.

Adrian - so say so in the security section.

George - nil FEC is equivalent to correctly implementing the existing draft.
Loa - who's read it?  Many hands.  Who thinks is ready?  not as many (cisco
hands rather missing). who thinks not ready?  similar number (cisco).

Nitin - will take this offline.

Loa - I won't ask the list, but will wait for a new revision with input from
George, Adrian etc.


Aggregated IP FEC (George)
----------------------------------------------------------------------------

covers similar ground to Bruno's draft. he's not here (new twins in France!)

so aim is better scaling in terms of IGP and LDP state.

today you need /32 FECs for all L3 VPN PEs when using LDP for tunnel labels.
So the way people do that today is not to summarise those /32 prefixes at
area boundaries.  so lots of routes and labels.  We're victims of our own
success as MPLS networks grow.  so is good news!!!

new FEC type.  Semantics are the same as today, but indicates that next
label is an unaggregated label for a /32.

issue is that you don't necessarily know which ABR will get a packet, so
need each ABR to know what that label means. 

de-agg label based on masking the high-order bits and adding 16.  so will
work with a /13 or longer prefix.  Algorithm ensures that all ABRs have the
same deaggregation...

rules are that anyone summarising is allowed to send out the FEC.  Label
must be non-null (as can't do PHP for context labels).  Must be downstream
assigned and ordered.

LDP labels for specific routes from area that you're the border of.
Context label points to the de-aggregated FECs (or to a standard /32 FEC).

could also do resummarisation.  but would have to translate each label
individually.  would encourage you all not to pursue that!

explanation of how it works.

example showing VPN labels.

more examples.

drawbacks - need 2 labels at ABR (so on some platforms may be slower).  Also
loses next-hop tracking (but hoping to do that by next IETF in Vancouver)

Bruno's draft doesn't need 2 labels at ABR.  Also in Bruno's draft you get
to see the label withdraw so can use that to e.g. change the next hop.

reduces label distribution and preserves LFIB space (unlike Bruno's draft).
Also keeps LDP and IGP co-ordinated (again unlike Bruno's draft).

Not aimed at stopping Bruno's draft.

Ina - this draft causes permanent VPN blackhole if there's a failure to that
PE.  Seems also that it won't work for v6.  So maybe you want to look at that.

George - Q is will algorithm work for v6?

Ina - true nobody is deploying v6 router IDs yet, but why restrict it?

George - Q is whether I'd need to change algorithm for v6?  e.g. toggle bits
in other parts of address range.

Ina - also draft doesn't show what you'd do with more specifics.  e.g. what
happens if you punch holes for some /32s.

George - not highlighted.  no need as will always pick most specific address.

Kireeti - I have a comment/question.  Is this first step in accepting label
blocks as a valid technique?

George - difference is these labels don't come from global space.

JL - actually the hierarchy idea is quite interesting. reduces FIB space.
But may have side effects, e.g. lose fast failure recovery approaches etc.
So may be optimising CP at cost of losing LDP FRR mechanisms.  so need to
mention that.

George - have thought about that.  right now LDP FRR isn't that mature so
is a bit of a moving target. key is that if you had to change ABR the
context labels wouldn't change.

JL - but would have to merge in another ABR?

George - change strategy so instead of going through next ABR would just go
to it and rely on the ABR knowing the context label...

JL - another point.  if I have a network with a /13 or longer prefix I don't
need LDP any more.

George - I've not proposed that.


Scaling in MPLS-TE networks (Adrian)
----------------------------------------------------------------------------

not saying MPLS-TE is broken, but looking forward to see where the barriers
are.

issue is PE-PE mesh.  So it's the old N-squared problem.

protocol overhead of maintaining state etc.

first bit us in looking at LSR management.  Too many entries in the MIB for
the NMS to retrieve.

solutions:
1) hierarchical LSPs
2) something else?

presented in Dallas (March 06).  Various updates including adding Femi
(Glasgow Uni) as author.

approach is to look at "simple" but large topologies (snowflake and ladder)
to see problem (benefit is simple to model).

snowflake is meshed core with edge tree.

ladder network is unmeshed core with edge tree.

so looked at flat networks, FAs (hierarchy), MP2P LSPs.

so metrics etc. - # of PEs, # of LSPs per LSR, amount of LSP state per LSR,
P/PE ratio (cost effectiveness)

conclusions:

1) hierarchical LSPs don't scale as well as you'd expect.  Issue is you need
multiple layers of hierarchy to get good benefit.  Also have major
management overhead.  How do you manage concentric circles of FAs?
Auto-mesh may help, but still major planning task.  Issue of OAM degradation.

2) MP2P LSPs.  So auto-merging of LSPs, with bandwidth increasing as you
move downstream.  So great LSP scaling (especially in ladder topologies).
But LSP state not as good (more state per LSP). Also issue of traffic
disambiguation.  So how do you know where a packet came from?  New
functional controls needed to make it work properly.

next steps are to polish this and close it off.  Would like it to be an
individual submission that would attract WG review in last call.  Not
pushing for WG status, but pushing people to realise there is a real problem
out there to be addressed in future.

Ben Niven-Jenkins - this work is valuable.  Had read the first version but
forgotten the content.  Do you take account of dual-homing in topologies?

Adrian - we don't, but ought to, but it'd fry my brain ;-)  Will have a
think about it.

JP - agree is good work.  do we need a solution?  If you're using MPLS TE
to optimise b/w then isn't it safer e.g. to have full P router mesh.  So get
80% of benefit whilst reducing LSPs by an order of magnitude.

Adrian - e.g. between middle layer in my diagram?  Issue is how many P nodes
do you have?  And do you need to have another layer of meshing?

JP - in a particular core e.g. with 1000 PEs have 100-200 P routers.  that's
OK.  So the thing I'm questioning is do we need to find a solution.  We have
something that may be good enough. key may be to protect stitching point.

Adrian - as soon as you have a mesh between "edge" P routers then you have a
solution.  So you've answered your Q as to whether you need a soln.

JP - so we're in violent agreement.  Also want heads-up to WG.  We're
writing draft on this.  In many cases where people have a problem the
solution is hierarchical LSPs.  What we intend to do is to document all the
issues with H-LSPs.  so if anyone wants to participate see me later.

Adrian - to summarise where that's coming from.  as soon as you go
hierarchical you lose granularity of control.

Dimitri - interesting to discuss this.  But what's the objective in terms of
performance in terms of number of states in network?  There is no perfect
solution.  So if we don't state this we may come with solutions that are
totally incorrect.  It may be a general question.  Are you willing to
enforce merging in the multi-area case.  Or does the source see the full
topology so you're just enforcing a policy?

Adrian - those are both good Qs.  Looking at the second one first.  We have
for the sake of understanding where we're starting from looked at a single
flat routing area.   Breaking into sub-areas or ASes would be an interesting
exercise.   in terms of objectives we need to do more work.  Started with a
simple one of "we want to be able to operate a network".

Dimitri - There's a question of signalling/routing relationship.  Similar to
Bruno and George's drafts.  Is a scalability issue.  need to check what type
of solution we're looking for.

Adrian - another objective was to do TE.

Dimitri - so is for MPLS-TE only?

Adrian - yes.

JL - this draft is very relevant and practical.  I may have some minor
concerns.  Did you look at the key issues in RSVP-TE scaling?  Is it the
number of states, size of state, CPU, memory. with MP2P LSPs you reduce the
number of states, but you may have more processing when you add or remove
LSPs etc.

Adrian - just as with P2MP, the bigger your tree gets the harder it is to
modify it.  We haven't analysed it, but we have recognised it.  not the same
as one LSP.

? - so in a large network you can't have a full mesh of P2P LSPs.

Adrian - my experience of telling SPs "you can't do that" is that it doesn't
help!  SPs want a full mesh of TE tunnels.

? - but there's no solution at this point so going in this direction is
dangerous.

Adrian - if the decision from this work is "you can't do it" then that
doesn't mean it isn't valuable.

? - SPs are facing this even more with P2MP. so would be beneficial to
include that.

Dimitri - if you plan to continue I'd love to see you look at scalability,
robustness etc.  Must look at amount of info that's restricting state
operation.  So look at fate analysis.  With MP2P have one state that
interconnects all LSPs.  Would be willing to help.

Loa - would like Adrian to put CCAMP chair hat on so we can agree process
around this document.  I'm not sure is as simple as sending it in as an
individual contribution.


Bob Thomas - LDP end-of-LIB
----------------------------------------------------------------------------

The motivation is addressing an oversight in the LDP spec.  An LDP speaker
has no way to tell when its peer has advertised all its label bindings.  It
may be useful to know, for example:
1) When is LDP/IGP synchronisation completed?  Better not to have to guess.
2) When has GR restart completed.
3) Case of a label request with a typed wildcard.  It'd be nice for the LDP
speaker which issued the request to know when its peer has sent all the
requested labels.

Our approach is LDP notification with a new status code for end-of-LIB (for
a FEC type).  So send the end-of-LIB status code plus a typed wildcard FEC
specifying the FEC type for which the advertisement is completed.

Issues with backwards compatibility.  Issue is that LDP spec (RFC3036)
assumed that new status codes could be defined but doesn't say what to do if
you get a notification msg with a status code you don't understand.

so draft uses LDP capability so that when you initialise you say if you can
process end-of-LIB.  Peer will only send end-of-LIB if that capability has
been advertised.

example walkthrough...

assume that R1 is active.  R1 sends init with end-of-LIB capability TLV.  R2
in this case can also support it so sends a similar message.  Then have
keepalives and label advertisements etc.

once R2 finishes sending labels it sends end-of-LIB notification for IPv4.

once R1 finishes it does the same.

there has been another draft on this topic (on LDP-IGP sync).  2 mechanisms.
One is similar to this (but no typed wildcard or capabilities).  The other
enhances the label mapping message.  So may want to look at that draft also.

would love comments etc.

? - this is essentially harmless if I received it and didn't understand it.
One of the things you may want to consider is a new FEC TLV that says
"this label mapping message is the last one I'm going to send".  That avoids
sending label mapping followed by notification.  So if there's a minor
routing change then you just send one message.

Bob - that's similar to the other draft.

Ina - what if I expect the notification, but you don't send it?  Shouldn't
it be a MUST rather than a MAY.

Bob - might be good to have relatively generous timeout. can't always be
sure peer will send it.

Ina - (unintelligible)

Alia - talking about negotiating a capability for this.  Wouldn't it be nice
to have a generalised capability saying how you'd respond to unrecognised
status notifications so don't have a special case for every such one in
future.

Bob - will consider that.

Alia - how do you envision a router determining when it's done sending the
LIB?  With LDP/IGP sync one issue is talkative sessions.  It's not always
easy to know.

Bob - things can happen which may require label mapping a few seconds later
or 10 minutes later.  But after e.g. a session comes up the router will know
when it has finished its initial set of advertisements.

Alia - so more clarification on that is good.

Yakov - the draft mentions that end-of-LIB is useful in various scenarios.
That is true, but would be good to document how it is used in those
scenarios.

Luyann - very useful.  when I was on the provider side we had LDP
blackholing issues and issues with LDP/IGP sync.  And issue of how we knew
it was done.  One Q is what if some nodes can do this and not others.  Have
to set certain timers.  Timers not by default.


Non PHB behavior and out-of-band mapping for RSVP-TE (Zafar)
----------------------------------------------------------------------------

Issue of out-of-band mechanisms to bind RSVP-TE LSPs to application (e.g.
with BGP, LDP).  So need to identify local label at egress node to apply
that mapping.  Can't forward until have that out of band info.

also various cases for non-PHP behaviour.

solution is 2 new optional bits.  one for out-of-band and one for no-PHP.
Independent of each other.

note that out-of-band requires no-PHP as have to be able to identify the
LSP.

want this to be WG draft.


Zafar - S2L Name ID for P2MP TE LSPs
----------------------------------------------------------------------------

problem is that for P2MP LSPs if you want to know destination etc.

this doc lets you signal S2L names as well as LSP names.  So can debug given
destination for a given P2MP tree within an LSP using the S2L name.

this draft defines an optional object for the sub-LSP descriptor tuple from
RFC4875.  Can use the S2L_ATTRIBUTE to carry more stuff in future.  Good
comment from Adrian on using RFC4420 encoding.

want more comments and to be WG draft...

Loa - not much support in the room.  will take this to the list and get
feedback.  see if things have improved in October.
This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls