Loa, George, The authors believe that draft-ietf-mpls-ldp-ipv6-04 is ready for the WGLC. Could you please advise the next step? Cheers, Rajiv _______________________________________________ mpls mailing list mpls <at> ietf.org https://www.ietf.org/mailman/listinfo/mpls
Working Group, this poll has ended and we have enough support to make it a working group document. Can the authors please publish a new version of the document as: draft-ietf-mpls-seamless-mcast-00.txt without any other changes than dates and file name. /Loa On 2011-05-12 15:59, Loa Andersson wrote: > Working Group, > > this is to start a two week poll on making > > draft-raggarwa-mpls-seamless-mcast-03.txt > > 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(Continue reading)
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Multiprotocol Label Switching Working Group of the IETF.
Title : Packet Loss and Delay Measurement for MPLS Networks
Author(s) : Dan Frost
Stewart Bryant
Filename : draft-ietf-mpls-loss-delay-03.txt
Pages : 50
Date : 2011-06-01
Many service provider service level agreements (SLAs) depend on the
ability to measure and monitor performance metrics for packet loss
and one-way and two-way delay, as well as related metrics such as
delay variation and channel throughput. This measurement capability
also provides operators with greater visibility into the performance
characteristics of their networks, thereby facilitating planning,
troubleshooting, and evaluation. This document specifies protocol
mechanisms to enable the efficient and accurate measurement of these
performance metrics in MPLS networks.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-loss-delay-03.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-loss-delay-03.txt
_______________________________________________
mpls mailing list
(Continue reading)
The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Packet Loss and Delay Measurement for MPLS Networks' <draft-ietf-mpls-loss-delay-03.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf <at> ietf.org mailing lists by 2011-06-15. Exceptionally, comments may be sent to iesg <at> ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-loss-delay/(Continue reading)
The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks' <draft-ietf-mpls-tp-loss-delay-profile-03.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf <at> ietf.org mailing lists by 2011-06-15. Exceptionally, comments may be sent to iesg <at> ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Procedures and protocol mechanisms to enable the efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC XXXX. The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport(Continue reading)
|
Hi,
Adrian has suggested that the RTGWG and the MPLS WG review the draft "Generic
Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks", available at http://www.ietf.org/id/draft-ash-gcac-algorithm-spec-00.txt (abstract below).
The underlying goal of the work is to specify an optional GCAC algorithm for IP/MPLS networks, to be adopted and implemented by vendors and service providers, that interoperates between vendor equipment and across multiple service provider domains. This
would be analogous to the PNNI GCAC that was widely adopted and helped promote interoperability of ATM networks. In addition, the approach:
o is based on CSPF, widely implemented by vendors
o does NOT include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms
o relies on available standard mechanisms for MPLS based networks, such as RSVP, DSTE, PCE...
Comments appreciated.
Thanks,
Jerry
From:
Internet-Drafts <at> ietf.org
To: i-d-announce <at> ietf.org Reply-to: Internet-Drafts <at> ietf.org Subject: I-D ACTION:draft-ash-gcac-algorithm-spec-00.txt X-RSN: 1/0/935/34473/37870 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks Author(s) : G. Ash, D. McDysan Filename : draft-ash-gcac-algorithm-spec-00.txt Pages : 23 Date : 2011-1-11 This document presents a generic connection admission control (GCAC) reference model and algorithm for IP/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, for example, to reject voice over Internet Protocol (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers. MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS based networks, such as RSVP, DSTE, PCE, NSIS, DiffServ, and OSPF. The MPLS GCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective QoS for specified QoS constraints. The source is able to compute a source route with high likelihood that MPLS GCAC via elements along the selected path will in fact admit the request. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-gcac-algorithm-spec-00.txt Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce <at> ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ***** Click below to download the attachment(s) in this message: <A HREF="http://www.ietf.org/ibin/c5i?mid=6&gid=0&rid=8&k1=935&file=i-d-announce.37870.1.txt">Attachment: draft_ash_gcac_algorithm_spec_00.txt</A> (1K) |
_______________________________________________ mpls mailing list mpls <at> ietf.org https://www.ietf.org/mailman/listinfo/mpls
Forwarding in plain text... ________________________________ From: Mach Chen [mailto:mach.chen <at> huawei.com] Sent: Sunday, May 22, 2011 11:35 PM To: Malcolm.BETTS <at> zte.com.cn; adrian <at> olddog.co.uk Cc: mpls-bounces <at> ietf.org; mpls <at> ietf.org Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? Hi Malcolm, See my response inline... Ermino, We have already been round this loop on this list once. Want to do it again? [MB] well the continuation of this thread indicates that the loop is still open.... As Huub said, this is about identifiers, not OAM. However, the model for OAM interworking shows "layering" not gatewaying, and certainly not mixing. That is, one end of the e2e path must be capable of operating both systems, but the other does not need to. [MB] OK To extend this model to identifiers means that one end of the e2e path must support both identifier formats and the other does not need to. [MB] It requires that one of the operators must administer both types of identifiers. [Mach] If mixed identifiers used, seems that all relevant domains (other than only one domain) of the path must administer both types of identifiers, and the operators(only prefer to ICC based Opr_ID) have to support and configure both ICC and Global_ID style identifier. On the contrary, for a specific LSP or PW, if only one type of identifiers is used, the operators (only prefer to ICC based Opr_ID) can really only need to support and administer only one type of identifiers (ICC) if they get the agreement of using ICC type of identifier with other operators. This causes two problems a) A (potentially) new operational process must be invoked to assign the second identifier type and; b) Given that a node will terminate/originate traffic from/to the local network and a third party network that node will have (different) identifiers, this will cause significant issues when attempting to perform normal operational processes e.g. alarm reporting. This becomes particularly important to the transit nodes that may have to inspect the identifiers. [MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes only need to check if the (bit string) presented matches the expected string. [Mach] Here is an example that the transit nodes may require to "inspect" the identifiers: MPLS-TP control plane. Because Opr_ID is part of the identifier of an LSP, PW and Section, the control plane has to communicate the Opr_IDs of the LSP, PW or Section among the relevant nodes when signal the LSP, PW or Section. Best regards, Mach BTW, we just submitted two drafts that define extensions to RSVP-TE and PW protocol for communicating Opr_ID when setup an LSP or PW. http://tools.ietf.org/id/draft-chen-ccamp-mpls-tp-oio-00 http://tools.ietf.org/html/draft-chen-pwe3-mpls-tp-aii-icc-00 None of this is new or specific to MPLS-TP. Adrian > -----Original Message----- > From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of > erminio.ottone_69 <at> libero.it > Sent: 18 May 2011 22:25 > To: loa <at> pi.nu; mpls <at> ietf.org; Malcolm.BETTS <at> zte.com.cn > Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > Appendix II of Y.1731 provides a good example about how inter-domain > connectivity with e2e OAM can be provided using transport-oriented OAM > functions. > > You can download the latest version of Y.1731 (the pdr version is for free) at > the following URL: > > http://www.itu.int/rec/T-REC-Y.1731/en > > It is a pity that with the current version of the identifier draft, MPLS-TP is > not capable to support such a network scenario. > > >----Messaggio originale---- > >Da: loa <at> pi.nu > >Data: 4-mag-2011 8.00 > >A: <mpls <at> ietf.org>, > "Malcolm.BETTS <at> zte.com.cn"<Malcolm.BETTS <at> zte.com.cn> > >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > > > >Malcolm, > > > >are you saying that operators today allow OAM to control node (MIPs and > >MEPs) on each others networks? > > > >Do we have an operator that can verify this? > > > >/Loa > > > >On 2011-05-03 22:44, Malcolm.BETTS <at> zte.com.cn wrote: > >> > >> All, > >> > >> I share your concerns and doubts about a multi carrier control plane. > >> However, I think that it is essential that a transport network supports > >> multi carrier data plane interconnection with end to end OAM. In today's > >> transport network this interconnection is supported by SDH and OTN. The > >> objective for MPLS-TP is to allow for packet based interconnection as > well. > >> > >> Regards, > >> > >> Malcolm > >> > >> > >> > >> *George Swallow <swallow <at> cisco.com>* > >> Sent by: mpls-bounces <at> ietf.org > >> > >> 03/05/2011 11:09 AM > >> > >> > >> To > >> "Andrew G. Malis" <agmalis <at> gmail.com>, <neil.2.harrison <at> bt.com> > >> cc > >> mpls <at> ietf.org > >> Subject > >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >> > >> > >> > >> > >> > >> > >> > >> > >> Andy - > >> > >> > Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > >> You are quite correct here! I think much of this debate surrounds a > problem > >> that is yet to be solved. So there are arguments for pieces of a solution > >> without and overall architecture. > >> > >> Based on all that I am seeing my inclination is to NOT say that we > disallow > >> mixed identifiers, but to say that they are for future study. > >> > >> ...George > >> > >> > >> > >> > >> > >> On 5/3/11 8:38 AM, "Andrew G. Malis" <agmalis <at> gmail.com> wrote: > >> > >> > Neil, > >> > > >> > To your case 1, we're in complete agreement. We (VZ) don't see at > >> > least a short-term need for peer-layer interworking, given where we > >> > intend to deploy MPLS-TP in our infrastructure (as an internal server > >> > layer in the transport core). If peer layer interworking ever becomes > >> > a necessity, then obviously we'll need a well-defined E-NNI which > >> > would include LSP identifier mapping/translation at the boundary, for > >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such > >> > an E-NNI definition does not yet exist for MPLS-TP (something else to > >> > put on the to-do list). This E-NNI would also include similar > >> > identifier mapping/translation for MS-PWs, to answer an earlier > >> > question from Erminio that I saw on the list. > >> > > >> > I also agree that both intra-layer and inter-layer mis-connectivity > >> > detection and amelioration are required, but I'm not convinced that > >> > the already defined mechanisms can't do that. Do you have some > >> > specific analysis on the inter-layer case? > >> > > >> > Cheers, > >> > Andy > >> > > >> > On Tue, May 3, 2011 at 3:36 AM, <neil.2.harrison <at> bt.com> wrote: > >> >> Hi Andy, > >> >> > >> >> 2 points: > >> >> > >> >> 1 I agree with your view of only having a single addressing scheme in > a > >> >> single layer network solely belonging to one party. Though you may > >> need to > >> >> be rather careful if you also advocate that one can also have peer > layer > >> >> interworking between different parties, ie E-NNIs (I believe this is > >> >> something you may support, eg old MPLSF case?). In such a peer > >> interworking > >> >> case it would seem one must allow different addressing schemes (and > >> indeed > >> >> any other variations in DP/CP functional components) if they exist > >> in the > >> >> standards. > >> >> > >> >> Of course, having an E-NNI and peer interworking between different > >> parties in > >> >> any non-TOS layer network (not just MPLS) is not technically > >> necessary (this > >> >> is trivial to prove), and this provides a strong argument for only > >> having a > >> >> single addressing scheme in a non-TOS layer network. > >> >> > >> >> > >> >> 2 You should also be aware that in client/server interworking of the > >> >> co-ps mode using variable size traffic units, and therefore > >> something rather > >> >> important for MPLS-TP in the role of a transport network (I'll > >> ignore issues > >> >> of transparency here), there could be inter-layer misconnectivity > >> (Aside=> > >> >> This case cannot occur in the co-cs mode). To date, however, we have > >> only > >> >> really considered intra-layer misconnectivity, ie between different > LSPs > >> >> belonging to the same party (note this also includes all cases of > >> nested LSP > >> >> sublayer misconnectivity). > >> >> > >> >> In the case of inter-layer misconnectivity one may receive traffic > >> units and > >> >> OAM messages from some other party's layer network. The OAM > messages > may > >> >> come from (i) networks using different OAM/addressing solutions or > (ii) > >> >> networks using the same OAM/addressing solutions. In both cases > >> there are > >> >> different issues wrt inter-layer misconnectivity one has to deal > >> with. I'm > >> >> not aware that these cases have been considered yet. > >> >> > >> >> > >> >> I'd like to hear your comments on both these points, but in > >> particular the > >> >> first one.....especially if you also support the notion of E-NNIs in > >> MPLS-TP, > >> >> as there seems to a possible logical conflict here. > >> >> > >> >> Thanks. > >> >> > >> >> regards, Neil Harrison > >> >> > >> >> BT Design > >> >> > >> >> 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----- > >> >>> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf > Of > >> >>> Andrew G. Malis > >> >>> Sent: 02 May 2011 20:48 > >> >>> To: George Swallow > >> >>> Cc: mpls <at> ietf.org > >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers? > >> >>> > >> >>> George et al, > >> >>> > >> >>> Verizon does not have any requirement for mixed use of Global IDs and > >> >>> ICCs. We are fine with specifications that require both ends of an > LSP > >> >>> to use one or the other. > >> >>> > >> >>> Thanks, > >> >>> Andy > >> >>> > >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow <swallow <at> cisco.com> > >> >>> wrote: > >> >>>> 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. > >> >>>> > >> >>>> 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. > >> >>>> Such an addition will add numerous object formats, and test cases. > >> >>>> 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. > >> >>>> 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 > >> >>>> mpls <at> ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/mpls > >> >>>> > >> >>>> > >> >>> _______________________________________________ > >> >>> mpls mailing list > >> >>> mpls <at> ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/mpls > >> >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls <at> ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls <at> ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > >-- > > > > > >Loa Andersson email: loa.andersson <at> ericsson.com > >Sr Strategy and Standards Manager loa <at> pi.nu > >Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > >_______________________________________________ > >mpls mailing list > >mpls <at> ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls <at> ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls <at> ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls <at> ietf.org https://www.ietf.org/mailman/listinfo/mpls
Forwarding in plain text...
________________________________
From: neil.2.harrison <at> bt.com [mailto:neil.2.harrison <at> bt.com]
Sent: Sunday, May 22, 2011 3:56 PM
To: Malcolm.BETTS <at> zte.com.cn
Cc: adrian <at> olddog.co.uk; mpls <at> ietf.org; mpls-bounces <at> ietf.org
Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Thanks Malcolm,
That would work. Though we would need to know a priori what IDs all other parties were using who could enter in
to client/server relationships.
Further, since client/server relationships are THE critical service for a transport network (non-TOS
peering is not a good idea IMO for many reasons) this means we can have inter-layer misconnectivity and
thus it is simply not tenable to say 'we will only consider IDs from this family' anyway. Obviously a single
CV 'SA' structure that all parties use would be best, but if X SA formats are used then each party really
needs to be able to handle incoming misconnected traffic from any of the X SA formats.
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: Malcolm.BETTS <at> zte.com.cn [mailto:Malcolm.BETTS <at> zte.com.cn]
Sent: 22 May 2011 13:36
To: Harrison,N,Neil,DKQ7 R
Cc: adrian <at> olddog.co.uk; mpls <at> ietf.org; mpls-bounces <at> ietf.org
Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Neil,
I should have been more explicit. We have two forms of Global identifiers, ICC based and IP based, both offer
a "real" source ID. I put "real" in quotes since whilst it is a unique identifier it is not a routable address
(in the Ethernet SA sense).
I assume that when we get around to doing the encoding we will have a simple flag to identify which type is
being used to both, avoid accidental collisions and allow interpretation. My assertion is that their is
no need, in the data plane, to understand the semantics of the identifier to determine if it is the correct value.
The actual received value can be passed up to an OSS, off line, for further analysis, at which level, using
the type flag it should be possible to present the actual location, or at least the network that the OAM PDU
was received from. This will allow the source to be identified so that the actual route can be traced to
located the point of the miss-connection.
Regards,
Malcolm
<neil.2.harrison <at> bt.com>
22/05/2011 03:19 AM
To
<Malcolm.BETTS <at> zte.com.cn>, <adrian <at> olddog.co.uk>
cc
<mpls-bounces <at> ietf.org>, <mpls <at> ietf.org>
Subject
RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Malcolm wrote:
"[MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes
only need to check if the (bit string) presented matches the expected string."
IMO this is not a great idea. Indeed, just inserting any old string of symbols is not a great idea
anyway....this was always the major weakness of BFD as originally defined. One wants a proper SA semantic
so that operations folks cannot only detect misconnectivity they can immediately *diagnose* from where
it came.
Note also that when we have a nested transparent (one hopes) client/server relationship (which is a pretty
fundamental capability for a useful co-ps mode transport network) then:
- not only must we be able to detect and diagnose a source of misconnectivity from within this layer network
(ie intra-layer misconnectivity),
- we must also be able to detect and diagnose a source of misconnectivity from other layer networks due to a
misconnectivity defect in some lower server layer network (ie inter-layer misconnectivity) and not
mistake this for intra-layer misconnectivity.
So IMO any identifiers that are used should be pukka SAs.....to use some other structure is not a great idea
IMO....and they must not only be unique across all same technology co-ps mode layer networks that can form
client/server relationships they must also be known to all such layer networks, ie which party owns a
given SA structure, so that rapid operations diagnosis can be made.
I don't think sufficient attention has be paid to the diagnosis point.
regards, Neil
BT Design
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: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of Malcolm.BETTS <at> zte.com.cn
Sent: 22 May 2011 01:04
To: adrian <at> olddog.co.uk
Cc: mpls-bounces <at> ietf.org; mpls <at> ietf.org
Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Adrian,
Please see in line below.
Regards,
Malcolm
"Adrian Farrel" <adrian <at> olddog.co.uk>
Sent by: mpls-bounces <at> ietf.org
20/05/2011 11:45 AM
Please respond to
adrian <at> olddog.co.uk
To
<erminio.ottone_69 <at> libero.it>
cc
mpls <at> ietf.org
Subject
Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Ermino,
We have already been round this loop on this list once.
Want to do it again?
[MB] well the continuation of this thread indicates that the loop is still open....
As Huub said, this is about identifiers, not OAM. However, the model for OAM
interworking shows "layering" not gatewaying, and certainly not mixing. That is,
one end of the e2e path must be capable of operating both systems, but the other
does not need to.
[MB] OK
To extend this model to identifiers means that one end of the e2e path must
support both identifier formats and the other does not need to.
[MB] It requires that one of the operators must administer both types of identifiers. This causes two
problems a) A (potentially) new operational process must be invoked to assign the second identifier type
and; b) Given that a node will terminate/originate traffic from/to the local network and a third party
network that node will have (different) identifiers, this will cause significant issues when
attempting to perform normal operational processes e.g. alarm reporting.
This becomes particularly important to the transit nodes that may have to
inspect the identifiers.
[MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes only
need to check if the (bit string) presented matches the expected string.
None of this is new or specific to MPLS-TP.
Adrian
> -----Original Message-----
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> erminio.ottone_69 <at> libero.it
> Sent: 18 May 2011 22:25
> To: loa <at> pi.nu; mpls <at> ietf.org; Malcolm.BETTS <at> zte.com.cn
> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>
> Appendix II of Y.1731 provides a good example about how inter-domain
> connectivity with e2e OAM can be provided using transport-oriented OAM
> functions.
>
> You can download the latest version of Y.1731 (the pdr version is for free) at
> the following URL:
>
> http://www.itu.int/rec/T-REC-Y.1731/en
>
> It is a pity that with the current version of the identifier draft, MPLS-TP is
> not capable to support such a network scenario.
>
> >----Messaggio originale----
> >Da: loa <at> pi.nu
> >Data: 4-mag-2011 8.00
> >A: <mpls <at> ietf.org>,
> "Malcolm.BETTS <at> zte.com.cn"<Malcolm.BETTS <at> zte.com.cn>
> >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >
> >Malcolm,
> >
> >are you saying that operators today allow OAM to control node (MIPs and
> >MEPs) on each others networks?
> >
> >Do we have an operator that can verify this?
> >
> >/Loa
> >
> >On 2011-05-03 22:44, Malcolm.BETTS <at> zte.com.cn wrote:
> >>
> >> All,
> >>
> >> I share your concerns and doubts about a multi carrier control plane.
> >> However, I think that it is essential that a transport network supports
> >> multi carrier data plane interconnection with end to end OAM. In today's
> >> transport network this interconnection is supported by SDH and OTN. The
> >> objective for MPLS-TP is to allow for packet based interconnection as
> well.
> >>
> >> Regards,
> >>
> >> Malcolm
> >>
> >>
> >>
> >> *George Swallow <swallow <at> cisco.com>*
> >> Sent by: mpls-bounces <at> ietf.org
> >>
> >> 03/05/2011 11:09 AM
> >>
> >>
> >> To
> >> "Andrew G. Malis" <agmalis <at> gmail.com>, <neil.2.harrison <at> bt.com>
> >> cc
> >> mpls <at> ietf.org
> >> Subject
> >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Andy -
> >>
> >> > Such
> >> > an E-NNI definition does not yet exist for MPLS-TP (something else to
> >> > put on the to-do list). This E-NNI would also include similar
> >> > identifier mapping/translation for MS-PWs, to answer an earlier
> >> > question from Erminio that I saw on the list.
> >>
> >> You are quite correct here! I think much of this debate surrounds a
> problem
> >> that is yet to be solved. So there are arguments for pieces of a solution
> >> without and overall architecture.
> >>
> >> Based on all that I am seeing my inclination is to NOT say that we
> disallow
> >> mixed identifiers, but to say that they are for future study.
> >>
> >> ...George
> >>
> >>
> >>
> >>
> >>
> >> On 5/3/11 8:38 AM, "Andrew G. Malis" <agmalis <at> gmail.com> wrote:
> >>
> >> > Neil,
> >> >
> >> > To your case 1, we're in complete agreement. We (VZ) don't see at
> >> > least a short-term need for peer-layer interworking, given where we
> >> > intend to deploy MPLS-TP in our infrastructure (as an internal server
> >> > layer in the transport core). If peer layer interworking ever becomes
> >> > a necessity, then obviously we'll need a well-defined E-NNI which
> >> > would include LSP identifier mapping/translation at the boundary, for
> >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such
> >> > an E-NNI definition does not yet exist for MPLS-TP (something else to
> >> > put on the to-do list). This E-NNI would also include similar
> >> > identifier mapping/translation for MS-PWs, to answer an earlier
> >> > question from Erminio that I saw on the list.
> >> >
> >> > I also agree that both intra-layer and inter-layer mis-connectivity
> >> > detection and amelioration are required, but I'm not convinced that
> >> > the already defined mechanisms can't do that. Do you have some
> >> > specific analysis on the inter-layer case?
> >> >
> >> > Cheers,
> >> > Andy
> >> >
> >> > On Tue, May 3, 2011 at 3:36 AM, <neil.2.harrison <at> bt.com> wrote:
> >> >> Hi Andy,
> >> >>
> >> >> 2 points:
> >> >>
> >> >> 1 I agree with your view of only having a single addressing scheme in
> a
> >> >> single layer network solely belonging to one party. Though you may
> >> need to
> >> >> be rather careful if you also advocate that one can also have peer
> layer
> >> >> interworking between different parties, ie E-NNIs (I believe this is
> >> >> something you may support, eg old MPLSF case?). In such a peer
> >> interworking
> >> >> case it would seem one must allow different addressing schemes (and
> >> indeed
> >> >> any other variations in DP/CP functional components) if they exist
> >> in the
> >> >> standards.
> >> >>
> >> >> Of course, having an E-NNI and peer interworking between different
> >> parties in
> >> >> any non-TOS layer network (not just MPLS) is not technically
> >> necessary (this
> >> >> is trivial to prove), and this provides a strong argument for only
> >> having a
> >> >> single addressing scheme in a non-TOS layer network.
> >> >>
> >> >>
> >> >> 2 You should also be aware that in client/server interworking of the
> >> >> co-ps mode using variable size traffic units, and therefore
> >> something rather
> >> >> important for MPLS-TP in the role of a transport network (I'll
> >> ignore issues
> >> >> of transparency here), there could be inter-layer misconnectivity
> >> (Aside=>
> >> >> This case cannot occur in the co-cs mode). To date, however, we have
> >> only
> >> >> really considered intra-layer misconnectivity, ie between different
> LSPs
> >> >> belonging to the same party (note this also includes all cases of
> >> nested LSP
> >> >> sublayer misconnectivity).
> >> >>
> >> >> In the case of inter-layer misconnectivity one may receive traffic
> >> units and
> >> >> OAM messages from some other party's layer network. The OAM
> messages
> may
> >> >> come from (i) networks using different OAM/addressing solutions or
> (ii)
> >> >> networks using the same OAM/addressing solutions. In both cases
> >> there are
> >> >> different issues wrt inter-layer misconnectivity one has to deal
> >> with. I'm
> >> >> not aware that these cases have been considered yet.
> >> >>
> >> >>
> >> >> I'd like to hear your comments on both these points, but in
> >> particular the
> >> >> first one.....especially if you also support the notion of E-NNIs in
> >> MPLS-TP,
> >> >> as there seems to a possible logical conflict here.
> >> >>
> >> >> Thanks.
> >> >>
> >> >> regards, Neil Harrison
> >> >>
> >> >> BT Design
> >> >>
> >> >> 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-----
> >> >>> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf
> Of
> >> >>> Andrew G. Malis
> >> >>> Sent: 02 May 2011 20:48
> >> >>> To: George Swallow
> >> >>> Cc: mpls <at> ietf.org
> >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >> >>>
> >> >>> George et al,
> >> >>>
> >> >>> Verizon does not have any requirement for mixed use of Global IDs and
> >> >>> ICCs. We are fine with specifications that require both ends of an
> LSP
> >> >>> to use one or the other.
> >> >>>
> >> >>> Thanks,
> >> >>> Andy
> >> >>>
> >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow <swallow <at> cisco.com>
> >> >>> wrote:
> >> >>>> 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.
> >> >>>>
> >> >>>> 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.
> >> >>>> Such an addition will add numerous object formats, and test cases.
> >> >>>> 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.
> >> >>>> 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
> >> >>>> mpls <at> ietf.org
> >> >>>> https://www.ietf.org/mailman/listinfo/mpls
> >> >>>>
> >> >>>>
> >> >>> _______________________________________________
> >> >>> mpls mailing list
> >> >>> mpls <at> ietf.org
> >> >>> https://www.ietf.org/mailman/listinfo/mpls
> >> >>
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> mpls <at> ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> mpls <at> ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
> >--
> >
> >
> >Loa Andersson email: loa.andersson <at> ericsson.com
> >Sr Strategy and Standards Manager loa <at> pi.nu
> >Ericsson Inc phone: +46 10 717 52 13
> > +46 767 72 92 13
> >_______________________________________________
> >mpls mailing list
> >mpls <at> ietf.org
> >https://www.ietf.org/mailman/listinfo/mpls
> >
>
>
> _______________________________________________
> mpls mailing list
> mpls <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Forwarding in plain text...
________________________________
From: Malcolm.BETTS <at> zte.com.cn [mailto:Malcolm.BETTS <at> zte.com.cn]
Sent: Sunday, May 22, 2011 8:36 AM
To: neil.2.harrison <at> bt.com
Cc: adrian <at> olddog.co.uk; mpls <at> ietf.org; mpls-bounces <at> ietf.org
Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Neil,
I should have been more explicit. We have two forms of Global identifiers, ICC based and IP based, both offer
a "real" source ID. I put "real" in quotes since whilst it is a unique identifier it is not a routable address
(in the Ethernet SA sense).
I assume that when we get around to doing the encoding we will have a simple flag to identify which type is
being used to both, avoid accidental collisions and allow interpretation. My assertion is that their is
no need, in the data plane, to understand the semantics of the identifier to determine if it is the correct value.
The actual received value can be passed up to an OSS, off line, for further analysis, at which level, using
the type flag it should be possible to present the actual location, or at least the network that the OAM PDU
was received from. This will allow the source to be identified so that the actual route can be traced to
located the point of the miss-connection.
Regards,
Malcolm
<neil.2.harrison <at> bt.com>
22/05/2011 03:19 AM
To
<Malcolm.BETTS <at> zte.com.cn>, <adrian <at> olddog.co.uk>
cc
<mpls-bounces <at> ietf.org>, <mpls <at> ietf.org>
Subject
RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Malcolm wrote:
"[MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes
only need to check if the (bit string) presented matches the expected string."
IMO this is not a great idea. Indeed, just inserting any old string of symbols is not a great idea
anyway....this was always the major weakness of BFD as originally defined. One wants a proper SA semantic
so that operations folks cannot only detect misconnectivity they can immediately *diagnose* from where
it came.
Note also that when we have a nested transparent (one hopes) client/server relationship (which is a pretty
fundamental capability for a useful co-ps mode transport network) then:
- not only must we be able to detect and diagnose a source of misconnectivity from within this layer network
(ie intra-layer misconnectivity),
- we must also be able to detect and diagnose a source of misconnectivity from other layer networks due to a
misconnectivity defect in some lower server layer network (ie inter-layer misconnectivity) and not
mistake this for intra-layer misconnectivity.
So IMO any identifiers that are used should be pukka SAs.....to use some other structure is not a great idea
IMO....and they must not only be unique across all same technology co-ps mode layer networks that can form
client/server relationships they must also be known to all such layer networks, ie which party owns a
given SA structure, so that rapid operations diagnosis can be made.
I don't think sufficient attention has be paid to the diagnosis point.
regards, Neil
BT Design
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: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of Malcolm.BETTS <at> zte.com.cn
Sent: 22 May 2011 01:04
To: adrian <at> olddog.co.uk
Cc: mpls-bounces <at> ietf.org; mpls <at> ietf.org
Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Adrian,
Please see in line below.
Regards,
Malcolm
"Adrian Farrel" <adrian <at> olddog.co.uk>
Sent by: mpls-bounces <at> ietf.org
20/05/2011 11:45 AM
Please respond to
adrian <at> olddog.co.uk
To
<erminio.ottone_69 <at> libero.it>
cc
mpls <at> ietf.org
Subject
Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Ermino,
We have already been round this loop on this list once.
Want to do it again?
[MB] well the continuation of this thread indicates that the loop is still open....
As Huub said, this is about identifiers, not OAM. However, the model for OAM
interworking shows "layering" not gatewaying, and certainly not mixing. That is,
one end of the e2e path must be capable of operating both systems, but the other
does not need to.
[MB] OK
To extend this model to identifiers means that one end of the e2e path must
support both identifier formats and the other does not need to.
[MB] It requires that one of the operators must administer both types of identifiers. This causes two
problems a) A (potentially) new operational process must be invoked to assign the second identifier type
and; b) Given that a node will terminate/originate traffic from/to the local network and a third party
network that node will have (different) identifiers, this will cause significant issues when
attempting to perform normal operational processes e.g. alarm reporting.
This becomes particularly important to the transit nodes that may have to
inspect the identifiers.
[MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes only
need to check if the (bit string) presented matches the expected string.
None of this is new or specific to MPLS-TP.
Adrian
> -----Original Message-----
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> erminio.ottone_69 <at> libero.it
> Sent: 18 May 2011 22:25
> To: loa <at> pi.nu; mpls <at> ietf.org; Malcolm.BETTS <at> zte.com.cn
> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>
> Appendix II of Y.1731 provides a good example about how inter-domain
> connectivity with e2e OAM can be provided using transport-oriented OAM
> functions.
>
> You can download the latest version of Y.1731 (the pdr version is for free) at
> the following URL:
>
> http://www.itu.int/rec/T-REC-Y.1731/en
>
> It is a pity that with the current version of the identifier draft, MPLS-TP is
> not capable to support such a network scenario.
>
> >----Messaggio originale----
> >Da: loa <at> pi.nu
> >Data: 4-mag-2011 8.00
> >A: <mpls <at> ietf.org>,
> "Malcolm.BETTS <at> zte.com.cn"<Malcolm.BETTS <at> zte.com.cn>
> >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >
> >Malcolm,
> >
> >are you saying that operators today allow OAM to control node (MIPs and
> >MEPs) on each others networks?
> >
> >Do we have an operator that can verify this?
> >
> >/Loa
> >
> >On 2011-05-03 22:44, Malcolm.BETTS <at> zte.com.cn wrote:
> >>
> >> All,
> >>
> >> I share your concerns and doubts about a multi carrier control plane.
> >> However, I think that it is essential that a transport network supports
> >> multi carrier data plane interconnection with end to end OAM. In today's
> >> transport network this interconnection is supported by SDH and OTN. The
> >> objective for MPLS-TP is to allow for packet based interconnection as
> well.
> >>
> >> Regards,
> >>
> >> Malcolm
> >>
> >>
> >>
> >> *George Swallow <swallow <at> cisco.com>*
> >> Sent by: mpls-bounces <at> ietf.org
> >>
> >> 03/05/2011 11:09 AM
> >>
> >>
> >> To
> >> "Andrew G. Malis" <agmalis <at> gmail.com>, <neil.2.harrison <at> bt.com>
> >> cc
> >> mpls <at> ietf.org
> >> Subject
> >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Andy -
> >>
> >> > Such
> >> > an E-NNI definition does not yet exist for MPLS-TP (something else to
> >> > put on the to-do list). This E-NNI would also include similar
> >> > identifier mapping/translation for MS-PWs, to answer an earlier
> >> > question from Erminio that I saw on the list.
> >>
> >> You are quite correct here! I think much of this debate surrounds a
> problem
> >> that is yet to be solved. So there are arguments for pieces of a solution
> >> without and overall architecture.
> >>
> >> Based on all that I am seeing my inclination is to NOT say that we
> disallow
> >> mixed identifiers, but to say that they are for future study.
> >>
> >> ...George
> >>
> >>
> >>
> >>
> >>
> >> On 5/3/11 8:38 AM, "Andrew G. Malis" <agmalis <at> gmail.com> wrote:
> >>
> >> > Neil,
> >> >
> >> > To your case 1, we're in complete agreement. We (VZ) don't see at
> >> > least a short-term need for peer-layer interworking, given where we
> >> > intend to deploy MPLS-TP in our infrastructure (as an internal server
> >> > layer in the transport core). If peer layer interworking ever becomes
> >> > a necessity, then obviously we'll need a well-defined E-NNI which
> >> > would include LSP identifier mapping/translation at the boundary, for
> >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such
> >> > an E-NNI definition does not yet exist for MPLS-TP (something else to
> >> > put on the to-do list). This E-NNI would also include similar
> >> > identifier mapping/translation for MS-PWs, to answer an earlier
> >> > question from Erminio that I saw on the list.
> >> >
> >> > I also agree that both intra-layer and inter-layer mis-connectivity
> >> > detection and amelioration are required, but I'm not convinced that
> >> > the already defined mechanisms can't do that. Do you have some
> >> > specific analysis on the inter-layer case?
> >> >
> >> > Cheers,
> >> > Andy
> >> >
> >> > On Tue, May 3, 2011 at 3:36 AM, <neil.2.harrison <at> bt.com> wrote:
> >> >> Hi Andy,
> >> >>
> >> >> 2 points:
> >> >>
> >> >> 1 I agree with your view of only having a single addressing scheme in
> a
> >> >> single layer network solely belonging to one party. Though you may
> >> need to
> >> >> be rather careful if you also advocate that one can also have peer
> layer
> >> >> interworking between different parties, ie E-NNIs (I believe this is
> >> >> something you may support, eg old MPLSF case?). In such a peer
> >> interworking
> >> >> case it would seem one must allow different addressing schemes (and
> >> indeed
> >> >> any other variations in DP/CP functional components) if they exist
> >> in the
> >> >> standards.
> >> >>
> >> >> Of course, having an E-NNI and peer interworking between different
> >> parties in
> >> >> any non-TOS layer network (not just MPLS) is not technically
> >> necessary (this
> >> >> is trivial to prove), and this provides a strong argument for only
> >> having a
> >> >> single addressing scheme in a non-TOS layer network.
> >> >>
> >> >>
> >> >> 2 You should also be aware that in client/server interworking of the
> >> >> co-ps mode using variable size traffic units, and therefore
> >> something rather
> >> >> important for MPLS-TP in the role of a transport network (I'll
> >> ignore issues
> >> >> of transparency here), there could be inter-layer misconnectivity
> >> (Aside=>
> >> >> This case cannot occur in the co-cs mode). To date, however, we have
> >> only
> >> >> really considered intra-layer misconnectivity, ie between different
> LSPs
> >> >> belonging to the same party (note this also includes all cases of
> >> nested LSP
> >> >> sublayer misconnectivity).
> >> >>
> >> >> In the case of inter-layer misconnectivity one may receive traffic
> >> units and
> >> >> OAM messages from some other party's layer network. The OAM
> messages
> may
> >> >> come from (i) networks using different OAM/addressing solutions or
> (ii)
> >> >> networks using the same OAM/addressing solutions. In both cases
> >> there are
> >> >> different issues wrt inter-layer misconnectivity one has to deal
> >> with. I'm
> >> >> not aware that these cases have been considered yet.
> >> >>
> >> >>
> >> >> I'd like to hear your comments on both these points, but in
> >> particular the
> >> >> first one.....especially if you also support the notion of E-NNIs in
> >> MPLS-TP,
> >> >> as there seems to a possible logical conflict here.
> >> >>
> >> >> Thanks.
> >> >>
> >> >> regards, Neil Harrison
> >> >>
> >> >> BT Design
> >> >>
> >> >> 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-----
> >> >>> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf
> Of
> >> >>> Andrew G. Malis
> >> >>> Sent: 02 May 2011 20:48
> >> >>> To: George Swallow
> >> >>> Cc: mpls <at> ietf.org
> >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >> >>>
> >> >>> George et al,
> >> >>>
> >> >>> Verizon does not have any requirement for mixed use of Global IDs and
> >> >>> ICCs. We are fine with specifications that require both ends of an
> LSP
> >> >>> to use one or the other.
> >> >>>
> >> >>> Thanks,
> >> >>> Andy
> >> >>>
> >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow <swallow <at> cisco.com>
> >> >>> wrote:
> >> >>>> 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.
> >> >>>>
> >> >>>> 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.
> >> >>>> Such an addition will add numerous object formats, and test cases.
> >> >>>> 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.
> >> >>>> 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
> >> >>>> mpls <at> ietf.org
> >> >>>> https://www.ietf.org/mailman/listinfo/mpls
> >> >>>>
> >> >>>>
> >> >>> _______________________________________________
> >> >>> mpls mailing list
> >> >>> mpls <at> ietf.org
> >> >>> https://www.ietf.org/mailman/listinfo/mpls
> >> >>
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> mpls <at> ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> mpls <at> ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
> >--
> >
> >
> >Loa Andersson email: loa.andersson <at> ericsson.com
> >Sr Strategy and Standards Manager loa <at> pi.nu
> >Ericsson Inc phone: +46 10 717 52 13
> > +46 767 72 92 13
> >_______________________________________________
> >mpls mailing list
> >mpls <at> ietf.org
> >https://www.ietf.org/mailman/listinfo/mpls
> >
>
>
> _______________________________________________
> mpls mailing list
> mpls <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Forwarding in plain text...
________________________________
From: neil.2.harrison <at> bt.com [mailto:neil.2.harrison <at> bt.com]
Sent: Sunday, May 22, 2011 3:20 AM
To: Malcolm.BETTS <at> zte.com.cn; adrian <at> olddog.co.uk
Cc: mpls-bounces <at> ietf.org; mpls <at> ietf.org
Subject: RE: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Malcolm wrote:
"[MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes
only need to check if the (bit string) presented matches the expected string."
IMO this is not a great idea. Indeed, just inserting any old string of symbols is not a great idea
anyway....this was always the major weakness of BFD as originally defined. One wants a proper SA semantic
so that operations folks cannot only detect misconnectivity they can immediately *diagnose* from where
it came.
Note also that when we have a nested transparent (one hopes) client/server relationship (which is a pretty
fundamental capability for a useful co-ps mode transport network) then:
- not only must we be able to detect and diagnose a source of misconnectivity from within this layer network
(ie intra-layer misconnectivity),
- we must also be able to detect and diagnose a source of misconnectivity from other layer networks due to a
misconnectivity defect in some lower server layer network (ie inter-layer misconnectivity) and not
mistake this for intra-layer misconnectivity.
So IMO any identifiers that are used should be pukka SAs.....to use some other structure is not a great idea
IMO....and they must not only be unique across all same technology co-ps mode layer networks that can form
client/server relationships they must also be known to all such layer networks, ie which party owns a
given SA structure, so that rapid operations diagnosis can be made.
I don't think sufficient attention has be paid to the diagnosis point.
regards, Neil
BT Design
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: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of Malcolm.BETTS <at> zte.com.cn
Sent: 22 May 2011 01:04
To: adrian <at> olddog.co.uk
Cc: mpls-bounces <at> ietf.org; mpls <at> ietf.org
Subject: Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Adrian,
Please see in line below.
Regards,
Malcolm
"Adrian Farrel" <adrian <at> olddog.co.uk>
Sent by: mpls-bounces <at> ietf.org
20/05/2011 11:45 AM
Please respond to
adrian <at> olddog.co.uk
To
<erminio.ottone_69 <at> libero.it>
cc
mpls <at> ietf.org
Subject
Re: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
Ermino,
We have already been round this loop on this list once.
Want to do it again?
[MB] well the continuation of this thread indicates that the loop is still open....
As Huub said, this is about identifiers, not OAM. However, the model for OAM
interworking shows "layering" not gatewaying, and certainly not mixing. That is,
one end of the e2e path must be capable of operating both systems, but the other
does not need to.
[MB] OK
To extend this model to identifiers means that one end of the e2e path must
support both identifier formats and the other does not need to.
[MB] It requires that one of the operators must administer both types of identifiers. This causes two
problems a) A (potentially) new operational process must be invoked to assign the second identifier type
and; b) Given that a node will terminate/originate traffic from/to the local network and a third party
network that node will have (different) identifiers, this will cause significant issues when
attempting to perform normal operational processes e.g. alarm reporting.
This becomes particularly important to the transit nodes that may have to
inspect the identifiers.
[MB] Why? only the entity inserting the identifier needs to understand the semantics, all other nodes only
need to check if the (bit string) presented matches the expected string.
None of this is new or specific to MPLS-TP.
Adrian
> -----Original Message-----
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> erminio.ottone_69 <at> libero.it
> Sent: 18 May 2011 22:25
> To: loa <at> pi.nu; mpls <at> ietf.org; Malcolm.BETTS <at> zte.com.cn
> Subject: [mpls] R: Re: Mixing ICC and Global-IDs in MPLS-TP Identifiers?
>
> Appendix II of Y.1731 provides a good example about how inter-domain
> connectivity with e2e OAM can be provided using transport-oriented OAM
> functions.
>
> You can download the latest version of Y.1731 (the pdr version is for free) at
> the following URL:
>
> http://www.itu.int/rec/T-REC-Y.1731/en
>
> It is a pity that with the current version of the identifier draft, MPLS-TP is
> not capable to support such a network scenario.
>
> >----Messaggio originale----
> >Da: loa <at> pi.nu
> >Data: 4-mag-2011 8.00
> >A: <mpls <at> ietf.org>,
> "Malcolm.BETTS <at> zte.com.cn"<Malcolm.BETTS <at> zte.com.cn>
> >Ogg: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >
> >Malcolm,
> >
> >are you saying that operators today allow OAM to control node (MIPs and
> >MEPs) on each others networks?
> >
> >Do we have an operator that can verify this?
> >
> >/Loa
> >
> >On 2011-05-03 22:44, Malcolm.BETTS <at> zte.com.cn wrote:
> >>
> >> All,
> >>
> >> I share your concerns and doubts about a multi carrier control plane.
> >> However, I think that it is essential that a transport network supports
> >> multi carrier data plane interconnection with end to end OAM. In today's
> >> transport network this interconnection is supported by SDH and OTN. The
> >> objective for MPLS-TP is to allow for packet based interconnection as
> well.
> >>
> >> Regards,
> >>
> >> Malcolm
> >>
> >>
> >>
> >> *George Swallow <swallow <at> cisco.com>*
> >> Sent by: mpls-bounces <at> ietf.org
> >>
> >> 03/05/2011 11:09 AM
> >>
> >>
> >> To
> >> "Andrew G. Malis" <agmalis <at> gmail.com>, <neil.2.harrison <at> bt.com>
> >> cc
> >> mpls <at> ietf.org
> >> Subject
> >> Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Andy -
> >>
> >> > Such
> >> > an E-NNI definition does not yet exist for MPLS-TP (something else to
> >> > put on the to-do list). This E-NNI would also include similar
> >> > identifier mapping/translation for MS-PWs, to answer an earlier
> >> > question from Erminio that I saw on the list.
> >>
> >> You are quite correct here! I think much of this debate surrounds a
> problem
> >> that is yet to be solved. So there are arguments for pieces of a solution
> >> without and overall architecture.
> >>
> >> Based on all that I am seeing my inclination is to NOT say that we
> disallow
> >> mixed identifiers, but to say that they are for future study.
> >>
> >> ...George
> >>
> >>
> >>
> >>
> >>
> >> On 5/3/11 8:38 AM, "Andrew G. Malis" <agmalis <at> gmail.com> wrote:
> >>
> >> > Neil,
> >> >
> >> > To your case 1, we're in complete agreement. We (VZ) don't see at
> >> > least a short-term need for peer-layer interworking, given where we
> >> > intend to deploy MPLS-TP in our infrastructure (as an internal server
> >> > layer in the transport core). If peer layer interworking ever becomes
> >> > a necessity, then obviously we'll need a well-defined E-NNI which
> >> > would include LSP identifier mapping/translation at the boundary, for
> >> > LSP provisioning (whether static or dynamic) and end-to-end OAM. Such
> >> > an E-NNI definition does not yet exist for MPLS-TP (something else to
> >> > put on the to-do list). This E-NNI would also include similar
> >> > identifier mapping/translation for MS-PWs, to answer an earlier
> >> > question from Erminio that I saw on the list.
> >> >
> >> > I also agree that both intra-layer and inter-layer mis-connectivity
> >> > detection and amelioration are required, but I'm not convinced that
> >> > the already defined mechanisms can't do that. Do you have some
> >> > specific analysis on the inter-layer case?
> >> >
> >> > Cheers,
> >> > Andy
> >> >
> >> > On Tue, May 3, 2011 at 3:36 AM, <neil.2.harrison <at> bt.com> wrote:
> >> >> Hi Andy,
> >> >>
> >> >> 2 points:
> >> >>
> >> >> 1 I agree with your view of only having a single addressing scheme in
> a
> >> >> single layer network solely belonging to one party. Though you may
> >> need to
> >> >> be rather careful if you also advocate that one can also have peer
> layer
> >> >> interworking between different parties, ie E-NNIs (I believe this is
> >> >> something you may support, eg old MPLSF case?). In such a peer
> >> interworking
> >> >> case it would seem one must allow different addressing schemes (and
> >> indeed
> >> >> any other variations in DP/CP functional components) if they exist
> >> in the
> >> >> standards.
> >> >>
> >> >> Of course, having an E-NNI and peer interworking between different
> >> parties in
> >> >> any non-TOS layer network (not just MPLS) is not technically
> >> necessary (this
> >> >> is trivial to prove), and this provides a strong argument for only
> >> having a
> >> >> single addressing scheme in a non-TOS layer network.
> >> >>
> >> >>
> >> >> 2 You should also be aware that in client/server interworking of the
> >> >> co-ps mode using variable size traffic units, and therefore
> >> something rather
> >> >> important for MPLS-TP in the role of a transport network (I'll
> >> ignore issues
> >> >> of transparency here), there could be inter-layer misconnectivity
> >> (Aside=>
> >> >> This case cannot occur in the co-cs mode). To date, however, we have
> >> only
> >> >> really considered intra-layer misconnectivity, ie between different
> LSPs
> >> >> belonging to the same party (note this also includes all cases of
> >> nested LSP
> >> >> sublayer misconnectivity).
> >> >>
> >> >> In the case of inter-layer misconnectivity one may receive traffic
> >> units and
> >> >> OAM messages from some other party's layer network. The OAM
> messages
> may
> >> >> come from (i) networks using different OAM/addressing solutions or
> (ii)
> >> >> networks using the same OAM/addressing solutions. In both cases
> >> there are
> >> >> different issues wrt inter-layer misconnectivity one has to deal
> >> with. I'm
> >> >> not aware that these cases have been considered yet.
> >> >>
> >> >>
> >> >> I'd like to hear your comments on both these points, but in
> >> particular the
> >> >> first one.....especially if you also support the notion of E-NNIs in
> >> MPLS-TP,
> >> >> as there seems to a possible logical conflict here.
> >> >>
> >> >> Thanks.
> >> >>
> >> >> regards, Neil Harrison
> >> >>
> >> >> BT Design
> >> >>
> >> >> 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-----
> >> >>> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf
> Of
> >> >>> Andrew G. Malis
> >> >>> Sent: 02 May 2011 20:48
> >> >>> To: George Swallow
> >> >>> Cc: mpls <at> ietf.org
> >> >>> Subject: Re: [mpls] Mixing ICC and Global-IDs in MPLS-TP Identifiers?
> >> >>>
> >> >>> George et al,
> >> >>>
> >> >>> Verizon does not have any requirement for mixed use of Global IDs and
> >> >>> ICCs. We are fine with specifications that require both ends of an
> LSP
> >> >>> to use one or the other.
> >> >>>
> >> >>> Thanks,
> >> >>> Andy
> >> >>>
> >> >>> On Mon, Apr 25, 2011 at 5:16 PM, George Swallow <swallow <at> cisco.com>
> >> >>> wrote:
> >> >>>> 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.
> >> >>>>
> >> >>>> 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.
> >> >>>> Such an addition will add numerous object formats, and test cases.
> >> >>>> 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.
> >> >>>> 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
> >> >>>> mpls <at> ietf.org
> >> >>>> https://www.ietf.org/mailman/listinfo/mpls
> >> >>>>
> >> >>>>
> >> >>> _______________________________________________
> >> >>> mpls mailing list
> >> >>> mpls <at> ietf.org
> >> >>> https://www.ietf.org/mailman/listinfo/mpls
> >> >>
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> mpls <at> ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> mpls <at> ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
> >--
> >
> >
> >Loa Andersson email: loa.andersson <at> ericsson.com
> >Sr Strategy and Standards Manager loa <at> pi.nu
> >Ericsson Inc phone: +46 10 717 52 13
> > +46 767 72 92 13
> >_______________________________________________
> >mpls mailing list
> >mpls <at> ietf.org
> >https://www.ietf.org/mailman/listinfo/mpls
> >
>
>
> _______________________________________________
> mpls mailing list
> mpls <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
RSS Feed136 | |
|---|---|
90 | |
148 | |
142 | |
184 | |
173 | |
167 | |
193 | |
72 | |
176 | |
226 | |
105 | |
83 | |
95 | |
216 | |
86 | |
100 | |
83 | |
149 | |
141 | |
120 | |
147 | |
303 | |
184 | |
247 | |
182 | |
229 | |
107 | |
148 | |
183 | |
145 | |
170 | |
56 | |
121 | |
217 | |
118 | |
114 | |
168 | |
319 | |
112 | |
92 | |
40 | |
77 | |
66 | |
40 | |
25 | |
56 | |
26 | |
22 | |
16 | |
90 | |
33 | |
18 | |
32 | |
85 | |
115 | |
91 | |
88 | |
63 | |
41 | |
69 | |
74 | |
49 | |
76 | |
29 | |
24 | |
46 | |
32 | |
47 | |
12 | |
44 | |
39 | |
42 | |
33 | |
64 | |
30 | |
49 | |
37 | |
70 | |
49 | |
69 | |
18 | |
36 | |
79 | |
48 | |
103 | |
26 | |
79 | |
29 | |
50 | |
31 | |
38 | |
32 | |
54 | |
37 | |
32 | |
42 | |
32 | |
58 | |
84 | |
26 | |
52 | |
63 | |
111 | |
46 | |
44 | |
34 | |
93 | |
121 | |
83 | |
133 | |
88 | |
82 | |
26 | |
227 | |
121 | |
82 | |
89 | |
118 | |
167 | |
86 | |
161 | |
396 | |
195 | |
164 | |
374 | |
221 | |
157 | |
102 | |
147 | |
435 | |
192 | |
277 | |
245 |
