[PWE3] PWE3 at IETF66

PWE3 at IETF66   TUESDAY, July 11, 2006 - 1740-1950 

chairs: Danny McPherson, Stewart Bryant 
minutes taken by Y(J)S

Agenda bashing - Danny
----------------------

WG Status and Update - Stewart
------------------------------
8 RFCs: 3916 (PWE reqs), 3985 (arch), 4197 (TDM reqs), 4385 (cw), 
        4446 (IANA), 4447 (control), 4448 (Ethernet), 4553 (SAToP)
5 in RFC editor's queue : ATM (waiting for announce), FCS (blocked by
l2tpext-ethernet), 
                          frag, frame relay, hdlc
TDMoIP, CESoPSN, SONET and cell transport sent to IESG just before
meeting
This completes the phase I set of documents.

MIBs - need serious review! are we ready for LC ?  
ATM and SAToP MIBs expired (need?), 
we need a volunteer to write a frame relay PW MIB

MS-PW reqs - ready for LC
are any of the others ready for LC?
wildcard and VCCV need updates.

for reference: L2TPv3 has 2 RFCs (4349 - hdlc, 4454 - atm) 
   1 in RFC editor queue (fr), 1 at IESG (Ethernet)

We crucially need to address congestion (will discuss later)

VCCV Extension for Ethernet OAM - Dinesh Mohan 
----------------------------------------------
propose a new VCCV payload type based on Ethernet OAM
joint work with large group of vendors and carriers

background: Ethernet can be the PSN for PW to run over (see e.g. TRILL,
GELS)
            also PWs over Ethernet basically the same as over MPLS
            MS-PWs can extend across MPLS PSN and Ethernet PSN segments

Need different types of OAM for full solution - end-to-end OAM, AC OAM,
VCCV 
OAM
VCCV provides platform for PW layer OAM
 presently 3 ways to distinguish VCCV packet from user packet (CW,
router alert, TTL=1)
 and 3 OAM PDU types (ICMP, LSP-ping, BFD)

We can define a new PDU type based on Ethernet OAM (Y.1731, 802.1ag)
rationale: strong functionality and extensively specified (would need to
augment BFD)
           already implemented if Ethernet PSN
           8 hierarchical levels defined - needed for MS-PW

Need to define a new CV type in VCCV draft 
  and reference existing work in ITU/IEEE
May need an appendix to answer questions brought up on list

Can address implications for MS-PWs in MS-PW drafts

Yaakov - need code point for PWACH (right now only IPv4 and IPv6)
Sasha - slide 5 shows BFD packet control packet and not BFD echo packet
        note: 2 redundant MAC addresses
        also sent several questions to list, would like answers 

Luca -  4447 has status messaging - why do we need anything more?
Dinesh - MPLS is not necessarily the tunnel here, Ethernet PSN
Stewart - in that case out of scope
Dinesh - Y.1731 has higher functionality than BFD

Luca - don't need OAM here at all - PWE control status is sufficient

Don O - a major advantage is that it reduces number of redundant OAM
flows, 
         better for SPs, also this is not restricted to Eth PSNs
Stewart - proponents need to clarify advantages on list before
continuing
         do we need anything in VCCV draft other than IANA codepoints?
Dinesh - no, everything else OK
Stewart - so needn't hold up VCCV draft, follow up to list

VCCV Extensions for Segmented Pseudo-Wire - Mustapha Aissaoui
-------------------------------------------------------------
draft describes a method for extension of VCCV to MS-PW
with both ping and trace of PW FEC
anu such method should be backward compatible with VCCV in SS-PW (CW,
etc)
just add new VCCV subTLV and new VCCV CW with TTL field

operation principles:
T-PE and S-PE negotiate use of CW for VCCV end-to-end
S-PE does not pass other CC types, so need CW!

data plane:
PW FEC ping
  T-PE sends VCCV packet with high TTL 
  S-PE does outer label pop, TTL--
  new outer label push
  no requirement for S-PE to look at CW
  egress T-PE inspects and responds to the VCCV packet

PW FEC trace
  T-PE sends VCCV packet with determined TTL
  S-PE does outer label pop
  TTL--
  if TTL=0 S-PE checks if VCCV and inspects / responds

