meeting minutes

[Danny McPherson <[e-mail]>]

Folks,
Inline below are the IETF60 PWE3 WG meeting minutes.
Thanks yet again to Matthew for serving as scribe.  Please
send me comments and corrections by 8/20/2004.

Thanks!

-danny & stewart


[snip]

Pseudo Wire Emulation Edge to Edge (pwe3)
=========================================

MONDAY,  August 2, 2004 (1530-1730)

CHAIR: "Danny McPherson" <[e-mail]>
        "Stewart Bryant" <[e-mail]>

MINUTES: Matthew Bocci [e-mail]

SLIDES: Available at http://pwe3.tcb.net/meetings/ietf60/index.html

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


WG Document Status & Charter Update:
Danny McPherson [e-mail] & Stewart Bryant <[e-mail]>

---------------------------
Shows slides on WG document status

These will be posted to the mailing list.  Requirements and  
architecture are in RFC editor queue.
Waiting on some documents:
TDM reqs, ATM encap, SATOP, sent to IESG
HDLC/PPP to IESG.
FCS retention needs update then sent to IESG.
WG last call: Frame Relay and cesopsn
Work in progress: MIBs are going in parallel with other specs

Tom Nadeau: the 1st 3 docs + ethernet MIB and ATM should be ready for  
last call after meeting
Danny McPherson: please send comments to Tom. Most been around for a  
while
Andy Malis: Asked several times for cell transport draft to become WG  
draft.
Danny: noted, OK


Charter Update (ppt)
Danny: We have moved to the Internet area. Tom Narten is area advisor.  
Margaret Wasserman is other AD.
Stewart: Proposed charter sent to Tom. Waiting for comments. Rewritten  
text. No work items have been removed, but some new ones added to  
regularise what we were doing, and in response to suggestions from the  
list.
- Allows more than one emulation for a service (e.g. ATM)
- HDLC/PPP
- OAM
- Transparency
- ECMP

New:
- Including users as well sas SPs
- Interconnections between different PWS and the same PWs
- IP PW
- Congestion



PW Control Word & MPLS BCP: Stewart Bryant & Danny McPherson
------------------------------------------------------------
http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw 
-00.txt

MPLS PW control word.
Control word removed from PWE3 architecture at request of IETF. George  
swallow has a BCP draft addressing ECMP
Control word draft shows how to address ECMP in PWE3
Explains preferred control word.
IANA considerations for 1st 4 bits: 3 ranges
- Reserved
- PW standards track
- Experimental / vendor specific
Registry is a catch-all.

Tom Nadeau: do we have 2 PW types?
Stweart : will regularise text between the two
Sahsa Vainstein: Current PWE3 draft specifies IPv4 and IPv6 types. What  
is proposed if you don't use these for VCCV?
Stewart: Setup a dictionary for PWE3. VCCV is VCCV's issue
Sasha V: May be resolved by allocated special values for VCCV payloads.  
A
Rahul Aggarwal: need to go back to VCCV document and make sure these  
things match
Mustapha Aissaoui: problem is that we use identifier for both control  
plane and data plane identifier. We have to understand how we  
differentiate and signal the two. In some cases may need control word  
for both data and control planes. General idea of a registry is good.
George swallow: If you want to use OAM with control word, you signal it  
and it uses all zeros. Otherwise you have to signal one of the other  
needs.
Dave Allen: PID avoids gratuitous complexity. Be careful.
Tom Nadeau: This is the same PW type as control plane setup. When we  
need a CW with PW type, will use same registry
Dave Allen: Seems like a new way to signal IP. seems complex
Danny: we have PWE3 registry for specific purpose. Ther eis still only  
one.
Stewart: have to ask if this can become WG draft
Danny: send to list and look at Georges draft too.


PWE3 OAM Message Map: Thomas D. Nadeau [e-mail]
---------------------------------------------------------
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-oam-msg-map-00

