Subject: [mpls] Identifiers following ITU-T conventions (was: draft-win-mpls-tp-itu-t-identifiers-01)

From: Rolf Winter <[email-masked]>
Date: Thu, 14 Jul 2011 19:16:58 +0000

Hello,

I changed the subject line since this is I think orthogonal to the call for adoption. I also try to address a set of comments from different people that have been raised in this one Email.

The main discussion has been revolving around the actual format of the MEG_ID, in particular the length of the whole ID and the length of the operator-definable part. The length results from Y.1731 using 13 bytes for MEG_IDs and the document is following ITU-T conventions after all. So that is where the length comes from. If the WG decides that the remaining UMC is not long enough then we need to define another identifier. That's regular WG process I'd say. In either event this document will be liaised with the ITU-T ensuring we follow the right ITU-T conventions.

Regarding the UMC. It is at least 4 characters long. If you restrict yourself to alphanumeric you will have 36 states per character resulting in 36^4 possible combinations which is around 1.6 million. I think the sheer number might not the problem but rather the structure, i.e. existing structures might not fit into these 4 characters and again, the WG needs to figure this out.

The need for a delimiter is based on the fact that you have three fields, two of which are of variable length. Let me illustrate this with an example to show that the delimiter is needed independent of the ordering. (and yes there are other ways to deal with this which I'd be happy to discuss). Say you do CC:ICC:UMC and take country "AB". Take also operator "C" and operator "CD". If "C" decides to use a UMC "DE" and "CD" to use a UMC "E" the resulting MEG IDs would be equal. A delimiter will solve this issue. The same principle applies to the ordering ICC:CC:UMC only here this could happen even with different country codes but if you want to be 100% sure that such a situation cannot arise, then you need another token in the ID (or used fixed sized fields or use another trick...).

Generally, there have been comments that the adoption call is either too early or the content should go into the identifiers draft. Well, the content in fact has been in that document. So, in principle the need for this already has been acked by the WG. This draft addresses the shortcoming which caused the content to be removed. That is why I asked the chairs to do the poll now (so please don't blame Ross, blame me). 

Anyway, I am happy to discuss this further.

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Jul 2011 20:51:18 +0100

Rolf

So the 16 bit identifier in section 5 is an additional identifier?

Please could you reduce the confusion by drawing up the proposed data 
structure in octet/longword format as per traditional IETF representation.

- Stewart

On 14/07/2011 20:16, Rolf Winter wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Kyung-Yeop Hong (hongk)" <[email-masked]>
Date: Thu, 14 Jul 2011 17:21:14 -0500

Rolf et al,

As the content had been in the draft-ietf-mpls-tp-identifiers and
removed due to the shortcoming until resolved, I propose to discuss and
figure out the resolution first before the adoption call.

I also believe the content should go back into the identifiers draft
once resolved.

Regards,
KY

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stewart Bryant (stbryant)
Sent: Thursday, July 14, 2011 3:51 PM
To: [email-masked]
Subject: Re: [mpls] Identifiers following ITU-T conventions
(was:draft-win-mpls-tp-itu-t-identifiers-01)

Rolf

Please could you reduce the confusion by drawing up the proposed data 
structure in octet/longword format as per traditional IETF
representation.

- Stewart

On 14/07/2011 20:16, Rolf Winter wrote:
> Hello,
>
>
> I changed the subject line since this is I think orthogonal to the
call for adoption. I also try to address a set of comments from
different people that have been raised in this one Email.
>
> The main discussion has been revolving around the actual format of the
MEG_ID, in particular the length of the whole ID and the length of the
operator-definable part. The length results from Y.1731 using 13 bytes
for MEG_IDs and the document is following ITU-T conventions after all.
So that is where the length comes from. If the WG decides that the
remaining UMC is not long enough then we need to define another
identifier. That's regular WG process I'd say. In either event this
document will be liaised with the ITU-T ensuring we follow the right
ITU-T conventions.
>
> Regarding the UMC. It is at least 4 characters long. If you restrict
yourself to alphanumeric you will have 36 states per character resulting
in 36^4 possible combinations which is around 1.6 million. I think the
sheer number might not the problem but rather the structure, i.e.
existing structures might not fit into these 4 characters and again, the
WG needs to figure this out.
>
> The need for a delimiter is based on the fact that you have three
fields, two of which are of variable length. Let me illustrate this with
an example to show that the delimiter is needed independent of the
ordering. (and yes there are other ways to deal with this which I'd be
happy to discuss). Say you do CC:ICC:UMC and take country "AB". Take
also operator "C" and operator "CD". If "C" decides to use a UMC "DE"
and "CD" to use a UMC "E" the resulting MEG IDs would be equal. A
delimiter will solve this issue. The same principle applies to the
ordering ICC:CC:UMC only here this could happen even with different
country codes but if you want to be 100% sure that such a situation
cannot arise, then you need another token in the ID (or used fixed sized
fields or use another trick...).
>
> Generally, there have been comments that the adoption call is either
too early or the content should go into the identifiers draft. Well, the
content in fact has been in that document. So, in principle the need for
this already has been acked by the WG. This draft addresses the
shortcoming which caused the content to be removed. That is why I asked
the chairs to do the poll now (so please don't blame Ross, blame me).
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014

---

From: Rolf Winter <[email-masked]>
Date: Fri, 15 Jul 2011 07:35:16 +0000

Hi KY,

> figure out the resolution first before the adoption call.

The shortcoming was the lack of ICC global-uniqueness. We address this in the draft.
 
> I also believe the content should go back into the identifiers draft

I suggested just that not so long ago. But the chairs' suggestion was to write a new document (see: http://www.ietf.org/mail-archive/web/mpls/current/msg06623.html) which might be able to swiftly go through the WG processes. So in short: I agree with you but this alternative has been dismissed in the past already.

Best,

Rolf

---

From: Rolf Winter <[email-masked]>
Date: Fri, 15 Jul 2011 11:18:29 +0000

Stewart,

Notation-wise we were following the identifiers draft which does also not include representations in ASCII art but in section 5 we indeed did forget to add it. I have drawn the ASCII art below, I hope it displays OK. This is the MEG_ID format as described in section 5. The 16 bit you are referring to I believe (in section 6 though) is indeed another 16 bit following the MEG_ID (MEG_ID::MEP_Index) to form the MEP_ID. If you would like me to extend the ASCII art to also include these additional 16 bit please shout.

Maybe some other pointers here, which we should have added to the document. The characters are encoded according to recommendation T.50. Further, in case the UMC space is not fully utilized by the operator the remaining space is filled with NULL characters as per Recommendation.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ICC                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           ICC cnt.            |      "/"      |     CC        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    CC cnt.    |                      UMC min                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |
+-+-+-+-+-+-+-+-+

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ICC       |      "/"      |              CC               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            UMC max.                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            UMC cnt.                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     UMC cnt.  |
+-+-+-+-+-+-+-+-+

Best,

Rolf

> Stewart Bryant
> Sent: Donnerstag, 14. Juli 2011 21:51
> To: [email-masked]
> Subject: Re: [mpls] Identifiers following ITU-T conventions (was:
> draft-win-mpls-tp-itu-t-identifiers-01)
> 
> Rolf
> 
> > The main discussion has been revolving around the actual format of
> the MEG_ID, in particular the length of the whole ID and the length of
> the operator-definable part. The length results from Y.1731 using 13
> bytes for MEG_IDs and the document is following ITU-T conventions after
> all. So that is where the length comes from. If the WG decides that the
> yourself to alphanumeric you will have 36 states per character
> resulting in 36^4 possible combinations which is around 1.6 million. I
> think the sheer number might not the problem but rather the structure,
> i.e. existing structures might not fit into these 4 characters and
> again, the WG needs to figure this out.
> >
> fields, two of which are of variable length. Let me illustrate this
> with an example to show that the delimiter is needed independent of the
> cannot arise, then you need another token in the ID (or used fixed
> sized fields or use another trick...).
> >
> too early or the content should go into the identifiers draft. Well,
> the content in fact has been in that document. So, in principle the
> need for this already has been acked by the WG. This draft addresses
> the shortcoming which caused the content to be removed. That is why I
> asked the chairs to do the poll now (so please don't blame Ross, blame
> me).
> >

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Jul 2011 09:46:57 -0400

In message <[email-masked]>
> I also believe the content should go back into the identifiers draft

+1

Yes and either way all of the issues have to be resolved before it is
added back or proceeds on its own.

A means to identify MPLS tunnels and LSP are needed.  All of the named
entities listed in draft-ietf-mpls-tp-identifiers-01.txt need to be
accomodated.  If the name space doesn't match the existing name spaces
in OSPF-TE, ISIS-TE, and RSVP-TE (ie: doesn't fit into existing GMPLS
work) which are based on IPv4 and IPv6, before accepting the work the
entire effort must be scoped.

A second limited functionality option is to acknowledge that ICC/CC
style Global_ID is not applicable if a control plane is used.  The
MPLS WG and the IETF would need to decide whether to go forward with a
lame approach, not something IETF tends to do.

Mixing IPv4 and IPv6 identifiers in the control plane and ICC/CC in
the OAM makes little sense.  If ICC/CC is needed for the benefit of an
antiquated OSS system, then a management shim, either on the OSS side
or the NE side or in a management proxy would be preferable.

It is worth noting that the 5 characters in ICC/CC can be fit into
four bytes since only 36 values are used per character.  There are 2
bits left over.  5 characters of 36 bits can be packet into 26 bits,
leaving 6 bits unused.  If this is acceptable, then there are two
Global_ID spaces, both fitting into four bytes.  If 1/64th of the four
byte AS space can be set aside, the ICC/CC space can be fit into the
AS space, setting the 6 unused bits to a fixed value, perhaps all
ones, if ICC/CC numbering is used.  That could be proposed within the
IDR WG or somewhere in the OPS area.  Just as easily as the
microprocessor in network equipment or management software displays
the AS number in its current notation (typically as two 16 bit decimal
values), the ICC encoding can be converted to ASCII ICC/CC
representation for display purposes.

Curtis

---

From: Rolf Winter <[email-masked]>
Date: Fri, 15 Jul 2011 14:43:04 +0000

Curtis,

Interesting encoding but the ICC is up to 6 characters long and the CC is another 2. You could do the CC ones in 5 bits/character but you'd still lack bits.

Best,

Rolf

> Curtis Villamizar
> Sent: Freitag, 15. Juli 2011 15:47
> To: Kyung-Yeop Hong (hongk)
> Cc: [email-masked]; Stewart Bryant (stbryant)
> Subject: Re: [mpls] Identifiers following ITU-T conventions (was:draft-
> win-mpls-tp-itu-t-identifiers-01)
> 
> 
> the
> resulting
> with
> the

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Jul 2011 13:01:50 -0400

In message <[email-masked]>
Rolf Winter writes:
>  
> Curtis,
>  
> Interesting encoding but the ICC is up to 6 characters long and the
> CC is another 2. You could do the CC ones in 5 bits/character but
> you'd still lack bits. 
>  
> Best,
>  
> Rolf

Rolf,

Yes that was a mistake on my part.  Better density is achievable, but
we can't get it into 4 bytes by a simple mapping.

Curtis