RE: [PWOT] IETF 50 PWE3 Meeting Minutes

["tom k. johnson" <[e-mail]>]

Danny, Giles - 

First off, thanks for the excellent minutes.

One quick question.  This reference to SONET over RTP was interesting...

"Christian - if you stick to IP and RTP then it is pretty much 
done.  Already a group looking at how to match to RTP (AVT WG)

Alison - We saw RTP carrying SONET over there, and these guys have 
it in their charter, but it is a very different payload to AVT.  We 
hope AVT will be sufficient, and these guys will talk to AVT."

Could anybody point me to the revelant drafts, etc. 

Thanks

-Tom



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of Danny
McPherson
Sent: Wednesday, March 28, 2001 8:29 PM
To: [e-mail]
Subject: [PWOT] IETF 50 PWE3 Meeting Minutes



FYI...  Folks, here are the minutes from the Minneapolis meeting.
Thanks to Giles for keeping them (and pretty much every of WGs *8^).   

-danny

[snip]

Minutes of PWOT Meeting
-----------------------
By Giles Heron.


Administrivia (Luca)
--------------------

CEOT fallout led to PWOT

PWOT now renamed PWE3 - "Private Wire Emulation Edge to Edge".


AD slot - Scott Bradner
-----------------------

Hope this session goes better than CEOT BOF.

There is an issue of the relationship to sub-IP.

Trying to tease apart what is being carried from how it is 
being carried.  This WG is focussing on aspects that do not 
include signalling the underlying network.  Should also be 
agnostic to what is being carried other than the next layer 
up.

This is stretching the IETF a bit.  As per last IETF, standards 
process is concerned with IP technology and with technology that 
is created by IETF (e.g. MPLS).  So this WG is going to be dealing 
with IP and MPLS and perhaps L2TP to some degree. Will see how it 
all fits together.  Will be a little funky to separate this out 
from what uses it (e.g. PPVPN.)  Currently in transport area as 
issues are edge to edge.  Unlike PPVPN, or simple encaps such as IP 
over Foo (this is Foo over IP.)  Would like input to focus the 
effort, and to decide if is being aimed correctly and even in the 
right area.

 
Chair intro - Luca Martini
--------------------------

General statement is that providers want to provide the same services 
they have with current packet infrastructures.  Would like interim 
meeting towards end of May.  Announcement will be on 
[e-mail] (assuming we can all agree on charter)

Charter

Want to agree common encapsulation method for transported circuits 
over Packet switched networks.  E.g. If we want to recover timing 
will do it in the same fashion whatever we run over.

Specify common edge-to-edge signalling protocol.  May not be 
possible now, but would be good to write the control plane once 
and use it again and again regardless of L2TP, IP or MPLS.  Want
to have signaling edge to edge for pseudo wire configuration.  And 
want edge to edge signaling for transported circuit status.  Is the 
other edge router OK?  Is the circuit up at the other edge?  Want 
to transport status across network to other edge router.

Want some network management methods (specifically for P wire 
and the circuits it transports). Not taking over work done in 
other WG.

Want security mechanism to protect the control plane.  Don't 
want to protect the user packets (or not in scope anyhow), but 
need to ensure that e.g.  If there is an SP-SP boundary we can 
control the boundary (similar to the current IP/BGP structure.)

Want to specify methods to communicate timing over the transport 
network (will leverage RTP.)

Currently considering L2TP, IP, MPLS.  Encourage suggestions of 
other protocols.

Pseudo Wires = Ethernet, Ethernet VLAN, Frame Relay, ATM, SONET, 
TDM circuit (DS1, DS3.)

? - should put wireless etc. stuff in there.

Some sarcastic comments on X.25 etc.

Luca - let's get some comments, and start working on PWE3.

Comments
- --------

? - fundamental underlying problem not mentioned anywhere.  ATM 
and particularly SDH/SONET have service models.  IP has this, not 
widely used.  MPLS doesn't.  Ensuring we meet these service 
semantics is a non-trivial problem.

Luca - if you have a broken network then pseudo wire will be 
broken.  This  group isn't dealing with how you guarantee that 
service model.

? - will some group do a service model for MPLS that can support 
ATM, SONET, TDM?

Scott - good questions.  This group is focusing tightly on 
encapsulation and edge-to-edge signalling, not on how it gets 
guarantees from underlying network.  So while questions are 
useful and interesting they aren't in scope for this effort.

? - if we don't have someone who worries about this won't we 
get a partial solution which doesn't meet the whole problem?

Alison - Charter has an applicability statement which explains 
what it does and doesn't deliver for each service.

Motty.  Edge to Edge limitation wrt encapsulation.  Might want 
to have broader scope of also end-to-end.  Need consistency on
end-to-end encapsulation of these protocols.  Should be same as 
on edge-to-edge.  Will there be another group.  Motty thinks 
should be in same WG.

Scott - number of compnents.  One is encapsulation.  Another is
edge-to-edge signaling.  e.g. ISP edge box talks to another.  
What is seen by customer looks like Frame Relay.  Edge-to-edge 
signaling is between edge boxes.  Don't want to invent new wheels.

