[PWE3] Draft

The draft minutes are below.

Our thanks to Yaakov for taking them.

Please send corrections to the chairs.

Thanks

Stewart

------------------------------------------------------------

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

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3

[PWE3] Draft - PWE at IETF66 minutes