Subject: PWE3 Draft Minutes - IETF 61

From: Danny McPherson <[email-masked]>
Date: Sat, 20 Nov 2004 20:34:26 -0700

Folks,
Please send me comments and corrections ASAP.

Thanks!

-danny

[snip]

1530-1730 Afternoon Session II; Lincoln East

Administrivia
-------------

Chairs: Danny McPherson & Stewart Bryant
Minutes: Matthew Bocci
Slides are available on pwe3.tcb.net

Charter & Draft Status - Stewart Bryant & Danny McPherson
---------------------------------------------------------

Working on updating charter with ADs. Danny to send email
  to list with prposed updated and goals and milestones.

Draft status: Stewart

Dependencies:
Lots of dependencies between drafts. Cannot become RFCs until
  dependencies become RFCs. Very important to get this right.
  Draft text may change if dependency text changes.

Stewart carried out a dependency analysis: this is shown
  and looks very complex.

This will drive order in which we send documents to
  RFC editor.

Concerns: Not all normative references are really
  normative. Authors need to double check this.  Also
  need to make sure all things that should be normative
  are called out as such.  Need to check for
  informative refs and docs with no normative
  references.

Base requirements now an RFC.

Architecture: list of dependencies, but one may not be
  correct. Edits sent to the list. Now in editors queue.
  Waiting for fragmentation and L2TP.  This will be RFC.

Fragmentation: needs an updated. Encap refs can be
  moved to control word references.
Andy Malis: Refs to arch can also be changed to refs
  to CW.
Stewart: not sure this is allowed as arch is
  informational.

Arch needs frag, needs control, and control doesn't
  have dependencies.

Luca Martini: Architecture doc should be an informative
  reference becasue you define CW in architecture.

Stewart: Fragmentation called up 2 bits in CW.
Yakov Stein: CW has to be standards track because
  of 1st 4 bits

Luca Martini: Every documents defines the CW bits
  that it uses. CW document is the generic template.

Mark Townsley: would be preferable if description
  was all in one place.

Yakov Stein: important to keep things the way they
  are now for expediency

Eric Rosen: will confise the IESG

Control Word Draft: Most refs to arch refer to sec
  5 and could be deleted. These could be changed to
  arch.   Will respin and send up.

IANA: This is in last call and will be sent out
  as soon as this is completed. Needed to set up the
  registries. Also lots of requests to stabalise code
  points.

Control : This is one of the most strategic docs.
  Past last call, but keeps getting minor change
  requests. This is an urgent gating draft. Need to
  take a hard line on this.

Luca Martini: Also some editorial nits that need
  to be fixed.

Stewart: as long as protocol works, need to draw
  a line in the sand.

ATM and Ethernet: Had 1st go of AD review. A
  few edits to fix.

Thomas: very close to last call.

TDM Reqs in Thomas' queue

SONET needs TDM requirements to get AD review
  before progressing.

SATOP sent to Thomas, but want to resolve UDP
  issues first.

CESoPSN is informational, but want to resolve
  UDP situation too.

HDLC encap: Needs a respin to fix refs.
  Completed last call.

Frame Relay: Needs some TLC. A get well package
  has been agreed, and should see a new rev
  shortly. Style out of step with rest of
  document set. terms need fixing.

Yakov Stein: Titles of encap drafts could be
  standardised or made more consistent.

VCCV: Pressure to move this on. It went to
  last call. Dave Allen's comments have not yet
  been resolved: should be in rev 04, but this
  has not been published yet.  Needs a serious
  edit pass, and should be last called. Depends
  on BFD and LSP-ping.

MIBs: these have a hge cross dependency list.
  Need to make sure procedures are published
  before.

FCS retention: Has standard encap dependencies.
  Not in last call yet.

Andy Malis: it is ready for last call.

Cell transparent mode ready too.
Stewart:

TDMoIP: Need to resolve UDP issue. Appendix
  depends on VCCV. Waiting for comments on 2
  OAM issues.

OAM messag mapping: Big dependencies, so wait
  for others to get out of the way.

Plan:
1. Get -iana-allocation- to IESG
2. Finish -pwe3-cw- and send to IESG
3. Edit -control-protocol- to sort out refs
   and send to IESG
4. Edit ?fragmentation- and then send to IESG
At this point we have the platform needed to
   progress the encap drafts
5) -ethernet-encap-
6) -atm-encap-
Get TDM requirements to IESG, then the TDM encaps
7) -tdm-requirements-
8) -satop-
9) -cesopsn
Then finish the following encaps as they become available
<draft-ietf-pwe3-frame-relay-03.txt>
<draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt>
<draft-ietf-pwe3-sonet-09.txt>

When we have made progress on the above we will
  promote the other work to the priority list

Architecture draft is in editors queue. Waiting on
  frag and L2TP. CW dtaft will be standard. Arch
  will be informational.

Yakov Stein: why is CW standards track, if it is
  not refered to as normative in other docs.

