[10:50:01] --- yjs has joined
[10:59:44] <yjs> nothing happening yet - awfully lonely here
[10:59:56] --- amalis has joined
[11:00:05] <amalis> There .. make you happy?
[11:02:07] <yjs> Yes !
[11:02:07] <yjs> Starting
[11:02:21] <yjs> All slides at pwe3.tcb.net
[11:05:31] --- yjs has left: Replaced by new connection.
[11:06:00] --- yjs has joined
[11:06:32] --- sbrim has joined
[11:06:40] <yjs> network dropped (for a change) but I am back now
[11:06:40] <yjs> Stewart updating on status
[11:07:01] <sbrim> the only reason to type here is to help with the meeting notes
[11:07:36] <yjs> IEEE review requested by IESG for ethernet encap.
[11:07:36] <yjs> Mark asks if anyone knows someone in IEEE to do review (his contact has not responded)
[11:07:47] <yjs> IANA codepoint draft - there was a "discuss" on the avt PW types, so we are removing them
[11:08:07] <yjs> AVT will then use the standard IANA process to request the PW types after the registry is set up
[11:08:21] <yjs> atm encap completed LC, but need Applicability statement
[11:08:35] <yjs> CW is in editors queue
[11:08:54] <yjs> SAToP is ready, but Stewart needs to write proto questionaire
[11:09:31] <yjs> final WG LC: frag, fcs-retention, somet, cell-transport (Stewart asks for other people to review!)
[11:09:42] --- sbrim has left
[11:10:01] <yjs> Andy: these have been reviewed MANY times (these are after several LCs)
[11:10:32] <yjs> David Black: in certain WGs if no-one comments the drafts are not progressed
[11:10:57] <yjs> the following need minor edits: FR, hdlc, CESoPSN, TDMoIP
[11:11:11] <yjs> MIBs needed for ATM, FR, Eth
[11:11:22] <yjs> all MS stuff - work in progress
[11:11:47] <yjs> Danny sent out LC on the new charter (with protection) which will go to the IESG in a week or so
[11:12:24] <yjs> matthew bocci is going to present the MS architecture draft
[11:12:48] <yjs> terminology: U-PE is not T-PE
[11:13:09] <yjs> added maintenance reference model, and S-PE functionality
[11:13:58] <yjs> Matthew showing the reference model (end-end signaling and hop-hop as well)
[11:15:15] <yjs> S-PE capabilities: S-PE do not have NSPs and do not see native service circuits
[11:15:32] <yjs> service up only if both directions up in all segments
[11:15:48] <yjs> misconnection unless all PW types compatible
[11:16:32] <yjs> security section (based on 3985), if S-PE are dynamically selected need ASBR type behavior
[11:16:49] <yjs> need mechanism to prevent misconnection of segment into an AC
[11:17:18] <yjs> please provide comments and text - want to make this a WG draft
[11:18:45] <yjs> Luca: if there is a set of providers, need authenticate originator, not just other provider
[11:19:12] <yjs> Yakov Reckhter: similar to secure ID meeting - source authentication (very complex)
[11:19:21] --- Glenn Parsons has joined
[11:19:55] <yjs> Luca: please remove statement that LDP full mesh doesn't scale from motivation section
[11:21:09] <yjs> Sasha: MS PW up if both directions of all segments are up - isn't this already implied?
[11:21:21] <yjs> Matthew: need to traverse same S-PEs
[11:21:55] <yjs> Stewart - hands up for making this a WG draft - overwhelming majority
[11:22:30] <yjs> Matthew: dynamic placement of MS PWs draft (with Luca and Florin)
[11:23:01] <yjs> background: set and maintenance by extending standard PWE LDP protocol
[11:23:26] <yjs> and there is the segmented PW draft - configure S-PEs
[11:23:55] <yjs> in the last IETF there were two drafts for using LDP to dynamically select S-PE, these have been merged
[11:24:09] <yjs> this new draft works for SS and MS
[11:24:30] <yjs> minimal number of provisioning touches (only T-PEs)
[11:24:46] <yjs> same T-PEs and S-PE in both directions
[11:25:00] <yjs> signaling of TE parameters and CAC
[11:25:26] <yjs> end-end negotiation of OAM
[11:25:57] <yjs> Floring continuing: addressing format - globally unique addressing for PW endpoints
[11:26:24] <yjs> new format needed, summarization, SP administers its own prefixes
[11:26:50] <yjs> use FEC129, all type 2 (as in draft-metz-aii-aggregate)
[11:27:04] <yjs> (Luca will discuss later)
[11:28:10] <yjs> In this approach signaling procedures for MS-PWs is a superset of the SS-PW procedures
[11:29:39] <yjs> check TAII against routing table - full match for T-PE2, longest match for T-PE1 and S-PE
[11:30:09] <yjs> Can either provision statically or dyanically advertise
[11:30:27] <yjs> address aggregation possible since advertise global ID part
[11:31:14] <yjs> QoS TLVs may be included using TSPEC, CAC
[11:31:34] <yjs> explicit routing using ER TLV, can have protection
[11:32:10] <yjs> Need feedback from WG on FEC128-129 usage case
[11:32:17] <yjs> ask for it to be made WG draft
[11:33:05] <yjs> Sasha: one of T-PE originates and the other responds - how is this started?
[11:33:18] <yjs> Florin: compare TAI and SAI or provision
[11:33:41] <yjs> Yakov R: explicit route LDP is that from CR-LDP? (yes)
[11:34:09] <yjs> second Q: can use TSPEC with this TLV?
[11:34:30] <yjs> Florin - no need to ask for a new type. There was a draft on mapping to TSPEC
[11:35:16] <yjs> Yakov: static provisioning = static routing. How do you route around failures? What about looping?
[11:36:04] <yjs> Florin: static means putting default GW, don't need protocol. Loop avoidance should be solved by routing protocol
[11:36:24] <yjs> also CR-LDP has TLVs for this (but maybe not implemented)
[11:37:31] <yjs> Rahul: last time we decided that requirements draft needed to be revised, and noted that LDP/TSVP both had advocates
[11:38:10] <yjs> it is not constructive at this time to vote on whether this draft should be progressed
[11:38:31] <yjs> Florin: if there is interest in this draft it can be progressed regardless of an alternative
[11:38:55] <yjs> Stewart: reasonable for two drafts
[11:39:12] <yjs> Luca: requirements draft has been revised per requests
[11:39:49] <yjs> Peter Buschbach: question about QoS - is QoS relevant only to end-points or to intermediates?
[11:40:00] <yjs> Florin: depends on what is needed.
[11:40:20] <yjs> Peter: if in message do intermediate nodes have to look at QoS info
[11:40:40] <yjs> Florin: if intermediate nodes do CAC this is useful
[11:41:22] <yjs> Peter: there was a discussion on the list where it was claimed that the QoS is not relevant for intermediates
[11:42:26] <yjs> Dave Dyson asks WG chair if we need only one draft - may need another solution when span operator domains
[11:42:56] --- Glenn Parsons has left: Disconnected
[11:43:05] <yjs> Stewart: I will ask for each draft individually whether the WG wants it to become a WG draft
[11:43:30] <yjs> Dave: please make it clear that there is no contradiction
[11:44:18] <yjs> Yakov R: question - if carry TSPEC - is this used in choosing the particular S-PE, and does this need to interact with BGP info
[11:44:50] <yjs> Florin: nothing precludes
[11:47:31] --- yjs has left: Replaced by new connection.
[11:47:36] --- yjs has joined
[11:47:47] <yjs> flaky network is back again!
[11:48:17] <yjs> What we missed is Rahul claiming that in Paris there was a 50:50 vote
[11:48:33] <yjs> Mark: Please choose one - don't want to deprecate later
[11:48:51] <yjs> Luca: I saw 3:1 majority in Paris, some claim it was 4:1 !
[11:49:08] <yjs> Yakov R: choice shouldn't be driven by IETF, rather by market
[11:49:33] <yjs> the division here originates in different market segments
[11:49:59] <yjs> Dmitry: what if there is an overlap, i.e. one environment where both applicable?
[11:50:33] <yjs> mark: If they both are applicable to same application, let's choose one. If non-overlapped cases, can have 2
[11:51:05] --- Glenn Parsons has joined
[11:51:12] <yjs> Kiriti: Dave said he doesn't yet know which he wants so let's advance both. If we can't choose now, let's progress both
[11:51:41] <yjs> CR-LDP vs RSVP-TE debate in MPLS was over precisely the same application. Here more divergence
[11:52:37] <yjs> So let's continue working on both, and decide when we get to draft standard
[11:53:25] <yjs> Dave: Authors should put applicability statements on both drafts
[11:56:58] --- yjs has left: Replaced by new connection.
[11:57:05] --- yjs has joined
[11:57:46] <yjs> Back again - the network is really bad here!
[12:01:22] <yjs> Stewart: how many people want only one solution now? clear majority voted for 2 drafts at this point
[12:01:42] <yjs> Stewart: how many people want this to become a WG draft? Majority want it to be
[12:10:30] --- yjs has left: Disconnected.
[12:14:17] --- yjs has joined
[12:17:01] <yjs> network was down for 5 minutes
[12:17:01] <yjs> Dmitry presented one slide on whether RSVP-TE needs to be a WG document Stewart: are there open issues here? Luca: the addressing is not closed. There is only a sketch of how to use RSVP-TE Rahul: The document is not yet fully developed, but this is not a show-stopper to become a WG document. Luca: So much work needs to be done that we can not yet decide if viable Yakov R: does the document need to be complete before can become WG doc Stewart: no, but need a reasonable expectation that will be Stewart: vote? more in favor of becoming a WG draft, but not overwhelming. Will move to list. Rahul: need to bring everything to list. Eric R: people sometimes vote in order to avoid a DoS attack on WG Dave D: Need applicability statement in RSVP-TE draft like there is in the LDP draft Mark: If we decide on 2 protocols, need sections in both on co-existence. Stewart: and coexistence with present LDP-based protocol George: Does this mean interworking? Mark: if needed for two operators to work together, then yes Stewart: vote on coexistence with existing control protocol - strong support
[12:17:53] --- yjs has left
[12:22:29] --- yjs has joined
[12:23:22] --- sbrim has joined
[12:23:34] <yjs> Network was down for 10 minutes
[12:23:37] <yjs> Yaakov S: Do we allow RSVP-TE for SS-PWs with QoS requirements?
[12:23:47] <yjs> Dmitry presented one slide on whether RSVP-TE needs to be a WG document
[12:24:14] <yjs> Stewart: are there open issues here? Luca: the addressing is not closed. There is only a sketch of how to use RSVP-TE
[12:24:32] --- sbrim has left: Disconnected
[12:24:43] <yjs> Rahul: The document is not yet fully developed, but this is not a show-stopper to become a WG document.
[12:24:51] <yjs> Luca: So much work needs to be done that we can not yet decide if viable
[12:24:58] <yjs> Yakov R: does the document need to be complete before can become WG doc
[12:25:08] <yjs> Stewart: no, but need a reasonable expectation that will be Stewart: vote? more in favor of becoming a WG draft, but not overwhelming. Will move to list.
[12:25:18] <yjs> Rahul: need to bring everything to list.
[12:25:27] <yjs> Eric R: people sometimes vote in order to avoid a DoS attack on WG
[12:25:47] <yjs> Mark: If we decide on 2 protocols, need sections in both on co-existence.
[12:25:55] <yjs> Stewart: and coexistence with present LDP-based protocol
[12:26:03] <yjs> George: Does this mean interworking?
[12:26:17] <yjs> Mark: if needed for two operators to work together, then yes
[12:26:29] <yjs> Stewart: vote on coexistence with existing control protocol - strong support
[12:26:44] <yjs> Next topic: draft-roth-pwe3-fc-encap T.11 approved FC-BB4 which allows MPLS transparent p2p FC transport over PW.
[12:26:59] <yjs> Although possible to transport over public Internet there is requirement to low delay, low loss FC frames and control frames over SAME PW (was unclear in Paris presentation) need FC port mode PW type
[12:27:06] <yjs> CW is REQUIRED (and need length field), SN MAY be used, fragmentation MAY be used
[12:27:13] <yjs> request PW type and to make WG draft
[12:27:29] <yjs> David Black: problem with network congestion, since FC doesn't have a mechanism
[12:27:29] <yjs> need some text on applicability to networks (from strong TE to network with PL, etc)
[12:30:41] --- yjs has left: Replaced by new connection.
[12:31:41] --- yjs has joined
[12:32:40] --- Glenn Parsons has left: Disconnected
[12:33:07] --- yjs has left: Disconnected.
[12:37:26] --- yjs has joined
[12:37:48] <yjs> sorry but network was down AGAIN !
[12:37:59] <yjs> Missed Zi Kang from Huawei on link aggregation status signal (draft-zi-pwe3-link-aggr-member-status)
[12:38:11] <yjs> new TLv for signaling status of remote AC
[12:38:25] <yjs> Himanshu: can use VCCV
[12:38:27] <yjs> Sasha: no requirement in PWE architecture for ACs on opposite sides to have same BW
[12:38:35] <yjs> Stewart: please articulate on list what the requirements are
[12:38:51] <yjs> (this section is very spotty as network was down and I am trying to catch up)
[12:39:34] <yjs> Jixiong Dong from Huawei on Operation and Maintenance for MS PW
[12:39:58] <yjs> draft-dong-pwe3-mspw-oam draft-dong-pwe3-mspw-oam Jixiong Dong from Huawei on Operation and Maintenance for MS PW
[12:41:51] <yjs> need end-end monitoring
[12:42:13] <yjs> ends need to agree on OAM, need FDI and RDI
[12:43:13] <yjs> extension to VCCV to distinguish between segment and end-end OAM
[12:43:30] <yjs> (5 minutes lost due to network problem)
[12:43:51] <yjs> Dinesh: MS-PW should not require change in current SS OAM
[12:45:39] --- yjs has left: Replaced by new connection.
[12:45:42] --- yjs has joined
[12:45:43] --- yjs has left
[12:48:03] --- amalis has left
[13:06:33] --- yjs has joined
[13:07:13] <yjs> I was going to say that there was no jabbering because I presented, but the network fell as well
[13:08:24] --- yjs has left: Replaced by new connection.
[13:10:44] --- yjs has joined
[13:11:43] <yjs> George on target choice of PW type (wildcard PW type)
[13:11:50] <yjs> typo - FEC type should be PW type
[13:13:01] --- yjs has left: Replaced by new connection.
[13:13:05] --- yjs has joined
[13:13:05] --- yjs has left
[13:13:18] --- yjs has joined
[13:13:38] <yjs> 2 years ago George brought draft on spvc interworking here, but later moved to MFA forum
[13:13:49] <yjs> however, certain pieces affect PWE3, so we had a liaison in Paris
[13:13:51] <yjs> problem - want to transition from existing ATM network to MPLS network w/o provisioning every circuit
[13:14:48] <yjs> so would like to reassemble FR at boundary between networks, but not if ATM
[13:15:28] <yjs> don't have enough info at the boundary
[13:15:50] <yjs> don't know what the PW type, but the remote side does
[13:16:14] <yjs> so let te target decide on the PW type, and use "wildcard"
[13:17:11] <yjs> Luca suggests that there may be wider applicability to such wildcards
[13:17:30] <yjs> this can be done quickly - can this be a WG draft
[13:32:40] <yjs> 10 minutes missing - I presented the PW security draft
[13:32:48] <yjs> Peter Buschbach
[13:33:03] <yjs> atm/mpls control plane IW
[13:34:06] <yjs> MFA forum is discussing 2 methods: client-to-client and virtual trunks (simpler - one big PW between PEs with PNNI)
[13:34:32] <yjs> so with virtual trunk VCs set up without MPLS caring
[13:35:25] --- yjs has left: Replaced by new connection.
[13:35:39] --- yjs has joined
[13:35:55] <yjs> (network dropped once again)
[13:36:34] <yjs> translating VPI ranges so that can use different ranges at remote side
[13:37:01] <yjs> mostly ATM work, but what PW type should use? none of the existing ones are OK
[13:39:48] --- yjs has left: Replaced by new connection.
[13:42:03] --- yjs has joined
[13:43:51] <yjs> so we need a new PW type for virtual trunk
[13:43:57] <yjs> Luca - need liaison statement
[13:44:03] <yjs> Stewart: the secretariat is overworked so the liaison was not posted
[13:44:09] <yjs> Andy M: the liaison was sent from MFA
[13:44:23] <yjs> Stewart : sorry for 5 minute overrun
[13:44:32] --- yjs has left