Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

From: Ross Callon <[email-masked]>
Date: Tue, 12 Jul 2011 11:31:46 -0400

Working Group,

this is to start a 12 day poll on making

draft-win-mpls-tp-itu-t-identifiers-01

an mpls working group document.

If you support the document becoming a working group document please
respond to this poll with "yes/support"

If you do not support the document becoming a working group document
please respond to this poll with "no/do not support" and at the same time
give the technical reasons why you are not supporting the document.

If you have technical comments or in any other way want to discuss the
document, please send these comments to the mpls working group mailing
list, but with another subject than what is on this mail. Please include the
string "draft-win-mpls-tp-itu-t-identifiers" in the subject line.

The poll ends 2011-07-24.  Please note that this is the Sunday before the
IETF. Also note that the length of the poll has  been shortened by two days
so that the poll can be completed prior to our first WG meeting in Quebec City.

Ross

---

From: "Kyung-Yeop Hong (hongk)" <[email-masked]>
Date: Tue, 12 Jul 2011 11:01:21 -0500

No / Do not support.

Section 5 proposes a 13 characters long MEG ID format:

ICC (1-6 characters) plus "/" (1 character) plus CC (2 characters) plus
UMC (4-9 characters).

The UMC is limited to 4 characters if 6 characters are used for the ICC.
The UMC is a unique operators' code and defined by their name plan which
can be based on their geographical area and transmission detail
information. In other Recommendations (e.g. G.709) defining ICC-based
format, minimum 6 or 7 characters are allocated for unique operators'
code.

In order to allow operators for future growth of their networks and to
maintain their name plan consistent with other Recommendations and
existing deployments, the UMC must not be limited to 4 characters.

KY

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ross Callon
Sent: Tuesday, July 12, 2011 11:32 AM
To: [email-masked]
Cc: Ross Callon; [email-masked]
Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

Working Group,

please respond to this poll with "no/do not support" and at the same
time 

list, but with another subject than what is on this mail. Please include
the 

The poll ends 2011-07-24.  Please note that this is the Sunday before
the 

IETF. Also note that the length of the poll has  been shortened by two
days 

so that the poll can be completed prior to our first WG meeting in
Quebec City.  

Ross

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 12 Jul 2011 18:22:48 +0100

I am not going to express an opinion either way on the adoption of this 
document as WG draft. That is for the working group to decide.

I do however have a few questions that I would like to ask the authors.

The proposal seems to be to constrain the total identifier length to 
13bytes. Why is this necessary?

The format chosen is ICC::Country_Code, using a "/" char as a separator. 
Why is that better than going from most unique to least unique, 
particularly since the CC is a fixed format. So why did you not adopt 
the format CC::ICC?

You then say that 16 bits of further MEG discriminator is sufficient. 
How do we know that this is indeed sufficient?

Why have you not provided at least a 32 bit integer for this purpose in 
order to make sure we have sufficient identifier space with the ability 
to partition (subnet) allocations?

I note that the equivalent function in Y.1731 provides about 36 bits of 
identifier space (7 octets of 36 states/octet), so compressing this by a 
factor of 10^6 would seem to require some explanation to the working 
group so as to verify the decision.

- Stewart

---

From: Rolf Winter <[email-masked]>
Date: Tue, 12 Jul 2011 18:12:02 +0000

Yes/Support. I don't think that every detail of the document is done yet and surely needs discussion. However the subject of the draft has been part of a wg draft already and I think the wg should take ownership of the document.

On 12.07.2011, at 17:34, "Ross Callon" <[email-masked]<mailto:[email-masked]>> wrote:

Working Group,

If you have technical comments or in any other way want to discuss the
document, please send these comments to the mpls working group mailing
list, but with another subject than what is on this mail. Please include the
string “draft-win-mpls-tp-itu-t-identifiers” in the subject line.

Ross

---

From: John E Drake <[email-masked]>
Date: Tue, 12 Jul 2011 11:50:03 -0700

Ross,

Isn't it a bit premature to be asking to make this a working group document?

Thanks,

John

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Tuesday, July 12, 2011 8:32 AM
To: [email-masked]
Cc: Ross Callon; [email-masked]
Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

Working Group,

Ross

---

From: <[email-masked]>
Date: Tue, 12 Jul 2011 21:49:39 +0200

