Subject: [mpls-tp] FW: [T15Q12] FW: working group last call ondraft-ietf-mpls-tp-nm-req-01.txt

From: <[email-masked]>
Date: Wed, 6 May 2009 13:04:13 +0100

Forgot to copy IETF MPLS-TP list....

-----Original Message-----
From: Harrison,N,Neil,CXM R 
Sent: 06 May 2009 12:58
To: 'Malcolm Betts'; [email-masked]'
Subject: RE: [T15Q12] FW: [mpls-tp] working group last call
ondraft-ietf-mpls-tp-nm-req-01.txt

Thanks Malcolm,

This is a useful and well-written document.  I have only some minor
observations for consideration:

1	In section 1 the draft defines a 'Communications Channel' which
is abbreviated to CC.  In order to avoid confusion with the OAM message
that Checks Connectivity (CC), I suggest the latter use the term CV
(Connectivity Verification) since this term captures both correct
connectivity ('continuity') and misconnectivity.

2	In section 6.5 it says:
"The MPLS-TP NE MUST support the configuration of maintenance entity
identifiers (e.g. MEP ID and MIP ID) for the purpose of LSP connectivity
checking."

I hope this is not understood as a requirement to provide a suite of
preconfigured OAM sublayers, ie TCM.  For on-demand investigation of
connectivity defects and performance degradations the requirements
should allow an implementation which is based on the passive tap-off of
a end-end unidirectional (also see aside) CV/PM flow at intermediate
nodes.

Aside => In co-ps mode networks the defect detection/handling OAM needs
to be unidirectional for several reasons.  In particular, when
defect-free a connection is a (single-source) constraining construct to
both DP traffic and DP OAM.  However, some types of misconnectivity can
result in traffic/OAM leaking from a connection (and perhaps getting
misinserted in some other connection).  Such leaking traffic/OAM defects
are very likely to be unidirectional in nature.  Therefore, OAM that is
of a request/response type (eg loopback) may not help in tracking down
the leaking-traffic type of misconnectivity.  In co-ps mode networks OAM
that is of a request/response nature should only be used under the
assumption that the network is misconnectivity defect-free, eg RTD
measurement.

3	Ibid it says:
"The MPLS-TP NE MUST support the enabling/disabling of the connectivity
check processing. The connectivity check process of the MPLS-TP NE MUST
support provisioning of the identifiers to be transmitted and the
expected identifiers."

Couple of points:
-	see previous comment 1 regarding possible confusion of the
acronym CC
-	agree with thrust of sentence but IMO it makes much sense to use
the source address (SA) of the DP LSP in CV OAM messages....
-	.....further, if a CP signalling protocol is used this should be
able to configure the expected CV SA at the LSP termination sink
point(s).

4	In section 7 it says:
"ITU-T Recommendation G.7710 [1] provides transport performance
monitoring requirements for packet-switched and circuit-switched
transport networks with the objective of providing coherent and
consistent interpretation of the network behaviour, in particular **for
hybrid network which consists of multiple transport technologies.** "

See the text highlighted (by **).  It would be useful if one of the
authors could please clarify what is meant by this.  I ask because a
given/single layer network needs to have consistent characteristic
information and so cannot be composed of different network
modes/technologies.

Aside=> There is a key point wrt the control of performance inheritance
in client/server layer network hierarchies but I am assuming this is not
what is meant here. 

5	In section 7.1 PM measurements are considered, and the SES
parameter is mentioned.  I think we have to be quite pragmatic about the
SES metric measurement in MPLS-TP networks.  Andy Reid and I spent
several years in the late-80s/early-90s measuring and mathematically
modelling real error distributions on PDH/SDH transport networks and
transmission systems and I never saw a SES as originally defined, ie a
Poisson bit error density >10^-3.  One tends to see self-similar error
bursts as the dominant source of error events on transmission systems
(not, Poisson, thermal noise induced BERs) where the bit error density
is 0.5 for some period T.  These events usually result in uncontrolled
bit slips (due to justification corruption) in PDH networks that are
mitigated by a rapid loss/recovery of frame alignment (which is the main
signature of SES, at least in the BT PDH networks we looked at in the
UK).  

Further, we also observed that SES events were either <<1s (ie a couple
of ms due to loss/recovery of framing from corrupted justification
control bits) or 1-4s in length.  Events lasting longer than this rarely
'went away' on their own and invariably then resulted in unavailable
time.  We were very surprised to see a roughly 50/50 split between
singleton-ms-SES and few-seconds-SES, and this led to us urging that
networks should also measure short-break events, ie periods of 3-9
consecutive SES.

