Subject: [mpls] Question about ICC

From: Mach Chen <[email-masked]>
Date: Fri, 10 Jun 2011 01:48:09 +0000

Hi,

Are ICCs globally unique?

According to the definition of ICC in M.1400, it just says that ICCs are unique within a country. And there is an example shows that different operators could have the same ICC (e.g., Teleglobe International (UK) Ltd and Téléglobe Canada ULC have the ICC code:"TGB"). 

So, if the ICCs are not globally unique, how to guarantee that the ICC-based identifiers are globally unique? 

Or maybe I missed something?

Best regards,
Mach

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 10 Jun 2011 16:37:25 +0300

Mach,
An excellent question!

lots of thanks for picking this up!

regards,
Sasha
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mach Chen [[email-masked]]
Sent: Friday, June 10, 2011 4:48 AM
To: [email-masked]
Cc: Matthew Wright
Subject: [mpls] Question about ICC

Hi,

Best regards,
Mach
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Vero Zheng <[email-masked]>
Date: Wed, 15 Jun 2011 15:50:54 +0800

Mach is correct on this. 
ICC is unique within a Country. To make it globally unique, a Country Code
is needed before the ICC.
Hope the authors of the identifiers draft are aware of this.

Several other drafts may also be affected.

Vero
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexander Vainshtein
> Sent: Friday, June 10, 2011 9:37 PM
> To: Mach Chen; [email-masked]
> Cc: Matthew Wright
> Subject: Re: [mpls] Question about ICC
> 
> Mach,
> An excellent question!
> 
> According to the definition of ICC in M.1400, it just says that ICCs are
unique
> within a country. And there is an example shows that different operators
could
> have the same ICC (e.g., Teleglobe International (UK) Ltd and Téléglobe
> Canada ULC have the ICC code:"TGB").
> 
> So, if the ICCs are not globally unique, how to guarantee that the
ICC-based
> identifiers are globally unique?
> 
> This e-mail message is intended for the recipient only and contains
information
> which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
> have received this transmission in error, please inform us by e-mail,
phone or
> fax, and then delete the original and all copies thereof.
>

---

From: <[email-masked]>
Date: Wed, 15 Jun 2011 09:37:25 +0100

Folks:

-	We should be using source addresses in misconnectivity checking OAM CV messages that relate to layer network access points.  Total coupling of address *structure* to layer network topology however is not a good thing, as minor changes to either require changes to the other.....total decoupling OTOH relegates addresses to names.

-	We should not be using arbitrary 'text strings' to identify connections as was the common OPs practice when these really old ITU Recs were written.  Note that USA operators liked these and kept them in the SDH stds (path trace) but other operators, and esp BT, pushed for pukka SA addresses to be used.

-	I'm not sure country code classification is that relevant here....we are not even dealing with a single layer network nor a TOS layer network where peering is required (sure we can create such peering problems, but they are technically quite unnecessary in any non-TOS layer network).  What is more relevant here is the client/server case...and this is not something any previous co-ps mode layer technology has considered.  Note we can have client server netsting of several different parties in the same country.

-	A corollary of the client/server problem when the client and server have the same traffic unit structure is that we can have inter-layer misconnectivity as well as intra-layer misconnectivity.  This means that the address structures we use in CV messages need to indicate at least 3 things:
-	the party X (globally unique)
-	the layer Y of party X (Y has to be unique within X)
-	the access point Z of layer network Y (Z has to be unique within Y).

Note that the normal forwarding information in the DP traffic units only need consider the access points addresses Z (of some layer network Y).  

regards, Neil

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

> Vero Zheng
> Sent: 15 June 2011 08:51
> To: 'Alexander Vainshtein'; 'Mach Chen'; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Cc: 'Matthew Wright'

---

From: Eric Gray <[email-masked]>
Date: Thu, 16 Jun 2011 07:14:28 -0400

Neil,

The case where a difference in either X or Y might result 
in an undetectable misconnectivity problem seems extremely
unlikely.  So much so, that it cannot be worth the trouble
to configure both X and Y information for every OAM entity
relationship, and carry it in every OAM message.

Say that operator X wants to check connectivity from A to Z
in layer Y. Now say that the actual connectivity is somehow
between A (in X at layer Y) and Z' (in X' at layer Y') where
identifier Z = identifier Z', and either X' != X or Y' != Y.

It seems to me that - for this misconnectivity to remain 
undetected - Z' would need to be configured to respond to
OAM messages from A.  Unless the OAM setup can occur auto-
magically at Z' (based on signaling from A, perhaps), or is
(for some reason) unnecessary, this seems like an extremely 
unlikely occurrence, since it requires both misconnectivity
and either a very unlikely coincidence, or an identical 
misconfiguration of OAM.

