PresentationMPLS Working Group Meeting in Seoul


Monday, March 1 at 1300-1500
----------------------------


Chair: Loa Andersson
Note takers: Giles Heron and  Rahul Aggarawal. Thanks!



1. Agenda bashing
-----------------
The agenda was accepted as published.


Slides: mpls-agenda-seoul.htm



2. Working group status - Loa Andersson
---------------------------------------


bunch of docs on RFC editor queue.  In good shape.  Most docs waiting for 
refs, but relatively few.  Waiting for IANA codepoints in some.  GMPLS 
routing is holding some of this up.  It's depending on a whole bunch of 
stuff.  The rest should be easy to get through.


RFC Editor found that for FTN MIB two of the refs weren't 
referenced.


MTU draft and IP/GRE are with the IESG.  Problem with MTU is that there are 
no known implementations - need implementations to go to standard track.  
May be that we can do experimental first then move to standards.


IESG has sent Fast Reroute and LDP PING back to WG for updates.  OAM 
requirements author has asked for WG last call.  Loa waiting for OK from 
authors to send various others drafts to IESG or WG last call.


OAM framework - Tom Nadeau and Dave Allan editing it. Plan is to publish an 
first version I-D soon.  The authors has agreed on an table of content and 
started fill in text.


Slides: wg-status-rfc-ed.ppt



3. RSVP-TE attributes - Adrian Farrel
-------------------------------------

<draft-ietf-mpls-rsvpte-attributes-02.txt> 


The aim of this draft is to address shortage of bit-flags in session 
attribute object. The attribute flags object has been variable lenght to 
make it more extensible.
RRO subobject allows each node to say whether it supports a bit and 
whether it acts on it. An RSVP-TE attribute is an LSP attribute, not a 
session attribute.


This ID is stable and referenced by other drafts. There is a temporary 
registry to track allocations until this goes to IANA.


The attribute per-LSP os of value in Resv and might be used for P2MP. It is 
easy to add and will be optional.


The plan is for one more iteration of draft in March (with per-LSP Resv 
added) and then document implementations, where are a couple started. 
after that it will time for working group last call.


Slides: LSP-Attributes.ppt



4. LDP graceful restart for planned outages - Ina Minei

-------------------------------------------------------

<draft-minei-mpls-ldp-planned-restart-00.txt>


The goal of this ID is to do graceful restarts, but only for planned 
outages (e.g. s/w upgrades). It is not within the scope of this ID if 
restart is ungraceful in other cases.


Graceful Restart parameters are negotiated at session 
establishment. So one will have to flap sessions to change them.


The aim is to make it possible to run in a"no GR mode " by default. When a 
planned restart takes place and the session is to be closed, one will be 
able to configure that at the next restart this will be done in a 
graceful manner. This will be backwards compatible with graceful restart 
RFC.


To make this work we need a new optional parm (GR data TLV) and to send 
this with shutdown status code. The new TLV Carries reconnect time for when 
it comes back up.


A scenario is to tell neighbours that the LSR are going down, but tell them 
to wait long enough to allow for the restarting LSR to come up 
gracefully. Neighbours will then wait until the LSR has come back up.


The restart box will be graceful for the planned outage, but 
ungraceful after. This could be done without specific 
configuration.


The discussion focused on how useful this would be. A question was asked on 
why it wouldn't be feasible to always do graceful restart. The authors said 
this could be a way of introducing graceful restart in the network by 
having it first be applied in a controlled environment, where the 
operator is comfortable with it, before deploying it network wide.


A question was asked whether there is a way to check if the neighbors 
suport this behaviour. The authors said that the current draft does not 
have provisions for it. The reason is because a planned restart is 
initiated by  the operator, who can do all the necessary checks at that 
time. The authors mentioned that the capability could be added.


A comment was made that essentially this draft adds the planned restart 
capabilities to RFC 3479 to RFC 3478.


Discussion to be continued on the mailing list.


Slides: ldp_gr_ietf_slides.pdf


5. Requirements for Point to Multipoint extension to RSVP-TE - Seisho 
Yasukawa

----------------------------------------
--------------------------------------

<draft-ietf-mpls-p2mp-requirement-01.txt>


The work orignated in an effort to put together requirements for TE MPLS 
multicast. This will for a basis for evaluating solutions in this area. 
Since last meeting input from service providers has been added to the 
requirment specification.


The ID is now very stable and the goal is now take the ID to working group 
last call after some minor updates.