design considerations
  each S-PE needs to TTL-- 
  problem: if LSR between S-PE and T-PE manipulates TTL VCCV 
           then may go to wrong S-PE

authors request feedback

Sasha - why can't router alert work?
Mustapha - no real problem (although TTL obviously can't work), 
           but we decided to limit combinations
Don O - Y.1731 can already handle MS-PWs, and needn't define new
mechanism 
Mustapha - here we don't assume the service is Ethernet
Dinesh - concerns with use of TTL, e.g. what about point-to-multipoint?

Mustapha - PWE hasn't dealt with point-to-multipoint PWs!
Danny - point-to-multipoint implicitly out of charter
Dinesh - should consider and be pragmatic when going forward

Mustapha - valid concern but shouldn't stop all work because of possible
future directions
           in any case the important point is compatibility with SS-PW
VCCV
Dinesh - haven't seen framework for management expectations - what about
>2 OAM layers ?
         Y.1731 method is less restrictive
Mustapha - yes, this method is restricted to cases presently considered
by PWE
Danny - at some point you will want this to become a WG item?
Mustapha - want to work with coauthors, will take to list

VCCV-BFD Issues - Luca 
----------------------
(Tom Nadeau's flight was cancelled and couldn't make it back to
Montreal)
control protocol has status messages and VCCV has a conflicting
mechanism
 what if they don't agree (e.g. inband message comes faster)?

text on VCCV capability advertisement is contradictory, 
suggest to change to read
  if (LDP DOWN and BFD is UP) or (LDP UP and BFD DOWN) then DOWN
  only BOTH UP is UP

Mustapha - addressed in OAM message mapping draft
           there are several faults, could be AC up, etc.
Peter B - wording in message mapping draft eliminates this problem
Luca - this was just an example - there is a general logic problem that
needs to be solved

propose new text for VCCV draft saying logically OR the BFD and LDP
status messages

Monique - need to make consistent with message mapping draft
Stewart - OAM message mapping won't block 
          (incidentally - needs to divide references into normative and
informative)

another issue is the BFD mode presently using UDP/IP encapsulation
this requires redundant lookupsm is confusing and could be used for
attacks

propose removing UDP/IP from BFD mode 

Yaakov - additional mode or instead of present mode?
Luca - instead of present mode

Sasha - this refers to generic BFD draft - what about echo packet (not
defined there) ?
        need additional channel types since UDP ports are needed !
George - this was meant to run in demand mode, and not echo mode

Rahul - there is a draft for BFD in MPLS, this includes PWs as well
        need to make all these drafts consistent
        also, OAM protocols should take into account 
         that data plane may be corrupted and misrouting
Luca - there is a discriminator, and chance of match minimal
Rahul - LSP ping uses UDP/IP also - why is BFD different?
Mustapha - no consensus here - need existing behavior, so let's have 2
modes
Peter B - echo mode is explicitly excluded here
          also inner IP addresses are not used for IP addressing in BFD
          proponents should be sure they understand how the OAM works

PW Redundancy - Praveen Muley
-----------------------------
How many have seen the draft? (Sorry was sent in late) - not many have
read!

set of redundant PWs configured between PE nodes for SS-PWs 
 or between T-PE nodes for MS-PWs 

status bit needed in PWE control protocol to indicate active or standby 
 for each PW in redundancy set

draft describes scenarios where PW redundancy is needed

tunnel protection mechanisms is not sufficient 
 when multihoming a CE to multiple PEs
 or there is failure of S-PE in segmented pseudo-wire 

deal with end-to-end protection of pseudo-wire
switchover to backup PW is at T-PE/PE only
(no fast restoration at S-PE)

T-PE/PE signal multiple pseudo-wires and indicates the choice of PW

since PW is bi-directional, need synchronization of status at both
end-points 

PE/T-PE needs to indicate preferred PW path

solution - activity status bit defined to indicate active/standby  
 (set means standby)

synchronization of status on ends helps in selecting active PW

shows diagrams of scenarios (multihoming CE with SS-PWs and MS-PWs)

request feedback from WG, and would like to become WG item

Peter B - what AC dual-homing protocol do you intend to use?
Praveen - not important
Peter B - ITU defining APS for Ethernet at service layer, isn't this
enough?
Praveen - carriers have asked for separation of switch directions
Ben NJ - do we need mesh of PWs across core for this to work?
Praveen - not really needed, but carriers sometimes want
Ben NJ - but this necessitates twice as much state without more
protection
Vach K - we had requests from SPs NOT to move from PE to PE unless
needed
         (less network disturbance) so shouldn't have "cross" PWs
Ali S - dual homing protocol may not work between CE and PE
        need decision to be made by PE too, so APS model doesn't work
        avoid problem completely by anchoring at egress PE
Praveen - still would want differentiation between active and standby
state
Ali S - why? two PWs, either can be used
Mustapha - Praveen is assuming APS on one side
Danny - take to list
Ronen S - do you want BW conservation (not waste resources for both PWs)
          OSPF external protection solves this problem

PW Protection - Ping Pan 
------------------------
third revision of draft - we initially thought it was a simple problem
since last IETF learned that protection may mean different things - 
  end-to-end, congestion relief, multihoming, or SS-PW/MS-PW protection 
  someone should write a use-case document first

key changes in version 3 - 
  preference TLV and protection TLV
  removed 1:N protection option (useless)
  more text on processing

PW path protection
  need a reference ID otherwise S-PE doesn't know how to forward
  identify working and protection PWs (CAC-desired and fate-sharing)

congestion control 
  set preference level and control pre-emption

other issues 
  multihomed PW protection (just heard discussion in previous talk)
 PW segment protection

Next steps - PW pre-emption and path protection
             need to iron out other issues
             work out use-cases

can make this a WG document?

Danny - this is now in the new charter
        can we unite these two drafts?

Generic PWs - Danny
-------------------
We didn't add this to the new charter, due to not being ready
but we want now to add a new charter item

What do we want to do?

want to carry MPLS, IPv4, IPv6, compressed header, IS-IS, another PW,
etc 
 IN A SINGLE PW

concern from MPLS WG on the MPLS over MPLS issue

topology example - connect two PEs interchanging IP, IS-IS, MPLS and OAM
over PW

Goals - decouple control protocol from SP signaling (don't want to
interop LDP!)
        distinguish MPLS in PW from "classical MPLS" (not allowed to
have two S=1 packets)
        are there implications of CW and ECMP ?
        MPLS relies on IP signaling - can't ignore bootstraping
functions

We tried not to define a solution yet, but ...
        CW required? 
        SS-PW and MS-PW? 
        L2VPN requirements (IPLS)

extraneous considerations 
  who else is working on this ITU, MPLS forum UNI, L2TPv3 (already have
IP PW!), L2VPN ?

payload considerations
  self-describing payload
  registry for ID (PPP, Ethertype, new)

can we accept as WG item?
need applicability/requirements ID, then arch/framework

Shahram D - do we need a PID?
Danny - yes
Luca - let's charter MPLS v2 ! this is not a PW, it is a new MPLS
Danny - we have engaged George in order to avoid problems here
Stewart - some of this work has been requested, e.g. IP PW for IPLS
Sasha - IP PW type described in 4447
Luca - yes, we already have an IP PW
Don O - this is not MPLS v2. If not done here it will be done at ITU, as
SPs need.
Yakov R - If somewhere else - is this T-MPLS ?
          We need a clearly written requirements statement.
George - enough to say what SPs can not do today with the present
infrastructure
Yakov - just because someone wants this, doesn't mean IETF needs to do
it
Don O - not only T-MPLS, but Y.1415 is relevant
Kireeti K - "GMPLS only" - GMPLS includes packet LSPs
            need to consider "MPLS service", i.e. give LSP to end
customer
Stewart - need a group to work on requirements document - volunteers
contact Danny

Congestion Issues - Stewart 
---------------------------
When PWE was formed it was put in the transport area because of
congestion worries

can't claim that PWs would always run over TE networks 
 and there are counterexamples today (e.g. TDM PWs over Internet)
 "anything that we define - someone will run over the public Internet" 

charter states - end-user deployed PW needs congestion avoidance
mechanisms

requirements RFC completely ignores congestion

TDM requirements RFC does discuss congestion, 
  says need to detect and shutdown PW, and mentions instability of
bringing up and down

RFC 3985 (architecure) has text (shown in slide!) but doesn't give
mechanism
other than mentioning TCP-friendly rate control

most encap drafts only point to 3985!

TDM drafts introduce special considerations, since can't do very much

ATM draft had a discuss focused on absence of congestion
 mechanism
  resolved by chairs promising to work on this

only real attempt at addressing PW congestion has been
draft-rosen-pwe3-congestion
draft died but recently resurrected
basic idea - when traffic starts getting lost then drop rate
 and when gets through rate should climb

it has been said that we do not need this mechanism

 one argument is - no since other than TDM the content is actually IP
payload 
 another argument - congestion impossible on our links (implausible)

existing endsystem solutions (e.g. TCP) ruled out

need router implementation - no acks, no complex state machine, limit
HW/SW interactions

how detect congestion? 
 sequence numbers - but many implementations don't use CWs (due to high
rates)
 periodic VCCV packets
 control plane
 tunnel level method

