From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Fri Sep 10 2004 - 20:02:30 GMT-3
>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
>mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:41 GMT-3