Subject: dratf minutes PWE3 @ IETF62

From: Stewart Bryant <[email-masked]>
Date: Fri, 11 Mar 2005 12:41:32 +0000

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

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:
Eric Rosen: agrees with Andy's point.

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.

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.

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: Expert review keeps people from doing
silly things with code points.

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.

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.

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.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 14 Mar 2005 15:04:34 +0000

We will correct in the final version of the minutes.

Stewart

> 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: "Nurit Sprecher" <[email-masked]>
Date: Wed, 16 Mar 2005 14:07:31 +0200

Also some additions to my statements:

1.    I said that 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.

2.    Regarding draft-shah-pwe3-pw-qos-signaling, I said that 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?

Thanks,

Nurit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yakov Rekhter
Sent: Monday, March 14, 2005 4:44 PM
To: Stewart Bryant
Cc: pwe3
Subject: Re: [PWE3] dratf minutes PWE3 @ IETF62 

Stewart,

> Please review and feedback by 25th March.

one correction - see below...

[clipped...]

Yakov.

_______________________________________________

pwe3 mailing list

[email-masked]

https://www1.ietf.org/mailman/listinfo/pwe3

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

---

From: "Florin Balus" <[email-masked]>
Date: Tue, 22 Mar 2005 11:27:16 -0500

Some corrections on the minutes below...

> 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
> 
> 
[...] 
> SETUP AND MAINTENANCE OF PSEUDOWIRES USING RSVP-TE
[...]  
> Florin Balus: If S-PEs are not ASBRs, how do you

I think I asked about the case 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 hence the challenges with dynamic
path computation.  

[...]