Yes/support.

This document provides the right basis to move forward.
Furthermore, it provides content for an important matter (as part of the MPLS-TP requirements) that has already been adopted by the WG.

Thanks,

Manuel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Tuesday, July 12, 2011 5:32 PM
To: [email-masked]
Cc: Ross Callon; [email-masked]
Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

Working Group,

Ross

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 12 Jul 2011 22:53:18 +0200

"yes/support"
this document provides a method to uniquely provide an
Operator ID and how this can be used in a MEG-ID.

Regards, Huub.

On 12-07-11 17:31, Ross Callon wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

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

---

From: Huang Feng <[email-masked]>
Date: Wed, 13 Jul 2011 05:36:25 +0800

Yes/support

BR
hffellow

Send from my iPhone

---

From: "Zhenlong Cui" <[email-masked]>
Date: Wed, 13 Jul 2011 09:13:07 +0900

Yes/support.

Thanks,
Zhenlong

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Wednesday, July 13, 2011 12:32 AM
To: [email-masked]
Cc: Ross Callon; [email-masked]
Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

Working Group,

 

 

Ross

---

From: "HUANG Feng F" <[email-masked]>
Date: Wed, 13 Jul 2011 08:42:32 +0800

yes/support
B.R.
Feng

Sent: 2011年7月12日 23:32

Working Group,

 

 

Ross

---

From: [email-masked]
Date: Wed, 13 Jul 2011 08:41:58 +0800

yes/support

Ross Callon <[email-masked]> 
发件人:  [email-masked]
2011-07-12 23:31

