Subject: Draft Minutes from Pittsburgh

From: George Swallow <[email-masked]>
Date: Thu, 05 Oct 2000 17:28:17 -0400

Minutes MPLS WG , Pittsburgh, Aug 2000
======================================

Wednesday        9:00 - 11:30            

1.  A Banerjee   kompella-mpls-ospf-extensions-00.txt
                 kompella-mpls-ospf-extensions-00.txt                

These drafts specify extensions to the IS-IS/OSPF routing protocols in
support of Multiprotocol Lambda Switching (MPL(ambda)S). In particular
they specify TLVs describing the capabilities of links which can be
used and signaled with gerenalized MPLS signaling.

Proposal:

Propose that drafts be accepted as WG document.

George (as chair):

Those drafts should actually be progressed as WG document  
in ISIS and OSPF WGs.  They were presented in MPLS WG because they
relate directly to documents that are the subject of MPLS.

Banerjee: agreed. Will progress through ISIS and OSPF WGs.

2.  Mannie        mannie-mpls-sdh-ospf-isis-00            

This draft specifies and suggests extensions to the OSPF and IS-IS
routing protocols in order to support the routing of dynamically
established SDH/SONET circuits using the MPLS architecture.

It builds upon existing OSPF/ISIS extensions, proposing TLVs for
routing of SDH and SONET circuits.  It also proposes Bundling for
scalability (see below).  It also addresses interworking between SDH
and SONET.

An important challenge is to achieve the optimal balance between the
amount of information need to make accurate routing decisions and the
cost of advertising that information.  There can be many "holes"
fragmenting the capacity. Possible solutions:

  - advertise exactly what's allocated-->optimum but very large overhead
  - advertise min and max--> small overhead but difficult to optimize
  - propose compromise: advertise per type of signal what is available

Some further challenges remain (e.g. scalability, factoring time 
constraints,..)

Conclusion: - need to find compromise between optimum routing and
  scalability constraints of ISIS/OSPF

Authors: will integrate OSPF/ISIS extensions with
  <kompella-mpls-isis/ospf> drafts to go to ISIS/OSPF WGs

Ping: - this is a lot of info to advertise. Should some info not be
distributed via SNMP or Policy otherwise it won't scale?

Mannie: - Yes. There is a question as to whether ISIS/OSPF are the
right protocols for all that. May be possible in small areas. Plan to
do some simulations.

3.  Bundling

Two drafts were presented, kompella-mpls-bundle-02 and
rs-optical-bundling-00.  Disposition was deferred until both drafts
were presented.

Kompella    kompella-mpls-bundle-02      

This draft proposes bundling at the "protocol" level.  This is
necessary for routing scalability.  Bundling at Layer 1/2, while
scalable, defeats the purpose.

A bundle does not make a bigger link of smaller links. It is simply a
means to advertise many links more efficiently.

The draft proposes a notion of Max LSP bandwidth as a means of masking
the actual bandwidths on particular links.  The Max LSP bandwidth is
simply the bandwidth of the largest reservation that could be made at
this point in time at a particular priority.  Bundling can be used
with Forwarding Adjacencies, and with unnumbered links.  Also
presented were the procedures associated with the use of Link Bundle
and use of Max LSP Bw by Constraint Based Routing.

Proposal: make this a WG document

George (as chair): need first to get consensus on the approach and then split into 
different document for the different WGs.

Curtis V: the LSP max bandwidth should depend on the LSP type(L3PID)
because in some case you can split an LSP over the multiple links.

Xxx: does this approach take into account delay?
George: links with different delays have to be in different bundle.

Saha        rs-optical-bundling-00    

The draft describes the issues that arise when optical links are
bundled, and proposes a rule for bundling optical links.  This work is
complementary to the work of kompella-mpls-bundle-02.  It proposes
that Bundle be divided into sub-bundles (aka Bundle Groups).

Kireeti: sub-bundle don't buy you much compared to TE bundle 
approach. They were useful with unnumbered links but this is 
supported with TE bundle. 

After a brief discussion, it was agreed that there was general
consensus on using the approach outlined in the kompella draft without
adding sub-bundles.  New drafts for the appropriate work groups will
be drafted.

4.  Ashwood-Smith   ashwood-generalized-mpls-signaling-00   

