[mpls] MPLS Minutes

IETF 68                     Prague, Czech            MPLS Working Group
=======================================================================

Working Group Upadate
---------------------

Changes in IAB/IESG - Dave Ward is new rtg area AD, taking Bill
   Fenner's position.

Status of Working Group Drafts:

One new RFC (4781).  Oldest doc from editors queue (been there 6 or 7
months).

Three docs are in the RFD-ed queue.

Six docs in IESG review.  When an AD leaves he has to clean up before
IETF week is out so Bill has been working hard to get these done:

Finally agreed on ECMP draft and how to spell bits out.  
[Editor's note] the IP protocol number 1 is now reserved (as is 0).

LDP spec is our first draft-standard.  Ina drove this - so thanks due
to her.

A protocol write-up is needed on LSR self test.  (George's action).

ICMP draft.  Companion draft in int area has gone through and been
last called.  So now done IETF last call on our draft.  One comment
but it was determined that the draft is correct and the comment
wrong. So no major problems expected.

Whole bunch of WG drafts:

FRR MIB not yet updated post MIB doctor review.  Tom will do this -
expect it to be published soon.

interas-lspping is relatively new.  All need to take a look and
comment.

LDP typed wildcard.  Authors want last call, will happen this
afternoon and have until 2 weeks after IETF.

Multicast encaps. Authors want comments - nothing else happened since
last our last meeting.

number-0-bw-lsps has no implementation so can't progress for now. But
it may be that there is now a test implementation, and it might work.
Ross seems favorable to progressing it...

p2mp lsp ping - new version was published.

Adrian - more updates.  Supposed to meet with George to check is
implementation ready, but forgot.  Looking for people to review it and
write code.

p2mp ldp - new version will be published soon after IETF.  Please
review.

p2mp ldp reqs - authors want wg last call.  Will be issued after the
IETF meeting.

The is a group of drafts around MPLS multicast/upstream labels.  Can
WG please review these four drafts (and any others in same area) and
make good comments by Chicago so we can progress...

One non WG draft - andersson-rtg-gmpls-change.  Focus changed over
time.  Has been approved by all relevant ADs, so will hit RFC editor
queue soon.  Been a pain for some time...  

George - contragulates Loa for pushing it through (with 
Adrian/Deborah).

Incoming liasons - will speak about two of them (from ITU-T - arrived
March 13th).

1) T-MPLS OAM mechanisms. want comment by end of March.  Triggered
response from MPLS and PWE3 WG chairs saying time was way too short.
Sent mail to list today.  will take around 6 weeks...

2) T-MPLS OAM reqs.  Stewart Bryant asked PWE3 and TMPLS to review.
Haven't had time to read comments from MFA.  Been delayed as got
dropped between chairs.  Please comment on it.

3) Updated version of Y.1720
George + Stewart did a liason response.  It will be sent for review.
Original thing is OK as doesn't break MPLS (but MPLS may break it -
not our problem).  Once piece of ambiguous text that implies you might
be able to put seq #s where the label ought to be in the stack.  Very
unclear and needs clarification...

Draft-vasseur-mpls-3209-patherr-01 - JP
---------------------------------------

This doc was produced because of soft preemption discussion (been
going 3 years!)  The issue is that misunderstanding on soft
preemption.  One suggestion from Adrian was that unless you
undertstand hard preemption you can't understand soft preemption.  so
wrote doc explaining what to do with each sort of PathErr.  Clarified
for each error code whether it is intended to tear LSP down or not.

Presented draft at last IETF.  Discussed with other vendors - esp Ina
(Juniper).  could be big work to document.  Proposal is to try to
scope the error codes related to preemption.  Might be sufficient to
unblock the situation in the soft preemption draft.  Need some other
vendors to show up and say what they do - and then we can do regular
updates.  Helpful to document it...

First Q is do we think it is reasonable to document what
implementations should do?  Not always clear from the RFC.  And if we
start with soft preemption then does that make it easier to progress
the soft preemption RFC?

Loa - my response has always been yes.  But we haven't really
delivered on our promises.  Given that we see promise of doc and work
in general the answer is yes.  don't want another doc hanging for 2 or
3 years.

JP - we can try to resolve preemption in the next month or two and
then work on the doc with other vendors.  Ina - agreed?

JP - can the WG adopt it?

Loa - fair number of hands.  Nobody opposed.  Will ask list.

Ina - can we look at split that JP proposed, and do a new doc version
which makes it clear what it addresses.

Loa - if we make it WG doc it gives WG chairs revision control of doc
and they can push on it.  For me this is procedural and I'll be happy
to discuss any split in the docs, but want WG to have revision control
- so we can push them through...