Luca Martini; Titles are not consistent. Most say
  MPLS/IP, some say just MPLS.... Want comments on
  changing all of the titles and making them
  consistent.

Danny: take to list.

Mustapha: is CW is informational, why not just
  merge back to the architecture draft.

Danny agrees that this is an issue that needs
  to be addressed.  Will take offline.

PW CW - Stewart & Danny
-----------------------
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cw-00.txt

There was lots of work after last IETF. Introduced associated
  channel concept. Only use of 001 encapsualtion is for associated
  channel for OAM traffic. This needs a formal definition for
  associated channel. Suggestions to the list on this. Other
  format ID values are available for additional purposes.

Yakov Stein: word channel clashes with the use in the
  architecture draft Stewart: propose some text to the
  mailing list.

Channel type will have its own registry. Plan is to grandfather
  VCCV value (21). Some errors in the text around IANA
  assignment.

UDP Statement to ITU - Stewart
------------------------------

This is one of the most discussed issues. TDM encaps are
  being pursued in SG13 as well. UDP encaps are only used by
  low speed TDM.  IETF documents are vague on use of UDP.
  Need to resolve this before we can go forward. The ITU
  started to talk about introducing an expected mechanism
  for handling the ports. 5 techniques proposed in
  liaison. Extensive comment on this to the list. Unable
  to reach consensus. Statement proopsed to the list.
  Essentially says PWE3 deals with L2TP, and MPLS
  tunnelled over IP. Unable to reach consensus on whether
  we need a 3rd method, so unable to give advice to
  ITU on where to go next. However, are willing to listen
  to proposals on how to carry PW over UDP, but anyway
  will need to consider issues such as congestion,
  security, and specific application.

UDP Encapsulation - Yaakov Stein
--------------------------------

Service provider model is presented. Emulation is PE to
  PE. IWF is located in the PE. AC is natve service.  Encap
  sits at the PE. Becomes MPLS at the PE. However, another
  model is that the iwf is at the CE. The AC does not
  run the native circuit. 3 possibilities:

- MPLS AC
- UDP/IP AC
- other AC possibilities (L2TP, MPLS over IP, native
    service over IP using GRE, etc)

Lively thread on the list. Over 50 emails from 16 participants.
Advantages: UDP/IP familiar to customer base, PW label as UDP
  port no. reduces overhead, already extensively deployed for TDM PWs,
  reuse of AVT protocols, simplify NAT traversal.

Disadvantages: had to provide QoS without c/o pt-pt trail.
  Cannot be layer network above UDP. UDP doesn't scale, not
  enough port numbers and increases NAT/firewall state. Need
  protocol for UDP port signalling. UDP checksum needs to be
  calculated. Why a new PW type at a late stage? Security
  and congestion control

Other comments: need to reply to ITU liaison, PWE charter
  aimed at operators, not enterprise customers, wrong, but
  how to stop enterprise using it, no consensus, should
  divert to AVT, but CE-CE PWs not in AVT charter, UDP
  OK for VoIP since adapts an application, some comments
  seem to rule out MPLS

Presents an rebuttal:
- QoS similar to LDP based MPLS or L2TP
- Enterprises don't need large number of UDP ports
- Scales better than VoIP today
- can use manual port provisioning
- UDP checksum can simply be set to 0
- PW type has been in the charter from day 1
- Security: LDP and L2TP protocols are similarly unsafe
- Congestion similar to L2TP

Proposal:
Explicitly limit UDP/IP to enterprises (CE-CE case)
- only allow manual provisioning
- enterprise responsible to security, congestion avoidance
- MPLS should be used if large numberof PWs needed.

Stewart: would like comments to help draft ITU response

Sahsa: Agrees that there is no sense in developing a
  control protocol for UDP PWs. Don't understand what
  enterprise PWs means.  If it connects to a class 5
  switch, what is it? ALso not sure that admission
  control should be up to the customer.

Yakov Stein: On congestion avoidance, that link that
  is UDP will sufer. SP can discard excess traffic.
  The access PW is the point from the CE to the core
  network.

Sasha: Confused. Are UDP PWs aonly a part of Multi
  hop PWs?

Yakov: yes

Sasha: don't know what to do with MH PWs

Eric Rosen: is is too late to remove this TDM from
  charter entirely?

Stewart: many people want to work on this

Eric: if you want to get this though, stop drawing
  attention to the problems e.g. NAT, signalling, how
  you do multiplexing, seems to need to be manually
  configured to interoperate. Solution is to take UDP
  out and leave up to SG13, or only have manual
  configuration. IESG may still notice this. Better
  to leave this in the hands of the ITU.

Luca Martini: Be careful and write a good security
  section. You are mixing control protocol with data
  planes. We are very exposed here.

Danny: We are trying to define protocols, not how
  and where they are deployed. A lot of concern on
  how to scope enterprise vs. service provider here.
  We need to assume the protocols defined here will
  be deployed in the Internet.

Stewart: can either:
- not respond
- say unable to reach consesus
- say we recognise that there are limited cases where
UDP would be appropriate, supported by manual
  configuration