http://www.labn.net/docs/gmpls.pdf has the presentation slides.  

In Adelaide a number of drafts on this subject that were presented.
The authors of those drafts agreed to work together to produce
framework, signaling and routing drafts.  This draft represents a
consolidation of the signaling aspects.

GMPLS signaling involves extensions to RSVP-TE/CR-LDP to support 
traditional statistically multiplexed, time division, frequency 
division and space division-multiplexed paths.  This draft describes 
a generalized label structure (generalized label request, generalized 
label, suggested label and label set) for MPLS and new functions: bi-
directional LSP establishment, a generalized notification mechanism 
and ingress/egress binding.

Generalized label request specifies the LSP encoding type, link 
protection type and G-PID.  The generalized label travels in the 
RESV/Mapping message.  It also supports traditional statistically 
muxed labels.  It consists of a Link ID and  Label.

The Suggested Label is a generalized label that is given by an 
upstream node to a downstream node in a PATH/Request message.  The 
downstream node should try to use this label and pass the same label 
back in the Mapping/RESV message.

The Label Set is attached by an upstream to a Request/PATH message 
and is used to restrict the choice of the downstream node's label to 
this set.  It is literally a set of generalized label objects.

Lou Berger presented the new functions that are driven by generalized 
switching requirements.

The bidirectional LSP is established by passing an upstream label in 
the Request/PATH message.  There is a possibility of contention for 
the same label when both sides can allocate for the same direction.

The notification function expedites notification of non-adjacent 
nodes of LSP events.  E.g. may notify ingress of LSP failure to 
reduce latency of end-to-end failure recovery.

Egress control enables the ingress of an LSP to control egress
termination.  This may be used to splice LSPs.  A new "Egress Label"
subobject has been defined.

Going forward, the authors will:
- investigate a better way to signal "LSP Encoding TLV"
- verify SONET/SDH label formats
- allow selection of time slots and lambdas via ERO
- minor editorial and other fixes
- incorporate feedback from this meeting
Once the functionality is stable, they will split the draft to 
separate the functional description from protocol formats.

Lou: proposal to accept this as WG document.

George (as chair): Proposed to the group to accept as WG document.
The document was accepted as a WG document. No objections from the
floor.

Floor: suggest to collaborate with ITU on Waveband definition
Peter AS: 100% agreed

5.  Guo             sorrento-rsvp-bi-osp-00    

This draft describes motivations for bidirectional setup of Optical 
paths:
	- faster set-up
	- optical continuity

It proposes a proposal to reduce "contention" window to 1 hop (through 
ordering of labels).

Proposal: move this into the generalized mpls signaling draft (in 
particular incorporate the pair-wise label allocation)

Jonathan Lang: the contention window is actually removed with the 
"label suggestion" or "label set" capabilities of generalized mpls 
signaling. So the proposal to reduce the contention window is no 
longer useful.

George (as chair): continue discussion on mailing list about whether some 
material from sorrento-rsvp-bi-osp-00 should go into generalized mpls 
signaling.

6.  Bala            bala-mpls-optical-uni-signaling-00  

This draft reflects work at the OIF.  
   
This draft addresses the "domain services" model for an optical
network. Under this model, the optical network provides a set of
well-defined services to clients (IP and others). The signaling and
routing interface between the client and optical networks is referred
to as the User-Network Interface (UNI).  This draft describes the
services provided over the UNI, and the requirements on any signaling
protocol used to invoke the services.  It considers both direct and
indirect interfaces.  It defines abstract UNI messages and associated
parameters

The objective in presenting this work here is to:
  - Guide development of MPLambaS protocols
  - Harmonize extensions with OIF

Conclusion:
  - identifies a MPLambdaS subset to allow support of a simple 
      UNI which can later be expanded
  - note that the draft reflects ongoing work in the OIF and is 
      still work in progress 

Bala: where does this draft belong?

George (as chair): It is useful to have information from the OIF presented here.
The draft itself is not something to adopt here.  Rather it should be
reflected into the actual MPLS WG drafts (i.e. extensions to RSVP-TE 
and CR-LDP for UNI).  We encourage you to keep bringing up-to-date
information on status of OIF work as guidance to this group.