Ina - if our main goal is to unstick soft preemption draft then best
approach is to address issues related to preemption first.  If bundled
together then there's a risk it'll sit around for years as Loa
indicated.

draft-leroux-mpls-p2mp-te-bypass-01.txt - Jean-Louis
----------------------------------------------------

There are limitations to using P2P bypass to protect P2MP LSP.

noted that may actually have duplication during link failures as well
as nodes (if the bypass for the failed link goes across another link
that is already being used for forwarding).

aim is to avoid duplication whilst retaining scalability advantages of
label stack.

inner label is backup LSP label (and is upstream assigned by PLR).
outer label is P2MP bypass tunnel label.

Use of P2MP bypass would compliment P2P.

UA label is context specific where context is P2MP bypass tunnel.

changes since last version:

New co-authors

Added support for link protection (see example above)

LAN interface protection (P2MP tunnel to all downstream LSRs on the
    LAN)

now 3 options to protect P2MP LSP (one bypass for all MPs, a set of
    bypasses reaching all MPs, or a bypass that reaches more than just
    the MPs)

Clarification as to how to set bypasses up (local implementation issue)

To be done:

Simplify LAN interface protection.  Since UA label needed for both
primary and backup LSPs we can use the same context.

Address case where MP doesn't support UA assignment (by using a mix of
P2P and P2MP bypass tunnels)

Want WG feedback on whether partial protection is ok if some MPs can't
be reached (would have a new attribute in attribute flags TLV -
RFC4420).

Look at cases where PLR isn't directly upstream of failed resource.

Conclusion - remains quite straightforward, and want WG feedback.  In
San Diego said would want WG status in Prague, so now requesting it.

Loa - Q on protection.  This can become extremely complicated.  Cases
where unless you swap to backup LSP for all traffic you don't save
much per network.

JL - in FT's network topologies this approach saves a lot of
bandwidth.  In some parts of network have P routers with 20 or so
downstream LSRs.  P2P bypass will give us 20x the TV traffic on some
links.  If you put the PLR two hops upstream of failure the b/w
optimization may be different but impact recovery time.  Always
tension between recovery time and b/w saving.

Loa - when you get into situation where b/w is scarce resource you
have to make hard decisions.

Adrian - FRR is not intended to put traffic onto a path that lasts
forever.  Idea is to recover trafic until you reoptimize.  In case Loa
showed you'd reoptimize the tree.

George - in fact by nesting the tunnels you could change the EXP bits
on the bypass so wouldn't interupt committed traffic.

JP - you raise a good point.  Might even be possible to signal the
tradeoffs so each PLR could evaluate cost for bypass LSP and use two
parms - how far from the point of failure and the cost of the LSP to
decide whether to be PLR.

George - don't forget we're talking about explicit routed tunnels.
May be regrooming to different area of network.  Backup tree may
already be set up but because of geographic distance you may want to
repair locally.

Show of hands on WG doc.  Good support...  taking to list...

LDP extension for Inter-Area LSP - Bruno
----------------------------------------

Draft allows FEC based on longest rather than exact match in RIB.

Text added on RIB interactions.  Issue is that with a single RIB
change, the longest match is likely to affect multiple FECs.

For prefix up check all FECs which are subset of *new* RIB entry to
see if it is a better match than existing prefix being used.  For
prefix down check all FECs using the RIB entry.  For next-hop change
must change NHLFE of all FECs using the RIB entry.

Conclusion is that this is straightforward, and solves an operational
problem.  It is stable and is being implemented.  Want WG adoption.

Ilya - idea is good and practical.  but if you consider that may have
one hop between ABR and destination then the area boundary has to pop
label and resolve the next label using a RIB lookup and impose new
label popped at next hop (doing another lookup).  So inefficiency in
handling...

Bruno - LSP doesn't stop at ABR.  IP route is summarized, but not IP
route...

George - good piece of technical work.  but does it save a lot or move
work from IS-IS or OSPF into LDP?  have you analysed that?  Is it
worth the effort to put this in LDP? how many cycles are saved?

Bruno - doesn't add work to LDP.  All it does is remove prefixes from IGP.

George - you still have to put disaggregated prefixes into every
linecard.  So when a routing change occurs you have to do X amount of
processing.  what is the new processing as a percentage of that?

Bruno - hard to answer that from a protocol point of view. Advantage
is that we can factorize some treatment.  If we have 100 LSPs and path
to ASBR changes then we have one event with 100 FEC changes, or 100
events with 1 FEC change.  We save the IP work.

