[mpls] (no subject)

[George Swallow <[e-mail]>]

IETF 62                 MPLS WG Meeting            March 9, 2005   
----------------------------------------------------------------

  Chairs:  George Swallow <[e-mail]>
           Loa Andersson <[e-mail]>

  Scribes: M.Morrow, M. Eubanks


Agenda Bash

I.   WG Status

   New RFCs:

      RFC 3988  MTU Extensions for LDP
      RFC 4023  Encaps MPLS in IP or GRE

   In IESG Review:

      ietf-mpls-bundle
      ietf-mpls-rsvpte-attributes
      ietf-mpls-nodeod-subobject-05
      ietf-mpls-bgp-mpls-restart
      ietf-mpls-explicit-null (approved)

      Comments:

      A. Farrel - Fast track for RFC process would be welcomed 
                  for the Bundle draft

   Working Group Drafts

      soft pre-emption (ver -04 in pipe)

      Comment:
 
      J-P Vasseur -  Should publish -04 next week for pre-emption 

      mpls over l2tpv3 (new)

      LSP-Ping - Last Call after this meeting

      LSR-Self-Test - Last Call after LSP Ping 


II.  Incoming liaisons:

   G.motnni from ITU-T SG 15 (Steve Trowbridge) 

      Loa:     Apologized for chairs dropping the liaison by accident
               (thus no response)

      Steve:   Genoa meeting, editor MPLS Transport - too much included;
               transport NNI aspects of MPLS itself as transport
               technology - was not purpose of the document - should
               be shorter document and narrower in scope Next meeting
               is in May (ITU-T)

      Monique: Cisco pointed out problems with draft and liaison
               needed to be done

   MFA: Liaison Relationship with IETF

      Loa:     The IETF already has a liaison relationship with the
               ATM Forum.  The IAB wants to await outcome of proposed
               merger of ATM Forum and MFA before responding.

      A. Malis: Merger has to be approved by written vote by both
               existing orgs and still in progress (end of Mar
               termination of voting period);


III. LDP to Draft Standard  (Ina Minei)

  New rev since last IETF draft-3036-bis-01

  Removal of host address FEC proved to be a significant change
  - Thanks E.Rosen and A.Malis for resolution of issue
 
  There were a lot of responses from the operational survey.  Thanks
  to the participants, and to Scott Bradener for being the anonymizer.
  A new draft based on the survey results is available:
  Draft-minei-ldp-opertal-exper-00.txt

  A new version of 3036 bis will be posted soon, and this should be
  ready for last call.

  There also needs to be an implementation survey, and we will be
  working on that.


IV.  Pt-to-MP Signalling Req Draft (S.Yakusawa), pt2mp-sig requirement

  Rev -04 
      Removed application scenarios
      Remove (and apologized for) offensive remarks about PIM
      Made the choice of signaling protocols less constrained
      Renamed draft "signalling" 

      Resolved 3 of the 5 outstanding issues 
       1) Variation of LSP parameters is not allowed
       2) transit LSR's can re-optimize a sub tree
       3) clarified case of tree re-merger to prevent egress data 
            duplication

      Two remaining questions and issues:
        1) Can short-term data duplication be tolerated
        2) Absolute limits and design targets
             number of recipients
             number of branch points
             rate of Join / prune
             rate of change of tree topology

  Seisho proposed that the remaining questions be resolved through
  discussion on the list.  Draft to be complete for last call in May
  or June.

  Loa: Preferable to have ready in May so that a last call can be
  completed before Paris.


V.  Extensions to G/RSVP-TE for P2MP TE LSP's  (D. Papadimitriou)
      draft-ietf-mpls-rsvp-re-p2mp-01

  Terminology adapted to requirements doc;
  Document structure has been reorganized.

  Open Issues:
     1) Style usage  (SE vs FF style)
     2) Review text for re-merge/cross-over conds
     3) Re-optimization (requires consensus whether re-opt may be done
           on a P2P sub-LSP and / or sub-tree basis)
     4) Pruning (deletion) and sub-ERO compression reorg
     5) Stitching mechanism - c.f. CCAMP

 Discussion:

    George:    Right now there are 3 different methods for tearing down 
               an LSP. This seems unnecessarily complicated.


    Rahul:     Point well taken.  As you know, we had a huge number
               of authors. It needs to be pruned down on the mailing
               list.


VI.  Detecting P2MP Data Plane Failures (A.Farrell)
       yasukawa-mpls-p2mp-lsp-ping

      Need simple and efficient mechanisms to detect data plane
      failures in P2MP MPLS LSPs

      Reqs:
        Verification of reception at recipients
        Discovering p2mp topology
        Objective is to build on top of LSP Ping
          need to introduce RSVP P2MP session sub-TLV

      Revision 01 has not changed very much. The biggest was that we
      limited the choice of traceroute destinations to all, or one.


      Request for WG

      Rahul:   The draft tries to limit the ping to a subset of
               the recipients?

      Adrian:  Sub-set permitted in sub-set 1 or all (target
               individual recipient or whole tree)

      Rahul:   If I have a tree with a thousand egresses then I am not
               sure that that solves my problem.

      Adrian:  Issue is with problem statement - may be need to be a 
               separate draft

      George:  Leave it together for now - if it gets too big then
               separate


VII. Component Link Recording and Resource Control for GMPLS Link 
       Bundles  (Zafar Ali)
         explicit-resource-control-bundle-04

  This started in CCAMP at IETF 57.  People found issues with link
  bundling.  These were discussed and it was decided that this should
  be pursued by the MPLS WG.

  Motivation : TE Link Bundle resources are identified by TE Link ID,
  Component interface ID and Label value.

  RFC3209 allows for label recording, component recording would also
  be useful. RFC3473 allows for label selection; explicit component
  selection would be useful for applications like LSP splicing and 
  SRLG diversity.

  Therefore the RRO and ERO should carry component IDs.

  We think that there is general agreement on the requirement and the
  solution, and would like to have it adopted as a WG doc.

  Loa: (after show of hands who read; who believe should be a WG doc)
       That's pretty good support, so we will take this to the list.


Loa: Meeting adjourned - see you in Paris 



========================================================================
George Swallow             Cisco Systems                  [phone]
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719



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