Subject: Proposed changes to draft-ietf-pwe3-arch-05.txt

From: Stewart Bryant <[email-masked]>
Date: Thu, 25 Sep 2003 14:54:11 +0100

I will post draft-ietf-pwe3-arch-06.txt shortly
but before I do, I would like to test the group
concensus on the following changes made as a result
of AD review.

Stewart

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

Used the following definitions of AC and PWES as suggested by
Ali.

Mostly changed to AC, but in some instances PWES seemed more
appropiate.

Attachment Circuit   The circuit or virtual circuit attaching
(AC)                 a CE to a PE.

PW End Service       The end-service that needs to be carried
(PWES)               over the PW. In case of homogenous ACs,
                      the AC and PWES are identical, but this is
                      not the case for heterogeneous ACs. For
                      example the AC might be an ATM VC but the
                      PWES might be Ethernet carried over EoPW.

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

Added to section 10 - Security

+ The unlimited transformation capability of the NSP may
+ be perceived as a security risk.  In practise the type
+ of operation that the NSP may perform will be limited to
+ those that have been implemented in the data path.
+ 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.

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

Added to section 4.2.2

The NSP function MAY apply any transformation operation
(modification, injection, etc.) on the payloads as they
pass between the physical interface to the CE and the
virtual interface to the forwarder.
+ These transformation operations will of course be limited
+ to those that have been implements in the data path, and
+ which are enabled by the PE configuration.

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

 From section 4.2.1

Deleted the multipoint reference, and given an example
of a forwarder type.

original text

Figure 4b shows a more general forwarding situation where
payloads are extracted from one or more PWEs and directed
to one or more PWs, including, in this instance, a
multipoint PW. In this case both filtering and direction
operations MAY be performed on the payloads.

changed to

Figure 4b shows a more general forwarding situation where
payloads are extracted from one or more ACs and
directed to one or more PWs. In this case filtering,
direction and combination operations MAY be performed on
the payloads.  For example, if the ACs were frame relay, the
forwarder might perform frame relay switching and the PW
instances might be the inter-switch links.

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

In section 5.4.1

+ RTP is normally carried over UDP, however the tunnel
+ protcols that are capable carrying a PW, provide
+ sufficient functionality to carry RTP without an
+ intervening transport layer.  UDP MAY therefore be omitted
+ from the protocol stack.

There is a note at the end of 5.4.2 saying ... As a special
case, if the PW Demultiplexer is an MPLS label....

I have assume that the RTP text therefore implicitly
applies to 5.4.2. Does everyone else read it the same
way, or should I duplicate the UDP exclusion in 5.4.2?

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

The IANA consideration section has been changed to

Sections 5.4.3 and 5.4.4 discuss the issue of aliasing
between PW and IP packets on an MPLS PSN.  This aliasing
is resolved by using two historic IP version numbers
to indicate the that the payload is an MPLS preferred
control word, or a PWE3 PID.  The IP version number
registry needs to be updated to allocate IP version
number 0 (currently reserved) to MPLS preferred
control word, and IP version number 1 (currently
unassigned) to PWE3 PID.

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 25 Sep 2003 16:58:43 +0200

Stewart and all,
Please see a couple of comments/questions inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Thursday, September 25, 2003 3:54 PM
> To: [email-masked]
> Subject: [PWE3] Proposed changes to draft-ietf-pwe3-arch-05.txt
> 
> 
... snipped ...
OK with me as long as it does not explicitly exclude UDP as
a valid demultiplexing layer in conjunction with RTP.
Is not V=1 used by the VCCV packets? 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 25 Sep 2003 10:45:24 -0400

Stewart,
 
>                       PWES might be Ethernet carried over EoPW.

Let put aside the text/editing for a moment. 

My question is what purpose does PWES play in the PWE3 specifications 
(besides the arch document) that is not already being covered by just 
using the AC acronym and definition?

If the answer is none then instead of adding a new acronym and definition, 
why not just clarify in the AC definition something like this
(reusing Ali's and the AC definition of the l2vpn framework draft):

  Attachment Circuit  AC refers to physical or virtual interface between 
         (AC)         CE and PE. An attachment Circuit may be a Frame Relay 
                      DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN,
                      a PPP connection on a physical interface, a PPP
session 
                      from an L2TP tunnel, an MPLS LSP, etc.
                      If these ACs are of the same technology (e.g., both
                      ATM, both Ethernet, both Frame Relay) the PW is said 
                      to provide "homogeneous transport"; otherwise it is
said 
                      to provide "heterogeneous transport".                 

and drops PWES altogether.

(it looks to it is more simpler and avoid any potential 
confusion).

Hamid.

---

From: Scott W Brim <[email-masked]>
Date: Thu, 25 Sep 2003 11:37:53 -0400

>                       PWES might be Ethernet carried over EoPW.

Should this be PW *EDGE* Service?  We have no clue what the END service
is.  This is about what we're delivering at the edge of the MPLS
network.  There are precedents for "edge".

Other small typo nits will be sent p2p.

..swb