Subject: Re: dratf minutes PWE3 @ IETF62

From: Yakov Rekhter <[email-masked]>
Date: Mon, 14 Mar 2005 06:43:35 -0800

Stewart,

> My thanks to Matthew for taking the Minutes.
> Please review and feedback by 25th March.

one correction - see below...

[clipped...]

> SETUP AND MAINTENANCE OF PSEUDOWIRES USING RSVP-TE
> --------------------------------------------------
> Rahul Aggarwal
> draft-raggarwa-rsvpte-pw-01.txt
> 
> Why RSVP-TE:
> - Inter-domain TE pseudo-wires
> - Intra domain tunnels are RSVP-TE LSPs
> - Look at entire picture with all pieces
> - Multi-segment PWs and PW TE and PW resiliency
> 
> Uses the same tools as inter-domain RSVP-TE and hierarchy.
> 
> The PW is instantiated as a bi-directional RSVP-TE
> LSP. The PW LSP is nested in PSN RSVP-TE LSPs between P
> W segment end points.
> 
> Explains how inter-domain PW setup works.
> Need to be able to do a partial path computation to
> next ASBR. Mechanisms already exist for this.
> Originally presented at IETF 60. Primary motivation
> has been clarified since then.
> 
> Then presents a requirements analysis versus the
> requirements draft:
> - RSVP TE already supports inter-domain signalling. T
>    his implies hierarchy, implicit route expansion.
> - Avoid a full mesh of signalling adjacencies between
>    U-PEs.
> - Fast reroute for protection of tunnels and S-PEs.
> - Mechanisms to perform fast switchover
> - QoS: need to support crank-back in any inter-domain
>    protocol
> 
> Compares LDP and RSVP:
> TE is missing piece from LDP signalling.
> 
> Addresses some of the misconceptions, e.g:
> LSP hierarchy supports targeted signalling
> Claims that RSVP state the same as LDP
> 
> Andy Malis: vendors are free to implement anything,
> and SPs are free to deploy anything. That doesn't mean
> we have to standardise it.
> 
> Mustapha Aissaoui: believe this draft uses forwarding
> adjacency LSPs
> 
> Rahul Aggarwal: it doesn't. We can take off line
> 
> Mustapha Aissaoui: T-spec for QoS: its a bidirectional
> PW, but not symmetrical.

> Rahul Aggarwal: CCAMP solves this
> 
> Luca Martini: We should make a decision this time.
> We need features that are not in the current protocol,
> do we want to start over? If you want this, use SIP
> 
> Rahul Aggarwal: RSVP does scale.
> 
> Dimitri Papadimitriou: there are mechanisms to cover
> Mustapha's comments
> 
> Nurit Sprecher:  RSVP provides many features that
> LDP does not. Cannot see how LDP can do it.
> 
> Florin Balus: If S-PEs are not ASBRs, how do you
> do path computation.
> 
> Rahul Aggarwal: The case is the same
> 
> Kireeti Kompella: The question is really take the
> mechanisms that you need. For LDP, TLV by TLV you
> will create CR-LDP.
> 
> Yakov Rekter: I am surprised Luca said RSVP was not
> designed for this.

What I said is that if one follows Luca's arguments that that RSVP-TE
should not be used for PWs because RSVP-TE was not designed for
PWs, then following the same line of reasoning one should not use
LDP for PWs (as the original LDP was not designed for PWs), and one
should not use BGP for the current Internet (as BGP was not designed
to carry well over 140,000 routes).
 
Yakov.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 16 Mar 2005 16:44:35 -0500

A couple of corrections

> On the IANA allocation: 
> Eric Rosen: agrees with Andy's point. 

I think I  suggested that the vendor-specific space have no  more than 32 or
64 values, and the rest be added to the FCFS space. 

> Eric Rosen: there have been cases where I have regretted
> a code point, but that has almost always been when they
> have been allocated through IETF consensus. A DoS attack
> is not likely. 

I think I said that a DoS attack  is not likely because there is no money to
be made in claiming code points and then selling them back. 

> Eric Rosen: Expert review keeps people from doing
> silly things with code points. 

I don't remember saying any such thing.   I believe I said that the value of
FCFS space  is that it prevents  innovation from being  stifled by political
machinations over the  granting of a codepoint.  This in  turn helps to keep
corporate competition in the marketplace rather than in the IETF.

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 17 Mar 2005 15:04:16 -0800 (PST)

