Subject: [mpls] updated wg minutes from Dallas

From: Loa Andersson <[email-masked]>
Date: Fri, 21 Apr 2006 15:27:33 +0200

Working Group,

I've uopdated the minutes according to comments. At least
the comments I've seen.

The IETF schedule require me to upload the minutes toady.
If you have further comments send them asap.

/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:  [email-masked]
                                            [email-masked]
Minutes form MPLS WG meeting at the IEYF65 in Dallas
====================================================

Monday, March 20, 2006, 9.00 - 11.30 AM

1. Agenda bashing
-----------------
Agenda adopted as presented.

2. Working group status
-----------------------
As of this meeting we have a new Area Director for the Routing Area, 
Ross Callon. We welcome Ross and thanks Alex for the last for four 
years.

A good MPLS status page could be found at:
http://www1.tools.ietf.org/wg/mpls/
apart from document status it is possible to find also agendas and 

There are five new RFCs since the last meeting:

    RFC 4379 (LSP ping)
    RFC 4378 (OAM Framwork)
    RFC 4377 (OAM Requirements)
    RFC 4220 (TE Link MIB)
    RFC 4221 (Management Overview)

There is also a non working group RFC:
    RFC 4381 (Informational)
    Title: Analysis of the Security of 
           BGP/MPLS IP Virtual Private Networks (VPNs)
    M. Behringer
that should be interesting reading for the working group.

The following documents are the in RFC-ed Queue:
------------------------------------------------

- draft-ietf-mpls-bgp-mpls-restart-05, for this draft there is a 
  dependency to a document in the Inter Domain Routing (idr) working
  group.

- draft-ietf-mpls-p2mp-sig-requirement-04, for this draft there is 
  no obvious unresolved issues, and it should  be published soon.

The following documents are in IESG review:
------------------------------------------

The three drafts in the package to take LDP to Draft Standards:

- draft-ietf-mpls-ldp-experience-00.txt
- draft-ietf-mpls-ldp-survey2002-00.txt
- draft-ietf-mpls-rfc3036bis-03.txt
---------------------------------------

Alex reported from the IESG review. There are issues in that the 
IETF Standards Process (RFC 2999) says that a normative reference in
a Draft Standard can't point to a document that is "only" a Proposed 
Standard. The LDP specification is dependent on the MPLS 
Architecture (RFC 3031) that is still Proposed Standard.
The suggested remedy here is to included enough of the of the 
information that is reference directly in the LDP specification and
then move the reference to Informational.

Eric R said that this is a dumb idea.  If you put pieces of one 
specification in another then you are creating problems

Alex - we're not cut and pasting.  For example if we look at place 
where label is distributed in LDP will treat this as an unsigned 
integer and then ref to the other doc.

Eric pointed out that the standards process is broken if it can't
handle this situation and if it is this broken we should revisit 
the decision to make LDP a Draft Standard, and just republish it
as a Proposed Standard. If we put pieces (however small) into 
orther specifications we create a even more complicated than the
one we have today, how to we update and change status on documents.
The leason we've learnt is that the broken process generates lots 
of useless work.

Alex said that we have a general problem with normative references
that needs to be fixed, this is not limited to MPLS docs, it the
IETF can't manage this we'll find ourselves in the situation we were
5-6 years ago where MPLS docs were in the RFC-Iditors queue for 
years as none of them could go ahead beacuse of very "meshy" 
references. We need to find a way to decouple references.

- draft-ietf-mpls-ecmp-bcp-02.txt
---------------------------------

This draft is also in IESG evaluation. There is a "discuss" in the 
review that has not been solved. George will meet with Margaret 
Wasserman to try to solve the problem this week. As soon as the 
discuss is resovled a new draft with be published,

- draft-ietf-mpls-nodeid-subobject-07.txt
-----------------------------------------

This document has been approved by the IESG and announced, but has 
not yet shown up in the RFC-Editors queue.

Working group drafts:
---------------------

The draft that will be on the agenda later is not reiterated here.
	
draft-ietf-mpls-icmp-04
-----------------------

