The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Hi George,

I have the following comments on the minutes.

1) I think you need to mention that draft-pan-lsp-ping-03.txt was presented instead of draft-pan-lsp-ping-02.txt and that the agenda was wrong regarding this draft.

2) Regarding the OAM discussion, the ITU has asked for 1 reserved label not 2 labels.

Yours,
-Shahram

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Monday, April 22, 2002 3:19 PM
> To: mpls@UU.NET
> Subject: Draft Minutes from MPLS in MPLS (Minneapolis that is)
> 
> 
> 
> 
>                        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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>