Major changes since the previous version:
1) Now a WG doc and added SP and CCAMP authors
2) terminology
3) scenarios
4) make-before-break
5) Added scalability and backwards compatibility.


Remaining Issues:
1) need some extra terminology
2) do we address more sophisticated functions.  Authors would rather defer to 
another doc.
3) Intention is re-spin and then go to working group last call.


Slides: p2mp_requirements_040302.ppt


6. Extended RSVP-TE for Point-to-Multipoint LSP Tunnels - Alan Kulberg

----------------------------------------
---------------------------
<draft-yasukawa-mpls-rsvp-p2mp-04.txt>


This draft is backwards compatibility with existing RSVP-TE LSPs, does 
simultaneous prune and graft and allows for an implementation based on P2P 
mechanisms and smoth migration because it doesn't need wholesale upgrade of 
network.


It will set up multiple P2P LSPs from sender to a single leaf, and then 
from each branch node to a single leaf. The association object is used to 
associate them together and form P2MP LSP.


There have been some changes since the previous draft:
Branches are encoded in secondary EROs (SEROs) up to the branching node, 
after that encoded into ERO at the branching node. Only the brancing nodes 
need to process the SERO.
The association object allows parallel LSPs and does make before break on 
P2MP LSP.


The opinion of the authors is that  this draft satisfies the 
requirements.


Issues:


There are two different solutions drafts for TE P2MP LSPs. The chairs and 
the meeting strongly encourage the authors for both need to get 
together and converge on a single soultion.


Charter milestone is Nov 04 for WG document to be submitted.  Edits will be 
done soon and submitted.  Welcome WG feedback on the email list.  Want 
direction here as to how to get solutions merged together.


Discussion were on capabilites of the solution. e.g. Fast Reroute in case of 
node failure. Authors agreed that this should be added.
The choice of RSVP-TE as protocol for TE P2MP MPLS were also 
challenged, but this discussion was defered until after next 
preentation.


Slides: p2mp_solution_040301.ppt


7. Establishing Point to Multipoint MPLS TE LSPs - Rahul Aggarwal

----------------------------------------
-------------------------
<draft-raggarwa-mpls-p2mp-te-02.txt>



This draft address the problem of introducing Traffic Engineered MPLS p2MP 
LSPs into the data plane with minimal changes to current RSVP-TE. It is 
optimized for a high volume of multicast. It uses P2P LSPS as building 
blocks.
It leveraging the existing Control Plane model, as RSVP-TE support 
multiple LSPs per session. One design criteria has been simplicity of 
protocol and implementation.


MPLS multicast label mappings set up at the merge nodes. The Source PE 
(SPE) initialises P2P LSPs to each Remote PE (RPE) for P2MP LSPs. common 
session object but distinct sender templates and PATH messages (P2P TE ERO in 
each PATH). Each RPE initates a Resv. 
Upstream node does RSVP-TE SE style merge.
SPE gets one Resv per RPE, but merge/branch nodes have set up the label 
binding.


Makes it very easy to add new elements without impacting the existing tree 
(could be significant churn with multicast).


Enhancements since 00 draft:
identifiers for constituents cleaned up
supports secondary P2MP LSPs (as this is common for P2P)
Non-adjacent signalling.
Make before break.
Fast Reroute.
LSP hierarchy.


Authors believe solution is on a par with P2P LSPs - and reuses their 
machinery.  It lets you signal different attributes for each P2P LSP - so in 
inter-domain case can give different behaviour for each exit point.  Aim is 
to move to WG doc.


Discussion were on the realtive merits of the two solutions 
proposals. This discussion concluded in that issues with both 
proposals should be sent to the list and the there seeems to be good 
reason to continue investigating ways of merging the two proposals.


It was also pointed out that there is work in other groups on 
multicast, e.g. extending PIM. In response to that it was said that the 
work specified in the two draft are for Traffic Engineered LSP only. 
Nevertheless there is a need to coordinate this work with the 
multicast working group(s), at least when it comes to non-TE.


Slides: ietf-59-seoul-p2mp-te-prn.ppt



8. Nexthop Fast ReRoute for IP and MPLS - Naiming Shen

------------------------------------------------------
<draft-shen-nhop-fastreroute-00.txt>



The goal for this draft is to solve the problem of Fast Rereoute for 
traffic in general, not just TE LSPs. LSPs, regardless if they are LDP, TE, 
IP or IP multicast is protected.


There are several known approaches:


1) IGP Fast Convergence - when a link or node failure is detected 
flood/process this information faster than other IGP information.  This 
enables the whole network to converge faster.