This drafts has a dependency on a draft progressed in the Internet
Area, that draft will be on the Internet Area agenda this week. Ron
will be back with further information as soon as we have the outcome
of the discussion in Internet Area.

draft-ietf-mpls-lsr-self-test-06
--------------------------------

The LSP Ping has been approved, so the LSR Self Test is now ready 
to be sent to the IESG for review.

draft-ietf-mpls-multicast-encaps-00
-----------------------------------

No news this time

draft-ietf-mpls-over-l2tpv3-01
------------------------------

The draft has been republished and is ready for Working Group Last 
call.

draft-ietf-mpls-p2mp-lsp-ping-00
--------------------------------

This draft has been waiting on multicast LDP to stabilize.  The
issue has been whether to put TE and LDP in the same draft or not.
Authors want to discuss with the multicast LDP authors during this
week to reach an agreement.

draft-ietf-mpls-p2mp-oam-reqs-01
--------------------------------
There were useful comments on list on the earlier draft, it has
been respun. The authors think it is ready for working last call.

draft-ietf-mpls-soft-preemption-07
----------------------------------

This draft has a dependency on a yet unpublished BCP, J-P has 
promised to start the process to get this BCP moving.

draft-ietf-mpls-upstream-label-00
---------------------------------	

No news.

"Un-published" working group drafts
----------------------------------

draft-raggarwa-mpls-ldp-upstream-00 has been accepted as a 
working group draft and will be published after the IETF meeting.
Other than that - no news.

"Dated draft" working group drafts
----------------------------------
draft-ietf-mpls-fastreroute-mib-04 has expired, Tom has taken the
initiative to republish and finalize this draft.

3. MPLS traffic engineering
---------------------------

draft-vasseur-mpls-number-0-bw-te-lsps-00
-----------------------------------------

The problem addressed in this draft is balancing trafffic across 
multiple ECMPs. Currently non-zero b/w LSPs balance OK the 0 b/w 
ones don't.  To re-optimise one need to know how many 0 b/w LSPs one
have per link. Currently there is no knowledge of this in OSPF-TE or
ISIS-TE so one can't just run a CSPF.

Proposal is a new sub-TLV that just advertises the number of 
zero-b/w LSPs on each link.

There is no changes in the flooding procedure involved and no IGP 
scaling impact. This is a very simple solution, to a very real 
problem.

Working group chairs pointed out that this proposes changes to OSPF
and ISIS. It should be taken to those WGs after we agreed that it is 
a requirement?

draft-ietf-mpls-explicit-resource-control-bundle-01
---------------------------------------------------
No one of the authors were present. This item was deferred.

draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01
-------------------------------------------------

Kohei Shiomoto

This draft is intended for the CCAMP working group presented
here for information and to solicit feedback. 

The draft discusses migration requirements, models, and scenarios
for a migration from an MPLS-TE to an GMPLS control plane.

For the migration period four interworking scenarios has been
identified:

1) MPLS->GMPLS->MPLS
2) GMPLS->MPLS-GMPLS
3) GMPLS->MPLS
4) MPLS->GMPLS

In the first two cases the ingress and egress LSRs are in the same
technology domain.

There are two major areas that need more work - signalling and 
routing. To achieve the migration goal we need to pay special 
attention to differences how these are treated in the MPLS and GMPLS
domain. The problems are mostly identified and the next step is to
is to figure out which solution directions we should take.  

Feedback and comments from the MPLS working group is appreciated.

draft-yasukawa-mpls-scaling-analysis-00
draft-yasukawa-mpls-mp2p-rsvpte-00
---------------------------------------

Seisho

The drafts discusses MPLS scaling issues given larger MPLS P2P 
networks, if a large number of PEs need to be fully meshed this
generates a huge number of LSPs in the core. The draft looks at 
different scaling limitations, e.g. memory, processing and 
management.

Memory is not seen as a real problem, the processing issues might
be for e.g. soft-state, protocols, the impact of a large number of 
LSPs on Network Management Systems (NMS) could be drastic.

