The MPLS WG Archive

[Loa Andersson <loa.andersson@utfors.se>]

Included are the drafts minutes from the MPLS wg meeting in
Yokohama. Thanks to Dave and Eric who helped taking notes,
but have not repsonsibility for the delay in getting them
out to the list.

Please comment.

/Loa


IETF 54 MPLS WG Preliminary Notes

Thursday July 12. 9 - 11.30 AM

Chair - Loa Andersson (George Swallow not in attendance).
Note Takers - David Allan, Eric Gray

Loa:
Agenda bashing
--------------
- process reminders/blue sheets
- LDP MTU draft off the agenda
- No further comments on the agenda


Loa:
LDP (RFC 3036) to draft standard (status)
---------------------------------------------------
Loa talked about the need to collect implementation information on
LDP for taking it to Draft Standard.
It is still not clear how many other rfc's that will be affected, encap 
and  LDP draft, maybe also architecture. This is because of normative
references.
A survey form is developed and will be  published on the list in a few 
weeks, together with instructions on  how to respond. Asked to include
an anonymity  option. Scot Bradner  will act as anynomizer".
Results will be published as an I-D.
One intention will be to simplify LDP, so unimplemented stuff will be
removed  when LDP is moved to draft standard.

Scott Bradner AD:
Current state of the issues in the mpls oam discussion and the ITU-T 
liaison.
-----------------------------------------------------------------------------
The background is that we have an I-D, by Hiroshi Otha, requesting a
reserved label to be used by ITU-T, for OAM. At the last meeting the
discussion concerned changes to IETF protocols that would result. As a
result a liaison was sent for clarification, asking if they were operating
under the assumption that they would be requesting changes.

Liaison response: Hiroshi Ohta (SG13 Rapporteur, slides included)

Hiroshi Ohta presented a report on ITU-T's response to IETF's liaison on
MPLS OAM.
He stated that they do not expect to impact IETF protocols and minimal 
impact
on implementations. Y.1711 cannot work without the reserved label - 
therefore,
they request that IANA assign a reserved label.

Discussion
----------
Rahul Aggarwal: The statement of no impact on forwarding plane is 
inaccurate,
on egress LSRs there will be an impact.


Kireeti: If we allocate this label, will the ITU use this label 
'efficiently',
  in other words, will there be other requests.

Scott: The ITU is finding that IETF protocols are popular, so they want to
use them.  He gave an example of the process using SIP. The IETF decides
that protocols developed by IETF need to be reviewed by IETF  when 
extensions
are being proposed.

Kireeti: there are two concerns, one is the IETF process (which is good)
and the other is how far does this go? Do they need to go through the RFC
process.

Scott: This may be dealt with in many ways, however we hope that the
cooperative approach will work.

Scott asked the sense of the room:
We have an I-D seeking assignment, we've interacted to find out answers to
questions we've asked. I think this is a good thing, both cooperatively and
for the good of the protocol. MPLS is being used in a number of 
environments,
and the usage assumptions are different depending on the carrier. We 
need to
support the IP carrier, but that is not all of them. In that context we 
should
be open to the use of our protocols in other environments. For MPLS to 
be seen
as useful in trad telco environments it needs this stuff.

Hummm (a few raised hands :)) showed a consensus for RFC publishing the 
draft
and issuing the label.


Scott Bradner:
rsvp-te vs. cr-ldp, initiating a discussion
-----------------------------------------------
In the implementation survey for GMPLS, there was lots of RSVP and 
little CR-LDP.
Concern in ISEG on multiple standards track ways of doing something is 
confusing to
the market place. Don't need to visit the history. Don't think we need 
to stop
publishing CR-LDP, but should they be informational or standards track.

Discussion:
----------

Loa: The intent of having this agenda item is to initiate the 
discussion, not
arrive at a conclusion at this meeting.

Bilel Jamoussi: Comment on the survey. Did not state the objective or 
indicate
how it was going  to be used. Not scientific by any means. More 
importantly GMPLS
is a new thing, carriers are still debating the architectures. Think the 
discussion
is premature.  There are today several networks running CR-LDP in a packet
environment.

Bert: Purpose of survey was to seek an implementation report before 
approving
GMPLS. This was an artifact of the survey not the intent. I don't think 
discussion
is premature, a decision may be. Folks can still implement 
informational. Within
one org you would normally try to go for one standard.

Kireeti: I wear several hats. CCAMP chair, twice as many protocol 
extensions
because  of two protocols. Have to write two sets of drafts as an 
author. Have to
read twice as many. As a vendor I do not care, and do not implement it. 
Impact on
IETF is twice as much material.

Luca Martini: as a service provider, we found RSVP predominantly 
deployed and
implemented. Pushed by a particular vendor for an obscure reason. We 
should shift
CR-LDP to informational.

Ron Bonica: Like to second what Luca said. IETF produces too much 
technology to
do a good job. Lets prune.

Chris Liljenstolpe: Third what Luca said.

Osama Aboul-Magd: From transport POV, the market is really slow so 
deployment is
pretty much nonexistent. This is not an indicator.

Joel Halpern: Helped work on CR-LDP, technically prefer it. That's 
irrelevant,
its not about what is technically better, RSVP won the fight.

Bilel: Agree on one application. Not necessarily so for optical 
transport. For
packet TE, RSVP has one the fight. In optical it is premature. So Packet 
TE it
is overwhelmingly RSVP, but GMPLS it is premature. Folks are building on 
the CR-LDP.
There are other examples of multiple protocols.

Bert: Past potential mistakes are not necessarily an indication of what
we should do in the future. In this case one far outweighs the other.

Chippy: We don't support it because we have no customer demand.

Ludo Practico: We support both and get interest in both.

Discussion to move to the mailing list.

Loa: Confine it to the MPLS list, but we'll send mail to the other 
sub-ip list
informing them about the discussion.


Bert Wijnen
Status and issues with the mpls mibs
-----------------------------------------------
We have lots of MPLS MIBs. Although separately they looks OK, there was 
a lot of
overlaps (TCs and the like, some conflicting). Shows authors not working 
together,
and no cross review of how they play together. No discontinuity timers 
for counters,
or how MIBs relate to each other. etc. etc.
Several issues, including inconsistencies and duplicated uses.
Also, there are uses defined that are not consistent with common usage
elsewhere. Some MIBs have already become RFCs and others have been held 
up in
queue for corrections. There is a draft that attempt to capture the 
relationships
between various MIBs, but this does not do quite enough.  Also, there 
are some
MIBs that are fairly 'all-inclusive' and it is not clear that this is 
always a
good thing. Also, there are differences in the 'tolerance' levels for 
various
MIB compilers and this results in MIBs that do not compile using some MIB
compilers.
We would also like to see better communications between various MIB 
development
efforts. We would also like to see who is implementing which MIBs.
Finally, people should get help for MIBs at mibs@ops.ietf.org or by asking
SNMP/MIB advisor for the working group.  If there is no SNMP/MIB advisor,
get one.

Marcus: We have actually implemented some MIBs only partially.

Bert: The correct way to work through this is to talk about these issues
on the public mailing list so that everyone can benefit from 
understanding the
issues and answers.

Kireeti: Asked if Marcus had tried the TE-WG MIB.

Marcus Brunner: I were actually referring to the LSR MIB.

Vach Kompella: I've had issues with the LDP MIB and we've also implemented
a proprietary MIB that supports a subset of the MIB.

Bert: The LSR MIB is in IESG review at this time.  We had reports
that people are implementing the LDP MIB.


Loa: My impression is that the MIBs have become complicated and
uncoordinated.  My feeling that we still need to think about what to do
next.  It is at least clear that enough changes have occurred since the 
last
set of last calls that another set will be required.



Andy Malis
Status of LDP restart and LDP fault tolerance drafts
Fault Tolerance for LDP and CR-LDP <draft-ietf-mpls-ldp-ft-03.txt>
Graceful Restart Mechanism for LDP <draft-ietf-mpls-ldp-restart-02.txt>
-------------------------------------------------------------------------
Andy: The latest status is that the LDP FT draft was successfully merged
with the Smith (check-pointing) draft.
The LDP Restart draft actually has a different applicability with very
little overlap.  The last call has been completed, George Swallow has
proposed some changes, some minor editing has to be done and then the draft
should go to the IESG.


Sven van den Bosch
Further considerations for Forwarding Adjacency LSPs
<draft-vandenbosch-mpls-fa-considerations-01.txt>
--------------------------------------------------------------
Sven van den Bosch : This is version one of the document, related to LSP
hierarchy 07 WG draft.

The issues addressed is complex resources classes and a new sub-class of 
TLVs
is proposed
Alternatively it could be possible to approach the IS-IS and OSPF wg's and
suggest that they define extensions to the protocols.

Amir Hermilage: Is it the the goal of this draft is to be merged into 
other work.

Sven: The intent is for this to be a separate draft.

Kireeti:  Not sure that all cases of complex resource classes can be 
represented.
Sven:  I'm aware that there is at least one case that his proposal does 
not cover,
but also feels that there is a real need to solve a subset of the 
problem space
that his proposal does address.


Loa: Take this back to the list and make a decision once all the 
implications
are clear.


B Jensen:(University of Wisconsin)
General Summary of Interoperability Testing Results and Experiences
<draft-jensen-mpls-interop-00.txt>
--------------------------------------------
There are interoperability efforts from several organizatios e.g. UNH, AIL,
MPLS Forum etc. There has been private tests in April, NI in May, and then
Supercom. White paper will available  from MPLS forum.
The Draft is key findings from April, test configuration are shown in the
slides.
IP transport, plus L2 and L3 VPN apps (2547/Martini Ethernet), POS and 
GigE plus
some ATM. Has been tested.
Issues found:
  OSPF TE is not universally supported even though required for TE LSPs
  Vendor implementations only support a single distribution mode (DU/DoD)
  Not all RSVP-TE implementations support both FF and SE reservation styles
  Inconsistent use of IP addresses in ERO
  RESV_CONFIRM is not universally supported
  Explicit NULL label is not universally supported

Discussion:
Amir said that he was surprised that the presentation was being given before
there was a white paper presented and said that the issue with explicit NULL
labels is essentially because of a misunderstanding of the standard.

Satoru Matsoshima asked about DU implementations that do not respond to
requests for Labels.

Rahul said that there implementation simply supports all of the possible
ERO IP address usages.

Amir commented on the ERO issue, saying this is critical.

Loa said that the discussion should be continued on the list, thanked
him for the report.


J-P Vasseur
MPLS Traffic Engineering Fast reroute: backup tunnel path computation for
bandwidth protection
<draft-vasseur-mpls-backup-computation-00.txt>
------------------------------------------------------------
P Vasseur: The draft addresses the charter item dealing with recovery
mechanisms and focus on bandwidth protection issues.  The draft proposes
two basic approaches - centralized and distributed. It was pointed out that
a Naive approach - using CSPF to setup backup paths - has two key problems:
it cannot protect the bandwidth and it is possible that no solution can 
be found
even though it can be shown that one must exist (as a result of timing). 
Examples
of real life scenarios were given, in which bandwidth protection is needed.
Bandwidth protection is needed for some traffic in some networks and 
input on the
draft is solicited.

Sven said that he is interested in this work.

Loa suggested that comments on this work should be taken to the list.


Seisho Yasukawa
Extended RSVP-TE for Multicast LSP Tunnels
<draft-yasukawa-mpls-rsvp-multicast-00.txt>
--------------------------------------------------------
Seisho Yasukawa: The draft is about potential extensions for RSVP-TE for 
multicast
LSPs. One of the things we propose in the draft is a grafting mechanism.  A
mechanism like this is needed e.g. for a VPLS service. It is
appropriate  that the multicast specifications should be discussed in 
the working
group because the charter already includes work on the framework for 
multicast.
Proposes that the WG should accept this draft as a WG draft.

Saha asked if the draft required a multicast routing protocol, answer 
was that
no multicast protocol is needed, but a function needed to determine the
the multicast tree.

Loa: This should be taken to the list. We are currently not prepared to take
on new wg documents for multicast, we need a discussion to scope the 
multicast
work within the mpls wg before we do that. That discussion should also 
be taken
on the list.


H.Hummel:
"Hierarchical LSP"
<draft-hummel-mpls-hierarchical-lsp-01.txt>
"O(n**2) investigations".
<draft-hummel-mpls-n-square-investigations-00.txt>
----------------------------------
Heinrich: The motivation for this work is to eliminate the  n**2 problem 
via
partial mesh of elementary tunnels. We have done tests and simulations to
determine precise values for scalability associated with the
use of hierarchical LSPs. Hierarchal LSPs is in scope for the charter by
implication because of the existence of the label stack.
Discussion deferred to list due to time constraints.

Loa:
WG and document status, Questions
---------------------------------------------
19 RFCs, latest is RFC 3270 on diff-serv. Multicast framework on the 
RFC-ED queue.
19 WG docs. 18 individual submissions.
The issue here is that the individual submission are so numerous and diverge
so much. This is a mature WG, and should be more focused.

The wg documents:

5 under MIB doctor treatment.
6 documents under chair/AD (pre-IESG) review before going to IESG.
4 in WG last call. (FT completed just before meeting).
4 work in progress (incomplete).

Meeting ended 11.30 AM.
-- 
     Loa Andersson
     Chief Architect,
     Utfors Research, Architecture and Future Lab (URAX)
     Utfors AB
     Råsundavägen 12
     Box 525, 169 29 Solna
     Office          +46 8 5270 2000
     Office direct   +46 8 5270 5038
     Mobile          +46 70 848 5038
     Email           loa.andersson@utfors.se
     WWW             www.utfors.se