Ping P: this is similar to RSVP-to-ATM, and UNI concept is not useful
Bala: this is not quite the same thing as ATM, and UNI is useful to 
define interface requirements.

7.  Aboulmagd       aboulmagd-mpls-ldp-optical-uni-00 

Create, Delete, Modify and Status Enquiry actions are possible across 
the O-UNI.  This draft argues that LDP already has well defined 
messages to support the O-UNI and there is no need to invent yet 
another protocol.  A proposal was made to consider this draft as a WG 
document.

Xxx: a comment was made that if the IETF is going to follow the OIF's 
recommendations, and the OIF was expecting to introduce major changes 
to the definition of the UNI.  So this is definitely work-in-progress 
at the OIF.

Ross Callon: what is the relationship to the generalized signaling 
draft?  Osama responded that they plan on using as many of the 
mechanisms specified in that draft as possible and the intent was not 
duplicate work.

Peter Ashwood-Smith stated that it is good idea to adopt the document 
as a WG document.

Lou Berger: recommended coordination with the generalized draft.

The document was accepted as a WG document without objection.

8.   Lang            lang-mpls-lmp-01                   

Why link management: The control channel may be on a different 
medium/link than the component links being controlled.  LMP includes 
control channel management, link connectivity verification, link 
property correlation and fault isolation.  The presentation described 
the major changes from the -00 version of the draft.  

The proposal was made to advance the draft to WG document status.

Greg Bernstein: wanted to do link verification and fault management 
differently for SONET than what is specified in LMP.  He wanted to 
know whether we should change the applicability statement for the LMP 
draft.  George said that this should be explicitly stated in the 
document.  

The document was unanimously adopted as a WG work item.

9.   Nadeau          nadeau-mpls-packet-classifier-mib-01

The goal is to provide FEC to NHLFE mapping for MPLS LSRs.  This is 
motivated by customer requirements to specify how packets enter the 
MPLS domain.  The new version is based on comments on the mailing 
list, requesting simplifications.

The ClassifierTable defines rules to compare against incoming packets 
and an action to be taken on matching packets.  The PerfTable 
contains performance statistics on packet classifiers on a per 
interface table.

Tom asked that the MPLS WG adopt this draft a WG work item.  The 
request was approved without objection.

Thursday             9:00 - 11:30            

10.  Le Faucher      ietf-mpls-diff-ext-06     

First last call on version -05 resulted in a number of comments.
These have been addressed in the -06 version.  Second last call
resulted in one comment on the list related to backward compatibility
with LSPs established with pre-Diff-Ext RSVP QoS.  A compromise
solution was worked out on the mailing list.  Francois presented the
details of this solution.  Francois proposed that we incorporate the
text of the resolution in version -07 and he believes that the
document is ready to be sent to the ADs for IESG last call.  There
were no comments or questions.

11.  Le Faucher      lefaucheur-diff-te-reqts-00    
                     lefaucheur-diff-te-ext-00      

Requirements for support of Diff-Serv-aware MPLS TE

The requirements draft was presented in the TE WG; the authors are
driving corresponding protocols extensions in the respective WGs
(MPLS, OSPF, IS-IS).  Current MPLS TE performs constraint based
routing on a single bandwidth constraint.  With Diffserv, there are
additional requirements to ensure the QoS of each class.  These
constraints cannot be enforced by current TE model based on a single
bandwidth constraint.  This requires extensions to current IGPs to
propagate per-class information.  The question was raised whether this
information would place a burden on IGP scalability.  The proposal
suggests to aggregate a group of classes into a class-type for
scalability improvements in IGP flooding.

ISIS/OSPF Requirements
  - minimize impact on scalability
  - Constraint based routing should be able to enforce different
    Max Reservable BW for each class type and retains existing concept 
    of preemption
  - CBR should enforce different Max Reservable BW for each Class Type
    AND enforce an Aggregate Max Reservable BW
  - Support for up to 3 additional Class Types
  - IGPs to only advertise the subset of CTs actually used

RSVP/CR-LDP Requirements
  - Signal CT at tunnel establishment
  - Backward Compatibility

CBR Reqs
  - CBR to take into account different unreserved bw for each CT
  - CBR may also take into account other constraints for each CT

