Subject: Oslo meeting minutes

From: Vijay Srinivasan <[email-masked]>
Date: Tue, 10 Aug 1999 10:07:28 -0400

Hi all,

Here are the draft meeting minutes from Oslo.  Sorry for being tardy in
getting these out.

Many thanks to Andy Malis for taking minutes.

- Vijay

------------------------------------------------------------------------------

MPLS, Oslo IETF

The meeting was chaired by George Swallow and Vijay Srinivasan.  Andy
Malis took the minutes.

First session, Monday, July 12, 0900-1130

Chairs, Agenda bashing

No changes were made to the agenda.

Juha Heinänen, draft-heinanen-diffserv-mpls-00.txt

Juha presented his draft on implementing Diffserv over MPLS.

Juha emphasized there are no end-to-end resources reserved like in ATM
or Frame Relay; rather, forwarding resources need to be reserved in each

LSR for each of forwarding class.  LSP setup messages need to be
extended to indicate which FCs its packets may belong to.  In order for
multiple FCs to share the same LSP, then the number of forwarding
class/drop precedence combinations needs to be restricted to eight, and
the three-bit EXP field can be used to contain the FC.  If there is only

one FC on the LSP, then the EXP can be used to denote the drop
precedence.  Each LSR on an LSP must have resources allocated for the
listed FCs during LSP setup.  Two LSPs can be merged if one's FCs are a
subset of the other's FCs.

Juha proposed a new LDP TLV to contain the list of FCs for the LSP.
There is no standardization of the EXP field contents; rather, it is
LSP-specific and indicated by signaling.

Juha also proposed a separate I-D on how to map Diffserv LSPs to each
subnetwork technology, such as ATM, FR, and Ethernet.

Juha is opposed to any standardization of the EXP field, especially for
explicit congestion notification.  He wants its use to be determined on
a per-LSP basis by signaling when the LSP is set up.

Francois Le Faucheur, draft-lefaucheur-mpls-diff-ppp-00.txt

This was another draft of MPLS support for Diffserv, this one specific
to PPP links.  Terminology introduced by this draft includes "Scheduling

Aggregate (SA)", which is the set of behavior aggregates whose packets
must be scheduled together because of ordering constraints, "Per-Hop
Scheduling (PHS)", which is a set of PHBs applied to the behavior
aggregates in a SA.

L-LSPs have the PHS inferred from the label, and contain the drop
precedence in the EXP field.  There is a proposed addition to LDP
signaling to indicate the PHS for an LSP.

E-LSPs use the EXP field to indicate the PHS.  It is used exactly like
the 6-bit DS field in the IP header, but is shorter, only 3 bits.  The
drop precedence and PHS are mapped together, and the mapping is
configured rather than signaled.  This is analogous to Diffserv over IP
where the DS field mapping is configured rather than signaled.  No new
object or TLV is required for signaling; signaling is identical whether
or not Diffserv is in use.

Service providers should be able to deploy multiple LSPs for each FEC: 0

or 1 E-LSPs, and 0-n L-LSPs for each FEC.

In contrast to Juha's draft, Juha's "single-class LSP" is roughly
equivalent to "L-LSP", and Juha's "Multi-class LSP" is roughly
equivalent to the E-LSP.  The main differences are that Juha wants to
support multiple E-LSPs per FEC, and  Juha proposes the use of signaling

rather than configuration for E-LSPs.

Outstanding feedback from the email list is whether or not there should
be multiple E-LSPs per FEC.

Francois Le Faucheur, draft-ietf-mpls-diff-ext-01.txt

This was another draft of MPLS support for Diffserv, this one specific
to ATM and FR links.  This is very similar to the previous draft, and
shares the same terminology.

Next steps on both drafts:

Proposal 1: get more opinions/resolution on whether or not multiple
E-LSPs are necessary per FEC.  If yes, then the default is what they've
already proposed (configuration of a single E-LSP), but also include
optional signaling for the set of PHSs in the E-LSP, similar to Juha's
proposal.

