The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Detailed Minutes
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
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
|
|