Francois then went through the protocol extensions to RSVP, CR-LDP.
Then he made the proposal that the MPLS WG hosts the work on RSVP-TE,
CR-LDP and MPLS MIB extensions.  The Requirements would be worked on
the TE WG.  He also proposed that MPLS accept the reqts-00.txt as a WG
document until it is better homed, and the RSVP/CR-LDP/MIB material of
ext-00.txt as WG document.

The first part of the proposal was accepted by the WG.  Dave Oran
asked that the proposal be posted to the Routing Discussion group.
The group also agreed to accept the RSVP/CR-LDP/MIB material as a WG
work item.  The final proposal regarding accepting the -reqts-00.txt
was also accepted, based on the understanding that this may get
rearranged once the work gets distributed among the appropriate work
groups.  Curtis asked whether the drafts need to be dissected.
Francois responded that the OSPF and IS-IS extensions need to be
broken off into a separate draft.

12.  Sharma draft-makam-mpls-recovery-frmwrk-01.txt

This draft provides a framework for MPLS recovery.  It also proposes
some evaluation criteria for solutions.  The draft has been evolving
for some time.  This is the latest update.

Proposal: to accept as WG document on track towards Informational 
RFC.

George (as chair): There may be a broader-scope document on recovery
as part of the new Routing Area/Control Plane WG.  This document
applies only to MPLS.  However there is material in this document that
would be appropriate for a broader-scope document. 

Dinesh B: there are a few inconsistencies/redundancies in draft. Will 
discuss on list.

Dave O (AD): what is meant by "extensible to Optical" in draft?

George (as chair): just means that the kind of definitions/procedures
could be reused in a separate document for Optical

Dave O: please send comment on what work belongs where on the routing 
area list.

The draft was accepted as a WG document.

11.  Sharma     Path protection

Two related drafts were presented.  The first describes the
mechanisms.  The second describes protocol extentions for RSVP-TE.
The primary mechanism is the use of a Reverse Notification Tree (RNT)
which is a set of LSP in the reverse direction which merge together as
they intersect on their path to the head end of the tunnels.

A.  draft-chang-mpls-path-protection-01.txt

Changes since last version:

  - Better defined scope, motivations...
  - Completed the features to provide complete solution
  - recognized that solution works for both physically and virtually 
    merged LSPs
  - reduced number of timers
  - ideas for future extensions:
	- mesh based protection, pre-qualified protection
	- priority, preemption
	- unify ideas for notification mechanisms

B.  draft-chang-mpls-path-protection-ext-00.txt

New attribute for EXPLICIT_Route object for path setup and RNT config
Added LABEL_REQUEST object to existing messages

Open Issues:
        - where to encode protection options

Proposal:
        - move Mechanism draft to WG document
        - merge RSVP-TE extensions draft with existing RSVP-TE spec

xxx: concern with reverse notification tree for failure notification 
because itself can be subject to failure

Sharma: there is no activity involved in maintaining the reverse 
notification tree. It is only states in the hops.

Xxx: so we cannot reliably know if the reverse notification tree is 
actually up or not. 

Ping: why define new messages than PathErr or ResvErr?

Sharma: see draft. In particular there is not enough space in error 
field.

Ping: doesn't see why it cannot be achieved via existing messages 
with new codes.

Kireeti: would like to think more on scheme (eg scalability) before 
it is accepted

George (as chair): More discussion to take place before making
this a WG document.  Since we cannot spend more time on this today,
the discussion is to be continued on the list.

12.  Matthews        brittain-mpls-ldp-ft-00  

LDP extensions for Fault Tolerance: Within an LSR, want to switch from
one LDP stack to another LDP stack without affecting data flow.
Specific examples of applicability are for software upgrade, and for
failure-handling such as switching to a backup control processor.

Solution:
        - Let old TCP connection die
        - establish new TCP conn and indicate "continue old session"..

defines :
  - Sequence numbers and Ack (for Fault Tolerant LSPs)
  - Re-sending missed messages

Optional extension to LDP, negotiated as session initialization time

Proposal:
	- that draft be accepted as WG document

Dave O: did you look at SCTP for transport of LDP rather than TCP?
Xxx: there has been discussion on list concluding that SCTP was not 
     mature.
