The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

All,

please find the preliminary minutes from the DC meeting
included.

Please send your comments to me.

/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
MPLS WG Agenda for the Washington Meeting

November 2004, 9.00 - 11.30

1. Agenda bashing
   Agenda accepted as proposed.
   Scribes: Markus and Dimitri

2. Working group status (20 min)
   - liaison from MPLS & Frame Relay Alliance on RFC 3036
   The MPLS working group has recieved a comunication from 
   the MPLS & Frame Relay Alliance (MFA) on RFC 3036 as it is 
   being progressed to draft standard.
   It was pointed out that IETF and/or its working groups do 
   not enter liaision relationships with any other orgtanizations
   than Standards Development organizations. However, this will
   not stop us from having an open and trustful communication with
   indurial forums like MFA. The technical issue brought up in
   the communication will be discussed in this meeting, and based
   on that discussion a response to MFA will be sent.
   Note: This response were sent November 11 and will be found at
   http://www.cell-relay.com/mhonarc/mpls/current/msg00028.html

   - new RFCs / IESG reviews
   two drafts "draft-ietf-mpls-explicit-null-01.txt" and 
   draft-ietf-mpls-rsvpte-attributes-04.txt have been in AD evaluation 
   a long time, don't know why?
   Alex: they will be IETF last called pretty soon

   A number of docs has been moved to rfc ed queue: congrats to 
   authors/editors. Since the dependencies on other documents are not
   that heavy they will go out as RFC soon

   The mpls bundle draft (draft-ietf-mpls-bundle-04) has been 
   pulled from rfc queue, and taken back to wg for a (hopefully) quick 
   respin, the reasons for this were discussed by Zafar at this meeting.
   A problem here is that several other documents depends on the bundle 
   draft.


   - wg drafts
   <draft-ietf-mpls-lsr-self-test-03.txt>
   This draft is stuck waiting for the lsp-ping draft to progress

   <draft-raggarwa-mpls-rsvp-te-p2mp-01.txt>
   <draft-allan-nadeau-mpls-oam-frmwk-00.txt>
   These two draft did miss the the cut-off date to be published 
   as working group documents, the working groups chairs have 
   sent a mail to the mailing list saying that for "all practical
   purposes the two draft should be treated as working group
   documents.

   <draft-ietf-mpls-bgp-mpls-restart-03.txt>
   "Graceful Restart Mechanism for BGP with MPLS" needs re-spin

   <draft-ietf-mpls-nodeid-subobject-02.txt>
   RRO Node-ID subobject: Jean-Philippe told that an update has 
   been submitted
   
   <draft-ietf-mpls-bundle-04.txt>
   Zafar Ali: Issues with link bundling draft
   After discussion among draft contributors, wg co-chairs and ADs
   it was decided decided that some issues with draft needed to be
   fixed. To tht end the draft was pulled from rfc queue. 
   The scope of this presentation is to outline the issues, focusing 
   on required functionality
   1. scoping of component link id: node vs. bundled te link scope
   2. equivalents of type 4/5 tlvs for ipv4 and ipv6 if_id_rsvp_hop 
      and if_id error_spec objects
   3. recording (and explicit controol) of component interface id
   Zafar described all three issues in more detail.
   Next step: would like wg to close on issues, then discuss solution 
   space
   Adrian ("ccamp co-chair hat on"): Good to do this work in mpls, 
   but it's blocking huge number of ccamp drafts in the rfc queue
   Loa: Just pulled the draft yesterday, don't know yet how long it will
   take to fix it
   Lou: Will submit update on draft as soon as drafts are accepted again
   George: authors should just circulate updated draft and solicit input
   Kireeti: No rewriting planned, only address specific issues and not 
   open up the whole thing
   Yakov: Focus only on changes, not rest of document, wg chairs should 
   structure discussion appropriately
   Lou: Don't add new things, don't reopen old issues, new functionality 
   needs new draft
   Loa: The issues will be dealt with as wg last-call, limited to the 
   issues outlined in Zafars slides
   slides: www.tla-group.com/~mpls/bundling.ppt

3. LDP to Draft Standards

   <draft-ietf-mpls-rfc3036bis-00.txt>
   Ina Minei

   Ina: Since the last IETF work has been done into two areas

  1. produced first draft of the revised specification
	- editorial
	- areas not covered in the document: securing hellos, LDP MTU signaling
	- shutting down adjacencies
	- clarifications: corner cases not spelled out correctly in the original spec
	- errors/clarifications/changes in the pseudo-code (split horizon when doing 	
	  ordered label control)
	
   2. started the operator survey
	- deadline for reply after the ietf
	
   Next steps
	- feedback from the changes made in the document
	- re-submit a version

   Kireeti Kompella: We need to update the IANA section, will propose text to Ina 
   to go into this part of the document.
   Slides: www.tla-group.com/~mpls/3036bis.ppt


   Liaison from MPLS & Frame Relay Alliance on RFC 3036
   Andy Malis
   Andy presented a liaison from MPLS & Frame Relay Alliance regarding 
   the LDP Host Address FEC. He described what the HA FEC is in comparison
   to the Address Prefix FEC.
   Ina's original email proposed to remove host addr fec due to non-use,
   changes to the Address Prefix FEC with a /32 prefix were alos proposed
   Andy summarized the liaison and stated that while the MFA could use the
   Address Prefix FEC with a /32 prefix, the MFA prefer to keep HA FEC
   as is due to implementation plans.
   Slides: www.tla-group.com/~mpls/mfa-communication.ppt

   Discussion on Host Address FEC
   Eric Rosen

   RFC3036 defines FEC element types used to bind labels to address prefixes 
   in routing table the RFC define two FECs (Address Prefix (AP) and Host 
   Address (HA)), other FEC element types will be defined by other protocols
   in early versiions of the LDP specification only AP FEC existed, the HA FEC 
   were included because it was assumed that an LSR must be able to distinguish 
   between locally delivered vs. forwarded packets (constraints of particular ATM
   based implementation).
   The HA FEC has not been used so far, the LDP specification is written so it is
   easy to remove it when we progress to Draft Standard.
   The MFA laim they use the HA FEC in their specification, a closer reading of
   the documents show that they are not using the FEC axactly as specified in 
   RFC3036, in particular it violates section 3.5.7.1 in the LDP specification. 
   The conclusion is that a new FEC has been specified and a new FEC
   type is needed.
   Slides: not yet

   George: Does anybody object to keep the same number for new FEC?
   Andy: Keeping the same FEC type value is fine. But given it's all there in the
   doc, why take it out?
   Kireeti: A Draft Standard means that an implementation has existed for some
   time. New fec does not belong in ds std.
   George: Reusing the FEC type value implies that we first remove it from the
   LDP specification.
   Alex: Based on the discussion here, moving it to separate document is best idea
   Loa: As we don't have an implementation of the HA FEC, we can't move the LDP 
   specification to Draft Standard. Move the new FEC into new doc and  we
   will "reassign" same number.
   Andy: To reassign number requires wg draft accordig to iana allocation process 
   (ietf consensus).
   Alex: Doesn't think proposed standard is required, but will need to check this.

4. P2MP TE (25 min)
      
   Requirements for Point to Multipoint Traffic Engineered MPLS LSPs
   <draft-ietf-mpls-p2mp-requirement-04.txt>
   Sheisho Yasukawa
   
   Sheisho stressed that the scope of the requirement specification 
   is p2mp traffic enginered LSPs only, how the p2mp tree is co,puted 
   is outside the scope of the requirment specification.
   Earlier revision -02 were working group last called, and revision
   -03 included updates accoring the last call comments. Revision -04
   introduced new text to include requirements and clarification originating 
   from the for all solution team issues.
   Thre are till some open issues:
   - variation of lsp parameters on different lsp branches?
   - can a transit (probably branch) re-optimize a sub-tree?
   - what should be the behavior if the tree "re-merges"?
   - can short-term data duplication be tolerated?
   - limits and design targets
   A new version is planned shortly and should be sent to working group
   last call.
   Slides: not yet

   Eric: Because of the way some of the requirements and the motivation for
   the requirements are stated the requirement document becomes more controversial
   than the solution document. It could be discussed if we need this 
   requirment document at all.
   Igor: Do we need to includ a requirmentfor leaf-initiated add/drop
   George: I'm opposed to it. Complete solution needs more work elsewhere.
   If such requirements exists, they need to be captured somewhere else.
   Rahul: The solution assumes that all leaves are known. Application use will be 
   defined elsewhere.
   Yakov: The requirement document should state that some issues are outside the 
   scope of the requirment document upfront. This needs to made very clear.
   Seisho: Will update the document according to the discussion of the scope
   of the document.



   Solution
   Extensions to RSVP-TE for Point to Multipoint TE LSPs
   <draft-raggarwa-mpls-rsvp-te-p2mp-01.txt>
   Dimtri, Rahul, Seisho

   The extensions to RSVP-TE for traffic engineered p2mp LSPs has progressed
   since the meeting in San Diego and a merged solutions document has been
   created. This document will be published as a working groupd ID after this 
   meeting.
   The state management issue has been solved by means of <sub-group orig ID,
   sub-group ID>.
   Outstanding issues are:
   a) style usage
   b) p2mp sender_template obj and filter_spec obj encoding specifics
   c) review re-merge/cross-over conditions
   d) re-optimization
   e) sub-ero compression re-organisation
   f) stitching mechanism detail
   Next steps: revision -01 will be submitted after meeting as wg i-d; 
   for revision -02 the organization of the document will be reviewed and
   a terminology section included.
   Slides: www.tla-group.com/~mpls/p2mp-solution.ppt

5. MPLS OAM (20)
      <draft-allan-nadeau-mpls-oam-frmwk-00.txt>
      Tom Nadeau and Dave Allan

   Tom: The first version of the document wer publsihed for the San Diego 
   meeting and accepted as a working droup document. Will be published 
   after this meeting.
   The document provides an overview of the FCAPS functionality and the 
   required data plane tools.
   Authors asks for working group input.
   Slides: Not yet

6. P2MP LSP Ping (10 min)
   Detecting Data Plane Failures in Point-to-Multipoint
   MPLS TrafficEngineering - Extensions to LSP Ping
   <draft-yasukawa-mpls-p2mp-lsp-ping-00.txt>
   Adrian Farrel

   This document extends the techniques described in [LSP-PING] in order
   that they may be applied to P2MP MPLS TE LSPs. This document stresses
   the reuse of existing LSP Ping mechanisms as such reuse simplifies
   operations of the network.
   Since Traffic Engineered P2MP LSPs are at lest as vulnerable to data
   plane failures a mechanism to verufy livesness of the data plane is 
   needed. The P2MP tree brings new requirements for verifying data plane
   liveness. On obvious candidate to be used to create a tool for this 
   is "LSP ping". The draft does not change the LSP ping as it exist, but 
   describes extension to the LSP ping techniques so that they may be 
   applied to P2MP MPLS TE LSPs
   Several issues needs to be discussed and questions need to be
   answered, e.g.:
   - is this the right approach, what are alternatives?
   - how to handle scaling
   - additional requirements?
   - what should happen to this draft?
   There is no consensus yet on this approach, we'll discuss on the mailing
   list until next meeting to see if we can make it a working group document.
   Slides: not yet


7. LDP/IGP Synchronization (10 min)
   <draft-jork-ldp-igp-sync-00.txt>
   Markus Jork
   In networks depending on edge-to-edge establishment of MPLS
   forwarding paths via LDP, blackholing of traffic can occur in
   situations where the IGP is operational on a link and thus the link
   is used for IP forwarding but LDP is not operational on that link for
   whatever reason.  This document describes a mechanism to avoid
   traffic loss due to this condition without introducing any protocol
   changes. This means that along the IP shortest path from one PE 
   router to the other, all the links need to have operational LDP 
   sessions and the necessary label binding must have been exchanged 
   over those sessions.
   Reasons for the a missing LDP session could e.g. be a configuration
   error.
   The draft need to cover interaction with TE tunnels better and it 
   need clarify that it is applicable to targeted LDP.
   The discussions focused on sorting out the concepts and the scope
   of the docuemnt. The differences between IGP and LDP convergence 
   were discussed.
   It was concluded that we need to discuss both content and the purpose
   of this document if we are to accept it as a working group document.
   Slides: www.tla-group.com/~mpls/ldp-igp-sync.ppt

8. Encapsulation of MPLS over (10 min)
   Layer 2 Tunneling Protocol Version 3
   <draft-townsley-l2tpv3-mpls-02.txt>
   Mark Townsley
   The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a
   protocol for tunneling a variety of payload types over IP networks.
   This document defines how to carry an MPLS label or label stack and
   its payload over L2TPv3.

   Yakov Rekhter: there is no reason to accept this as a WG document,
   - because we have enogh methods to transport MPLS over an IP core
   Eric Rosen: This is really a no brainer - there is nothing specific here 
   to do this and if this is just to make people being interested in the 
   topic I don't see the reason to prefer one method or the other.
   Peter Lothberg: Speaking for isp using l2tp. Useful to add mpls into it as 
   its just another l2.
   Jeff Young: Support in making this a standard of this to interoperate.
   Loa: Rename the draft-townsley-mpls-l2tpv3 to indicate it is intended
   to be mpls work item, take the discussion on the mailing list and come back 
   with a resolution for the next meeting.
   Slides: www.tla-group.com/~mpls/mpls-over-l2tpv3.ppt 


9. Meeting closes
_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls