[12:23:04] --- LOGGING STARTED
[12:34:37] --- LOGGING STARTED
[12:35:57] --- LOGGING STARTED
[14:54:43] --- yjs has joined
[15:25:45] --- yjs has left: Replaced by new connection
[15:25:49] --- yjs has joined
[15:26:03] <yjs> Danny was called away and Stewart is alone
[15:26:15] <yjs> Agenda - slight order changes
[15:26:32] <yjs> Status - we now have 2 RFCs, the reqs and the architecture draft
[15:26:58] <yjs> In IESG review - TDM reqs (small editorial changes)
[15:27:12] <yjs> In AD review - CW, setup, Ethernet
[15:28:01] <yjs> After WG LC: HDLC, IANA, frag, ATM (need update)
[15:28:22] --- acmacm has joined
[15:28:56] <yjs> SAToP, CESoPSN and TDMoIP - need an additional draft for control extensions
[15:30:00] <yjs> Work in progress:VCCV, frame-relay, OAM message mapping, TDM MIBs
[15:30:11] <acmacm> are the slides posted somewhere?
[15:30:55] --- esac has joined
[15:31:00] <yjs> MIBs - (Tom at mike) - Dave and Tom worked on 5 docs and will refresh
[15:32:10] <yjs> Luca: draft updates and re-org
[15:32:38] <yjs> HDLC draft was acknowledge by secretariat, but was not posted
[15:33:04] <yjs> chairs asked for follow-up and cc to them
[15:33:14] <yjs> correction: ADs asked ...
[15:33:44] <yjs> Luca: need re-org of application specific docs
[15:33:57] <yjs> AD review: too many normative references
[15:34:06] <yjs> MPLS WG needs to review LDP usage
[15:34:20] <yjs> there is duplication of text in IANA and control doc
[15:34:36] <yjs> must remove dependencies of control doc from encap docs
[15:34:48] --- vph has joined
[15:35:12] <yjs> the idea is that a new PW type should be addable without update of control doc
[15:35:34] <yjs> there were many MPLS-specific parts
[15:35:43] <yjs> syntax/grammar errors were rectified
[15:35:54] <yjs> Reorg:
[15:36:17] <yjs> IANA allocations: control doc ony required new allocations from existing registries
[15:36:26] <yjs> All new registries are now in IANA doc
[15:36:49] <yjs> Service specific text: no longer in control doc - only in encaps
[15:37:08] <yjs> interface parameters specific to tech are now in encap doc
[15:38:00] <yjs> updated PW status section of control doc:
[15:38:10] <yjs> MUST for status and MAY for label withdrawal
[15:38:40] <yjs> IP PW is left in control doc since there is no encap doc (RFC3032 covers)
[15:39:09] <yjs> security section needs rewording to pass IESG review
[15:39:59] <yjs> Ethernet encap doc: tag and raw mode is now clearer
[15:40:19] <yjs> "SHOULD implement MIB" removed
[15:40:42] <yjs> security section has been changed to "use security offered by PSN"
[15:40:50] <yjs> (will be the same for all encaps)
[15:41:06] <yjs> ATM encap doc: didn't make draft update deadline
[15:41:36] <yjs> needs some changes (e.g. CW MANDATORY -> REQUIRED)
[15:41:41] <yjs> grammar fixes
[15:41:56] <yjs> frame relay encap: this hadn't been edited in a few years ....
[15:42:14] <yjs> 80 percent rewrite was needed (VCs instead of PWs, etc)
[15:42:25] <yjs> padding was required ! so this was removed
[15:43:04] <yjs> port mode: do we need it? isb't it the HDLC mode?
[15:44:21] <yjs> PPP/HDLC doc: updated boilerplates, removed service-specific text, PW type ...
[15:45:48] <yjs> IANA doc: (need to settle now)
[15:46:56] <yjs> SAII, TAII and AGI "types"
[15:47:23] <yjs> need ASAP registry of TAII types (8 bit values)
[15:48:03] <yjs> IANA allication policy - IETF consensus, expert review, first come first served, vendor specific, exp
[15:48:19] <yjs> AD's opinion: expert allocation is best
[15:48:36] <yjs> WG members think this is too slow
[15:49:07] <yjs> editor prefers strict control on data-plane code points, looser on control protocol
[15:49:42] <yjs> George S: why not one registry for SAII and TAII types
[15:50:43] <yjs> "AII type registry" and "AGI registry"
[15:50:52] <yjs> Luca will change text to do this
[15:52:00] <yjs> Stewart: do we agree with suggestion that strict control on data-plane code points, looser on control protocol ?
[15:52:13] <yjs> Andy: why is this useful?
[15:52:45] <yjs> Luca: the control part is the associated channel type in CW
[15:52:55] <yjs> Should use PW type not ACH
[15:54:28] <yjs> Thomas: No one would go for expert review if there is first-come first-serve
[15:55:13] <yjs> Are we OK with everyone getting numbers allocated without review?
[15:55:52] <yjs> Luca: I have been told that expert review didn't work in the past
[15:56:23] <yjs> Thomas: what do we want to do now? we can fix the expert review mechanism
[15:56:31] <yjs> by giving guidelines for the expert
[15:57:27] <yjs> On the other hand, people may grab first-come first-serve allocations and later we will discover that this is a gross mis-use
[15:58:02] <yjs> Yakov R: should IETF outlaw first-come first-serve?
[15:58:43] <yjs> Thomas: In general we should ask what the potential for hard is, if no harm then FCFS is OK
[15:59:19] <yjs> Andy: need to look far into future to know, rules for expert review would be complicated
[15:59:44] <yjs> Stewart: AD inherits control over the expert
[16:00:24] <yjs> Thomas: if expert isn't responsive the IESG can replace the expert (based on WG chair recommendation)
[16:02:24] <yjs> Vach K: Another possibility: FCFS but only when draft is submitted (6 months to check if sensible)
[16:02:35] <yjs> Andy: has there ever been an abuse of FCFS?
[16:02:57] <yjs> Mark T: yes, there has been (often later regretted having FCFS)
[16:03:34] <yjs> Mark: there are only 256 values - what if someone takes 128? (If there were 16 bits we could be less worried)
[16:03:54] <yjs> If there is a problem with expert review - let's fix the method
[16:04:13] <yjs> Luca: it sounds like we are worried about a DoS attack against registry
[16:05:19] <yjs> Eric G: Not enough for ID (no one would read), must be a draft towards RFC
[16:06:27] <yjs> Eric R: There have been cases where I have regretted assignment of code point
[16:06:36] <yjs> but these were by IETF consensus
[16:06:58] <yjs> He doesn't think someone is going to collect code points for resale
[16:07:19] <yjs> Thomas: "designated expert" is a loaded term
[16:07:49] <yjs> It is just in order for IANA not to have to make a judgement (wierd requests)
[16:08:18] <yjs> If there is someone who is designated who understands what the field s for
[16:08:41] <yjs> If there is still a WG, the expert should go to it
[16:09:15] <yjs> Yakov R: expert should not be an only and final judge, it is OK if expert gives advise
[16:09:52] <yjs> Luca: even if expert disapproves, can go for consensus
[16:11:00] <yjs> Stewart: I am not sure what the consensus is here ...
[16:12:27] <yjs> Quick vote: no-one wanted expert review
[16:12:36] <yjs> Many wanted FCFS
[16:12:45] <yjs> Yaakov S: with draft or without?
[16:13:03] <yjs> Most wanted with draft
[16:14:03] <yjs> Stewart: will put to list
[16:14:13] <yjs> Stewart: CW draft
[16:14:49] <yjs> The authors are the WG chairs
[16:14:58] <yjs> There were AD comments, mostly editorial
[16:15:21] <yjs> there was a discussion at previous meeting about consensus process for ACH
[16:15:58] <yjs> there were two CW types: 1) regular (0000) and 2) OAM one
[16:16:20] <yjs> the present word was "SHOULD" use the prefered CW format
[16:17:02] --- acmacm has left: Disconnected
[16:17:13] <yjs> proposal: MUST use prefered format, otherwise MUST specify why generic is not good
[16:17:58] <yjs> second problem: length field wording
[16:18:30] <yjs> the AD review added that the text was not clear enough for interop
[16:19:17] <yjs> new text was sent to list (simpler)
[16:20:47] <yjs> New text was accepted by show of hands
[16:21:49] <yjs> Next presentation: Nabil B - inter domain PW requirements
[16:22:25] <yjs> Scope: multiple domains and PSN tunnels (ASs)
[16:23:11] <yjs> Must expand the single-hop (SH) architecture to multi-segment MS-PWs
[16:23:38] <yjs> there are ultimate PEs U-PEs, and switching PEs S-PEs
[16:24:20] <yjs> U-PE where customer AC bound to forwarder
[16:24:42] <yjs> also can interconnect where different technolgies (MPLS and L2TPv3)
[16:25:01] <yjs> also can reduce N-squared problem
[16:25:57] <yjs> also where different operators control networks
[16:27:06] <yjs> S-PE MAY only support stitching PWs of same type
[16:27:21] <yjs> bu MAY change type or encap mode
[16:28:17] <yjs> 2 set-up mechanisms: static endpoint provisioning and config, static end-point but dynamic config
[16:28:28] <yjs> long list of setup requirements
[16:28:41] <yjs> resiliency requirements (also long list)
[16:29:40] <yjs> TE and QoS requirements (priorities, failure to setup messages, ...)
[16:29:50] <yjs> admission control
[16:30:12] <yjs> routing requirements: static and dynamic, resiliency
[16:30:23] <yjs> OAM requirements (once again a long list)
[16:31:04] <yjs> Next steps and Questions: security requirements, policy requirements
[16:31:15] <yjs> requests to make this a WG doc
[16:32:55] <yjs> were comments on list about calling multi-segment (MS) rather than multi-hop (MH)
[16:37:11] <yjs> Dmitry: why is there a discussion on SH PW control protocols?
[16:37:36] --- vph has left
[16:37:41] <yjs> Luca: this is a requirement - we MUST be able to stitch MPLS, L2TPv3 and static
[16:38:34] <yjs> Luca: once this is a WG doc, we can prune reqs according to comments on the list
[16:39:29] --- esac has left: Replaced by new connection
[16:39:29] --- esac has joined
[16:41:32] <yjs> Vach: is resiliency of the PW or of the tunnel?
[16:41:43] <yjs> Nabil: there are both
[16:42:17] <yjs> Stewart: 2 minutes - only bring up points that bear on whether this should become a WG doc
[16:42:38] <yjs> Yakov R: against becoming WG doc, need more work
[16:43:03] <yjs> Bruce Davie: I think it is ready. Also L2TPv3 vs. MPLS is important
[16:43:41] <yjs> show of hands is overwhelmingly for this becoming a WH doc. will take to list
[16:44:26] <yjs> next presentation: Simon (FT) on OAM scenarios
[16:45:28] <yjs> service provider context diagram: customer - access network - POP - transit PWN - POP - access network - customer
[16:46:03] <yjs> issues: 2 sides may be similar technologies or not,
[16:46:23] <yjs> three networks (two access networks and transit) can belong to same SP, or 2 or 3
[16:46:55] <yjs> Monitoring - 3 items: 1) background on how PSs divide networks and services
[16:47:50] <yjs> 2) end-end service architecture 3) service supervision (OAM requirements, connectivity check)
[16:48:21] <yjs> These models are technology agnostic - applicable to ATM, FR, Eth< MPLS in the different networks
[16:49:51] <yjs> There are 4 OAM docs in PWE and L2VPN
[16:50:32] <yjs> This draft is glue to link the 4 docs
[16:51:17] <yjs> i.e. VCCV to L2VPN OAM, or OAM msg mapping to VPWS OAM
[16:51:42] <yjs> this draft uses the standard MEP and MIP OAM points (ITU, IEEE, etc)
[16:52:03] <yjs> L2VPN WG has acknowledged this draft
[16:52:18] <yjs> Asks for PWE WG members to review this draft
[16:52:39] <yjs> wants to expand to MH PWs
[16:54:07] <yjs> Vach: Does IETF need to do anything here?
[16:54:32] <yjs> If this is technology agnostic (i.e. can go over ATM) this is more for ITU or someone
[16:57:32] <yjs> Mustapha A: L2VPN discussed OAM yesterday - there is a model there.
[16:57:56] <yjs> Perhaps we can extract VPWS part and use
[16:58:44] <yjs> Dave D: there are pieces that belong to L2VPN here
[16:59:11] <yjs> Tom N: the point is not to define something new, it is to describe the larger picture
[16:59:34] <yjs> So we should leave VPWS part here, and the rest needs to be merged with L2VPN work
[16:59:46] <yjs> Monique M: split doc, good work here
[17:00:37] <yjs> Ali S:Nice doc. captures service and network layer aspects. service specific parts will be incorporated in L2VPN
[17:00:54] <yjs> Stewart: continue on list
[17:01:35] <yjs> Next presentation: Mustapha - OAM message mapping updates
[17:02:14] <yjs> abstract forward and reverse states, etc. new contributors
[17:02:32] <yjs> doc is stable, but after Simon's draft maybe not ready for LC
[17:03:49] <yjs> Next: Rahul A - use of RSVP-TE for PWs
[17:05:18] <yjs> WHY? interdomain TE PWs, use of multi-segment PWs, TE and resiliency
[17:05:52] <yjs> RSVP-TE addresses all of this by using RFC 3209 and the LSP-hierarchy draft
[17:06:29] <yjs> a MS PW is a bi-directional RSVP-TE LSP nested between PW segment endpoints
[17:06:40] <yjs> can use MPLS and CCAMP messages
[17:07:06] <yjs> QoS via TSPECs, explicit routing using ERO/RRO, single sided signaling
[17:08:51] <yjs> shows example of using RSVP-TE for setup
[17:09:45] <yjs> recap: was presented at IETF-60 but motivation was made clear
[17:10:03] <yjs> now with MS work, its applicability is clear
[17:10:25] --- narten has joined
[17:10:43] <yjs> MS-PW TE requirements in MH-reqs draft:
[17:10:57] <yjs> RSVP-TE already supports interdomain signaling
[17:11:08] <yjs> ccamp drafts already there
[17:11:51] <yjs> dynamic rerouting is done via fadt reroute
[17:13:16] <yjs> setup of back-up PWs needs RSVP-TE (can share reservations)
[17:13:42] <yjs> QoS - RFC 3209 using diverse QoS models - diffserv, crankback
[17:13:55] <yjs> comparison of RSVP and LDP:
[17:14:21] <yjs> RSVP-TE can use PWE encaps and forwarding, MS-PW TE, need ecndpoint ID
[17:14:28] <yjs> LDP is missing key elements
[17:14:56] <yjs> misconception: there IS RSVP targetted signal, there IS reliability, it DOES scale
[17:15:46] <yjs> Is there a valid reason NOT to use RSVP-TE for MS-PWs
[17:16:01] <yjs> The fact that only LDP has been specified for SH PWs is not relevant
[17:16:16] <yjs> There are SPs and vendors who want this
[17:16:42] <yjs> so PWE3 should look at the big picture and accept this
[17:17:27] <yjs> Andy M: We have everything we need already - if vendors or SP want something else they can implement w/o our standardizing
[17:18:22] --- narten has left: Logged out
[17:18:27] <yjs> Mustapha: there can be assymetric BW, how can TSPEC be used?
[17:21:15] <yjs> Nurit S: RSVP-TE support TE, reroute, etc which LDP doesn't. How can we NOT use this?
[17:21:36] <yjs> Luca: why not use SIP?
[17:22:50] <yjs> Kireeti: there are truly new requirements for MH-PWs, and to beef up LDP we recreate CR-LDP!
[17:22:54] <yjs> Do we want to do this?
[17:23:28] <yjs> yakov R: LDP was not designed for PWs either, so maybe draft-martini isn't right
[17:24:12] <yjs> Next presentation: Florin + Dave - MH using LDP
[17:24:37] <yjs> This same presentation was given yesterday at L2VPN
[17:25:09] <yjs> full mesh of PSN tunnels and LDPs, so becomes difficult to handle
[17:25:49] <yjs> If we add hierarchy we reduce complexity, BGP, RADIUS can be used
[17:26:22] <yjs> this proposal is good for inexpensive U-PEs (no BGP, RSVP-TE)
[17:26:51] <yjs> requirements addressed: dynamic creation using IP addressing, S-PE by S-PE hop routing
[17:26:57] <yjs> minimal OSS touches
[17:27:34] <yjs> there are several solutions: martini, rahul, shah-bocci
[17:28:26] <yjs> not yet addressed: QoS, resiliency, OAM
[17:30:21] <yjs> TLV gives source U-PE, destination U-PE
[17:31:17] <yjs> U-PE1 uses IP address to find next hop, uses martini signaling to label,
[17:31:34] <yjs> two targetted LDP sessions from S-PE one to each U-PE
[17:32:09] <yjs> PE knows it is U-PE when destination PE address is its IP address
[17:32:34] <yjs> needs some more work - welcome more contributors
[17:33:02] <yjs> Mustapha: do we need the same S-PE in both directions? Probably yes.
[17:34:04] <yjs> Also, is the LDP downstream unsolicited?
[17:34:36] <yjs> Yes
[17:35:24] <yjs> Kireeti: why need new TLV for explicit routing - there already is one?
[17:35:30] <yjs> Stewart: take to list!
[17:36:26] <yjs> last, absolutely last presentation: Shah - QoS signaling
[17:37:12] <yjs> This was presented before, but have added dynamically signaled parameters and MH
[17:37:37] <yjs> updates: flags for forward and backward directions
[17:37:52] <yjs> MH label mapping with costs
[17:38:04] <yjs> leaves dangling PW
[17:38:32] <yjs> can use LDP message for congestion notification
[17:38:56] <yjs> request to adopt - this is NOT CR-LDP!
[17:39:29] <yjs> Kireeti: why additions? RFC3212 has is all.
[17:40:17] <yjs> Nurit S: need even more QoS parameters, e.g. DiffServ
[17:41:08] <yjs> Also, if the tunnels use RSVP-TE , why use something else for PWs
[17:41:38] <yjs> A VERY VERY last presentation by Shah: MH signaling protocol
[17:42:24] <yjs> want mechanism for resiliency and backup, without crankback, and guarantee go thru same S-PE
[17:43:11] <yjs> solution: U-PE initiate, MH-PW created by fanning out, and pruned in the backward direction
[17:43:46] <yjs> animation demonstrates the process
[17:45:25] <yjs> Kireeti: I have nothing against LDP, but let's call it CR-LDP
[17:45:50] <yjs> Yakov R: This looks like 802.5 APE (all paths explored) in token ring
[17:46:32] <yjs> Luca: Where does all of this work belong - here or L2VPN
[17:46:49] <yjs> Stewart: all placing is L2VPN, we are told were to set up wires
[17:48:23] <yjs> Done (1/2 hour late)
[17:50:35] --- esac has left
[17:53:16] --- yjs has left