2) MPLS-TE Fast Reroute


3) Pre-Computed alternative next-hops.  Based on IP (typically IGP) 
information.  Download alternative paths into forwarding plane and switch 
onto that when there's a node/link failure.


4) Next hop fast re-route.  Use MPLS LSP as an explicitly routed tunnel to 
reroute general traffic in case of node failure.



All four types of traffic have an IP next-hop.  An explicitly routed 
tunnel is used to protect the next-hop.  Use this to route to next-hop node 
or next-next-hop.  Protection LSP is unaffected by routing changes as is 
explicitly routed.  Could equally do this with Frame Relay etc.  Reason for 
doing it with MPLS  is because modern routers support MPLS LSPs.  Can 
either use one tunnel to protect mix of traffic, or one tunnel per 
traffic type, any approach is possible.  The uniform in itself is a 
benefit. Don't need one mechanism for fast reroute for TE and another for 
IP.


Tpo achieve this we need an new RSVP object - bypass next-hop.  It is used by 
ingress node to inform egress of what you're trying to protect.  For link 
protection is next-hop, for node protection is next-next-hop you've 
learned through some other mechanism.  The major application is 
multicast.  Need to modify the RPF check.


We need to request a C-class number from IANA for bypass nexthop object. 
There are also drafts on node-protection for LDP and for PIM.


Too early to adopt this as a working group document, the discussion will be 
continued on the mailing list.


Slides: nexthop-frr-mpls.ppt


9. Discovering LDP Next-Nexthop Labels - Enke Chen

--------------------------------------------------

<draft-shen-mpls-ldp-nnhop-label-00.txt>



This is an LDP specific follow-up to the draft discussed previously.


Normally LDP nodes only know bindings for adjacent peers.  To do node 
protection next-nexthop labels are needed.


The next hop label discovery is build on two capabilities.
- the  ability of a node to signal its interest in getting the 
next-nexthop label mapping info and the ability of the node that 
receives this request to advertise the next-nexthop information


- the use of the status TLV to carry info in notification message (saves 
inventing a new TLV) and the use label TLV to carry next-nexthop info in 
label mapping (consists of label/router-id pairs of next-nexthop nodes).


Loa (chairman's hat off) - we do FRR.  Fine.  It is one of the key 
element in TE.  Fine.  We have RSVP-TE as TE tool.  So why start doing TE 
with LDP at this moment?  We closed CR-LDP about a year ago, and it is not 
our intention to revive it.


Authors responded that LDP is widely deployed today.  Fast reroute makes 
sense in this kind of deployment.  RSVP-TE is already available sure.  If 
you are using LDP for L3VPN then don't need to turn on RSVP-TE for Fast 
reroute. BTW we are not trying to do TE for LDP.  Just trying to 
protecting traffic.  


Questions were asked if tLDP already gives give you what this draft tries to 
accomplish. The discussion on first draft will contiune on the list, it 
makes sense to include this second draft in that discussion, since they are 
closely related.


Slides: ldp-nnhop.ppt



10 .Multiprotocol Label Switching Pre-emption - Adrian Farrel

----------------------------------------
---------------------
<draft-farrel-mpls-preemption-00.txt>


The issue were brought up in Minneapolis and it was agreed upon that there 
are differnt interpreations on how to preeemption in different RFCs, as 
well as various interpretations of what people *want* to achieve. In 
preparing the draft the author have polled for requirements. The 
discussion has been very limited on the list, and some off-line. 


The requirements are 
- that we have known and understood procedures for soft/hard 
pre-emption,
- that these procdures are backward compatible 
- that it possible to tell what is soft vs. hard preemption.


Author asked if there is an intrest to continue this work and several 
people said that there is an contiuned interest.


Issues:


Need to clarify GMPLS - especially for soft preemption.
Question as to whether existing soft preemption draft will now be 
redundant.
Not going to address rights and wrongs of implementations.


Plan:


Will clarify GMPLS in march.  Last call April.  Not a big deal - just an 
error code.



Adrian - Loa, would you like it to be a WG draft?


Loa - asked you to do this because I care, so we need a working 
solution with >1 implementation.  Not been asked if we should make this WG 
doc.  Probably come back to it once you've done a re-spin.


Dimitri - can we fix a timeline for this.  If we don't find a solution soon 
will have workarounds that people find.  Would like it solved ASAP.  Do 
re-spin soon and discuss on list.


Loa - Adrian promised re-spin in March.  Take to list then and discuss if is 
WG.


Slides: soft-preemption.ppt


11. Meeting closed