Ina - for performance evaluation with/without this extension it'd be
better to look at this from the operator's perspective.  Do you really
want to leak all those prefixes?  What you pay in terms of performance
on router is implementation issue.

Loa - I guess we are at point where we need to send this to WG list
and list our concerns, asking for comments before we make it a WG doc.

Bruno - in San Diego conclusion was to get comments on list.

Loa - hadn't heard Ina's comment before.  Also George's.  So you've
requested WG feedback.

George - poll of room on support is ok.  but need to seriously think
this through.

?? - this is about IGP scaling.  ABR or L1-L2 router is the busiest
router in the network.  Anything that takes dynamics off the core is
good.

Some in favor, few opposed.  chance to talk on mailing list.

George - need serious discussion on list...

Security framework for MPLS/GMPLS - Luyann
------------------------------------------

The question was raised in CCAMP as to whether this should be MPLS WG
or CCAMP.  For now is in MPLS.  Final call must go through both of
course...

Issue is that various drafts have been stuck on Qs from security area.
Can't just say "no new security issues".  Maybe a better way to do
this is to have a single document on security issues of MPLS and GMPLS
in general to have consistency.  Other each draft can ref this and
adderence any specific issues.

Scope - issues with MPLS protocols, specific operational issues for
MPLS nets.  May change scope in future.

Outline of 00 draft:

Need to define the trusted zone (e.g. your own AS).
Will be emphasizing how to protect the SP core

A new version will be issued before Chicago and we will be asking for
WG status then so please review + comment.

Richard Grossman (RFG security) - real good start.  Approach of not
inventing security mechanisms is entirely correct, but good to hint at
what to do.  Scope issues in current draft.  What you say is correct,
but you also mention syn floods, social engineering etc.  But then
insider threats may be important.  Please look at RFC4230 (RSVP
security properties).  DoS is really important and scattered in doc -
so maybe pull it out into one section.  Important issues are (1) being
able to filter at line speed.  (2) not to amplify.  Can't stop people
sending DoS.  Statement about encryption being expensive is left over
from 1980s.  Get used to it.  Integrity checks are even cheaper, and
sometimes that's all you need.  Key management is important,
neglected, and hard.  Doc talks IPSEC.  IKE is the tough bit.  Suggest
that the work of the isthmus and syslog groups be looked at.
Reporting is important and syslog group is active and in late last
call.  Isthums may be more promising than SNMPv3.  BGP is talked
about, but OSPFv2, v3 and IS-IS are all important.  IS-IS is different
as not an IP protocol...

Sam Hartman - agree this is important.  I think that this is great
starting point.  If you want this to serve its function then it's
going to be important to spend a lot more effort on the trust
model. You have a trusted zone but don't talk about what people in/out
of the zone are/aren't trusted to do. So hard to evaluate security. So
most work needed there...  Another area is going to be discussion of
gaps.  For example many of the protocols involved don't meet RFC4107.
Need to call that out (but not fix it - as not your job).  The one
other concern is that not entirely sure that the goal of having
something useful for security sections of protocol drafts is also
consistent with giving operational advice.  Think it's a good goal but
set up a fairly challenging set of issues for one doc.

Loa - Q for Sam (out of blue).  Could we have a contact in the
security area directorate?

Sam - A group of us are meeting for lunch to discuss this stuff.

Luyann - been thinking about trusted zones etc.

Sam - to get past IESG you need more.

Kireeti - I was curious that you had PCE in there but no TE IGPs.
Much more widely deployed.  Also don't think should be informational.

Sam - doesn't need to be normative for security considerations.

Adrian - tried to take notes as Richard was talking.  Richard - good
comments and can you please send to list.

LDP Capabilities - Jean-Louis (on behalf of Bob Thomas)
-----------------------------------------------

Motivation overview - abiity to negotiate enhancements to the base LDP
specification at session init and then to enable/disable those
enhancements later.

Changes - tried to simplify encoding/processing.  Removal of
capability list TLV and ack mechanism for dynamically advertized
capabilities simplifies things.  Defined capability parameter -
optional LDP TLV.  Each capability has its own code point.  No need
for new registry - using existing LDP codepoint registry.  "S bit"
defines whether capability is being advertized or withdrawn.  Also
have ability to encode more complex capabilities.

The upstream-assigned label draft has been aligned with this new
capability.

Loa - seem to be no Qs or comments. Authors want it to be WG doc.
A poll of the room showed good support.

draft-ali-mpls-rsvp-te-s2l-name-00 - Zafar
------------------------------------------