收件人
"[email-masked]" <[email-masked]>
抄送
Ross Callon <[email-masked]>, 
"[email-masked]" 
<[email-masked]>
主题
[mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

Working Group,

 

 
 
The poll ends 2011-07-24.  Please note that this is the Sunday before the 
IETF. Also note that the length of the poll has  been shortened by two 
days 
so that the poll can be completed prior to our first WG meeting in Quebec 
City. 
 
Ross

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: [email-masked]
Date: Wed, 13 Jul 2011 11:02:15 +0800

Yes/Support

收件人

Working Group,

 

 

Ross

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Wed, 13 Jul 2011 11:06:59 +0200

Dear John,
if you mean "do not support", please could  you provide a technical reason. I'm interested in knowing your position.

Best regards,
Alessandro

------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

Da: [email-masked] [mailto:[email-masked]] Per conto di John E Drake
Inviato: martedì 12 luglio 2011 20:50
A: Ross Callon; [email-masked]
Cc: [email-masked]
Oggetto: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

Ross,

Thanks,

John

Sent from my iPhone

Working Group,

Ross

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Wed, 13 Jul 2011 11:07:26 +0200

Yes support

Da: [email-masked] [mailto:[email-masked]] Per conto di Ross Callon
Inviato: martedì 12 luglio 2011 17:32
A: [email-masked]
Cc: Ross Callon; [email-masked]
Oggetto: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

Working Group,

Ross

---

From: <[email-masked]>
Date: Wed, 13 Jul 2011 10:31:01 +0100

I also have a question on this draft:

How do different MPLS-TP layer networks that belong to the same operator get differentiated...noting that these may form nested client/server relationships and thus be subject to inter-layer misconnectivity as well as intra-layer misconnectivity?

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

> -----Original Message-----
> Stewart Bryant
> Sent: 12 July 2011 18:23
> Subject: [mpls] draft-win-mpls-tp-itu-t-identifiers-01
> 
>

---

From: [email-masked]
Date: Wed, 13 Jul 2011 10:44:05 -0400

Yes/support

Ross Callon <[email-masked]> 
Sent by: [email-masked]
12/07/2011 11:31 AM

To
cc
Subject

Working Group,

 

 

Ross

---

From: venkatesan mahalingam <[email-masked]>
Date: Wed, 13 Jul 2011 10:58:57 -0400

Yes/Support

Regards,
Venkat.

>  *Ross Callon <[email-masked]>*
> Ross Callon <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> Subject

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 13 Jul 2011 17:21:04 +0200

Hi,

I am a bit concerned. 

I think the IETF should support ICC based identifiers as required and
agreed. 

BUT

I am concerned from the same technical concerns and question that K.Y.
and Stewart raised up. I think the document is immature for adoption. 

Moreover, I do not think it is the role of the IETF to define the format
of global ICC. We need to ask the ITU-T for a reference to a document
that defines global ICC to ensure consistent definition with other
transport networks. 

I do not think the IETF should refer to a liaison as a technical
specification as is, but as a mean to get a pointer to the appropriate
document that we need to refer to. 

I do not see the benefit in just putting a place holder for an IETF
document. Let's first bring the information and then we should progress
with the document. 

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Ross Callon
Sent: Tuesday, July 12, 2011 6:32 PM
To: [email-masked]
Cc: Ross Callon; [email-masked]
Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

Working Group,

Ross

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 13 Jul 2011 13:09:16 -0400

In message <[email-masked]>
Ross Callon writes:
> list, but with another subject than what is on this mail. Please include th=
> e
> so that the poll can be completed prior to our first WG meeting in Quebec C=
> ity.
>  
> Ross

No / Do not support

This should be input to draft-ietf-mpls-tp-identifiers-06 which is
already a WG document and has matured quite a bit over its six
iterations so far.

I'm not saying that it should be accepted, but it is input.  If
anything this is a new 13 byte Global_ID that might be considered as
an alternate to the 4-octet AS number (which is essentially what the
draft suggests).

However the problem is that the ASCII is OK for configuration but the
four byte binary is used in the AII type 2 used in PW [RFC5003,
RFC4446].  A new AII type is needed if this format is accepted.  There
is also the issue that the Tunnel_ID and Extended_Tunnel_ID in RFC3209
is 4 bytes or 16 bytes and has in the past been a globally unique
identifier that happens to be an IP address.  In
draft-ietf-mpls-tp-identifiers this is set to the node_ID which
happily fits nicely.

Any attempt to use ICC/CC would have to update all documents that
currently use a four byte or 16 byte identifier which is normally
configured with an IPv4 or IPv6 address.  Since this is likely to be
impractical and breaks backwards compatibility with all MPLS
implementations up to now, I dont' support this.

Curtis

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Jul 2011 10:18:44 -0700

Alessandro,

I was not taking a position.  Rather, I was strictly asking a procedural question.

Thanks,

John

Sent from my iPhone

From: D'Alessandro Alessandro Gerardo [mailto:[email-masked]]
Sent: Wednesday, July 13, 2011 2:07 AM
To: John E Drake; [email-masked]
Cc: [email-masked]
Subject: R: Poll on draft-win-mpls-tp-itu-t-identifiers-01

Dear John,

Best regards,
Alessandro

Ross,

Thanks,

John

Sent from my iPhone

Working Group,

Ross

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 13 Jul 2011 13:42:22 -0400

In message <[email-masked]>
[email-masked] writes:
> How do different MPLS-TP layer networks that belong to the same
> operator get differentiated...noting that these may form nested
> client/server relationships and thus be subject to inter-layer
> misconnectivity as well as intra-layer misconnectivity?
>  
> Thanks.....regards, Neil

How about the operator allocates from a different IP prefix for each
layer and uses a one line policy statement to prevent inter-layer
misconnectivity even if misconfiguration were to occur.

Oops.  Wrong type of identifiers.  No identifier aggregation in the
ICC/CC name space.

:-)

IMHO ICC/CC makes even less sense than using 20 byte OSI addresses.
At least those could be aggregated (not that I recommend using them).

Curtis

---

From: <[email-masked]>
Date: Thu, 14 Jul 2011 08:42:25 +0100

[email-masked] observes 13 July 2011 18:42
 
> At least those could be aggregated (not that I recommend using them).

Curtis, I get the feeling here you think I am pro the ITU suggested addressing structure.  I am not.  The ancient Recs this stuff comes from were based on really old PDH layer networks where operators did not use proper addressing structures but some general alpha-numeric symbol string.  BT tried to deprecate this form of 'addressing' in the SDH Recs but some US operators wanted to keep this old addressing structure.

I am merely pointing out that besides distinguishing operators we also need to distinguish each different MPLS-TP layer network that belongs to the same operator in whatever addressing structure is used.  I think it should be obvious why this is required.

regards, Neil

---

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

Neil

Yes, I think that you are correct. Leaving aside PWs for the moment, 
presumably an operator should consider each of their layer networks to 
be considered as an individual autonomous system and identify it as such.