Motty - so edge-to-edge relates to signalling?

?2 - good work done in last meeting wrt Martini draft.  Flood 
of IETF drafts the last couple of months showing alternatives 
for supporting different services over pseudo-wire.  Haven't 
seen a real requirements doc allowing vendors to focus on key 
areas that are required.  Impossible for a vendor to figure out 
exactly what are the behaviours we need to maintain when we 
support multi-services over pseudo-wire.  Would request we get 
carriers to work with vendors.  Would like a requirements doc 
before we propose a solution.

Danny - requirements doc is in the charter and hasn't been sent 
out yet.

Luca - several SPs are getting together to write a requirements 
doc.  Haven't posted yet.  Will be posted shortly.  This is 
independent of WG.  Will propose it should be accepted as WG 
items, and will see what WG says.

Tom Worster.  Would like clarification.  Some of the stuff here 
is a lot like L2VPN as discussed in PPVPN.  Would like to 
understand the difference and whether there is overlap etc.

Danny - signaling is wrt managing the pseudo wire, nothing more.

Scott - yes there is overlap and this group needs to work with 
PPVPN.  PPVPN needs to use output of this group for its wires, 
but it is PPVPN that needs to worry about characteristics of wires 
and where to put them.

?3 - are we trying to reach single encapsulation for any of those 
services over any of these transport services.  What are we doing 
to ensure that this doesn't conflict with other standards bodies 
that are coming up with their own X over Y proposals?

Scott - we are trying to figure out what reasonable encapsulations 
there are for X over Y.  Reasonable number of Xes over fewer Ys.  
There is work being done in other forums - e.g. ATM forum doing ATM 
over MPLS.  Would hope that work will be made visible to this group.  
Don't know if that encapsulation will meet requirements of this group.  
Would prefer not to have different concept of encapsulation over MPLS, 
IP and L2TP.  If MPLS forum's work will do that then fine.  But no 
predictions can be made without seeing the work. 

?3 - how will this group ensure that it can see work in ATM forum?  
Do you want us to resubmit as ID?

Scott - yes.  Work being used here must be an ID, or must be 
publicly available.  Forum's Works in Progress are private.

?3 - assume there is a standard from ATM forum for ATM over 
MPLS and one from here then which one do vendors and carriers 
adopt?

Scott - whichever the community prefers.  Clearly in everyone's 
interest not to duplicate effort.  But sometimes unavoidable as 
have different architectural concepts (e.g. SIP and H.323).  Hope 
that won't occur here.

?4 - comment about QoS.  If don't have QoS then what is the point 
of pseudo-wire.  Many SPs are working on QoS,  e.g. Global Crossing.  
Will be reporting their results.  Personal opinion is that this 
BOF/WG can do its work and that can happen in parallel with SP work o
n QoS.  Most SPs believe the work being done here makes many mistakes.

Luca - QoS is not necessary if you have lots of bandwidth.  There 
are SPs with lots of bandwidth and they won't need QoS to offer 
these services.

?5 - despite listening to WG chairs and AD don't have the slightest 
idea of what protcol work this group is doing.  Also find it scary 
when people talk about common encapsulation.  It depends on what the 
underlying protocol has.  E.g. FR over MPLS doesn't need to carry 
DLCI, but over IP or L2TP it will.  Don't see what criteria are for 
deciding what needs to be included.

Luca - certainly can have common encapsulation which will keep 
vendors happy as only have to build one forwarding engine.  May 
not be most optimal but will be most cost effective.

?5 - will LDP extensions from draft-martini come under scope of 
this WG?

Luca - not if we are trying to come up with common protocol (as 
want something which works for IP, MPLS and L2TP.)

?5 - problem is that many transport protocols come with their 
own signaling protocols.  Doesn't make sense to tell people to 
throw them away when they use "this" protocol.

Luca - agree it might make more sense to have technology-specific
control protocols.  That is a question for the WG.  

Chris - I'm another provider who believes that QoS is not necessary.
It is up to the provider to ensure that the network provides the 
relevant QoS for the wire.

?6 - I completely disagree.  Age old argument.  Want edge to edge
service, but by doing this you will have impact on the service you 
carry over the top.

Luca - I agree in that this group isn't going to stop some other 
group like CCAMP or TE providing paths which meet the requirements 
you have.  It is up to the implementation to merge the use of those 
tools provided by other groups with what we are going to provide 
here.

?6 - I agree with that, but I want the requirements to document 
that, so it doesn't get out of control

?7 - previous speakers were talking about choice of signaling 
protocols.  Might end up with something like Sigtran.  Explained 
Sigtran.  What this allows is native signaling of one protocol to 
go through API layers.  Possibly this gives a common base with 
adaptive layers on top.

Christian Huitema - actually I think this group has made a lot 
of progress since the last BOF, but too bad you still have MPLS 
on the charter.

Luca - But MPLS is in fashion!

Christian - if you stick to IP and RTP then it is pretty much 
done.  Already a group looking at how to match to RTP (AVT WG)

