Subject: RE: Review of draft-martini-pwe3-MH-PW-requirements-00.txt

From: [email-masked]
Date: Fri, 14 Jan 2005 14:33:10 +0000

Hi Ben,

Many thanks for your editorial and technical comments. I've tried to
address some of them below for the next revision of the draft.

best regards,

Matthew
------------------------------

1) Section 3.2 Figure 2:
The diagram shows 'Native Layer2 Service (AC)", ignoring the fact (IMO)
that terms like Layer 2 aren't particularly meaningful, does this
implicitly exclude non-layer 2 access circuits (e.g. TDM PWs, IP PWs etc.)

What does "Optional PW adaptation function" mean? [I know what an
adaptation function is but I'm not sure what this adaptation function will
be adapting if you see what I mean].

MB> I belive this is adaping a PW between different PSNs, but it is a
confusing to introduce this here, so I've just removed it.

2) In Section 3.2:
It states "PE2 is therefore the PW switching point and will be referred to
as the PW switching provider edge (S-PE)". Under Section 4 (Terminology)
S-PE is defined as a PW Switching Point not a PW switching provider edge
(incidentally PW switching provider edge is never used after Section 3.2).
I assume this is just a editorial mix up?

MB> I fixed the terminology section to, in essence, state that an S-PE
is a PW switching PE, which is a PW switching point.

Also under the definition for PW Switching Point it states "A PW switching
point is never the S-PE and the U-PE for a MH-PW"  I'm not saure what this
means - is it trying to say that a PW switching point can never
simultaneously be a S-PE and a U-PE for a single (same) PW.  If so I think
it needs to be stated a bit more clearly.

MB> Agreed. Fixed.

3) Section 4:
The definition of PW access point address - I can see what this trying to
be achieved with this definition but I don't think the wording is very
clear and will lead to confusion, particularly what does it actually mean
for a 'client layer service access the server layer at the access point
address'?

MB> Luca? This is from your draft.

4) Section 6.1:
Requirement -i starts "Client-server transparency MUST be maintained at
each layer" - This implies that the current 'defaults' for some PWs may
need changing in the MH-PW case - e.g. the current default for Eth PWs is
to strip the FCS, so if I understand correctly for a MH-PW to achieve
requirement -i then the default for Eth MH-PWs must be FCS retention?

MB> I think client-server transparency in this context means that the
PSN is agnostic
to the service being transported, not that the service is necessarily
being transported transparently.

Requirement -i seems to conflict with requirement -iv (MH-PWs MUST use the
same encapsulation modes specified for SH-PWs) - what if the modes
specified for SH-PWs do not allow transparent transfer of the client?  Is
this just a matter of subtle interpretation? - i.e. the mode is the same
for SH-PWs and MH-PWs but the 'options' chosen may be different.

Requirement -i suggests "S-PEs MAY only support PWs of the same type" and
requirement -v "S-PEs MAY change the type or encapsulation mode of a PW." -
IMO allowing S-PEs to stitch a PW of type A onto a PW of type B is likely
to lead to a whole raft of potential interworking issues.

MB> Agreed. S-PEs should not effectively be interworking functions.

Requirement -ii, I'm not sure what this means - what's a SH-PW PSN?  Is it
saying that you could use SH-PWs as a server layer for MH-PWs?

MB> My interpretation of this is a PSN who's PEs only support SH-PWs.
However, I don't think that SH-PWs
would be a server layer for MH-PWs, but rather you would use e.g. an
inter-AS LSP
to tunnel MH PWs across the PSN. The LSP would terminate of the PEs at
the edge of the
PSN that does support MH-PWs. Does this make sense?

5) Section 6.3, 3rd paragrah:
"Ideally the PSN tunnel SHOULD have better QoS or same QoS characteristics
as the carried PW.  However, in certain cases, an operator may need to bind
a PW to a PSN tunnel with nominally lower QoS characteristics.

Is this saying that it is ok for a PW to expect a QoS of X (which a
customer is presumably paying for) and for that PW to be transported over a
PSN tunnel with QoS of Y (where Y<X) - doesn't seem right to me?

MB> In principle, I agree with you. However, I think the text intended
to refer to the fact that an operator may choose to reroute a PW to a
tunnel that doesn't strictly meet the comitted loss/delay
characteristics if connectivity/availability is considered more
important. In any case, I'm not sure that such a discussion fits in a
standardised requirements document. I think the simple statement that
the PSN tunnel should have the same or better QoS characteristics is
adequate.

6) Section 6.3, 6th paragraph:
"If the PW signalling protocol signals PW traffic parameters in-band, it
MUST enable separate traffic parameter values to be specified for the
forward and reverse direction."

Why does this only apply to in-band signalling, should it also apply to out
of band signalling (I think it should).  In fact IMO this is agnostic -
i.e. separate traffic parameter values should be supported for the forward
and reverse directions regardless of the method used to instantiate the
MH-PW)?

MB> Agreed, although I think we are only likely to standardise the
in-band signalling here.

7) Section 6.4, Requirement -iv
"MH-PWs SHOULD be routed across multiple S-PEs without the need to
explicitly specify or configure the S-PEs that a PW uses."

This implies to me that a PW routing instance/database is required
(analagous to the TE routing instance/link state database that can be used
in GMPLS), which also implies that PW nodes must be capable of advertising
their PW capabilities (which ACs, PWs, PSNs, OAM mechanisms, signalling
mechanism etc. they support) and maintaining PW routing adjacencies with
other PW nodes?.  Is this conclusion correct?

MB> I believe so.

8) Section 6.5, requirement -ii
"MH-PWs MAY be set up dynamically end-to-end with a minimal number of OSS
touches."

I assume this really means "MH-PWs MAY be set up dynamically and when they
are set up dynamically they MUST be set up using a minimal number of OSS
touches"?

MB> Agreed

I think it would be worthwhile defining what an OSS touch is in the
terminology section - For example does a single OSS touch mean only one OSS
is used, only one 'box' is touched, only one MIB is touched or what?

MB> I think this probably means "OSS intervention", so the OSS would
only configure the end points, and leave other setup tasks along the
path up to the PW signalling protocol.

9) Section 6.6., requirement -vii
"To avoid complex OAM interworking at the S-PE, the same PW OAM mechanisms
MUST be used on both the ingress and egress sides of an S-PE"

I can see what this is trying to achieve and tend to agree (i.e. let's try
and interwork as little as possible and just use best of breed functional
components) but it somewhat contradicts section 5, use case -iii (PSN
Internetworking - leaving aside that PSN interworking using MH-PWs is
likely IMO to be a something of a nightmare) - i.e. it's OK to use MH-PWs
to interwork between different PWE3 signalling protocols and PSN types but
not different OAM types/mechanisms?  Is section 6.6., requirement -vii
actually achieveable when PSN internetworking is being performed (e.g. is
it possible to use the same OAM mechanism (VCCV?!?) over both LDP and
L2TPv3 PWs)

MB> i have a similar question and would appreciate feedback from the list.
Ideally, I think we want to minimise the amount interworking that goes on
at the S-PE, which means avoiding
using different PW OAM mechanisms either side of an S-PE. I don't think
this imposes restrictions on the PSN OAM on either side.

---

From: David McDysan <[email-masked]>
Date: Wed, 19 Jan 2005 12:10:05 -0500

A few comments in line below on relevant parts. Other parts snipped.

Dave

> Behalf Of [email-masked] (MB)
> Hi Ben,

> "Ideally the PSN tunnel SHOULD have better QoS or same QoS 
> characteristics as the carried PW.  However, in certain 
> cases, an operator may need to bind a PW to a PSN tunnel with 
> nominally lower QoS characteristics.
> 
> Is this saying that it is ok for a PW to expect a QoS of X 
> (which a customer is presumably paying for) and for that PW 
> to be transported over a PSN tunnel with QoS of Y (where Y<X) 
> - doesn't seem right to me?
> 
> to refer to the fact that an operator may choose to reroute a 
> PW to a tunnel that doesn't strictly meet the comitted 
> loss/delay characteristics if connectivity/availability is 
> considered more important. In any case, I'm not sure that 
> such a discussion fits in a standardised requirements 
> document. I think the simple statement that the PSN tunnel 
> should have the same or better QoS characteristics is adequate.
> 

