The MPLS WG Archive

["Amir Hermelin" <amir@cwnt.com>]

Loa,
my name is Amir Hermelin, and not Amir Hermilage  ;-). If there's a non-draft edition, please correct.
Thanks.

--
Amir Hermelin                    < mailto:amir@cwnt.com>
Charlotte's Web Networks Inc.     < http://www.cwnt.com>



>-----Original Message-----
>From: Loa Andersson [mailto:loa.andersson@utfors.se]
>Sent: Friday, August 02, 2002 2:51 PM
>To: MPLS wg
>Subject: draft minutes from Yokohama mpls meeting
>
>
>
>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
>
>
>