Stewart

On 14/07/2011 08:42, [email-masked] wrote:
>> In message<6D3D47CB84BDE349BC23BF1C94E316E4405B29F6B0@EMV62-
>> UKRD.domain1.systemhost.net>

-- 
For corporate legal information go to:

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

---

From: <[email-masked]>
Date: Thu, 14 Jul 2011 12:28:21 +0100

Exactly so Stewart...I'm glad at least you get this.

We have never had to deal with the issue of nested layer networks that have ostensibly identical characteristic information in co-cs mode transport networks based on regular time-slices before (eg PDH, SDH), simply because the traffic unit (==frame) here has a fixed/deterministic resource size in bits...so you cannot nest them, eg we cannot have T1overT1.  This is not the case with the co-ps mode that is based on irregular time slices of resource and, specifically, a variable traffic unit length in bits....such as MPLS-TP.

Traditional LSP nesting is sublayering...so this is all the same layer network.  But MPLS-TP demands we can do proper layering of different MPLS-TP layer networks.  And a single operator may want to have several MPLS-TP layer networks for different purposes and these can form client/server relationships.

So, the addressing structure of 'source' as used in CV flows needs to not only identify the operator but also the specific layer network of that operators.

regards, Neil

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: 14 July 2011 12:18
> To: Harrison,N,Neil,DKQ7 R
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01
> 
> Neil
> 
> > Curtis, I get the feeling here you think I am pro the ITU suggested
> addressing structure.  I am not.  The ancient Recs this stuff comes
> from were based on really old PDH layer networks where operators did
> not use proper addressing structures but some general alpha-numeric
> symbol string.  BT tried to deprecate this form of 'addressing' in the
> SDH Recs but some US operators wanted to keep this old addressing
> structure.
> >
> > I am merely pointing out that besides distinguishing operators we
> also need to distinguish each different MPLS-TP layer network that
> belongs to the same operator in whatever addressing structure is used.
> I think it should be obvious why this is required.
> >
> > regards, Neil
> >

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Jul 2011 10:17:37 -0400

In message <[email-masked]>
[email-masked] writes:
> I am merely pointing out that besides distinguishing operators we also
> need to distinguish each different MPLS-TP layer network that belongs
> to the same operator in whatever addressing structure is used.  I
> think it should be obvious why this is required.
>  
> regards, Neil

Neil,

I understood that you were pointing out a limitation in the ICC/CC as
an identifier.  I was sort of adding to that.

In addition to the absolutely trivial approach of assigning from
different prefixes, there is also all of the IGP MT work and the GMPLS
MLN/MRN work to isolate layers in routing and signaling.  The IGP
instance used in these is not carried into the OAM.  If we look at the
tp-identifiers draft, we have a 4 byte or 16 byte Node_ID but no IGP
instance.  So using a prefix works even if Global_ID is set to zero.

I don't see a need to add IGP instance to Node_ID since the AS number
is available and there is a large pool of numbers reserved as private
AS numbers for use within a provider (originally intended for use in
BGP Conferations).  Where IGP instance never leaves the provider the
reserved private AS numbers can be used.

OTOH why should we settle for something simple that works when we
could have a committee design something complicated.  This isn't your
grandfather's IETF, where simple solutions and running code matters.
We have ITU-T helping us now.  :-)

Curtis

---

From: [email-masked]
Date: Thu, 14 Jul 2011 10:28:25 -0400

As Neil points out below each operator must ensure that the MEG identifier 
is unique for each LSP that is being monitored within the scope of that 
operator.  This is also stated in section 5 of the draft   "The UMC MUST 
be unique within the organization identified by the ICC."   The need to 
make the UMC unique is independent of the method used to identify the 
operator.

Regards,

Malcolm

<[email-masked]> 
14/07/2011 07:28 AM

To
<[email-masked]>
cc
[email-masked]
Subject
Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01

We have never had to deal with the issue of nested layer networks that 
have ostensibly identical characteristic information in co-cs mode 
transport networks based on regular time-slices before (eg PDH, SDH), 
simply because the traffic unit (==frame) here has a fixed/deterministic 
resource size in bits...so you cannot nest them, eg we cannot have 
T1overT1.  This is not the case with the co-ps mode that is based on 
irregular time slices of resource and, specifically, a variable traffic 
unit length in bits....such as MPLS-TP.

