Subject: Re: [mpls] ICC and CC

From: Huub van Helvoort <[email-masked]>
Date: Fri, 01 Jul 2011 12:00:06 +0200

Hello George,

On 17-06-11 you wrote:

> And if so, do you have a suggestion for the combined fields?

Yes. After discussing the MEG-ID format on the Q10 list we have
the following format definition, the identifier

 >- consists of 13 characters, which contain:
 >- ICC (1 to 6 characters) as defined in rec. M.1400
 >- "/"
 >- CC (2 characters) as defined in ISO 3166-1 alpha-2
 >- UMC with trailing NULLs

All used characters are as defined in rec. T.50.

> I thought ICC stood for _International_ Carrier Code. M.1600 does not
> expand the acronym.

This acronym is expanded in M.1400, which is referenced in
the identifiers draft, as "ITU-T Carrier Code".
The CC above is "Country Code".
And UMC is "Unique MEG ID Code".

Regards, Huub.

> On 6/17/11 9:19 AM, "George Swallow" <[email-masked]> wrote:
>
>     Huub, Italo, Malcolm,
>
>     I look to you guys as the authority on this. Should I prefix the ICC
>     with a CC?
>
>     Thanks,
>
>     ...George
>     ------------------------------------------------------------------------
>     _______________________________________________
>     mpls mailing list
>     [email-masked]
>     https://www.ietf.org/mailman/listinfo/mpls
>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

-- 
*****************************************************************
                          我爱外点一七三一

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 1 Jul 2011 16:52:21 +0200

Hub,
I did not see yet an agreement on the proposal in Q10.
I do not think your mail represents the ITU-T.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Huub van Helvoort
Sent: Friday, July 01, 2011 1:00 PM
To: George Swallow
Cc: [email-masked]; Huub van Helvoort; BUSI,ITALO (ITALO)
Subject: Re: [mpls] ICC and CC

Hello George,

Regards, Huub.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 04 Jul 2011 12:30:57 +0100

I have been away for a few days and so have only just had time to read 
the thread. Here is what I posted to the ITU list:

I pulled up a copy of Y.1731-2008

Y.1731-2008 defines MEG ID type 32

It says length MUST be 13

It says MEG ID MUST be 7 to 12 characters

It says that everything that follows the last alpha/numeric MUST be a NULL.

An implementation can expect that this definition of type 32 is 
definitive and that any thing else is an error.

It is impossible to do an exhaustive investigation of all existing 
implementations and implementations in progress. Thus to change the 
definition of type 32 is unsafe.

Therefore the only safe way to introduce an ICC that contains a country 
code is to define a new MEG ID type.

A new MEG ID type  is not constrained by the definition of type 32.

- Stewart (no hats on)

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 04 Jul 2011 13:57:20 +0200

Hello Stewart,

You wrote:

> I have been away for a few days and so have only just had time to
 > read the thread.

(Maybe you skipped a few messages)

The request from George was for the definition of a global
unique ICC for *MPLS-TP*.
The answer is:
To make it globally unique use the format: [ICC]/[CC]
where [ICC] is the 1-6 character ITU-T Carrier Code,
and [CC] is the 2 character ISO Country Code.

> Here is what I posted to the ITU list:
>

This addresses Y.1731 and is not relevant to the question
from George.

Regards, Huub.

---

From: [email-masked]
Date: Mon, 4 Jul 2011 10:30:35 -0400

Stewart,

Why did you post this on the mpls list, this only impacts G.8013/Y.1731 
i.e. Ethernet.  It has no impact on MPLS-TP.

Regards,

Malcolm

Stewart Bryant <[email-masked]> 
Sent by: [email-masked]
04/07/2011 07:30 AM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: [mpls] ICC and CC

I have been away for a few days and so have only just had time to read the 
thread. Here is what I posted to the ITU list:

It says that everything that follows the last alpha/numeric MUST be a 
NULL.

An implementation can expect that this definition of type 32 is definitive 
and that any thing else is an error.

- Stewart (no hats on)