Comment: Curtis Villamizar wants multiple E-LSPs per FEC, but doesn't
feel it is necessary to be signaled.   He was also concerned with
interoperability between routers that can read the EXP field and those
that cannot.

Comment from Liam Casey: Juha's draft adds complexity to a switch to
support multiple E-LSPs, both for signaling and in forwarding, so he was

in favor restricting to one E-LSP per FEC.

Comment: Scott Brim is in favor of explicit signaling, so prefers Juha's

proposal.

Comment: Curtis feels that it's an implementation decision whether or
not to support one or more E-LSPs per FEC.  He's also very concerned
about merging issues, and whether or not a separate draft is required.

Comment: Juha spoke against configuration; he is in favor of signaling
for both L-LSPs and E-LSPs.

George said that he feels we have consensus on signaling for L-LSPs, the

question is whether we also need to signal the mapping for EXP bits for
E-LSPs.

Curtis volunteered to provide proposed wording on how to support
multiple E-LSPs without requiring signaling.

There was agreement that supporting merging is a requirement for these
proposals, since not merging doesn't scale.

Proposal 2: Francois is going to combine his two drafts, and that will
become a working group draft.  This was accepted.

Proposal 3: SA/PHS terminology: Keep in MPLS WG documentation for now
and hand over to Diffserv WG when work on updating RFC 2475 commences.
Juha objected to this; he preferred his own terminology.  However,
Francois emphasized that it took some time to get agreement from the
Diffserv chairs on his terminology.  Further discussion will be taken
offline.

Walt Wimer, draft-wimer-mpls-atm-rsvp-00.txt

Walt spoke on MPLS using RSVP and ATM VC switching.  He discussed MPLS
over ATM concepts, RSVP label object encoding for ATM, and RSVP with ATM

SVCs, and a possible new RSVP object.

His draft borrowed some content from draft-ietf-mpls-atm-02.txt, and
intends to remain coordinated with that draft.

He proposed a specific encoding of VPI/VCI in the RVSP Label Object
Encoding.

With ATM SVCs, VPI/VCIs are not preserved end-to-end, so he proposed
using the GIT to piggyback the VCID and using the VCID in the RSVP
signaling.

He proposed carrying RSVP messages in the default non-labeled IP PVC
between LSRs, rather than in a separate ATM VC.  The draft also
discusses the interactions between the RSVP and ATM signaling, and to
fix some problems, reverse the VCID assignment to make it consistent
with downstream label assignment.

Finally, he proposed a new Hop_Count object to include the number of
hops through the ATM cloud.

There was consensus to merge this material with the existing ATM draft.
Walt will work with Bruce Davie on this.

K. K. Ramakrishnan, draft-mpls-ecn-00.txt 15

This is a proposal for incorporating explicit congestion notification in

MPLS.  They received comments on the list, and wanted to negotiate the
use of the EXP field so that they can have a single ECN bit in the EXP
field.  ECN builds on the work on active queue management for RED and
other congestion management algorithms.  K. K. presented the motivation
for ECN for both IP and MPLS.  Their ECN is not identical to ATM EFCI or

FR FECN, since those are based on instantaneous queue size, while their
ECN algorithm includes a smoothing function to make it less noisy.

Since they are specifying the use of one bit out of the only three bits
in the EXP field, ECN must be negotiated/signaled during LSP setup.

When in use, the ingress LSR must import the IP ECN bit to the MPLS
header, and the egress LSR must export the MPLS EXP bit to the IP
header.

K. K. discussed the interactions between ECN-capable and non-ECN-capable

LSRs.

The use of ECN with MPLS is likely to be gradual at best, which is why
they recommend that signaling is necessary to negotiate its use.  They
plan to include the signaling in a future version of the draft.

Question: Have they considered the effects of merging and local repair
on ECN?  A: They've discussed this among the authors, but it is not yet
in the draft.

