Subject: [PWE3] Q12/15 Liaison

From: Stewart Bryant <[email-masked]>
Date: Tue, 30 May 2006 16:41:42 +0100

Based on review by various members of the PWE3 WG
I propose the following text as the body of the response
to the liaison from Q12/15.

Do I have consensus from the PWE3 WG?

I propose to send this out on Friday 2nd June
with any corrections / amendments received by then.

Regards

Stewart

===========================

You are already in receipt of comments from the IETF MPLS-WG
with which we concur.

This comments refer to G.8110/Y.1370.1 Appendix 1:
Functional Model for describing PWE3 and MPLS Network
Interworking

G.8110 states:
"The IETF PWE3 work group has developed an MPLS transport concept,
know as pseudowires."

Later G.8110 states:
" The PSN can be implemented by utilizing a MPLS label switched
network."

PWE3 has developed methods of transporting services over many
different PSNs, one of which is MPLS.

G.8110 states:
"PWE3 is intended to provide only the minimum necessary
functionality to emulate a wire with the required degree
of faithfulness for the given service definition."

We think that to put this in proper context you
should note that in our view an applicability statement
MUST always be provided to clearly describe the extent
of the emulation, and that in some cases more than one
emulation method may be needed.

G.8110 states:
"A four octet Control Word is added to the MPLS payload field for
some encapsulations."

The CW is defined for all payload types. Use is optional
for HDLC/PPP and Ethernet, but is REQUIRED in all other cases.

G.8110 states:
"these processes are called "Native Signal Processing (NSP)"

NSP stands for Native Service Processing

G.8110 states:
"The NSP function process the Control Word."

The NSP does handle the flags (when there are flags defined).
However the PW handles the sequencing, FRG, etc.

G.8110 states:
"IETF has defined pseudowire encapsulations for Ethernet, Frame
Relay, ATM, PPP, PDH, and SDH."

The PPP emulation also emulates HDLC.

G.8110 states:
"The Forwarder function is called an Interworking Function
(IWF)"

It is not clear that IWF and forwarder are identical in scope
and purpose.

G.8110 states:
In Figure 9 Pseudowire Model G.8110 shows the PW as a trail
with a T-MPLS trail termination function. This termination
is defined here as injecting Y.1710 OAM.

The IETF PWE3 specifications use VCCV as the PW OAM.

G.8110 states:
"Pseudowires can be switched by a Subnetwork Connection
(SNC).  This creates in PWE3 terminology Multi-Segment
Pseudowires (MS-PW) as defined in the bibliography
reference [1]."

Bibliography reference [1] is RFC 3985, which was
published prior to our work on MS-PWs. The correct
reference is reference [2].

G.8110 states:
"When the MPLS server layer is an SDH layer network,
an SDH path layer may be used instead of the
pseudowire PSN transport tunnel. This approach has
been called "dry martini" as defined in the
bibliography reference [2]."

The correct reference is reference [3]. We must however
caution you that this work has not been adopted as an
IETF PWE3 working group item. The draft was an
individual submission which has now expired under the
IETF policy of expiring such drafts after six months.

Within the scope materiel you state:

"a T-MPLS network will not peer directly with an
IP/MPLS network".

The data plane behavior of the one currently supported
adaptation ("EVC") is intended to be exactly the
same as an Ethernet pseudowire (Y.1415 is based
on what became rfc4448). Therefore the statement
is not true.  They will interoperate at the level
of the pseudowire, e.g. a multi-segment PW could
span adjacent "full" MPLS and "subset" T-MPLS
networks connected by an S-PE, regardless of
what else T-MPLS does not do. We believe this
would be called a "common adaptation layer" in
SG13.  Signaling interworking, if any, is TBD,
but there certainly can be data plane interworking.

G.8110 states:

"From an OAM perspective, pseudowires provide
service-specific status and alarm management".

However PW status signaling and VCCV are
agnostic to the native service type.

PWE3 members who are also SG13 experts make the following
additional observations:

G.8110 states:
"ITU SG 13 has developed a series of recommendations for MPLS /
Client Network Interworking  for Ethernet (Y.1415), ATM
(Cell Mode - Y.1411), ATM (Frame Mode - Y.1412), and TDM (Y.1413).
These recommendations are similar in concept to IETF PWE3."

You omit X.86 (frame relay PW), which, although developed by
SG17, it is now in SG13.

These recommendations are are identical in concept, and
to the best of the ability of those concerned are identical
in detail.

We note that in Figure 8 you pick the semi-formal diagram
from Y.1415 when the same Recommendation has a G.805
diagram as well. We recommend that you show Figure 6-2
of Y.1415 in its place.

G.8110 states:
"Pseudowires can be used as a packet transport mechanism
for emulating LAN Services over a Transport MPLS network.
Like in Virtual Private LAN Service (VPLS) a full mesh of
T-MPLS trails (PW trails) is used to interconnect
split-horizon ETH Flow Domains."

We suggest that you reference Appendix I of Y.1415.

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 30 May 2006 12:00:02 -0400

Stewart,

The statement looks really good.  I have a two small comments on your 

>emulation method may be needed.

I disagree with the quoted sentence - in many cases, PWE3 can provide 
more than just the minimum necessary functionality.  I would suggest 
that G.8110 replace "PWE3 is intended to provide only" with "PWE3 is 
intended to provide at least".

>The PPP emulation also emulates HDLC.

We also have an encapsulation for SONET, and AVT working group is 
finishing work on an encapsulation for header-compressed voice samples.

Cheers,
Andy

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 30 May 2006 17:11:47 +0100

Andy

> intended to provide at least".

I agonised over that for a while, but unfortunately they are
quoting directly from RFC3985! That is why I suggested that
they added the context material rather than modifiying their
text.

> finishing work on an encapsulation for header-compressed voice samples.

I will add that.

- Stewart

---

From: Scott W Brim <[email-masked]>
Date: Tue, 30 May 2006 12:26:08 -0400

> This comments refer to G.8110/Y.1370.1 Appendix 1:

I believe that here and everywhere you mean G.8110.1, right?  G.8110 is
done and gone :-).

> but there certainly can be data plane interworking.

First, it has been suggested that my understanding of "peer" is not
the same as SG15's.  Perhaps that should be clarified.  Anyone?
However, if we keep this, let's clean it up a little:

  The data plane behavior of the one currently supported adaptation
  ("EVC") is intended to be that of an Ethernet pseudowire as
  specified in Y.1415 and RFC4448.  Thus it is possible for "IP/MPLS"
  and T-MPLS networks to interoperate at the level of the pseudowire,
  e.g. a multi-segment PW could span adjacent "IP/MPLS" and T-MPLS
  networks connected by an S-PE.

Thanks ... Scott

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 31 May 2006 16:04:32 +0200

Stewart. 

Just a small comment.

You state:

Shouldn't that be

   The NSP does handle the flags (when there are flags defined).
   However the IWF handles the sequencing, FRG, etc.

or

  The NSP does handle the flags (when there are flags defined).
  However the PW-layer processing handles the sequencing, FRG, etc.

?

Also, materiel -> material .

Y(J)S

---

From: Luca Martini <[email-masked]>
Date: Wed, 31 May 2006 11:32:26 -0600

Stewart,
Some minor corrections below.
Thanks.
Luca

> with any corrections / amendments received by then.
........
> for HDLC/PPP and Ethernet, but is REQUIRED in all other cases.
Actually not required for ATM cell mode as well.

> Within the scope materiel you state:
French ?  maybe material ?

> You omit X.86 (frame relay PW), which, although developed by
Isn't X.86 the predecessor to GFP ? ( ethernet in a hdlc frame ? )

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 31 May 2006 14:05:38 -0400

Luca,

>Isn't X.86 the predecessor to GFP ? ( ethernet in a hdlc frame ? )

Indeed.  This should be X.84, not X.86.  Good catch - got by me on my 
prior review.

Cheers,
Andy

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 31 May 2006 21:44:34 +0200

> Isn't X.86 the predecessor to GFP ? ( ethernet in a hdlc frame ? )

Right (X.85 and X.86 are LAPS).
 
Frame relay over MPLS is X.84 .
 
Y(J)S