Traditional LSP nesting is sublayering...so this is all the same layer 
network.  But MPLS-TP demands we can do proper layering of different 
MPLS-TP layer networks.  And a single operator may want to have several 
MPLS-TP layer networks for different purposes and these can form 
client/server relationships.

So, the addressing structure of 'source' as used in CV flows needs to not 
only identify the operator but also the specific layer network of that 
operators.

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

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 14 Jul 2011 09:36:10 -0500

Yes/Support

--Kam

Working Group,

Ross

---

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

Malcolm and Yes/Supporters,

MEG ID is unique for each LSP. 

As I pointed out in my earlier email (re: "No / Do not support"), the
unique MEG ID code (UMC) is limited to 4 characters as defined in
Section 5 of draft-win-mpls-tp-itu-t-identifiers.

In case of MPLS-TP associated bidirectional LSP ID, each of the
unidirectional LSPs require LSP_nums (16-bit unsigned integer). So the
32 bits are required just for LSP ID, and additional 32 x 2 bits for
Node ID and so on.

How can you identify it only with 4 characters?

You cannot simply say it's a matter for the operator to use a different
method and provide unique IDs.

KY

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, July 14, 2011 10:28 AM
To: [email-masked]; [email-masked]
Subject: Re: [mpls] draft-win-mpls-tp-itu-t-identifiers-01 - the UMC
must beunique

As Neil points out below each operator must ensure that the MEG
identifier is unique for each LSP that is being monitored within the
scope of that operator.  This is also stated in section 5 of the draft
"The UMC MUST be unique within the organization identified by the ICC."
The need to make the UMC unique is independent of the method used to
identify the operator. 

Regards, 

Malcolm 

<[email-masked]> 

14/07/2011 07:28 AM 

To

<[email-masked]> 

cc

[email-masked] 

Subject

		

So, the addressing structure of 'source' as used in CV flows needs to
not only identify the operator but also the specific layer network of
that operators.

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

> From: Stewart Bryant [mailto:[email-masked]
<mailto:[email-masked]> ]
> > Registered in England no: 1800000
<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> 

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls
<https://www.ietf.org/mailman/listinfo/mpls>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Jul 2011 17:11:30 +0100

Malcolm

There some outstanding questions I raised, in particular whether there 
was enough address apace in your proposal which I think only leaves 
space for 65535 discrete values.

Stewart

On 14/07/2011 15:28, [email-masked] wrote:
>   "The UMC MUST be unique within the organization identified by the 
> ICC."   The need to make the UMC unique is independent of the method 
> used to identify the operator.
>
> Regards,
>
> Malcolm
>
>
>
> *<[email-masked]>*
> simply because the traffic unit (==frame) here has a 
> fixed/deterministic resource size in bits...so you cannot nest them, 
> eg we cannot have T1overT1.  This is not the case with the co-ps mode 
> that is based on irregular time slices of resource and, specifically, 
> a variable traffic unit length in bits....such as MPLS-TP.
>
> MPLS-TP layer networks.  And a single operator may want to have 
> several MPLS-TP layer networks for different purposes and these can 
> form client/server relationships.
>

---

From: Scott Mansfield <[email-masked]>
Date: Mon, 18 Jul 2011 15:01:01 -0400

WG adoption will be an excellent way to work through the issues in the current individual draft.  Yes/support adoption.

regards,
-scott.

Working Group,

Ross

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 19 Jul 2011 15:08:49 +0200

+1  Yes/Support

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Scott Mansfield
Sent: Monday, July 18, 2011 10:01 PM
To: Ross Callon; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

WG adoption will be an excellent way to work through the issues in the
current individual draft.  Yes/support adoption.

regards,

-scott.

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ross Callon
	Sent: Tuesday, July 12, 2011 11:32 AM
	To: [email-masked]
	Cc: Ross Callon;
[email-masked]
	Subject: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

	Working Group,

	If you support the document becoming a working group document
please 

	If you do not support the document becoming a working group
document 

	please respond to this poll with "no/do not support" and at the
same time 

	give the technical reasons why you are not supporting the
document.

	If you have technical comments or in any other way want to
discuss the 

	document, please send these comments to the mpls working group
mailing 

	list, but with another subject than what is on this mail. Please
include the 

	string "draft-win-mpls-tp-itu-t-identifiers" in the subject
line. 

	The poll ends 2011-07-24.  Please note that this is the Sunday
before the 

	IETF. Also note that the length of the poll has  been shortened
by two days 

	so that the poll can be completed prior to our first WG meeting
in Quebec City.  

	Ross

---

From: Ross Callon <[email-masked]>
Date: Tue, 19 Jul 2011 16:27:23 -0400

John;

Accepting a document as a working group document is very different from deciding whether it is ready to pass WG last call.

In deciding whether to accept a document as a working group document, we need to think about whether this is an appropriate work for the WG to take on, is in the WG's charter, and whether the document is a reasonable start towards a working group document. It certainly does not need to be complete or in a finished form.

In this case, the notion of having identifiers based on the ITU-T's ICC codes was previously in a working group document, but was removed because we found technical issues with it. This document is a start at resolving those issues.

Ross

From: John E Drake
Sent: Tuesday, July 12, 2011 2:50 PM
To: Ross Callon; [email-masked]
Cc: [email-masked]
Subject: RE: Poll on draft-win-mpls-tp-itu-t-identifiers-01

Ross,

Thanks,

John

Sent from my iPhone

Working Group,

Ross

---

From: John E Drake <[email-masked]>
Date: Tue, 19 Jul 2011 13:46:14 -0700

Ross,

Thanks for your clarification and I will answer yes to your question.

John

Sent from my iPhone

From: Ross Callon
Sent: Tuesday, July 19, 2011 1:27 PM
To: John E Drake
Cc: [email-masked]; [email-masked]
Subject: RE: Poll on draft-win-mpls-tp-itu-t-identifiers-01

John;

Ross

From: John E Drake

Ross,

Thanks,

John

Sent from my iPhone

Working Group,

Ross

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 20 Jul 2011 07:43:53 +0200

Ross hi,

I fully agree with your point.

As mentioned before, I think we need to work on this.

My concern is how we ensure that ITU-T code is defined appropriately and
in consistent way with other definitions in transport networks? I have
seen technical debates on the definition both in the ITU-T and the IETF
mailing lists. 

I would prefer we refer to a definition in an ITU-T recommendation. 

Best regards,

Nurit 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Ross Callon
Sent: Tuesday, July 19, 2011 11:27 PM
To: John E Drake
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

John;

Accepting a document as a working group document is very different from
deciding whether it is ready to pass WG last call. 

In deciding whether to accept a document as a working group document, we
need to think about whether this is an appropriate work for the WG to
take on, is in the WG's charter, and whether the document is a
reasonable start towards a working group document. It certainly does not
need to be complete or in a finished form. 

In this case, the notion of having identifiers based on the ITU-T's ICC
codes was previously in a working group document, but was removed
because we found technical issues with it. This document is a start at
resolving those issues. 

Ross

From: John E Drake 

Ross,

Isn't it a bit premature to be asking to make this a working group
document?

Thanks,

John

Sent from my iPhone

Working Group,

Ross

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 21 Jul 2011 15:20:19 -0400

Ross,

Inline ...

In message <[email-masked]>
Ross Callon writes:
>  
> John;
>  
> Accepting a document as a working group document is very different
> from deciding whether it is ready to pass WG last call.
>  
> In deciding whether to accept a document as a working group document,
> we need to think about whether this is an appropriate work for the WG
> to take on, is in the WG's charter, and whether the document is a
> reasonable start towards a working group document. It certainly does
> not need to be complete or in a finished form.

I think the objections are related to "and whether the document is a
reasonable start towards a working group document".

It covers only OAM identifiers and not tunnel, LSP, PW, etc and
therefor it is too incomplete to be a reasonable start.  If either the
same author or another provided a more complete document, then it
would be a reasonable start.  If the WG feels that it is acceptable to
specify use of ICC/CC restricted to no use of a control plane, then
that must be very agreed to by the WG and very clearly stated in the
draft.

So far MPLS-TP will support a control plane but make it optional to
use it and therefore this is a major departure.

> In this case, the notion of having identifiers based on the ITU-T's
> ICC codes was previously in a working group document, but was removed

Regards,

Curtis