how do we respond to loss - AIMD (like TCP) or softer rate control ? 
 TCP friendly slow response but maybe better
 TDM PWs - can we adjust rates? (e.g. select channels)

Proposal
 adopt draft-rosen as WG draft
  need framework as to the meaning of congestion in PW context
 form a design team with PWE and transport experts

David B with T11 liaison hat on - fiber channel PW people brought
propsal to T11
 and T11 returned to IETF
 some work with TFRC has been done
Bob B - first need to distinguish flows in PW, some using TCP some not
        2nd, TSV WG working on edge-to-edge congestion control with
infrequent messages
Danny - need happy medium between large effort and something that will
be implemented
Yakov R - change order - 1st design team and then consider draft
Ping P - congestion has 2 parts - detection and retransmisson
         if need TCP then why not TCP/IP PSN ?
Stewart - not fast enough
Vach - can we keep up the charade until we have an RFC number for ATM
draft?
George - PW mechanisms can not push back on source - and buffering
dangerous
             need system view
Kireeti K - need to protect Internet from PWs, but also the other way
around

ITU T-MPLS Liaison Update - Stewart
-----------------------------------
ITU SG15/12 sent a liaison to PWE3, MPLS and MFA regarding G.8110.1
(T-MPLS)

IETF representatives attended the SG15/12 meeting in Ottawa (Stewart,
Loa, Ross)

ITU accepted essentially all the corrections PWE asked for

response to MPLS WG will be discussed at MPLS WG session

ITU sent IETF an updated copy of G.8110.1
and requested that we respond with technical comments before August 1st
(!)

Please repond if important to you

Loa - let's coordinate a unified IETF response

Fibre Channel over MPLS - Ronen Solomon 
---------------------------------------
work done with KDDI - deployed and running

version 1 of the draft discusses congestion management

this presentation will also cover
 interworking between TFRC and LAPB
 rate shaping 
 selective retransmission  
 FC credit management 

native service processing termination for Fibre Channel is handled by
T11
PW termination is handled by PWE3 in IETF

FCoMPLS may be used in controlled and non-controlled environment
(i.e. CIR and EIR specified)

rate adaptation uses TFRC rate equation

selective retransmission (SR-LAPB) mechanism (already used for FC over
ATM)
this indicates congestion conditions to the TFRC mechanism for
throughput calculation

TFRC/LAPB interworking 
 rate shaping via TFRC to avoid  traffic bursts
 adapt to available BW 
 selective retransmission via LAPB
 FC credit manager (NSP function)

encap
 L2 hdr 
 PW hdr (outer + inner label + PW) 
 FC frame (LAPB hdr + FC frame + CRC)

rate shaping 
 RFC 3448 + adaptive rate shaper 
 assures minimum bandwidth guarantee (CIR)
 interworks with LAPB
 works in conjunction with SR 
 monitors SR frame loss 
 frame loss monitoring 

selective retransmission
 reuse mechanism described in T.11 FCoATM 
 reliable (sequencing + acks)
 retransmissions
 4 byte overhead 
 fixed window size   

need new PW type for fiber channel port mode

Wrap up - Danny
---------------

finished on time !

good idea to have Yaakov take minutes 
 when he doesn't get to mike everything goes faster