Subject: [mpls] Detailed Minutes

From: George Swallow <[email-masked]>
Date: Tue, 07 Sep 2004 11:53:52 -0400

Giles took really great notes.  I added most of the details not included
in the offical minutes for anyones entertainment.

...George

========================================================================

Multiprotocol Label Switching Minutes - IETF60
----------------------------------------------

WG status (Loa & George)

  Mail list - has been moved to the ietf server.  We've also changed
  maillist administrators at this time.  Thanks to Eric Rosen for
  serving us so well and so long.  And thanks to Eric Gray for taking
  this on.
  
  Four new RFCs (all MIBs).  RFCs 3811 - 3815.
  
  Various drafts on the RFC editor's queue.  No real problem per se.
  Draft editors - please take care with refs to other docs (esp docs
  you don't control and normative refs).  Some refs that were said to
  be normative weren't etc.  Refs are most common reason for getting
  stuck in the Q.
  
  MTU signalling doc got stuck because of over-ambitious author (added
  RFC editor's note himself).  Need to verify that we got the RFC
  editor's note correctly.
  
  Author, chairs, and ADs will be meeting to sort out comments on MPLS
  over GRE.
  
  A respin needed on LSP ping.  Other documents including LSR
  self-test depend on this.
  
  ATM/FR LC MIB doc is in MIB-doctor review.
  
  Ina Minei has taken on the task of getting LDP to draft standard.

MPLS OAM Framework
draft-an-mpls-oam-frmwk-00.txt

Tom Nadeau and Dave Allen

  An OAM framework was added to charter a few meetings back.  Tom and
  Dave had been active in that area so were asked to have a go.  This
  is initial output.
  
  The aim is to keep the scope down and describe circumstances where
  data plane tools would facilitate addressing FCAPS issues.  Since
  the draft is a framework, it is intended to be technology agnostic.
  Specific tools are not discussed.  Each of the topics in FCAPS will
  be addressed.  The document currently covers the following.
  
  Fault Management - enumerates potential MPLS forwarding problems and
  explores where data plane tools can assist in detection and
  diagnostics - how do you isolate the fault and take failed resource
  out of service.  Really looking at TTL mechanisms.  There is some
  discussion of availability criteria but this could use some fleshing
  out by providers.
  
  Config - using data plane tools to verify config.
  
  Admin in future.
  
  Perf - extracting counts etc.
  
  Security - can tools be abused?  How to prevent this.
  
  Next steps are to adopt this as WG draft.  The authors will continue
  to work on security and administative issues.  George said it was
  inappropriate to poll the room for support to make this a WG
  document since the draft did not make the cut-off.  So take to list
  after the meeting.

P2MP requirements
draft-ietf-mpls-p2mp-requirement-03.txt

Seisho Yasukawa

  This draft has gone through an initial WG last call.  This revision
  is intended to address those comments 

  Not considering routing based or multicast MPLS here.
  
  Further requirements issues were raised by the P2MP design team (see
  next draft below) that need to addressed in this draft, including:
  
  1) are all leaves/branches subject to same LSP parameters?  Esp
     important inter-domain.
  
  2) How do we do re-merge and cross-over?  Issues with duplication.
  
  3) How does this scale.  Is core of network so scaling different to
     pure IP multicast.  Hopefully tree is more stable than in IP.
  
  4) Partial tree reoptimisation is important - but can cause
     duplication.
  
  5) What if path message gets fragmented downstream (as it grows as
     it goes)?  Don't want to rely on IP fragmentation - so need to
     handle in control plane.
  
  6) should we avoid replication on MPLS LAN interfaces?
  
  Next steps:
  
  Revision 4 - will add the new well understood requirements.
  
  Authors will ask list about those that are not well understood.
  
  Then hopefully will produce revision 5 as final rev. and put into WG
  last call.

  George - Speaking as chair
  
  The draft needs to be revised to both clarify and narrow the scope
  to P2MP traffic engineering.  The draft should only be about
  requirements, references to RSVP should be minimal if not completely
  expunged.  Requirements draft is causing consternation in IETF
  multicast groups.  People are upset by statements that can be used
  without a multicast protocol.  This is a directive not a comment.
  If you don't do some work this won't make it through the IESG.
  
  Eric - I have some fundamental problems with this doc that I've
  stated on mailing list.  None have really been addressed.  Charter
  says requirements for TE to P2MP LSPs.  Doesn't say we need to be
  able to set up explicit routed P2MP LSPs using RSVP-TE.  TE is a lot
  of different things (explicit routing, FRR, constraint based
  routing, guaranteed b/w).  It's not clear that all these things
  create the same requirements for P2MP.  Explicit tree doesn't need
  PIM, but PIM might fit in well for FRR (based on unicast FRR).
  These questions would seem to be in scope of the WG charter.  Also
  multicast groups have other requirements for protocols which build
  multicast distribution trees.  Most aren't considered here.  May not
  be reqirements for this application, but need to be addressed.
  E.g. multicast guys are serious about having large numbers of
  receivers and changing very fast without loading root of tree.
  Depending on what you think the goals are you might have a very
  different soln.
  
  Loa - to summarise.  We need to be clear about the scope of the doc,
  and we need feedback from the multicast community.
  
  Eric - I've heard people say "this doc is only about content
  distribution so why are you talking about large numbers of
  receivers".  But the doc doesn't say that.  If it was called
  reqirements for content distribution that would be fine, but this
  seems to be aimed at generic reqirements (yet has a long way to go
  before it gets there).
  
  Adrian - many of the points Eric has been making became clearer to
  authors during first stab at solution.  We do have a list of
  questions including the extent of the rate of change of leaves and
  attend to address this.  I have a concern that the only person who
  commented during last call was Eric.  If we spin this again and get
  the same rate of comments we're in trouble.  Would be helpful to get
  comments from the chair during last call.
  
  George - Eric had made most obvious comments.  Also matter of time.
  Other stuff has occured during this meeting.
  
  ? - what do you mean by multicast MPLS being out of scope.  are you
  excluding label distro for multicast packets, or are you excluding
  multicast content?
  
  Seisho - we're not excluding multicast packets from being
  transmitted over P2MP LSP.
  
  ? - so it's intended to carry multicast traffic?
  
  Seisho - Yes.
  
  Yiqun Cai - problem I have is that this is free-floating.  Defining
  TE reqirements without saying what framework this is and what it
  provides transport for is like defining TCP without defining
  datagram service.  I don't think anyone will use this to carry IPMC
  over an SP core.  So what is the req with or without TE.  Needs to
  have normative refs, but no doc exists for that.  So hard to
  evaluate something free-floating.
  
  Seisho - can't understand your point.
  
  Albert Tian - still a bit confused as to what is excluded.  What
  do you mean by Multicast MPLS?
  
  Seisho - eliminating possibility of doing setup based on multicast
  IP address.
  
  ? - good to do the work.  But consternation being caused by the fact
  that the transport service and the packets that it will carry are
  likely to be multipoint forwarding mechanisms.  So you still have
  the same problem space as multicast even if you don't call it that.
  You need to be able to describe the reqirements. of the content that
  the service will end up carrying.  Once you start talking about that
  things like tree size/tree dynamics will come into play.
  Presentation in MBONED WG yesterday clarified this.  Once we started
  calling it multicast then people woke up.  What would be useful is
  to present this stuff in MBONED and PIM WGs.  Will have an effect on
  PIM at edge if you want to carry multicast over this.
  
  Rahul - 7 points were made.  All good points.
  
  1) Reqirements does talk about applications - e.g. L2 multicast, L3
  multicast.  If you think they aren't complete then let us know.
  
  2) Reqirements for interaction between multicast protocols and P2MP
  TE need to be in there.
  
  3) multicast community hasn't been involved.  That's being
  overstated.  First of all over last year or so have received
  comments from some multicast folks.  Also solution draft on PIM-SM
  interaction with P2MP TE was presented 3 IETFs ago in PIM.  Got
  feedback then.
  
  Dave Meyer - Over in MBONED we're trying to put infrastructure in
  place to stop protocol WGs going off on their own.  This wasn't
  really vetted in MBONED.  Need to facilitate communication between
  disparate groups.  No blame - is just a structural issue.
  
  Loa - point taken.  Number of cross-WG things to co-ordinate.  This
  is one of them.  No intention to sneak this through.  Thanks for
  bringing it to our attention.