I only mention this all 'in-passing' as things to be aware of when we
come to specify the PM metrics for MPLS-TP.  I have no idea how current
transport networks behave wrt what real error events look like and it
would be very useful if anyone has any more recent measurements that we
could look-at/discuss.

6	Section 9 discusses security considerations.  Although one can
consider malicious/DOS type of attacks on the DP one can also consider
misconnectivity defects as 'fortuitous/accidental' security compromises.
This latter point is why it is important in co-ps mode networks based on
label-swapping (like MPLS-TP) to have and a proactive CV flow containing
the LSP source address.  The authors might like to consider if it is
worth adding any comments in the draft wrt this latter point.

regards, Neil

> -----Original Message-----
> From: Malcolm Betts [mailto:[email-masked]] 
> Sent: 05 May 2009 14:22
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: [T15Q12] FW: [mpls-tp] working group last call 
> ondraft-ietf-mpls-tp-nm-req-01.txt
> 
> All, this is the WG last call for the MPLS-TP Network Management
> requirements.  If the last call is successful the next step in the
> process will be for the IETF to formally request the ITU to review and
> agree to the approval of this document.
> 
> To minimize the time required to revise the document following the
> formal ITU review process please review this document and 
> send comments
> directly to the [email-masked] mailing list.
> 
> If you have major comments that you consider should be provided in a
> liaison statement to the IETF please post them on the
> [email-masked] by May 18th. 
> 
> 
> Malcolm Betts
> co chair Ad Hoc MPLS-TP
> Phone: +1 613 763 7860 (ESN 393)
> email: [email-masked]
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Loa Andersson
> Sent: Monday, May 04, 2009 11:25 AM
> To: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]; Adrian Farrel; Ross Callon; George Swallow
> Subject: [mpls-tp] working group last call
> ondraft-ietf-mpls-tp-nm-req-01.txt
> 
> ALL,
> 
> This is to start a two week working group last call on
> 
> draft-ietf-mpls-tp-nm-req-01.txt
> 
> Please send your comments to the mpls-tp mailing list.
> 
> This working group last call is joint between the mpls, 
> ccamp. Pwe3 and
> l2vpn.
> 
> The working group lst call ends on May 19th eob.
> 
> /Loa
> 
> 
> -- 
> 
> 
> Loa Andersson
> 
> Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
> Ericsson ///                                 +46 767 72 92 13 
> 
> 
>                                        email:
> [email-masked]
>                                                
> [email-masked]
>                                                [email-masked]
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> 
> 
> 
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 06 May 2009 20:10:07 +0100

Neil, Colleagues,

> connectivity ('continuity') and misconnectivity.

Use of CC Vs CV and whether we just need CV was much debated, so as not to
open up that debate again in the context of the NM draft but to address your
valid concern over ambiguity and to align with other documents e.g. GACh, I
propose using CCh for "Communications Channel".

Ben

---

From: <[email-masked]>
Date: Wed, 6 May 2009 20:16:50 +0100

Thanks Ben....no problems, your suggestion is fine with me, I don't care
what we call it as long as it is unambiguous.  regards, Neil  

> From: Niven-jenkins,B,Ben,DMF R 
> Sent: 06 May 2009 20:10
> To: Harrison,N,Neil,CXM R; [email-masked]
> Subject: Re: [mpls-tp] FW: [T15Q12] FW: working group last 
> call ondraft-ietf-mpls-tp-nm-req-01.txt
> 
> Neil, Colleagues,
> 
>

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Wed, 6 May 2009 15:21:25 -0500

Neil, Ben, and all,

Using CCh for 'Communications Channel' is okay to me provided we can
keep MCC for "Management Communications Channel' and
SCC for "Signaling Communications Channel'.

MCC and SCC have been used in many other documents, including existing
ITU-T recommendations. Any change to the use of MCC and SCC should be
avoided.

Regards,
Kam 

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of [email-masked]
> Sent: Wednesday, May 06, 2009 3:17 PM
> To: [email-masked]; [email-masked]
callondraft-
> ietf-mpls-tp-nm-req-01.txt
>

---

From: "Maarten Vissers" <[email-masked]>
Date: Thu, 7 May 2009 08:21:31 +0200

Neil,

The MEGID+MEPID provides a unique source address of an LSP input port.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: woensdag 6 mei 2009 14:04
To: [email-masked]
Subject: [mpls-tp] FW: [T15Q12] FW: working group last
callondraft-ietf-mpls-tp-nm-req-01.txt