Scott Bradner: You have about a week to honor
  tradition and not respond, but it would be
  better to send them a response

Thomas Narten: be pragmatic and reasonable. If we
  don't respond, what will happen?
Stewart: we have an opinion as to how UDP is correctly
  operated. We have a duty of care.
Yakov Stein: reason this was sent was that this was
  going to be progressed in SG13. If we cannot reach
  consensus, SG13 wil l do what it wants.
Scott Bradner: ITU is trying to work with us. We
  should cooperate going forward, even if it is to
  say that we don't have an opinion. We must not
  ignore them.
Thomas Narten: AGrees. We can give our thoughts.
  We may not like what they want to do, but ghould
  explain why.
Mark Townsley: could say PWE3 doesn't care. Is there
  some work to do at an IAB level on what you do with UDP?

Craig White: We do need to send a fairly strong
  statement similar to what eric expressed, but
  need to be cognisant of the fact that they have
  implementations. Need to say that on the Internet,
  this is not an appropriate use, but may be
  appropriate in a private network. be aware of
  issues if it gets connected to Internet at any
  time.
Scott Bradner: What is magic about UDP in this
  context?
Stewart: this was not an issue until it was noticed
  that we needed a port assignment protocol
Scott Bradner: This working group was formed with
  the assumption of UDP and MPLS
Craig: congestion avoidance problem with UDP
Scott: no real difference
Yakov Stein: ITU would be happy to hear that we only
  want manual configuration.
Luca Martini: We also have an implementation of this.
  Bottom line is that a better design is L2TPv3 and
  this should be used instead. IETF thinks this is
  a better idea.
Eric Rosen: 2 issues: signalling. Suggestion that
  you could use LDP, with port numbers instead of
  labels. DO you use source or destination port?
  What about NATs? not sure we can come to
  consensus, except you need to manually configure
  it.

Stewart: We do not recommend UDP, but L2TP. If
  you use UDP, you so manual config.

Yakov Stein: why?

Stewart: Responds saying we recommend that you
  only do manual configuration of the ports.

Mark Townsley: ...and if you want to do
  automatic configuration, use L2TPv3 Issue with
  UDP is that it can cause problems for NATs. Some
  of the arguments made on the list are significant.

Yakov Stein: why does RTP group get away with this?

Shasha: Neither MPLS nor L2TP are suitable for
  NAT traversal. Could say: No signalling protocol,
  should not be used in NAT environment. Agree
  that there is substantially more VoIP and so
  we could say that UDP already used for VoIP
  sessions with operational success.

Mark Townsley: L2TPv3 deigned to run over UDP.
  Every NAT knows how to do L2TPv3 as in RFC2661
Thomas Narten: Liaison doesn't ask if it is a
  good or a bad thing. It asks how to do port
  number stuff. We should answer the question.

Stewart: Our advice is that this is only done
  in a manually configured mode, and anything
  more advanced should be made as a proposal
  to the PWE3 group.

Yakov Stein: pick one and send it back already!
  Pick manually configured, but use L2TPv3 for
  signalled

Consensus around this. Propose to the mailing
  list by Friday afternoon.

PW Multi-Hop Requirements - Luca Martini
----------------------------------------

Presents the outcome of the requirements team.

Last IETF was a discussion about PW stitching. Since
  then, we had a long drawn out email thread. Concluded
  we needed a requirement document.

Document not achieved by this IETF deadline.

Met face to face. We are regrouping, and trying to
  produce a draft by the end of november
  concentrating on requirements for this technology.
  This will guide if we need to do any more protocol
  work.

Open Microphone
---------------

Luca Martini: What is the state of the rechartering?
Danny: Will provide an update on the charter, goals
  and milestones on the mailing list.

Meeting Adjourned

---

From: [email-masked]
Date: Wed, 24 Nov 2004 14:36:44 -0000

Danny,  Thanks for the notes.

I have an observation on the issue of PWs over UDP.  Please see
below....I have taken a couple of extracts:

<snipped>

><snipped>

>   consensus, SG13 will do what it wants.
<snipped>

>   want manual configuration.

It's my understanding (from the BT guy present in Q5/SG13) that there
are no SPs asking for this in ITU, and only one manufacturer is pushing
it there.  I don't recall hearing any SPs supporting this on the PWE3
list either (and I did ask a couple of times), or indeed any other
manufacturers strongly supporting it except the same one.  So I don't
want IETF to get the impression there are whole bunch of SPs in ITU
baying for this and intend to use it in weird/wonderful ways when
(AFAIK) there are none.

Please correct me if any folks know otherwise.

regards, Neil

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 24 Nov 2004 19:00:11 +0200

Neil, 

Actually there are quite a few manufacturers doing this, 
and interested in its becoming a standard.

About service providers, as I stressed in my talk
(which unfortunately you were not present to hear,
 but you can see the slides on Danny's site)
this solution is for the enterprise (CE-to-CE) case,
not for the SP (PE-to-PE) one.

Y(J)S