Changes: aligned with WG input (any-to-any), Aligned with  
draft-aissoui-l2vpn-vpws-iw-oam-01, aligned with MPLS/ATM/FR Alliance  
OAM documents
Trying to work with other groups and not redefine anything
Issues:
- Timing synchronisation between protocols
- End to end vs. partitioned loop model
Does anyone care about end-to-end model?

Dave Allen: yes
Tom: why?
Dave Allen: with end to end, don't care what the notification method is  
in any particular AC. In partitioned case, I'm note sure this is true.  
Want to discuss this with other authors
Rahul Aggarwal: Agrees with point Dave made. Transparent OAM end to  
end, and second is where you break down end to end OAM from PE to CE,  
PE to PE, etc. Need to break down both.
Yakov Stein: both models have justification: trail extended vs. trail  
terminated.
Mustapha Aissaoui: Draft currently has both models used in specific  
contexts. Less of an issue with this draft, more of an issue with  
draft-aissaoui. Plan to discuss on the mailing list.

- Congestion
Do we need to add congestion control like counting lost packets
Danny: need a problem statement, but in priciple yes
Tom: leave a placeholder
George Swallow: just sets up control channels for this.

Tom: need to get document to the ID repository. Sorry, were a little  
late. Also need to include Ethernet OAM over MPLS mappings
Didn't change title, but this is an open question. Respond on mailing  
list. We are fairly close to what we want.


ITU-T Update: Thomas Walsh [e-mail]
----------------------------------------------
Andy Malis presents.
Liaison is available online at IESG liasons site.
X.84 text online at: see slides for URL
Approved for publication in March 2004
Completely based and aligned with PWE3 FR draft, plus some optional  
stuff for end to end PVC status signalling
Needs some IANA actions: FEC128, FEC129, and status code points.  
Several liaisons have asked for this to be formalised
Current IANA procedures, as long as it is in 1st come 1st served space,  
can do allocation while it is still an ID.

Tom Narten: Not just the code points, but also needs the drafts to be  
approved. IANA cannot hand out code points for a registry that doesn't  
exist.
Sasha Vainstein: is not the allocation of the PW type also needed? This  
is in FEC 128/129
Andy: That's true
Luca Martini: No problem: status TLV code points are not reserved
Andy: So really need to get these documents done. FR draft has  
completed editing at v03, but not in time for this IETF. Is on PWE3 WG  
server.
Yakov Stein: SG 13 approved Y.1413, TDM PW document. Contains 3 drafts  
here.
Danny: have not yet seen liaison from SG13, so would be good to follow  
up



RSVP-TE for Multi-hop PWs: Rahul Aggarwal [e-mail]
-----------------------------------------------------------
http://www.ietf.org/internet-drafts/draft-raggarwa-rsvpte-pw-00.txt

Idea is to introduce a problem space, a solution, and get a discussion  
going.
Single hop PW: a PW with only 2 PW demux allocation nodes
Multi-hop PW: a PW with more than 2 demux allocation nodes
Why?
- PWs across multiple domains
Multiple IGP domains and multiple ASs

- PW QoS
SLA with emulated service: signalling QoS parameters such as BW,  
interface types etc

PW redundancy
- Primary PW and backup PW. Shares QoS resources with primary PW on  
common nodes. like secondary LSPs in RSVP-TE

Motivations:
- explicit routing of PWs (QoS provisioning and administration)

Why RSVP-TE:
- look at entire picture, RSVP-TE provides required mechanisms.  
Especially of interest to providers running RSVP-TE
No intent to pitch against LDP solutions. Simply saying that one  
solution doesn't fit all.

Lists capabilities of RSVP-TE
Overview of the mechanisms is given
A few points:
- Convergence requires QoS, multihop, and PW redundancy. PWE3 needs to  
look at all of these.
PWE3 must look at all of these. We feel RSVP-TE fits the bill.

Yakov Stein: anything that helps stitching is good. A few questions  
about RSVP.
- Charter says cannot exert influence on underlying PSN. This sounds  
like we are forcing the PSN to give us something. Not sure how this  
works with different underlying PSNs.

