Subject: Minutes from IETF 56 PWE3

From: Danny McPherson <[email-masked]>
Date: Sun, 13 Apr 2003 11:35:59 -0600

Any final comments, I need to submit these tomorrow (4/14).

-danny

PWE3 @IETF56 -- San Francisco, CA  March 19, 2003

Minutes Recorded by Vach Kompella

No agenda bashing allowed - lack of time

Progress (Danny)
 - security considerations needs more work
 - need feedback from security wg
 - terminology, and refs need to be cleaned up

 3 week last call on new rev of pwe3 requirements

Architecture (Stewart)

 - all feedback incorporated except
  - all syntax/terminology is more ietf-oriented
  - ref models retained from the reqmts draft

 - generic control word
  - need more flag bits
  - specify ttl = 2
  - use pid to make a first level determination that the packet is NOT ip
   - propose pid=0 for pwe3
   - reject control words that use 4 for the first nibble
   - itu-based control word violate this (stewart)
   - dave allan: isn't this iana issue
   - yaakov s: at least 2 in violation of the basic limitation != 0, 4, 6
   - chris l: why assume that it is always ip?
   - mark t: this is for pw that requires control, or requires all pws to implement cw
   - mark t: can't accidentally use 4 or 6
   - stewart b: can't squander the bits, so can't limit to not using 0, 4, 6
   - mustafa: don't use that position (1st nibble) for anything
   - andy m: mpls implied that ipv4/ipv6 carried by mpls
      need lot more discussion
   - andy m: make it self-describing, not this half-baked approach
   - luca m: don't call pid because it is not a protocol id, but maybe a class
   - find out packet is ip by computing checksum, other methods (general groans from audience)
   - george swallow: for better or worse, mpls decided not to have protocol
       - need some way to find what is in there, to identify flows
       - various hacks out there
   - eric r: original encap did have pid but it was deemed unnecessary
   - mark t: need to have defined value that is pw
   - vach k: this is really version, so can use 1, 2, 3, 5
   - dave mcdysan: 5 may still be in use

 - congestion
   - pwe3 may be used by end-user and so it will be
   - text from rtp wg
   - if known to carry tcp, then its own backoff mech kicks in so no need for extra work
   - if not, pw must provide a loss-sensitive backoff mech
     - done by nsp, and out of scope
     - long term avg for tcp throughput

 - issues
   - do we need cong ctrl
   - is perfect emulation more important than congestion mgmt
   - what to do if we detect congestion?
   - how to identify a traffic class to do measurements on?
   - run over dccp?
   - congestion mech like red and yellow cards - backoff or drop 
   - need more description on the pwe3 congestion approach?

   - rahul a: if qos sla is broken, what to do?  We haven't reached that point because we don't know what to do yet
   - rahul a: some measuring mechanism is required [Stewart Agrees]
   - steve casner: perfect emulation means that when congestion occurs, the pw is probably breaking anyway,
     - what about other protocols over ip?  who is responsible for better behavior, pw mgmt or just regular internet behavior
       - sb: whatever the internet does
   - mustafa: how to make some AS's take action, across admin boundary.  can't take unilateral action to curb traffic
      - how to provide enough info so that the feeder of the congestion is notified of what is causing congestion
      - need fault notification
   - mark t: hope i'm not hearing that p routers have to worry about congestion

OAM reqmts (Tom Nadeau)
   - promised not to bore us
   - sp reqmts
   - common set of oam reqmts for mpls networks
   - read the draft

VCCV (Tom Nadeau)
   - mech for pwe3 using inband diagnostic
   - two approaches
     - use a bit in the flags (although none are left)
     - use a pid
     - mustafa: can't use existing tools to test PWs.  use existing tools - there are already existing approaches.
       - tom: using those mechs you can't tell whether a p router is broken
       - mustafa: if you have native oam, then you can determine pw connectivity
          - lsp-ping for tunnel, and native oam for pw
          - not needed
          - but what fixes the problem with vc lsp and tunnel connectivity
   - dave allan: use a bit to identify the packet is an inband test packet
       - the reply is back over the vc
       - tom: yes, the pw is bi-di
       - what identifies what comes in the test packet? read the draft
   - shahram: can't use lsp-ping? because of ecmp?
       - tom: not necessarily, want to follow the disposition path of the egress, so we want the packet to be encapped correctly
       - george: you can't just ping the vc lsp, you need to identify the packet as a test packet
   - george swallow: (off-mike) something about informal survey of ecmp hashing methods - if detected to be ip, then fish in packet header , etc.
   - yaakov s: pws are defined as uni-directional
   - george s: always send the reply in the control plane
   - single-sided downstream unsolicited - incorrect in draft
   - still need to find a way to identify the test nature of a packet

   - take to wg for discussion

Mesg mapping (Tom Nadeau)
    - based on a customer oam reqmt

    - translation of failures in lsp-ping or vccv to atm oam or other l2 oam messages

    - what to do about ethernet?

    - mustafa: mapping of state: need to check several things
          - cv is pro-active
          - but need defect indication (e.g., mpls tunnel failure needs to be used to generate ais type messages)
          - look into the proper oam and mapping of defects, rather than looking at it as a mapping of messages (which sounds like interworking of the native and mpls oam)
          - reactive mechanisms need to be addressed
          - tom n: this is not the be-all end-all, look at all the tools to solve the problems, this is only part of the solution
    - dave a: use of withdrawal of label as failure manifestation - so need to address in data plane

ATM mib (Tom Nadeau)
    - adds to the basic structure of the mibs for pwe3

TDM (Tim Frost filling in for tom johnson)
    - why another?
    - 2 years of deadlock, and no compromises have worked
    - tom put in charge of dt to address this
    - draft-johnson
      - same control word structure more or less as sonet draft
      - unstructured em mode: pure bitstream, normal segmentation
      - (see draft for details)
      - broad agreement on this mode from dt (debate on default size of payload)

      - structured em (NxDS0 w/ CAS)
      - similar to atm cem doc

      - structured em (NxDS0 w/o CAS)
      - based on tdm multiframe format

      - discussion on how to choose the arbitrary payload length
      - need feedback from list as to whether this draft breaks the deadlock
      - yaakov: unstruct mode - everyone agrees
                struct mode: disagreement because the optional mandatory mode is not well-defined
      - tim: why pick a size that fits the tdm network when we are going into a pkt network that can have
      - alex: how many advantages of the other drafts are preserved?
      - tim: succeeds in preserving structure, uses the same cas structure (atm interworking is more difficult)
      - alex: why not preserve draft-anavi advantage (atm interworking)
      - tim: because it is not possible to solve both problems
      - alex: but draft-anavi is for unstruct mode
      - danny: if you have a draft that preserves all advantages then we'd be happy, but we need a compromise
      - danny: bring it to the mailing list
      - steve (axerra): big picture - lot of activity suggesting solutions or identifying problems - what changes are in the offing?
      - tim: in the area of how to segment it into different payload sizes, with the tradeoff into efficiency or latency
      - steve: what about areas like lost packets?
      - tim: needs to be addressed, but probably minor (in terms of controversy)
      - shahram: ask list which is more important. constant delay from pe to pe regardless of the bit rate, or ease of atm interworking

TDM reqmts (Max Riegel)
    - init draft covered t1, e1, t3, e3
    - needed to cover sdh/sonet
    - rest from the slides
    - revised edition out beginning of may, continue discussion on list

TDMOIP-LE (Yaakov Stein)
    - loop emulation for congestion control
    - form id does not conflict with pid
    - aal2 is variable bit rate so allows more nsp processing (e.g., vad, compression, etc.)
    - tcp is 1st class citizen, and tdm is dropped with congestion (which is contrary to service provider needs)
    - if pw traffic is small, and not all of it is tdm.  so for statistical peak situation by dropping packets and conceal with nsp techniques
    - to deal with congestion avoidance
       - we must have vbr mode
       - cw must have length field
       - form id is needed (since we can't change modes in control plane)

TDM Structured Em (Sasha - who subbed for him?)
   - mostly stuff right from the slides
   - main concept: nsp function allows for less perfect structure
   - see convergence on tdm in the offing

   - Why there has been difficulty in obtaining consensus for TDM work, and how to resolve it?

   - Good news -
     - consensus on emulation of unstructured TDM (E1,T1,E3,T3) is close
   - Bad news
     - situation with structured tDM, because different people mean different things
   - clear WG position on scope, reqts and arch lacking for structured TDM.

   - Tried to clarify what structured TDM means and why we care about it.
   - Bandwidth saving on psn by skipping unused channels
     - efficiency
     - resilience of attachment circuit and specific applications to packet loss
     - application-specific BW mgmt

   - Piece of wire vs. Distributed DXC approaches.

   - Conclusion - optimistic for consensus on different approaches.

MPLS FORUM liaison (Andy Malis)

   - current draft for tdm is ready
   - please read and comment

PWE3 control and maintenance changes (Luca)
   - changes include
    - refs
    - single sided mode
    - atm modes
    - numeric allocations to separate iana draft

    atm-encap
    - n-to-1 cell mode default
    - need some defs in 1-to-1 mode
    - may conflict with the arch doc

    ethernet-encap
    - tagged option needs reworking: move to nsp function
    - resolve and move to wg last call

    danny: need to resolve other docs before ethernet encap moves forward even though it is ready

    - rahul a: don't understand need to change. the tagged mode supports tagged mode and the spec should be left unchanged.   
    - rahul a: there are existing implementations and some deployment around the tagged mode.
    - luca m: tagged mode is needed to overcome limitations of ip routers
    - ali s: both modes are useful
    - luca m: send comments to mailing list

AAL1 transport (Shahram)
    - does not introduce new protocol
    - suggest move to informational wg
    - andy m: third suggestion - don't use pdu mode
       - also, l&r bits handling is not just informational, adds protocol changes so draft can't be info
    - yaakov s: support the draft, need atm encap draft changes

L2TPV3 (Mark Townsley)
    - draft is in hands of iesg
    - companion drafts are in last call
    - will post to the list on the status

David Allan
    - y1711 and lsp-ping are complementary
    - for pwe3: easy to do oam interworking with y1711
    - with oam in dp, will prevent overloading control plane and label removal
    - danny: send points to mailing list

Danny: work on documents between meetings, and not just near the IETFs

---

From: Alik Shimelmits <[email-masked]>
Date: Mon, 14 Apr 2003 18:52:50 +0200

...snipped

>   - current draft for tdm is ready
- the agreement name (and actual content) is "tdm emulation over MPLS using
AAL1"
>   - please read and comment

Alik