Subject: [mpls] R: RE: R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?

From: "[email-masked]" <[email-masked]>
Date: Sun, 22 May 2011 19:32:34 +0200 (CEST)

If I understand correctly, you think that all the operators and all the devices 
MUST support both types of identifiers.

This is not indicated in the draft.

If the consensus is to mandate all the operators to support two types of 
identifiers, the draft needs to be updated to clarify this.

>----Messaggio originale----
>Da: [email-masked]
>Data: 20-mag-2011 18.19
>A: "[email-masked]"<[email-masked]>, "Gregory 
Mirsky"<[email-masked]>, "[email-masked]"<Malcolm.
[email-masked]>
>Cc: "[email-masked]"<[email-masked]>
>Ogg: RE: [mpls] R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP 
Identifiers?
>
>I cannot see how support for mixed identifier types is any
>different from forcing both ICC and IP based operators to
>support both types of identifiers.  Moreover, in addition 
>to requiring the operators to do so, you effectively also
>require every device in any operator's network to do so. 
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
>Sent: Wednesday, May 18, 2011 5:00 PM
>To: Gregory Mirsky; [email-masked]
>Cc: [email-masked]
>Subject: [mpls] R: RE: R: Re: Mixing ICC and Global-IDs in MPLS-TP 
Identifiers?
>
>Well, I understand (and I agree) that it is possible to setup via NMS an LSP 
or 
>a MS-PW that crosses both IP-based and ICC-based domains even if there is 
no 
>e2e OAM.
>
>As this is possible, there is no realistic way to force the ICC-based 
>operators to support also IP-based identification nor viceversa.
>
>The issue is that the draft in its current form does not allow giving a 
name 
>to such an LSP or MS-PW.
>
>If you allow mixing IP-based and ICC-based identifiers for path ID (as 
>proposed by ITU-T), naming these LSPs/MS-PWs becomes very trivial.
>
>As I stated in another mail, I do not see any protocol implications on 
mixing 
>ICC and IP identifiers for path identification so it is not very clear what 
is 
>the technical issue in accepting the ITU-T comment at least for path 
>identification purposes.
>
>>----Messaggio originale----
>>Da: [email-masked]
>>Data: 3-mag-2011 0.31
>>A: "[email-masked]"<[email-masked]>, "Malcolm.
>[email-masked]"<[email-masked]>
>>Cc: "[email-masked]"<[email-masked]>
>>Ogg: RE: [mpls] R: Re:  Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>>
>>Dear Erminio,
>>I don't see an issue with NMS setting an LSP that crosses domains that 
>utilize different, IP-based and ICC-based, identifiers. The problem, as 
being 
>identified, in running e2e OAM on such LSP.
>>
>>	Regards,
>>		Greg
>>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf Of 
>[email-masked]
>>Sent: Monday, May 02, 2011 2:58 PM
>>To: [email-masked]; [email-masked]
>>Cc: [email-masked]; [email-masked]
>>Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>>
>>Section 2.1.4 of RFC5860 states:
>>
>>   For certain functions, OAM messages need to incorporate
>>   identification information (e.g., of source and/or destination
>>   nodes).  The protocol solution(s) MUST at least support
>>   identification information in the form of an IP addressing structure
>>   and MUST also be extensible to support additional identification
>>   schemes.
>>
>>If an operator A supports IP-based identifiers and operator B supports 
ICC- 
>based identifiers, how can we setup a transport path (LSP or PW) between 
the 
>two operators?
>>
>>
>>----Messaggio originale----
>>Da: [email-masked]
>>Data: 28-apr-2011 1.11
>>A: <[email-masked]>
>>Cc: "[email-masked]"<[email-masked]>, <[email-masked]>
>>Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>>
>>Dear Malcolm,
>>I agree that e2e OAM is one of requirements for MPLS-TP but I cannot find 
>>implicit, less explicit requirement to support e2e OAM over MPLS-TP LSP 
and 
>PW 
>>with heterogeneous addressing (mixed IP and ICC).
>>
>>Regards,
>>Greg
>>
>>On Wed, Apr 27, 2011 at 3:44 PM, <[email-masked]> wrote:
>>
>>Eric, 
>>
>>If you "stitch" the LSP or PW and change identifiers you will not have end 
>to 
>>end OAM which is a requirement for a MPLS-TP transport network. 
>>
>>Regards, 
>>
>>Malcolm 
>>
>>
>>
>>Eric Gray <[email-masked]> 
>>Sent by: [email-masked] 27/04/2011 12:11 PM 
>>ToGeorge Swallow <[email-masked]>, "[email-masked]" <[email-masked]> 
>>ccSubjectRe: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>>
>>
>>
>>
>>As one of the co-authors on this draft, I support a restriction to using a 
>>common 
>>form of identifier throughout an LSP or PW. 
>>  
>>In my opinion, it is far better to terminate LSPs or PWs at the point 
where 
>>there 
>>might be an identifier form change and "stitch" them together if that is 
>what 
>>the 
>>operators want/agree to do.  This limits the need-to-know for the mapping 
>of 
>>one 
>>form of identifier to the other to the point at which this occurs, rather 
>than 
>>at each 
>>node in the LSP or (potentially) MS-PW. 
>>
>>From: [email-masked] [mailto:[email-masked]] On Behalf Of 
>George 
>>Swallow
>>Sent: Monday, April 25, 2011 5:17 PM
>>To: [email-masked]
>>Subject: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>>
>>All -
>>
>>Many of the comments received from the ITU on draft-ietf-mpls-tp-
>identifiers-
>>04 have to do with the Global and ICC identifiers.
>>
>>The identifiers for Tunnel, LSP, PW, and MEG include fields to identify 
>each 
>>end of an LSP.  Currently the draft allows a Tunnel, LSP, PW, or MEG to 
use 
>>either the Global-ID for both ends or or the ICC for both ends.  Mixed use 
>is 
>>not permitted.
>>
>>The ITU liaison requests that we allow mixed use.
>>
>>The authors of the draft are very reluctant to do this.  
>>
>>1.        Obtaining an AS Number (from which the Global-ID is derived) is 
a 
>>fairly trivial procedure.  Many organizations if not most already have AS 
>>Numbers. 
>>2.        Such an addition will add numerous object formats, and test 
>cases. 
>>3.        The extent inter-provider MPLS-TP is as yet unknown.  If mixed 
>modes 
>>of ICC and Global-ID identification is required, they can be added later. 
>>4.        For signaled connections, there is no plan to allow routing 
based 
>on 
>>either the Global-ID or ICC.  That would be a radical change to how IP 
>works.  
>>However for IP routing to work (in order to forward the signaling 
>messages), 
>>the providers involved will need to run BGP and have AS numbers. 
>>
>>We are looking for input/consensus from the WG.
>>
>>George, Eric, & Matthew _______________________________________________ 
>>mpls mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>>_______________________________________________
>>mpls mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>>
>>
>>
>>_______________________________________________
>>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: <[email-masked]>
Date: Sun, 22 May 2011 21:18:51 +0100

[email-masked] wrote 22 May 2011 18:33
 
> MUST support both types of identifiers.

NH=> Of course they must.  Forget the distraction of those who would have us implement unnecessary non-TOS peering cases, this also applies to the important client/server transport case.  Here we can have *inter-layer* misconnectivity and thus each party must be able to understand the CV ID it sees incoming from some other party...and in such a case we should be able to identify the other party involved to help Ops folks get the problem sorted quickly.  

Note - Both intra-layer and inter-layer misconnected traffic is also a potential security issue...probably not captured as such however.

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

> >>George, Eric, & Matthew