P2MP merged solution document
draft-raggarwa-mpls-rsvp-te-p2mp-00.txt
  
Dimitri Papadimitriou, Rahul Aggarwal & Seisho Yasukawa

  In Korea there were two drafts that were far apart.  Alex asked that
  there be one draft, merging the two and that a design team be
  formed.  together.  That happened slowly at first, but what happened
  once people started focussing on the problem were able to find the
  right solution.  This draft represents both the consensus and
  captures the remining differences of the original two drafts.  While
  it is far from converged much progress has been made.
  
  Open issues (partial list):
  
  1) state management.  Intent is to disambiguate message size.  ID
     still needed for sub-tree reoptimisation.
  
  2) re-optimisation.
  
  3) re-merging.  Would like to point out issues under discussion -
     data plane and control plane issues.  Identified a case for this.
  
  4) Recovery.  Need to expand on GMPLS applicability.

  The authors will be requesting this be a WG document after this
  meeting.

Source Routed MPLS LSP using Domain Wide Label
draft-tian-mpls-lsp-source-route-01.txt

Albert Tian

  This draft introduces global labels as a means of source routing or
  loose source routing a packet in an MPLS network.  If each
  destination of interest (say all of the loopback addresses used as
  router-IDs) had a label which was both globally known and globally
  used by all routers, then one could source route a packet by
  stacking up labels for each of the routers in the source route.
  This technique could be applied to fast reroute.
    
  Some concerns over maximum stack size.  Probably use loose segments
  in the stack to reduce size of stack.  Also can prove that for link
  protection need max 2 labels for unicast and 3 for multicast
  (assuming symmetic metrics).  For node protection can be worse.
  Most implementations allow you to have a big stack (it's just
  overhead).  Deeper stack only needed at head-end.  As you go down
  the path you're just popping and swapping.
  
  LDP extn. - a range of labels needs to be reserved for DWL.  Can be
  identified by the range and agreed throughout the domain.  Need
  domain wide binding.  If revieved label is DWL then allocate the
  same one and propagate upstream.
  
  How to allocate:
  
  sub-range per LSR.
  
  can do manual allocation via config (so add a line to each LSR to
  assign a sub-range).  Could automatically derive from IP addresses
  (nice chunks).  Or could use a central server.  Pedro suggested LDAP
  for this.
  
  Note that if you don't need strict hops you just need 1xDWL per
  router (for loopback).
  
  PHP is an issue.  but can overcome if you want it.
  
  Need mechanism for strict hops over high cost links (as OSPF follows
  IGP).
  
  People always have security concerns with source routing.  Note that
  DWL only makes source routing easier (for user and hacker).  it
  doesn't actually facilitate it.  So don't accept labels from outside
  trusted domain.
  
  Albert requesting WG status as he believes this fits in MPLS charter.
  
  Eric - sometimes a WG goes on too long.  I hardly know where to
  begin.  The idea of the MPLS label being local was so fundamental to
  the MPLS specs that we could spend the rest of our lives looking for
  places where this might break.  At very least you need to spend time
  on an impact statement.  If you like paradigm of forwarding on
  global info suggest a look at RFC792 (explains how to do that).
  Problem with domain-wide labels is that the notion of domain isn't
  well defined.  What if a router is a member of two routing domains?
  Could have conflicts there.  Unlike ATM the label space isn't
  necessarily interface specific so you don't necessarily know which
  label space the packet is for.  Seems to be going back down the path
  of "signalling creates too much overhead so let's statically
  provision".  Scope of getting label from far end of tunnel doesn't
  require new architecture.
  
  Yakov - (1) outlined alleged benefits of this proposal.  But where's
  slide outlining drawbacks?  Are you saying none or some? (2)
  provisioning/IP/centralised server.  Let's go to third point.
  Should have several options for this - RADIUS, LDP (perfect choice
  as this is LDP), BGP (for those who don't like LDP or RADIUS).
  
  Albert - issue of how to ensure uniqueness is definitely part of
  drawback.  You don't lose something for nothing.  Is more of admin
  overhead, but gives you more control and more troubleshooting
  ability.  Stated the other way - if you use a full mesh of tLDP then
  that's a big protocol overhead.  Full mesh of TCP connections.  100s
  or 1000s of copies of the same info so clearly can optimise that
  out.  Can explore more on how to achieve the uniqueness of label
  allocation.  But that's an independent issue.
  
  Adrian - 2 points.  (1) need to consider control/data ratio with a
  large label stack and very little data.  (2) DWL is interesting
  concept - note that labels can fit in 32 bits so would be handy to
  have a structure, e.g. break up into classes or something like that.
  What was it Eric said about RFC792?
  
  JP - unfortunate that Eric, Yakov and Adrian run faster than me.  But
  I'm faster than Luca! You need to spell out the limitations. We don't
  see those in live networks.  As Adrian mentioned overhead is an issue.
  Finally use of loose hops, but if you do that you lose control at the
  head end and lose advantage of easy troubleshooting.
  
  Albert - there's another draft coming up. If you use explicit paths
  as repair paths then you can prove that loose paths won't change if
  you calculate them properly.
  
  JP - not true in terms of b/w sharing etc.
  
  Albert - if you have b/w requirements then yes.  But LDP traffic
  doesn't generally carry b/w reqirements.  so why would you require
  repair path to carry these.
  
  JP - can also have issue with proving that loose paths are diverse
  from that which they're protecting.
  
  Luca - like to second Eric's comment about WG going on too long.  Also
  would like to have someone prove tangibly that TCP scales badly.  I
  have tested myself that LDP scales very well.  No issue with full mesh
  of LDP.  Would like statements like that to get backed up.
  
  Pedro - are we going away completely from hop-by-hop labels or having
  this side-by-side.
  
  Albert - not going to use DWL for RSVP-TE or BGP.  So just for BGP.
  And possibly only for LDP loopbacks - i.e. not for L2VPN etc. (they
  can still use local labels).  Both can co-exist as long as partition
  can be respected.
  
  Alex - Label allocation is an integral part of the architecture.  The
  workgroup is done with architecture.  Unless it can be proved that
  architecture is not sufficient then this doesn't fit in charter.
  
  Albert - DWL is special case of label allocation.  Just require people
  to allocate labels in the same way.  Don't see it as such a
  fundamental change in architecture.
  
  George - thank you albert for getting Albert, Eric and Yakov to
  agree at last.
  
  Albert - can we be WG doc?
  
  George - no.  Alex ain't happy.
  
  Albert - DWL is just one area.  Source routing and strict hops over
  high-cost links are still issues.
  
  Lou - we have two approches CR-LDP and RSVP-TE.
  
  Albert - but source routing is an approach
  
  Lou - both CR-LDP and RSVP-TE support both.
  
  Yakov - why not use source routing in RFC792?
  
  Albert - this is more efficient.
  
  Yakov - efficiency is relative.

Loose Segment Optimization in Explicit Paths
draft-tian-rsvp-loose-seg-opt-00.txt

Albert Tian

  The issue addressed by this draft is FRR.  The author has concerns
  about having large numbers of repair paths. If you use RSVP-TE could
  have a lot of state in the network.  Can alleviate this by
  tunnelling the RSVP-TE path messages to reduce RSVP-TE state.  Two
  applications are envisioned, Fast Reroute and P2MP.  In the latter
  case this is applicable if shape is the only concern.
  
  The idea is to have RSVP state only at critical nodes and to use LDP
  as a form of fowarding adjacency between those nodes.
  
  Example using mix of strict and loose hops and using Soft FAs for the
  loose segments.
  
  Can use PHP - just merges RSVP-TE into LDP on last loose segment.
  
  P2MP example can again remove RSVP-TE state on the loose segments.
  
  Just one bit (O-bit) to ask for a loose segment.
  
  So - can reduce RSVP states on repair paths for FRR and limit to
  branch points in P2MP TE.
  
  Albert request that this become a WG document.  Some discussion
  ensued with no clear direction.  George asked that the discussion be
  continued on the list.
  
  Rahul - this is already in the hierarchy docs.  If there's anything
  missing need it spelled out.
  
  Albert - will take a look to see if it is.
  
  Yakov - you mentioned in an early slide that node protection
  requires a lot of paths and state.  As Luca pointed out in previous
  presentation can you please put numbers on the table.
  
  Albert - yes will do that.
  
  Yakov - we need to get numbers and talk about them before we make
  any decision...
  
  Dimitri - how are you performing TE LSP hierarchy using this method
  when there's no TE concept in LDP?
  
  Albert - if you're doing protection paths then there could be QoS
  requirements.  But if they don't exist then this is a perfect fit.
  
  Dimitri - How does this mechanism inherit TE attributes given that
  this is LDP?
  
  Albert - for repair you don't want much attributes.
  
  Dimitri - will take offline.

FastReroute using Alternative Shortest Paths
draft-tian-frr-alt-shortest-path-01.txt
  
Albert Tian

  This draft proposes a new way to calculate repair paths which offers 100%
  repair coverage using explicit paths with loose segments.
  
  First issue is to determine the termination point.  For link
  protection this is the next-hop; for node protection the
  next-next-hop.  Repair path calculation is simple.  Take out the
  link or node being protected and calculate a path.
  
  The repair can be made using any of:
  
  Source Routed MPLS LSP using Domain Wide Label
  RSVP-TE
  RSVP-TE with Loose Segment Optimization in Explicit Paths
  
  Draft gives algorithm to simplify the repair path.
  
  The key benefit benefits claimed are 100% coverage with reduced
  repair paths based on next-hop/next-next-hop termination, and shared
  protection for MPLS, IP unicast, and IP multicast.
  
  Albert asked that this become a WG document.  George question which
  parts belonged here and pointed out that there was related work
  going on in the Routing Area WG.  It would appear that the algorith
  part of the draft would belong there since it's applicable to IP as
  well as MPLS.  Discussion will continue in that WG and on the
  list(s).

Equal Cost Multipath Best Current Practices (ECMP BCP)
draft-swallow-mpls-ecmp-bcp-00.txt

George Swallow

  This draft is intended to give guidance to people building
  applications on MPLS.  The issue first surfaced in PWE3.  If all of
  the data for a psuedo-wire then steps need to be taken to avoid
  ECMP.  There are several known reasons for wanting a single path.
  One is to reduce jitter and avoid out-of-order delivery (note that
  these can still occur in a reroute situation).  Anther is to ensure
  that OAM flows follow the paths that they are trying to monitor.
  
  MPLS defines FECs.  The primary FEC used in the core of the network
  is the IP prefix.  MPLS has no payload identifier; it is inferred
  from the FEC.  on this early on in MPLS.  If you get label in middle
  of network for IP FEC and have no payload ID then many vendors
  assume is IP.  But some vendors said "if look at first nibble and
  isn't 0x4 will assume it isn't IP.  If it is IP we'll do our usual
  IP hash".  All well and good as long as only carried IP or L3VPN.
  But get problems with PWE3 as have non-IP payload.  If first nibble
  is 0x4 the core is likely to assume this is IP and we'll get
  mis-ordering.
  
  Ultimately best solution is to avoid 0x4 or 0x6 in first nibble.
  Problem is that IANA is working up from 4.  Nobody knows the exact
  status of 0-3, but it is unlikely that they would be assign before
  7-15, if at all.  The recommendation in this draft is to use 0x0 and
  0x1.
  
  George will be asking for WG status on the list.  A poll of the room
  showed general support for this.
  
Giles took really great notes.  I added most of the details not included
in the offical minutes for anyones entertainment.

...George

========================================================================

Multiprotocol Label Switching Minutes - IETF60
----------------------------------------------

WG status (Loa & George)

  Mail list - has been moved to the ietf server.  We've also changed
  maillist administrators at this time.  Thanks to Eric Rosen for
  serving us so well and so long.  And thanks to Eric Gray for taking
  this on.
  
  Four new RFCs (all MIBs).  RFCs 3811 - 3815.
  
  Various drafts on the RFC editor's queue.  No real problem per se.
  Draft editors - please take care with refs to other docs (esp docs
  you don't control and normative refs).  Some refs that were said to
  be normative weren't etc.  Refs are most common reason for getting
  stuck in the Q.
  
  MTU signalling doc got stuck because of over-ambitious author (added
  RFC editor's note himself).  Need to verify that we got the RFC
  editor's note correctly.
  
  Author, chairs, and ADs will be meeting to sort out comments on MPLS
  over GRE.
  
  A respin needed on LSP ping.  Other documents including LSR
  self-test depend on this.
  
  ATM/FR LC MIB doc is in MIB-doctor review.
  
  Ina Minei has taken on the task of getting LDP to draft standard.

MPLS OAM Framework
draft-an-mpls-oam-frmwk-00.txt

Tom Nadeau and Dave Allen

  An OAM framework was added to charter a few meetings back.  Tom and
  Dave had been active in that area so were asked to have a go.  This
  is initial output.
  
  The aim is to keep the scope down and describe circumstances where
  data plane tools would facilitate addressing FCAPS issues.  Since
  the draft is a framework, it is intended to be technology agnostic.
  Specific tools are not discussed.  Each of the topics in FCAPS will
  be addressed.  The document currently covers the following.
  
  Fault Management - enumerates potential MPLS forwarding problems and
  explores where data plane tools can assist in detection and
  diagnostics - how do you isolate the fault and take failed resource
  out of service.  Really looking at TTL mechanisms.  There is some
  discussion of availability criteria but this could use some fleshing
  out by providers.
  
  Config - using data plane tools to verify config.
  
  Admin in future.
  
  Perf - extracting counts etc.
  
  Security - can tools be abused?  How to prevent this.
  
  Next steps are to adopt this as WG draft.  The authors will continue
  to work on security and administative issues.  George said it was
  inappropriate to poll the room for support to make this a WG
  document since the draft did not make the cut-off.  So take to list
  after the meeting.

P2MP requirements
draft-ietf-mpls-p2mp-requirement-03.txt

Seisho Yasukawa

  This draft has gone through an initial WG last call.  This revision
  is intended to address those comments 

  Not considering routing based or multicast MPLS here.
  
  Further requirements issues were raised by the P2MP design team (see
  next draft below) that need to addressed in this draft, including:
  
  1) are all leaves/branches subject to same LSP parameters?  Esp
     important inter-domain.
  
  2) How do we do re-merge and cross-over?  Issues with duplication.
  
  3) How does this scale.  Is core of network so scaling different to
     pure IP multicast.  Hopefully tree is more stable than in IP.
  
  4) Partial tree reoptimisation is important - but can cause
     duplication.
  
  5) What if path message gets fragmented downstream (as it grows as
     it goes)?  Don't want to rely on IP fragmentation - so need to
     handle in control plane.
  
  6) should we avoid replication on MPLS LAN interfaces?
  
  Next steps:
  
  Revision 4 - will add the new well understood requirements.
  
  Authors will ask list about those that are not well understood.
  
  Then hopefully will produce revision 5 as final rev. and put into WG
  last call.

  George - Speaking as chair
  
  The draft needs to be revised to both clarify and narrow the scope
  to P2MP traffic engineering.  The draft should only be about
  requirements, references to RSVP should be minimal if not completely
  expunged.  Requirements draft is causing consternation in IETF
  multicast groups.  People are upset by statements that can be used
  without a multicast protocol.  This is a directive not a comment.
  If you don't do some work this won't make it through the IESG.
  
  Eric - I have some fundamental problems with this doc that I've
  stated on mailing list.  None have really been addressed.  Charter
  says requirements for TE to P2MP LSPs.  Doesn't say we need to be
  able to set up explicit routed P2MP LSPs using RSVP-TE.  TE is a lot
  of different things (explicit routing, FRR, constraint based
  routing, guaranteed b/w).  It's not clear that all these things
  create the same requirements for P2MP.  Explicit tree doesn't need
  PIM, but PIM might fit in well for FRR (based on unicast FRR).
  These questions would seem to be in scope of the WG charter.  Also
  multicast groups have other requirements for protocols which build
  multicast distribution trees.  Most aren't considered here.  May not
  be reqirements for this application, but need to be addressed.
  E.g. multicast guys are serious about having large numbers of
  receivers and changing very fast without loading root of tree.
  Depending on what you think the goals are you might have a very
  different soln.
  
  Loa - to summarise.  We need to be clear about the scope of the doc,
  and we need feedback from the multicast community.
  
  Eric - I've heard people say "this doc is only about content
  distribution so why are you talking about large numbers of
  receivers".  But the doc doesn't say that.  If it was called
  reqirements for content distribution that would be fine, but this
  seems to be aimed at generic reqirements (yet has a long way to go
  before it gets there).
  
  Adrian - many of the points Eric has been making became clearer to
  authors during first stab at solution.  We do have a list of
  questions including the extent of the rate of change of leaves and
  attend to address this.  I have a concern that the only person who
  commented during last call was Eric.  If we spin this again and get
  the same rate of comments we're in trouble.  Would be helpful to get
  comments from the chair during last call.
  
  George - Eric had made most obvious comments.  Also matter of time.
  Other stuff has occured during this meeting.
  
  ? - what do you mean by multicast MPLS being out of scope.  are you
  excluding label distro for multicast packets, or are you excluding
  multicast content?
  
  Seisho - we're not excluding multicast packets from being
  transmitted over P2MP LSP.
  
  ? - so it's intended to carry multicast traffic?
  
  Seisho - Yes.
  
  Yiqun Cai - problem I have is that this is free-floating.  Defining
  TE reqirements without saying what framework this is and what it
  provides transport for is like defining TCP without defining
  datagram service.  I don't think anyone will use this to carry IPMC
  over an SP core.  So what is the req with or without TE.  Needs to
  have normative refs, but no doc exists for that.  So hard to
  evaluate something free-floating.
  
  Seisho - can't understand your point.
  
  Albert Tian - still a bit confused as to what is excluded.  What
  do you mean by Multicast MPLS?
  
  Seisho - eliminating possibility of doing setup based on multicast
  IP address.
  
  ? - good to do the work.  But consternation being caused by the fact
  that the transport service and the packets that it will carry are
  likely to be multipoint forwarding mechanisms.  So you still have
  the same problem space as multicast even if you don't call it that.
  You need to be able to describe the reqirements. of the content that
  the service will end up carrying.  Once you start talking about that
  things like tree size/tree dynamics will come into play.
  Presentation in MBONED WG yesterday clarified this.  Once we started
  calling it multicast then people woke up.  What would be useful is
  to present this stuff in MBONED and PIM WGs.  Will have an effect on
  PIM at edge if you want to carry multicast over this.
  
  Rahul - 7 points were made.  All good points.
  
  1) Reqirements does talk about applications - e.g. L2 multicast, L3
  multicast.  If you think they aren't complete then let us know.
  
  2) Reqirements for interaction between multicast protocols and P2MP
  TE need to be in there.
  
  3) multicast community hasn't been involved.  That's being
  overstated.  First of all over last year or so have received
  comments from some multicast folks.  Also solution draft on PIM-SM
  interaction with P2MP TE was presented 3 IETFs ago in PIM.  Got
  feedback then.
  
  Dave Meyer - Over in MBONED we're trying to put infrastructure in
  place to stop protocol WGs going off on their own.  This wasn't
  really vetted in MBONED.  Need to facilitate communication between
  disparate groups.  No blame - is just a structural issue.
  
  Loa - point taken.  Number of cross-WG things to co-ordinate.  This
  is one of them.  No intention to sneak this through.  Thanks for
  bringing it to our attention.

