PWE3 IETF63, Thursday November 10th 2005.
CHAIRS: Stewart Bryant (email@example.com) & Danny McPherson
MINUTES: Matthew Bocci with additional notes from Yaakov Stein
SLIDES: Available at http://pwe3.tcb.net
Agenda: Stewart Bryant
Requested to move fibre channel to after MS-PW presentations, then OAM and then some other issues.
No other comments on the agenda.
Danny is not available this week and send his apologies. All but two sets of slides available. No slides, no presentation. This is a final warning!
Status of WG drafts: Stewart Bryant
Now have 3 RFCs 4197 is the new one: TDM reqs.
Control draft is now in the RFC editors queue.
Then a small batch in IESG review: went through IETF last call.
Ethernet has a discuss on it saying that it needs an applicability statement. This will be added.
Needs to remove some text and a bunch of detailed edits.
Blocking on a need for an IEEE review.
Mark Townsley: not technically an IEEE review, rather asking some people in IEEE to review it. Asks for some people in the room who is involved or who know someone and who can comment on the flow control. Want to avoid invoking overhead of a formal IEEE review.
IANA draft: one remaining issue to discuss, and some AVT related code points from the IANA draft.
Plan is to do this, then once in RFC editors queue IANA will create the registry. AVT will have to go though IANA process.
ATM: needs applicability statement.
Control word is in the RFC editor's queue.
SAToP is ready, but Stewart needs to write proto questionnaire.
Final WG last call: fragmentation, FCS retention, SONET, ATM cell transport.
Stewart asks for other people to review!
David Black: Have heard that if no one reviews a document, then ceratin WGs won't progress it.
Andy Malis: These documents have been reviewed many times
Mark Townsley: just needs to be reviewed at some
Outstanding WG last comments: the following need minor edits: FR, HDLC, CESoPSN, TDMoIP
Work in progress: mostly MIBS. Also need MIBs for ATM, FR etc
All else is work in progress.
Charter: Danny sent last call on the charter. Added PW protection. This will go to the IESG in a week or so.
An Architecture for Multi-Segment PWE3
Matthew Bocci (firstname.lastname@example.org)
Presents an overview of the updates since the last version.
The terminology has changed: a U-PE is now called a T-PE
Added maintenance reference model, and S-PE functionality
Matthew shows the reference model (end-end signalling and hop-hop as well)
S-PE capabilities: S-PEs do not have NSPs and do not see native service circuits
Service up only if both directions up in all segments
Mechanisms need to be provided to prevent misconnection, e.g. ensuring PW types are compatible
Security section (based on 3985): if S-PEs are dynamically selected, they need ASBR like behaviour
Need mechanisms to prevent misconnection of segment into an AC
Asks for comments and text and proposes to make this a WG draft
Luca Martini: if there is a set of providers, need authenticate originator, not just other provider
Yakov Rekhter: Authentication originator is similar to Secure Origin BGP, which is known to be fairly complex. For now we should focus on authenticating peers, rather than source authentication.
Sasha Vainstein: MS PW up if both directions of all segments are up - isn't this already implied?
Matthew: Need to traverse same S-PEs, but there is no implication if you set up all segments in one direction, followed by all in the other direction, or if you do both directions simultaneously in a hop-by-hop manner. This statement says that either way, you must wait until all segments in both directions are up.
Stewart Bryant: Who agrees with making this a WG draft? There is an overwhelming majority
Dynamic Multi-Segment Pseudo Wire Signaling Procedures Using LDP
Florin Balus (email@example.com)
Matthew Bocci presents the first section.
Background: set and maintenance by extending standard PWE LDP protocol and there is the segmented PW draft, where you must configure S-PEs. In the last IETF there were two drafts for using LDP to dynamically select S-PEs. These have subsequently been merged.
This new draft works for SS and MS PWs, with a minimal number of provisioning touches (only T-PEs).
The same T-PEs and S-PEs are used in both directions. The signalling of TE parameters and CAC is supported, as well as end-end negotiation of OAM.
Florin Balus takes over the presentation.
Addressing format that allows dynamic selection and summarisation.
Allows tracing without revealing private layer 3 addresses.
Shows example of MS-PW information model - unique identification of the PW endpoint.
Claims it is consistent with the existing addressing.
Shows an example of the signalling procedures. MS-PWs effectively behave as a superset of SS-PWs
Routing information is disseminated using static provisioning or dynamic advertisement e.g. with MP-BGP.
Other related procedures: QoS TLV, Explicit routing, OAM negotiation, FEC 128 support
Next steps: need feedback on the hybrid FEC128/129 usage case
High level of interest so would like to progress to a WG draft.
Sasha Vainstein: how are roles of initiator and responder of signalling determined?
Florin Balus: compare TAII and SAII, or provisioning
Yakov Rekhter: Explicit route LDP: is that from CR-LDP?
Yakov Rekhter: Are you using RSVP T-SPEC?
Yakov Rekhter: How hard would it be to use CR-LDP?
Florin: no need to ask for a new type. There was a draft on mapping to TSPEC
Easy to use RSVP-TE tspec. CR-LDP uses a mapping to TSPEC object.
Yakov Rekhter: How do you do reroutes around failures in static routing
Florin: can use a default gateway configuration
Yakov Rekhter: How can you do loop avoidance?
Florin: Routing protocol will do this, or can use PW switching TLV
Rahul Aggarwal: On next steps, at last IETF we had a section on MS-PWs. There was a decision that the requirements draft needed to be revised with required/optional requirements. We need to continue this. Not sure it is constructive to go to WG draft at the moment.
Florin: if there is another interest, should go ahead. Don't see a reason to peg the two solutions together.
Stewart Bryant: The question is reasonable, just as you asked for RSVP draft. However, it is also appropriate to ask about the revisions to the requirements document.
Luca Martini: we have revised requirements document in this way
Peter Busschbach: At some point we had a discussion that QoS was needed for the intermediate points as well as the end points. Is QoS relevant only to end-points or to intermediates?
Florin: May or may not use it if you need CAC
Peter Busschbach: Must it be?
Florin: Cannot mandate a must.
Peter Busschbach : Should clarify this point.
Dave McDyson: do we really need one solution? Trying to strive for one size fits all may not be possible.
Stewart Bryant: I will ask individually if each draft should be a WG draft.
Dave McDyson: by saying that you support this, you are not excluding the other draft.
Stewart Bryant: Each draft has to independently justify its existence
Yakov Rekhter: If you do carry T-SPEC, should you use this to select next hop, and do you need extensions to BGP? That is, information that may be matched to TSPEC.
Florin: we just advertise reachability at the moment. Can use IGP
Yakov Rekhter: IGP doesn't do this. Do you want to extend BGP for inter provider case?
Luca Martini: Think we can use mechanisms that we have today. We have had extensive discussion on the list about the RSVP-TE draft. Result was no consensus to progress this work. It is still missing major parts of the design. We need to make a choice.
Rahul Aggarwal: In the IETF in Paris, the room was polled for both versions. My view from the audience was that there similar support.
Mark Townsley: would strongly urge the group to make a choice. If anyone believes that it is impossible with one or the other, say now.
Luca Martini: It was 3:1 or 4:1 in Paris in favour of LDP
Yakov Rekhter: The choice shouldn't be driven by the IETF, but by the market.
Dimitri Papadimitriou: What happens if there is an overlap in the markets?
Mark Townsley: I am asking that if they apply to substantially the same environments, make the choice now.
Kireeti Kompella: Heard Dave McDyson saying "I don't know which one I want now". This is different from saying that if they are for the same environments, choose now. We may not have enough information to choose now. This is different from RSVP vs CR-LDP : they were much closer. Need to put a line in the sand saying that we do not go forward to draft standard. It is not impossible to do
this with either LDP or RSVP. That is not the issue. Should do both because there are different ways of doing things and come back to the discussion when we are at draft standard status.
Dave McDyson: The way to do this is to add applicability statements to each draft. Would like to see both progress and understand the applicability.
Mark Townsley: I asked if this impossible with either. Kireeti answered that. So, I asked, is it impossible with both? Is it a requirement that the T-PE initiator is single hop or multi-hop?
Stewart Bryant: How important is it to co-exist with single hop? Personally, I think so.
Kireeti Kompella: Need to take consensus independently on progressing them.
Ping Pan: This is up to the market to decide. There is an implementation available: got it working already between last IETF and this IETF.
Luca Martini: How many tests of consensus do you want?
Stewart Bryant: Who here thinks we need to come to a firm conclusion that we
Mark Townsley: How many want one solution, how many want two?
Stewart Bryant: How many want one solution before progressing?: Quite a few
Stewart Bryant: How many want to take them both progressed and make a decision later?: substantially more.
Yaakov Stein: if we go forward like this, and we have a QoS issue, do we have to have RSVP for single segment?
Luca Martini: how many people want three or four?
Stewart Bryant: Who thinks this should be a WG draft? Large number in favour
Setup and Maintenance of Pseudowires using RSVP-TE
Dimitri presents the status of the draft.
The authors have progressed on refining the text and the procedures. Sender_TSPEC clarified.
Discussion: do we need to document how this fits the requirements?
Authors ask for this to be a WG document
Luca Martini: We discussed this document at length on the mailing list. We didn't have consensus then. What has changed? My questions were things like how you do status, addressing.
Dimitri: The document discussed after Minneapolis was not as presented today.
Stewart Bryant: there was a discussion and no consensus. Are there outstanding technical issues?
Luca Martini: we have not addressed how you do the addressing and status messaging. This document has a sketch of how you do it, but someone has to write it down in detail.
Rahul Aggarwal: PW FECs can be used. Does the choice of which is ready to be implemented need to be addressed yet? No.
Luca Martini: Needs an addressing scheme for layer 2. In the LDP draft, made a big effort to specify all of the addressing details.
Stewart Bryant: There should be a reasonable expectation that it will be a viable technical solution
Stewart Bryant: Asks who agrees with making this a WG draft: A moderate number.
Should put both to the list.
Rahul Aggarwal: I think we should progress both and ask the question a bit more carefully
Eric Rosen: Sometimes a WG is willing to accept a document because they think the alternative is that the authors will mount a DoS attack on the WG, and I wonder if that's the case here.
Dave McDyson: It would be helpful to have applicability statements and additional work e.g. references to use cases.
Stewart Bryant: I agree that there needs to be clear applicability statements.
Himanshu Shah: would like to see this
MarK Townsley: There must be a section in each draft explaining how they co-exist.
Stewart Bryant: That includes co-existence with the old stuff
George swallow: Does this also mean interoperability in the inter-provider case?
Mark Townsley: It means interworking.
Dimitri: What's a coexistence section?
Stewart Bryant: We do have an existing single hop solution that is deployed, so they both need a section showing this.
Stewart Bryant: Do we have to co-exist with existing PW control? Strong support.
So all solutions will have to describe how they co-exist.
Morin Roth: can write this.
Stewart Bryant: Who is against making this a WG draft? A few. Will ask the question to the list.
[Note: This topic was discussed at length on PWE3 mailing list following the meeting. The reader is referred to this for further information. ]
Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks
Ronen Solomon (RonenS@corrigent.com)
Presents an overview of the draft. This was originally presented in Paris.
T11 approved FC-BB4, which allows MPLS transparent p2p FC transport over PW.
Idea is to take FC ACs and have PW emulate end to end service. NSP is handled by T11
For the new version of the draft, we added applicability. Faithfulness improved by providing low loss, low reordering of event, low delay, NSP handles bandwidth-controlled behaviour during congestion.
FC data frame, control and primitive sequences use the same PW.
Shows an overview of the signalling.
MTU: the PSN should be able to transport the largest FC encapsulation.
Control word: must use the PW control word.
Assign new PW type for FC
Would like to go to WG draft
David Black: there is no RFC2581-class (TCP-class) congestion control in
Fibre Channel, hence leaving congestion control to the NSP (i.e., Fibre Channel) will not be acceptable (to the Transport Area) in all cases. Need you to write up an applicability to networks as you move from low loss, tightly constrained networks, to where you have congested anything goes IP network. Need to identify where you do need TCP congestion control, and where this is therefore not applicable. I will run this by some transport area experts.
The applicability statement needs to be carefully written, particularly with respect to the expectations on the PSN.
Stewart Bryant: If they accept a controlled environment then this would clearly work, and can work on it if there is interest.
There were no objections to Fibre Channel draft becoming a working group document. It will be asked once again on the list.
Link Aggregation Member Interface Status Signal
Zi Kang (firstname.lastname@example.org)
PWE3 requires same BW on each AC
Shows a use case: all ports are a member of a trunk. Handles case if one AC on a trunk fails.
Introduces a new TLV indicating BW.
Asks for comments.
Ping Pan: why can't do this with VCCV? Also, can't RSVP deal with this if you do link aggregation?
Zi: No VCCV for RSVP
Stewart Bryant: Isn't he worried about external link rather than internal?
Himanshu Shah: There is a common solution to QoS on PW. This has already been documented in the PW QoS signalling draft so doesn't see any need to do this.
Sasha Vainstein: You say PWE3 requires the two ACs to have same BW. Apart form TDM, I do not remember this as a requirement for anything else.
Stewart Bryant: There is no such requirement for any packet or cell services.
Luca Martini: You are trying to create a PW type for trunks. That might be a useful solution, but today people are deploying one AC for one PW, and using trunks over this. We can make this work today by just provisioning.
Scott Brim: Compare with what you would do in a physical environment. If one port fails, don't you just kill the whole trunk?. Don't think you should require something in PW technology.
George Swallow: This just makes you drop earlier.
Stewart Bryant: can I ask that you articulate the requirement more precisely to the group on the list.
Scott Brim: and a little more clarity about the specific service that you are carrying over the PW
Operation and Maintenance for Multi-segment Pseudo Wire
Jixiong Dong (email@example.com)
Two levels: segment and end to end OAM.
End to end OAM packets transparent to the S-PE.
Proposes an in band FDI generated on a PW segment failure. This results in an RDI from the remote T-PE, or PW status.
In order to distinguish end-to-end OAM, includes a new VCCV packet type.
Next steps: RDI and PW mismatch
Monique Morrow: What is the difference between this and what is already in the PW segmented draft?
Ping Pan: PW segmented draft doesn't have OAM
Jixiong: Segment OAM is only for faults on one segment.
George Swallow: the way this is built, it will be a lot easier to do the end-to-end bit. Only way to catch this is TTL.
Dinesh Mohan: The framework is the right way to look at it. I'm not sure of the specific solution. This seems to imply a change to the existing SS-PW OAM. Need to avoid this.
Yaakov Stein (firstname.lastname@example.org)
Two PW OAM methods: original TDMoIP had one OAM PW per tunnel, and assumed defects are the same for all PWs.
VCCV OAM: OAM packets in each PW. Higher overhead when there are many PWs in same tunnel. The second is probably easier to do architecturally. So proposal is to go to the VCCV style OAM, but add additional things we need: PM such as delay, PDV, packet loss ratio. For TDM PWs it is also useful to monitor backup PWs for fast switch over without timing degradation.
Shows a VCCV-style performance OAM packet format.
What should time format be? RTP, NTP, ICMP, IEEE1588 style
How many timestamps?: 1, for approximate round trip, 2 for approximate one way, 3 - for round trip with delta T, 4 - for ICMP
Peter Busschbach: VCCV is primarily to carry other OAM protocols over PWs. We need a performance monitoring method generally applicable to MPLS.
Yaakov: So you want to go back to the original method of monitoring per MPLS tunnel?
Peter Busschbach: the point is if you want to do delay/packet loss, should apply to MPLS in general. Then you can run them over MPLS layer.
Yaakov: I am particularly interested in TDM PWs, but may need some PM for MPLS in general.
Peter Busschbach: expand to general MPLS problem.
Sasha Vainstein: applicable to non-TDM PWs as well. Measurement of packet loss have discussed in the PW congestion draft by Eric, which has withered since. He has indicated severe problems for non-TDM PWs.
Yaakov: In the PWE3 model, i/w model starts in the PE. But there is the issue of when the PW starts before the PE.
George Swallow: It is not clear that the way to measure packet loss for TDM would be the same for other types. I did intend that we should do other things with VCCV. I support this work, and it is appropriate to look at what could be moved into MPLS. The control channel issue was not the be all and end all of VCCV.
Monique Morrow: needs a little more discussion, including mitigating against the complexities here.
Yaakov: thinking of the functions, if it is at the PW layer, this is simper than at the MPLS layer.
Dinesh Mohan: need to think about the role of VCCV. It is a control channel today, and you run other protocols in the payloads. But, we need extensions because there are some new requirements that are coming out.
Ping Pan: We have used per PW OAM. Needed to support non-MPLS tunnels. Should apply to non TDM PWs. On the time stamps, probably don't want to get involved in timestamps again.
George Swallow: I was misunderstood. There are a few things here that may be generally used. If there are some things that can be put into LSP ping, then we can do that. But, the control word is designed so that we can make extensions for specific applications that do not.
Stewart Bryant: Take it to the list, partitioning work between general and specialised.
AII Types for Aggregation
Chris Metz (email@example.com)
Luca Martini presents the changes from 00.
Shows the AII type I which is in the , and type II which includes an global ID that should be RD i.e. an AS#
Shows the long prefix version. This has no structure, so could work for IPv6
Next steps: synced with L2VPN signalling and dynamic MS-PW placement.
Ping Pan: AII type II is suitable for MS-PW , George has a PNNI i/w type... there are a lot coming along
Luca: I don't have an objection to documenting more
Ping Pan: just need to be consistent
Target Choice of FEC Type
George Swallow (firstname.lastname@example.org)
Title of the draft should say PW type, not FEC type.
Background: 2 years ago brought in a draft that interworked with ATM S-PVC.
MFA Forum took this up because only a small bits and pieces affect PWE.
Those pieces brought back here.
Shows the reference application. Transitioning ATM endpoints to PEs. and also redundancy with no single failure points.
Sometimes you can tell clearly if the S-PVC if frame relay / ATM, and sometimes you cannot at the boundary.
If it is FR, would be nice to be able to reassemble at that point.
Don't know what PW type to put in at the boundary, but want the target to make the decision.
Ping Pan: Your previous draft expired? We are doing this and the customer asks where the draft is.
George: This is being progressed at the MFA.
Ping Pan: why not do this here?
George: There are lots of details about how you interwork with ATM so not really right place here
Florin Balus: how do you prevent misconfigurations?
Andrew Dolganow: it would be a very old signalling message that doesn't tell me
Stewart Bryant: ask to the list if this needs to be done and if it should be a WG draft.
Pseudo Wire Security
Yaakov Stein (email@example.com)
The time has come to look into this. There are PW specific attacks and certain things that are specific to PWs.
Shows a list of the threats to PWs.
Out of scope is anything related to the customer network, the AC, considerations to all MPLS networks, L2TPv3 (done in L2TP extensions) and considerations specific to MS PWs.
Security weaknesses: PW label is the only identifier, CW sequence number can be used for DoS attack, PWE3 control doesn't mandate authentication, VPLS, auto discovery and MS-PWs all introduce new problems.
Security strengths: most attacks require compromising a router at some place, adequate protection of the control traffic can help with this, can't insert a packet with proper format outside the SP network.
Gives an example of PW man in the middle. Man in the middle looks like an S-PE. Not the same as MPLS-layer man in the middle.
Should also look at encryption of PW packet: as the PW does not provide packet integrity, and thus the encryption mechanism must be per-packet and history independent. Cannot encrypt PW label (not legal MPLS), or control word since loose 0000 from first 4 bits. So how is this different from service encryption? No packet reliability (retransmission) at PW layer so PW level encryption should work with packet loss, while service layer may be stream cypher.
Work on draft has started, but would appreciate co-authors.
Don O'Connor: Ethernet security in 802.1 suggests we would want to do this on every frame.
PW Type for ATM Virtual Trunks
Peter Busschbach (firstname.lastname@example.org)
A few words on the liaison sent from MFA Forum on ATM-MPLS-ATM control plane interworking. Two approaches: clinet-to-client with a 1:1 mapping from ATM VCs to PWs. Virtual trunks (related to this liaison statement): establish single PW between PEs, and run a single PW for all ATM VCs. Separates ATM and MPLS control plane functionality. Shows the details of how you translate VPI ranges. VPI ranges are locally significant, so MEs translate VPI ranges.
None of the existing PW types apply, because N:1 mode explicitly does not change the VPI values. Asks for a new PW type for VTs.
Luca Martini: where is the liaison statement? I would have put the code point in if I had seen it.
Andy Malis: I did upload it!
Stewart Bryant: should wait for the registry to be set up