Alison - We saw RTP carrying SONET over there, and these guys have 
it in their charter, but it is a very different payload to AVT.  We 
hope AVT will be sufficient, and these guys will talk to AVT.

Christian - people say what is the point of carrying a circuit when 
you can just carry a T1.  Can just be a vanilla implementation of 
SIP and SDP.

?1 - Replying to speakers who talked on no need for QoS because 
of overprovisioning.  Separation between mechanisms and policies.  
If you say don't need mechanism then that is between you and 
investors.  If you say it does ATM then it will need to meet the 
ATM service model.

Luca - if people really wanted the ATM service model then we'd 
be running ATM to our desktops today!

?9 - Looks like perfect app for next gen radio access networks.  
Subtle interactions between wireless and wireline QoS.

?10 - I don't see people using VoIP to the desktop or to 
their cellphones. (not everyone.)  Whilst we're doing the 
encapsulation methods here it is necessary for this WG to ensure 
that traffic which needs QoS has specific mechanisms in the 
encapsulation which allow it to signal its requirements to 
the underlying network if that capability is there.

Matt (Holdredge?)  - signalling between layers.

?? - Can I suggest we also look at the very high end when we do 
encapsulation.  So look at efficiency.

Luca - we welcome your input.  There will be some point where 
it doesn't pay, e.g. 40 gig circuit on 100 gig circuit.

?10 - there are applications for very high end, lets please not 
burn all the processing power.

Christian - the market for emulation is specifically for single 
network doing multiple services when you have low utilisation?  
But want to comment re low end.  Problem is that your edge point 
may need to be behind firewalls or NATs.  If you don't put that 
in from the beginning then you have a problem coming up.

Luca - I would never design a hard to firewall protocol.

Christan - unintelligible.

Luca - aiming at core, but will consider NAT as well.

Christian - the core market for this is for the low end.  We 
want the low end to operate through firewalls etc.

Scott - meta point that we're not interested in protocols that 
don't work through NATs.

?11 - worry about people using these encapsulation schemes 
thinking that they automatically get the service layer of what 
they are emulating.  Example of DS1.  Expectation is that it 
will go down for some time.  Red alarms etc. sent.  If you 
emulate over IP then it will re-route quickly, so don't get
outage for 3-5 minutes.  Get a "burp".  That is a feature 
not a bug.  For you folks who want to run this over IP please 
recalibrate the service level expectation of users to acount for 
this.

Craig White - Want to respond with comment that I'd like this 
group to allow us to put a testset on and not know if this is a 
T1 or an emulated T1.  QoS seems to relate to latency for some 
reason - jitter buffers should fix that.  Would like to second 
the guy who talked about RTP frame.  Would be interested in a 
generalised method for encapsulating circuits of all kinds. 
Ability to add profile for those things which are different.  
Some things will be needed by all wire emulations.  Some will 
be optional.

?12 summary - is "Pseudo Wire Turing Test".

Tom Worster.  Does this charter allow resurrection of Cells in 
Frames.

Luca - I don't see why it wouldn't.

Luca - if you want to transport ATM cells over Frames you can.  
Not sure why.

Luca - we need to find efficient solution to do this.

?14 - disagree with "Pseudo Wire Turing Test".  It isn't emulating 
a particular wire but a way of extending a particular service.  
E.g. Don't care about ATM service model, just want to get IP over 
this service.  Don't shoot it down just because it doesn't meet 
that.

?12 - yes  I agree.  Shouldn't emulate bugs.  Craig's point was 
didn't want test equipment to be obseleted.  Need to explain to 
customers that this is FR, and maybe has changed a bit.

Luca - will cost you less money etc.

?1 - If you just want to run IP over this then what is the point.

Christian - a lot of people use wires to do stuff other than IP.  
Might do monitoring, or geographic experiments, or old kit that 
needs FR or whatever.

?1 - Fine, but if that is what you want then fully emulate that 
service. Don't just slap an encapsulation around it.

Luca - there are apps that will require the real thing, and we'll 
never be able to emulate 100%.  Don't want to duplicate e.g what 
ATM did with T1 emulation which never worked 100%.  
 
Craig - my rationale is that I want 10 Gig E WAN, and I want to 
allow someone to put SONET gear over it.  How do I carry SONET 
over something that isn't SONET?

?1 - SONET has strict requirements.  Need to emulate these. 

Craig - testset should be the litmus test.  If the testgear 
thinks it is SONET then it is SONET.

Scott - (Non Maskable Interrupt)  We'll send a slightly modified 
version of charter out to mailing list.  Want to get comments back 
based on what has happened today.  Ben's comment on if emulate then 
emulate pure is a point of view, and makes sense for some 
situations.  But have to realise that not everything has to be done 
that way.  If it is complicated and tricky to do FOO2 over MPLS  
(and more so than doing FOO2 natively) then stick to  FOO2.

But there are some applications that are happy to have slightly
different timings etc. and we can carry those.  Will have to see 
as we go along where this applies and where it doesn't.  Don't 
want to get to point where needing something perfect stops us doing 
something good.


_______________________________________________
pwot mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pwot

_______________________________________________
pwot mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pwot