Rahul: Using RSVP for PW signalling. If underlying PSN signalling is  
RSVP TE, then its good. They are orthogonal issues.
Luca Martini: that's not what the draft says. Nobody is preventing you  
from using RSVP TE with one tunnel per PW.
Eric Rosen: Nobody would use one tunnel per PW. Could use BGP for  
setting up the PW ;-) We already have two ways to setup a PW. We need  
to understand what we can't do with existing protocols. No issue with  
QoS in the PSN (tunnel does this). Doesn't see what RSVP gives you  
here, or understand sharing of BW
Rahul: need to TE the PW over several hops. Tell me how to do this with  
LDP?
Eric Rosen: want to have some architecture to see what is missing from  
today's protocols and see the requirements.
Rahul: once you want PW QoS you need this
Kireeti Kompella: should we just do auto-discovery with RSVP, or LDP?
Dimitri Papadimitriou: what prevents us from progressing enhanced  
requirements?

Stewart: continue on the list



PW Switching (Inter-provider/AS PWs): Luca Martini [e-mail]
------------------------------------------------------------------
http://www.ietf.org/internet-drafts/draft-martini-pwe3-pw-switching 
-00.txt

Trying to solve inter-domain PW problem.
Slides show an overview of the problem.
Sometimes don't want reachability info to be passed between providers,  
or you may have multiple PSN technologies.
Proposes additional control plane between ASBRs, and between ASBRs and  
PEs
Not meant to be a new protocol, or to make LDP scale better. LDP scales  
very well already; this does not have same issue as BGP.
Illustrates differences.

Peter Busschbach: So this is really for inter-provider communication.  
This is not clear in the draft. I like this for inter-provider. For  
intra provider,  would have to configure switching points
Luca: don't confuse auto-discovery with this. Configuration of this can  
be dealt with L2VPN draft.
Peter B: This goes back to previous discussion. If inter-provider, this  
makes sense as you don't want to exchange all information. But, would  
be more comfortable if we had clear requirements. However, thinks RSVP  
TE draft makes more sense for intra-provider.
Luca: Auto-discovery doesn't come with RSVP-TE. Can use BGP with this  
draft.
Kireeti Kompella: We need requirements for stitching and for QoS for  
PWs before we go down the path of solutions. These are new aspects.  
Also, if you take LDP and add all these things, we get CR-LDP.
Luca: unclear whether you need to actually signal the QoS. Most  
implementations don't use single sided signalling.
Danny: take it to the mailing list. Need a requirements draft.



PWE3 QOS Signaling: Himanshu Shah [e-mail]
--------------------------------------------------
http://www.ietf.org/internet-drafts/draft-shah-pwe3-qos-signaling-00.txt

Presents a list of requirements:
QoS is an inherent attribute of the service
Typically service delivery with a specific QoS is realised by  
configuring appropriate parameters.
The sender of the PW FEC provides guidance for the receiving PE
Should be backwards compatible with the existing LDP protocol.
Explains the proposed solution.
Can use the same mechanism for congestion notifications
Comments:
- Policing upstream would not make sense
- This is not a QoS TLV, a traffic parameter TLV
- Should not use for congestion indication
- PW affects the traffic stream, to signalled parameters do not  
indicate this




Dry-Martini: Ping Pan [e-mail]
------------------------------------------------
http://www.ietf.org/internet-drafts/draft-pan-pwe3-over-sub-ip-00.txt

This gives a PW perspective to IP centric technology for Sub IP traffic
An aggregation mechanism.

Shows how dry this could be:
Shows how you can aggregate through any

Eric Rosen: clearly out of scope. This is PWs over no PSN.
Ping Pan: No, PWs over any layer 2 network
?: ITU SG13 is working on this very problem: Ethernet over SDH etc
Ali Sajassi: Are you doing the whole thing to save one label at the  
edge of the network? Don't need IP/MPLS in network.
Luca Martini: Don't understand what you are trying to do. Do you want a  
statement as to what the PSN is? GMPLS? ATM?
Ping Pan: Can allow any PSN
Yakov Stein: Can't use TDM on it's own. You need something to get a  
packet across it.
?: For MPLS over SONET, can just use PPP
Dave Allen: This is a valid scenario. PHP will replicate this  
behaviour. Control plane draft acknowledges this.