P2MP merged solution document
draft-raggarwa-mpls-rsvp-te-p2mp-00.txt
  
Dimitri Papadimitriou, Rahul Aggarwal & Seisho Yasukawa

  In Korea there were two drafts that were far apart.  Alex asked that
  there be one draft, merging the two and that a design team be
  formed.  together.  That happened slowly at first, but what happened
  once people started focussing on the problem were able to find the
  right solution.  This draft represents both the consensus and
  captures the remining differences of the original two drafts.  While
  it is far from converged much progress has been made.
  
  Open issues (partial list):
  
  1) state management.  Intent is to disambiguate message size.  ID
     still needed for sub-tree reoptimisation.
  
  2) re-optimisation.
  
  3) re-merging.  Would like to point out issues under discussion -
     data plane and control plane issues.  Identified a case for this.
  
  4) Recovery.  Need to expand on GMPLS applicability.

  The authors will be requesting this be a WG document after this
  meeting.

Source Routed MPLS LSP using Domain Wide Label
draft-tian-mpls-lsp-source-route-01.txt

Albert Tian

  This draft introduces global labels as a means of source routing or
  loose source routing a packet in an MPLS network.  If each
  destination of interest (say all of the loopback addresses used as
  router-IDs) had a label which was both globally known and globally
  used by all routers, then one could source route a packet by
  stacking up labels for each of the routers in the source route.
  This technique could be applied to fast reroute.
    
  Some concerns over maximum stack size.  Probably use loose segments
  in the stack to reduce size of stack.  Also can prove that for link
  protection need max 2 labels for unicast and 3 for multicast
  (assuming symmetic metrics).  For node protection can be worse.
  Most implementations allow you to have a big stack (it's just
  overhead).  Deeper stack only needed at head-end.  As you go down
  the path you're just popping and swapping.
  
  LDP extn. - a range of labels needs to be reserved for DWL.  Can be
  identified by the range and agreed throughout the domain.  Need
  domain wide binding.  If revieved label is DWL then allocate the
  same one and propagate upstream.
  
  How to allocate:
  
  sub-range per LSR.
  
  can do manual allocation via config (so add a line to each LSR to
  assign a sub-range).  Could automatically derive from IP addresses
  (nice chunks).  Or could use a central server.  Pedro suggested LDAP
  for this.
  
  Note that if you don't need strict hops you just need 1xDWL per
  router (for loopback).
  
  PHP is an issue.  but can overcome if you want it.
  
  Need mechanism for strict hops over high cost links (as OSPF follows
  IGP).
  
  People always have security concerns with source routing.  Note that
  DWL only makes source routing easier (for user and hacker).  it
  doesn't actually facilitate it.  So don't accept labels from outside
  trusted domain.
  
  Albert requesting WG status as he believes this fits in MPLS charter.
  
  Eric - sometimes a WG goes on too long.  I hardly know where to
  begin.  The idea of the MPLS label being local was so fundamental to
  the MPLS specs that we could spend the rest of our lives looking for
  places where this might break.  At very least you need to spend time
  on an impact statement.  If you like paradigm of forwarding on
  global info suggest a look at RFC792 (explains how to do that).
  Problem with domain-wide labels is that the notion of domain isn't
  well defined.  What if a router is a member of two routing domains?
  Could have conflicts there.  Unlike ATM the label space isn't
  necessarily interface specific so you don't necessarily know which
  label space the packet is for.  Seems to be going back down the path
  of "signalling creates too much overhead so let's statically
  provision".  Scope of getting label from far end of tunnel doesn't
  require new architecture.
  
  Yakov - (1) outlined alleged benefits of this proposal.  But where's
  slide outlining drawbacks?  Are you saying none or some? (2)
  provisioning/IP/centralised server.  Let's go to third point.
  Should have several options for this - RADIUS, LDP (perfect choice
  as this is LDP), BGP (for those who don't like LDP or RADIUS).
  
  Albert - issue of how to ensure uniqueness is definitely part of
  drawback.  You don't lose something for nothing.  Is more of admin
  overhead, but gives you more control and more troubleshooting
  ability.  Stated the other way - if you use a full mesh of tLDP then
  that's a big protocol overhead.  Full mesh of TCP connections.  100s
  or 1000s of copies of the same info so clearly can optimise that
  out.  Can explore more on how to achieve the uniqueness of label
  allocation.  But that's an independent issue.
  
  Adrian - 2 points.  (1) need to consider control/data ratio with a
  large label stack and very little data.  (2) DWL is interesting
  concept - note that labels can fit in 32 bits so would be handy to
  have a structure, e.g. break up into classes or something like that.
  What was it Eric said about RFC792?
  
  JP - unfortunate that Eric, Yakov and Adrian run faster than me.  But
  I'm faster than Luca! You need to spell out the limitations. We don't
  see those in live networks.  As Adrian mentioned overhead is an issue.
  Finally use of loose hops, but if you do that you lose control at the
  head end and lose advantage of easy troubleshooting.
  
  Albert - there's another draft coming up. If you use explicit paths
  as repair paths then you can prove that loose paths won't change if
  you calculate them properly.
  
  JP - not true in terms of b/w sharing etc.
  
  Albert - if you have b/w requirements then yes.  But LDP traffic
  doesn't generally carry b/w reqirements.  so why would you require
  repair path to carry these.
  
  JP - can also have issue with proving that loose paths are diverse
  from that which they're protecting.
  
  Luca - like to second Eric's comment about WG going on too long.  Also
  would like to have someone prove tangibly that TCP scales badly.  I
  have tested myself that LDP scales very well.  No issue with full mesh
  of LDP.  Would like statements like that to get backed up.
  
  Pedro - are we going away completely from hop-by-hop labels or having
  this side-by-side.
  
  Albert - not going to use DWL for RSVP-TE or BGP.  So just for BGP.
  And possibly only for LDP loopbacks - i.e. not for L2VPN etc. (they
  can still use local labels).  Both can co-exist as long as partition
  can be respected.
  
  Alex - Label allocation is an integral part of the architecture.  The
  workgroup is done with architecture.  Unless it can be proved that
  architecture is not sufficient then this doesn't fit in charter.
  
  Albert - DWL is special case of label allocation.  Just require people
  to allocate labels in the same way.  Don't see it as such a
  fundamental change in architecture.
  
  George - thank you albert for getting Albert, Eric and Yakov to
  agree at last.
  
  Albert - can we be WG doc?
  
  George - no.  Alex ain't happy.
  
  Albert - DWL is just one area.  Source routing and strict hops over
  high-cost links are still issues.
  
  Lou - we have two approches CR-LDP and RSVP-TE.
  
  Albert - but source routing is an approach
  
  Lou - both CR-LDP and RSVP-TE support both.
  
  Yakov - why not use source routing in RFC792?
  
  Albert - this is more efficient.
  
  Yakov - efficiency is relative.

Loose Segment Optimization in Explicit Paths
draft-tian-rsvp-loose-seg-opt-00.txt

Albert Tian

  The issue addressed by this draft is FRR.  The author has concerns
  about having large numbers of repair paths. If you use RSVP-TE could
  have a lot of state in the network.  Can alleviate this by
  tunnelling the RSVP-TE path messages to reduce RSVP-TE state.  Two
  applications are envisioned, Fast Reroute and P2MP.  In the latter
  case this is applicable if shape is the only concern.
  
  The idea is to have RSVP state only at critical nodes and to use LDP
  as a form of fowarding adjacency between those nodes.
  
  Example using mix of strict and loose hops and using Soft FAs for the
  loose segments.
  
  Can use PHP - just merges RSVP-TE into LDP on last loose segment.
  
  P2MP example can again remove RSVP-TE state on the loose segments.
  
  Just one bit (O-bit) to ask for a loose segment.
  
  So - can reduce RSVP states on repair paths for FRR and limit to
  branch points in P2MP TE.
  
  Albert request that this become a WG document.  Some discussion
  ensued with no clear direction.  George asked that the discussion be
  continued on the list.
  
  Rahul - this is already in the hierarchy docs.  If there's anything
  missing need it spelled out.
  
  Albert - will take a look to see if it is.
  
  Yakov - you mentioned in an early slide that node protection
  requires a lot of paths and state.  As Luca pointed out in previous
  presentation can you please put numbers on the table.
  
  Albert - yes will do that.
  
  Yakov - we need to get numbers and talk about them before we make
  any decision...
  
  Dimitri - how are you performing TE LSP hierarchy using this method
  when there's no TE concept in LDP?
  
  Albert - if you're doing protection paths then there could be QoS
  requirements.  But if they don't exist then this is a perfect fit.
  
  Dimitri - How does this mechanism inherit TE attributes given that
  this is LDP?
  
  Albert - for repair you don't want much attributes.
  
  Dimitri - will take offline.

FastReroute using Alternative Shortest Paths
draft-tian-frr-alt-shortest-path-01.txt
  
Albert Tian

  This draft proposes a new way to calculate repair paths which offers 100%
  repair coverage using explicit paths with loose segments.
  
  First issue is to determine the termination point.  For link
  protection this is the next-hop; for node protection the
  next-next-hop.  Repair path calculation is simple.  Take out the
  link or node being protected and calculate a path.
  
  The repair can be made using any of:
  
  Source Routed MPLS LSP using Domain Wide Label
  RSVP-TE
  RSVP-TE with Loose Segment Optimization in Explicit Paths
  
  Draft gives algorithm to simplify the repair path.
  
  The key benefit benefits claimed are 100% coverage with reduced
  repair paths based on next-hop/next-next-hop termination, and shared
  protection for MPLS, IP unicast, and IP multicast.
  
  Albert asked that this become a WG document.  George question which
  parts belonged here and pointed out that there was related work
  going on in the Routing Area WG.  It would appear that the algorith
  part of the draft would belong there since it's applicable to IP as
  well as MPLS.  Discussion will continue in that WG and on the
  list(s).

Equal Cost Multipath Best Current Practices (ECMP BCP)
draft-swallow-mpls-ecmp-bcp-00.txt

George Swallow

  This draft is intended to give guidance to people building
  applications on MPLS.  The issue first surfaced in PWE3.  If all of
  the data for a psuedo-wire then steps need to be taken to avoid
  ECMP.  There are several known reasons for wanting a single path.
  One is to reduce jitter and avoid out-of-order delivery (note that
  these can still occur in a reroute situation).  Anther is to ensure
  that OAM flows follow the paths that they are trying to monitor.
  
  MPLS defines FECs.  The primary FEC used in the core of the network
  is the IP prefix.  MPLS has no payload identifier; it is inferred
  from the FEC.  on this early on in MPLS.  If you get label in middle
  of network for IP FEC and have no payload ID then many vendors
  assume is IP.  But some vendors said "if look at first nibble and
  isn't 0x4 will assume it isn't IP.  If it is IP we'll do our usual
  IP hash".  All well and good as long as only carried IP or L3VPN.
  But get problems with PWE3 as have non-IP payload.  If first nibble
  is 0x4 the core is likely to assume this is IP and we'll get
  mis-ordering.
  
  Ultimately best solution is to avoid 0x4 or 0x6 in first nibble.
  Problem is that IANA is working up from 4.  Nobody knows the exact
  status of 0-3, but it is unlikely that they would be assign before
  7-15, if at all.  The recommendation in this draft is to use 0x0 and
  0x1.
  
  George will be asking for WG status on the list.  A poll of the room
  showed general support for this.

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

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