Subject: Arch draft updated

From: Stewart Bryant <[email-masked]>
Date: Tue, 09 Mar 2004 20:15:01 +0000

As presented at IETF59 and mostly as already presented to the
list as individual items I have updated the PWE3 Architecture
description with the changes described below.

The latest version is at

ftp://ftpeng.cisco.com/stbryant/PRE-draft-ietf-pwe3-arch-07.txt

This is the start of a two week last call on the changes which
I describe below. If these changes are acceptable to the WG I
will submit version 07 to ietf-drafts and give the draft back
to the IESG.

- Stewart

--------

1) Changes to remove the references to IP version number
    and detailed control word text:

a) Removed the PWE3 Payload Type Identifier from Fig 11
    which now looks as follows:

    /=====================\
    H Payload Convergence H--+
    H---------------------H  |       +--------------------------------+
    H       Timing        H--------->|              RTP               |
    H---------------------H  |       +--------------------------------+
    H     Sequencing      H--+------>| Flags, Frag, Len, Seq #, etc   |
    \=====================/  |       +--------------------------------+
    |  PW Demultiplexer   |--------->|           PW Label             |
    +---------------------+  |       +--------------------------------+
    |  PSN Convergence    |--+  +--->| Outer Label or MPLS-in-IP encap|
    +---------------------+     |    +--------------------------------+
    |        PSN          |-----+
    +---------------------+
    |      Data-link      |
    +---------------------+
    |       Physical      |
    +---------------------+

      Figure 11: PWE3 over an MPLS PSN using a control word

b) Deleted the following sentence from 5.4.2

Where the design of the control word would alias an IP
packet, a PWE3 Payload Type Identifier (PWE3 PID) should
be interposed between the PW label and the control word (see 5.4.4).

c) Replaced 5.4.3 with the following and deleted 5.4.4

5.4.3. PW-IP Packet Discrimination

    For MPLS PSNs there is an additional constraint on the PW packet
    format.  In order to facilitate proper functioning of label switched
    routers that detect IP packets based on the initial four bits of the
    packet content, these bits in PW packets must not be the same as an
    IP version number in current use.

    The use of this field for PWs is work in progress.

d) Simplified the IANA consideration section to:

    IANA considerations will be identified in the PWE3 documents that
    define the PWE3 encapsulation, control and management protocols.

--------

2) Editorials

a) Deleted the capitalised keyword text which I believe
    to be the normal convention for and arch/framework
    text

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

b) Changed corresponding main text to lowercase.

c) In Fig 2 changed PW End Service to Access Circuit (outstanding
    edit error from last pass)

--------

3) Reference cleanup

a) Deleted the text:

    For example, this capability is needed in [PPPoL2TP]
    (PPP negotiation has to be split between the two ends of the
    tunnel).  PWE3 may also need this type of control channel to

 From 5.1.2 example 1, which now reads:

    1. A reliable control channel for signaling line events, status
       indications, and, in some exceptional cases, CE-CE events
       that must be translated and sent reliably between PEs.
       PWE3 may need this type of control channel to
       provide faithful emulation of complex data-link protocols.

Reason - PPPoL2TP is a dead reference.

b) Also deleted the reference from the list of references.

c) Brought the references up to the latest revision level

------

4) MIB cleanup following MIB doctor review

    Replaced the MIB text (section 8.2)

------

5) Clean up security section following IESG comments

a) In the security section deleted non-repudiation from the
    following sentence:

IPSec MAY provide authentication, integrity, non-repudiation, and
confidentiality of data transferred between two PEs.

b) In the security section replaced

The access controls that are in place in the PE to
protect and validate its configuration will be sufficient to ensure
that the NSP performs as expected.

with the text:

A PE designed and managed to best current practise
will have controls in place that protect and validate its
configuration and these will be sufficient to ensure that the NSP
behaves as expected.