> time give the technical reasons why you are not supporting the
> document.
>  
> include the string "draft-win-mpls-tp-itu-t-identifiers" in the
> subject line.
>  
> the IETF. Also note that the length of the poll has been shortened by
> two days so that the poll can be completed prior to our first WG
> meeting in Quebec City.
>  
> Ross

---

From: Yuji Tochio <[email-masked]>
Date: Fri, 22 Jul 2011 10:27:00 +0900

Yes/support

Regards, Yuji

---

From: Rui Costa <[email-masked]>
Date: Fri, 22 Jul 2011 08:21:02 +0100

Yes/support.

Regards,
Rui

Working Group,

Ross

---

From: HUANG Feng F <[email-masked]>
Date: Fri, 22 Jul 2011 16:05:53 +0800

+1

---

From: Rolf Winter <[email-masked]>
Date: Fri, 22 Jul 2011 08:29:03 +0000

Curtis,

> that must be very agreed to by the WG and very clearly stated in the

That is not quite accurate. I think you have missed this part of our document:

"The same substitution procedure applies to all identifiers specified
in [I-D.ietf-mpls-tp-identifiers] except for the other alternatives
mentioned in this document."

In other words, _all_ IDs are already there and made globally unique with the ICC_Operator_ID defined in section 4. 

Best,

Rolf

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

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 22 Jul 2011 10:23:56 -0400

In message <[email-masked]>
Rolf Winter writes:
> In other words, _all_ IDs are already there and made globally unique
> with the ICC_Operator_ID defined in section 4.

Perhaps I needed to provide more detail to expand on the perhaps too
terse point that I made above.

A key point in I-D.ietf-mpls-tp-identifiers is that all of the
identifiers are consistent with existing routing and signaling
extensions defined for MPLS (including GMPLS and MPLS-TP) and PW.

The 4 byte global ID (based on AS number) is consistent with RFC 5003
"Attachment Individual Identifier (AII) Types for Aggregation".  The
unique Attachment Interface Identifier (AII) is a four byte quantity.

  3.1.  The Global ID

   RFC 5003 [3] defines a globally unique Attachment Interface
   Identifier (AII).  That AII is composed of three parts, a Global ID
   which uniquely identifies a operator, a prefix, and finally and
   attachment circuit identifier.  We have chosen to use that Global
   ID for MPLS-TP.  Quoting from RFC 5003, section 3.2, "The global ID can
   contain the 2-octet or 4-octet value of the operator's Autonomous
   System Number (ASN).  It is expected that the global ID will be
   derived from the globally unique ASN of the autonomous system hosting
   the PEs containing the actual AIIs.  The presence of a global ID
   based on the operator's ASN ensures that the AII will be globally
   unique."

The ITU Carrier Code does not have that property (fitting nicely into
four bytes and uniquely identifying a provider).

A quick search for SAII or TAII or RFC 5003 yields the following.  The
following documents either reference RFC 5003 or make use of AII.

  RFC 4379 - Detecting Multi-Protocol Label Switched (MPLS)
	     Data Plane Failures

  RFC 4447 - Pseudowire Setup and Maintenance
             Using the Label Distribution Protocol (LDP)

  RFC 4667 - Layer 2 Virtual Private Network (L2VPN) Extensions
             for Layer 2 Tunneling Protocol (L2TP)

  RFC 4762 - Virtual Private LAN Service (VPLS) Using
             Label Distribution Protocol (LDP) Signaling

  RFC 5287 - Control Protocol Extensions for the Setup of
             Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks

  RFC 5601 - Pseudowire (PW) Management Information Base (MIB)

  RFC 6073 - Segmented Pseudowire

  RFC 6074 - Provisioning, Auto-Discovery, and Signaling
             in Layer 2 Virtual Private Networks (L2VPNs)

At the very least, RFC 5003 needs to be updated with a new document
defining a new AII type.

Then any implementation claiming compatibility needs to update all of
the above protocol implementations to accommodate the new AII type.
The list above may not be complete in that inclusion of RFC 4447
implies any use of PW with LDP signaling, therefore impacts the
implementation of most documents from the PWE3 WG.  The inclusion of
RFC 4379 in the list means that any use of MPLS Ping, including MPLS
use, PW use in VCCI, and MPLS-TP use is impacted.