Q: There are interesting interactions if some of the branches are
congested and others aren't; should the congestion management affect all

of the branches or not?  A: It's a more complex subject than can be
answered in the time allowed.

Comment: Curtis prefers the two-bit ECN scheme over the one-bit scheme,
and also prefers configuration to negotiation.  He wants the two-bit
scheme included, at least as an option.

Q: Juha asked if he can use all three bits of the EXP field for Diffserv

if he didn't want to?  K. K. emphasized that a bit is not being reserved

for ECN, but this is signaled.

Further discussion was moved to the list.

Dimitry Haskin, draft-haskin-mpls-fast-reroute-01.txt

Dimitry discussed a proposed method for setting up alternative LSPs to
handle fast reroutes following switch or link failures.  His goals were
to provide service level protection for an MPLS tunnel, as opposed to
physical layer protection and achieve quick restoration comparable to
SONET's restoration time.

The proposed approach is to reverse traffic at the point of the
protected LSP back to the source switch of the protected LSP such that
the traffic flow can be then redirected via a parallel LSP between
source and destination switches of the protected LSP tunnel.

Dimitry discussed the benefits of this approach, and how holding
priority and preemption can be used to preclude the need to reserve
bandwidth for the alternative path until it is actually needed.  It also

has some limitations, such as the network's topology and policy must
allow establishment of the parallel LSP on different LSRs than the
protected path.

Q: Liam Casey noted that the proposed preemption approach doesn't appear

in the traffic engineering drafts.  Dimitry agreed, and said that the
other drafts will need to be modified to support this.  This led into
the next presentation.

Ram Krishnan, draft-krishnan-mpls-reroute-rsvpext-01.txt

This draft proposed the required RSVP signaling changes to support
Dimitry's draft.  This included a new flag for the SESSION-ATTRIBUTE
object, a REVERSE-LABEL-REQ object in the RESV message, and
REVERSE-LABEL object in the PATH message.

Vijay asked about the effects that this has on resource reservation and
whether the reverse traffic uses the resources reserved for forward
traffic or backward traffic.  Ram gave a detailed reply on the possible
interactions and reserved resources.

Comment: One person thought that this draft was quite complex, and
should use existing mechanism available from e.g. RSVP to set up the
alternative paths.  A: This is the first proposal for fast reroute, and
proposed changes are welcome.  Please submit them to the list.  Q: The
questioner felt that the necessary mechanisms are already in the RSVP
specification.

Comment: The terminology should be changed to "rapid restore" rather
than "rapid reroute".  Ram had no problem with that.

Ram asked that these drafts be made into working group drafts, but
George felt that this was premature.  George also noted that several
vendors are building fast reroute-type functionality using existing
signaling mechanisms.

Matt Holdrege disagreed with George, saying that things have been
delayed in the WG and this should be addressed promptly.  Matt would
also like to see protection requirements addressed.  George reemphasized

that he felt is premature, and that requirements should be addressed in
the Traffic Engineering BOF.  Curtis reiterated George's earlier comment

that router vendors are building this functionality with existing RSVP
based mechanisms.

Ram suggested that the traffic-triggering part was new when compared to
existing work.  George agreed, but also opined that this could possibly
cause a denial-of-service problem, and the security section of the draft

would be formidable.

Ken Owens, draft-mpls-protection-00.txt

Ken discussed MPLS protection requirements for configuration, failure
detection, failure propagation, protection switching, and restoration.
They had a one-second requirement for restoration, rather than Dimitry's

50 ms.  This was more of an ATM OAM-ish approach, using separate failure

signaling rather than reversed traffic.

They would extend LSP signing to identify LSPs that need protection, and

they propose both layer 2 and layer 3 options for establishing the
protection path.

Ken have a detailed overview of the operation of his proposed protection

mechanism.

An updated draft will be coming out a few weeks following the meeting.
No action was taken.

Gerald Ash, Peter Ashwood-Smith, draft-ash-crlsp-modify-00.txt

Gerald presented proposed changes to CRLDP to support QoS resource
management and changing LSP characteristics, especially when used with
VPNs.  Ingress LSRs would allocate bandwidth to each virtual network
based on demand, and use modified CRLDP signaling to change the
characteristics of existing LSPs when necessary.

They used network simulations to compare various network designs and
per-flow bandwidth allocation vs. per-VPN bandwidth allocation.
Per-flow was somewhat more efficient, but not by much.

They feel this is a simple extension to CRLDP to support per-VPN
bandwidth allocation with modification.

Peter discussed the specific changes required to CRLDP to support this,
especially modification.  Peter said that the CRLDP draft had alluded to

modification, but the details hadn't been filled in.  Peter proposed
that any modification to an LSP should be treated as a new LSP, since
rerouting may be necessary, but the same LSP ID should be used to avoid
double-allocation, and a new flag would be used to signal this use of a
duplicate LSP ID (which usually isn't allowed).  Peter went though an
example of how this would work.

Bilel Jamoussi discussed the plans for the next spin of the CRLDP
document.  He asked if there was any objection to including this in the
next respin of CRLDP.  George suggested that this be brought up on the
list, and added if there are no objections received.   Bilel said that
CRLDP is also going to be updated to reflect the recent changes to the
base LDP spec.  George noted that the RSVP spec also needs a few minor
updates before it is published as an RFC.

Second session, Monday, July 12, 1300-1500

Bob Thomas, Peter Ashwood-Smith, Interop interworking demo of LDP

Bob discussed the result of MPLS interoperability testing that occurred
at the Las Vegas Networld+Interop meeting in May.  It occurred through
the efforts of Bill Jensen of Jim Leu of the University of Wisconsin,
and it demonstrated MPLS forwarding over ATM links through LSPs set up
using version -03 of the LDP specification.  It included Cisco and
Nortel routers and ATM switches.

It exercised LDP discovery, LDP session establishment and shutdown,
downstream-on-demand LSP setup and teardown, and almost all of the LDP
messages.

About the Cisco implementation:  MPLS encapsulation and tag switching
encapsulation are the same, LDP implemented as refinement and
enhancement of the existing TDP implementation, the label distribution
protocol used on a particular interface could be configured to be LDP or

TDP, and an LSP could be set up using TDP only, LDP only, or mixed on
different segments of the LSP.

The three main interoperability testing issues on the Cisco side were
"Is Hello a Multicast or Broadcast message", "What was that message
anyway?", and "Can we find a label range to use?"  The first issue was
because of one of the differences between LDP and TDP.  The second
problem was that a mysterious message was appearing on the wire, and it
turned out to be a TDP notification message going out on the LDP link
instead of the LDP notification message.  The third issue was that
sessions were coming up, and then being turned down immediately.  The
problem was that both implementations wanted non-overlapping label
ranges.   Once these was fixed, it all came up and worked.

The Nortel implementation is distributed over the interfaces, with LDP
session setup on each processor, and LSP setup messages sent up to a
central processor.

The Nortel testing issues were a wrong version number in the init
message (bit order was wrong), non-overlapping label ranges, a wrong
length field in one of the TLVs, didn't include the mandatory hop count
TLV, and only supported one message per PDU (Cisco supported multiple).

Nortel has put up version 2 of its LDP recognition code at
www.nortelnetworks.com/mpls that includes these fixes.

Cheng-Yin Lee, draft-leecy-mpls-loop-avoidance-00.txt

The primary motivation for this work was to prevent loops in multicast
LSPs.  The proposed algorithm can be used in both unicast and multicast
LSPs.  The primary problem solved is how to graft a node onto a tree.  A

SLICE message is sent to the root, and when an ACK is received, the node

can be grafted to the tree.  This is done in separate signaling from the

basic path setup.  This can be used for p2p, mp2p, and p2mp LSPs, as a
clean, scalable method for avoiding loops when setting up LSPs.

There was no action taken regarding that draft, to give people a chance
to read and comment on it.

Ron Bonica, draft-bonica-icmp-mpls-01.txt

This presentation was proposed extensions to ICMP to support MPLS.
These are being suggested in order to produce an MPLS-aware traceroute
to allow the path taken by MPLS packets to be discovered or verified.
Ron discussed current traceroute and how it could be extended to include

labels from the label-switched path.  The output would include the MPLS
labels and any other information of interest from the MPLS header, such
as the EXP bits.

The current behavior when an LSR cannot forward an MPLS packet has its
MPLS header stripped off and a regular ICMP message is returned to the
source.  The proposal is to append the information from the MPLS header
to the ICMP error reply.

They had to be backwards compatible to current ICMP and they also wanted

this to be extensible.  They have proposed a set of optional objects
that can be added to any fixed-length ICMP message.

Q: How do we know that the source is in the label switched path, and the

labels are not significant to it.  A: We don't care - this is just for
reading traceroute output in order to debug label-switched paths.  In
some cases, the output is useful as a hint as to which router to log
into in order to debug a particular problem, or to read its label
information base.

Ron proposed for this to be advanced to a working group document.  This
was accepted.

Dirk Ooms, draft-ietf-mpls-multicast-00.txt

This was previously draft-ooms-mpls-multicast-02.txt and has been
accepted on the email list as a working group document.  Dirk discussed
the changes from the previous version of the draft.  The major changes
were in state coexistence and piggybacking.  Their long-term intention
is to make this an informational RFC, but it is not yet ready for WG
last call.

Alex Mondrus, draft-wu-mpls-multicast-te-00.txt

Alex discussed traffic engineering for MPLS multicast LSPs.   He
described two methods of building a multicast traffic engineering tree,
sender-initiated trees and receiver-initiated trees.

Cheng-Yin Lee, draft-leecy-multicast-te-00.txt

This was another draft on the this topic.  The goals were to be able to
select paths based on diverse traffic engineering criteria for multicast

traffic, and to reduce resource allocation states within the
traffic-engineered network.

The proposal partitions the multicast traffic engineering problem such
that multicast routing protocols do not have to be modified to setup
engineered routes or allocate resources for multicast traffic, nor do
resource allocation protocols such as RSVP or CRLDP have to be able to
set up forwarding states.  Allocated resources are not associated with
particular multicast groups, but with multicast LSPs.  This is done by
extending the multicast routing protocol's JOIN message with the traffic

engineering parameters.

Q: Are you trying to do inter-group aggregation, to support
heterogeneous receivers?  In that case, you could use pre-setup LSPs at
L2 and share the resources.  A: Yes, you can do this offline, but their
goal was to be able to do this dynamically as well.

Discussion is going to continue on the list.

Alex Mondrus, draft-mondrus-mpls-attribute.txt

When MPLS signaling sets up a LSP, it uses layer-3 topology, so if the
source-head of a LSP calculates the source-route to a destination, it
cannot take into an account if the IP interface is MPLS-capable or not -

it has to assume that they are all MPLS-capable.  They could not be
MPLS-capable either as a result of configuration or because MPLS is not
implemented on the router.

When the proposed MPLS-capable attribute is used, it allows routing
protocols to automatically detect the IP interfaces which support MPLS,
to aid in the setup of LSPs.  The proposed attribute would be flooded
using an IGP. Both IS-IS and OSPF can be used for this purpose.

Q: Yakov Rekhter asked why this is necessary, since this information is
already available.  Curtis followed up on this by noting that OSFP and
IS-IS already have attributes to advertise traffic engineering
attributes, and whether or not an interface or router supports MPLS can
be inferred from these TLVs.  A: TE attributes can be used to infer that

an interface is MPLS-capable, but they may not be advertised for all
MPLS-capable interfaces.

Q: Peter Ashwood-Smith asked how do we know whether RSVP or CRLDP is
supported on a particular interface?  Curtis answered that different
colors could be used for RSVP and CRLDP, but he doesn't know of any
service providers that want to do this.

Curtis also asked what the value is of advertising TE information on
non-MPLS-capable interfaces?  He couldn't think of any.  Yakov agreed
with this.

Further discussion is going to be taken to the list.

Hans Sjostrand, draft-ietf-mpls-ldp-mib-01.txt

The LDP MIB has been dormant for a while, and work is going to be
revived.  Hans presented an overview of  what's changed since the last
version.  It very closely follows the LDP specification.  The proposed
OID tree is MPLS -> MPLS Protocols -> LDP.  There are five tables in the

MIB: LDP LSR, LDP Entity, LDP Peer, LDP Session, and LDP Hello
Adjacency.  An ambiguity regarding the relationship between LDP
entities, peers, and sessions were cleared up.  A new IANA
Considerations section was taken from the NHRP MIB.  There are new
objects in the MIB for loop detection and loop prevention.

Their to-do list before the MIB will be final includes updating the
front section, making it less ATM-centric, updating the MIB based on the

most recent LDP version, adding a model of the Label Information Base,
and updating the conformance statements.  Their intention is that all
MPLS-related MIBs are consistent and non-overlapping.

They intend to produce a new revision of the MIB draft around late
August or early September.

Q: Bob Thomas raised an issue regarding the mapping between entities and

sessions - he feels they should not be one-to-one.  A, from Jim Luciani:

This will be fixed in the next draft - it's not really one-to-one.

Bob also had a few other comments.  He feels changes are needed in both
the entity and peer tables to make the MIB less ATM-centric, and was
curious how it was going to be done.  Hans discussed some of the
required changes that need to be made.  In some cases, they're still
working out the details, and this will be further discussed on the list.

Q: There was a suggestion to have separate trees for each kind of
interface, and have the interface-specific information in each of these
trees.  A: This sounds reasonable.  Q: Should there be more than one
label range per session?  A: Yes, this also needs to be fixed.  Q: What
is the purpose of the default VPI/VCI?  A: This is the MPLS control
channel, as specified in the MPLS over ATM draft.  George suggested that

the name be changed from "default" for something else, such as
"control".

Q: Alan Kullberg asked about the adjacency table index.  A: We plan to
change this.

Heinrich Hummel, draft-hummel-mpls-explicit-tree-01.txt

Heinrich spoke on the explicit tree routing draft.  He gave an
introduction to the draft and discussed the changes since the
Minneapolis meeting. This draft proposes the TREE ROUTE TLV, which
encodes a tree structured route, either for multicast or for
multipoint-to-point LSPs.  The TLV carries explicit routing information
describing the tree topology.  The draft also specifies the progression
of the TLV from the root of  the  tree to  the  leaf  nodes.  Heinrich
discussed this at great detail.

Heinrich asked that this become an official working group draft.

George felt that this is not a protocol, but a mechanism or TLV, and
that this should be moved forward only if the RSVP or CRLDP authors feel

they need this mechanism to solve a particular problem.  This can't
stand by itself, but Heinrich should ask the CRLDP or RSVP authors to
include this in their specification.  George doesn't see any place in
the IETF to do this kind of work.  Heinrich will try to find someone
that needs to apply this mechanism to a particular protocol.

Open Discussion

Nancy Feldman announced that there is a new version of the framework
document, and that people should read it.  George suggested that people
read it, and then comment on it on the list.

Loa Andersson asked the chairs to discuss the current state of each of
the WG documents.

The architecture and encapsulation drafts are through the IESG and
waiting on the RFC editor.  The FR and ATM drafts are through IESG last
call and are waiting on the LDP draft.  The LDP draft needs to have its
applicability statement discussed between the chairs and routing area
director.  The RSVP and CRLDP specs both require minor revisions and
have them checked by the list, and then moved to IESG last call.  The
VCID draft just completed WG last call.  Traffic Engineering
requirements is also being reviewed by the IESG.