CESoPSN and WG LC: Sasha Vainshtein [e-mail]
----------------------------------------------------
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-01.txt
Reviews the main issues raised in last call, Reference PE architecture  
is clarified, simple vs. enhanced NSP
Draft is now in last call after fixing issues raised
Yakov Stein: Last 2 issues are questions of trail terminated vs. trail  
extended
Sasha: want to do trail terminated
Yakov: please add wording for which model you want

TDM Extensions to PWE3: Sasha Vainstein
---------------------------------------
http://www.ietf.org/internet-drafts/draft-vainshtein-pwe3-tdm-control- 
protocol-extensi-01.txt

Lists motivation for control protocol extensions.
Setup of TDM PWs needs additional parameters, but these were not  
included in any of the encapsulation drafts.

TDM PW over UDP and TDMoIP Updates: Yaakov Stein [e-mail]
---------------------------------------------
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdmoip-02.txt

Issues: UDP/IP based PWs in PWE3 architecture
UDP/IP extensively deployed in TDM PWs
ITU-T SG13 has questions about this too

Where do we put PW label?
- destination UDP port should be a registered value
- source UDP port number = PW label

The constraint about using the destination port number is to get  
through NATs and firewalls. Can get through with relatively few changes

How do we distribute the label?
use a well known port number at the begining to exchange port numbers
Asks for immediate decisions on where to put PW labels, and what label  
distribution methods

Sasha Vainstein: alternative 2 looks like what L2TPv3 lets you do over  
UDP. Source IP address identify uniqueness
Yakov: That gives you the tunnel
Sasha V: not so
Stewart Bryant: what are security implications of implicit method?
Eric Rosen: We already have 3 ways of doing this over IP networks.  
Don't see why we need another way.
Stewart Bryant: please consider this request from ITU-T as they have  
asked for an answer

Other TDM updates:
Explains trail terminated vs. trail extended OAM models
Explains performance OAM



IP Pseudowire Encapsulation: Florin Balus <[e-mail]>
--------------------------------------------------------------------
http://pwe3.tcb.net/draft-balus-pwe3-ip-pseudowire-00.txt

Defines motivation and requirements for IP PW. PWs used for transport  
between unlike ACs, but traffic is known to be IP.
Ensure consistent PW OAM. Maintain same datapath for OAM and data  
frames using IP PW
Explains control word:
IP header already has length and fragmentation fields, so don't need  
this and set to reserved.
Pass the layer 2 discard priority bit using the D flag, signal FR  
congestion using B flag

Any Malis: ARP mediation draft already covers this
Florin: No it doesn't
Luca Martini: RFC1332 is encapsulation for this
Florin: control word moves this into the PW domain
Luca: IP already has TCP, and QoS parameters.
Florin: SP cannot touch IP header on PWs
Ali Sajassi: jist is to take care of ECMP. This is one instantiation of  
control word draft. Can incorporate this in control word draft
Florin: need to discuss on the list where this should go



PWE3 Control Protocol Extensions:       Mr. Cagatay Buyukkoc  
[e-mail]
------------------------------------------------------------------------ 
-
http://www.ietf.org/internet-drafts/draft-yudong-pwe3-control-protocol- 
ext-00.txt

The presenter claims there is an issue of scaling when there are large  
numbers of tunnels.
Introduces a reflector to reduce the number of T-LDP sessions from N^2  
to N
Extensions to LDP: simple relay mode where reflector participates in  
sinalling messages, but not in routing
Second mode (next hop self mode) reflector participates in routing as  
well
Explains the stitching points of the PW and an auto negotiation of the  
capability to support the reflector.

Tom Nadeau: Is this basically another PW switching mechanism? Earlier  
consensus went a couple of ways, We need to write requirements. This  
could be one of several ways to do PW stitching.
Cagatay Buyukkoc: can also be used for inter AS
Stewart Bryant: please continue this on the list


MEETING CLOSES