I recommend that we need to specify how the QoS characteristics are
signaled. There needs to be some convention on how to signal the requested
QoS (in addition to traffic parameters (e.g., at least average rate, and
possibly also burst duration and peak rate (see RFC 2215). There are some
drafts on a minimal set of Diffserv PHBs and the associated semantics
occurring in tsvwg and there is also an effort in the ITU-T updating Y.1540
and Y.1541 that may be relevant here.  

> "MH-PWs SHOULD be routed across multiple S-PEs without the 
> need to explicitly specify or configure the S-PEs that a PW uses."
> 
> This implies to me that a PW routing instance/database is 
> required (analagous to the TE routing instance/link state 
> database that can be used in GMPLS), which also implies that 
> PW nodes must be capable of advertising their PW capabilities 
> (which ACs, PWs, PSNs, OAM mechanisms, signalling mechanism 
> etc. they support) and maintaining PW routing adjacencies 
> with other PW nodes?.  Is this conclusion correct?
> 
> MB> I believe so.

Suggest that the document needs to have much more discussion on this issue
in general, with requirements captured in the routing section. For example,
here is some suggested text on the use of IP addresses. if U-PE IP addresses
(or at least prefixes) and S-PE IP reachability is known via IP routing
protocols, then at least the ways to reach set of end and intermediate
points is known. Depending upon the routing protocols used between the
domains (e.g., same IGP area , different IGP areas, IGP-TE, BGP, static
routes (possibly augmented with TE information as being defined in PCE)
additional information to aid  a routing decision may be available. 

> "MH-PWs MAY be set up dynamically end-to-end with a minimal 
> number of OSS touches."
> 
> I assume this really means "MH-PWs MAY be set up dynamically 
> and when they are set up dynamically they MUST be set up 
> using a minimal number of OSS touches"?
> 
> MB> Agreed
> 
> I think it would be worthwhile defining what an OSS touch is 
> in the terminology section - For example does a single OSS 
> touch mean only one OSS is used, only one 'box' is touched, 
> only one MIB is touched or what?
> 
> only configure the end points, and leave other setup tasks 
> along the path up to the PW signalling protocol.

There may be a need for policy regarding the number and capacity of MH-PWs
that an intermediate domain (i.e., S-PE) will support for each authorized
source and destination domain. Would this count as an "OSS touch?"

Suggest that there are several OSS interactions to be specified, including
at least the following: PW provisioning, S-PE policy as described above, AAA
population for identifier/name to IP address resolution, provisioning of NMS
destinations for the configured OAM information.

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 19 Jan 2005 12:24:49 -0600

Dave,
Matthew,

> > 5) Section 6.3, 3rd paragraph:
> > MB> In principle, I agree with you. However, I think the 
> > text intended to refer to the fact that an operator may 
> > choose to reroute a PW to a tunnel that doesn't strictly meet
> > the committed loss/delay characteristics if 
> > connectivity/availability is considered more important. In
> > any case, I'm not sure that such a discussion fits in a 
> > standardised requirements document. I think the simple 
> > statement that the PSN tunnel should have the same or better
> > QoS characteristics is adequate.

Dave> I recommend that we need to specify how the QoS 
> characteristics are signaled. There needs to be some
> convention on how to signal the requested QoS (in addition to
> traffic parameters (e.g., at least average rate, and
> possibly also burst duration and peak rate (see RFC 2215). 
> There are some drafts on a minimal set of Diffserv PHBs and
> the associated semantics occurring in tsvwg and there is also
> an effort in the ITU-T updating Y.1540 and Y.1541 that may be
> relevant here.

If so, then NSIS-based QoS-NSLP signaling for Y.1541 QoS classes could
also be relevant, see
http://ietf.org/internet-drafts/draft-ash-nsis-y1541-qsp-00.txt.

Thanks,
Jerry