Dave O: would have concluded differently. Let's talk.
Eric R: we shouldn't change the underlying transport protocol for LDP 
        for which TCP has been standardized for a long time.

Xxx: do we need to standardize such mechanisms which achieve Fault
     Tolerance inside a box? cannot inside-the-box mechanisms achieve
     FT?

Phillip M: makes FT a lot simpler, very hard to achieve FT with TCP

The draft accepted as WG document without objection.

13.  Reichmeyer      franr-mpls-cops-00     

COPS usage for MPLS/TE

Kick off policy discussion took place in the MPLS WG in Adelaide. Not
a lot of interest then.  This draft provides more details to see if
there is more interest now in MPLS WG.

The draft describes the application of the COPS for Provisioning 
COPS-PR) protocol for managing TE.

Just to manage TE:
	- tunnel set-up
	- classification of packets onto tunnels
	- LSP tunnel perf monitoring (eg if LSP more than 80% full, 
          setup another,...)
	- Notification

Policy Management Model:
	- COPS-RSVP or COPS-PR?
	- needs to work for RSVPTE and CRLDP
	- policy-wise RSVPTE different from RSVP

Solution proposed in draft is based on COPS-PR. May not be the best 
model.

Describes:
- COPS-MPLS model (with PDP)
- exchange between PDP and LSR
- policy on a per-interface basis

Proposal:
	- is there interest in the WG
	- adopt as WG draft

George:
	- policy is not in our charter
	- should be driven top-down from the policy

Eric R: this does not achieve anything that cannot be achieved by 
existing mechanism (eg SNMP)

Reichmeyer: it optimizes such control

Curtis: TE in real world does not need policy

Brian Carpenter: from IAB, there is not a stable language to specify
PIB yet so it does not make sense to specify a PIB for different
applications until such language is stable enough.

Draft is not accepted as WG document.

Declerc       schrijvp-mpls-end-to-end-auth-01   

Objective is to achieve end-to-end Auth between Label Edge Routers.
Two procedures (and associated TLVs) described:
	- challenge
	- digital certificate

Proposal:
	- adopt draft as WG document

Dave O: let's assume you have security mechanisms on intermediate
LSRs.  Do you need to set-up e2e authorization in situations where you
don't have transitive trust relationship with intermediate LSRs?

Floor: Yes, it is needed

Xxx: agree that there is a need for e2e auth. Would prefer a solution 
     that would not require message to go 2ways.

Declerc: 2nd method achieves that

Vijay (as Chair): There is agreement in room that this is appropriate
item of work for WG. More discussion on mailing list on solutions
before making it a WG document.

14.  Iwata        fujita-mpls-crldp-crankback-01  

Crankback useful for rerouting upon setup blocking and for 
restoration of failed LSP

Changes from previous draft include discussion (in section 2) of 
explicit vs implicit rerouting indication.
Discuss some limits of implicit indication (in some cases does not 
give sufficient info to achieve rerouting)
Proposes that Explicit notification be used, with following 
information encoded in new Codepoint of Status TLV
	- where blocking occurs (link ID)
	- whether alternate routing should be attempted

Proposal:
     - accept draft as WG document for crankback extension to 
       CR-LDP, OR
     - merge with mpls-cr-ldp-00.txt

Billel: not clear what you achieve that cannot be done via te-feed.

Iwata: te-feed is limited intra-area

Crankback draft was accepted as a WG document without objection.

15.  Ashwood-Smith   daft-ietf-mpls-te-feed-01 

This draft aims at improving topology database accuracy with LSP
feed-back.  Bandwidth information is fed back to upstream nodes 
during LSP set-up and set-up failure.

The draft was first presented in Oslo, and was accepted as WG document.

Two type of comments:
  - do not re-advertise info that you learned through feed-back
	--> this is agreed and addressed now
  - questions about race conditions. Act
	---> it actually doesn't matter who win the race
only works within single area, there is room for other mechanisms 
that work inter-area (such as crankback)

Future:
	- could extend for Diff-Serv-aware capability
	- could incorporate some comments from mannie et al

xxx: would it not be useful to feed update info in both directions.

Peter AS: evaluated ideas to send feed-back in both directions and 
also to snoop on feed-back on intermediate nodes. Simulation showed 
that these other variations did not add much.