Hi Stewart,

A couple of comments inline:

On Fri, 11 Mar 2005, Stewart Bryant wrote:

> Thanks
> Stewart
> WEDNESDAY, March 9, 2005, 1530-1730
>
> CHAIRs: Danny McPherson ([email-masked])
> Stewart Bryant ([email-masked])
>
> Minutes: Matthew Bocci ([email-masked])
>
>
> ------------------------------------------------------
>
> ADMINISTRIVIA
> -------------
> Chairs:
> Stewart Bryant chaired the meeting.
> Apologies from Danny who was called away at the last minute.
>
> Agenda Bashing:
> After the front end items, Luca will deal with all of
> control and encapsulation drafts. Then we will do Multi-Hop
> requirements, OAM and then signalling.
>
> Minutes:
> Matthew Bocci takes the minutes.
>
> WG DOCUMENT STATUS
> ------------------
> Stewart Bryant
>
> 2 RFCs now: PWE3 architecture came out today officially.
> In IESG review: TDM Requirements. Received some comments
> last week. Edits are in hand and a new version should be
> cut this week.
>
> In AD Review: Control word, PW setup/maintenance, Ethernet.
> These will act as template for all the other encapsulation
> drafts.
>
> Completed last call: HDLC was refreshed. IANA allocation,
> fragmentation, and ATM need an update to tie in with new style.
>
> Thomas Narten: IANA allocation needs to go with previous set.
>
> SONET/SDH, SATOP and structure aware TDM have completed
> last call. These will need another spin to cover bits
> moved from the control draft to the encapsulation documents.
> ATM cell transport is ready to go.
>
> Work in progress:
> VCCV is now ready for WG last call.
> Frame Relay needs to resolve the port mode issue. Then it
> will be ready for last call.
>
> PW over MPLS MIBs: (Tom Nadeau) All 7 drafts need a
> refresh after editing yesterday.
>
> PSEUDOWIRE SETUP AND MAINTENANCE USING LDP AND ETHERNET OVER MPLS
> -----------------------------------------------------------------
> Luca Martini
> draft-ietf-pwe3-control-protocol-15.txt
> draft-ietf-pwe3-ethernet-encap-09.txt
>
> Restructure of the drafts following AD review.
>
> PPP HDLC draft was sent out, got an acknowledgement, but was
> not posted for some reason.
>
> Thomas Narten: please follow up and CC Mark Townsend and chairs.
>
> 8 different drafts updated for this IETF. General reorganisation
> of the drafts.
> AD review points:
> - Too many normative refs,
> - MPLS WG needs to review LDP usage,
>
> Stewart: We should give them the final document.
>
> - Duplication of text in IANA and control,
> - Remove dependencies between control and encapsulation
>    documents. This is so that in the future we can just
>    create a new document and not update the control draft.
>
> Because we have L2TPv3 defined elsewhere, we removed notes
> to L2TPv3 and IP, so the documents are about MPLS only now.
>
> There are also some grammar and syntax corrections.
>
> General reorganisations:
> Documents only contain new allocations from existing IANA
> registries. All new IANA registries and initial allocations
> are in IANA document.
>
> Service specific text moved from control draft to the
> encapsulation drafts. Interface parameters specific to a
> given technologies.
>
> All text referring to IP/L2TPv3 remove needs to be removed.
>
> Control document:
> Removed IANA duplications, move technology specific text
> to service docs, updated PW status section according to
> email thread on list: MUST for PW status TLV, and MAY for
> label withdraw.
>
> IP PW type is left in the control document because this
> is described in RFC 3032.
>
> Security section needs some rewording to pass IESG review.
> Comments is that we must implement all applicable MPLS/LDP
> security measures, as defined in those documents.
>
> Ethernet encapsulation document:
> Changed tagged vs raw mode to be clearer.
> Remove SHOULD implement MIB as this was redundant.
> Security section -> use security offered by PSN.
>
> ATM encapsulation document:
> Did not make draft update deadline. Requires service
> specific text from the control draft. CW presence:
> MANDARTORY changed to REQUIRED. Grammar fixes.
> Reference structure changed with a normative reference
> to the control protocol document.
>
> Fame Relay Document:
> There was 80% rewrite of version 3. Document is now
> inline with PWE3 architecture and terminology.
> Requirement for padding removed.
> Changes still to come: sequencing text is ancient
> and broken. FR port mode text needs to be removed
> or edited, as this looks the same as HDLC mode.
> Plan to remove and put a note in the HDLC document
> that for historical reasons there is a FR port mode
> and this is the same.
>
> PPP/HDLC document: updated boilerplates, moved specific
> text to it.
> Next revision changes:
> - add note about HDLC = FR port mode.
>
> Chair asks for comments to resolve this: No one opposed
>
> PW types still have to match, but the bits on the wire
> are the same.
>
> Stewart Bryant: Take this as OK. Luca to send email
> out on the list with what he is doing.
>
> IANA document:
> Minor addition of new registries for TAII, SAII, and AGI type
>
> Andy Malis: I would be in favour of increasing the
> size of the 1st come 1st served at expense of vendor
> specific range.
>
> Luca Martini: several options:
> - IETF consensus
> - Expert allocation
> - 1st come 1st served
> - Vendor specific (private)
> - Experimental
>
> George Swallow: Why do you need 2 different registries
> for TAII and SAII?
>
> Luca Martini: Do we ever need different types? they
> should be the same.
>
> George Swallow: Its not the field's that need to be the
> same, but we only need one registry.
>
> Luca Martini: OK, one for SAII/TAII type, and one for AGI type.
>
> On the IANA allocation:
> Stewart Bryant: OK we can play with the sizes, but what
> about the policy?
>
> Andy Malis: would be interested to know why need strict
> control on allocations
>
> Luca Martini: we have much more space for control
> protocols. Would like to avoid people using the wrong
> types. I can change the ranges, but right now there is n
> o expert allocations in the ranges. Do we want this?
>
> Andy Malis: No
>
> Luca Martini: is anyone in favour of expert allocation
> for control protocols
>
> Thomas Narten: There is no reason for expert review for
> 1st come 1st served.  What is the minimal level of review
> required? Is there a potential of abuse?
>
> Luca Martini: personally, we should make it as easy as
> possible to allocate as people will do it anyway. People
> gave feedback that expert review did not work in the past.
>
> Thomas Narten: I'm not sure this is a good reason for
> no review. Need to say what is the minimal level of review,
> and then make sure it is timely. For expert review, there
> could be guidelines on what the WG intended. Could have
> expert review, and say that as long as WG is comfortable with
> it, then that is good enough.
>
> Yakov Rekter: do you mean IESG should outlaw 1st come
> 1st served?
>
> Thomas: No. But in 1st come 1st served, you run the
> risk of the outcome being undesired later. The right
> thing is to look at name space and see if there is no
> hard. Am opposed to blanket 1st come 1st served.
>
> Andy Malis: need to look far enough in future when there
> is no longer a working group.
>
> Stewart Bryant: isn't this a AD job if there is no WG left?
>
> Luca Martini: could put a time out in the draft for the
> expert to reply
>
> Thomas Narten: In that case, should replace the expert
> reviewer or use other mechanisms.
>
> Vach Kompella: what if you don't need an expert
> review, but just need to submit a draft.
>
> Luca Martini: OK put a requirement in that you need a draft.
>
> Vach Kompella: so rather than 1st come 1st served, that
> has its own DoS characteristics, write a draft.
>
> Andy Malis:  not sure there has ever been abuse
>
> Mark Townsley: never been any abuse of 1st come 1st
> served. What concerns me is that if somebody does something
> stupid after a WG shuts, there would be no review. If the
> registry space was huge, would be less of a concern. So,
> would be good to have some form of review. Right way is to
> fix the expert review process.
>
> Eric Grey: I think that having an ID being submitted
> for 1st come 1st served, it must be an ID targeted as
> being an RFC. Otherwise no one will review it.
>
> Luca Martini: you need this for IETF consensus.
>
> Eric Grey: IETF consensus agreed for standards track,
> but this is not true for an informational.
>
> Thomas Narten: a designated expert is a loaded term.
> The IANA considerations RFC has this because IANA does not
> want to make the judgement call. It is useful to have
> someone who understands what the registry is for. The
> designated expert simply says yes or no as an interface
> to IANA. They do not have all power: WG if still around
> has input.
>
> Luca Martini: process can take 6 months to a year
> Yakov Rekter: problem is that expert becomes judge.
> Expert should advise the people who want the allocation.
>
> Luca Martini: agrees that we would not want to kill
> innovation with the allocation process
>
> Kireeti Kompella: would like to revise 2334
>
> Stewart Bryant: Would like to ask Mark (AD) on how
> to proceed.
>
> Sense of the room: consensus is 1st come 1st served.
>
> Mark Townsley: OK but would like to take this to the list.
>
> Stewart Bryant asks if 1st come 1st served with a
> draft or without a draft:
>
> Stewart Bryant: Saw a minor preference towards
> with a draft: anyone object?
>
> Eric Grey: would prefer an informational RFC.
> People who have been putting proprietary protocols in
> informational RFCs.
>
> Outcome: Debate taken to the list.
>
>
> PW CONTROL WORD
> ---------------
> Stewart Bryant
> draft-ietf-pwe3-cw-01.txt
>
> Both chairs are the authors, so am concerned that this
> has full buy in from WG. This went to AD review. Most
> of the comments were editorial. There was also some
> discussion at last IETF on IANA policy.
>
> Two issues discussed on the list:
> - Wording on generic verses preferred CW
> Sense of the room: seems to indicate this is OK
>
> - Text for length field.
> Actually, all encapsulation drafts use a simpler
> version of the text. New text was sent to the list.
> New text addresses trimming of any added padding.
> Would like to get these words sorted out. Need to
> change text "Layer 2" to PW.  Also, "must be
> trimmed if required".
> Sense of room: Consensus on this.
>
>
>
> MULTI-HOP PSEUDO WIRE REQUIREMENTS
> ----------------------------------
> Nabil Bitar
> draft-martini-pwe3-mh-pw-requirements-01.txt
>
> Note: Agenda showed version 0.  Actual draft discussed
> was version 1.
>
> The scope is to describe requirements to allow a S
> ervice Provider to extend PWs across multiple domains
> and tunnels. Could be ASs, areas, etc.
>
> Shows current single segment architecture.
> In contrast, multi-segment PWs are composed of multiple
> segments, over any PSN tunnel.
>
> Explains concept and terminology.
> Endpoints are ultimate PEs, while switching points
> are S-PEs.
>
> Draft defines a list of terminology, applications:
> scalability, extending PWs to metro and access networks,
> extending PWs across provider boundaries to deal with
> confidentiality and security requirements, avoid
> continuous PSN tunnels across providers, and interworking
> between different PSN tunnelling technologies.
>
> Lists some of the architecture requirements:
> Transparency to P-routers maintained.
> Both directions must traverse same S-PEs.
>
> Setup mechanism requirements:
> - static endpoints with static or dynamic switching points
> List of detailed requirements on setup, resiliency,
> We talk about a PW backup as well as a path backup.
> TE and QoS requirements:
> - need to do admission control and carry PW parameters
>    in the signalling.
>
> Routing requirements:
> - Must support static as well as optional dynamic
> OAM requirements
>
> Next steps:
> - Security requirements text ready to add to next
>    version. All existing security requirements apply,
>    but also new ones for inter-provider case
> - Policy requirements
> - Consideration for any further refinement
> - WG option on multi-segment vs. multi-hop terminology
> - Request to accept this document as a WG draft
>
> Dimitri Papadimitriou: why does section 6.4 refer to
> a list of mechanisms of single segment signalling
> mechanisms. Why are you referring to single segment?
>
> Luca Martini: The idea was to use this document for
> all types of PWs, not just MPLS
>
> Dimitri Papadimitriou: The intention is to discuss
> multi-segment. But refers to single segment protocols.
> Why should I support this?
>
> Luca Martini: requirements is to support multi-hop
> for all types of PWs
>
> Rahul Aggarwal: This document talks about MS PW
> requirements. Why should it presuppose a particular SS
> signalling technology?
>
> Nabil Bitar: there was a discussion on the list about
> backwards compatibility.
>
> Luca Martini: Now this document has a collection of
> requirements from different people. If you think this
> requirement is a problem, send an email to the list.
>
> Himanshu Shah: it is ok to have requirements for a
> single hop to show we are consistent with single hop.
> There have been discussions on mailing list about
> explicit route. We are talking inter-domain: is it known
> at U-PEs that you can provide list of hops?
>
> Nabil Bitar: these are not always ASs. Could have a list
> of one AS that leads you to the next AS.
>
> Himanshu Shah: so there are cases when it is not
> possible.
>
> Stewart: please focus on issues blocking this moving
> to a WG document.
>
> Vach Kompella: are you talking about tunnel resiliency?
>
> Nabil Bitar: when you configure static endpoints, you
> need to protect the path of the PW, not the tunnel.
> You want to be able to choose different S-PEs if S-PEs fail.
>
> Yakov Rekter: in its present shape this document should
> not be WG document.
>
> Bruce Davie: a fine start and pruning can happen later,
> after WG status. Also, on L2TPv3, would be a nice
> requirement for this.
>
> Sense of the room to make a WG document.
>
> Stewart Bryant: should take discussion to the list.
>
>
> PWE3 APPLICATIONS & OAM SCENARIOS
> ---------------------------------
> Simon Delord
> draft-delord-pwe3-oam-applications-00.txt
>
>
> Thanks co-authors and many vendors that have provided
> feedback.
>
> Explains the service provider context: deliver
> end-to-end services over many technologies.
>
> Draft considers specific problems that will be met
> by SPs for deployment and monitoring of end-to-end
> services.
>
> Issues include:
> - Access/metro technologies may use different technologies,
> CEs may or may not be managed by SP, networks can belong
> to same or different SPs.
>
> What does it bring?
> - Background on how SPs handle/divide network sand for
>    which type of services
> - E2E service architecture from CE to CE
> - Specific focus on service supervision: fault detection
>    and fault localisation.
> - Based on well-known definitions.
> - Defines 3 generic models for E2E service supervision and
>    applies MEP and MIP points to these services
>    3 options: use specific e-e OAM, interworking
>      between OAM segments, using a client server model.
>
> Models are technology agnostic.
>
> Where does this draft fit?: There are 4 minor documents
> today in PWE3 and L2VPN:
> - OAM message mapping
> - OAM for VPWS interworking
> - L2VPN OAM framework
> - VCCV
>
> This draft can be the glue for all these documents. It
> provides clarification and applicability guidelines.
>
> Also brings requirements for pt2pt supervision.
>
> Conclusion and next steps:
> - A common view among service providers with generic models.
>
> Next steps:
> - L2VPN has already acknowledged this draft.
> - Specific requirements on PWE3 OAM will be identified
> - Include MH PWs
>
> Stewart Bryant: should this be done here or in PWE3?
>
> Simon Delord: it covers parts from PWE3
>
> Vach Kompella: Transit PSN could be a MH PW if you
> generalised picture. I am not convinced what the IETF
> needs to do except acknowledge that this exists. This is
> technology agnostic, but IETF is only interested in IETF
> protocols and how they are affected. Should this be
> defined here, or in a body that covers all of these
> other technologies. If they decide it is in scope,
> should do whole thing in L2VPN.
>
> Simon Delord: We are not talking about any specific
> OAM. This is a generic model.
>
> Vach Kompella: we have already defined OAM message
> mappings. Do we need a framework to show how these
> work end to end, or only how they impact IETF protocols?
>
> Mustapha Aissaoui: There is a place holder for VPWS
> OAM requirements. In the message mapping doc etc we
> made assumptions, which may not be understood by others.
> It does not do harm to include this in L2VPN framework.
> However, can understand Vach's position.
>
> Dave McDyson: This contains stuff relevant to L2VPN,
> so should be split.
>
> Tom Nadeau: The point is not to redefine what we
> have already done. Should take VPWS stuff and do it here.
>
> Monique Morrow: this is a good document and would
> like to see relevant parts split between the
> working groups.
>
> Ali Sajassi: Should include service specific stuff
> in L2VPN OAM requirements/framework.
>
> Outcome: Continue discussion on the list.
>
>
> PSEUDO WIRE (PW) OAM MESSAGE MAPPING
> ------------------------------------
> draft-ietf-pwe3-oam-msg-map-02.txt
> Mustapha Aissaoui
>
> Provides a quick update. Changes similar to those for
> draft-aissaoui. Separated forward and reverse PW state.
> Major entry / exit criteria rewrites.
>
> Next steps: Document is in a stable state and
> wants to ask to go for last call, but should see
> what happens to Simon's document.
>
>