The requirements is for signalling of sub-LSPs in P2MP-TE.  We don't
want to overload the session naming for S2L naming.  Becomes a
meaningful concern where customers want visibility of S2L bindings in
large networks.  Thus we need two levels of naming - one for P2MP LSP
name and one for S2L name.

The solution is straightfoward.  It also allows us to add future
attributes at S2L level if we find them (for now only have S2L name).

Loa - no Qs.  Very few read the draft...  very little support for WG
status.  nobody seems opposed.  Take to list!

George - need to get everyone to read it.

draft-brockners-ldp-half-duplex-mp2mp-00 -  Frank
-------------------------------------------------

This one sounds complex, but is actually a simple extension of mLDP.
There are a couple of scenarios (some inspired by regulators etc.)
where you want to broadcast from multiple sources to a large number of
receivers but don't want clients to be able to talk to each other.
The application is similar to routed multipoint EVCs from MEF.

This draft allows servers talk to clients (and each other) clients
talk to servers (and not to other clients).

Objectives:

  Simple provisioning - no reconfig when a new leaf joins (server or
    client).

  Automatic forwarding setup.  

  Limited state.

  Avoid ingress replication.

Today would use P2MP LSPs for server-client and MP2P LSPs for
client-server, and have each client join to N x P2MP and N x MP2P (for
N servers).  Besides all the extra state, an operational problem is
that need to reconfigure clients when you add a server.

This draft modifies current MLDP behavior to allow just two trees
(clients to servers and servers to clients+servers).  It everages the
P2MP FEC element to allow 4 FEC types which identify the upstream and
downstream directions of the two kinds of LSPs.

In principle it is very similar to MP2MP LSPs.  The difference is we
need additional behaviors to get to half-duplex behavior.  Opaque
value may be required e.g. for broadcast scenarios.

Would appreciate feedback.  Draft is a bit hard to digest, so adding
an example to make it more readable...

Kireeti - rather specific topology here (servers, clients with fixed
roles, rules), so this seems to be a point solution.  What you really
want is to separate tree topology from LSP setup.  Otherwise if
someone e.g. has servers that don't need to talk to each other they
need a new solution.  So could end up with a huge number of drafts.  I
understand you want simple config.  So let's separate the two
problems.  Have one mechanism for topology discovery, and one for
creating trees, and glue the one on top of the other...

Ina - seemed to me reading draft that assumption was that you have
manual config.  did you consider automating it. Also can you in a few
words describe the scaling for forwarding/control plane as compared to
building N trees?

Frank - need to configure at each device if you're client or server.
e.g.  scenario with 50 BRAS in residential environment would have 25 x
the state with separate trees.

Venu - trying to understand benefits.  Is the benefit that you just
have one tree?

Frank - benefit is 2 trees and no config at client when you add a
server (e.g.  when you add a BRAS).

Venu - as compared to SSM trees?

Frank - yes, not a tree per server in this case.

Yakov - the reason why you need to configure each time you add a new
server (today) is because you have no topology discovery.  So need to
look at auto-discovery as an option and then build trees to match that
topology.

Frank - I agree with concept of generalizing this. and we can probably
do it.

Yakov - as you yourself said it is a point solution, and we want to
avoid those...

draft-swallow-mpls-remote-lsp-ping - George
-------------------------------------------

