The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

All,

the working group minutes from Dallas.

Thanks to Giles and Tom who took note, they are
the reason anything got captured. However, mis-
spellings, curious grammar and misunderstandings
are mine.

Please comment to the wg co-chairs and or the list.

/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
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.
There were discussion about the this, but also stated that the MPLS 
working group is not the venue for this discussion, should be taken 
to newtrk. 

- 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".

Q12/15 is currently working on something that they say is a profile
(subset) of MPLS, i.e. Transport MPLS (T-MPLS). The first round of
the documents are already decided (consented) on or close to being 
decided on.

The is a T-MPLS Architecture document (G.8110.1) consented in 
February 2006. This document describe the MPLS for a transport 
environment and what functional units are needed to provide that.

There are certain parts of the text in the documents that, even 
though positioning T-MPLS as a subset of MPLS, needs to be looked
into for compatibility reason.

It is clear that this should have been liaised from Q12/15 to the
MPLS working group. The working group chairs will send a liaison to
SG 15 and point this out and also request that the documents are
liaised to us.


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
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls