The MPLS WG Archive

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

All,

included are the final notes from the mpls meeting in Yokohama.
"Final" - unless there are further comments ;)

Again thanks to Eric G and Dave for taking notes!

I've also complemented the agenda from meeting to include all
slides that were used. Will be found at:

http://62.119.0.68/~loa/mpls_agenda_for_yokohama.htm

/Loa


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


IETF 54 MPLS WG 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 RFCs 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 anonymizer.
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 Ohta, 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 
operatingunder the assumption that they would be requesting changes.
The draft is called: 
"Use of a reserved label value defined in RFC 3032 for MPLS OAM
functions"

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) band 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 the SNMP/MIB advisor for the working group.  If there is 
no SNMP/MIB advisor, get one.

Summary:

- Main concerns/worries:
  o How do Label Distribution Protocols, SNMP, 
    Manual config, GSMP interact and make sure
    they do not step on each others toes??
  o How are assignments under mplsMIB controlled?
  o Who is implementing all these Mibs?
  o How is the impact on follow up (G)MPLS MIBs?

- Status/Action plan
  o Authors have answered a lot of comments and 
    supposedly know what needs to be fixed.
  o Authors revising MIBs to address comments.
    Sofar I have received a new TC MIB, need
    revisions of all otehr MIBs
  o Then will need to re-review (MIB-Doctor)
  o I want the WG to re-review as well and make 
    sure that you all agree, before it gets approved


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 was 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 once we see the updated MIBs we
will need another round of last calls.



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, since there might be some interdepencies 
betseen the resource classes and the use of backup LSPs without any
assigned bandwidth,

The issues addressed is complex resources classes and a new sub-class
of TLVs 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 Hermelin: Is it the the goal of this draft is to be merged into 
other work.

Sven: I feel it is useful to keep the draft as an overview of 
outstanding issues but that any eventual resolution of any of the 
issues could be merged with other work.

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. Although the 
solution does not work in this particular case, an operator will always
know (by virtue of its resource class specification policy) whether or 
not it is safe to use the proposed solution.



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 their 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 onto 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.