Subject: PWE3 minutes from IETF62

From: Stewart Bryant <[email-masked]>
Date: Thu, 24 Mar 2005 11:18:33 +0000

PWE3 IETF62 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:

Eric Rosen: I suggest that the vendor-specific space have no  more
than 32 or 64 values, and the rest be added to the FCFS space.

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 no 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.

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 because there is no money
to be made in claiming code points and then selling them back.

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.

Eric Rosen: 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.

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 Service 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.

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 PW segment end points.

Explains how inter-domain TE 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. This 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
Asks for the draft to become a working group document.

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 cannot. Cannot
see how LDP can do it. reading the requirements draft on the MH (MS)
PW, there are new requirements for TE (Traffic Engineering) services
(PWs). These include requirements for explicit routes, traffic
parameters, traffic priority, traffic class, resiliency, etc. In
order to allow the S-PEs to select the appropriate tunnel for the
MS PWs (Which apply to the TE requirements), the entire information
should be signaled when establishing the PWs. RSVP-TE naturally
provides the means to include this information, except for two
things, which is very easy to add: the PW ID/PW type and the
control word. LDP should be enhanced to include the new requirements
for TE PWs. And my assumption is that we are behind the argument of
using RSVP-TE or CR-LDP. RSVP-TE was already chosen as the protocol
for TE.

Florin Balus: When the ABRs are not S-PEs, adjacent S-PEs being
for example in different OSPF areas. A direct forwarding adjacency
cannot be used in between those 2 S-PEs. 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: 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).

Discussion taken to the list.

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?

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: QoS is a very important part of the TE requirements
but not the only one. We have requirements for traffic priority,
requirements for specific traffic class, requirements for protection
(e.g. no more than 50 ms of traffic disruption when a failure
occurs), requirements for traffic priority, etc. None of these,
except for the QoS traffic parameters is included in the proposed
draft. In addition I said that for TE we are using TE tunnels (which
are signaled using the RSVP-TE protocol). Why should we use another
new protocol for establishing the services?

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.

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 28 Mar 2005 10:49:21 +0300

> Kireeti Kompella: Would like to revise 2334.

While revising the Server Cache Synchronization Protocol (SCSP)
might be interesting, I think Kireeti meant 2434.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 28 Mar 2005 19:18:41 +0300

Stewart and Danny, 

Sorry for my waking up late in noticing this.

The minutes state:

        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.

That may be the case for the SONET/SDH encap document;
but for SAToP, CESoPSN and TDMoIP we had agreed
(and I mentioned at the meeting) that it was not reasonable to place the
signaling
material in all three documents separately.

Instead, Sasha and I will put together a single TDM signaling document,
extensively reusing material from Sasha's "control protocol extension"
draft,
which will cover all the low-rate TDM drafts.

Y(J)S

---

From: "Ron Cohen" <[email-masked]>
Date: Mon, 28 Mar 2005 08:48:53 -0800

CEP has signaling and encapsulation already in one draft CEP-10

Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yaakov Stein
Sent: Monday, March 28, 2005 8:19 AM
To: Stewart Bryant; Danny McPherson
Cc: pwe3
Subject: RE: [PWE3] PWE3 minutes from IETF62

Stewart and Danny, 

The minutes state:

That may be the case for the SONET/SDH encap document;
but for SAToP, CESoPSN and TDMoIP we had agreed
(and I mentioned at the meeting) that it was not reasonable to place the
signaling material in all three documents separately.

Instead, Sasha and I will put together a single TDM signaling document,
extensively reusing material from Sasha's "control protocol extension"
draft, which will cover all the low-rate TDM drafts.

Y(J)S

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3