If I were to expand the search to find references to RFC 4379 and RFC
4447 there would be a very long list of RFC implementations affected.

> Rolf

The reason I have called this work hopelessly incomplete is that you
have specified a "wish" to use ICC/CC as the GLobal_ID, but have not
specified or called for necessary protocol extensions, and nave not
even touched on the impact of doing so and enumerated the changes to
existing protocol implementations that would be required.

In addition, I see zero gain in using ICC/CC rather than AS number and
quite a bit of pain in doing so.  Going from IPv4 to IPv6 has proven
quite painful (and is still ongoing) but the pain was endured for a
very good reason.

Regards,

Curtis

---

From: [email-masked]
Date: Fri, 22 Jul 2011 22:35:12 +0800

Yes/support

Fei

收件人

Working Group,

 

 

Ross

---

From: John E Drake <[email-masked]>
Date: Fri, 22 Jul 2011 07:38:54 -0700

Curtis,

It sounds like the authors have a lot or work to do.

Thanks,

John

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, July 22, 2011 7:24 AM
> To: Rolf Winter
> Cc: [email-masked]; Ross Callon; John E Drake; [email-masked]; draft-
> [email-masked]
> In message
> <[email-masked]>
> Rolf Winter writes:
> >
> > Curtis,
> >
> > please see inline:
> >
> >

---

From: [email-masked]
Date: Fri, 22 Jul 2011 11:36:43 -0400

Curtis,

The introduction of draft-ietf-mpls-tp-identifiers states:

1.  Introduction

   This document specifies an initial set of identifiers to be used in
   the Transport Profile of Multiprotocol Label Switching (MPLS-TP).
   The MPLS-TP requirements (RFC 5654) [7] require that the elements and
   objects in an MPLS-TP environment are able to be configured and
   managed without a control plane.  In such an environment many
   conventions for defining identifiers are possible.  This document
   defines identifiers for MPLS-TP management and OAM functions suitable
   to IP/MPLS conventions.  The identifiers have been chosen to be
   compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions.

The mapping to control plane identifiers is only mentioned in section 5.3:

5.3.  Mapping to RSVP Signaling

   This section is informative and exists to help understand the
   structure of the LSP IDs.
   GMPLS [5] is based on RSVP-TE [2].  This section defines the mapping
   from an MPLS-TP LSP_ID to RSVP-TE.  At this time, RSVP-TE has yet to
   be extended to accommodate Global_IDs.  Thus a mapping is only made
   for the network unique form of the LSP_ID.

As Rolf stated in his reply, win-mpls-tp-itu-t-identifiers describes the 
substitution of the global ID with an ICC based identifier.

On this basis I am have trouble understanding how your comments are 
relevant.

Regards,

Malcolm

Curtis Villamizar <[email-masked]> 
Sent by: [email-masked]
22/07/2011 10:23 AM
Please respond to
[email-masked]

To
Rolf Winter <[email-masked]>
cc
"[email-masked]" <[email-masked]>, Ross Callon <[email-masked]>, 
John E Drake <[email-masked]>, "[email-masked]" <[email-masked]>, 
"[email-masked]" 
<[email-masked]>
Subject
Re: [mpls] Poll on draft-win-mpls-tp-itu-t-identifiers-01

  3.1.  The Global ID

Regards,

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 22 Jul 2011 15:25:28 -0400

Malcolm,

The text you cite has nothing to do with the issues related to AII in
PW.  The AII does specificy a globally unique identifier which can be
used if PW T-PE are using IPv4 private address space and a lot of
protocol definitions and implementations rely on the PW AII.

Curtis

---

From: Ross Callon <[email-masked]>
Date: Sun, 24 Jul 2011 21:48:41 -0400

This poll has now ended, and the document has been accepted as a working group document.

Authors, please re-submit this document as draft-ietf-mpls-tp-itu-t-identifiers-00.

(Also note that the window for submitting internet drafts is currently closed, but will re-open sometime tomorrow).

Thanks, Ross

_____________________________________________
From: Ross Callon
Sent: Tuesday, July 12, 2011 11:32 AM
To: [email-masked]
Cc: [email-masked]; Ross Callon; Loa Andersson; George Swallow; Martin Vigoureux
Subject: Poll on draft-win-mpls-tp-itu-t-identifiers-01

Working Group,

Ross