[First Thanks to Matthew for very detailed notes].

The above should read "inter-domain TE PW".

> Claims that RSVP state the same as LDP

Then I asked for the document to be a WG document and Stewart said that
further discussion should be taken to the list.

thanks,
rahul

> MULTI-HOP PSEUDOWIRE SETUP AND MAINTENANCE USING LDP
> ----------------------------------------------------
> David McDysan & Florin Balus
> draft-balus-mh-pw-control-protocol-00.txt
>
> Dave explains the MH PW challenges and solutions, and
> described in the MS PW requirements draft.
> Basic approach is to add a switching PE.
> There are a number of solutions e.g. add BGP or
> RADIUS, RSVP-TE,  This approach to use a simple protocol
> in areas where you don't want BGP or RSVP.
>
> Dynamic creation using IP addressing
> Use IP routing to determine intermediate S-PEs.
>
> Lists some of the requirements not yet addressed:
> QoS and admission control, MH PW resiliency, do we need
> to traverse same S-PEs in the forward and the reverse
> directions. Asks for input from the list on the last point.
>
> Florin gives an overview of the solution. Introduces a
> MH PW TLV. Explains the fields. Runs through the
> signalling procedures. We are not trying to do CR-LDP.
> Use IP routing to find the next hop.
>
> Next steps:
> - should signalling procedures be in L2VPN or here?
>    L2VPN wanted to have the ??????????
>
> Mustapha Aissaoui: need to constrain the S-PEs to be
> the same in each direction so that you know where you
> get the state from. Also, are you using LDP-DU, and
> if so how the explicit route list helps?
>
> Florin Balus: the example was LDP DU, could use the
> same TLV for DoD.
>
> Kireeti Kompella: Why do you have a new TLV, when we
> already have one? Why not just use ERO object?
>
>
> PSEUDOWIRE QOS SIGNALING
> ------------------------
> Himanshu Shah
> draft-shah-pwe3-pw-qos-signaling-02.txt
>
> This was presented 2 IETF meetings ago. We reviewed
> why we need to signal QoS.
>
> New draft has added dynamically signalled ATM circuits,
> multi-segment PWs.
>
> Updates in the current rev: added clarifications on
> why PW QoS TLV needed, support for multiple QoS TLVs.
>
> Shows example of how this works in MS PW and congestion
> notification case.
>
> Asks for this to be a WG item.
>
> Kireeti Kompella: do you want LDP with explicit routing
> and QoS? That is described in RFC 3212.
>
> Nurit Sprecher: DiffServ parameters etc are missing.
> Why not use existing protocols?
>
>
> MULTIHOP PSEUDOWIRE SIGNALING
> ------------------------------
> Himanshu Shah
> draft-shah-bocci-pwe3-ms-pw-signaling-00.txt
>
>
> This is another PW signalling mechanisms want to
> reuse the same PW signalling as much as possible,
> Eliminate requirement to configure SPEs, and want to
> use a mechanism that gives resiliency for primary
> with a backup PW.
>
> Gives overview of the solution with animations for
> some scenarios.
>
> Kireeti Kompella: all these things about backwards
> compatibility. I have nothing against LDP, but just call
> a spade a spade.
>
> Dave McDysan: this is more general work than PWE3
>
> Luca Martini: would like to know where routing of PWs
> belongs
>
> Stewart Bryant: routing is a layer 2 VPN problem
>
> Hamid Ould-Brahim: I don't see routing is relevant.
> Why not use PCE?
>
> Mark Townsley: What Stewart says makes sense: one
> PW does not do much. The service is L2VPN.
>
> Stewart: take to the list.
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: David McDysan <[email-masked]>
Date: Tue, 22 Mar 2005 08:37:30 -0500

Clarification of the minutes below.

Dave 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stewart Bryant
> Sent: Friday, March 11, 2005 7:42 AM
> To: pwe3
> Subject: [PWE3] dratf minutes PWE3 @ IETF62
> 

> There are a number of solutions e.g. add BGP or RADIUS, 
> RSVP-TE,  This approach to use a simple protocol in areas 
> where you don't want BGP or RSVP.
> 
> QoS and admission control, MH PW resiliency, do we need to 
> traverse same S-PEs in the forward and the reverse 
> Florin gives an overview of the solution. Introduces a MH PW 
> TLV. Explains the fields. Runs through the signalling 
> procedures. We are not trying to do CR-LDP.

L2VPN believed that the signaling should be in PWE3.

> 
> Mustapha Aissaoui: need to constrain the S-PEs to be the same 
> in each direction so that you know where you get the state 
> from. Also, are you using LDP-DU, and if so how the explicit 
> route list helps?
> 
> Florin Balus: the example was LDP DU, could use the same TLV for DoD.
> 
> Kireeti Kompella: Why do you have a new TLV, when we already 
> have one? Why not just use ERO object?
> 
>