The MPLS WG Archive

["Mina Azad"<mazad@nortelnetworks.com>]

Title: RE: Draft Minutes from MPLS in MPLS (Minneapolis that is)

George,

You missed my comments on MPLS OAM.
1) My response to Scott's comment on Y.1711 being "in the telephony sense rather than the IP sense" was that all e-mail and previous IETF discussions have been on IP-centric v.s. non-IP centric requirements/solutions for OAM. And Scott conceded.

2) In response to your comments on potential for signaling changes, I said
   In the current version of Y.1711, CV is enabled/disabled by means of configuration only. Y.1711 mentions enabling/disabling CVs via signaling as an ideal solution, but does not mandate it. I also mentioned that there are other mechanisms to enable/disable CVs.

3) On monitoring CV on all LSPs, I pointed out that Y.1711 does not mandate such thing but mentions that ideally, to detect all misbranching and mismatching defects CV must be monitored on all LSPs.

Regards,

Mina

> -----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.
>
>
>
>
>
>
>
>
>
>
>
>
>