16.  Peter AS       paraschiv-mpls-lsp-query-00 

LSP Query for LDP/CR-LDP.

Provide extensive information on established LSPs (path, label at 
each hop, free bw at each hop, merge points, future:delay 
estimates...)

Adds a Query Object, with a flag for each info requested. Query could 
travel on Label Request or Query Message.

Query Reply traveling on both Query Reply message and Label Mapping 
message

Proposal:
	- to accept as WG document
	- to be used to accumulate LSP and CRLDP query requirements and 
          protocols (eg ASON/Optical)

Eric Gray: have you considered what happens if an LSR does not 
           support this?

Peter AS: no but it should be addressed.

Draft accepted as WG document without objection.

17.  Theimer         theimer-tcrtp-mpls-00   

Tunneling Compressed RTP in MPLS. Targeted for VoIP Trunking from GW 
to GW.
Started from work in AVT to transport compressed RTP in L2TP.
Tunneling Compressed RTP in MPLS has benefits over L2TP approach:
	- better overhead
	- remove header processing overhead
	- get MPLS QoS benefits
	- get MPLS protection benefits

There are existing proposals for Header Compression with MPLS.  This
draft focuses on end-2-end compression.  End-2-end Compression has
many benefits over hop-by-hop.  The solution proposed in draft
achieves 80-90% compression but is fairly complex.  By contrast,
draft-swallow-,... achieves 52% but is simpler.

Operations:

	- use a pair of unidirectional LSPs or use bidirectional LSP 
          setup if/when supported,
	- defines a mechanisms to establish compression over LSP
	- apply path constraints to get low-loss
	- signaling extensions to RSVP-TE

Some issues:

	- state synchronization in case of packet loss, should be 
          avoided by path-constraints
	- complexity is no worse than hop-by-hop
	- possible reordering

Proposal:
	- it should become a WG document

Andy: points out that draft-Martini provides a mechanisms for 
      transport of PPP over MPLS that can be used.

Dave O: although processing is same between e2e and hop-by-hop it 
        would be spent in different locations which matters.

Lou B: there is a need for both e2e and hop-by-hop anyway.

The draft was accepted as a work group draft.

18.  Berger        ietf-mpls-hdr-comp-over-ppp-00   
                   ietf-mpls-hdr-comp-00            

Changes from Adelaide:
  - Draft-name
  - resolved a bit naming collision
  - draft does not assume or preclude support of CRTP enhancements

Again the end-to-end and hop-by-hop approaches are useful: one is CPU 
intensive and efficient, one is simple and less efficient.

Vijay: had felt that in Adelaide although it was not stated, it was 
       implied that this draft were accepted as WG document.
Lou:   thought it was said but it is not clear in the minutes anyway.

The drafts are now accepted as WG document.

19.  Leu          leu-mpls-ldp-label-aggregation-00   

The motivation for this draft is to conserve the number of LSPs 
needed in a network by aggregating multiple FECs over a single label.
Thus a single LSP carries multiple FECs.  This is particularly useful 
in ATM since the number of available LSPs may be limited.

Proposal:
	- accept as WG document

Curtis: cannot merge LSPs/FECs with different QoS/Diff-Serv

Leu: agreed. 

Vijay: could you not achieve this via a new FEC (eg BGP Next Hop)

Peter AS: could it be implemented in the Linux implementation to 
          demonstrate the benefits.

Ross C: this was discussed some time ago in the context of LDP and it 
        was concluded that you could achieve that by only advertising 
        the address of the egress router.

Chairs: More discussion on the list required to clarify applicability
        and demo implementation would be very useful.  Until it's 
        utility can be demonstrated, the document is not accepted.

---

From: Debanjan Saha <[email-masked]>
Date: Thu, 05 Oct 2000 18:10:05 -0500

> 3.  Bundling

  < stuff deleted>

> Saha        rs-optical-bundling-00
   < stuff deleted >

> adding sub-bundles.  New drafts for the appropriate work groups will

I don't remember any such consensus on using the approach outlined
in the kompella draft.

Regards,
Debanjan

-- 
Debanjan Saha                         Phone: 732-923-4264
Senior Network Architect              Fax:   732-923-9804
Tellium Optical Systems               http://www.tellium.com