The draft discusses three possible strategies to address these
scaling issues, P2P tunnels in the core, LSP hierarchy and MP2P LSPs.

P2P tunnels gives god scaling in the core, LSP hierarchy is most 
effective towards the edge, while MP2P LSPs is effective near the 
egress, but have no impact near the ingress.

Next step will be continued analysis of scaling issues, to determine
real network sizes and limitations. A requirements draft will be 
written, and work with implementers is planned.

JP commented that this is very interesting and promising as far as
it goes. However there are issus that in to be addressed. These 
issues are e.g. sizing of core tunnels, fast re-route and protection
of hierachical LSps will reduce the benefits. JP offered to work 
with the authors to cover these issues.

This draft is intended to become an Informational RFC.

4. MPLS p2MP
------------

P2MP LDP requirements
draft-leroux-mpls-mp-ldp-reqs-03
--------------------------------
Jean-Louis

Changes since previous version - solution oriented requirements and 
text that said that a multicast routing prtocol should not be 
required been removed.
A "complexity requirement" has been added saying that additional 
routing protocol should not be required in the core.
Requirements on avoiding replication on LAN interfaces has been 
clarified. A branch LSR must be able to send one copy on a LAN to 
reach multiple downstream LSRs. It must be possible to select a 
single upstream LSR on a LAN for one P2MP LSP and it shall be 
possible to load balance between candidate upstream LSRs.

The draft is now quite stable, but needs working group feedback. 
There are some comments (mostly editorial) that will be included in
the next version. 

There is a growing support to make this a working group document,
working group chairs will take this to the mailing list.

draft-ietf-mpls-ldp-p2mp-00
---------------------------

Ice

This draft is the outcome of merging to earlier drafts from Ina and
Ice. It is now a working group document.

Changes since the earlier individual version - references to the 
upstream label allocation drafts has been added.  

There is some future work needed:
- resolve issues of ECMP upstream LSR selection
- minimize packet loss during upstream LSR change 
  (make before break?)

draft-ietf-mpls-rsvp-te-p2mp-03
-------------------------------

Dimitri

Some point has been discussed over the last couple of weeks, it is
time to wrap up.

- document how to protect against branch failure, there are three 
  alternatives
  a. include the simple cases in the current draft and leave the
     rest to another draft
  b. take the whole issue to a separate draft
  c. postpone publication until we have solved this issue

No one is arguing for option c, and we seems to be converging on 
option b.

There is also a proposed a clean-up of the terminology.

Version 4 will be ready to publish end of April and should be the
draft we take to working group last call.

Reroute Extensions to LDP for P2MP LSP
draft-liu-mpls-ldp-p2mp-reroute-00.txt
--------------------------------------

Shuying Liu

The goal of this draft is to reduce disruption and duplication during
rerouting. The rerouting mechanism in draft-ietf-mpls-ldp-p2mp has
issues in terms of LSR load, traffic disruption and scaling.

A new mechanism which reduces disruption time and data duplication is
proposed.

Working group chairs pointed out that there is already a working
group document that potentially will address these issues
(draft-ietf-mpls-ldp-p2mp-00). The two group aóf authors should
discuss and see if it is possible to merge these ideas into the
working group documents.

7. T-MPLS; report from the IETF liaison to ITU-T SG15
-----------------------------------------------------
Transport MPLS

Adrian

Adrian very carefully pointed out that he was reporting on an 
activity within the ITU-T Q12/15 for information. 

"Don't shot the messenger".

He also did a quick ITU-T introduction and discussed the relevant
Study Groups (SG).  ITU-T is very contribution and process driven.
SG-13 is NGN,  SG-15 is access network transport and optical 
techologies. T-MPLS is not optical, but it is access network
transport.

Question 12 in SG-15 (Q12/15) owns T-MPLS. A Question is the ITU-T 
rough equivalent to an IETF working group.  The T-MPLS activity has
been going more than a year. But so far no information on this has
been sent to IETF and/or the MPLS working group.

