New Liaison Statement, "Multi-Region and Multi-Layer Networking"
Adrian Farrel (IETF CCAMP WG) <adrian@olddog.co.uk> Wed, 22 August 2007 16:28 UTC
Return-path: <owner-ccamp@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INt4b-0005bl-Dk for ccamp-archive@ietf.org; Wed, 22 Aug 2007 12:28:49 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INt4Z-0007J8-SD for ccamp-archive@ietf.org; Wed, 22 Aug 2007 12:28:49 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1INst6-000FJV-CW for ccamp-data@psg.com; Wed, 22 Aug 2007 16:16:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_WHITELIST autolearn=no version=3.2.1
Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from <mirror@ietf.org>) id 1INst2-000FJ4-2A for ccamp@ops.ietf.org; Wed, 22 Aug 2007 16:16:54 +0000
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 120352AC65; Wed, 22 Aug 2007 16:16:51 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43) id 1INst0-00028d-R8; Wed, 22 Aug 2007 12:16:50 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: Greg Jones <greg.jones@itu.int>
Cc: Kam Lam <hklam@alcatel-lucent.com>, Stephen Trowbridge <sjtrowbridge@alcatel-lucent.com>, Ross Callon <rcallon@juniper.net>, David Ward <dward@cisco.com>, Scott Bradner <sob@hardward.edu>, CCAMP Mailing List <ccamp@ops.ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, Deborah Brungard <dbrungard@att.com>, Adrian Farrel <adrian@olddog.co.uk>, Deborah Brungard <dbrungard@att.com>
From: Adrian Farrel <adrian@olddog.co.uk>
Subject: New Liaison Statement, "Multi-Region and Multi-Layer Networking"
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
Message-Id: <E1INst0-00028d-R8@ietf.org>
Date: Wed, 22 Aug 2007 12:16:50 -0400
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86
Title: Multi-Region and Multi-Layer Networking Submission Date: 2007-08-22 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=360 Please reply by 2007-09-20 From: Adrian Farrel(IETF CCAMP WG) <adrian@olddog.co.uk> To: ITU-T Q14/15(Greg Jones <greg.jones@itu.int>) Cc: Kam Lam <hklam@alcatel-lucent.com> Stephen Trowbridge <sjtrowbridge@alcatel-lucent.com> Ross Callon <rcallon@juniper.net> David Ward <dward@cisco.com> Scott Bradner <sob@hardward.edu> CCAMP Mailing List <ccamp@ops.ietf.org> Reponse Contact: Adrian Farrel <adrian@olddog.co.uk> Deborah Brungard <dbrungard@att.com> Technical Contact: Adrian Farrel <adrian@olddog.co.uk> Deborah Brungard <dbrungard@att.com> Purpose: For action Body: The CCAMP working group of the IETF thanks you for your liaison titled "Follow up Liaison Statement to IETF CCAMP on Multi-Layer Networking" generated from your May 2007 interim meeting. This communication provides answers and explanations in response to the comments and questions that your liaison raised. As previously indicated, the CCAMP working group is ready to hold a working group last call on these two Internet-Drafts. However, in view of your comments and interest in this work we are delaying this last call to allow you to consider our responses and to provide further comments during your September interim meeting. Any additional comments that you supply will be treated as working group last call comments and handled accordingly. Working Group last call will complete on 21 September 2007 at 12 noon GMT. Please ensure that any comments are received by the IETF before that time. The latest copies of the drafts concerned can be found at http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-05.txt and http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-03.txt draft-ietf-ccamp-gmpls-mln-reqs "1. General - Does this draft apply only to single service provider or do you envision it applying when there are multiple service providers? The ASON model (G.8080) allows for many different configurations of multilayer networks ranging from a single provider administering all layers and regions to a different provider per layer or region to several providers per layer or region. If two layers are under different administrative domains because they belong to two different providers, the amount of information that can be shared between the two domains is more limited than in the case where a single provider network provides resources at all layers." A customer network may be provided on top of the GMPLS-based multi-region/multi-layer network. It is indeed a strong motivator for the deployment of multi-region/multi-layer networks as described in Section 3.2 of the draft. This draft is, however, scoped to the assumption that the control plane and the data plane are under the responsibility of a single service provider and so constitute a single administrative domain. The MRN/MLN suite of documents makes no assumptions concerning the interfaces with other domains (e.g. UNI, E-NNI). In particular, the specific problem examined within the CCAMP MRN/MLN work is the integration of multiple network layers (that may be from different regions) within the same administrative domain. Requirements for multiple network layers under different administrative domains are out of scope of this document. It should be noted that the term region used in the MRN/MLN suite of documents is as per IETF definition (see RFC4206). The statement has been added to Section 1 to articulate that this draft is scoped to the requirements for multi-layer networks under a single control plane and that the requirements for multi-layer networks under different administrative domains are out of scope of this document. But note also that Secitons 1 and 3.3 of this document reference RFC4726 (A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering) for interconnection of MRN/MLN TE domains. Another RFC of possible interest on multilayer-multidomain discusion is RFC4655 (PCE Architecture). "2. Section 3 - There is an example of several layers of a TDM region. The addition of a VCAT layer example would be more complete. For example, VC-4-7v." Thank you for this suggestion. We have integrated this example into the I-D. "3. Section 3.1 - The last paragraph mentions discontinuity when crossing a region boundary. We would like to point out that the ASON model does not have control plane discontinuity when crossing a region boundary as there are call controllers at each layer. Call controllers at both ends of adaptation into a server (lower) layer communicate with each other." There may be some misunderstanding of the term "discontinuity". In the context of this section of the draft, "discontinuity" indicates that it may not be possible to simply forward the signaling message (i.e. RSVP-TE Path message) from a node in one layer to a node in the next layer (even when stitching or 1:1 multiplexing is used) because there is a necessary change in some of the signaling objects (for example, the representation of bandwidth) at region boundaries. We may solve the discontinuity issue in a method similar to that of ASON by using triggered signaling or any of the other mechanisms described in this document. To help clear up the misunderstanding, the last paragraph of Section 3.1 will be rephrased. "4. Section 5.3 - Scalability problems can be minimized by the use of TED per region in case they are under separate administration or for scalability reason." It is correct to note that the use of a separate TED per region can improve the scalability. However, part of the objective of the MRN/MLN work is to allow full visibility from each network node into all participating layers/regions. Splitting the TED will not reduce the amount of information stored or flooded within the network. Indeed, as multiple switching capabilities can be advertised in a single TE-link advertisement, the total number of entries in a TED should not differ much from a single layer network (although each entry may be a little larger). Furthermore, the number of TE-link advertisements should not differ much from a single layer network (although each advertisement may be slightly larger), thus not putting additional strain on the routing protocol flooding process. No scalability problems have been identified. Section 5.3 will be further clarified. "5. Section 5.8.2 - Virtual TE-links - We can think of two different models and are not sure which one is implied in this document. The first one is that a virtual TE-link represents server (lower) layer potential connectivity. The second one is that a virtual TE-link represents client (upper) layer potential connectivity. The first one requires knowledge of the adaptation capabilities by the client (upper) layer. The second does not require any knowledge of the adaptation capabilities or even the existence of the server (lower) layer and should also be a valid configuration. The second option may be required, for example, when the different layers are administered by different entities." The virtual TE-link represents potential client layer connectivity that may be achieved through potential server layer connections. The client layer connectivity is potential because the TE-link does not actually exist (event though it is treated in the client layer exactly as though it does exist). The server layer connections are potential because the LSPs necessary to support the TE-link have not been set up. It may be helpful to recap some terminology. A TE-link is (as discussed in the GMPLS/ASON lexicography set out in RFC 4397) a logical routing element that allows path selection to be decoupled from resource assignment. Thus a TE-link is associated with one or more data links. This is equivalent to an SNPP link. A TE-link in one layer may, of course, be achieved by one or more LSPs in a lower layer. That is, an LSP in one layer may form a data link in an upper layer. A virtual TE-link (again referencing RFC 4397) is a TE-link associated with zero data links. It is the potential for a TE- link, that may be used in path computation on the assumption that, if it is used, an attempt will be made dynamically to create the necessary data link(s). That is, to signal an LSP in a lower layer, to designate the LSP as a data link in the upper layer, and to assign the data link to the TE-link. Thus, the virtual TE-link is dynamically converted into an actual TE-link. Please note that one of the comments we will be considering during working group last call is the suggestion to change the name "virtual TE link" to "potential TE link". Advertisement of the virtual TE-link is dependent (just as with a real TE-link) on the adaptation capabilities at the end points. As far as client layer network is concerned, there is no difference between virtual and real TE-links. In both cases the TE-link is connectivity in the client layer, but (clearly) with a virtual TE-link, although the connectivity is advertised as if it is real, it is only potential. The principal difference between a real TE-link and a virtual TE-link is that the server layer network resources are not tied up when the virtual TE-link is not in use, and that the signaling process of the client layer LSP might fail if the virtual TE-link cannot be realized (i.e., if the server layer LSPs cannot be set up). "6. Section 4.2 - The last paragraph mentions that TE-link advertisements may need to provide information about the node's internal adaptation capabilities in order to perform layer border node functions. It might be worth clarifying the instances where this is required versus not required. For example, if virtual TE-links are used to represent the client (upper) layer connectivity, it is not necessary to advertise internal adaptation capabilities." There is no difference with respect to real or virtual TE- links in this regard, and all TE-links (virtual or otherwise) must be considered with regard to their switching types and the adaptation capabilities of their end points. The adaptation capability, enables a node to discriminate the remote nodes (and thus allows their selection during a multi- region path computation) with respect to their adaptation capability. i.e., their capability to terminate LSPs at a given region. Please see also RFC4397 for adaptation capability definitions. draft-ietf-ccamp-gmpls-mln-eval "1. Section 4.1.1.2 - Setting up virtual TE-links. We would like to understand why the virtual TE-links need to be created as opposed to discovered, manually or dynamically. In terms of scalability, could a virtual TE-link (assuming it represents server (lower) layer resources) be assigned a virtual link identifier that may be locally associated to one or more link identifiers? It is not clear from the draft whether this is allowed or not but we think it is essential in developing a scalable solution. In case the virtual TE-link could represent client (upper) layer potential connectivity, the identifier would have to be virtual as it would represent potential adaptation capability into a server (lower) layer." First of all, please note again that the requirements for multi-layer networks under different administrative domains are out of scope of this document. Advertising the virtual TE-link into the "client" network, which is under different administrative domain, is out of scope of this document. The above question may be separated into three sub-questions as follows; Q1-a) Why do the virtual TE-links need to be created as opposed to discovered, manually or dynamically? A1-a) It would be possible to automatically discover all potential connections across the lower layer network and to advertise a full mesh of virtual TE-links. However, we believe that this scenario is unlikely to meet with the requirements of service providers who will want to apply their own operational policies. Such operational policies effectively install a management function (e.g., VNT Manager) between the analysis of the lower layer potential connections, and the advertisement of virtual TE-links. However, nothing precludes from a policy of discovering and advertising such a full mesh. Q1-b) Could a virtual TE-link be assigned a virtual link identifier that may be locally associated to one or more link identifiers? A1-b) In general, data link identifiers can be autogenerated and "discovered" through information exchange between adjacent nodes. TE-link identifiers can similarly be autogenerated, and exchanged and associated with data links. This, however, presupposes the existence of the data links when the TE-links are created. The virtual TE-link represents potential connectivity (as discussed for point 5, above), but does not have a server layer trail (i.e., a client layer data link) committed. The virtual TE-links must still be advertised so that they can be use in path computation. Virtual TE- link identifiers are assigned at both end points. They are logical identifiers and are not necessarily identical to any identifiers associated with the real physical interfaces. They may be picked from a local pool of identifiers at both end points and exchanged between the the end points. On the other hand, assigning the identifier associated with a real physical interface to the virtual TE-link is not precluded. Clearly configuration (manual or through an automated process such as the Virtual Network Topology Manager) may provide this information in this case. The use of LMP for exchange of information for virtual TE-links is for future study. Q1-c) In case the virtual TE-link could represent client (upper) layer potential connectivity, would the identifier have to be virtual as it would represent potential adaptation capability into a server (lower) layer? A1-c) As described in A1-b), the identifier of the virtual TE-link could be associated with a real physical interface. Note, however, that many virtual TE-links could exist where there is the physical capacity for only one server layer tail at any time. It may be convenient to assign each virtual TE-link a different identifier. "2. Section 4.1.1.3 - Traffic disruption minimization during FA release. In case disruption is required in the server (lower) layer, we think there is also an option to signal to the adaptation points and let them re-establish the server (lower) layer as opposed to rely on the head-end LSRs in the client (upper) layer." Section 4.1.1.3 does not specify nor preclude any mechanism to deal with traffic disruption. In the context of the MRN/MLN, upper layer LSPs may be routed over FAs. For reasons outside the scope of these documents, an FA may need to be released or rerouted. This may have a disruptive effect on the LSPs using this FA in the sense that this would induce a route change of these upper layer LSPs. Only the head-end LSR of an (FA-)LSP is responsible for re-routing or releasing FA-LSPs. As such head-end LSRs ("adaptation points" as stated in the question) are responsible for rerouting/releasing FA-LSPs and head-end LSRs of the upper layer LSPs are responsible for rerouting the LSPs they control. The adaptation points can NOT take responsibility for rerouting upper layers LSPs over other (newly established or not) FAs if they are not head-end LSRs of the upper-layer LSPs but only intermediate LSRs for these LSPs The data link created in an upper layer by an FA LSP may be a protected data link (in the meaning of link level protection - see RFC 3471). This link level protection may be achieved by end-to-end protection of the FA LSP, or through any other LSP protection scheme including LSP restoration. This case seems to match what you have described, but note that the process of switching traffic (i.e. the nested LSP) from one FA LSP to another is likely to cause a small traffic hit in all but packet/frame technologies. We would like to thank you for your detailed enquiry into this topic, and hope that you feel that the discussion has been fruitful. Best regards, Deborah Brungard and Adrian Farrel IETF CCAMP Co-chairs Attachment(s): No document has been attached
- New Liaison Statement, "Multi-Region and Multi-La… Adrian Farrel (IETF CCAMP WG)