If OAM setup at Z' can occur automatically, it would - in 
this case - require signaling that traverses either the
(X, X') or (Y, Y') boundary (depending on which applies in
any given case conforming to this strange scenario).  That
this could happen, if signaling occurs in the same channel
as the misconnectivity, seems to be a flaw in techniques
that depends on this mechanism for OAM setup.

So, assuming that OAM MEP setup occurs using some technique
that doesn't involve signaling over a potentially incorrect
connection, without signaling authentication - exactly how
likely is it that this scenario will actually occur in the
real world?

If OAM setup is unnecessary, this is a special problem (but
still quite unlikely).  If this is possible, it seems to me
that a better safeguard against this occurrence would be to
prevent OAM messages from crossing either the (X, X') or 
(Y, Y') boundary.

This is quite a bit more likely than it may seem.  It is 
quite likely that typical OAM messaging across an (X, X')
boundary is blocked by default (to protect against an OAM
based DoS attack, for example).  And it seems to me that
transferring OAM messages across a (Y, Y') boundary is not
a trivial process and therefore extremely unlikely to occur
accidentally.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 15, 2011 4:37 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Eric Gray
Cc: [email-masked]
Subject: RE: [mpls] Question about ICC
Importance: High

Folks:

regards, Neil

---

From: <[email-masked]>
Date: Thu, 16 Jun 2011 12:58:17 +0100

Eric...please see in-line:

Eric Gray [mailto:[email-masked]]b wrote 16 June 2011 12:14
> unlikely. 

NH=> I recall someone (I won't say who) saying many years ago at an IETF mtg that if we had misconnectivity problems in MPLS then we should buy our equipment form a reputable supplier and not add OAM...things seems to have changed a bit since then....

> So much so, that it cannot be worth the trouble

NH=> Well, that is a judgement call one has to make. But given that the ability to provide a transparent client/server relationship is the critical service a transport network must provide then one should at least consider the implications of this within the OAM framework.
 
The inter-layer misconnectivity problem does not arise in any co-cs mode layer transport network where the traffic unit (frame) is of a fixed size....this is a property of the regular time-slicing of resource that creates the co-cs network mode.  So here we only have intra-layer misconnectivity to deal with.

It also was not a problem with past co-ps mode technologies because we never self-nested them AFAIK...indeed for any co-ps mode technology based on a fixed traffic unit size (similar to the co-cs case above) this would not be possible anyway, eg ATM.

The problem of misconnectivity between different LSP levels already exists in MPLS wrt sublayering of LSPs.  But here we are only dealing with a single layer network belonging to one party.

However, in a proper transport network such sublayering is not required.  We do however require layering.  And in MPLS-TP we have both sublayering and layering.

So one can either aim for completeness in one's approach to OAM across both nested sublayers and layers or not.  That is a judgement call one can make.

> OAM messages from A. 

NH=> We should never use OAM that is of a request/response type to detect defects in either co-cs or co-ps mode layer networks as it is not reliable.  This is not like the cl-ps mode where request/response OAM is the right approach.  And the reason is that in the co-cs or co-ps mode we create connections which are constraining constructs for their child traffic units and OAM....this is also why one can take short-cuts of the labelling of the child traffic units as I have explained in previous mails.  However, one can have traffic leak unidirectionally from a connection, ie there is no return path.  So request/response OAM should never be used to try and detect or trace out misconnectivity defects in such networks.

> Unless the OAM setup can occur auto-

NH=> Hmm...not sure this is valid.  One should be passing client traffic and its OAM transparently in the server in a client/server relationship.  Something could happen in a server layer to incorrectly strip off the server header and expose the client traffic units and OAM to forwarding in the server layer.  This is the type of defect I had in mind....same thing can happen in MPLS today but here only wrt sublayering in the same layer network.

regards, Neil

> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Eric Gray
> -	We should be using source addresses in misconnectivity checking
> OAM CV messages that relate to layer network access points.  Total
> coupling of address *structure* to layer network topology however is
> not a good thing, as minor changes to either require changes to the
> other.....total decoupling OTOH relegates addresses to names.
> 
> -	We should not be using arbitrary 'text strings' to identify
> connections as was the common OPs practice when these really old ITU
> Recs were written.  Note that USA operators liked these and kept them
> in the SDH stds (path trace) but other operators, and esp BT, pushed
> for pukka SA addresses to be used.
> 
> -	I'm not sure country code classification is that relevant
> here....we are not even dealing with a single layer network nor a TOS
> layer network where peering is required (sure we can create such
> peering problems, but they are technically quite unnecessary in any
> non-TOS layer network).  What is more relevant here is the
> client/server case...and this is not something any previous co-ps mode
> layer technology has considered.  Note we can have client server
> netsting of several different parties in the same country.
> 
> -	A corollary of the client/server problem when the client and
> server have the same traffic unit structure is that we can have inter-
> layer misconnectivity as well as intra-layer misconnectivity.  This
> means that the address structures we use in CV messages need to
> indicate at least 3 things:
> Note that the normal forwarding information in the DP traffic units
> only need consider the access points addresses Z (of some layer network
> Y).
> 
> regards, Neil
> 
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > > Alexander Vainshtein
> > > From: [email-masked] [[email-masked]] On Behalf Of
> Mach
> > > Chen [[email-masked]]
> > > According to the definition of ICC in M.1400, it just says that
> ICCs
> > are
> > unique
> > > which is CONFIDENTIAL and which may be proprietary to ECI Telecom.
> If
> > you

---

From: George Swallow <[email-masked]>
Date: Thu, 16 Jun 2011 17:03:52 -0400

Vero -

Carrier codes are done on a national basis.   But I believe that ICCs are
unique.  My basis for this belief is the following on the ITU Web page.

"A centralized List of ITU Carrier Codes (ICCs) has been created with the
ITU/TSB as the repository. All domestic and international carriers are
expected to register with ITU/TSB for a carrier code. Instead of individual
operators sending their ICCs to the TSB for registration, the national
regulatory authorities are requested to provide the validated codes and
related information of domestic network operators directly to the TSB. This
list may be used to identify the operators while completing layer 2 records,
related information, as explained in paragraph 8.3, 13.3 and 20.3 of ITU-T
Recommendation M.1400."

8.3 has an example using unqualified (no country code) ICCs used to
designate an international circuit.

The odd thing is that I cannot find a pointer to the "centralized List of
ITU Carrier Codes (ICCs)".

...George

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 16 Jun 2011 23:19:41 +0200

George,
The codes are unique within a country. 
As specified in M.1400, the national authority in each country is requested to ensure that the Carrier Codes are unique within that country. 
That means that in order to have unique global identification you must include the country code (which identifies the country in which the town is located. Format: ISO 3166 three alpha-code).
Best regards,
Nurit

P.S. note that where M.1400 refers to a transmission station in which the circuit is terminating, they include the following elements: town name, transmission station detail, operator ID (ICC) and country code. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext George Swallow
Sent: Friday, June 17, 2011 12:04 AM
To: Vero Zheng; 'Alexander Vainshtein'; 'Mach Chen'; [email-masked]; BOCCI Matthew; Eric Gray
Cc: 'Matthew Wright'
Subject: Re: [mpls] Question about ICC

Vero -

...George

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 16 Jun 2011 23:25:58 +0200

I had a typo :-(
See correction below <NS>. 

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
Sent: Friday, June 17, 2011 12:20 AM
To: 'ext George Swallow'; Vero Zheng; 'Alexander Vainshtein'; 'Mach Chen'; [email-masked]; BOCCI Matthew; Eric Gray
Cc: 'Matthew Wright'
Subject: RE: [mpls] Question about ICC

George,

<NS> that means that in order to have a unique global identification you must include the country code (which identifies the country of the domestic network operator. Format: ISO 3166 three alpha-code).

Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext George Swallow
Sent: Friday, June 17, 2011 12:04 AM
To: Vero Zheng; 'Alexander Vainshtein'; 'Mach Chen'; [email-masked]; BOCCI Matthew; Eric Gray
Cc: 'Matthew Wright'
Subject: Re: [mpls] Question about ICC

Vero -

...George

---

From: "Nattrass, William W" <[email-masked]>
Date: Fri, 17 Jun 2011 09:11:49 -0400

Who maintains the list?  

Is it being said that the ITU is a maintenance agency to maintain a listing?

If so,  how does ITU receive remuneration for the work?

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of George Swallow
Sent: Thursday, June 16, 2011 5:04 PM
To: Vero Zheng; 'Alexander Vainshtein'; 'Mach Chen'; [email-masked]; BOCCI Matthew; Eric Gray
Cc: 'Matthew Wright'
Subject: Re: [mpls] Question about ICC

Vero -

...George

---

From: George Swallow <[email-masked]>
Date: Fri, 17 Jun 2011 09:12:35 -0400

Thanks Nurit.  Guess Y.1731 has a problem here as well!

...George

On 6/16/11 5:25 PM, "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
<[email-masked]> wrote:

> As specified in M.1400, the national authority in each country is requested to
> ensure that the Carrier Codes are unique within that country.
> That means that in order to have unique global identification you must include
> the country code (which identifies the country in which the town is located.
> Format: ISO 3166 three alpha-code).
> 
> <NS> that means that in order to have a unique global identification you must
> include the country code (which identifies the country of the domestic network
> operator. Format: ISO 3166 three alpha-code).
> 
> Best regards,
> Nurit
> 
> P.S. note that where M.1400 refers to a transmission station in which the
> circuit is terminating, they include the following elements: town name,
> transmission station detail, operator ID (ICC) and country code.
>