[03:19:31] --- yjs has joined
[03:31:07] <yjs> I will jabber this session
[03:31:22] <yjs> Danny started - agenda slightly changed
[03:31:47] <yjs> status of drafts on web site - Mark (AD) has things moving along
[03:32:23] <yjs> charter update: deadline extended to 2 weeks from now
[03:32:42] <yjs> already changed according to comments received
[03:33:22] <yjs> SVC removed, FC added explicitly, some work still in charter although documents almost complete
[03:34:00] <yjs> Agenda tight, so questions at end.
[03:34:18] <yjs> Luca - requirements for interdomain PWs
[03:35:05] <yjs> there will be a joint presentation by Luca and Yakov later about LDP vs RSVP setup
[03:35:36] <yjs> Luca: a couple of brief slides
[03:35:58] <yjs> Former PW-switching draft now called segmented PW draft
[03:36:39] <yjs> (Luca was just fitted with a wireless mike)
[03:36:52] --- azinin has joined
[03:37:00] --- azinin has left
[03:37:05] <yjs> we now have LDP, L2TPv3 and static setup - do we need UDP?
[03:37:32] <yjs> should the MS usage examples (also in MS requirements draft) stay here?
[03:38:36] --- amalis has joined
[03:38:45] <yjs> authors ran out of time for application scenarios for MS requirements draft
[03:39:20] <yjs> Danny polling how many have read the MS req document - a lot have
[03:39:58] <yjs> Luca and Yakov will now present their joint work on MS PW req and selection
[03:40:30] <yjs> in order to resolve the LDP vs RSVP debate Luca and yakov are arm wrestling
[03:40:40] <yjs> Yakov thinks this is the IETF way of deciding
[03:41:37] <yjs> which protocol fits reqs best? presents list with reqs
[03:42:05] <yjs> there are mandatory and optional reqs - please help decide which are mandatory
[03:42:38] <yjs> need a clear understand as to what needs to be changed for MS - in both LDP and RSVP
[03:43:20] <yjs> authors of all MS protocol drafts - please document the changes to standard LDP or RSVP
[03:43:41] <yjs> for example: LDP needs QoS info, RSVP need PW status info
[03:44:16] <yjs> Yakov: not just a bullet list - explanation of additions and their complexity
[03:45:05] <yjs> Sasha: how much work is needed to fix drafts (requirements and signaling proposals) ?
[03:45:16] <yjs> Luca: req draft needs a couple of days of work
[03:46:19] <yjs> Himanshu: want clarification as to what is needed from authors
[03:46:44] <yjs> Yakov: quote section of RFC and fix needed
[03:47:19] <yjs> explain what new section needed to RFC
[03:47:36] <yjs> Ali S: what is cost associated to extensions?
[03:48:36] <yjs> Yakov: need SW to actually compare protocols, but what we really need for an objective decision is basic idea
[03:48:52] <yjs> Mark T: is this for MS only (not single segment)
[03:49:02] <yjs> Yakov and Luca: only for MS
[03:49:37] <yjs> Mark: in that case need how to migrate from, and coexist with, LDP
[03:50:19] <yjs> Mark: If RSVP-TE is suggested for single segment, then need to explain deprecation of LDP
[03:50:35] <yjs> Kireeti: not talking about deprecation of LDP
[03:50:53] <yjs> neither LDP nor RSVP is trying to deprecate the other
[03:51:34] <yjs> Mark: there is now a requirement for us to know a priori whether the PW is SS or MS
[03:52:33] <yjs> if we can not know a priori whether the PW will be SS or MS, then we will end up using the MS protocol for the SS case as well
[03:53:05] <yjs> So we might want to get rid of LDP for SS !
[03:54:10] <yjs> Luca: as much as possible we should extend the SS protocol to the MS case
[03:54:19] <yjs> operators would prefer one protocol for both cases
[03:54:58] <yjs> Dimitry: clarification to Mark - what do you mean by "not knowing whether the PW is MS or SS" ?
[03:55:44] <yjs> Mark: PE setting up the PW, doesn't know if at the end of the PW there is a native service, or an intermediate point being switched onto another PW
[03:56:39] <yjs> Raul: req document needs more detail on coexistence of MS and SS, and if known a priori whether MS or SS
[03:57:23] <yjs> also we should not rule out the possibility that after looking over the reqs we will end up with 2 protocols based on applicability (as happened in L2VPN)
[03:58:05] <yjs> Mark: is it realistic for us to require that it is always known a priori whether it SS or MS?
[03:58:25] <yjs> Kireeti: it is important to know whether SS or MS at setup time
[03:59:42] <yjs> Dimitry: putting architecture and req documents together might help
[03:59:58] <yjs> Scott B: knowing end point does not imply knowing number of segments
[04:00:12] <yjs> Matthew B coming to stage
[04:01:01] <yjs> Matthew and Stewart's MS architecture draft
[04:01:24] <yjs> objectives: document the main scenarios and framework
[04:01:40] <yjs> key issues: applicability vs. L2VPN
[04:02:01] <yjs> layering model, network reference models, PW reference model and protocol stack
[04:02:17] <yjs> this is similar to what we did in PWE up to now for SS PWs
[04:02:28] <yjs> finally - are there gaps?
[04:03:15] <yjs> Applicability: MS-PW is a single PW that is segmented into concatenated hops for technical or administrative reasons
[04:03:31] <yjs> from U-PE prespective, MS-PW looks like SS-PW
[04:04:04] <yjs> layering is same as 3985 (SS PWE architecture) except
[04:04:15] <yjs> PWs are separate layer from the PSN tunnel
[04:04:29] <yjs> independent of PSN routing, signaling, etc
[04:04:40] <yjs> but will reuse PSN protocols
[04:05:18] <yjs> network reference models: intra-provider and inter-provider cases (shows ASCII drawing from draft)
[04:05:42] <yjs> in the inter-provider case there is an S-PE on boundary of each provider
[04:06:20] <yjs> PE reference model: preprocessing as in 3985, but S-PE has no NSP, but maps PW labels
[04:06:32] <yjs> static or dynamically configure the mappings
[04:06:54] <yjs> there must be a 1:1 mapping between ingress and egress PWs
[04:08:13] <yjs> protocol stack also similar to 3985, but remove PW label from one side and add for other side
[04:08:28] <yjs> can apply various policies too
[04:08:43] <yjs> control plane can static or dynamic
[04:08:51] <yjs> gaps? security issues?
[04:09:10] <yjs> requests comments and additional text to improve
[04:10:10] <yjs> Mustapha: protocol layering is independent of PSN tunnel but reuses protocols ? actually need to use information from PSN
[04:10:56] <yjs> Matthew: reachability info may be used, but only used to select which packets passed
[04:11:38] <yjs> Dimitry: what do you mean by "may be a separate layer" ?
[04:12:05] <yjs> Matthew: not same layer although shared protocols
[04:13:24] --- m.behringer has joined
[04:14:47] <yjs> Ron C: what policy decisions can be use?
[04:15:05] <yjs> matthew: for mapping and selection of next hop
[04:15:20] <yjs> Yaakov: please leave statement about PWs being a separate layer (network)
[04:15:38] <yjs> In the past there have been discussions whether PWs are an adaptation or separate layer network
[04:15:46] <yjs> Rahul now on stage:
[04:16:04] <yjs> draft on RSVP-TE draft for MS-PWs
[04:16:34] <yjs> Why is RSVP-TE a good fit here?
[04:16:54] <yjs> Intra-domain TE PSN tunnels are already RSVP-TE LSPs
[04:17:33] <yjs> the functional blocks need TE mechanisms (resiliency, scalability, etc), and RSVP solves these
[04:18:23] <yjs> inter-domain PWs can use 2 unidirectional LSPs or bidirectional LSPs
[04:18:50] <yjs> shows diagram of RSVP-TE setup stages
[04:19:27] <yjs> Next let's map from requirements draft, with emphasis on scalablity, routing , CAC, etc
[04:19:48] <yjs> scalability - a full mesh of signalling adjacencies is not a good idea
[04:20:21] <yjs> with RSVP, U-PE only maintains session with S-PE, not with all other U-PEs
[04:20:56] <yjs> routing requirements: need to achieve QoS and policy reqs. This is done using RFC 3209
[04:21:13] <yjs> dynamic reroute triggering is also already supported
[04:21:33] <yjs> RSVP-TE already supports inter-domain signaling (see CCAMP drafts)
[04:22:29] <yjs> RSVP-TE has crank-back support, which is very important when checking QoS reqs during setup
[04:22:42] <yjs> also can leverage PCE work
[04:23:18] <yjs> resiliency: all people who have worked with RSVP-TE know that resilency has taken a long time to perfect
[04:23:37] <yjs> RFC 3209 allows primary and backup PWs
[04:23:59] <yjs> there is an ID (RSVP-TE-EXCLUDE-ROUTE) to avoid fate-sharing
[04:24:33] <yjs> how do we protect against S-PE failure? RSVP has fast reroute draft
[04:24:40] <yjs> there is also segment protection
[04:25:12] <yjs> QoS and CAC: RSVP-TE has support for DiffServ, traffic priorities
[04:25:41] <yjs> OAM: use mechanisms already specified in VCCV, LSP-ping
[04:26:45] <yjs> segment (non end-to-end) OAM will require extensions (perhaps protocol independent)
[04:27:02] --- m.behringer has left
[04:27:11] <yjs> defect propagation mechanisms - needs to be done
[04:27:39] <yjs> what is the relationship between SS and MS setup protocols?
[04:28:11] <yjs> SS should continue to use LDP, but MS ones will use RSVP-TE. Is this coexistence possible?
[04:28:27] <yjs> Is it possible for each segment to use LDP? Rahul has no opinion.
[04:28:46] <yjs> What is required to be specified?
[04:29:25] <yjs> PW ID TLV (TSPEC), CW negotaition (TSPEC), OAM mechanism (?)
[04:30:07] <yjs> conclusion: SPs that already use RSVP-TE will want to use it for MS PWs as well
[04:30:43] <yjs> It might turn out that for different cases different solutions will be best
[04:31:48] <yjs> Mustapha: PWE PWs are always bi-directional. CCAMP allows symmetric BW
[04:32:22] <yjs> Rahul: indeed TSPEC forces symmetric, but can be worked around
[04:33:26] <yjs> Luca: your presentation included a lot of ideas. Fast reroute (is there a requirement for this?)
[04:34:00] <yjs> A lot of RSVP-TE is too complex for what we need (we assume a reliable infrastructure)
[04:34:26] <yjs> Rahul: let's ask providers, CCAMP, etc why they are talking about fast reroute
[04:36:09] <yjs> Sasha: isn't targeted LDP and targeted RSVP the same from the scalability point of view?
[04:36:19] <yjs> Rahul: yes, they are similar
[04:37:17] <yjs> Dimitry: what is the source of the information about reliability (or lack thereof) of infrastructure?
[04:38:27] <yjs> MS PW Setup and maintenance using LDP draft
[04:38:42] <yjs> a lot of vendors and operators worked together on this draft
[04:39:21] <yjs> Why LDP? extension of SS PW protocol, use super set of procedures
[04:39:38] <yjs> there are a lot of deployments already, and we don't want disruptive change
[04:40:08] <yjs> help SPs exploit operational experience (service management, provisioning models, etc)
[04:40:32] <yjs> easily applicable to existing LDP-VPLS implementations
[04:41:20] <yjs> So idea was to extend LDP. Extensions: need dyanmic creation ensuring same forward and reverse path
[04:41:42] <yjs> provisioning touches only at U-PEs
[04:42:02] <yjs> from database perspective - SS and MS needs to look the same to the customer
[04:43:16] --- javier has joined
[04:43:19] <yjs> PW control protocol (soon RFC), uses unique endpoint ID, PW defined by triplet IP1, FEC, IP2
[04:44:17] <yjs> here same elements and triplets, just topology change means can no longer derive other side prefix
[04:45:41] <yjs> two ways to carry prefixes: 1) using FEC128 with separate MS-PW TLV 2) use FEC129 with complete address in TLV
[04:46:58] <yjs> walks through MS PW E2E setup (using dynamic slides)
[04:49:08] <yjs> related procedures: how to find S-PE? next signaling hop determined by static provisioning or BGP autodiscovery
[04:50:09] <yjs> Kireeti: so I need a certain predetermined set of hops ?
[04:50:27] <yjs> No, may have BGP advertising the prefix of PEs
[04:51:50] <yjs> QoS TLVs included (TSPEC format)
[04:52:11] <yjs> reroute around failure for resiliency
[04:52:26] <yjs> next steps: do we need to support FEC128?
[04:52:32] <yjs> we need to discuss protection
[04:56:19] <yjs> Lou Berger: why not just pick standardized mechanisms which are as generic as possible?
[04:56:38] <yjs> Florin: only small set of additional TLVs needed
[04:58:02] <yjs> Sasha: should not preclude FEC128
[04:58:14] --- yjs has left
[04:58:43] --- yjs has joined
[05:00:03] <yjs> Dimitry: where does NSAP addressing requirement come from?
[05:00:40] <yjs> Florin: only a possibility.
[05:01:37] <yjs> Mustapha: still missing what happens when S-PE releases label - what crankback supported?
[05:01:56] <yjs> Florin: addressed in draft
[05:02:23] <yjs> Mustapha: no I am talking about a label dropped because of resource problem
[05:03:16] <yjs> Ali S: not same as VPLS, where does trail terminate?
[05:03:50] <yjs> Florin: need to extend HVPLS model
[05:05:05] <yjs> Matthew to present draft-shah-bocci
[05:05:34] <yjs> Want to extend PW control protocol based on LDP DU
[05:06:11] <yjs> want the protocol to be light weight, particular for U-PEs
[05:06:18] <yjs> already mentioned how LDP already used for L2VPN
[05:07:17] <yjs> guidnig assumptions: can't assume U-PEs have full reachability info (don't know all the tunnels in network)
[05:07:47] <yjs> signalling launched by downstream U-PE, while informed selection can be made by upstream U-PE
[05:08:17] <yjs> each hop can select next hop by controlled path discovery (less than flooding)
[05:08:32] <yjs> or by blind path search (with crankback)
[05:09:08] <yjs> crankback requires access to source routing info to be effectve
[05:09:19] <yjs> and we want ot minimize crankback
[05:09:54] <yjs> solution: U-PEa and S-PEs establish T-LDP adjacencies, and assume passive/active roles
[05:10:25] <yjs> MS-PW TLV provides unique key
[05:10:36] <yjs> peer PW ID - don't need global PW ID
[05:11:03] <yjs> choice of S-PE via local policy
[05:11:35] <yjs> requirements addressed: intra dna inter domain PWs with partial tunnel mesh
[05:12:32] <yjs> resiliency and protection, QoS, TE (next hop can be based on E2E knowledge), OAM mechanisms inherited
[05:12:53] <yjs> main changes needed to PW control protocol:
[05:13:10] <yjs> controlle path discovery (as opposed to crankback)
[05:13:25] <yjs> need to add concept of active/passive behavior
[05:13:31] <yjs> a few additional TLVs
[05:13:49] <yjs> walkthrough (with dynamic slides)
[05:17:38] <yjs> Jeff S: doesn't timing of label propagation strongly influence which is used?
[05:18:12] <yjs> Matthew: U-PE needs to wait, but yes may pick first as primary and 2nd as backup
[05:18:59] <yjs> Rahul: CCAMP and PCE have spent a lot of time developing mechanisms, have you considered?
[05:19:09] <yjs> Matthew: could reuse mechanisms, could coordinate
[05:19:37] <yjs> Dimitry: how is explicit routing related (it is in doc)
[05:20:02] <yjs> Matthew: explicit routing could be used in simple cases
[05:22:41] <yjs> Kireeti: aren't both of the LDP paths merely ways of no adding ERO TLVs to LDP
[05:23:15] <yjs> the path discovery described here is not appealing, it can become uncontrolled very quickly
[05:23:51] <yjs> any LDP based mechanism will end up reinventing many of the CCAMP mechanisms
[05:24:26] <yjs> Matthew: this is a way of getting around the problem of partial information (only known after label distribution arrives)
[05:25:20] <yjs> Kireeti: 3 ways to know which path to select: 1) flooding 2) crankback 3) oracle
[05:27:24] <yjs> Mustapha: do we need best E2E path, or is a compromise good enough
[05:28:10] <yjs> Bruce D: agrees with Kireeti that shouldn't invent new mechanisms for path discovery
[05:32:43] <yjs> Adrian: PCE WG never received requirements from PWE3
[05:33:02] <yjs> Andy Malis: have we gotten closer to a solution?
[05:33:15] <yjs> Danny: not really, but need to progress the requirements doc
[05:33:58] <yjs> Danny: there has been a lot of work on both approaches (RSVP/LDP) but perhaps not best to have 2 solutions
[05:35:52] --- javier has left
[05:38:01] <yjs> Lou Berger: why not use CR-LDP if it fits best (not be scared by its present state)
[05:38:19] <yjs> we can go forward with RSVP and CR-LDP and let the market decide
[05:39:22] <yjs> Mark: IETF management statement - first let the WG try to decide. only if the WG can not choose dol we let the market decide
[05:39:31] <yjs> otherwise we can all go home now
[05:40:38] <yjs> Luca: it seems that RSVP-TE does not work very well for multiple providers, that's why we needed PCE!
[05:41:52] <yjs> ? from France telecom: we don't need to make a choice now, since we frequently use RSVP or LDP depending on whether we need explicit routing
[05:42:20] <yjs> Yakov: the design principle should be to make the minimum number of protocols
[05:43:03] <yjs> Yakov: the IESG often makes the WG decide, but the market has more experience and will decide
[05:45:19] <yjs> George: if we advance both, we will end up working on interoperability between the two
[05:45:57] <yjs> Danny made s short poll LDP vs. RSVP: results 50-50!
[05:45:58] <yjs> Bye
[05:52:07] --- amalis has left: Disconnected
[05:59:12] --- yjs has left
[06:55:13] --- amalis has joined
[06:59:03] --- amalis has left