This mechanism is actually called proxy ping (except in the draft name
which was kept because of the later draft deadline.  No huge changes
since last time.

The mechanism can be used to do a leaf to root trace.  A leaf knows to
whom it sent the label request to join the multicast tree.  The leaf
uses a proxy ping to get that node to ping that segment.  he can also
send it the previous hop.  It can then iterate up the tree to the
root.  It can also limit the number of ping messages that get
processed by only going two hops at each step.  On each iteration the
leaf can scope the ping down to the particular next-hop that extends
the LSP toward itself, since it has already discovered and verified
that node.  It can scope the node from which wants a response to the
one two hops toward itself.  So this compresses things and makes a
really nice tool.

Proxy echo reply is there to carry previous hop info and verify that a
ping was (or will be) sent.

There have been various changes since 00.  The most notable one is
that faking of the source address on the ping has been dropped.  (It
raises all kinds of security issues).  A consistent source address is
needed on P2P LSP to follow ECMP route, but since use cases are almost
all multipoint (which has no ECMP issues) then this becomes much less
useful.

Loa - how many have read.  Quite a few.  Mostly in favor of WG status.
nobody opposed.  Take to list.

draft-swallow-mpls-mcast-cv-01 - George
---------------------------------------

This draft defines a keep-alive OAM mechanism for P2MP MPLS LSPs.  It
also can be used for MP2MP, but complete coverage only comes by
running a session for each sender.  

There are a few differences when compared to unicast (MPLS-BFD).
Leaves may be coming/going, that is the LSP may be changing
dynamically over time.  In BFD one can only take down the entire
session to all leaves.  We need to be able to take a leaf out of
service (basically tell it not to alarm) without terminating the OAM
to other leaves.

The motivation came from customers wanting good OAM for P2MP-TE.  High
value apps sending TV or financial data so can't afford to lose it.
Willing to create two entire trees, send data twice, and use OAM to do
egress selection (equivalent of UPSR).

Also applicable to M-LDP but in that case you are monitoring rather than
doing repair.  Allows reporting of failure indications.

One requirement is to keep config to a minimum.  Leaf configuration
could be as simple as "Accept all mcast-cv sessions".  All you have to
do is send this msg from head and then everyone binds it.  Of course
in real world you may not want to accept every session.

We're defining control protocol to control BFD session.  Actual
probing done using BFD.  BFD draft not submitted last time I
presented, but being worked on since last June.  Dave Katz and Dave
Ward doing it.  It was presented in BFD the other night.  New AD is
also AD over in BFD and is also BFD chair and draft author.  Poll of
room in BFD indicated it would probably be accepted as WG doc once BFD
rechartered to include it.

BFD mcast has morphed slightly since last rev.  3 modes of
notification to head have been slightly refined:

1) no notification (used in "UPSR" case - head doesn't need to know as
it's up to the tail to repair and/or alarm).
2) unreliable notification (occasionally set poll bit and get replies
back, but not 100% guaranteed that they'll arrive)
3) reliable nofification (use set of P2P BFD sessions and unicast to
leaves you've not heard from).

Dropped scoping after discussion with Adrian.  Never heard the
req. from providers and don't want to add processing.

Adrian - we goofed.  After our conversation you took it out and I put
it back in (into MP LSP ping).  We need to agree if we want scoping to
a set of nodes or not.

Adrian - we had scope to single node or all nodes before.  Are WG
happy to take that back out again...

Loa - fairly new, few have read The draft.  Most of those support WG
doc.  Nobody opposed.  To list.

draft-ali-mpls-rsvp-te-no-php-oob-mapping-00 - Zafar
----------------------------------------------------

George began with an introduction:

Two issues have arisen in RSVP-TE.  There have been discussions
between Rahul, Yakov, Zafar and myself.  We we're able to come to a
consensus in time to meet the ID deadline, but have since.  We wanted
to take the oportunity at this meeting to introduce the problem so
that we can move forward in future meetings.

The issues are first, sometimes you need no-PHP in order to have the
proper context at the terminating router.  However there is no way to
signal this in RSVP-TE.  Second, the binding information for a
tunnel's use may come asynchronously and this needs to be indicated.
A side issue here is that the semantics of the PID signaled in the
RSVP Path message may not be adequate.

Zafar has put together a draft presenting the problem and our proposed
solution.  We didn't come to closure in time to publish the draft, but
have reached closure since.

Zafar -

The draft was posted last night.  Should be there in a few days.  One
issue is where you need to bind an RSVP-TE tunnel to some out of band
mechanism.  That is, the info as to what LSP to use comes out of band
(e.g. via BGP).  To do this we need local label info at egress to
idenfify incoming tree.

The two operations - signalling of RSVP-TE LSP and binding out of band
are asynchronous - could be asynchronous.  LSR receiving binding info
out of band can't do forwarding until that binding shows up.

To avoid cases where you didn't get binding for unreasonable amount of
time we need cleanup to avoid tying up resources or blackholing.  The
egress MAY send PathErr if an out of band mapping is not received in a
reasonable period of time.

Another app could be multicast RPF check.  Or determining that we're
receiving traffic on the expected LSP.  Also with UA labels where
the context is in the MPLS LSP we need the non-PHP behavior.

Solution is straightforward.  One bit for non-PHP behavior and one to
indicate that mapping will be out of band.  The two new bits are
completely independent.

When an egress receives non-PHB bit it must assign a local label.  The
ingress may use the RRO label recording to check it and send a path
tear if egress has assigned null label.

Yakov - granularity of out of band mapping may be finer than what we
can express with L3PID.

George - so out of band mapping could overwrite L3PID.

Yakov - exactly.

George - while bits are independent I can't think of a case for out
of band mapping being used without turning off PHP.

Conclusion - Loa
----------------

A big thank-you to Bill Fenner for his 5 years of service as routing
AD!  Meeting closed - see you in Chicago!

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls