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

From: [email-masked]
Date: Tue, 21 Dec 2004 15:08:33 -0000

Colleagues,

I've just read draft-martini-pwe3-MH-PW-requirements-00.txt and have several technical questions/observations, so here goes...

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].

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?

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.

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'?

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?

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.

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?

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?

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)?

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?

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"?

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? 

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)

Ben

-- 
Ben Niven-Jenkins
Networking Specialist, BT Exact

e-mail: [email-masked]
tel: +44(0) 1473 648225

pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, UK

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 21 Dec 2004 18:16:33 +0200

Ben and all,
Please see some comments inline.
I have snipped the parts that I do not comment upon.
Regards,
                                  Sasha Vainshtein
email:                         [email-masked] <mailto:[email-masked]> 
phone:                       +972-3-7569993 (office)
fax:                            +972-3-6487779
mobile:                      +972-52-8674833 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Tuesday, December 21, 2004 5:09 PM
> To: [email-masked]
> Subject: [PWE3] Review of draft-martini-pwe3-MH-PW-requirements-00.txt
> 
> 
> Colleagues,
> 
> I've just read draft-martini-pwe3-MH-PW-requirements-00.txt 
> and have several technical questions/observations, so here goes...
> 
... snipped ...
> 
> 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].
> 
[Sasha] I'd say that the draft requires some clean-up regarding the style
and usage of terms:
- IMO, consistent usage of one set of terms and notions is preferable to
mixing existing PWE3
  terms with ITU-T G.805/G.809 ones. If necessary (and I agree that it would
be beneficial),
  a "translation" could be provided, but it should be localized (e.g., in an
Annex).
  (And, yest,I fully understand that this would be at quite a cost to the
Editors. But
  the current mix comes at a price for the readers:-)
- terms that are used must be defined, preferably once and all in one place
- terms that are NOT USED should be removed from the "Terminology" section
- Different things should be called by different names. E.g., either an
SH-PW and 
  a PW segment are different, or there is no such term as a PW segment (I
assume
  that SH-PWs exist, since that is what this WG has been dealing with for
the last
  3+ years, right?:-)
> 
> 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?
>
[Sasha] While the terms U-PE and S-PE are very convenient, they
carry a certain connotation that requires, IMO, clarification. Namely,
is an S-PE really a "provider edge" device? Because, IMO, "provider edge"
is something well understood and does not depend upon existence or
non-existence of MH-PWs... In other words: can any router on the path
between a pair of U-PEs become an S-PE, or is this functionality limited to
routers that belong to some well-defined borders?  
... snipped ...
> 
> 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'?
> 
[Sasha] This is a good example of a term defined but never used.
(So I am not sure it is worth clarifying what the Editors try to achieve
with this definition:-)
> 
> 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?
> 
> 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.
>
[Sasha] This is a good example of the style mixture.
The current (SH) PWE3 Architecture has its "Principle of Minimum
Intervention"
which presumably is equivalent to the client/server transparency. 
>
> 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.
>
[Sasha] I agree that this can become a nightmare both for the operators
and for the vendors. On the other hand, can we really prohibit any
kind of interworking at S-PEs without serios impact on the desired
functionality? Or should we restrict interworking to a few
well-understood use cases? 
>
> 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?
> 
[Sasha] I could not say it better!
... snipped ...
> "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)?
> 
[Sasha] I agree. 
> "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?
> 
[Sasha] It looks correct to me, and leads me to a conclusion that
this requirement cannot be realistically met.
> 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"?
> 
> 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? 
> 
[Sasha] Assuming that zero OSS touches (whatever an OSS touch means)
presumably cannot result in setup of an MH-PW, 1 (one) seems like
the lower limit for this number. And, as mentioned already on this
list, it is important to understand whether the requirement for minimal
number of OSS touches means "a single OSS touch" (in which case it
can be easily verified), or someting else -in which case it is not clear
to me that it can be verified: how do you prove that a specific MH-PW
set up with N>1 OSS touches cannot be set up with (N-1) touches?
> "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"
> 
... snipped to the end ...

---

From: [email-masked]
Date: Wed, 22 Dec 2004 06:16:58 -0000

Hi Sasha,  Largely agree with all your points...a few observations
below.

> [Sasha] I'd say that the draft requires some clean-up 
> regarding the style and usage of terms:
> - IMO, consistent usage of one set of terms and notions is 
> preferable to mixing existing PWE3
>   terms with ITU-T G.805/G.809 ones. If necessary (and I 
> agree that it would be beneficial),
NH=> I know the guys who started the G.805 func arch stuff and I also
know why they did it, ie to create a consistent language to describe
networks, esp for the folks who then need to create equipement
specifications and management information models.  The key point about
this stuff is that it captures 'discovered truths' about
networking.....so, irrespective of whether one likes or dislikes the
actual vocabulary used, the underlying concepts are invariant of this.
Its a pity more folks are not familar with these concepts as I think
they help provide insight and clarity.
 
>   a "translation" could be provided, but it should be 
> localized (e.g., in an Annex).
>   (And, yest,I fully understand that this would be at quite a 
> cost to the Editors. But
> - Different things should be called by different names. E.g., 
> either an SH-PW and 
>   a PW segment are different, or there is no such term as a 
> PW segment (I assume
>   that SH-PWs exist, since that is what this WG has been 
> dealing with for the last
>   3+ years, right?:-)
> > 
> > 2) In Section 3.2:
> [Sasha] While the terms U-PE and S-PE are very convenient, 
> they carry a certain connotation that requires, IMO, 
> clarification. Namely, is an S-PE really a "provider edge" 
> device? Because, IMO, "provider edge" is something well 
> understood and does not depend upon existence or 
> non-existence of MH-PWs... In other words: can any router on 
> the path between a pair of U-PEs become an S-PE, or is this 
> functionality limited to routers that belong to some 
> well-defined borders?  
NH=> This is an excellent example of why using func arch helps one
see/describe things in a consistent way, ie irrespective of the 'names'
one gives to devices it is only the functions they contain that are of
any real importance.
> [Sasha] This is a good example of a term defined but never 
> used. (So I am not sure it is worth clarifying what the 
> Editors try to achieve with this definition:-)
NH=> I think the whole area of addressing is a bit of mess.  And one
reason for this IMO is that we have not used a func arch approach to
describing the networks we are dealing with.....this does not only apply
to MPLS but also GMPLS (ie the co-cs mode networks).  If one makes a
mistake with layer network addressing at t=0 it is very hard to go back
and sort it out later.  

One thing that has bothered me for a long time in MPLS is that the
trails (ie LSPs) do not have a consistent method of access point
addressing.  The traffic data-plane addresses should be independent of
the control-plane, ie whether a trail is created by signalling protocol
X, Y or Z or by network management provisioning the access point
addresses should be the same.  However, in MPLS these addresses take
their format from the signalling protocol used.  This is wrong.  When
one considers OAM requirements (and downstream NMS/OSS impact) this
issue comes into focus.  That is, a CV function is a common OAM theme
across all 3 network modes.....in the cl-ps mode this 'comes for free'
as each pkt contains a SA, but in the co modes we have to consciously
add this function.  So if we want a simple, consistent and unambiguous
method of defect detection/handling across the whole population of
trails we need a consistent method of inserting the trail's SA in the CV
function.  Further, this has to be unidirectional with processing at the
trail sink....else things will not work well/simply, and we can't have a
common approach across p2p and p2mp constructions.  For those reading
the MPLS WG list, you will also note I am also trying to get this point
across here because folks are currently discussing p2mp OAM
requirements.
> The current (SH) PWE3 Architecture has its "Principle of 
> Minimum Intervention" which presumably is equivalent to the 
> client/server transparency.
NH=> Yes it is Sasha.  I think it was a really big mistake to start this
client layer compression stuff as its creates (per case) functional
dependancies between the client and the server.  
> [Sasha] I agree that this can become a nightmare both for the 
> operators and for the vendors. On the other hand, can we 
> really prohibit any kind of interworking at S-PEs without 
> serios impact on the desired functionality? Or should we 
> restrict interworking to a few well-understood use cases?
NH=> This is an example of what happens downstream if if you don't keep
the client/server case functionally decoupled.  Of course one can't stop
folks doing crazy things (like client compression between layer
networks) but the default behaviour should be to sound arch principles.
> [Sasha] I could not say it better!
NH=> I agree with both of you.....but if you think about it then why
not?  I mean, if folks think things like client compression and
SDHoverIP are 'good ideas' then one can have any XoverY and recurse this
as many times as one likes....whether the resultant HRX (Hypothetical
Reference Connection) constructions will 'work' for some end-system
application and/or can be meaningfully apportioned (wrt impairment
objectives) across a set of tamdemed operator domains is yet another
complex problem that has been created and is waiting in the wings for
future discovery.
> > directions regardless of the method used to instantiate the MH-PW)?
NH=> I agree too.  The requirement for OOB control/management is an
issue that should be adressed in its own right.
> [Sasha] It looks correct to me, and leads me to a conclusion 
> that this requirement cannot be realistically met.
NH=> This is where I came in on the topic when I observed right at the
outset that moving from SH to MH LSPs is starting to look like creating
a new layer network to me (and all this implies as Ben noted above).
MPLS is a digital wrapper and this has a 'topology of the fly' issue
(see my response to Chris Metz of recent).  MPLS degenerates to a proper
layer network iff the top level LSPs are span-congruent with their
server (true networked) LSPs, ie the 1-hop top level LSPs are acting as
some form of 'session' IDs for the client payload....which is the case
with SH PWs and rfc2547 (the latter resolves to (at least) a VPN/VRF in
a PE).

I'm not sure how this issue is going to get resolved (or if it can get
resolved).  

regards, Neil
<snipped to end>

---

From: [email-masked]
Date: Wed, 22 Dec 2004 17:08:12 -0000

Sasha, Colleagues,

See in-line.  I have snipped where appropriate

Ben

> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: 21 December 2004 16:17
> To: Niven-jenkins,B,Ben,XGH5 R
> Cc: [email-masked]
> Subject: RE: [PWE3] Review of
> draft-martini-pwe3-MH-PW-requirements-00.txt
> 
> Ben and all,

I do not believe that the PWE3 'Principle of Minimum intervention' is exactly equivalent to client/server transparency which is what prompted the observation/query above.

My understanding is that the 'Principle of Minimum intervention' means that 'the payload should be transported as received with as few modifications as possible' whereas transparent transfer of a client means that 'the client must be transported as received with no modifications'.  So in my understanding client/server transparency is equivalent to a 'principle of no intervention'.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 24 Dec 2004 11:01:25 +0000

>>>-i then the default for Eth MH-PWs must be FCS retention?

I don't think that changing the PWE3 defaults is viable, because
the IETF tries very hard to maintain backwards compatibility.
Ideally the two outer ends of a MH-PW don't (or shouldn't) know
that they are part of a MH-PW.

However the above does not stop some "enhanced" mode such as FCS
retention becoming the industry norm.

> I do not believe that the PWE3 'Principle of Minimum intervention' 
is exactly equivalent to client/server transparency which is what
prompted the observation/query above.
> 
> My understanding is that the 'Principle of Minimum intervention' 
means that 'the payload should be transported as received with as
few modifications as possible' whereas transparent transfer of a
client means that 'the client must be transported as received
with no modifications'.  So in my understanding client/server
transparency is equivalent to a 'principle of no intervention'.

Unless you have a real piece of wire, then you always have
some changes - and even then there it depends on the wire.

There has been a consistent focus on Ethernet FCS (and we have
a draft to allow an FCS retention mode). FCS retention is a
relatively simple operation. However that is only part of the
story. For full transparency you also need to carry the
preamble bits, and maybe you need to propagate some timing
info as well.

So do we really want a complete absence of intervention - with
all the assocated hardware, bandwidth and deployment delay costs,
or is it that we need minimum intervention and are really just
discussing the extent of the emulation?

- Stewart

---

From: [email-masked]
Date: Fri, 24 Dec 2004 15:48:32 -0000

Hi Stewart,

> I don't think that changing the PWE3 defaults is viable, 
> because the IETF tries very hard to maintain backwards 
> compatibility.
NH=> I think we must always strive for adherence to correct
architectural practice....and in a client/server case (which is what PWs
are) the most fundamantal architectural requirement is functional
decoupling between the client and the server.  But when that is violated
(eg client compression) saying we should maintain backwards
compatibility with that is hardly good practice IMO.

> Ideally the two outer ends of a MH-PW don't 
> (or shouldn't) know that they are part of a MH-PW.
NH=> I fully agree.  And that is precisely what we would have now if:
-	we had adhered to the arch principle noted above of client and
server layer decoupling;
-	we had not forced an artifical requirement that XoverMPLS be
treated the same as XoverIP.....indeed, its already clear this is
untenable anyway.  The differences get even more obvious when one
considers the co-cs mode as in GMPLS, eg here control/management must be
OOB, but that is not the only difference.

I won't bore folks with a long explanation of why the 3 modes are
different and all that entails, but its this sort of stuff that has lead
to the current situation....which is a pity IMO as I think we could have
avoided many of the complexities/problems we now are encountering had we
used the correct arch principles from the outset.
 
> However the above does not stop some "enhanced" mode such as 
> FCS retention becoming the industry norm.
NH=> This spin on client compression is almost unforgiveable IMO.  If we
apply func arch principles to the IEEE specification of ethernet the FCS
is part of the link-connection adaptation and should be checked on each
link connection.  It is not part of the CI (characteristic information)
however (like the SA/DA is for example).  However, it should never be
removed if the traffic units then get switched across a series of
nodes/links and then re-inserted at some downstream point.....that is
clearly wrong.
> >>Intervention" which presumably is equivalent to the client/server 
> >>transparency.
> > 
> > 
> is exactly equivalent to client/server transparency which is 
> what prompted the observation/query above.
> > 
> means that 'the payload should be transported as received 
> with as few modifications as possible' whereas transparent 
> transfer of a client means that 'the client must be 
> transported as received with no modifications'.  So in my 
> understanding client/server transparency is equivalent to a 
> 'principle of no intervention'.
> > 
> 
NH=> True....and this is why it is important to be very clear on the
difference between section layer protocols that do not get
networked/switched (ie those that are media specific on links, like
optical line codes or indeed ethernet's preamble) and the CI of layer
network protocols (ie the traffic units that are switched/networked and
that remain constant over various electrical/optical/radio section layer
types).  This is a key purpose of defining layer networks according to
the functional arch principles of G.805 and G.809, ie to avoid any
ambiguity.
> 
> There has been a consistent focus on Ethernet FCS (and we 
> have a draft to allow an FCS retention mode). FCS retention 
> is a relatively simple operation. However that is only part 
> of the story. For full transparency you also need to carry 
> the preamble bits, and maybe you need to propagate some 
> timing info as well.
NH=> If one was truly emulating the section layer behaviour I'd
agree.....but this makes very little sense.  A section layer protocol,
almost by definition, lies at the bottom of the networked stack, ie
there is nothing below it.  The thing we must convey transparently
however is the CI.  Indeed, the name 'PW' can be seen as a pretty poor
choice because this is NOT what we are doing or what is required.
> 
> So do we really want a complete absence of intervention - 
> with all the assocated hardware, bandwidth and deployment 
> delay costs, or is it that we need minimum intervention and 
> are really just discussing the extent of the emulation?
NH=> What we really want is actually very simple....and if we do this
things are going to work as best they can (the limit here is how well
each technology has been functionally specified in the first place):
-	client/server decoupling (all planes)
-	correct mapping of defects detected at the server layer to the
client layer FDI (if the client belongs to the co mode).....the nature
of defect detection/handling in the server is dependent on the mode of
the server, its different in all 3 cases.
-	the adaptation between the client and server layers is a
function of the mode of both the client and the server...1 size does not
fit all here.

regards, Neil
> 
> - Stewart
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>