ITU-T and Q12/15 have consented recommendations (roughly equvialent
to and RFC) for an T-MPLS architecture (G.8110.1 - Feb 06) and
Interfraces for T-mPLS hierarchy (G8112).

The T-MPLS is build on MPLS, but it is not obvious that it is 
directly compatible. It introduces a formal structure (e.g. UNI
and NNI), some functional restrictions as compared to MPLS (e.g. no 
PHP, no MP2P/LDP, no ECMP). All LSPs are uni-directional, 
bi-directional LSPs are created by associating two uni-diretional
LSPs, i.e. not GMPLS compatible.

OAM are according to Y.1711, i.e. not compatible with LSP ping.  
Protection switching and survivability is Y.1720.  

P2MP is for furhter study.

The control plane is not decided, but ASON, MPLS-TE, GMPLS, LDP++
are still discussed, though it is not clear what LDP++ really is.
Anyway it is an indication that the LDP base specification is not
sufficient.

One criticial issue from an MPLS point of view is that labels 16-31 
have been chopped out as reserved lables for future study. If this
happens all existing MPLS HW will be incompatible with T-MPLS.
 
Next steps:
1) get a copy (limited free download allowed and MLPS WG may liase 
to ITU-T to get a copy).
2) debate (with care!)  Remember these are from another body with 
their own views and they have put *serious* thought into it.  
therefore raise Qs, don't tell ITU-T what to do.
3) show (somehow) that existing protocols meet the needs (if they 
do).

Eric R: This might be one of the few cases where it may be 
appropriate to shoot the messenger!  
IETF doesn't want to get involved in this attempt to do Frame-based
ATM. It would be best not to engage at all.  It would be useful 
to figure out whether T-MPLS is incompatible with MPLS in data 
plane, and if so then send a liason to ITU-T asking them to make 
it clear that T-MPLS is not MPLS.

Adrian pointed out that if ITU-T Q12/15 or anone else decide to 
extend or tweak our protocols then we need to either be involved or 
to let them do it. 

Loa: In the particular case of ITU-T there is an agreement between
them and IETF to exchange certain type of information. Q12/15 has 
failed to do this in this case.

Dimirti - we already have several flavours of control plane, 
we don't want another.

Kireeti - It is very annoying that this has even got this far. 
We have a GMPLS/MPLS change process.  The idea was to do this 
co-operatively with ITU-T people.  Now they've got a set of 
requirements that became a recommendation without working with 
the proper IETF Working Groups.  Mandating no PHP is funky, 
mandating no merging is really funky.  Can't just go round messing
with SIP and call it SIP.  So can't go messing with MPLS and call 
it MPLS.

Yakov - it is interesting that thee same discussion can say 
"no merging" and "LDP" (which is MP2P protocol).

Italo (Editor of G.8110.1) - we are willing to discuss. T-MPLS is
defined to be a sub-set of MPLS. Idea was not to deviate from the
current standard.

George - as chair you need either to liase with us (if you want 
to use the name "MPLS") or go off and name/do your own thing...  
if it's called "T-MPLS" then its name is a little close to MPLS 
so it would be nice to agree with us.   Is "consented" final?

Editor - no, you can do last call comments after consented.  
Last call is end of this month.

Yakov - Question to WG and its chair.  If you take the MPLS data 
plane as is and use PNNI as the control plane then what would you
call it?  Answering that question will help us deal with this Q.

George - "We could do that, but that would be wrong".

Loa - The working group chairs will send a liaison to SG15 and point
out the failure to communicate and require that the T-MPLS documents
are liaised to the MPLS working group.
8. RSVP-TE extensions
---------------------

draft-xu-mpls-rsvp-te-bidirection-00
------------------------------------

Xiaohu Xu

By the binding of two unidirectional RSVP-TE tunnels between a pair
of LSRs, a bidirectional RSVP-E tunnel could be formed. The 
bidirectional RSVP-TE tunnel can be used e.g. to establish L3VPN 
with virtual router technology.  

It was decided to take this discussion to the working group mailing-
list.

9. End of meeting

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls