The MPLS WG Archive

[George Swallow <swallow@cisco.com>]

                       MPLS WG Meeting Minutes  

                  IETF #53 Minneapolis, March 2002
 
 
Tuesday March 19 2002, 9.00 AM - 11.30 AM
 
  George introduced Loa Andersson (loa.andersson@utfors.se) as the new
  WG co-chair.


Agenda bashing
 
  Loa introduced the agenda noting the addition of a discussion on the
  ITU Liaison on the subject of MPLS OAM to be lead by Scott Bradner.
 

LDP to Draft Standard  -  Loa Anderssen
 
  Loa gave an update on status and presented representations.
 
  In order to advance to Draft Standard, we need to identify those
  features of LDP which are actually implemented and in use.  To that 
  end we would like to get information on all implementations of LDP.


Report on the FT/Graceful restart for LDP  -  Andy Malis

  Andy updated the group on the progress of integrating the two
  proposals.  Good progress has been made, but there is one major
  technical issue to resolve.  If sequence are carried in both 
  schemes this will simplify the implementation if someone needs 
  to build both schemes. It will also make it easier to for the 
  two schemes to interoperate.  On the downside, it causes the
  simplier solution to be more complicated.  Simplification was the 
  original motivation for the proposal

  George (chair): Interoperability is important.  If that can be 
  achieved, we should go for it.
 

Detecting Data Plane Liveliness in RSVP-TE  -  Kireeti Kompella
  <draft-pan-lsp-ping-02.txt>
 
  Kireeti presented the draft and closed with the comment that
  although he would like to see it become a WG document eventually, he
  suggested that perhaps people should just write some code for now.

  George (as a co-auther and chair) suggested that it would be good
  for the workgroup to know what proposal folks were trying to
  converge on.

  He then asked the room.  There was consensus to make a WG document.
 

Fast Reroute Extensions to RSVP-TE for LSP Tunnels  -  Ping Pan
  <draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt>

  Ping gave an overview of recent updates to the draft.  George
  commented that the draft was pretty much technically stable at this
  point but would benefit from an editorial scrub.
 

MPLS Traffic Engineering MIB for Fast Reroute  -  Riza Cetin
 <draft-cetin-mpls-fastreroute-mib-00.txt>
 
  Riza Cetin gave an overview of the draft.

  George: Should we use this as a basis for the FRR MIB in this WG?
  Room: Looks like consensus.
  George:  Should it be adopted as WG draft?
  Room: Looks like consensus.
  Bradner: Charter process check. Is this in the charter?
  George: Yes.  Fast-reroute is in the charter.  A MIB for this 
  is therefore appropriate.
 

Backup Record Route for Fast Reroute Techniques in RSVP-TE  -
 Stefan de Cnodder 
  <draft-decnodder-mpls-ero-rro-fastreroute-00.txt>
 
  Stefan presented his draft and asked that it be accepted as WG
  document.


 George (not as chair): I am reluctant on both pieces presented. 
 In the backup RRO (BRRO), a lot of management information is being 
 moved around in RSVP.  With regard to the backup ERO (BERO), we are
 working on mechanisms for doing FRR in a unified way.  I wouldn't
 want to add this to the standard right now.  We might want to 
 move this around in experimental track for now.
 
 Q1: If you have a failure, is there a signaling delay?

 Stefan: ERO is optional. If nodes cannot follow the path suggested, then 
 they can take alternate one. If there is a failure, then you can fall 
 back on the original path.

 Q2: BRRO is important for the MIB. Customers are interested in seeing 
 all detours in one place. Otherwise we have to go along all PLRs along 
 path.

 Ping: This same information might be encapsulated in RRO. Also, should 
 get more operator feedback before we change the RSVP protocol.

 Yakov: This approach will not work well (or at all) with inter-area TE. 
 Head end needs to have all link state information, so this can become a 
 major bottleneck.

 Tom: Need more experience from operators to see if they want more 
 information in RSVP or want to just contact each node to get FRR 
 information.

 George: Need more experience with this approach and feedback from 
 operators before we can adopt this document.
 
 
A method for an Optimized Online Placement of MPLS Bypass Tunnels  -
 Jean-Louis le Roux
  <draft-leroux-mpls-bypass-placement-00.txt>

  Jean-Louis presented his draft.  He then asked that this be accepted
  as a MPLS WG document.  There was no consensus on this as the work is
  in a fairly early stage.

  George commented that he felt that this was important work and
  encouraged Jean-Louis to continue it.
  
  Yakov: CCAMP is working on protection restoration.   The issue of shared 
  resources are being addressed there. There may be an overlap between both 
  pieces of work.

  George: These mechanisms can be made generalized. Our charter 
  is to do specific MPLS work. (to Jean-Loius) Make sure that your 
  work is coordinated with CCAMP.
 

A Packet 1+1 Path Protection Service for MPLS Networks
 <draft-nagarajan-ccamp-mpls-packet-protection-00.txt>
 
 Akber Qureshi

 Akber: Presentation.

 Loa: This seems almost too good. Could you address the drawbacks
 associated with this proposal. Could you also address why this
 proposal is MPLS-specific. This looks like something done in the
 mid-80's for telephony.

 Akber: This is selection based on the packet level. This is different 
 from traditional 1+1 because you are creating both as active and 
 selecting one based on an identifier. This scheme is targeted towards 
 services that have QoS requirements. If you look at other schemes that 
 use a sliding window scheme, you can tell which next packets are 
 accepted. The size of that window depends on how many packets you can 
 process. 

 Loa: I think we have to discuss this on the list a bit more. On the 
 drawbacks: cost is double-bandwidth allocation which might be an issue 
 for a provider who has to book 2x.

 Akber: The cost with any 1+1 scheme is 2x booking.

 Mina: Mentioned that similar work is going on in ITU study group 13 for 
 protection switching. There is a similar proposal: Y.1720.

 Akber: You need OAM packets to be sent if you are doing QoS to detect 
 failures.

 Mina: OAM are two different things. That doesn't mean that protection 
 switching will not work.

 Q1: How will this work if part of the net is going 1+1 and the other not.

 Akber: The 1+1 is done on a segment basis, but maybe not end-to-end. You 
 can do part 1+1 in the network.

 Q2: Do you envision this as part of some MPLS service to guarantee 
 bandwidth or packet loss.

 Akber: The benefit of the select is that you can have no packet loss. 

 Q3: Intriguing proposal. How can you trouble ticket failure with this 
 approach?

 Akber: From an egress point of view, it is not detecting any failure here.

 Q3: If something breaks, but the service servives, want to trouble 
 ticket. The order of the detection can be different from protection.
 Bradner: I think this is a good demonstration of why we shouldn't do 
 this. Technical presentations should not be done because of time. We 
 need to do this on the list BEFORE the meeting so that we can discuss 
 only open questions/issues at the meeting.

 George: At this point, we have exhausted our time. Take it to the list.
 

Further considerations for Forwarding Adjacency LSPs -
 Dimitri Papadimitriou:
 <draft-vandenbosch-mpls-fa-considerations-00.txt>

 Dimitri: Presentation.

 George: I think that this work is important to get out to the community. 
 We are always open to enhancing existing work, but we need to figure out 
 exactly which things you want to consider doing and see how it fits 
 into the charter.

 Dimitri: Since the existing MPLS document has passed last call. Should 
 we open an new document?

 George: We don't want to just do a V2 of forwarding adjacencies. We need to 
 examine what further functionality is required by the community.

 Dimitri: We had a list of issues seen by the community today. Is this 
 list complete enough today to do work.

 George: We need to understand if this work is okay to stand on its own 
 and then determine if these all need to go into the same draft or into 
 multiple ones. First step: check for interest in community, second: see 
 if it fits into the charter.
 
 
Hierarchical LSP
 <draft-hummel-mpls-hierarchical-lsp-00.txt>

  Heinrich Hummel
 
  Heinrich presented his draft.  In the presentation he noted that his
  ideas had evolved beyond what was captured in the first version.  He
  asked that members of the workgroup look for his updated draft and
  requested that it be a subject of discussion on the maillist.
 
  George said that he would like to see more of the motivation and
  requirements behind the draft.  Heinrich replied that this had been
  discussed in other workgroups, but that he would also summarize and
  continue the discussion on the MPLS list.
 

RSVP-TE Extension for IPv4/IPv6 Dual Stacking PE under IPv4 MPLS 
 Core Environment  -  Hiroki Ishibashi
  <draft-ishii-rsvp-te-ipv4-ipv6-extension-00.txt>
 
 Hiroki: Presentation

 George pointed out that there is already a means of signaling the
 contents of an LSP with the PID.  There already exist ethertype
 values for IPv4 and IPv6.
 
 Francois: I think that you know that ENGTrans working group that talks 
 about Ipv6 over a Ipv4 backhone (with MPLS or without). There is already 
 work being done elsewhere. The existing work is more general because it 
 works with RSVP-TE and LDP, and covers routing and signaling aspects. I 
 don't see why we need something more than what is already being done 
 without extensions to MPLS protocols.
 
 Hiroki: Don't want to talk about routing issue. EngTrans need miultiple 
 extensions for BGP, but this approach doesn't need that. This approach 
 doesn't talk about routing extensions.
 
 Francois: Need to talk about routing. Can talk about BGP tunneling 
 approach as well. Don't see why we need to change MPLS signaling to 
 forward Ipv6 packets over MPLS.

 Hiroki: I just want to augment the egress process of PE routers.

 Loa: It appears this may overlap with work going on elsewhere in the 
 IETF.  I recommend that you go back and see if there is a delta to
 add this here after you check with those working in the other space.

 

Issues with MPLS OAM  -  Scott Bradner
 
 Scott introduced the topic:

 There has been a discussion on MPLS OAM recently (CCAMP mailing list). I 
 want to talk about what the next steps to take are. We (IETF) received a 
 liason statement from the ITU in February requesting two LSP label 
 values to support the ITU document Y.1711 (MPLS OAM). This describes OAM 
 in the telephony sense rather than the IP sense.
 
 We have had two discussions going on. First, is this area of Telephony 
 sense interest to the IETF. The consensus is reasonably there, but that 
 there is more interest in dealing with MPLS in the arena of transporting 
 IETF (CCAMP, MPLS). There are tools that existing in CCAMP/MPLS for 
 addressing this.
 
 I sent a message asking for direction to the mailing list. Options: here 
 is your label values ITU, or should we work together on this with ITU, 
 or should we work on it alone?
 No votes for the latter.
 
 A couple people noticed that 1711 has hints that it itself is not a 
 standalone concept. To fulfill the concepts it will require changes to 
 other IETF protocols (BGP, LDP, RSVP). This is a little bit confusing. I 
 want to send a lieason statement back to ITU and ask for specifics of 
 what they want to do in this area. Talk to Brian M. about what to do. We 
 cannot go in and ask the ITU for what they want to do for now and 
 forever, but we need to ask about the implications of working together 
 on this or handing off LSP labels. We need to understand what the 
 implications of doing 1711 (what protocol modifications are required).
 
 [A lengthy and somewhat heated discussion ensued.]
 
 Scott asked for a show of hands to get a feel for the consensus of
 the room.  Below are his three proposals and the WG response.
 

 1.  IESG/IETF tell IANA to approve draft-ota as a proposed standard 
     to make number assignments.
 
     5 hands.
 
 2.  Suggest that the ITU play with their solution and see what 
     market does.
 
     Some support.
 
 3.  Send liason statement asking for further clarification asking 
     for details of their current plan.

     Clear majority.

Scott said that such a liaison statement would be sent.