-----Original Message-----
From: Harrison,N,Neil,CXM R
Sent: 06 May 2009 12:58
To: 'Malcolm Betts'; [email-masked]'
Subject: RE: [T15Q12] FW: [mpls-tp] working group last call

Thanks Malcolm,

1	In section 1 the draft defines a 'Communications Channel' which
is abbreviated to CC.  In order to avoid confusion with the OAM message that
Checks Connectivity (CC), I suggest the latter use the term CV (Connectivity
Verification) since this term captures both correct connectivity
('continuity') and misconnectivity.

I hope this is not understood as a requirement to provide a suite of
preconfigured OAM sublayers, ie TCM.  For on-demand investigation of
connectivity defects and performance degradations the requirements should
allow an implementation which is based on the passive tap-off of a end-end
unidirectional (also see aside) CV/PM flow at intermediate nodes.

Aside => In co-ps mode networks the defect detection/handling OAM needs to
be unidirectional for several reasons.  In particular, when defect-free a
connection is a (single-source) constraining construct to both DP traffic
and DP OAM.  However, some types of misconnectivity can result in
traffic/OAM leaking from a connection (and perhaps getting misinserted in
some other connection).  Such leaking traffic/OAM defects are very likely to
be unidirectional in nature.  Therefore, OAM that is of a request/response
type (eg loopback) may not help in tracking down the leaking-traffic type of
misconnectivity.  In co-ps mode networks OAM that is of a request/response
nature should only be used under the assumption that the network is
misconnectivity defect-free, eg RTD measurement.

3	Ibid it says:
"The MPLS-TP NE MUST support the enabling/disabling of the connectivity
check processing. The connectivity check process of the MPLS-TP NE MUST
support provisioning of the identifiers to be transmitted and the expected
identifiers."

Couple of points:
able to configure the expected CV SA at the LSP termination sink point(s).

4	In section 7 it says:
"ITU-T Recommendation G.7710 [1] provides transport performance monitoring
requirements for packet-switched and circuit-switched transport networks
with the objective of providing coherent and consistent interpretation of
the network behaviour, in particular **for hybrid network which consists of
multiple transport technologies.** "

See the text highlighted (by **).  It would be useful if one of the authors
could please clarify what is meant by this.  I ask because a given/single
layer network needs to have consistent characteristic information and so
cannot be composed of different network modes/technologies.

Aside=> There is a key point wrt the control of performance inheritance in
client/server layer network hierarchies but I am assuming this is not what
is meant here. 

5	In section 7.1 PM measurements are considered, and the SES
parameter is mentioned.  I think we have to be quite pragmatic about the SES
metric measurement in MPLS-TP networks.  Andy Reid and I spent several years
in the late-80s/early-90s measuring and mathematically modelling real error
distributions on PDH/SDH transport networks and transmission systems and I
never saw a SES as originally defined, ie a Poisson bit error density
>10^-3.  One tends to see self-similar error bursts as the dominant source
of error events on transmission systems (not, Poisson, thermal noise induced
BERs) where the bit error density is 0.5 for some period T.  These events
usually result in uncontrolled bit slips (due to justification corruption)
in PDH networks that are mitigated by a rapid loss/recovery of frame
alignment (which is the main signature of SES, at least in the BT PDH
networks we looked at in the UK).  

Further, we also observed that SES events were either <<1s (ie a couple of
ms due to loss/recovery of framing from corrupted justification control
bits) or 1-4s in length.  Events lasting longer than this rarely 'went away'
on their own and invariably then resulted in unavailable time.  We were very
surprised to see a roughly 50/50 split between singleton-ms-SES and
few-seconds-SES, and this led to us urging that networks should also measure
short-break events, ie periods of 3-9 consecutive SES.

I only mention this all 'in-passing' as things to be aware of when we come
to specify the PM metrics for MPLS-TP.  I have no idea how current transport
networks behave wrt what real error events look like and it would be very
useful if anyone has any more recent measurements that we could
look-at/discuss.

6	Section 9 discusses security considerations.  Although one can
consider malicious/DOS type of attacks on the DP one can also consider
misconnectivity defects as 'fortuitous/accidental' security compromises.
This latter point is why it is important in co-ps mode networks based on
label-swapping (like MPLS-TP) to have and a proactive CV flow containing the
LSP source address.  The authors might like to consider if it is worth
adding any comments in the draft wrt this latter point.

regards, Neil

> formal ITU review process please review this document and send 
> comments directly to the [email-masked] mailing list.
> 
> [email-masked]; [email-masked]; Adrian Farrel; Ross Callon; George 
> Swallow
> This working group last call is joint between the mpls, ccamp. Pwe3 
> and l2vpn.
>