Subject: CEP-09 - RE: PWE3 Draft Minutes - IETF 61

From: "Ron Cohen" <[email-masked]>
Date: Wed, 8 Dec 2004 14:56:05 -0800

Danny,

> 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>

Draft-ietf-pwe3-sonet-09 has been submitted in August 2004 and is
available since then. It includes resolution to all comments received
via the mailing list after last call. I don't see anything that needs
finishing here.

I suggest the plan be to get the TDM requirements to IESG and following
that put the SONET draft on IESG queue. 

Thanks
Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Danny McPherson
> Sent: Saturday, November 20, 2004 7:34 PM
> To: pwe3
> Subject: [PWE3] PWE3 Draft Minutes - IETF 61
> 
> 
> 
> 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
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Dec 2004 09:33:55 +0000

Ron

As soon as we see the feedback on TDM requirements and SATOP
(already in the IESG queue) we will either submit SONET by
return, or request an update from you to reflect the
feedback.

Stewart

---

From: "Ron Cohen" <[email-masked]>
Date: Fri, 17 Dec 2004 07:02:14 -0800

Stewart,

> return, or request an update from you to reflect the

I don't see any reason to wait for feedback on SATOP. I don't see ATM
emulation draft waiting for feedback on FR emulation draft. If SATOP is
already on the IESG queue I suggest to put CEP on that queue as well. 

Thanks
Ron

> Behalf Of Stewart Bryant
> Sent: Friday, December 17, 2004 1:34 AM
> To: Ron Cohen
> Cc: 'David Zelig'; 'pwe3'; 'Danny McPherson'
> Subject: Re: CEP-09 - RE: [PWE3] PWE3 Draft Minutes - IETF 61
> 
> 
> 
> 
> Ron Cohen wrote:
> > Danny,
> > 
> >