Subject: [PWE3] Draft Prague minutes

From: [email-masked]
Date: Thu, 29 Mar 2007 12:08:20 +0100

Please find below the draft minutes for the PWE3 meeting in Prague.

Please let me know if you have any comments / corrections.

Regards,

Matthew

TUESDAY, March 20th, 2007 - 15:20 - 17:20
-----------------------------------
CHAIRS: Danny McPherson (danny at tcb.net) & Stewart Bryant (stbryant at
cisco.com)
Minutes: Matthew Bocci (matthew.bocci at alcatel-lucent.co.uk)
SLIDES (to be posted): http://www3.ietf.org/proceedings/07mar/index.html

WG Status and Update - Chairs
-----------------------------
AII aggregation in RFC editor queue.
IPR statement delayed sent in august.
OAM msg map in LC.
MIBs - 4 are in LC, ends at end of this week.
Fibre Channel - held up by transport area review.

Ronen Solomon - can we schedule a time line for when we are expecting a
response?
Stewart - We tried to assign date of before this IETF. Will chase them.

T-MPLS draft:
Yakov Rekhter - We should accept as a WG draft
Danny - I agree this is time. We will put forward on the list.

RFC4446 has an AGI type that is a route distinguisher.

MS-PW requirements is in last call.
PW protection - added to the charter.
TDM signalling - this has expired.
Yaakov Stein - needs a couple of small changes then ready for last call

PW security - Yaakov Stein ([email-masked])
---------------------------------------------
After the last meeting there were some comments on requirements. A new rev
of draft was done. PW sec mechanisms draft is still at -00.
Question - do we need a PW specific or a general MPLS solution?
What is the issue: confidentiality, integrity, or authentication?
What are the scenarios requiring PW specific security?
Are there enough providers who want this?

What are the solutions?
- Requiring MPLSoIPoMPLS and using IPSec: which providers use this?
- Defining a security PW type in which arbitrary MPLS can be tunnelled? But
is this ruled out by MPLS as currently defined?
- Generic security option for PWs e.g. PWsec.

Danny McPherson: will take PW security work to the list and see if support
from operators and vendors. If sufficient support, then get officially
chartered.

Luca Martini: Service providers he polled, only one said they needed it
using L2TP cookie. No others had any interest.

Segmented Pseudowire - Luca Martini ([email-masked])
--------------------------------------------------------
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-segmented-pw-04.txt
Reviews changes to the draft, in particular procedures for mapping PW
status at S-PEs.

Presents changes since v3.
- MS VCCV
- MS-PW status section.
- Move active/passive role section to this document
- Switching point TLV is a useful feature and should be MUST to process and
OPTIONAL to send
- Added PW status introduction text
To do:
- Finish MS-VCCV
- Expand the applicability section

Explains the way PW status works with a failure of the transmit direction
in an intermediate segment of an MS-PW, and how multiple failures clear.

Dave McDyson: Status information might be challenging. What if an
attachment circuit goes down? There is information in this control plane to
do a better job. With this model, you have to mine everything from the
network.

Mustapha Aissaoui: It's not that you keep track of many failures. If you
get an AC fault and a PW fault, AC failure after PW failure, you should
suppress AC failure.

?: Should keep option to pass AC down. Need this for dynamic MS PW case and
other applications.

Danny McPherson: Take it to the list.
George Swallow: I don't see any value in suppressing the generation. We
suppress the alarm already. Whether you have the extra bit set then you
will not suppress this in the control plane.
Ronen Solomon - both status can go through the network and can suppress at
the end.
Luca Martini: Trade off with the number of PWs.

Pseudowire (PW) Redundancy - Praveen Muley
([email-masked])
-----------------------------------------------------------------------------
http://www.ietf.org/internet-drafts/draft-muley-pwe3-redundancy-01.txt

Changes are to merge with draft-dutta on VPLS standby from L2VPN.
Move forwarding bit definition to a separate draft.

Danny McPherson: Would like to request as a working group draft.

Luca Martini: Want to understand what the problem is. This is a property of
the attachment circuit. We don't need any protocol changes.

Praveen Muley: Need to not propagate the fault to the attachment circuit on
the other side.

Mustapha Aissaoui: When you do APS to two different nodes, the two nodes in
Multi-chassis APS do communicate among themselves, but they need to
synchronise to the other side of the network.
Luca Martini: All you need is a bit to say PW is not down
Mustapha Aissaoui: PW is not down - you can use VCCV on it etc
Luca Martini: Nothing says you have to stop OAM.

Danny McPherson: There is a requirement to switch between T-PEs and S-PEs
in MS-PWs requirements.

Praveen Muley: This is intended to be informational.

Pseudowire Preferential Forwarding Status bit definition - Mustapha
Aissaoui ([email-masked])
--------------------------------------------------------------------------------
http://www.ietf.org/internet-drafts/draft-muley-dutta-pwe3-redundancy-bit-00.txt

This describes the Active/standby bit. Two other drafts describe the
applications.

Outcome of IETF 67 was to write a separate draft explaining the new bit,
how it is used, and how it interoperates with existing implementations.

Defined active state: PW labels are exchanged between two terminating
points.
Standby state is when PW labels are exchanged, but data path traffic is
blocked at either or both ends.

Two modes of operation - Independent mode does not mandate synchronization
of the PW forwarding paths. If a PW shows local and remote active, then
this must be selected as active.
Shows a diagram illustrating the independent use case
Master/slave mode - one side drives the other side, and has to drive the
other side to tell it what forwarding to use. The slave node should block
forwarding when over the PW when the RX status bit transitions from active
to standby. Shows an example of the master/slave use case for H-VPLS

Interop with existing implementations - T-PE/S-PE that does not implement
this keeps PW active as long as it is operationally up.

Requests status bit

Luca Martini: H-VPLS example. There are several solutions for this already
e.g. using CFM, Spanning tree. In L2VPN you can use MAC flush.
Mustapha Aissaoui: yes, and those are fine as far as they go.
Luca Martini: Need to be clear that no matter what the bits are OAM will
flow.
Mustapha Aissaoui: Yes, this does not change that.

Continued discussion on whether PW not forwarding should raise an alarm at
the other side.

Dynamic MS-PW Routing using OSPF - Andrew Dolganow
([email-masked])
-----------------------------------------------------------------------------
http://www.ietf.org/internet-drafts/draft-dolganow-pwe3-ospf-ms-pw-ext-00.txt

Motivation -
- Need to dynamically route MS-PWs in a single IGP network where routers
have limited routing
Shows example architecture where MS-PW overlays on a single IGP network
Solution adds a couple of TLVs for OSPF representing S-PEs-S-PE adjacencies
and T-PE to S-PE adjacencies

Wang: Need IGP to converge faster
    What is impact on convergence time?

Andrew Dolganow: No intent to add to convergence time. Some of the OSPF
routers are not PE routers. The draft addresses this point.

Wong: What's wrong with BGP - worries about multiprotocol aspects.

Andy Malis: This is not needed. TE using TE tunnels.

Luca Martini: Issues with oscillations. Use OSPF to propagate external
routes - not figure out the best path.

Andrew: Don't try to limit # tunnels. But do get scaling advantages. Not
interAS. May be a simpler approach

Matthew Bocci: Enable you to build link state for the PWs. There is a use
case for MS-PWs in access and metro networks, which can be flat. May not be
at edge. We need solution that does not need EGP. Because LS - can TE the
MS-PWs through the existing tunnels. There is also a requirement to specify
a strict route for a MS-PW. This gives enough topology to do that.

Dimmitri Papadimitriou: Draft makes clear draft it is protection of PWs
with no impact on the protection of area. IGP makes sense for intraAS case.

Lou Berger: Highlights the point that we are creating new TE switching
layer - should do this based on TE semantics. Look at 2370bis from
OSPF WG. Don't redo this work.

To be discussed in OSPF list

Requirements for P2MP Pseudowires - Frederic Jounay
([email-masked])
----------------------------------------------------------------------------

http://www.ietf.org/internet-drafts/draft-jounay-pwe3-p2mp-pw-requirements-00.txt

Presents some motivation for the P2MP PW.
Needs to collect the requirements for P2MP PW and identify the use cases.

TDM based use case:
- adaptive clock distribution and recovery e.g mobile backhauling. Pros are
provisioning, bandwidth savings

ATM- based use case
- Broadcast TV over ATM. e.g. wholesale services over IP/MPLS network

Ethernet based use case

Framework includes:
P2MP SS-PW, which is a PW over a P2MP LSP.
P2MP MS-PW over P2P LSP (downstream label assignment), and PW segment over
P2MP LSP (upstream label assignment)

Further steps:
Is there interest in this work?
Comments on draft-00
Other use cases, additional requirements for transfer plane, signalling,
security, etc
There are a couple of related solutions drafts.
Charter review?

Danny McPherson: Yes, we need a charter review. There seems to be general
interest in this.
Yakov Rekhter: There is work to use P2MP LSPs. This has to be limited to
that.

Gile Heron: In the SS case, we are not using P2MP LSPs. There is a solution
that you can use this with VPLS.

Kireeti Kompella: Is there a requirement that this is bidirectional?
Fred: P2MP PW is unidirectional
Kireeti Kompella: Can we use BGP to signal P2MP PW?
Yaakov Stein: how important is this that it requires a recharter? Is this
the best way of doing sync, given TICTOC?
Fred: This is one way to transfer the adaptive clock.
Luca Martini: Good to start the discussion. Can use P2P PWs connected to
VSIs in real networks to build P2MP

Danny McPherson: Is there interest in adding this to the charter?  A few
hands go up.
Any opposed? one or two

IEEE 1588v2 and PWE3 - Ron Cohen ([email-masked])
------------------------------------------------------------

Presents and overview of the status of 1588.
v2 is nearly ready.
Timing protocol aligns slaves to master time.
Time stamp at master and slave.
There is also a peer delay measurement which is optional
Introduces end to end transparent clocks.
Can use peer-to-peer transparent clocks
Topology changes to not affect slave clocks
Shows an application of 1588 for CES.
Summarises differences between PWE3 and TICTOC service
There are some commonalities and some differences

Yaakov Stein - 1588 for CES: there is no connection between PWE3 and 1588
here. Do you have an example of running timing over PWE3?
Ron - don't disagree
Kireeti Kompella - I am clueless about this, but is it possible to use P2MP
in this? Is the messaging from server to clients the same?

MEETING CLOSES

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